本次分享将从酷家乐面临的稳定性问题和挑战，在稳定性保障上的工作思路，建设实践，保障体系，价值经验等几个方面，与大家一起分享交流。稳定性工作是一个非常复杂的工作，希望通过这次分享交流，我们可以一起持续探索这个领域的最佳实践。

一. 问题和挑战

随着用户体量变大和系统复杂度变高，酷家乐稳定性建设难度也越来越大。从酷家乐历年故障原因类型分析中可以看到，系统功能缺陷，系统设计缺陷，流程问题占比较高，接近80%。其中包括很多历史债，以及各种新的故障类型，在业务&架构变得更复杂后，稳定性建设工作进入到了“深水区”。在经过了仔细地复盘后，我们发现了非常多的问题，集中体现在：

既然有这么多的问题和挑战，那么其他大厂是怎么做的呢？稳定性保障在很多“大厂”已经建设多年，在云原生观测，故障快速恢复&自愈，平台系统建设，智能化&移动化&数字化运营，以及完善的流程规范&度量&考核等各方面都形成了相对健全的稳定性保障体系。

而对比“大厂”，酷家乐在这些方面的建设相对落后较多。面临着业务监控建设缓慢，故障监控发现率低；快速恢复故障手段单一，恢复时间长；稳定性平台零散不成体系，缺少开发资源；流程和度量不统一，考核要求低等一系列挑战。

二.酷家乐稳定性工作思路针对这么多的问题和挑战，酷家乐的稳定性建设工作思路分别从组织管理，流程建设，数据运营&文化建设，系统&能力建设等四方面自上而下，循序渐进地做到日常工作中。

1.从组织管理出发，每年都要制定稳定性目标（比如：高P故障个数，故障平均恢复时长，高P警报个数，故障分等），从CTO到各业务线技术总监，再到研发经理&一线技术人员，自上而下的为结果负责。同时由CTO授权稳定性委员会对各业务线的稳定性工作运作进行监管和追踪，明确各角色职责，做到权责利统一。

2.完善流程规范，重新梳理和优化稳定性相关流程，确定流程负责人，明确流程指标，并进行宣讲和实践，让流程能真正运作起来。在线下跑通跑顺流程后，以流程指导系统建设，逐步将流程固化到IT系统（避免建设资源的浪费）。比如最基本的故障应急流程，谁来拉群组织应急，谁来协调资源，谁来同步信息，都要有明确的流程规范，以及IT系统支撑高效运转。关于应急流程，我会在下面再具体展开来讲。

3.从流程中提炼出核心结果指标和关键过程指标，定期自上而下的通晒稳定性目标数据，运营指标，驱动业务线改进，形成文化&氛围。比如我们会把故障分，故障恢复时长，故障监控发现率等通过周报，群内推送等方式通晒，自上而下的追踪和分析这些数据。包括做的好的业务线的一些最佳实践分享，以及定期组织一些演练比赛等等。

4.在指标数据推动各业务线同学分析改进的过程中，我们会将实践中的能力和经验沉淀到稳定性相关平台建设中。慢慢从单点突破，到由点带面，逐步形成体系能力。比如，通过故障原因分析，发现变更故障多，就重点抓变更管控系统建设，在业务高峰期，严格控制核心业务系统发布窗口等。再比如发现大家应急能力和预案不足，组织学习应急经验和实践，在提升能力的同时，也完善各种应急操作系统功能。

当然稳定性有很强的技术相关性，本次分享主要侧重点在整体体系的实践，所以会从整体角度来分享。

这四个步骤，相对直接借鉴“大厂”的体系化建设经验，搭建各种系统平台能力，会更“轻”一些，从成本上也能很好的控制。先从组织和流程能力双管齐下，通过数据运营和指标驱动，然后再逐步地完成系统和能力建设，有着先轻后重，先看效果，后建能力，低成本，重管理，抓指标的特点。

三.酷家乐稳定性建设实践

下面我们就具体展开来讲酷家乐的稳定性建设实践。
1.意识问题

首先，我们看下我们面临的第一个问题，意识问题。这里的每个问题，背后都是一个个故障，这些结论都是通过深入的故障复盘总结出来的。

线上意识薄弱

发布时和发布后，需要做业务观测，看业务表现，日志，监控，客诉反馈等。但有一次变更，发布后没有做观测，连最基本的告警报出来，都没及时处理，本来当天晚上可以及时发现解决的，硬是等到第二天早上用户批量反馈后，才开始解决。

管理不重视日常应用运维能力

研发忙于日常业务需求，针对基本的应急能力，平常不重视学习和演练。真正发生故障时，手忙脚乱，忙中出错。

比如某次故障，前端有个bug，导致请求流量翻倍，本来应该能通过限流快速解决，但错误的执行了切换集群，导致问题扩大化，本来只是打开慢，现在直接挂掉。

责任不清晰

部分同学的行为缺乏敬畏，认为出现故障很正常，修复就好了，反正也没有明确的责任要求。

比如某次故障，开发做一个线上配置变更，在没有完全搞清楚配置操作的影响范围的情况下，随意地执行了配置操作，直接导致线上所有文案类配置显示大量错误，导致各种用户投诉。

稳定性组织保障-三级责任制

针对上述问题，为了保障稳定性，各产品线、各敏捷组，都需要在OKR中背负一部分稳定性指标，并明确地将其完成度纳入绩效考核中。

稳定性建设工作需要多方配合，涉及到开发，测试，SRE，运维，监控团队，中间件团队等各个角色的协作和配合。因此，需要从组织管理的角度，思考如何更好地让相关方能在各自的领域完成工作的同时，又能高效配合，共同为结果负责。
首先，明确稳定性保障工作的主体为各业务研发团队。各业务团队研发总监，研发经理等要以身作则，与CTO自上而下一起承担稳定性结果指标，作为绩效考核的依据。在组织保障层面构建出 “总监->研发经理→应用Owner/一线研发”的三级责任制。

其次，酷家乐创造性地建设了“稳定性委员会”的横向虚拟组织，由CTO和各技术总监授权，挑选横向团队中的精英骨干组成稳定性委员会，运作稳定性日常工作。包括流程规范的制定，监管，问责，追踪各业务线稳定性工作等。

稳定性文化建设

有了组织保障之后，再配合文化意识建设等氛围的营造，往往能达到事半功倍的效果。

a.稳定性宣传针对稳定性目标和各种考核结果指标，定期通过海报，周报，月报等期刊通晒数据，以及同步最新的稳定性工作建设进展。同时，定期组织各种专项活动，比如突袭演练活动，让各业务线锻炼团队应急能力，验证服务容灾预案的合理性，提升团队应急止血速度，以及问题定位能力，选出故障应急最强战队，营造氛围。

b.稳定性培训&分享上面提到的各种应急能力和意识（怎么处理监控告警，怎么快速执行预案恢复故障），需要通过各种培训分享来推广落地，尤其是新人培训，必须要纳入到新人的入职培训体系中，并组织理论考试和实操考试（演练）。

此外，各业务线在稳定性方面做的好的方面，也要鼓励他们写出最佳实践的文档，在研发内部分享，推广到其他业务线使用。

c.稳定性奖针对做的好的同学和团队，设定稳定性奖项：从稳定性盘点，演练，应急监控，预案，复盘等事前，事中，事后各方面设置奖项，鼓励做的好的团队。

d.稳定性惩：对于违反红线等情况，实行绩效考核，以及研发内部通报批评等。

实际结果和价值
经过一段时间的治理：线上故障的平均响应时长大大降低，研发同学对警告的敏感度提升非常明显。在业务线和公司的整体应急警告处理群，都能有序的执行和运作起来。

2.流程机制问题

第二个大问题：流程机制问题。

1.流程不完善

很多流程缺失，导致很多稳定性工作变的很混乱。比如提到的数据变更类操作，在发生那次故障以前，完全没有流程和规范要求技术同学应该怎么做。除了流程缺失外，有一些流程也只是停留在文档上，出现无人维护，无人推动和无法落地等情况。没有人为流程结果负责。

比如有一次故障，做线上的批量数据更新，竟然没有按照数据变更流程去做数据的备份，出错之后无法短时间快速回滚，一堆开发花了4个小时重新修复了数据。

2.流程执行不到位

在故障应急时，各自为战，信息不通畅。比如有次故障应急，没有统一的指挥和协调，不同业务线的好几个同学大量做隔离和扩容操作，将原本负载偏高的机器再次推满，本来故障已经快恢复了，因为这些操作反而导致故障又恶化了，且恢复时间也变长了。

此外，我们的复盘流程规范对怎么做复盘做了非常明确的要求，部分开发同学在做复盘文档时出现分析不深入，改进措施无法避免再次发生等情况。比如在故障原因的分析方面，没有分析从故障引入到恢复的全部过程，而只是停留在表面上的技术原因。在原因分析不全面的情况下，制定出的改进措施可想而知效果也不会太好。导致故障的管理没有闭环。

流程建设实践----以应急流程为切入点

针对上述问题，我们整体上盘点了稳定性相关的流程规范，下面就应急流程举例说明。

线上应急作为稳定性保障的重要日常工作，应急效果的好坏直接关系到是否能快速恢复故障，以及降低故障对用户体验造成的影响。因此，在流程建设中，以线上故障应急流程为切入点，我们重点梳理和优化了该流程，打造技术支持&SRE值守&业务线值班长owner机制。让值班长owner故障应急全流程，在响应，判断，通告，拉群，升级，解决，验证等各个关键节点，以降低损失，恢复线上业务为第一优先级，做到有序高效地应急。

流程管理机制和指标建设
从应急流程切入后，由点及面的扩展相关流程建设，比如故障等级定义，监控&巡检规范，封网流程规范，发布规范，演练流程规范，变更红线规范等等一系列稳定性配套流程规范。

同时，在流程中，明确各种稳定性关键结果指标，比如故障分，故障恢复时长，故障监控发现率，故障复盘分，演练分等，以便做目标管理和考核。
在流程和指标建设中，需要特别注意以下两点：

1.每个流程都要有owner，为流程结果负责；定期更新和维护流程，并持续推动流程落地，做好监督和检查。最后，通过IT系统固化流程，做到自动或强制执行。避免流程成为摆设，无法落地。

2.稳定性关键结果指标，一定要从CTO到研发自上而下的负责，落到绩效考核结果中。

意识&流程机制建设概况
总结：针对上面提到的这些组织管理和流程能力的痛点，酷家乐进行了一系列针对性的措施。确认以稳定性委员会作为日常运营和监管的重要组织，明确各角色职责和流程规范。设立稳定性目标和各种结果指标，营造由CTO到一线研发自上而下的为稳定性结果负责的考核要求和文化氛围。以月报期刊，红黑榜，各种奖惩等手段，强化所有同学的稳定性意识。相对来说，成本适中，收效明显。

3.能力问题
第三个问题：能力问题。

能力问题，是一个较大的问题，包括告警的治理和闭环能力，应急处理和改进能力，变更管控的能力等等。

1.能力痛点-----告警治理能力
为什么要做SRE监控值守和巡检？

通过观察酷家乐的高P告警数量，发现平均每天有180+的高P告警。对研发同学来说，每天跟进和处理这么多的告警，是有一定的压力的。另一方面，也说明我们的系统处于亚健康状态，需要不断的优化和治理。

此外，很多告警&巡检发现的问题，因无人跟进或排查难度大等原因，导致有一些问题没有被彻底解决，成为线上故障的隐患。

最后，做监控值守&巡检，最主要还是为了提前&主动发现和解决问题，避免因处理不及时导致故障。

监控值守&巡检闭环
a.基于上面提到的问题，SRE和监控团队的同学，打造了一整套的监控和巡检体系。梳理监控&巡检流程规范，打造7*24小时监控值守，聚合高P疑似故障告警，推送到公司监控大群，提前发现和解决隐患，并建立警报事件跟进排查出根因&改进。

b.针对云服务器，中间件，网络，应用等系统自动每日巡检，对发现的异常，创建任务确定优先级，并指派到对应的研发负责人跟进解决。

c.每日汇总高P告警数量，重点警告概述&分析，以及线上业务量情况等，形成SRE日报，每日推送到研发大群。

d.持续跟踪创建的任务，根除告警和巡检发现的问题，并完善全链路监控系统和监控诊断定位系统。

监控和巡检发现的问题会创建相应的任务，根据优先级和任务归属，指定给对应的研发owner，并要求在规定时间解决。定期会通晒解决数据情况。

2.能力痛点-----应急能力
a.应急协同

分工不明确，不知道应急的时候应该做什么。

b.信息同步

故障期间,各个群内消息杂乱，容易漏掉关键故障进展信息。

c.复盘管理

故障复盘信息没有平台统一存放，散落在各个文档，不方便查看和回顾。

a.应急响应能力：
一键拉群&一键外呼，发送故障通告信息到公司应急群。定期更新故障通告，保障信息同步通畅。

3.能力痛点-----变更管控能力
随着业务的快速发展，系统之间的依赖耦合也越来越复杂。历年来酷家乐出现了多次因为A业务的变更导致B业务线上异常而出现故障。此类问题出现，都是有一方做了线上变更导致另外一方异常，并且排查的时候受影响方影响，比较难在第一时间快速定位到是哪方的变更导致，尤其是涉及一些线上配置变更的问题。

经过梳理和分析酷家乐线上变更数量和相关系统，发现以下几个痛点：