Google 和 Facebook 如何大规模处理 IT 事件管理 —— 2016 SRE 大会之我见

OneAPM蓝海讯通

【编者按】本文作者为 Maria Arbisman,主要介绍 Google 与 Facebook 两大巨头是如何大规模处理 IT 事件管理。文章系国内 ITOM 管理平台 OneAPM 编译呈现。

2016 年举办的可靠性工程师学会大会 (SREcon 2016) 汇聚了来自全球各地的多家企业,探讨企业在继续扩展业务的同时其网站可靠性工程师所面临的各种问题,包括“究竟什么才能成就强大的 SRE 团队”这样的准生存问题。似乎很多公司都会把精干的软件工程师和运营人才拼凑在一起,以此确保网站可靠性工程职能。但无论怎样精心组织这些团队,他们都是在努力让过去一直依赖于人力的过程自动化。这些过程通常围绕性能、可用性、效率、监测、事件管理、延迟和可靠性。

全球顶尖企业的发言人向与会者介绍了最佳实践,也坦率地探讨了其方法的一些局限性。我发现两个讨论组特别有意思(我刚写完一篇有关根源分析进化论的文章),这两个讨论组的主角是当今最最成功的两家企业:Google 和 Facebook。以下内容就是我对这两家企业如何应对 IT 事件管理的重要领悟。

Facebook 深入探讨的问题是:“人类应当留意哪些 IT 告警?”

Facebook 的产品工程师 Brian Smith 首先向我们介绍了 Facebook 用来确定 IT 事件应否入人类法眼(这一过程被称为 SAR,即信号、可行动性和关联性)的准则的初步定义。

  • 信号 — 这是误报吗?一定是信号不足!

  • 可行动性 — 收到这一告警时,能立即采取措施吗?

  • 关联性 — 收到这一告警时,有其他告警传达相同内容或重叠吗?如果是,请删除其中一个告警。

Smith 表示,使用 SAR 方法并在每个栈区只持续关注一个告警,就能提高可行动性和关联性。他解释道,Facebook 利用这一方法消除了 97% 的告警,从而减少了每天收到的噪音,也提高了总体运营效率。

Google 的问题是“在 IT 事件管理中,哪个指标最为重要?”

Google 的项目经理 Sue Lueder 要求她的团队在事后分析中采用一种标记系统,这有助于精准地指出他们认为在优化 IT 事件管理时最重要的五大关键字段:

  1. 开始时间

  2. 结束时间

  3. 检测时间

  4. 鉴别分流时间

  5. 确定根源时间

Google 利用这一系统,结合一份包括侥幸脱险和级联故障的严重程度量表,来确定后期告警的阈值,不断要求其团队选择“如果这一事件再次发生,你是否愿意接受”。

Facebook 和 Google 的 IT 事件管理法适用于你的企业吗?

从事后标记到确定可执行的告警,这两家科技巨头(L2 公司创始人 Scott Galloway 戏称 Facebook 和 Google 为数字大动乱的天启四骑士之二)费尽心血,只为完善他们的事件管理例程,让所有成功进化的小规模事件管理能在其企业内得到充分利用。

但不是每家企业都能像 Facebook 和 Google 这样。对其他企业来说,解决方案用过即弃、使用过多操作人员或创建大量并行的数据中心这些方法完全行不通。

如果你真的按照这些方法来,最后还是不能实时探测新问题和消除虚假告警。对于扩展操作,正确的方法是借助计算机来运行这些企业中目前由人类来管理的事务。通过这一转变,机器能够进行持续的分析,而解决问题仍然依靠人类,只要敢于创新,就能取得更丰硕的业务成果。

如果产品环境规模较小,或者需要应付和单一根源挂钩的事件时,Facebook 的方法会是个很好的选择。可惜的是,现代企业的产品环境往往较大,要应付的事件也相对复杂,所以如果每个栈区丢弃所有告警只保留一个,会有极大风险,这是因为事件告警风暴往往有多个起因(Forrester 公司的一份报告进一步佐证了这一结论,该报告指出,有 74% 的 IT 事件不是由 IT 部门而是由其他人员汇报的,而这些其他人员甚至包括最终用户 — 这可不太乐观)。

相反,如果解决方案不仅能挑选出数据中的异常现象和常规模式,进而显示整个基础架构内多个告警之间的紧密联系,还能洞察你曾经遇到的各种问题,那么你的整体服务质量就能得到提升,这是因为把数据放在上下文中来考虑并理解这些指标背后的事态发展,会让响应更有效更及时。

增加实时分析解决方案也可以进一步提高 Google 系统的效率,因为这一解决方案可以改进 Google 的过程,让操作人员解决问题花费的所有时间以及所需的所有关键指标都得以实时存储并按照具体“情况”(“情况”由一组相关联的或“集群的”事件来定义)编入目录,从而瞬间生成其五大关键字段分析,而无需返回、检查、在事后分析过程中给所有内容所标记。我们知道,事后分析过程成本高昂,尤其是在没有可动态捕捉取证活动的工具时。

除了这些关键字段之外,我们认为,如果能增加诊断步骤和关键解析行动指标来比对事件集群(“情况”)之间的相似性,也是非常有益的,这不仅缩短了平均检测时间,也能利用历史数据来帮助指引后期响应,从而加快解决问题的步伐。

我们坚信,未来,事件数据分析必须在事件发生时就要集中精力实时处理数据。不过,使用自适应式事件管理模式的企业也应该广开门路,积极降低运营成本,把人类解放出来,让他们去做最拿手的工作:创新。

本文系 OneAPM 工程师编译整理。OneAlertOneAPM 旗下产品,是国内第一个 SaaS 模式的云告警平台,集成国内外主流监控/支撑系统,实现一个平台上集中处理所有 IT 事件,提升 IT 可靠性。想阅读更多技术文章,请访问 OneAPM 官方技术博客

本文转自 OneAPM 官方博客

原文地址:https://www.moogsoft.com/whats-new/blog/google-facebook-incident-management-scale-insights-srecon-2016/

阅读 1.3k

OneAPM 官方技术专栏
OneAPM 官方技术分享平台

Software makes the world run. OneAPM makes the software run.

11.4k 声望
237 粉丝
0 条评论

Software makes the world run. OneAPM makes the software run.

11.4k 声望
237 粉丝
宣传栏