看到这样的标题，圈内伙伴一定想到了不久前的一次事件，3月29日，某知名电商企业的线上商城出现无法登陆或者无法下单等情况，当天，该电商企业便做了官方回应，确实是系统崩了：因系统短时故障，主站“加购”等功能或出现异常。

在两个月后的6月5日，该电商企业发布的一则“关于机房宕机故障处理的公告”，引发业内人士的广泛关注。根据该企业发布的公告显示，线上商城停止服务的原因是温度快速升高造成的机房宕机，机房宕机是因冷冻系统故障导致。

据公告内容，系统宕机持续12个小时，导致该公司业绩损失超亿元，影响客户达800多万，公司将此次故障判定为P0级故障。此次事故暴露出容灾应急预案和风险防范措施不到位，公司决定对此次事件严肃处理。对基础平台部负责人做了免职处理。

出了这样的事件，面对这样的结局，难免会引发我们进行很多思考，首先就是出现这样严重的问题，是否有相应的问责机制，到底应当谁来承担责任？其次对于第三方机房出现的故障，最终基础平台部负责人被免职，处理是否合理？另外在企业开展业务的过程中，应当采取哪些方式才能避免宕机，保证业务的持续性？带着这些疑问，小编特别组织并发起群讨论，向在数字化一线摸爬滚打的广大群友寻求答案。问题一经发出，群内成员积极响应，各位群友观点不一，各持己见。

一部分群友认为这样的处理方式还是有些过重了，原因在于机房并不是由自己企业内的IT维护的，而是第三方机房，责任更多在于第三方，因此很可能是这位负责人“背锅”了。另外出于成本考虑，很多企业并没有做到事前的容灾预案，与风险防范，造成了“没出事之前公司不舍得花钱，出了事就找人背锅”的局面。“如果公司业务连续性组织有了明确的策略和要求，每年的灾备演练是否执行，正常情况下责任不会到IT”，群友们这样谈论到。

当然也有一些群友认为这样的处理合情合理，并不算重。“对于该企业来说，还是因为基础平台负责人带领的部门所做的负载和灾难恢复机制不太完善，导致出现问题后系统的恢复时间过长，超过阈值了，才造成了如此大额的损失，因此相关的负责人被免职也是无可厚非的。”也有人认为：“这种级别的电商平台竟然宕机十二小时！绝对属最高级别严重事故，直接负责人必须问责！”，还有朋友说：“有提前警示宕机风险就不应该开除，但是即使有提前提过警示但宕机出现后竟然持续十二个小时中断业务，足以说明他们业务连续性灾备应对方案没做到位！”

从企业管理层面来讲，出现问题一定是需要有人承担责任的，这并不是什么新鲜事。而这次事件也让我们看到了数字化其中隐藏的潜在风险，所以不论是互联网电商企业还是专注于生产制造的传统企业，系统宕机所带来的损失一般情况下都是巨大的。相关数据显示，有96%的企业曾在过去三年中至少经历过一次系统中断，对于小型企业来说，宕机一小时平均造成25000美元的损失，而对于大型企业来说，平均成本可能高达540000美元……

然而现实情况是宕机事故是不可预测的，所以被称之为系统中的“黑天鹅”，当前各类信息系统架构日趋复杂，其风险也随之升高，因此从故障中寻求分类，并有针对性的进行防御，或许能够有效避免一些潜在的损失。例如现在的容灾架构就是一种灾难防御手段，它主要针对的是机房级的故障场景。

在相关的文章中，有这样的表述，从IDC的维度上看，主要有机房入口网络故障、机房间网络故障以及机房掉电。如果精细化到应用层，又可以分为接入网关故障、业务应用故障以及数据库故障等，背后的故障原因可能是软件BUG或者部分硬件故障，比如机柜掉电、接入交换机故障等等。容灾架构的目标是，在单机房出现任何故障的情况下，能够快速恢复业务，保障RTO和RPO。

针对不同种类的故障，灾备行业有三种不同等级的防御方式：数据级、应用级、业务级。现在业内主流的容灾架构还是灾备容灾，属于数据级的容灾方案。由于灾备中心平时不工作，应用服务的完整性和运行状态未知，在发生故障的关键时刻也会面临敢不敢切的问题。有些企业会因为无法确定能否承载流量而不敢切，有些决定切换的企业也可能因为备用机房的应用状态不对而不能完全恢复业务，最终造成的影响就是RTO或者RPO较长，反应给外界就是大型“宕机”事件。

如何避免出现大型的“宕机”事件，出现问题后又该如何快速处理，小编也搜罗了一些业界较为普遍的做法，供大家参考。

1、降低事件和告警数量

识别和确定重要故障尤为重要，且大量的告警信息也是不合适的。所以要持续地降低事件和告警数量，但随着IT系统的不断升级变更，配套的监控就会调整，此时告警数量又会增加，所以要进行持续的调整。

2、强化变更管理

80%的故障都是变更引起。ITIL4将变更支持实践中定义的最大化成功服务和产品的变更主要表现在以下三个方面：确保已正确评估风险、授权进行变更、管理变更时间表。促成变更的五个主要活动是：记录、计划、批准、执行、回顾。

3、降低故障响应时间

如果系统发生故障，最好是能够第一时间发现，如果没有成熟的管理体系，故障的发现时间会延迟很久，所以企业建立快速响应机制是非常有必要的。

4、降低故障恢复时间

首先需要收集有效数据，对事件进行收集和分析，最合理的方式就是事件和处理时间的平衡。中间数的处理时间应该是20-30分钟，当然最理想的状态是事件和恢复时间同步日趋减少。

5、升级问题管理

问题管理强调的是找出事件产生的根源，从而制定恰当的解决方案或防止其再次发生。问题管理需要根据事件、容量、配置、服务级别管理等流程提供的信息制定解决方案和应急措施。

6、升级策略

当事件发生后，如果在规定时间内没有处理，事件就可能会无限期的拖延或者是遗漏，如果建立有效的升级策略和高效的管理组织，就能够避免类似问题发生。

7、巡检体系建设

保证信息系统的安全稳定运行，自动化巡检的应用提升了信息系统运行的可靠性，通过对机房基础环境设备、网络设备、主机、数据库及中间件系统等实现巡检，自动收集各种巡检项指标，能够及时发现系统缺陷和故障，这对于大型复杂信息系统的运维工作模式具有重要意义。

8、灾备演练管理

无论数据级还是应用级，都只是灾备建设的技术手段。要想灾备系统在关键时刻能发挥应有的作用，完善的灾备应急预案、定期的灾备演练、自动化的灾备切换和恢复能力不可缺少。

目前来说，针对系统宕机似乎还无法做到完全杜绝，只能是采取一定措施来进行事前的预警与发生时的快速处置。从IT的角度来说，如今各行各业正加速推进自身业务和管理模式的数字化转型，在提升客户体验，为运营提质增效的同时，为企业的IT运维带来了更大的挑战。数字化转型推动新技术、新场景的快速迭代，运维面临的复杂度、不确定性因素加大，企业业务连续性面临着更大挑战和不确定性。

当然业务连续性管理如今也已经成为了IT最基本的工作之一，而且这是一个持续不断提升的过程，围绕”快速发现事件→快速响应事件→快速定位与处理事件→减少事件发生”的事件生命周期闭环，结合一体化运维平台，或许是一种不错的思路。如果能够有效利用数据指标，以数据驱动，并进行持续的改进和优化，就可以有效缩短故障恢复时间，并进行有序的事件处理。

那么，你是否经历过服务器宕机呢？又是如何解决的呢？欢迎在下方留言区与我们讨论交流！