观影《切尔诺比利》

切尔诺比利，讲的是前苏联的切尔诺贝利核电站发生爆炸，造成大量的核泄漏，数十万人被迫永久迁移，数千万人受到核辐射影响的真实故事。故事主线从瓦列里教授的视角，阐述事情发生的前前后后。

首先说，为什么会爆炸？

主要原因有二，一是人员问题，主管为了尽快完成核电站的安全测试，多次违规操作；二是故障保障程序有致命的缺陷，救命稻草反而成了引爆点。

个人认为，事故的人员问题是主要的，尤其是主管，有很多细节点可以看出，安全测试被延迟了10个小时，造成夜间换班人员并不知道有安全测试，而主管也没有清晰的告知大家；还有，换班的人员，仅靠着一份检查清单，就鲁莽的开始进行安全测试，完全没有问清楚，还有，在发生问题时，虽然多次挑战了主管，但迫于主管的威胁，并未坚持自己的原则。

第二点，故障保障程序的缺陷，我个人觉得主管是不清楚的，所以，他才敢如此大胆激进的操作，更何况，主管是一个十分自负且不负责任的人，多次有人已经警告过他，他仍固执已见，不亲自去核实问题，不仅延误了时机，还害了更多的人。

为什么要看此片？

切尔诺比利核泄漏是历史上最严重的核电事故，其每小时的核泄漏就相当于广岛原子弹的两倍，爆炸影响半径2600平方公里，且100年内不适于人类居住。

作为互联网的一名码农，很多在自己的领域牧码多年，一定或多或少遇到过大大小小的线上事故。我们会发现究其现象和原因，是非常相似的。一次线上事故的背后，往往是由于为了在 DeadLine 前完成 KPI，开始着急上线，并把隐患和风险完全押宝在降级策略和回滚方案上。

而当真的问题出现时，大脑会蒙地一下，耳鸣声格外刺耳，虽然会按照预案一步一步执行，但紧张一定会让你遗漏什么。就如同墨菲定律说的，你担心的事情，一定会发生的。

有哪些反思和收获？

据统计，线上事故50%都是由于变更引起的，出现问题一定是有什么变化了。

所以，变更前的 CodeReview、变更单、灰度策略等，都是一种保障措辞。保护了系统，也保护了变更人。我们看到切尔诺比利核电站那晚的工程师们，大多数都有由于强核辐射，在2周内都去世了，这是血的代价。所以，可以设想，一次线上事故一定会伴随着舆情、资损的出现，最终，一定是有人要担起责任和付出代价的，很多人是交不起这学费的。

总结一下，一切操作都是人来实现的，人是最大的不确定因素，但却只有人才能完成。

个人的经验，想清楚再做，稳扎稳打，Double Check，小步快跑，不硬上，有问题先回滚，多复盘，不重复栽跟头。用曾国藩的一句话总结：结硬寨，打呆帐。