一、前言 - 为何需要稳定性

哈啰作为一家以出行起家的公司，尤其是两轮业务已经逐渐成为影响民生的基础设施，在如此大体量业务的今天，任何一个小故障都可能影响成千上万的人，因此有必要对稳定性做重点保障。

有幸参与过哈啰整个技术体系稳定性建设的历程(踩过不少坑)，尤其是从去年底开始主导做两轮技术风险之后，对稳定性建设与之前相比有了更深的理解，因此想把其中的一些心得和经验用文字记录下来，一方面对我们以往的稳定性工作做一个回顾总结，通过思考沉淀出新的东西;另一方面是通过分享这种形式，与大家进行一些讨论反馈，得到一些新的思路。

我们计划就以往的工作内容和经验心得来写一个系列文章，会涵盖稳定性建设的方方面面，由我们技术风险团队相关同学和NOC同学一起共创完成，本文作为系列文章的开篇，主要从稳定性的概念和含义、稳定性保障常用手段、常见方法论等角度来回顾我们对稳定性工作的认识。

在开始之前，先问大家几个问题：
1、当我们在讨论稳定性的时候，我们在讲什么？
2、稳定性保障有哪些手段？
3、在哈啰稳定性中经常提到的5-5-10到底是什么意思？

二、稳定性的定义

稳定性(也称高可用 High availability)是可靠性工程中的一个概念，主要是指系统能长时间的运行在一个确定的状态：能正常处理用户请求。所以，核心概念是：让系统长时间的运行在预期状态。

关于稳定性做的好坏的评价，目前主要有三类指标，分别从 “可正常对外服务时间、数据完整性、应急处理效率” 三个维度进行评判。

1、SLA(Service-level agreement) 服务等级协议

首先我们看第一个指标，即系统可用(可以正常对外提供服务)时间，与之相对的是系统不可用(无法正常对外提供服务)时间，SLA主要用来衡量 可用时间 与 全部时间的占比，那么不可用时间要控制在多少才算做系统是高可用的，即大家日常所说的 “3个9、4个9”到底意味着什么，请看下图：

可以看到，SLA = uptime / uptime + downtime 即系统不可用时间占比全年时间，数值越高，意味着系统稳定运行时间越长。

所谓的4个9，意味着全年最多有52.56分钟的故障时间。
5个9，意味着全年最多有5.26分钟的故障时间，等等，以此类推。

举例，阿里云ECS(多地域)承诺的SLA为99.995。

2、RPO与RTO 数据完整性

RPO与RTO是 业务连续性(Business Continuity) 和 灾难恢复(Disaster Recovery) 领域内的两个重要概念，主要用来说明系统数据的完整性和抗灾难性，详细解释如下：
RPO: Recovery Point Objective 可以恢复到多久之前的数据，这个指标决定了数据会不会丢失，以及能丢多少。
RTO: Recovery Time Objective 需要多长时间来恢复，这个指标体现了出现灾难之后，数据的恢复时长。

按照SHARE-78国际标准来看，把RTO分为7个层次，从图中可以看到，层次越高容灾级别越高，数据丢失的可能性越小。

我们做的各种故障隔离的手段，从多实例部署、到阿里云多可用区、再多目前在做的异地双活、以及未来要做异地多活。本质上都是为了解决“服务连续性和灾难恢复性”的问题。终极手段是把应用部署在不同的地区，防止电力、网络、自然灾难等各种外接因素导致服务中断。

3、MTTR与MTBF 应急处理效率
很多时候，我们做了各种技术保障手段来避免发生故障，但是故障仍然无法避免，黑天鹅总是存在的，因此，在故障发生之后，如何快速的让系统恢复到可用状态，监控告警是否及时、应急手段是否完善，就需要另外两个关键的指标来衡量。

MTTR = Mean Time To Repair 平均故障恢复时间。
MTBF = Mean Time Between Failures 平均故障间隔时间。

从上图可以看到，MTTR即意味着每次出现故障之后，我们需要多少时间来让系统恢复到可用状态，这个时间越小越好

小Tip: 5-5-10 就是我们的MTTR时间的进一步拆解：故障发生之后，5分钟之内告警信息要触达到对应人员，接下来5分钟之内要定位故障原因(注:这里不是指故障根本原因，能把故障范围定位到一个比较小的范围，可以执行应急手段即算定位成功)，接下来10分钟之内要恢复核心业务的可用性(可能是通过应急预案、降级限流等）。

综上，可以看到非常重要的一点: 在故障可用性计算中，时间都是以分钟甚至以秒计的，因此，在出现故障之后，所做的每个动作都非常重要，首要目标永远是先恢复系统可用性，即使系统可能有部分业务不正常，但至少保证核心系统是可以对外服务的，然后再慢慢排查根因。

三、稳定性保障的常用手段

从前面两章可以看到，稳定性建设的首要目标提高系统可用性，因此，得出了我们稳定性建设的两个关键问题:

1、在没有故障的情况下，如何降低故障发生概率，如何提前验证某些策略是否有效的。
2、在出现故障之后，如何快速恢复系统的可用性。

按照我们对以往故障的定位经验，结合业界常用的手段，我们把核心保障手段按照不同的层次，分为以下几个部分:

最底层是文化建设，稳定性文化是一件非常重要的事情，在日常工作中，我们沉淀出各种流程规范、规章制度、稳定性军规等，让它成为我们的理论武器，用以指导研发同学在日常工作中避免犯错，以及在后续的故障追责中做到有据可依。

故障永远是无法避免的，因此，应急体系即有了存在的必要性，是否拥有良好的应急体系，决定了我们能否从容的面对故障，在故障来临的时候是一团乱麻，还是有条不紊。

上面两层的故障隔离和弹性服务是目前技术风险团队工作的重点，好的稳定性架构师，应该是一个悲观主义者，要充分考虑各种异常情况，并且反复的验证(压测、演练)，即最终让系统架构做成面向失败的设计。

四、稳定性建设的方法论

想做好稳定性建设，
1、全员参与 - 发动群众力量
稳定性建设不止是某几个部门(NOC / SRE / 技术风险等)的事情，是要研发的全部成员一起参与的，包括业务研发、业务测试、中间件、基础运维等，甚至包括产品同学，在设计需求的时候，最好也有意识的考虑一些非功能需求，例如稳定性相关设计等。

良好的稳定性建设，从需求分析阶段就开始考虑稳定性相关设计，例如某个需求是否涉及到核心系统，技术同学在设计技术方案的时候，也应该多思考一些：这个需求是否涉及到核心系统？是否会导致核心系统依赖了一些非核心系统等等。在提测之后，测试同学也可以基于稳定性来做一些非功能测试，例如接口健壮性、依赖合理性等。

2、流程闭环 - 项目研发全生命周期守护
系统的稳定性问题是可以在各个环节进行预防的，从研发同学开始分析需求，到代码交付上线，每个环节都可以基于稳定性做一些事情，例如：在技术方案评审环节，从稳定性角度对系统依赖关系、存储资源使用情况进行一些评估；在写代码的开发环节，可以提供一些静态代码分析工具，检测潜在风险和异常；在测试环节，做一些非功能测试，例如我们在推进的一个“核心(S1)系统依赖合理性验证”等；在部署环节，发布系统可以基于分批次发布，降低变更风险，以为未来要做的精细化灰度发布等；系统上线之后，必不可少的监控告警等等。

在项目研发的每个环节，都需要做很多稳定性的事情。

3、逐步沉淀 - 注重工具和机制的建设
稳定性建设涉及到不同的角色、不同的阶段，不同部门的同学背景不一样、立场(利益)不一样，这里面会有很多不确定性，因此稳定性建设要想办法消除人的不确定性，主要通过两个思路来解决这个问题：
①、多沉淀工具，优先使用工具代替人，例如巡检平台、压测平台、演练平台等等。
②、无法用工具实现的，提炼出规则，由大家共同遵守，例如我们的研发军规等等。

五、结语

综上，本文作为稳定性建设系列文章的开篇，到这里就结束了，请大家期待我们后续的系列文章，也欢迎大家就稳定性建设相关问题在留言区多交流，谢谢！

注，稳定性建设系列文章后续相关目录，敬请期待！

1. 稳定性建设系列文章1 - 大纲&方法论。

2. 稳定性建设系列文章2 - 依赖关系治理。

3. 稳定性建设系列文章3 - 全链路压测。

4. 稳定性建设系列文章4 - 故障演练。

5. 稳定性建设系列文章5 - 风险感知&治理。

6. 稳定性建设系列文章6 - NOC应急体系。

PS:如果有其他同学有兴趣一起参与系列文章共创，欢迎评论或者钉钉联系

附:参考文档
1、High availability https://en.wikipedia.org/wiki/High_availability

2、Disaster recovery and business continuity auditing

https://en.wikipedia.org/wiki/Business_continuity_planning

3、MTTR vs MTBF vs MTTF? – A Simple Guide To Failure Metrics https://limblecmms.com/blog/mttr-mtbf-mttf-guide-to-failure-metrics/

The End