方法论与技术栈双管齐下的运维可用性能力建设（一）

一、运维可用性的思考

业务的不断演进，系统的数据量不断扩大，技术栈越来越复杂，系统模块越来越多，造成信息系统中断的风险场景越来越多，中断事件的频率和种类持续增长，且有相当一部份事件会造成业务中断，可用性问题越来越严峻。

一个严重的业务可用性问题通常是多个层面上的可用性保障均失效的结果，比如：架构的高可用能力、监控能力、自动化工具能力、应急能力等，所以说运维组织的事件管理能力特别重要，应该本着“不浪费故障”的理念去深挖故障背后的问题，不断完善每个环节的不足（当然，这里不提倡追责的方式分析故障）。

可以用“海恩法则”来进一步解释可用性问题由量变向质变转变的过程：

海恩法则：一起重大的飞行安全事故背后都会有29个事故征兆，每个征兆背后又有300个事故苗头，每个苗头背后还有1000个事故隐患。由此可见，对隐患、苗头、征兆的忽略，是导致意想不到的安全事故发生的罪魁祸首。——百度百科

海恩法则强调两点：一是事故的发生是量的积累的结果；二是人自身的素质和责任心。将法则运用到运维领域，我觉得可以从技术手段与管理手段进行可用性能力建设。

其中技术手段主要是运维把控技术架构的高可用的标准化策略的生产环境准入门槛、运用数据分析及专家意见进行信息系统架构的持续优化、运维工具建设提高问题的预测或加快可用性的恢复；管理手段则主要从演练与应急方面分解。

二、运维可用性标准方法论

在梳理可用性能力建设前，我们先看看关于可用性的一些基本概念与方法论。

在方法论的研究上，我暂时还没看到一个完全针对运维的信息系统可用性的建设方法论，所以暂以BCM（业务连续性管理），以及Google src中提到的可用性的理解。

这些方法论有助于培养一个体系化的知识体系，串起运维可用性能力的知识碎片。

1可用性概念

可用性是运维组织最重要的KPI指标，在国标的可信性与服务质量电工术语中对它的解释是：在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力，它是产品可靠性、维修性和维修保障性的综合反映。——百度百科

业界通常会用N个9来体现可用性程度，计算方法是：可用性=平均故障间隔时间MTBF/(平均修复时间MTTR +平均故障间隔时间MTBF)

用直观的数据展示如下：

在实际情况下可用性的计算会做一些局部调整：

由于系统7*24小时不停机是不太可能的情况，故通常会以名义可用性作用计划，即停业时间只考虑非计划性的情况。

由于组织资源有限，不同的维护对象的稳定性不一样，所以可用性的目标也不是一成不变，比如机房、核心网络相对稳定、且可用性问题将是全局性的，所以通常的目标是100%或6个9；重要交易系统直接面向客户，需要投入更多资源进行保障，可用性目标是5个9或4个9；一般的内部管理系统，可能是4个9或3个9。

在运维保障过程中，影响可用性的因素通常有性能问题、功能问题、设备问题、应急处理效率等，相关保障方式后续会提及。

讲完可用性的概念，我们再看看RPO与PTO的恢复能力标准。

RPO（Recovery Point Obejective，恢复点目标）是指业务系统所允许的在灾难过程中的最大数据丢失量，用来衡量容灾系统的数据冗余备份能力。

RTO（Recovery Time Objective，恢复时间目标）是指信息系统从灾难状态恢复到可运行状态所需的时间，用来衡量容灾系统的业务恢复能力。

以下是《信息安全技术信息系统灾难恢复规范》对灾备数据中心根据RPO与RTO两项指标分成了6个相应的等级：

在明确了灾备建设中灾难恢复能力等级目标之后，另一个重要问题是在具体建设中应该考虑哪些资

源要素。下表是对灾备建设的七要素：

宝企通IT服务作为智能化工单系统龙头，拥有多年优化SLA经验，能够有效提高员工对IT的服务满意度。是一款支持SAAS、本地化部署、源码交付的运维工单系统(SAAS免费试用，企业微信--工作台--添加应用，搜索“IT服务”，排名第一的就是)。目前是全网众多企业选择的工单类产品，支持手机验证码或账号验证，员工自助修改域账号密码，具备智能化派单模式工程师响应快减少员工等待时间。自定义知识库可提升工程师专业技能水平，帮助工程师迅速判断员工问题，极大提升员工报单体验。系统还能够大幅提升职能部门可以服务的用户数，有效降低专业人力成本开支，提高业务执行效率，展现工作成果。产品服务好能为用户免费开发个性化需求，连续多年被魔力象0评为leaders位置，市场占有率爆发式增长