服务器 频道

降本增笑P0事故频发,构建持续高可用系统的破局之道

  2023年的互联网世界,“草台班子”、“降本增笑”、“开猿节流”成为大家互相调侃的关键词。苦笑过后,问题还在,事故终要复盘,未来仍需规划。从架构角度看,我们应该怎么去认清高可用的本质,并真正在业务场景中做好高可用,这是本文想跟大家探讨的问题。

  2023年过去了,但是相信没多少技术人会特别怀念它。这是不平静的一年:首先是大大小小的公司各种花式裁员,35岁危机的焦虑在行业蔓延;其次就是各个大公司萝卜蹲式的各种 P0/P1 故障,频繁占据了热搜榜单。

  虽然事后各个公司公布的故障原因五花八门,例如有的故障是因为某地域 IDC 冷冻系统故障,有的故障是因为升级工具 bug 导致服务器被误下线,有的故障是因为 K8s 版本升级导致容器全部宕机……等等。但是这样的解释很难让人信服为什么2023年会成为多事之秋的一年,毕竟机房故障、各种升级操作等以前也都存在,并不是2023年独有的。

  那到底是什么原因导致各个大公司频繁的线上故障呢?

  突然之间,“降本增笑”成了大家的共识:因为公司裁掉了经验丰富的35岁以上的一二线老员工,留下来的技术人员有的是年轻的,有的是便宜的,有的是新招的。虽然可能降了成本,但是很多系统踩坑经验和隐含陷阱都随着老员工的离去而丢失,系统容易出问题也就不奇怪了,而一旦出问题又没有经验丰富的老员工能够快速处理,问题影响变得更大,持续时间变得更长,之前各种技术大会上 PPT 写的天花乱坠的异地多活、高可用等高大上的方案,也都形同虚设,成了全网吃瓜群众的笑料。

  这个解释确实有一定道理,但是不是不降本就不会增笑呢?

  其实远没有那么简单,今天我们就来聊聊构建持续高可用系统背后的困境和挑战。

  一、高可用的达摩克利斯之剑

  首先,思考一个终极的类哲学问题:我们能否构建出永不出问题的系统,或者退一步讲,能否构建出不出大问题的系统?

  很遗憾,答案是“不能”,因为有两条定律成了高可用系统上面悬着的达摩克利斯之剑。

  第一条定律是“熵增定律”: 在一个孤立的系统里,如果没有外力做功,其总混乱度会不断地增大,最后达到一个无序的状态。

  “熵增定律”本来是描述物理学方面的系统的,但是类社会的各种系统也是完全符合“熵增定律”的,无论是我们所处的公司,还是我们开发的各种软件系统,都会遵循“熵增定律”。

  对于软件系统来说,“熵增”是无处不在的。例如:

  为了完成某个领导年度 KPI,原本需要6个月的项目,被压缩到2个月,代码加班加点才能写完,怎么方便怎么来,埋下大量的隐患和暗坑;

  产品经理为了绩效堆需求数量,做了大量无用又别扭的需求,代码经手了一茬又一茬的人,被改得复杂又看不懂,新需求都是另起一个if重新写,系统慢慢成了“代码屎山”;

  为了在市场竞争中先对手一步,技术团队被当成生产队的驴一样驱赶做各种新需求,技术债越来越多,但只要不到崩溃那一天,是不可能有机会停下来清理技术债的;

  好不容易花大力气做完了重构,后面新来的人不熟悉,又是按照自己的理解来到处改,团队又没有 code review 机制(代码都写不完,谁还有时间和精力去 code review),重构的模型和约定慢慢又被腐化了;

  技术不断在发展,各种新技术层出不穷。技术团队不管是为了自己的绩效也好,是为了业务的发展也好,最终都会大概率选择不断尝试和引入新技术。虽然确实能享受新技术的一些好处,但也带来了复杂度和风险的增加。

  这些问题有破解方法吗?看起来都可以破解,“只要……” 就行了,但实际落地会发现,一个都破解不了,因为有人的地方就有江湖,而技术团队在这些场景中,基本都是最弱势、最没有话语权的。

  第二条定律是“墨菲定律”:任何可能出错的事情最终都会出错。

  好吧,假设我们的老板真的懂技术愿意给技术团队偿还技术债,假设我们的 leader 真的时刻关注系统质量,假设我们的产品也都像微信张小龙一样尽量克制,是不是就意味着我们的系统就不会出大问题了呢?

  很不幸的是也做不到,墨菲定律告诉我们只要你的系统还在运行,就总有可能出错的。例如:

  机房空调可能会损坏,服务器可能起火,网络可能被挖掘机挖断,网线可能被老鼠啃破,海底光缆可能被船拉断;

  你用的 MySQL 一定会有 bug,K8s 也一定会有 bug,Nginx 也一定会有 bug……等等;

  你的系统代码也一定有 bug,只是你现在不知道 bug 在那里而已。

  有的人可能会说,我们做了异地多活架构啊,出故障后切换就可以了。但实际上异地多活本身可能就有问题,异地多活相关的辅助系统在真正需要切换的时候也可能用不上。

  基于上述分析,我们可以看到,构建永不出问题的系统是不可能的,如果你的老板看到出了问题就说技术团队不行,那么我建议你可以尝试给他科普一下“熵增定律”和“墨菲定律”)

  当然,我们也不能拿“熵增定律”和“墨菲定律”来作为躺平的借口。虽然无法构建永不出问题的系统,但也不能让系统天天出问题,所以我们还是需要考虑如何去构建持续高可用的系统。

  二、构建持续高可用系统的困境

  但是在实际落地高可用建设的时候,会遇到第二个挑战:神医悖论。

  “神医悖论”是我从扁鹊回答魏文侯的问题里面概括的一个名词。原文大意是魏文侯问扁鹊三兄弟中谁的医术最高明。扁鹊回答说:“长兄最善,中兄次之,扁鹊最为下。”扁鹊医术精湛,神医名声远播,为什么扁鹊却认为大哥二哥比他强呢?

  扁鹊解释说:大哥治病于病发之前,一般人不知道他事先除去了病因,故而他的名气无法传出去;二哥治病于病情初发之时,一般人以为他只能治轻微小病,故而他的名气只及本乡里;而扁鹊治病于病情严重之时,所以他们认为扁鹊的医术最高明。

  我们在建设高可用系统的时候,一样会遇到“神医悖论”。不管公司是有专门的 SRE 团队,还是各个团队的直接负责系统高可用;也不管公司是为了可用性做了很多基础系统,还是各个团队靠人力来保障可用性,都会面临这个问题:你怎么证明你的可用性做得好?你的可用性投入是有很大价值的?

  假设1年没出问题,能说明是你的可用性工作做得好吗?

  很难,因为大概率可能是你运气好。所以也许有时候去庙里烧点香,也能达到这个效果。某互联网大厂以前准备双十一的时候,很多团队都会事先去灵隐寺拜一拜的,据说确实拜了和不拜有差别。

  假设今年出了一个 P0 问题,就能说明你可用性工作做得不好吗?

  也不一定,因为也可能是你运气不好。即便都是 P0 问题,如果没有你做的这些可用性工作,时间可能从1小时变成6小时,损失可能从1000万变成8000万,而你做的可用性工作,投入才100万。

  你兢兢业业地像扁鹊的大哥一样,做了很多事情把各种问题都消灭在萌芽状态,全年下来没有发生任何 P0/P1/P2 故障。年底汇报的时候回过头来一看,全是一些看起来鸡毛蒜皮的事情,你怎么汇报才能拿到绩效?

  相反,隔壁团队虽然上半年出了一次 P0 故障,但是换了一个 leader 后,新 leader 大刀阔斧重构架构,搞多活建设,年底汇报 PPT 都写了50页,绩效不是 S 就是 A。你难道跟老板说“我是扁鹊大哥,他只是扁鹊而已”?

  从技术的角度来说,构建持续高可用的系统实际上就是要和扁鹊的大哥一样,要花费很大的时间和精力来做各种琐碎的事情,将问题消灭在萌芽状态。虽然不能彻底消灭所有问题,但是可以大幅度减少发生大问题的概率。

  例如:单元测试、code review,数据库设计规范、监控系统、应急系统、架构评审、方案评审、系统重构、全链路测试、混沌测试、故障定期演练、灰度发布……等,这些事情散落在各个团队,项目的各个阶段,但是都和高可用有一定关系,对持续高可用有一定的作用。

  但是从人的角度来说,要想通过高可用建设拿到好的绩效,却需要和扁鹊一样。只有等到系统已经被证明不行了,系统故障影响太大了,老板或者领导才会突然发现可用性的价值,才会给予技术团队时间、人力、资金来做高可用建设。

  例如:微服务演进、弹性架构、同城双活、异地多活、多云建设、混合云演进……等,一看这些技术名词就能看出来高大上,规划这样的项目,技术团队干起来都特别有劲,年底汇报写 PPT 都能写出花来。

  从老板的角度来讲,一样也面临神医悖论带来的挑战。假设老板心甘情愿每年投入1000万给某个团队来做高可用,最后年底一看1000万下去,就做了一堆琐碎的事情,心里肯定也会有疑惑:你们这帮小子,拿了我1000万,弄了一个几十人的团队,一年到头就干这点事?

  如果老板愿意投钱的时候都会有这种困境,那么当老板开始“降本增效,开猿节流”的时候,更加会毫不意外地优先裁掉做可用性建设的团队和人员,而往往在团队里面负责这部分工作的员工,都是经验丰富但成本也高的老员工。

  于是乎,“降本增笑”几乎成了不可避免的结局。

  三、破局之道?

  综合上述的分析来看:结果的不确定性,价值难以准确衡量,工作不容易被看见等因素,让实践中的高可用工作都变成了运动式高可用攻坚项目。

  简单来说就是陷入了一个无解循环:前人积累太多技术债,系统磕磕碰碰逐渐越来越不稳定,但是没有人愿意花太多时间去整体解决,只希望保证击鼓传花的雷不要在自己手里爆炸即可。

  等到哪一天某个倒霉蛋运气不好,系统终于发生了“史诗级”的故障,成功让公司上了热搜;此时老板或者大领导们终于顿悟:如果系统再来一次类似的事故,业务或者自己可能就要吃不了兜着走了。

  于是公司或者大领导开始了运动式的高可用攻坚项目:先找一个原来的倒霉蛋背锅,让他走人或者降级;然后找一个新的幸运儿来负责高可用的“彻底优化”。幸运儿来了之后肯定不会走扁鹊大哥的路线,而是直接整高大上的项目:重构、双活、多活、多云、混合云等。

  基本上这样的项目建设可以做1年,彻底完善可能需要2年。做完后系统整体的高可用能力确实能上一个新的台阶,毕竟那么多问题都明摆着,光解决这些问题就能够很大提升系统质量,更何况还做很多高可用的架构、基础设施等,肯定能够大幅提升系统的高可用能力。

  于是新的幸运儿大概率会升职加薪,走向新的职业巅峰,老板或者大领导们也终于放心了。

  但是系统正是从这时候开始又慢慢地进入了新的一轮循环:继续拼命赶项目忽视质量;继续堆各种杂乱的需求;原来做高可用相关的人员逐渐缩减,调岗到其它业务开发团队……就这样又慢慢地逐渐退化,直到新一轮的运动式高可用攻坚项目来临。

  有什么有效的破局之道打破这个循环吗?坦白的说:几乎没有。

  绝大部分人能做的就是期望自己不要成为这个循环中的倒霉蛋,或者自己能够成为这个循环中的幸运儿。

  如果说一定要打破这个循环,其实关键不在技术团队身上,而是取决于老板和大领导们。

  当然,并不是要老板和大领导们自己买一本《SRE 谷歌运维揭秘》的书籍自己去学习如何做高可用建设,关键在于转变对持续构建高可用系统的认知,然后鼓励技术团队持续在高可用方面进行一定的投入。

  首先,意识到系统和人类似,高可用的系统需要持续建设。

  健康的系统和健康的身体都是要持续投入的,而不是靠一段时间内突击运动和打兴奋剂。在日常的工作中,给技术团队留出一定的时间和精力来做一些高可用方面相关的工作,即便这些工作看起来在当时都没有明显的作用。

  其次,不要那么功利化。在高可用方面保持一定的人员和投入,即便看起来这些都是“成本压力”。

  就像人锻炼一样,很难说今天跑了 5KM,身体就一定变好了,甚至有可能今天跑了 5KM,过两天还会感冒发烧。但长期来看,坚持锻炼的人身体大概率会比不锻炼的人要好很多。

  因此,公司和组织可以安排一些人员来专门负责高可用方面的一些工作,保证高可用相关的一些系统、工具、规范有人去推动落地。就算这些人没事找事,那他们也是在寻找系统中的一些隐患和不足,或者尝试对系统进行优化和加固。

  第三,坚持定期给系统体检和保养。

  就像人需要定期体检,车子需要定期保养一样,系统也需要定期的检查和保养。千万别不出事就万事大吉,出了事就莫名惊诧!

  可以每年给系统进行一次小的复盘和盘点,每两年给系统进行一次全面的检查和优化,大概率就可以避免一些灾难级的故障发生。

  即便运气不好发生了严重事故,也可以大大减少故障的影响时间。要知道一个2小时的 P0 故障和一个12小时的 P0 故障,虽然等级都是一样,但是影响和破坏力是天差地别。

  总而言之,构建持续高可用系统的破局之道,其实在于公司和组织的技术文化上,而非技术手段。

0
相关文章