「海恩法则」是航空涡轮发动机的发明者帕布斯·海恩提出一个在航空界关于飞行安全的法则。海恩指出：每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。法则强调两点：一是事故的发生是量的积累的结果；二是再好的技术，再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。「海恩法则」虽然针对的是飞行领域，在软件开发领域遭遇生产bug，用「海恩法则」也可以解释。
当生产环境出现bug的时候，通常情况下，我们会很快定位出bug产生的原因具体在哪一行代码上，然后根据实际情况决定回滚或者修复。然而事后总结发现，每一个线上bug的出现绝不仅仅是代码的问题，会涉及到开发、测试和运维多个环节；更多暴露出的是流程的问题，管理的问题，执行力的问题。特别是初创团队和架构大规模升级后最容易暴露出代码以外的问题。以我个人处理过的生产bug，事后分析原因最多的一次有14项措施要么缺失，要么执行不到位，其中与代码相关的只有2项，更多的原因是方案和流程执行不到位。
上线前通常会采取一些措施来保证质量；比如：开发阶段的code review，ut以及测试阶段的压测等；而且会有配套的流程确保必要的步骤都执行到位；然而即便采取多么复杂的流程也不能避免bug的出现。归根结底，代码是人写的，是人就可能出错 ；我们要做的不是不出bug，而是不出低级bug 。对于可能出现的低级bug要擅于通过工具发现；诚然，再好的工具和流程也比不上人自身的素质和责任心。
上线后系统会有各种维度的监控确保系统正常运行；在出现生产bug前监控系统通常会有异常表现，比如CPU，内存，IO，线程等指标可能会有同比变化；此时报警策略的精准性和人的责任心就比较重要；发现异常后第一时间根据各项指标分析出异常的根本原因，是正常波动，是受到攻击还是程序bug。特别是新功能或者bug修复后上线要特别注意这些指标。在确认系统出现问题时候后立刻采取相应措施，回滚，扩容，限流，熔断等，避免或者尽可能减少造成的损失 。
其实所有的问题都可以归结为人的问题。最后想到奈飞文化准则的第一条「我们只招成年人」 。