共创共识 相互支撑——小米公司软件服务端质量提升背后的故事

共创共识 相互支撑

——小米公司软件服务端质量提升背后的故事

□ 本报记者 彭 燮

大面积宕机、大规模断网、大量用户无法访问……近年来，多家互联网企业接连发生服务端质量事故。因此，软件服务端质量保障成为各企业关注的重点项目，小米公司也不例外。

服务端被称为软件系统的“基础设施”，一旦出现故障，会给业务端带来很大负面影响。但由于其自身的复杂性以及软件开发的随机复杂性，服务端“零故障”在现有条件下是不可能实现的。因此，作为一家服务全球数亿用户的移动互联网公司，小米公司能做的就是，尽可能降低服务端质量事故发生的概率，以及在事故发生后，尽可能减少对用户的负面影响。

这也是小米公司软件服务端质量提升专项（以下简称“专项”）的目标。2023年1月，小米公司由负责基础服务的集团信息技术部牵头，联合4个重点业务部门以及集团质量办共同成立专项工作组，围绕10个重点业务和25个核心基础服务，全力治理软件服务端的质量风险，目的是夯实基础服务容灾能力，并提升重点业务的逃生能力。

容灾和逃生，听起来像是应对各类灾害的专业用语，在专项工作组看来，服务端质量故障，就属于“技术灾害”，提高防灾减灾救灾能力，是小米公司必须要修炼的“内功”。

相互支撑的5毫秒

服务端和业务端共同完成各项互联网应用技术保障，分工不同，但目标一致。而专项工作组的工作之一就是要加强服务端和业务端的双向配合。

配合的基础是共识，在技术上被称为“SLA握手”，即双方就基础服务的具体技术指标达成一致。其难度在于，业务端主要关注业务指标对于提升用户体验和质量水平的重要性，而软件服务端主要从现有能力出发，更多考虑业务指标的提升路径和相应成本。

专项工作组给记者讲述了一个关于“5毫秒”的故事。

5毫秒，对于日常生活来说，是完全可忽略不计的时间。可对于Redis（一个存储数据库）日志组件来说，5毫秒却是目前业界公认的，能实现良好用户体验的最短延迟时长。

在软件服务端质量提升专项实施之前，米家工程师小张并不了解，在小米，其实有两个5毫秒：一个5毫秒是他所熟悉的，米家相关应用Redis日志延迟时长的标准，尽管延迟超过100毫秒用户才会明显感觉到“有点慢”，但米家依然把延迟时长标准定为5毫秒，这也是目前业界公认的最高标准；另一个5毫秒是软件服务端监测的服务器Redis日志延迟时长，目的也是想给米粉们提供最好的体验。

可问题是，这两个5毫秒，并不能划等号。

小张说，在实际应用中，他们时常发现Redis日志延迟时长达到6-7毫秒，虽然用户对于多出的1-2毫秒并无感知，但小米的工程师们不会视而不见。他猜想，是不是软件服务端出了问题？

通过专项，小张发现自己想错了——软件服务端的工程师们一直坚守着“5毫秒”的标准，而且从目前技术数据看，基本上不会出现延迟时长达到6-7毫秒的情况。

那问题到底出在哪里呢？

经过双方工程师的共同排查和数据“拉齐”，他们找到了延时时长增加的原因，小张管它们叫“中间地带”，包括网络、云平台容器等。一般来说，它们会增加1~2毫秒的延迟时长。甚至有一次云平台容器基础设施升级，业务端的延迟时长最高超过20毫秒。

问题找到了，那实现“SLA握手”的有两种方案：一是以业务端的5毫秒为基准，让软件服务端把“中间地带”造成的延迟算进去，进一步缩短延迟；另一种是以软件服务端的5毫秒为基准，综合考虑“中间地带”的因素，业务端适当提高延迟时长标准。

对于小张和同事们来说，第一种方案显然是最简便也是最好操作的，因为只需要看好自己业务的数据，就可以保证不出现延迟问题。但最终，他们却自愿选择了第二种方案。

“我们觉得，考虑问题不能只想着自己怎么方便怎么来，而是要从集团整体角度来判断，什么是最优解的。”小张的考虑有两方面，一是在现有技术条件下，如果要保证业务端的5毫秒，就意味着软件服务端要把延时控制在3~4毫秒，这需要公司投入巨大成本，投入产出严重不成比例；二是对于软件服务端的同事来说，他们平时主要是着眼于基础服务，对“中间地带”的运行原理和相关情况的了解不如业务线多，让他们去负责排查“中间地带”的问题，要多花费很多的时间和人力。“这样做，他们的压力太大了，不光要管自己，还要管自身以外的一些业务。”小张说。

就这样，原本是“自说自话”的两个5毫秒，通过“SLA握手”，双向奔赴、合二为一。而工程师们也从在一个园区里上班却少有联络的“网友”，变成了互相支持、互相信赖的真朋友。

让人“上瘾”的“噩梦”演练

如果盘点小米工程师的“噩梦”，交换机断网肯定可以算一件。 一台交换机断网已是大事故，更不用说两台交换机同时断网了。然而，就在2023年5月20日凌晨，小米公司近百位工程师共同“围观”两台交换机同时断网。那个场面让软件服务端运维工程师刘工至今难忘。

为了验证专项通过推进“SLA握手”提升灾备能力的成效，提升各业务端和软件服务端的协调作战能力，工作组先后组织了4场集团级别的应急有损演练——几乎辐射小米所有业务线。作为应急演练的具体负责人，刘工用“纠结”两个字来形容自己当时的心情。

让人纠结的点在于，因为是有损演练，万一演练过程中引发了更大的问题，波及的用户数量可能是数以亿计的。“虽然公司不追责，但怎么和米粉们交代呢？”刘工记得，有位业务工程师曾质问他：“干嘛非要搞个事出来！”

“没事找事”的背后，是因为工作组深知，问题不会因为不演练就不发生，与其因为意外情况失控，还不如通过有损演练把预案做好。这就和消防演练对防火工作的重要性一样。再难也得干！而且他们直接挑战两台交换机同时断网，这在小米历史上是从未发生过的。

2023年7月25日凌晨，近百名小米工程师在工作群里集合，之所以选择这个时间，也是为了尽量减少对用户可能造成的影响。

“倒计时10分钟。”

刘工发出第一条指令。各业务线工程师开始按照之前预演过的流程进行准备，监控相关数据。

“倒计时5分钟。”

刘工发出第二条指令。各业务线工程师再次确认应急预案。相关操作人员进行准备。

“倒计时1分钟。”

刘工发出第三条指令。这一刻好像空气都凝固了，群里看似静悄悄，又仿佛能听到大家的心跳。

“光纤接口已断开。”

负责“制造”交换器断网的工程师在群里发布了最新情况，随后群里逐渐热闹了起来。有的工程师表示，确实如预判的一样，后台数据明显波动，但好在有预案，用户基本感受不到；有的工程师表示，居然没有出现预想的问题；有几位本来是“观战”的工程师说，自己的业务后台数据竟然出现了抖动。

让人纠结的演练终于结束了，结果令人欣慰——事实证明，软件服务端质量提升专项确实提升了业务端和服务端的“合力”和灾备能力，通过双方“握手”和数据“拉齐”实现的预防方案，能够应对突发情况的挑战。

更让人欣慰的变化是，这场演练居然让小米工程师“上瘾”了，一些之前观望的业务线，主动找到工作组要求参与演练；工程师在评估业务量的时候会考虑演练所涉及的容灾内容；甚至有些工程师在得知演练没有发现问题的时候，会感叹“白演练了”。

实践证明，故障演练很好地验收了对前期项目推进的成效，也全面检验了各团队应急响应能力、预案执行效率、系统协同能力。

从“治病”到“治未病”，从“救火”到“防火”，这是专项给小米质量工作带来的积极变化。虽然推进过程非常艰难且纠结，但正如刘工所说：“我们多纠结一点，用户选择小米的心就会更加坚定一些。”

《中国质量报》