点击“技术领导力”关注∆  每天早上8:30推送

作者| Mr.K   编辑| Emma

来源| 技术领导力(ID：jishulingdaoli)

上周张总让我介绍一个架构师给他，正好我的朋友大卫最近在看机会，于是我们就约一起碰个面聊聊。

张总带了一位技术经理Peter一起来，从发型和发量上来看，Peter应该是高级开发。

张总的公司有10来个开发，2个产品，1个运维，没有测试人员和项目经理。他说这个团队是facebook的低配版，人不多，但都很精悍，按这个逻辑，张总自己就是小扎男了。

他们的项目叫做“青年横财发展促进会”社区，提供专业知识服务、行业分析报告、同行交流等等，其实就是割创业者的韭菜。因为做得还算专业和专注，业务发展得还不错。这也说明确实有太多的韭菜，迫切地想要提高自我修养，把镰刀都忙坏了。

业务的快速增长给系统带来了巨大压力，现有技术团队有点搞不定了，近期故障频发。

大卫跟他们的技术经理Peter聊起来。

大卫问，你们目前的技术架构是怎么样的？

Peter说，前端用了多端适配的框架，类似uniApp，用来提高开发效率；后端按业务域简单拆分服务，有个简单的网关做负载、鉴权；只用了一个数据库，没做拆分；缓存简单用了一些redis。

大卫又问，质量怎么控制的？线上问题多吗？版本节奏是怎么样的？

Peter回答，我们没有测试，刚开始是开发做交叉测试，现在忙起来也没做了，每周都有10几个线上问题，小问题不断。目前一周一个版本，基本隔一天上线一次，修复bug和常规发版。接下来有个大版本，所以这两周没有发版，除了一些hotfix。

大卫点点头接着问，你们开发团队的人员构成是怎么样的？

Peter说，我5年经验，另一个主力开发也是5年左右，6个JAVA，3个前端都是2年左右的。

又聊了一会，Peter也问了大卫一些服务熔断、数据存储架构方面的问题，雨一直下，气氛还算融洽，聊完，大家就各自散了。

晚上的时候，收到大卫的信息，“跟技术Leader聊了10分钟，我就猜到下周要发生重大宕机事故！”

我说，聊得不投机也不要这样诅咒他们嘛，张总除了不懂技术、不懂产品、不懂管理、比较抠门、人品差之外，人还可以的。

过了一周，张总突然打电话过来说，当天发新版，宕机4个多小时，电话被客户打爆了，损失巨大，让我催下大卫那边，有意向的话赶快入职。

我很好奇，大卫是怎么猜的这么准。

大卫看起来并不惊讶，他说，老K呀，这其实也不全是猜测，你记得这个数字吗？“300：29：1”

哦，大卫说的是“海因里希法则”。

大卫接着说，你还记得那天我问他的几个问题吗？根据当时得到的信息，我做了一些分析，就得出这个结论了：

1、系统迭代节奏一周一个版本，说明团队的研发压力是比较大的。虽然BAT、TMD这些公司也是这个迭代节奏，但是别忘了，他们都是有自动化测试工具，以及专门的测试人员做质量保障，是有成熟质量体系的。

2、每周上线4次是非常频繁的，对系统稳定性挑战很大。一项数据统计显示，线上事故80%是由于上线变更引起的。因此，频繁的变更对系统稳定性的影响很大。当然，你又会说BAT也是这个发版节奏啊，那你怎么不说他们都有成熟的DevOps工具，能够支持灰度发布、蓝绿发布，发版失败也能够做回滚，这样对线上的影响是很小的。

3、没有质量保障措施。如果团队成员比较资深，可能即使没有专门测试人员，质量问题也不是特别大。但是张总的技术团队，以三年以下的程序员为主，没有大厂规范开发经验，也没有任何质量保障措施，质量问题就像炸药桶，随处会爆发。

4、每周10几小事故。这已经是重大事故的前兆了，一旦到了一个临界点，事故灾难一触即发。

5、雪崩的最后一片雪花，就是他们准备要发布的大版本。小修改，产生小问题，他们对代码都比较熟悉，所以改起来快。但是大修改，可能动到了底层，而且没有经过性能测试，直接上生产，往往会导致重大生产事故，并且他们上线的时候，大概率是没有回滚方案的，只能在线上改，所以处理的时间会很久。

我说，大卫啊，你干技术屈才了，干侦探去啊，抓小三、揭发渣男，比干技术有前途。

言归正传，我们继续聊聊“海因里希法则”，海因里希是美国著名的安全工程师，他分析了保险公司的工伤事故数据，在55万件事故中，其中死亡、重伤事故1666件，轻伤48334件，其余则为无伤害事故。

从而得出一个重要结论，即在事故中，死亡、重伤、轻伤和无伤害事故的比例为1：29：300。说明，在生产过程中，每发生330起意外事件，就有300件未产生人员伤害，29件造成人员轻伤，1件导致重伤或死亡。

后来国际上把这一法则叫事故法则，也就是著名的海因里希法则 （“1：29：300法则”）。

这是一个事故发生的概率。给我们的实际指导意义是，通过不断排查和消除安全隐患和危险行为，则可以有效降低重大事故的发生几率。

然而在大多数企业中，管理者通常只考核员工的安全事故数量。这种指标设置是非常危险的。因为，安全事故的发生通常不是主观发生的，并不由员工的意识所控制。如果只是考核安全事故的结果，那么会造成很多员工即使发生了事故也会尽量隐瞒不报。而最终只会把大量的隐患隐藏在冰山下，导致严重事故的发生。

因此，在实际管理中，我们应该鼓励员工尽量去发现一些危险隐患或者危险行为。以发现的数量进行考核，越多越好。这样我们才能从根本上消除安全隐患的发生。

具体怎样做呢？

以软件开发为例，质量数据显性化是个不错的方法，啥意思呢，就是管理者关注软件开发中质量相关的数据，将过程质量数据定期公布给整个团队，并激励和引导开发人员进行自我检查，这样才能最大程度的消除安全隐患，降低事故的发生。

如果想要降低事故发生的概率：

第一，线上事故的发生只是结果。过多关注结果指标对降低事故毫无帮助。

第二，事故的发生根本原因是由于：技术人员的行为不规范，比如开发不写单元测试，测试用例覆盖不全，运维人员不遵守变更规范。

第三，彻底解决技术人员行为不规范的办法是，建立质量操作规范、反复宣导质量意识。比如，技术团队要指定上线规范、变更操作流程，这些规范流程要落实到系统操作当中，强制执行。要反复宣导质量意识，经常敲警钟，通过邮件、海报、视频等手段，强化每个人的质量意识。

要减少线上事故，功夫在于平时的点滴积累，按照“海因里希法则”的比例，“1：29：300”，把300这个分母降低，那么1这个重大事故的概率就可以大大降低。

如果觉得本文对你有所帮助，请关注本公众号、转发朋友圈、点在看，老K每天早上8：25为您推送一篇原创干货文章。

作者简介：Mr.K，知名电商公司技术老K级人物。文出过畅销书，武做过CTO，若非生活所迫，谁愿一身才华。

-END-

关注公众号，不错过每一篇原创干货

想跟100位CTO学习交流？回复“加群”

这是公众号作者老K的私人微信

席位珍贵，至于老K加不加你，随缘吧！

（如遇繁忙，请手动添加：laokei2020）

大家在看：

1.最“狂”天才，保送清华，怒怼阿里 P10！

2.一个好的Leader，首先要分清谁是“野狗”

3.从一线技术到阿里合伙人，主导了去“IOE”

4.Leader忙死，下属闲死，谁的错？猴子理论

5.BAT都在用价值10万的思维工具：费米估算

6.如何看待，阿里不再强制员工提交周报？

7.CTO丢给我《技术管理30条军规》照着做！

8.业务方的一堆需求，CTO一句话就怼回去了