正文
记住， “危机”一词常常引发慌乱和瘫痪，而不是导致清楚的、理智的行为。
看到事件苗头，要及早上报，频繁上报。
你需要培养这样一种公司文化：不仅要赋予员工权力，而且也要鼓励他们在看到不好苗头的时候讲出来。
“如果你闻到烟味，你要说出来。我们让Simple团队的每个成员上报事件苗头，描述它们，而不是去分析它们。”这是克里斯塔在Simple团队形成的准则。因为Simple的业务涉及银行和个人身份信息，所以很重视隐患的排查。
例如，团队成员在例会上举手说：“我注意到了用户方面的一个问题”或者“流量似乎超过了预期，应用程序需要更长的时间来处理它”。
Slack频道界面
在Simple团队中使用了一个专门的Slack频道（
注：Slack是一款团队协作软件，类似于国内的Teambition
）来上报事件。然后技术团队就会帮助他们处理问题。通常情况下，火焰还在苗头状态就被扑灭了。
这个处理问题的模型是参考了美国林业局火灾事件处理系统。
美国林业参考系统图
美国火灾危险评级系统简单易懂，提醒是绿色，除了绿色之外，其他颜色都代表事件。如果有巡逻者或公众上报了什么事情，那么即使没有立即采取行动，也会发出提醒。
这种警告图表的好处在于它的基本分类大家都明白，但是有些地方还根据当地情况做了专门的调整。例如，林业局与南加州的一家地方机构合作开发了一种额外的颜色，以便更好地评估该地区特有的风险。同样，公司也应调整这种系统，以最好地适应公司、行业和用户群等等的风险承受能力。
频繁、及早上报隐患。否则，
本来一桶水就可以浇灭的小火苗可能最后需100名消防队员来扑灭。
感谢及时上报隐患的同事
大多数危机沟通系统都忽视了一个地方：
要像对待用户一样认真对待同事。
要培养一种支持危机沟通系统的文化，你需要向每一个报告问题的人表示感谢。即使这个警报微不足道，你也要表示感谢，这一点非常重要。
’“非常感谢你报告这件事，我想情况还不算严重，但是我们会留神它的。”团队负责人绝对不能说“你怎么会觉得这是个问题呢？”
所以这种公司文化其实就是
去救助每一个大叫“狼来了”的小男孩
，无论这个小男孩所说的”狼“在与不在。 如果你希望人们上报的事件隐患有100%的命中率，那么上报的风险就比较大了。在这种情况下，你在被火烧到之前是看不到火焰的，因为不会有人告诉你。
第一线的人看到的东西是最多的。
因此在像Simple这样的消费型科技公司，第一线上报上来的任何信息都需要珍视。如果因为一线员工受不了团队领导的官僚主义态度而不愿意向上报告任何苗头，那么在“事件”发生之前，团队领导就很难察觉得到它的。
俗话说，患难见真情。克里斯塔认为在公司里也是这样的。
在最危急的时刻，公司的价值观往往会表现得最强烈。
然而对于很多公司来说，当灾难发生时，这些无形资产都会消失无踪。为了确保那种情况不会发生在Simple，克里斯塔和她的团队使用了一件工具：
事件管理系统（IMS）系统。
Simple的IMS系统就是内部系统或Simple员工上报的任何问题，都会通过特定的Slack频道发送提醒。提醒分为两类：技术的和非技术的。
非技术性事件涉及人或关系的提醒。 这部分涉及到的可能是用户、合作伙伴或供应商，也有可能是社交问题。这部分的事件花样百出，但通常不涉及内部的代码，因此不会自动发送提醒给工程师。一般来说是经营或整合团队会收到信息，由他们决定是否需要叫上工程团队一起来解决问题。
技术事件与产品有关的提醒。 在Simple只要没有按照最佳操作方式执行，其他任何操作方式都将立即触发PagerDuty（一款线上的数字管理软件）的技术反馈，同时向工程、传讯、整合和用户关系团队发送提醒。这就少了打电话的麻烦，并且创建了一个即时响应团队，可以立刻处理事件。所以，即使是在凌晨2点发生了什么事情，所有应该出现的处理人员都会到位。
Simple开发的这个工具为团队提供了灵活性。由于这两类情况需要的处理人员不同，所以在设计系统的时候把它们分开了。对于非技术问题，你可能不需要工程师来处理。需要调试基础架构的时候，你也不用业务经营专家来帮助你。
为什么不创建一个“多合一”的系统呢？经历过许多危机事件的克里斯塔发现，如果创建一个’多合一’的系统只会导致混乱。真正可以节省时间的工具是一直在线的PagerDuty状态页面。
面对用户的自动更新状态页面
