这一周我听到的最揪心的就是东北大学6位同学在参观工厂的意外悲剧，作为东北大学的毕业生，母校以这样的方式登上热搜。而今天看了新闻推送的时间线，10点20分事故发生，12点01第一位遇难者被打捞上来，接近2个小时。
几乎可以肯定的是，过去的应急演练都没做或者是糊弄过去的，但凡认真做了，都不会出现这种情况。
应急演练的意义
以前在外企的时候，每个季度都有应急演练，小到某个系统，大到整个数据中心网络都切断。当时北京的灾备中心在亦庄，我早上6点从北边出发，8点到达，9点网络团队准时切断数据中心的网络，从基础设施到应用系统的同事都要在指定时间内，将服务切换到上海的灾备中心，确保能够继续提供服务。而每年的应急演练，都不能顺畅，总有一些我们遇不到的问题阻碍，按照监管要求的15分钟内切换基本做不到。演练结束之后，大家后面复盘会议要开好几天，几十甚至上百项整改要求，要在一个季度内逐项落实，下个季度演练，global团队要验收。即便如此，下个季度还会出现很多新问题或者老问题复现。
久而久之，我就会怀疑，这事情做的有价值吗？
直到有一次早上7点多，交易系统的同事跟我说，Oracle数据库连不上了，我8点多赶到公司一看，linux服务器故障，即便是服务商当天送来备件，也赶不上9点的交易。没办法，切灾备吧。
过往演练的经验终于派上用场了，不到10分钟完成备库的切换和健康检查，应用系统同事用了接近的时间完成服务启动，赶在9点之前完成这一切。而且过往哪些点可能有问题，大家也心里清楚，切换过程遇到一些小问题都能克服。如果没有演练，我可能根本不知道印度人配的global TNS服务要改，仅仅这一项足以让我这次切换失败。
那一天最终交易顺利完成，也让我后背发凉了一天。
应急演练的内容
应急演练到底练什么？就两样，系统和人。系统层面，我们的生产环境和灾备环境，永远不可能做到1：1的复制还原，一定存在各种各样的差异和潜在风险。生产环境每天使用，大家的熟悉程度比较高，但是无论是从稳定性还是从系统资源配置的角度，灾备想要做到和生产一样，都需要投入更多成本。出于这一点考虑，大家都对灾备系统的要求不会那么严格。各种问题和潜在风险能不能在万不得已的时候支撑起业务，都是需要测试验证的。演练的时候，发现问题才是对系统层面最重要的内容。如果演练完成没有发现任何系统问题，那很可能演练自己就有问题。
人的维度，人对系统的熟悉程度和对切换灾备的熟练程度，都是需要真实操作才能学会的。比如我汽车里的备胎该怎么换，我是不知道的，因我没换过。演练过程中，各个团队的磨合怎么样，抗压能力怎么样，处理问题的速度和思路是不是正确，都需要演练过程来验证。这一点是公平的，没做过就是没做过，拍脑子想的和实际做的永远相去甚远。甚至某个人适不适合这个岗位，都是通过演练发现的，比如之前我们一个同事，日常工作看不出波澜，但是每次演练手是真的麻利，脑子也清醒，后来整个中国区演练都让他负责了。
更需要注意的是，不仅仅系统需要冗余，有时候人也需要。比如我们就演练过，北京办公室集体断网，上海的同事能不能支撑起系统的运维。这些都是没有捷径可以走的，只能一部一脚印。
之所以写这篇，不仅仅是因为本周的悲剧，还有就是我们有相当多的企业重冗余建设，轻事故演练，设备和人在关键时刻发挥不出作用。但是事故演练，真的是很多运维人员重要的保命符。
