去哪儿网 - 朱仕智
高级技术总监
# 稳定性治理，有哪些非常有效的大招？
全链路压测、混沌工程、质量左移 是主动预防风险最有效的三个手段
去哪儿网整个稳定性相关的工作都由我的团队负责落地实践，从个人角度来讲，我认为去哪儿历年来在质量保障上，尤其是大规模重大活动保障上，实践出来最有效的手段主要有以下三个。
第一个是全链路压测，它对电商型的系统来说是一个绕不开的话题，只要系统存在大规模的流量波动，我认为全链路压测是必须要做的工作。第二个是混沌工程，在抵御失控、避免不确定上，它是非常不错的技术手段。经过混沌工程一系列的保障措施之后，在过去的近三年里，我们再没有产生过任何由于中间件可靠性导致的故障了，这对我们来说是非常大的进步。另外，现阶段很多问题的排查定位速度也有了质的飞跃，已经从几十分钟降为3-5 分钟的水平。第三个是质量左移，质量左移让去哪儿的重大故障减少了很多。前段时间我看了一组数据，质量左移（包括一些质量稳定性保障）做完后，故障数同比已经减少了三分之二，即已降到了去年同期约33%的水准。当然，稳定性治理的动作和产出之间，最终并不一定有直接的因果性，只能说具有很强的相关性。所以，想要取得什么样的成果、计划做哪方面的投入，是需要根据企业的实际情况来评估的。
无法完全预防的故障，用AIOps来自动化分析，提高解决速度
在去哪儿的故障已经大幅减少后，我们目前正在着手提高故障处理的速度，AIOps的主动发现和智能归因我认为是性价比最高的。通过上述的三种“主动避免”形式，我们预防了大部分的故障，剩下 1/3 大多是变更型的问题，而这种变更型的问题较难预防，只能尽可能提高发现和解决速度。自动化智能分析是我们目前正在做的事。
从过去一个季度的落地效果看，利用智能分析提高主动发现率比较困难，对于没有人工设置告警的场景，只有30%左右可以通过自动分析的方式主动发现，当然这也说明了我们的分析策略还需要持续优化。但是对于已经发现问题，进行排障归因的阶段，有78%的问题是可以通过智能分析正确归因的，这主要得益于我们对大量关联数据的自动分析，涵盖了宿主机、容器、应用、中间件、事件、链路等维度。
数列科技 - 陆学慧
联合创始人兼CTO
# 稳定性治理，有哪些非常有效的大招？
十大业务流程梳理，把有限的精力投入到最核心的“20条链路”上去
在稳定性治理里，我觉得应该做的第一件事情就是梳理十大业务流程，其最主要的作用，就是把公司能够投出来的最核心的资源投到最核心的业务上去。大多数企业在稳定性上都不会投入太多的人力，那么有限的精力到底该投到哪里去？假设有5000个接口，难道都要搞吗？不可能的，只要保障核心的那20个接口不出问题即可。
当然，在一开始没有工具的情况下确实会耗点时间，但它仍然是投入产出比最高的办法。十年前阿里内部提出了几个大的技术战略，可用性是其中之一，在没有工具支撑的情况下，我们当时的做法就是大家都去梳理十大业务流程，把十大业务流程保住，剩下的链路不去投入太多精力，年底整体的可用性确实提升了很多。所以我觉得梳理十大业务流程应该是最有效的办法。
核心业务流程做全链路压测，是活动必备的大招，确保在老板关注的大节点上不出大问题
把十大业务流程梳理出来后，就可以去做全链路压测了。在具体做法和工具上，有很多成熟的经验可供参考，也有很多办法去落地。我认为把这两招做完后，再搞大型活动就基本不会有什么问题了，即老板关注的大节点上，有办法能够把控，做到心中有数，所以这一招我认为也是比较成熟的可以去落地的“大招”。
发布之前提交变更登记，抓好变更是落实稳定性规范的核心我记得 《Google SRE》那本书里面也提到过，60%的故障都是变更引起的。理论上说，变更这件事情抓得越细致，出问题的风险就越小，但考虑到投入的人力、精力和落地可行性，我认为抓好一点就够了，即做好线上变更登记（可参考阿里变更管控平台ChangeFree ）。
“不登记，负全责”，简单讲，就是规定做线上变更前，必须在系统平台中登记，并写下操作步骤以及如何验证。从技术上讲，它就是一个表单，实现起来并不复杂。对于提交变更，还可以对定责做约定，即如果没有提交变更单就发布变更，出了问题就由发布人担责；如果变更前提交了登记则无需担责。我们经常在讨论稳定性规范要如何落地，其实规则不能定太多，规则太多大概率会无法落地，我认为变更登记是落实稳定性规范非常核心的一点。 核心业务流程不依赖非核心节点，分开部署，保证十大业务流程的机器和数据独立如果以上3点落实后还有余力，我认为在架构上还有一点值得投入——核心业务流程上不能依赖非核心的节点。梳理完十大业务流程后，一定要判断链路上是否有我们认为的非核心节点，如果有，那么应该把那些节点踢出去，或者把他们剥离出来，哪怕单独部署一套机器，也就是分组，其实提供的服务都一样，但是某一组机器就只给核心业务，其他机器可以由非核心业务混用，这样就能做好隔离。以上四个办法我认为是在稳定性治理中性价比非常高的几点，如果能真正落实，我认为系统稳定性基本会有40%的提升，至少系统不会出现的大问题，也能有精力去持续优化小问题。
飞书 - 张相龙
资深研发工程师
# 稳定性治理，有哪些非常有效的大招？
新的架构和业务增加后，从技术上看，无非是前端到服务端，再到存储的调用过程，在这个过程中要做的就是如何去解决其中的稳定性问题，我认为有三点比较重要。第一，做好监控。第二，把所有的强弱依赖梳理出来。第三，对所有的强弱依赖和接口，在平台上做好 trace 跟踪、链路管理、数据分析，以及每一个节点流转上的成功率、失败率、 SLA 、PCT99 等各方面的监控和预警。你可能认为，这些动作看上去好像和业务没有关系？实际上，上线一个新的功能，它一定是接口维度的，这个接口在平台上做户口注册，接口的QPS、SLA、PCT99等数据都可以在框架层面自动上报做统计分析，同时也会随着接口调用绘制出trace路径，并跟进trace路径得到强弱依赖，这样就完成了对接口在技术层面的所有和质量&性能相关指标的管理。做好这些管理后，从问题发生，到快速发现问题并通知到相应的服务提供人，再到解决问题，就可以完美地闭环了，所以不管业务如何变化、变得多复杂，并没有太大的影响。这样稳定性的保障工作，就已经可以下沉到基建层面了。
浙江移动-蒋通通
SRE架构师
# 稳定性治理，有哪些非常有效的大招？
浙江移动在近些年的架构演进中，一方面随着云原生行业的发展，逐步完成对核心业务系统的微服务化以及容器化改造；另一方面，面对国家对国有企业开展国产化自主可控先行先试的战略要求，也在持续进行各类国产化软硬件的替换试错，包括数据库、存储、服务器、操作系统等等。因此我们在长期的踩坑过程中也沉淀了一些稳定性保障经验。
SRE参与到架构设计、入网控制、测试发布、应急抢修等各个环节，建立完整的“护航体系”
传统的研发运维边界往往处在上线交付的时间线上，而稳定性治理工作也都是作为事后的反向提升工作，需要付出大量的工程成本和重复人力投入。因此我们拓展了SRE的职责边界，将稳定性工作左移至软件生命周期的更前端，联合研发提前开展可观测性、稳定性等保障规划，建立起全局的安全生产“护航体系”。现在我们SRE团队除了常规的线上问题修复外，还会涉及上线之前的测试发布，甚至再往前涉及架构评审等的各个阶段SRE都会参加，如此可以全程参与故障的预防和控制。
在应用多活的基础上，建立覆盖业务、集群、网元的多层预案体系，提高应急团队抢修效率
架构团队现在做新的技术栈引入，或者新的架构变更等等，都有相应的架构评审或架构治理，在这种情况下，我们设了比较多规则，比如链路梳理、强弱依赖梳理、耦合点分析等等。还有更重要的是，会在多活分片的基础上看整个链路环节是否有相应的业务开关，并对每个节点做预案控制，在链路上预埋相应的预案开关，在交付到应急团队时就能根据相应的预案手段及时处理。
那么如何去评估最终的效果？核心系统架构治理后，理论上不允许再出现 G4 （浙江移动内部的故障风险等级）以上故障，即不应出现客户或者业务受审达到较强程度的故障。
构建独立的应急系统，做“多活”的备份，对核心业务做兜底保障
我们尝试构建了一个完全独立的应急系统，和所有生产平面进行解耦，不和现有生产平面处于同一个机房。比如，浙江移动的生产平面，目前是杭州+宁波两地多中心的架构，那么应急系统就在金华重新构建。同时，这个应急平面系统和生产平面系统是不一样的，在原有的多活架构中，比如杭州和宁波的机房中可能应用部署一模一样，但是在应急平面系统中，我们只保留了最低水平的服务状态。我们基于BASE理论对所有核心业务进行拆解，只把重点依赖的服务在应急系统中重新集成，并将前台受理流程极简化，而且这部分应急数据和生产的数据是不做实时同步要求的，允许有损。因为前台用户在业务受理的过程中，大多数只关心前台的业务动作是否正常。在真正面临所有生产平面不可用的极端情况下，应急系统会自动启用并引导用户进入该平面继续办理业务，而等到生产平面的能力恢复后，再自动将所有应急数据同步回生产系统保障业务数据最终一致性。
