墨菲定律是运维的魔咒！

什么是墨菲定律？最简单的表达形式是“有可能出错的事情，就会出错（Anything that can go wrong will go wrong）。”爱德华·墨菲(Edward A. Murphy)是一名工程师，这句话迅速流传。墨菲定律的原句是这样的：If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it.（如果有两种选择，其中一种将导致灾难，则必定有人会作出这种选择。）

墨菲定律的来源，是一个叫墨菲的工程师，他有一个经常会遇到倒霉事的同事。1949年的一天，墨菲开玩笑说：“如果一件事情有可能被弄糟，让他去做就一定会弄糟。”举个例子吧，比如你每天出门都带着雨伞，可总也不下雨。当你这一天不想再带伞出门时，则往往会赶上下雨。再比如你去排队买东西，窗口前有几条相同长度的队伍。这时，你所加入的队伍往往是最慢的。

好吧，我承认我被墨菲定律照顾过几次，下面来一一聊聊。以此为戒，希望大家引起重视，特别是做技术的同学。

第一个案例。在之前腾讯数据运维组，记得当时农场业务某个数据使用了125台内存机器，每台机器两个类似memcache实例。由于内存不是持久化的（访问量太大无法落磁盘），担心内存数据丢失，我们使用了多种备份方案。1）定时冷备的方案，一天备份两次，把内存dump到本地，本地磁盘保留一份，统一的数据中心保留一份。2）实时通过更新server合并持久化到mysql中。3）由于以上两种方案都会有时间窗问题，再次使用timemachine的机制，进一步合并最小时间窗的数据到本地文件中。当时我们都在想，这么完备的方案应该肯定没有问题了，结果这个时候墨菲定律生效了。接下来一台机器的故障是本地的磁盘IO总线错误，导致所有的冷备和binlog都无法产生；机器内存数据无法dump出来，最终只能拿多天以前的冷备恢复，造成用户的数据丢失，给业务也造成了不好的影响。这个地方大家自己发散想想解决方案，就假设你维护的内存是memcache，你会怎么做？

第二个案例。不具体化了，大家都有一个经验，认为自己写一些脚本做一些运维工作很爽，其实这恰恰问题的开始，一定有rm删除一个重要文件或者目录的经历，甚至删除一个操作系统根目录的情况都有。

第三个案例。刚刚发生的一个事情，我们硬件环境是：刀片+统一存储。软件是vmware虚拟化，结果还是出现虚拟机文件失效，导致文件不明所以的丢失。原因依然在定位中。

其实这些故障都在我身边以小概率发生，在没发生之前，思想上会非常懈怠，很容易忽略在系统存在的单点或者盲点。如何彻底的避免这类的情况，还是有些方法可循的。

第一、拒绝“我以为”对故障的解释。当故障发生之后，要严格避免这类的说辞，当你这么说的时候，其实就意味着下一次还会“我以为”。“我以为”是一个非常主观的认定，而非基于特定方法论的验证。

第二、不要惧怕问题的发生。从我们的自身的能力来说，我们一定会有一些认识盲区，这些盲区导致的故障恰恰是个改进自身工作的好机会。但最快的恢复故障使我们的目标，其实从业务架构来说，我们一定是有技术手段来减少故障对用户的影响，特别是对于一个不复杂的系统来说。

第三、突发事件预案和周期性的演练计划。在ITIL中叫业务连续性计划。结合系统架构，根据业务的访问流来梳理系统中的单点存在，这个工作非常庞大，对于一个大型分布式系统来说，几乎就无法靠人来完成。在梳理的过程中，我们需要对业务系统进行分级，最好是到服务级别。根据不同的级别，提出不同的恢复时间要求，从而确定相应的备份计划，容灾计划，容错计划，恢复手段等等。为了检验我们的方案的完整性，我们需要提出周期性的演练计划，这个演练需要根据我们之前的设计目标来实施，比如方案说，某个数据库故障、某个机房故障，这个时候，我们直接模拟真实的故障的来进行演练来检验方案。

第四、监控、监控、再监控。当故障发生的时候，我们一定要有监控手段帮助我们比客户先知道故障点，有预警的情况下一定要通过预警来提醒我们。此时需要一个端到端的业务监控方案，从而能够在客户产生影响之前消除故障。端到端的业务监控，这个地方大家可以参考业界的一些标准做法，比如说google和twitter，他们都提供相应的开源实现，google的非常彻底，已经到了cpu指令级。

第五、技术架构是第一解决方案。能技术解决的一定要技术解决，不要交给流程。真要引入流程，还是有些原则可以遵守的：它一定是公共的，易于执行；一定是团队迫切需要的，否则流程可能也给我们带来新的麻烦。另外分布式系统有些设计原则可以遵守，比如说有损服务，柔性可用，动态运营，立体化监控等等。

希望大家以我为戒！也欢迎我们在一些高可用运维经验上进行深入探讨！