简单来说，起因是一个server有改动，需要部署到N台机器上。
改动后的server会读取一个之前已经存在，但是没有用到的配置文件。
配置文件里面有一项，应该是本机的IP。
由于某种原因（就是低级失误的根源）， 部分机器上的IP配置是相同的，都设成了其中的一台。
导致的结果就是那台不幸的机器由于负载过重，请求处理不过来。
而且由于这是一个比较关键的server，于是乎，系统的可用性被波及了。

但凡涉及到可用性（或者稳定性、用户体验之类用户可以感知的问题），总是比较容易引起关注的。
虽然不是事故的直接责任人，不过整个过程中暴露出来的问题，还是值得思考和总结一下。
追究责任或许有警示的作用，但正如代码都会有bug，人也总有犯错的时候。
如何在流程和制度上避免同样问题的再次出现，更值得去分析和研究吧。

有两个为什么需要解答：
1 为什么定位问题消耗了过长的时间？
2 为什么会部署了错误的配置文件？

对于第一个问题，有工具的原因、有个人的原因。
主要是因为出现状况的早期没有深入分析， 错过了尽早查出根源的机会，导致耗时较多。
对于这类问题，感觉唯一解是强化个人的责任心 。

而第二个问题，则是想讨论的重点。
虽然强调流程和制度，可能会被人诟病过于僵化。
但对于一个希望长期运营的产品来说，流程就像一个人的起居饮食一样，
虽然每天的重复会非常沉闷，但只要一天没有，就可能引起各种各样的缭乱。
其实流程对程序员来说也并不是完全的无聊和乏味，它可以搞定所有重复性的体力劳动，
省出来的时间，足够写不少有意思的程序了。而这还没考虑到由此避免的潜在的差错时间。

据个人感觉，流程上的问题有两个：
1 配置文件设置本机IP不是由部署脚本完成的，就算有部署脚本，也是人工写好再执行，并不是由部署系统根据占位符生成
2 上线后，开发人员会监控程序的运行，但通常不会检查每台机器上的配置文件是否正确，尤其是在机器很多的情况下

所以我的建议无非也是两个：
1 对于那些和机器有绑定关系的配置文件，由开发人员在运维平台上录入配置模板，部署时由脚本自动生成合适的配置文件。 如果再能够通过cron脚本，定期检查配置文件的合法性，则更加完美
2 开发人员在上线后，除了监控程序的运行状态，还要检查配置文件是否符合预期

其实只要第一条做到了，第二条就有蛇足之嫌。但又有谁能保证部署脚本没有bug呢？

您可能也喜欢：
Second Screenshot	Another Hello World is running on my iPhone!	浏览器战争	利用ssh tunnel建立本地sock代理
无觅

火箭发射是一件相当隆重的大事，
需要经过长时间的准备，花费不计其数的人力物力后，
在一个精心选择的时间，所有相关人物齐聚一堂，等待火箭的轰然升空。

最大的问题是，火箭发射可能失败，在付出巨大的努力后，依然失败。

个中的情形与后果，与软件开发中的一次性重构非常相似。

一次性重构是软件开发中一种相当具有冒险精神的活动，
需要实施者有“不成功便成人”的坚毅决心，埋头苦干若干日子，
最后在合十祈祷中，迎来一个充满不确定因素的发布。
用Bison的话来说，是找死。

找死也有两种找法，
一种是终止老版本，不接新需求，专心闭门造车，重写一个新版本；
还有一种是同时维护两个版本，老版本做新需求，等新版本做出来之后，再把新功能合并过去。
前一种伴随着巨大的风险，而后一种则会带来太多额外的复杂性，都不是一个理性程序员的选择。

更好的方式是采用平滑重构，这才是真正意义上的重构。
只要不是病入膏肓，这是最佳选择。

由此想到一个不太恰当的比喻：将编写程序比喻为治理国家。

假如现在的执政党已经日益腐朽，人浮于事，贪污横行。
总之，是到了需要改革（重构）的时候了。
此时有两个选择：革命，或者重新大选。
先不论大选的利弊，单看革命。
另一股势力，利用民众的不满，积极宣称自己的主义可以拯救这个岌岌可危的国家；
由于拥戴者渐多，力量日益强大，终于到了可以和执政者分庭抗礼的程度。
执政者当然不会轻易交出自己手中的权力，
于是经过非常暴力或者不太暴力（没有非暴力这个选择）的斗争，
新势力终于推翻了旧势力，春风得意的上台了。
一时间，气象一新，处处欣欣向荣的美好景象。
经过若干年后，执政党开始日益腐朽，人浮于事，贪污横行。
又一个轮回开始了⋯⋯

这种情形，历史上还少见吗？
软件终究会腐朽的，就像政党一样。
与其暴风骤雨，我宁可润物无声。