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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　为了验证专项通过推进“SLA握手”提升灾备能力的成。