每个公司大概都有一个“稳定性保障一号位”，在不断翻车中持续进击。

当技术手段不足以提供确定性解法的时候，一般就需要祭出“压实主体责任”这最后的一招了，充分调动每个人在组织中的能动性，以达成目标。而设置“一号位”通常是压实主体责任的第一环。

在 IT 领域，稳定性保障一直属于最不具备“确定性解法”的 topic，防不胜防，大家的解法也是五花八门，你有你的张良计，我有我的过墙梯。奈何常在河边走，哪能不湿鞋。打脸来的太快，这怕是对负责稳定性保障的技术人心态的最好写照了。

此外，稳定性保障工作，低频、高危。平时不显山露水，但是一旦发生大故障，一号位首当其冲，如果功夫没有做在平时，那就是被架在火上烤，在接下来的稳定性整改运动中，基本可以引咎辞职了。

稳定性 case 的影响可大可小，对应的责任也可大可小，取决于：

1. 承载的业务的重要性
2. 故障时刻的损失程度
2. 舆论的传播面
3. 品牌的影响度
4. 法律法规和监管的要求
5. 公司管理制度的要求

因此，随着以上几个因素的不断变化，公司在某个阶段，对稳定性保障提出更高的要求，对一号位的要求也会有不同。但总体而言，一号位的职责总结如下。

## 稳定性一号位的职责是什么

1. 承担责任

也俗称“背锅”，稳定性既然是技术领域的重要工作，对业务产生着重大影响，那么结果不符合预期，一号位需要承担责任，这是完全说得通的，有压力才有动力。但承担责任不是目的，核心还是通过一号位的机制，将整个稳定性保障工作体系化的规划起来。

2. 制定合理的目标并确保目标可被分解和量化，让所有人参与进来

目标是否合理，体现在两个方面，一是稳定性目标是否和业务效果紧密挂钩，IT 系统是否稳定，是由其承载的业务是否正常来决定的，唯有如此，才能真正体现IT系统赋能业务支撑业务的本质价值，避免自嗨式目标、听不懂的目标；二是系统的稳定性，够用就好，目标过高，投入产出不成正比，要知道目标过高，每前进一小步，所花费的人力物力时间成本，会呈数量级放大。

目标设置不合理，首先是对自己的业务、IT 现状认识不全面，没有深入去思考，其次是盲目攀比，听闻坊间传说几个9，就随手拍脑袋，比他再高一个点！关于稳定性目标，可以延伸阅读[《服务稳定性保障的五大误解》](https://mp.weixin.qq.com/s/G8W2cqVKqT2AlZxWWXU0Rw)。

承担责任，也是一个技术活，要讲究方式方法，不是死扛硬抗，个人英雄主义。制定了目标，要有机制拆解到 IT 系统的各个技术参与方并且清晰的量化，确保参与方都能使上劲。具体可以参考[《SLO新解，一种行之有效的故障处理方法》](https://mp.weixin.qq.com/s/dA-7o-7wv0x24pDf0TXJag)。

3、确定预算

撇开成本谈保障工作，属于无源之水无本之木。稳定性保障一号位，在定好目标之后，接下来就是要确定和锁定预算。预算不单纯指直接负责稳定性保障任务的 headcount，也包括公司对于资源使用率要求、架构升级专项任务的预算、行业先进工具引入的费用预算、业务研发团队在稳定性工作上的参与度等等。

在一个大的组织，在年度预算开启前，确定好上面这些工作，是非常有挑战和考验稳定性保障一号位的综合能力。

4、建立技术保障体系

实际上是通过建立工具体系，做好两个事情：
- 不断提高稳定性保障的“确定性”：
>> 提高确定性的过程，就是不断兑现承诺、提升信心的过程，比如稳定性保障团队是否能在业务和用户感知之前发现问题，是否能给出故障解决的预期时间，能快速准确的评估故障的影响面，有行之有效的故障止损预案等。
- 不断降低稳定性保障工作的“门槛”：
>>要承认，现阶段处理故障，对工程师的经验要求太高了，既要有扎实的 troubleshooting 的能力，有强大的抗压能力，对各种工具平台熟练使用，还要对整体系统的架构、细节都非常熟悉，这就决定了这样富有经验的工程师总是很稀缺，难以批量培养，甚至于一旦离职或者转岗，容易出现青黄不接的现象。那么能不能把这些经验形成方法论，沉淀到工具中，形成套路，降低门槛就显得至关重要。

当然，随着微服务和云原生架构的更多采用，带来敏捷和高效的同时，使得整个IT系统的复杂度成数量级的上升，这与我们所追求的“确定性”、“低门槛”背道而驰。

1. 系统越来越复杂，以至于无法清晰的定义什么是真的故障，无法定义，那就更谈不上准确、及时的发现故障了，稳定性保障工作，直接输在了起跑线；
2. 数据量越来越大，信息过载的问题变得格外突出，技术团队在有限的时间里，无法有效、准确的提取关键信息，导致贻误战机，造成巨大的业务损失；
3. 稳定性保障，在整个行业范围，缺乏有效的方法论沉淀和产品化抽象，导致故障处理的各个环节，高度依赖工程师个体的经验，不具备复制性，难以持续改进，俗话讲，缺乏套路，门槛太高；

所以，如何通过技术手段，结合数据、流程，形成一套行之有效的稳定性保障打法，应对上面的挑战，所有的一号位共勉。

十年前，我从毕业到百度、小米、滴滴，从保障一个服务、到保障一个业务、再到保障全平台，scope 在变化，但是职责未变、初心未改。直到今天创立快猫星云，仍然是希望通过打造最好的Flashcat平台，为整个行业做出力所能及的贡献。

如果你有观点和解法，欢迎添加我的微信 laiweivic 探讨交流。

关于快猫星云

快猫星云，一家云原生智能运维科技公司，秉承着让监控分析变简单的初心和使命，致力于打造先进的云原生监控分析平台，结合人工智能技术，提升云原生时代数字化服务的稳定性保障能力。

快猫星云团队是开源项目夜莺监控的主要贡献者、项目管理委员会核心成员。夜莺监控是一款开源云原生监控分析系统，采用 All-In-One 的设计，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力，已有众多企业选择将 Prometheus + AlertManager + Grafana 的组合方案升级为使用夜莺监控。

夜莺监控，由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。

快猫星云产品介绍

- 一分钟视频介绍： https://flashcat.cloud/videos/flashcat.mp4
- Flashcat平台PPT： https://sourl.cn/G5iZCT
- Flashcat官网：https://flashcat.cloud
- 在线体验demo： http://demo.flashcat.cloud

办公区里此起彼伏的短信声、手机铃声，IM群里铺天盖地的消息，人人都在问，什么情况？服务挂了吗？有没有人在上线？。。这是在线服务挂了的日常一幕。

目前没有哪家企业敢承诺自己的服务肯定不会宕机，强如谷歌、亚马逊、微软的服务也不时有宕机的新闻传出。服务稳定性保障是一个系统而复杂的工程，有越来越多的技术关注在这个领域，以期提高稳定性保障工作的确定性。

对于做稳定性保障的同学来说，在众多稳定性保障方案和技术的选择中，不但要选对，更要避免选错用错，避免做无用功甚至适得其反。查理芒格说，如果知道我会死在哪里，我将永远不会去那个地方。今天就来聊聊那些稳定性保障工作可能的死亡地带，以资参考，如有谬误欢迎交流指正。

① 把日常排障和故障处理混为一谈

日常排障和故障处理是两个非常相似其实又有巨大区别的场景。但在谈到方案时很多人往往对它们不加区分，认为自己所用的方案和技术在这两个场景里是通用的（当然更有可能是没有意识到这是两个场景）。

这两个场景有什么区别呢？

最大的区别就在于日常排障是一个非紧急，以追查技术上的根因为主要目标的场景，而故障处理则是一个紧急，以服务的快速止损为主要目标的场景。

典型的日常排障，如追查个别用户请求失败的原因、追查某个模块响应时间变长的原因、追查个别程序实例崩溃的原因等等，这些异常以不影响全局的个例和局部问题为主。可能通过trace、通过程序堆栈分析、通过火焰图、通过代码分析等手段，最后查出是某个程序的代码bug，或某个机器的硬件性能问题等。

而服务故障则表现为相当比例的用户无法正常使用服务、大面积的服务宕机。这个场景里要追求的是服务的尽快止损恢复，需要争分夺秒，越快越好。要做到这一点，就不能按日常排障的思路来了。首先要做的是故障的特征分析和事件分析，基于特征和事件来确定一个止损方案，比如流量调度、比如重启服务、比如回滚上线、比如扩容、比如降级、比如摘除异常实例等等。这些操作都不必知道根因就可以执行，而且只要故障特征或关键事件对症，止损效果会立马显现。

当然，也存在这样的case，在故障中这些手段都用尽了仍然起不到止损的效果，这时候就不得不去深入排查技术上的根因，但这应该是最后不得以而为之。而且一旦走到这一步通常大事故已经酿成。

其实在稳定性保障中，日常排障和巡检一样，都属于故障预防，可以避免小问题和隐患引发事故。而故障处理则处在稳定性保障中最紧迫的位置。如果一开始就按日常排障的思路去做故障处理，那就好比医生用保健品来挽救将死的病人，药可能有用，但时间等不起。

基于这样的差异，日常排障更多的是关注在个别请求个别实例这样的点上，而故障处理则需要更多的从全局从面上去分析故障的特征和关键事件。

这两个场景可以共用的工具和方法很多，主要是不能把它们的优先级用反了。

更重要的是，当大家都把注意力聚集在排障和根因上时，是不是更应该想想，如何从全局上对故障的特征分析和事件分析做一些事情？

② 预案过多

想要抢在故障升级前恢复服务，确定了故障的特征或关键事件后就需要有预案来应对。但问题也在于有些服务的预案可能过多了，真到要用时可能不知道该用哪一个，光决策就花去很长时间，而终于选中一个却又执行不成功。

这个问题的关键可能在于缺乏预案建设的核心思路，只是漫无目的的打补丁。

我印象最深刻的预案是一招鲜：多活切流，以及围绕这个核心预案所做的预案集合。

这个预案集合的建设思路是：

要让多活切流能发挥作用，就必须控制所有异常的出现都是局部性的，不能所有多活单元里同时出现异常；
要做到第1点，首先要做好的就是变更和线上操作的灰度控制和灰度策略。而像机器/容器异常、网络异常，这些天然就是大概率出现在局部，不会多个单元同时出现；
再有，要让多活切流能够随时操作，还要保障好单元间的n+1资源冗余，以便切流时不至于容量不足；
为了平衡n+1的资源冗余和成本，就要做好服务降级，以便可以降低冗余，如果切流操作需要发生在高峰期，就可以先降级后切流；
以上工作做好，基本上80%以上的故障都可以在早期得到快速止损，不至于升级为大事故。

这个预案建设有几个重要特点：

核心预案（多活切流）操作简便、生效快；
思路和原则清晰，既有利于预案建设和维护，又有利于决策执行，甚至可以做到自动执行；
当然，不同服务的情况要具体分析，比如有的业务多活都没有，或多活建设很困难，不敢随时切流，那就需要另辟思路了。核心是要有核心预案和主线思路，那种预案建到哪算哪，像给服务不停打补丁的方案，迟早兜不住。

③ 用报警的多少来感知服务的异常和严重程度

老司机们也许会会心一笑，曾几何时，甚至是现在，有多少团队还是靠这个来发现服务故障的？

这个做法的问题显而易见，要么容易遗漏重要的报警，要么容易遗漏导致事故的隐患。这种模式也只有天天浸淫在某个服务中的老司机能够勉强玩转，因为他们可能瞄一眼就知道每个报警的轻重，但一旦换人立马玩完。

有两种方法解决这个问题，一个是研发或直接引入一个报警降噪的事件中心。另一个是要从海量的指标和报警中抽象出北极星指标，让大家的注意力首先集中在少量的关键指标上，具体做法历史文章中有介绍 SLO新解，一种行之有效的故障处理方法

两种方法同时使用当然最好。

④ 执迷于依赖关联关系来做故障定位

这是一个长期以来被持续追求，却又收效甚微的方向。

分析起来可能的原因有二：

在现有的基础技术上，服务的关联关系获取和更新难度都很高，也缺少打通各个环节的命名规范；
这个事情可能陷入了一个悖论：服务复杂才需要这样的关联信息来做问题定位，但复杂的服务真画出关联往往是一团乱麻，而不是一颗清晰的树。而如果服务比较简单，那其实也都用不着把它的关联画出来了；
我愿意相信这个方向能有走出悖论真正开花结果的一天，但如果一个服务着急解决眼前的问题，这个方向可能一时半会还帮不上大忙。

⑤ 把宝都押在智能化上

自从AlphaGo打败李世石以来，大家就开始期待智能化能够推动运维领域的变革。但目前为止业界在AI智能运维方向上，还鲜有有说服力的案例。针对时序数据趋势的智能预测和异常检测，大概可以算是比较接近智能化的一个实现。

在服务稳定性保障上，大家期望智能化能够解决的最大问题是智能定位问题（虽然和前面的问题一样，要定位个什么结果出来大家未必想得足够明白），这个方向已有无数的尝试和努力。

但要实现智能化，一个很重要的前提是输入数据的正确性和标准化。而目前基础设施参差不齐、运维报警全凭手动配置，80%、90%的报警可能都是误报。想要在这样的基础上产生智能，大概跟要在垃圾堆里挖出矿来差不多。

我也愿意相信这个方向会迎来真正变革的一天，但短期内不能寄予过高的期望，至少不能把解决问题的重心都押在这上面。

⑥ 过于依赖个人能力

能够在故障处理中从容应对，在别人还没反应过来的时候就把故障解决了的老员工是企业的宝贝。

但问题是这个宝贝不会一直留住在一个岗位上（离职/转岗/升职/休假。。）。

不知道是不是幸存者偏差，据笔者多年的观察，一个核心技术人员的离岗，通常意味着紧接而来的一场大事故。这个准确率简直比天气预报准多了！

原因其实也很明显，这个岗位所需的各种信息、各种服务定位止损经验都存在这个员工的脑子甚至是肌肉记忆里，别人无法复制或在短时间内重建这些信息。当老员工离开时，如果这个岗位不能把他的经验留下，那很不幸，这个服务很高概率要靠一场事故来重建保障体系。

所以，有没有办法把一个老员工的经验留下，融入到这个服务里，或者让新来的人能无缝获取？

这个工作似乎很有挑战，但却很值得尝试。现在有一些产品能够预置故障处理的最佳实践，并将老司机的经验通过配置的方式沉淀到产品中，让这个经验可复制。也许智能化真正到来之前，这是更值得探索的方向。

关于快猫星云

快猫星云，一家云原生智能运维科技公司，秉承着让监控分析变简单的初心和使命，致力于打造先进的云原生监控分析平台，结合人工智能技术，提升云原生时代数字化服务的稳定性保障能力。

快猫星云团队是开源项目夜莺监控的主要贡献者、项目管理委员会核心成员。夜莺监控是一款开源云原生监控分析系统，采用 All-In-One 的设计，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力，已有众多企业选择将 Prometheus + AlertManager + Grafana 的组合方案升级为使用夜莺监控。

夜莺监控，由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。

快猫星云产品介绍

- 一分钟视频介绍： https://flashcat.cloud/videos/flashcat.mp4
- Flashcat平台PPT： https://sourl.cn/G5iZCT
- Flashcat官网：https://flashcat.cloud
- 在线体验demo： http://demo.flashcat.cloud

大家都知道SSD成本比较高，而不少用户在考虑可用性时都会选用RAID 10作阵列，这样无疑又增加了成本。然而RAID 10的可用性也并非百分百完美。为了能够平衡可用性和成本，因此最近一直在研究性价比更高的RAID 50，它提供了接近RAID 10的可用性并且接近RAID 5的成本，像是在高可用的RAID 10和低成本的RAID 5之间的取了一个平衡点。

为了能够直观了解不同RAID类型下的故障可用性，我们首先做个简单的可用性分析（以8盘RAID 10的同等容量作对比）：

RAID 50中：4块盘组成单组RAID 5，然后两组RAID 5再组成RAID 0最后得到8块盘的RAID 50

案例分析：

• 第1块盘的容错概率都是100%，可见磁盘阵列最基本的能力就是容错，然而不同级别的阵列能够提供的数据保护能力也是不同的；
• 从第2块盘开始除了RAID 6能够提供100%的故障可用性以外，其他包括RAID 10在内都不能提供完美的解决方案。同时我们可以发现RAID 5的容错能力是四者中最差的，但是要达到同样容量所需要的盘数量也是最少的，如果故障运维较为及时的话RAID 5是一个性价比较高的方案，不然在第一块盘故障后至阵列修复期间如果发生第二块盘故障就会导整个阵列故障（数据全部丢失），这就是风险所在；
• RAID 6当然是较为可靠的方案，但是它要牺牲两块盘的容量并且性能也较差（后面有性能测试说明），所以要权衡性能和可用性；
• 当然重点还是RAID 10和50：我们发现50在第二块盘故障时的可用概率和10比较接近，由于上述案例中只有两组RAID 5因此只能提供至最多两块盘的容错，如果RAID 5的组数量更多的话能够容错的盘数也将更多，且可用概率也会更高。

我们以9块盘RAID 50（3组RAID 5）为例作分析（达到相同容量的RAID 10需要12块盘）：

再以12块盘RAID 50（4组RAID 5）为例作分析（达到相同容量的RAID 10需要16块盘）：

上面对比中RAID  50已经能够容忍第3甚至第4块盘的故障，只是可用性相比RAID 10低了些，但是两者都不能达到完美的100%，所以权衡可用性和成本RAID 50还是有相当大的优势。

接下来看看性能，为了能够很好地分析性能，我们沿用了第一组对比方案的作性能分析：

 随机读分析：

• 理论上认为R10性能最好，真实测试数据显示4K、8K数据块下R5、R50、R6的性能都要优于R10；
• 当数据块增大到16K、32K时，R10的多盘优势才被逐渐体现出来。

随机写分析：

• 4K由于R50、R5由于有大量校验计算一定程度上影响了性能，但随着数据块逐渐增大，盘数量的优势也显现出来。当数据块达到和超过8K时，R50性能全面超越了R10；
• R10由于存在R1的写同步问题，因此只有4块盘在支撑并发写，随着数据块的增大，R50和R5的多盘性能优势开始发挥。

混合随机读写分析：

• 得益多盘和无校验计算，混合读写R10领先；R50其次，和R10相差27%，性能也较为接近，R5和R50性能为线性关系，R6性能最差。

顺序读分析：

• 由于不存在校验计算，顺序读性能基本上由盘的数量决定；R50和R10性能也较为接近，同盘数的R6和R50性能相当，而盘数较少的R5性能相对前三者要弱一些，符合预期。至于为何R10性能无法线性增加，主要是因为阵列卡本身的性能限制。

顺序写分析：

• 顺序写R5被优化得最好；R50由于需要同时计算两次校验因此损失了一些性能，和R10性能相当，当数据块达到512K时，多盘优势进一步体现出来了，拉开了与R10的差距；R6由于校验和计算的实现较为复杂，顺序写性能也是最差的。

再来看看这些阵列方案的性能和容错特性：

性能测试结论：

• 性能测试显示，相同容量的R50和R10性能接近：其中小块文件的随机读R50要全面好于R10，随机写4K虽然R50和R10差距在28%，但是块增大后R50要全面优于R10。顺序读写方面，R50和R10十分接近。
• 容错方面，R50接近R10：第二块盘容错率R50十分接近R10，两者相差30%。R10的优势主要是在有一定的概率提供第三、甚至第四块磁盘的容错率，但是考虑到并非100%容错，因此从容错角度来看R50虽然和R10有一些差距，但也已体现出较好的容错率，至少优于R5。而且R50搭配灵活，甚至可以指定3组R5以达到最大3块磁盘的容错；
• 成本方面，R50有很大优势：按这个配置计算R50只有R10的3/4。

总结：

RAID 50提供了接近RAID 10性能、可用性以及接近RAID 5成本的特性，具有较好的整体性价比优势，所以考虑使用RAID 50替换RAID 10把！

没有开场白，直接切主题！各位把这篇当成是报告来阅读吧：

应用IO模型：大量读线程同时访问多块SSD，请求均为4KB随机读，并且被请求的数据有一定间隔连续性；

服务器硬件配置：LSI SAS 2308直连卡 + 8块SSD

优化前应用QPS：27K

第一轮优化：读策略优化

通过 /sys/block/sdx/queue/read_ahead_kb 观察到预读大小为128KB，进一步观察iostat情况：

观察到每块SSD的rMB/s十分高，平均已经达到了250MB/s+，初步判断是由于read_ahead_kb的设置影响了应用的读效率（即预先读取了过多不必要的数据）。遂将read_ahead_kb设置为0，观察iostat情况如下：

而应用QPS却下降至25K！

分析原因：由于之前有预读功能存在，因此部分数据已经被预先读取而减轻了SSD的访问压力。将read_ahead_kb设置为0后，所有的读访问均通过随机读实现，一定程度上加重了SSD的访问压力（可以观察到之前%util大约在60~80%之间波动，而预读改成0之后%util则在80~90%之间波动）

尝试16K预读

通过IO模型了解到每次请求的数据大小为4KB，因此将read_ahead_kb设置为16KB进行尝试，结果QPS由25K猛增到34K！

观察iostat情况如下：

%util降了不少，而且通过rrqm/s可以发现出现了一部分读合并的请求，这说明优化确有成效。

此时CPU_WA也由原来的平均30%下降到20%，这说明处理器等待IO的时间减少了，进一步验证了IO优化的有效性。

第二轮优化：直连卡中断多核绑定

考虑到SSD的随机读写能力较强（通过上面的iostat可以发现），在多盘环境下每秒产生的IO请求数也已接近100K，了解到LSI SAS 2308芯片的IOPs处理极限大约在250K左右，因此判断直连卡控制芯片本身并不存在瓶颈。

其实我们担心更多的是如此大量的IO请求数必定会产生庞大数量的中断请求，如果中断请求全部落在处理器的一个核心上，可能会对单核造成较高的压力，甚至将单核压力打死。因此单核的中断请求的处理能力就有可能成为整个IO系统的瓶颈所在，于是我们通过mpstat观察每个核心上的中断数：

可以发现第二个核心中断数已经达到了十分恐怖的80K！再来观察实际的处理器核心压力情况，为了能够更加直观地了解，我们用了比较准确的i7z工具来观察：

果然不出所料，Core 1的Halt（idle）已经到了1，充分说明第二个核心确实已经满载。

那么通过观察/proc/interrupt的情况再来进一步验证我们的假设，：

我们截取了片段，可以发现mpt2sas0-misx的大部分压力都集中在了CPU 1上，并且我们发现直连卡模式是支持多队列的（注意观察irq号从107至122，mpt2sas驱动总共有16个中断号），因此我们将实际在处理中断的irq号107至118分别绑定至不同的核心上（这里就不再赘述有关多核绑定的原理，有兴趣的同学可以百度搜索以上命令的含义）：

随后我们惊奇地观察到应用的QPS由34K再次猛增至39K！

通过观察mpstat发现大量的中断被平均分散到了不同的处理器核心上：

并且CPU_WA也由平均20%下降到15%，io wait被进一步优化！

优化总结：

• 通过以上两个优化方法将应用的QPS由27K优化至39K，并且处理器的iowait由30%下降至15%，优化收效显著；
• SSD的优化要根据实际的应用IO模型和设备的理论极限值进行综合考虑，同时还要考虑到各个层面的瓶颈（包括内核、IO策略、磁盘接口速率、连接控制芯片等）。