真英雄最终都不会在半夜里爬起来抢修生产事故,因为他们会聪明地使用分布式系统稳定性设计,以及混沌工程,避免将自己陷入如此凄惨的境地。
作为一名开发人员,如何能让自己能逐渐减少在半夜爬起来抢修生产事故的次数?可以尝试使用本文要介绍的“分布式系统稳定性设计关键清单”。
如何让队友不会半夜把你喊起来帮着抢修生产事故?影响领导,尝试使用混沌工程,来让团队成员都在上班时间,主动发现并修复分布式系统的漏洞,逐渐减少夜里喊你的次数。
不是。真英雄最终都不会在半夜里爬起来抢修生产事故。为什么?且听下面的故事。
我以前很崇拜那些能修复各种软件缺陷的“救火”高手。
很多年前,我曾经在一个维护遗留系统的团队做过开发。
团队的每个开发,都轮流带一个7x24小时开机的手机,处理用户问题。
团队里有一位英雄。他戴眼镜,经常身穿一件白大褂。
我们要是有搞不定的各种疑难杂症,就会找他。
他能搞定80%的问题。所以过去了十多年,我依然很佩服他,觉得他是英雄。
但当年团队还是火情不断,我们这些普通水平的开发人员,还是救不了火。
前段时间在“得到”听华杉的孙子兵法。
孙子说:善战者,无智名,无勇功。
因为善于作战的人,会始终设法让自己在局部能比敌人更强大,又不错过敌人犯错的机会,所以每次胜利都轻轻松松。
“战胜而天下曰善,非善之善者也”。
如果你打了一场漂亮战,全天下的人都说太漂亮了,那不一定是什么好事。为什么?因为这是侥幸,重复不了第二回。
华杉讲起了扁鹊的故事。
扁鹊是一个名医,有一次魏文侯问他:“听说你们家兄弟三个人都是医生,那谁的医术最好?”
扁鹊就说,“我们家大哥医术最好,二哥差一点,我是最差的。”
魏文侯就不明白了:“你是天下名医啊,你大哥和二哥都没有听说过。”
扁鹊就解释:“我大哥治病是在病情发作之前,病人自己还不觉得有病,大哥就下药,铲除了病根。所以他的医术很难被人家认可。”
“我的二哥没有大哥那么大本事,在病情发作之前他发现不了。但在病情初起症状不十分明显的时候,二哥能够药到病除,所以村里人会觉得二哥还能治点小病。所以他的名气只能在本村,邻村的人都不知道他。”
“我的动静就会比较大。我治病都是在病情十分严重,病人痛苦万分的时候。我在病人的经脉上穿刺,有时候甚至还敷上毒药来以毒攻毒。最后这个病人可能得到了缓解,甚至还有治好的。所以我就名闻天下了。”
要每天治小病,而不要每年治大病。
每天治小病,花钱少,痛苦少,治得好,百岁老。
以前听到这个熟悉的故事,并没有什么感受。但最近这一次听,却颠覆了对英雄的认知。
我以前所认为的英雄,其实并不善战,而只是运气好。
而真英雄,是能把需要半夜爬起来抢修的生产事故,化解成一个个小任务,在白天上班时间给解决了。还需要半夜里爬起来吗?
有人会说,我刚刚毕业,加入一家公司,接手了一套“祖传代码”,经常需要半夜爬起来抢修生产事故。这该咋整?
可以在自己日常开发新代码,或解决软件缺陷时,经常浏览和思考下面的“分布式系统稳定性设计关键清单”,来检查相关的代码,是否踩了系统稳定性的“反模式”?如果是,那么可以用系统稳定性的“模式”这些“解药”来解决。
这样,就能把需要半夜抢修的事故,逐渐分解到日常开发中,在白天上班时逐一解决。让自己能睡个好觉。
其中,反模式和模式前面的编号,分别是《发布!》第二版第4章和第5章的小节号,方便查阅。
如果不明白后面“解药”的含义,可以查阅后文“解药的解释”一节。
反模式场景 | 反模式编号、名称及含义 | 解药 |
---|---|---|
系统的用户 |
|
|
系统的用户 |
|
|
子系统之间 |
|
|
子系统之间 |
|
|
子系统之间 |
|
|
子系统之间 |
|
|
子系统之间 |
|
|
子系统之间 |
|
|
子系统之间 |
|
|
子系统之间 |
|
|
子系统之间 |
|
|
子系统之间 |
|
|
解药,即解决相应反模式的系统稳定性的模式。
模式编号与名称 | 模式含义 |
---|---|
| 只要认为响应不会到来,就可以停止等待 |
| 如果调用执行成功,那么一切平安无事。但如果调用执行失败,断路器会将其记录下来。一旦失败次数或频率超过阈值,断路器将跳闸并“断开电路” |
| 能将船分隔成若干独立的水密隔间的隔板,可防止水从一个部分流到另一个部分。使得船体即使被洞穿一次也不会沉没,从而控制损害范围 |
| 针对每个累积资源的机制,要相应存在另一个机制以回收该资源 |
| 如果系统无法满足SLA要求,则需要快速通知调用者。不要让调用者等待错误信息,也不要让他们等到超时为止。否则只会让你的问题成为他们的问题 |
| 创建系统级稳定性所能做的最好的事情,就是放弃组件级的稳定性,并尽快更换组件,以回到系统最初干净的刚完成启动的状态 |
| 发送方和接收方两个设备之间用于规范两者之间通信方式的过程,让服务器通过限制自己的工作量来保护自己 |
| 能够用网络错误、协议错误或应用程序级错误等各种低层错误,来“考验”被测软件的测试服务器。因为每个系统最终都会偏离接口规范 |
| 通过在系统之间传递数据和事件的中间件来实现集成;通过让参与其中的系统不必了解其他系统的特定知识,而只是对其进行调用,来实现解耦 |
| 当负载过高时,就开始拒绝新的工作请求。这与快速失败模式相关 |
| 请求的消费方将其处理请求的速度通知发送方,让自己能慢些工作,从而创造安全性 |
| 减缓缺乏判断能力的自动化机制出错时的速度,从而为纠正错误争取时间 |
如果按照上面的方法,能做到自己很少在半夜爬起来抢修生产事故,但保不齐你的队友没有掌握这套方法,结果半夜把你喊起来,帮着抢修生产事故。这该咋整?
当然你可以把上面那套方法及其成效,分享给和你关系不错的队友。
但更有效的方法,是设法影响你的技术领导,请他了解《发布!》第2版最后一章所介绍的新实践——混沌工程。
早在2008年,Netflix公司在把数据中心迁往亚马逊云平台的时候,踩了一个大坑,经常会出现生产事故。为了能在白天上班时间解决生产环境的事故,而不是半夜爬起来解决,他们摸索出一套行之有效的方法——混沌工程。
可以自己阅读并请领导阅读这篇文章“【混沌工程入门】领导让我做混沌工程……该咋做?——《混沌工程》动物书2020年4月英文版解读之一”。
然后从那篇文章后面所介绍的“摆正心态、人员主动和试点业务”三方面入手,来启动混沌工程,从而让这个试点业务的每个团队成员,逐渐成为不会把自己逼到夜里就火份儿上的“真英雄”,这样他们也不会半夜喊你帮忙了。
需要注意的是,因为那篇文章重点是混沌工程,而不是本文所讨论的“分布式系统稳定性设计”,所以并没有在“该咋做混沌工程”中,体现前面说到的稳定性设计。
为了弥补这个缺憾,下面把稳定性设计补上,并用黑体字标出补充的内容。
借鉴Netflix的实例,可以从“摆正心态、人员主动和试点业务”三方面入手,来启动混沌工程。
承认暗债为复杂系统所固有,而不是一味要求工程师“不能也不该出现失误”。否则在故障面前,大家就只会花大量时间相互甩锅,耽误了发现更多暗债和防范措施。
前面说过,根据必要多样性法则,要建立对系统能够承受生产环境的动荡的信心,需要针对生产环境“丰富多彩”的暗债,设计同样“丰富多彩”的防范手段。而技术骨干一个人,是发现不了那么多暗债,并找到那么多的防范手段的。所以,就需要发挥各位工程师的主动性。此时,领导者要创造能调动工程师主动性和创造性的企业文化,来促进工程师更安全地发现与修复更多“花样”的暗债。在修复暗债的过程中,就可以使用上述“分布式系统稳定性设计关键清单”。