共计 3203 个字符，预计需要花费 9 分钟才能阅读完成。
前言 – 为何须要稳定性
哈啰作为一家以出行起家的公司，尤其是两轮业务曾经逐步成为影响民生的基础设施，在如此大体量业务的明天，任何一个小故障都可能影响成千上万的人，因而有必要对稳定性做重点保障。
有幸参加过哈啰整个技术体系稳定性建设的历程(踩过不少坑)，尤其是从去年底开始主导做两轮技术危险之后，对稳定性建设与之前相比有了更深的了解，因而想把其中的一些心得和教训用文字记录下来，一方面对咱们以往的稳定性工作做一个回顾总结，通过思考积淀出新的货色; 另一方面是通过分享这种模式，与大家进行一些探讨反馈，失去一些新的思路。
咱们打算就以往的工作内容和教训心得来写一个系列文章，会涵盖稳定性建设的方方面面，由咱们技术危险团队相干同学和 NOC 同学一起共创实现，本文作为系列文章的开篇，次要从稳定性的概念和含意、稳定性保障罕用伎俩、常见方法论等角度来回顾咱们对稳定性工作的意识。
在开始之前，先问大家几个问题：
1、当咱们在探讨稳定性的时候，咱们在讲什么？
2、稳定性保障有哪些伎俩？
3、在哈啰稳定性中常常提到的 5 -5-10 到底是什么意思？
稳定性的定义
稳定性 (也称高可用 High availability) 是可靠性工程中的一个概念，次要是指零碎能长时间的运行在一个确定的状态：能失常解决用户申请。所以，外围概念是：让零碎长时间的运行在预期状态。
对于稳定性做的好坏的评估，目前次要有三类指标，别离从“可失常对外服务工夫、数据完整性、应急解决效率”三个维度进行评判。
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。
RPO 与 RTO 数据完整性
RPO 与 RTO 是 业务连续性(Business Continuity) 和 劫难复原(Disaster Recovery) 畛域内的两个重要概念，次要用来阐明零碎数据的完整性和抗灾难性，具体解释如下：
RPO: Recovery Point Objective 能够复原到多久之前的数据，这个指标决定了数据会不会失落，以及能丢多少。
RTO: Recovery Time Objective 须要多长时间来复原，这个指标体现了呈现劫难之后，数据的复原时长。
依照 SHARE-78 国际标准来看，把 RTO 分为 7 个档次，从图中能够看到，档次越高容灾级别越高，数据失落的可能性越小。
咱们做的各种故障隔离的伎俩，从多实例部署、到阿里云多可用区、再多目前在做的异地双活、以及将来要做异地多活。实质上都是为了解决“服务连续性和劫难恢复性”的问题。终极伎俩是把利用部署在不同的地区，避免电力、网络、天然劫难等各种外接因素导致服务中断。
MTTR 与 MTBF 应急解决效率
很多时候，咱们做了各种技术保障伎俩来防止产生故障，然而故障依然无奈防止，黑天鹅总是存在的，因而，在故障产生之后，如何疾速的让零碎复原到可用状态，监控告警是否及时、应急伎俩是否欠缺，就须要另外两个要害的指标来掂量。
MTTR = Mean Time To Repair 均匀故障复原工夫。
MTBF = Mean Time Between Failures 均匀故障间隔时间。
从上图能够看到，MTTR 即意味着每次呈现故障之后，咱们须要多少工夫来让零碎复原到可用状态，这个工夫越小越好
小 Tip: 5-5-10 就是咱们的 MTTR 工夫的进一步拆解：故障产生之后，5 分钟之内告警信息要触达到对应人员，接下来 5 分钟之内要定位故障起因(注: 这里不是指故障根本原因，能把故障范畴定位到一个比拟小的范畴，能够执行应急伎俩即算定位胜利)，接下来 10 分钟之内要复原外围业务的可用性(可能是通过应急预案、降级限流等）。
综上，能够看到十分重要的一点: 在故障可用性计算中，工夫都是以分钟甚至以秒计的，因而，在呈现故障之后，所做的每个动作都十分重要，首要指标永远是先复原零碎可用性，即便零碎可能有局部业务不失常，但至多保障外围零碎是能够对外服务的，而后再缓缓排查根因。
稳定性保障的罕用伎俩
从后面两章能够看到，稳定性建设的首要指标进步零碎可用性，因而，得出了咱们稳定性建设的两个关键问题:
1、在没有故障的状况下，如何升高故障产生概率，如何提前验证某些策略是否无效的。
2、在呈现故障之后，如何疾速复原零碎的可用性。
依照咱们对以往故障的定位教训，联合业界罕用的伎俩，咱们把外围保障伎俩依照不同的档次，分为以下几个局部:
最底层是文化建设，稳定性文化是一件十分重要的事件，在日常工作中，咱们积淀出各种流程标准、规章制度、稳定性军规等，让它成为咱们的实践武器，用以领导研发同学在日常工作中防止犯错，以及在后续的故障追责中做到有据可依。
故障永远是无奈防止的，因而，应急体系即有了存在的必要性，是否领有良好的应急体系，决定了咱们是否从容的面对故障，在故障降临的时候是一团乱麻，还是井井有条。
下面两层的故障隔离和弹性服务是目前技术危险团队工作的重点，好的稳定性架构师，应该是一个悲观主义者，要充分考虑各种异常情况，并且重复的验证(压测、演练)，即最终让零碎架构做成面向失败的设计。
稳定性建设的方法论
想做好稳定性建设，
全员参加 – 发动群众力量
稳定性建设不止是某几个部门 (NOC / SRE / 技术危险等) 的事件，是要研发的全副成员一起参加的，包含业务研发、业务测试、中间件、根底运维等，甚至包含产品同学，在设计需要的时候，最好也无意识的思考一些非性能需要，例如稳定性相干设计等。
良好的稳定性建设，从需要分析阶段就开始思考稳定性相干设计，例如某个需要是否波及到外围零碎，技术同学在设计技术计划的时候，也应该多思考一些：这个需要是否波及到外围零碎？是否会导致外围零碎依赖了一些非核心零碎等等。在提测之后，测试同学也能够基于稳定性来做一些非功能测试，例如接口健壮性、依赖合理性等。
流程闭环 – 我的项目研发全生命周期守护
零碎的稳定性问题是能够在各个环节进行预防的，从研发同学开始剖析需要，到代码交付上线，每个环节都能够基于稳定性做一些事件，例如：在技术计划评审环节，从稳定性角度对系统依赖关系、存储资源应用状况进行一些评估；在写代码的开发环节，能够提供一些动态代码剖析工具，检测潜在危险和异样；在测试环节，做一些非功能测试，例如咱们在推动的一个“外围 (S1) 零碎依赖合理性验证”等；在部署环节，公布零碎能够基于分批次公布，升高变更危险，认为将来要做的精细化灰度公布等；零碎上线之后，必不可少的监控告警等等。
在我的项目研发的每个环节，都须要做很多稳定性的事件。
逐渐积淀 – 重视工具和机制的建设
稳定性建设波及到不同的角色、不同的阶段，不同部门的同学背景不一样、立场 (利益) 不一样，这外面会有很多不确定性，因而稳定性建设要想方法打消人的不确定性，次要通过两个思路来解决这个问题：
①多积淀工具，优先应用工具代替人，例如巡检平台、压测平台、演练平台等等。
②无奈用工具实现的，提炼出规定，由大家独特恪守，例如咱们的研发军规等等。
结语
综上，本文作为稳定性建设系列文章的开篇，到这里就完结了，请大家期待咱们后续的系列文章，也欢送大家就稳定性建设相干问题在留言区多交换。
（本文作者：孟闯）
本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者应用。非商业目标转载或应用本文内容，敬请注明“内容转载自哈啰技术团队”。
