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

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

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

[2016 年举办的可靠性工程师学会大会]3 汇聚了来自全球各地的多家企业,探讨企业在继续扩展业务的同时其网站可靠性工程师所面临的各种问题,包括“究竟什么才能成就强大的 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 官方博客

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

相关文章
|
6月前
|
存储 数据可视化 数据管理
Google Earth Engine谷歌地球引擎GEE外部栅格矢量数据导入管理与下载及数据与代码共享
Google Earth Engine谷歌地球引擎GEE外部栅格矢量数据导入管理与下载及数据与代码共享
153 1
【Google Play】创建和管理内部测试版本 ( 创建内部测试版本 | 检查并发布内部测试版本 )(一)
【Google Play】创建和管理内部测试版本 ( 创建内部测试版本 | 检查并发布内部测试版本 )(一)
726 0
【Google Play】创建和管理内部测试版本 ( 创建内部测试版本 | 检查并发布内部测试版本 )(一)
|
前端开发
实战:第十八章:facebook和google免登接入
实战:第十八章:facebook和google免登接入
113 0
实战:第十八章:facebook和google免登接入
《Facebook Online Schema Change原理和大规模表结构变更最佳实践》电子版地址
Facebook Online Schema Change原理和大规模表结构变更最佳实践
84 0
《Facebook Online Schema Change原理和大规模表结构变更最佳实践》电子版地址
|
存储 SQL 缓存
Google 大规模监控系统 --Monarch
Google 大规模监控系统 --Monarch
291 0
Google 大规模监控系统 --Monarch
|
XML Android开发 数据格式
android google market 不能搜索到facebook或显示不兼容
android google market 不能搜索到facebook或显示不兼容
183 0
|
存储 缓存 NoSQL
社交网络场景下大规模图存储实践——Facebook TAO
社交网络场景下大规模图存储实践——Facebook TAO
217 0
社交网络场景下大规模图存储实践——Facebook TAO
|
编解码 定位技术 数据库
Google Earth Engine——PAD-US是美国官方的国家清单,其中包括专门用于保护生物多样性和其他自然、娱乐和文化用途的美国陆地和海洋保护区,并通过法律或其他有效手段对这些区域进行管理。
Google Earth Engine——PAD-US是美国官方的国家清单,其中包括专门用于保护生物多样性和其他自然、娱乐和文化用途的美国陆地和海洋保护区,并通过法律或其他有效手段对这些区域进行管理。
114 0
Google Earth Engine——PAD-US是美国官方的国家清单,其中包括专门用于保护生物多样性和其他自然、娱乐和文化用途的美国陆地和海洋保护区,并通过法律或其他有效手段对这些区域进行管理。
|
安全 开发工具 开发者
【Google Play】管理目标受众群体 ( 加入“亲子同乐计划“ 由于政策原因 “更新被拒“ 后的处理 )(一)
【Google Play】管理目标受众群体 ( 加入“亲子同乐计划“ 由于政策原因 “更新被拒“ 后的处理 )(一)
228 0
【Google Play】管理目标受众群体 ( 加入“亲子同乐计划“ 由于政策原因 “更新被拒“ 后的处理 )(一)
|
开发工具
【Google Play】管理目标受众群体 ( 加入“亲子同乐计划“ 由于政策原因 “更新被拒“ 后的处理 )(一)
【Google Play】管理目标受众群体 ( 加入“亲子同乐计划“ 由于政策原因 “更新被拒“ 后的处理 )(一)
143 0
【Google Play】管理目标受众群体 ( 加入“亲子同乐计划“ 由于政策原因 “更新被拒“ 后的处理 )(一)