小编导读：世界上没有不存在缺陷的软件，互联网产品也都会遇到运营中断，那么遇到运营中断应该如何处理呢？
没人喜欢谈论运营中断问题，如果你是一名公司员工，经历过这种体验一定会感到非常可怕。企业一旦遭遇运营中断，首先受到重创的就是顾客信任，其次也对企业未来的收入产生巨大影响。但是，它的确会发生。
即便是很多已经上市的科技巨头，比如eBay和微软，他们所拥有的资源可能比任何一家初创公司都要多，但是可悲的是，这些大企业也都深受过运营中断之害。当这个悲剧发生之后，企业的所有业务都无法开展了，他们的股东和高管团队也会因此非常懊恼，后悔没有及时做好准备。事实上，根据全球权威调研机构Aberdeen Group估计，企业由于故障导致停摆的平均成本已经高达每小时16.1万美元。
l 臭名昭彰的“乌龙指”(人为错误)
l 对于复杂系统和他们之间相关性了解不足
l 设备故障，包括设备过期，或者是设备没有得到正确配置
l 被黑客攻击，或是存在其他安全漏洞。
l 流程设备不够完善，或是存在流程缺失
l 也可能是上述数个原因综合在一起。
l 不可挽回地损失收入，比如在今年六月，Facebook被爆出现了半个小时的运营中断，估计公司损失达到了50万美元。
l 生产力严重损失，比如最近Office 365出现了故障，导致他们的客户陷入困境之中，无法使用电子邮件服务。
l 客户会感到愤怒，比如最近eBay断断续续出现了很多服务问题，这让依靠eBay服务的很多小企业感到非常恼火。
l 导致企业彻底失败，比如Codespaces公司之前受到了黑客的DDOS攻击，给整个公司带来了毁灭性的严重后果。这个黑客的目的是企图敲诈勒索该公司，他们获得了Codespaces公司亚马逊EC2控制面板的访问权，然后删除了公司客户数据，悲剧的是，这些数据都无法恢复了。
对于运营中断是否会发生在你的公司，貌似已经不是个问题了(因为肯定会发生)，现在的问题是，它神秘时候会发生。企业想要在竞争中生存下来，那么就要更好地去应对、处理运营中断问题，同时，还要从其他公司犯过的错误中吸取教训。没有人是完美的，而且即便有一次你把问题处理的很完美，也无法保证你每次都能如此。但是我们希望通过讨论这些过来人所犯过的错误，并从现在努力做起，帮助你避免在未来重蹈覆辙。
下面这段，听上去是不是觉得耳熟?
运营中断发生了。客户支持团队不得不向技术运营团队发送大量电子邮件，及时报告故障情况，因为情况已经十万火急了。公司的高管们会要求下属每个五分钟就汇报问题处理进展。技术团队里的每个人都打开自己的监测工具，时刻关注数据何时可以疏通，但通常他们也只能看到问题的一部分而已。更大的混乱也会随之而来，团队之间开始互相指责对方，推卸责任，此时系统管理员更无法确定究竟是否要按照老板的要求，通过更新去解决问题，还是继续处理问题，或是进行一个可行的修补。市场营销部门和法律部门这会儿也跳了进来，他们也要对外做出回应。营销部门会说，“我们的社交媒体正在被垃圾充斥!我们需要给用户发送电子邮件，或是在官方博客上发帖，告诉大家到底出了什么事情!”;法律部门会说，“不要承认责任!”牛头不对马嘴，整个世界都要爆炸了!
好吧，世界当然不可能爆炸。但是如果上述中的前半部分让你感到非常熟悉，那么你的公司正在犯错误，也就是，没有一个经过检验且靠得住的运营中断响应计划。
那么，如何可以避免这个问题呢?
在处理运营中断问题时，一个“格式正确的”流程是必须要确定的，谁来负责解决问题，谁来负责升级系统，以及谁来负责针对问题进行交流沟通;这些都需要落实到人。另外还要有事后剖析流程，分析究竟是什么原因导致出现的运营中断故障，并且解决各种漏洞。事后剖析的范围可以放得宽泛一些，从建筑物冗余，到各个相关系统，此外你还可以改变监测工具设置，这样就能及时捕捉到问题原因，并及时解决，而且还能避免日后再次发生同样的运营中断故障。
一旦运营中断发生，你肯定会迫不及待地希望自己公司能够重新回到正轨，但是就在这最紧张的时候，反而最容易忙中出错。不幸的是，如果你没有及时和客户进行沟通，那么往往还会引发一系列负面结果，比如客户投诉电话将如潮水般涌入，等待时间会因为故障而变得更长，客户体验也会变得一塌糊涂，更可怕的是，运营中断很可能给用户造成一种恶劣印象，他们会觉得你的公司反应非常迟钝，而且不值得信赖，靠不住。
故障往往还会让公司内部面向客户的团队和你的技术运营团队之间的沟通出现问题，要么沟通不到位，要么沟通完全不畅。如果你没有一些可以发布公告，通知客户的系统，比如博客、论坛、批量电子邮件、RSS订阅，等等，那么将会造成很严重的问题。还有，公司之所以在发生运营中断时不愿意与客户沟通，其实还有一个错误的观念，他们认为客户可能不会注意到发生问题了，实际上，客户肯定会注意到;另外他们还会觉得损失将会降到最低，但正是由于缺乏沟通，从而让情况变得越来越糟糕。
如何避免：
无论是内部沟通，还是外部沟通，在运营中断发生的过程中，或是在故障发生之后，你都要确保有一个明确的沟通流程，而且每个人都要清楚地分配好相应的职责。要确保每一个人明白自己所担负的责任。不要简单地把自己的工作职责挂在公司的网站上面，因为当运营中断故障真的发生时，这么做一点作用都起不到。
3、逃避责任，玩儿“指责游戏”
为了对运用中断故障有所回应，企业有时会把责任归咎于合作伙伴或是供应商。但这么做很少能取得什么好的效果，因为客户会把这种做法看成是你在逃避责任(谁选的供应商和合作后瓣?还不就是你嘛)。如果你不愿意去承担责任，那么公司就无法从中吸取教训，既无法避免同样的问题再次发生，也不会让公众感到满意。
如何避免：
你需要承担更多的责任，并且要开始调查与故障有关的供应商，设置好冗余和审核过程，这些都有助于解决问题，解决问题的方法越多，就越不会出现推卸责任的状况。要确保事后监督是无可责备的，并使用“五个为什么分析法”来找到运营中断故障的根本原因。(“五个为什么分析法”，是一种提出问题的方法，用于探究造成特定问题的因果关系，类似于“碰到问题，多问几个为什么”)
最糟糕的事情，是你从自己的客户嘴里听到发生运营中断故障了(或者还有一种可能，就是从你的老板那里知道发生故障)。在数据中心的监控基础架构同样也需要被监控，这是一个不错的方法，因为有时候发生运营中断故障时，你根本无法得到提醒，其中一个原因就是你的监控系统并没有及时运转起来。即便是像亚马逊这样的大公司也曾遇到过这种情况，几年前他们曾经发生过外部运营中断故障，好在他们用了Loggly云监测软件开发平台才解决了相关问题。
最好的方法：你需要有一个基于“软件即服务”的统一平台，并且它能够给你发出报警，提醒你是否数据中心出现故障了。你的监控平台也需要覆盖到方方面面(包括对各种综合交易的复核检查)，比如网站，应用程序，数据库，网络，服务器，虚拟机，以及云服务(无论你的IT基础架构部署在什么地方)。这样你就能领先一步，至少可以在客户发现问题之前主动发现问题，并搞定它。
Dreamhost公司曾经在他们计费系统的客户体验上出现了一些问题，该公司自以为是，用了一种幽默的口气做了解释，想以此回应问题。但是他们这种做法引起了部分客户的强烈不满，他们觉得Dreamhost公司用“吉普森一家”动画片做回复，完全是不把他们当回事儿，他们应该做出正式道歉，并做出合情合理的解释。于是，这些客户在网上和社交媒体上疯狂攻击Dreamhost公司。
如何避免：
如果运营中断故障影响到了你的客户，让他们无法正常办理业务，请务必要认真对待。如果你的客户是一家公司，并选择你作为供应商，那么如果你出现了运营中断且没有合理的解释，那么肯定会对你的服务有所怀疑。
6、没有处理好上述五个要素中的任何一个，就无法实现有效的运营中断沟通/致歉
“我很抱歉会发生运营中断故障，但是我真的帮不了你。的确，我知道我们没有给您提供任何有用的信息，向您解释为什么会发生故障，以及为了解决这个故障我们做了些什么。我们的解决方案也没有给您提供一个故障恢复时间，对于我们是否会计划防止此类故障再次发生，我们也暂时无可奉告。而此次运营中断故障给客户的赔偿应该也不会如您所愿，但是给客户所造成的不便，我感到最深、最衷心的抱歉。我知道您需要依赖我们，作为客户，我们也非常重视你们，我们真的非常重视这次运营中断故障。”
永远不要说上面这段话。这种错误说明了在你的客户支持团队以及技术运营团队之间没有做好沟通，至少这个沟通不够直接和开放，或是你的道歉申明没有经过法律和财务部门的审核。
如何避免：
如果你要给外界一个正式的道歉申明，那么前面介绍的五个要素(就是上面的五个黑体字标题)是非常重要的。如果你无法给客户一个有效的致歉申明，那么最后付出的代价是巨大的，除了收入遭受重创，而且也会导致客户大量流失。
7、灾难恢复，最后自身变成了一个“灾难”
事实上，企业在构建灾难恢复解决方案的时候，也一样会犯很多错误。首要问题，其实也是最常见的一个问题就是，很多企业没有把灾难恢复(DR)放在首要位置。其次就是，企业在构建灾难恢复解决方案的时候，没有把二级系统的负载考虑进去，因为二级系统故障一样会发生，而且也会对主系统造成影响。绝大多数计算机负载并不是成线性比例的，如果有两个站点，每个都是在一个40%负载的数据库上运营，这并不意味着的一个网站可以在80%的负载上处理工作，很可能负载率会达到120%，也就是说，企业在进行灾难恢复时，如果有一个网站失败了，可能会导致两个网站都无法运营。
如何避免：
在你的系统上面，要进行容量测试，这样你才能知道网站的动态余量，以及在负载状况下网站的运营表现。还有一个方法，就是灾难恢复网站不需要把所有功能都激活，而是把它看作是一个生产网站的理想替代品。这么做可以避免在灾难恢复时出现配置错误，除非你真的想再犯下一个错误……
8、不经过实践练习，就期待完美
Chelsey “Sully” Sullenberger是一位传奇机长，他曾经将一架美国航空的A320客机成功地降落在哈德森河上，挽救了几百人的生命。但是在此壮举之前，他已经有超过2万小时的安全飞行时间，而且完成了无数次模拟紧急状况的练习。在每次危机发生的时候，他都能提前知道该做什么。但是，许多公司却无法做到这一点，他们的应急计划测试不通过，或是测试结果无法满足专业性要求。最后到问题出现的时候，他们根本就没有做好准备。
如何避免：
要形成一个业务连续性计划，还要经过大量测试。在测试的过程中，你会发现什么地方有问题，然后及时解决，毕竟这要比实际发生运营中断故障要好的多。
9、责任分散
有研究显示，当人们面对很大一群人的时候，他们很少会在紧急情况发生时采取行动，或者，他们在这种情况下很少会觉得自己也需要负一定责任。责任分散往往被用于解释这一现象，而且在困境中的个体很少可能得到援助，特别是当有一大群人在现场的时候。本质上来说，群体中的个体们会等待一个集体决策，如果其他人没有做决策，“我”也不会。
在发生运营中断故障时，企业往往在责任分散上存在问题。他们没有把解决问题的责任明确地分配到个人头上，团队之间还会相互指责，最后谁都不会对问题负责。如果你有太多监控解决方案，或是升级路径不清晰，就会发生类似的状况。
如何避免：
在制定运营中断响应计划的时候，就要把每个人的职责分配清楚，还要包括各种系统升级的时间进度。公司内部所有团队必须使用同一个故障监测平台(比如LoGICMonitor)，这样做的目的，就是当问题发生时可以根据问题的类型，定位到正确的人头上。公司需要有一个问题解决的升级链，如果某个人在预定的时间内无法得到解决某个问题，就需要把这个问题自动转移到下一个人头上。
10.变成了一个“处理急事的奴隶”
“我们越来越感到进退两难，其实并不是缺少时间，而是在优先级安排上存在问题。”
– Charles E. Hummel, 《Tyranny of the Urgent》(Charles E. Hummel的《缓急之辨》、这本讲时间管理的小书，原书名Tyranny of the Urgent，有人译为「急事的奴隶」，也有译为「燃眉的暴政」，是帮助忙碌异常的现代人，在许多紧急事情中分辨先后的实用手册)
笔者在写这篇文章的时候，联系和很多快速发展的“软件即服务”公司CEO。其中一个人告诉我的话，让我感到十分惊讶。他说，“我对题目非常感兴趣，但是我恐怕没有时间和你一起，针对运营中断故障问题展开讨论了。”我问道，“为什么?”他回答，“嗯…..我们现在正在发生运营中断故障。”
他做了一个错误的回答。
你很容易就会变成一个“处理急事的奴隶”，把所有时间都用在救火上面。
但通常来说，这都是因为优先级安排的管理不当造成的，有些事情很重要的，但是还没有到紧急的程度，如果经常处理应急事件也会消耗企业大量资源。实际上，你完全可以做些预防工作，做些准备和具有前瞻性的工作是明智的。
