若是你还没有履历过不能回退系统的痛苦，那么若是继续玩火，不停地迅速修复系统，迟早会遇到这种问题。不要用应用太庞大或者代码公布太频仍作为捏词，拒不加入回退代码的功效。一个明智的飞行员，若是没有具备让飞机着陆的能力，就不会让飞机腾飞。一个明智的程序员，若是不能让系统在紧要情况下回退代码，就不应该公布代码。
为了给接下来要讲的原则制造气氛，我们应该在深夜围坐在一堆篝火周围讲恐怖故事。我们要讲的是经典的恐怖故事，就是人们在屋子里听到了恐怖的声音但并不逃跑的事。那些忽视所有忠告信号的傻瓜就是我们。作为程序员的上司和CTO，我们收到过几平每个司理架构师和程序员的汇报:应用太庞大了，不能举行回退。我们自己对此也确信无疑。代码公布后曾经泛起过几回中止或问题，先是疯狂地迅速修复，之后在同一天中获得一个热修复补丁，以便完全恢复服务。我们忍受了这种小小的未便，由于我们以为这个应用太庞大了，不能举行回退。
和之前公布的所有版本一样，一个主要的基础设施的版本公布后，也不能举行回退。这次公布简直是场灾难。破晓时，一切看起来都很好但当天亮了以后，流量激增，这个站点就招架不住了。若是回退，只会让几个用户不高兴，给自己留点儿小伤痕，但不会有更糟的事情了。但我们却不能回退，以是只好破费一整天的时间，为这个站点做点儿增添容量、限制流量等事情，以便在获得修复补丁之前保持一切仍然运行。那天晚上我们推出了一个补丁，那时站点并没有流量，以是我们以为问题已经修复了。第二天早晨，当流量增添后，这个站点又最先有问题了。只好又在晚上打补丁…这种模式连续了一周多。
接连折腾了这么多天，到那周结束时，所有人都已精疲力竭。最后，我们打了一个补丁，完全忽略之前的所有修改，终于使站点稳固了。虽然从这次事故(包罗指挥失误)中可以学到许多器械，但与本条原则关系最慎密的是，无论我们照样客户所履历的所有痛苦都是可以通过回退代码制止的。
事后总结经验教训，我们确定日后不允许再公布没有回退功效的版本。那时除了发出这个布告外，我们别无选择，客户无法容忍这种性子的问题，每个程序员也都理解了这种要求的必要性。六周后，当下一个版本准备好时，我们已经能够举行回退了。我们曾经都以为难以克服的难题变得相当简朴了。
(责任编辑：网络)
评论列表