Google 和 Facebook 如何大规模处理 IT 事件管理 —— 2016 SRE 大会之我见-阿里云开发者社区

开发者社区> oneapm_official> 正文

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/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Qt之处理QNetworkAccessManager网络连接超时
简述 在网络操作中,经常会由于各种原因引起网络连接超时,究竟何为网络连接超时? 网络连接超时:在程序默认的等待时间内没有得到服务器的响应 简述 超时原因 Qt 中的网络连接超时 如何处理超时 封装类 超时原因 引起网络连接超时的原因很多,下面,列举一些常见的原因: 网络断开,不过经常显示无法连接 网络阻塞,导致你不能在程序默认等待时间
3800 0
0316理解db file parallel read等待事件
[20180316]理解db file parallel read等待事件.txt --//一直对db file parallel read等待事件不理解,因为在实际系统中很少遇到这样的等待事件.
1038 0
RAC中的等待事件
■ Block-oriented■ gc current block 2-way■ gc current block 3-way■ gc cr block 2-way■ gc cr block 3-way■ Message-oriented■ gc curren...
567 0
能在电脑桌面提醒待办事项的日程安排管理软件
很多上班族越来越习惯找寻一款桌面日程安排软件来管理待办日程、提醒任务事项,常见的比如win7系统的便笺、win10系统的便利贴等。
3280 0
CEGUI的事件系统分析
当客户向事件系统发送了一个事件之后,即是执行EventSet::fireEvent. EventSet::fireEvent首先执行了GlobalEventSet:: fireEvent,而后才执行其自身的一个方法EventSet::fireEvent_impl,该方法才是真正进行事件处理的方法,由该方法的后缀impl即可得知了.
1364 0
+关注
oneapm_official
分享技术干货,解决性能问题,塑造品牌力量!
188
文章
2
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载