海恩法则

德国人帕布斯·海恩提出一个在航空界关于飞行安全的法则: 每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患，这个法则即是著名的海恩法则。猜想在飞行安全领域，海恩也是通过统计学的方法发现的这一法则，不然为什么是1：29:300:1000 这样的比例呢？

和海因里希法则一样，在其他领域的安全生产仍然有借鉴意义。我们来看2个案例，得以管窥一二。

东方网2016-11-25 09:15报道，截止11月24日早7时左右，江西省丰城市国电丰城电厂三期在建项目冷却塔施工平桥吊倒塌，事故死亡人数已上升至67人。记者还发现，该公司近年曾发生多起工人死伤的安全事故。那么，试问一家频发安全事故的公司为何还在正常经营，每次事故发生后又做了哪些改进措施？

大众日报于2012年曾报道过岱山县一个蓄水18万立方米的水库突然溃坝,洪水瞬间冲毁村庄。当地已确认遇难10人,27人受伤。多名村民接受多家媒体采访时反映,早在50天前,水库已经出现裂缝漏水,村民向当地政府反映了不止一次,但一直没人来修。有村民告诉记者,就在事发前一天,还有人去镇政府反映情况。在8月7日,岱山县三防指挥部在台风“海葵”到来前还曾信誓旦旦地称,岱山县水利部门已对全县水库、山塘、海塘等水利设施进行了全面检查,确保“危险水库空库运行”,“24小时值班,加密巡查频率,对水库安全运行情况进行密切监测,确保不因水利设施因素造成人员伤亡”。

别再用事故去验证海恩法则了，没有切实的措施或者防患于未然，或者对隐患的采取行动，发什么誓都没有用。“海恩法则”核心理论有二:一是事故的发生是量的积累的结果；二是再好的技术,再完美的规章,在实际操作层面,也无法取代人自身的素质和责任心。

回到软件行业，海恩法则和海因里希法则有非常好的指导意义。我们稍微回溯一下自己手头发生的，看到的，见到的系统故障，无不是因为所谓的简单、低级问题到导致大故障。

代码拷贝之祸

小明看到张三的代码刚好是实现了他想要的功能，于是就拷贝过来使用了。不曾想，上线之后，消息被张三负责的系统服务器接收去了，因此拷贝代码未正确修改事件标识。同时，笔者也见过另外一个拷贝代码的案例，导致金额错误的膨胀到100倍，因为拷贝者把多个processor的顺序搞反了，而让代码实际运行超出预期。拷贝无小事，必须让代码成为自己身体的一部分，足够了解。这2个案例都有很多种方法去发现问题而不至于让故障流入线上，质量防线一再失守，值得深思。除了可能的技能问题，态度和意识是首要问题。

未正确处理的返回值或异常

一般公司的编码规范都会涉及异常的正确处理问题。比如业务异常，系统重试；系统内部异常，返回失败；明确抛出异常和空字符串NULL的区别，明确抛出异常和返回数字0的区别等等。被调用方本应该抛出异常，结果返回了0，那么调用则继续按照正常的业务逻辑进行处理，就会发生超出预期的事情，比如本应扣款的账户却未扣款而产生资损。

GITLAB误删除数据库事件

前一段，Gitlab.com发生了一个大事，某同学误删了数据库，这个事看似是个低级