亚马逊在3月末的大规模互联网中断提醒人们,任何提供公共云服务的公司,无论大小,都需要事件响应计划。停电是生活中的事实; 重要的是当它们发生时你如何应对。
拥有适当的流程是必不可少的,但是这些流程不能 (也不应该尝试) 涵盖所有可能发生的情况。如果上午3点发生意外,您的事件响应团队需要坚定的指导方针,以帮助他们决定在随后的关键时刻如何采取行动。
在Atlassian,我们提出了五个价值观,指导我们如何应对事件并最大程度地减少干扰。关于 “价值” 的文章很多,但它们不仅仅是挂在墙上的好东西。我们的工程师期待这些价值观来引导他们在压力下做出艰难的决定。
每个值映射到事件响应的特定组件。我在这里分享它们,希望它们对您的组织也有用。
值: Atlassian知道我们的客户之前
精心设计的服务将具有足够的监视功能,以在任何问题成为事件之前检测并标记任何问题。如果您的团队在即将发生的问题影响客户之前没有被寻呼,则需要改善监视和警报。
值: 升级,升级,升级
工程师可以决定的最糟糕的事情是,他们不想唤醒某人,因为这可能不是他们的问题。没有人会介意被事件唤醒并发现不需要它们。但他们会介意他们是否在本应该被唤醒的时候被唤醒。我们应该在同一支球队,队友互相支持。
值: 事情发生了; 快速清理
客户不在乎为什么您的服务关闭,只关心您尽快恢复服务。毫不犹豫地迅速解决事件,这样您就可以最大程度地减少影响。
如果您是技术负责人,并且知道您可以通过快速重启来恢复服务,但是您也可以在服务仍处于关闭状态时花时间调查原因,您应该怎么做?这个值指导你的答案: 现在恢复,以后再找出原因; 客户体验是第一位的。
值: 总是无可指责
事件是运行服务的一部分。我们都通过让团队负责而不是分摊责任来改善。人为错误绝不是重大事件的根本原因。为什么那个工程师能够将开发版本部署到生产中?命令行错字是如何产生如此毁灭性的影响的?
指责从来都不是适当的回应。找出缺少的保障措施,并将其落实到位。
值: 从来没有发生过两次相同的事件
确定根本原因并确定将防止整个事件类别再次发生的更改。同样的虫子能在别处咬吗?什么情况会导致程序员引入这个bug?承诺按特定日期交付特定更改。
有了这些价值观,下一步就是确保它们付诸实践。我们每月举行一次会议,讨论它们是如何实施的,并剖析不实施的场合。我们呼吁人们关注他们 -- 不关注他们。我们已经将它们添加到我们的文档中以进行事件响应。
服务中断是一件大事: AWS事件影响了前100名零售商中的54家,这只是一个行业领域。您的足迹可能要小得多,但是从比例上讲,停机对您和您的客户的影响可能同样具有破坏性。为您的工程师提供所需的帮助,以在crunchtime做出艰难的决定。他们和您的客户都会感谢您。