共计 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) 零碎依赖合理性验证”等;在部署环节,公布零碎能够基于分批次公布,升高变更危险,认为将来要做的精细化灰度公布等;零碎上线之后,必不可少的监控告警等等。
在我的项目研发的每个环节,都须要做很多稳定性的事件。
逐渐积淀 – 重视工具和机制的建设
稳定性建设波及到不同的角色、不同的阶段,不同部门的同学背景不一样、立场 (利益) 不一样,这外面会有很多不确定性,因而稳定性建设要想方法打消人的不确定性,次要通过两个思路来解决这个问题:
①多积淀工具,优先应用工具代替人,例如巡检平台、压测平台、演练平台等等。
②无奈用工具实现的,提炼出规定,由大家独特恪守,例如咱们的研发军规等等。
结语
综上,本文作为稳定性建设系列文章的开篇,到这里就完结了,请大家期待咱们后续的系列文章,也欢送大家就稳定性建设相干问题在留言区多交换。
(本文作者:孟闯)
本文系哈啰技术团队出品,未经许可,不得进行商业性转载或者应用。非商业目标转载或应用本文内容,敬请注明“内容转载自哈啰技术团队”。