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