运维可用性能力建设

运维可用性能力建设

2.3.1 可用性的思考

业务的不断演进，系统的数据量不断扩大，技术栈越来越复杂，系统模块越来越多，造成信息系统中断的事件的风险场景越来越多，中断事件的频率和种类持续增长，且有相当一部份事件会造成业务中断，可用性问题越来越严峻。一个严重的业务可用性问题通常是多个层面上的可用性保障均失效的结果，比如：架构的高可用能力，监控能力、自动化工具能力、应急能力等，所以说运维组织的事件管理能力特别的重要，应该本着“不浪费故障”的理念去深挖故障背后的问题，不断的完善每个环节的不足（当然，这里不提倡追责的方式分析故障）。可以用“海恩法则”来进一步解释可用性问题由量变向质变转变的过程：

海恩法则强调两点：一是事故的发生是量的积累的结果；二是人自身的素质和责任心。将法则运用到运维领域，我觉得可以从技术手段与管理手段进行可用性能力建设。其中技术手段主要是运维把控技术架构的高可用的标准化策略的生产环境准入门槛、运用数据分析及专家意见进行信息系统架构的持续优化、运维工具建设提高问题的预测或加快可用性的恢复；管理手段则主要从演练与应急方面分解。

2.3.2 可用性标准方法论

在梳理可用性能力建设前，我们先看看关于可用性的一些基本概念与方法论。在方法论的研究上，我暂时还没看到一个完全针对运维的信息系统可用性的建设方法论，所以暂以BCM（业务连续性管理），以及google src中提到的可用性的理解。这些方法论有助于培养一个体系化的知识体系，串起运维可用性能力的知识碎片。

2.3.2.1 可用性概念

业界通常会用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个相应的等级：

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

2.3.2.2 业务连续性管理

站在业务角度看，信息系统的运维可用性能力建设，可以转化为业务连续性的管理，行业里的业务可用性管理比较标准的是BCM，以下是百度百科对BCM的定义：

以下从互联网下载的一张关于BCM的整体解决思路，从中可以看出业务连续性管理涉及到方方面面，

从上图可以看出BCM的方法论是一个体系化的业务连续性管理，从灾难恢复，风险管理，应急管理等维度进行分解，其中多个行业都提出相应的业务连续性管理指引：

这其中，银监会于2011年发布的《商业银行业务连续性监管指引》在多个角度进行规定：

上述的指引是体系化的连续性管理，己超出我当前的分析梳理能力，有兴趣的同学可以找找具体的指引、BCM方法论细读。

2.3.2.3 google SRE 的可用性保障

关于google sre的理解在本次梳理第一篇中的《运维不简单》中做了一些总结，以下仍引用那篇小文中的理解：

总的来说，BCM更关注于从管理层面可用性能力建设方法论，而从GOOGLE现有的分享来看，GOOGLE SRE更关注于技术层面的可用性能力建设，两者都值得我们在可用性能力建设中借鉴，以下仅从一个局部梳理我理解的可用性能力建设一些方面。

2.3.3 可用性能力建设（技术手段）

关于技术手段方面的可用性能力建设，将从运维把控技术架构的高可用的标准化策略的生产环境准入门槛、运用数据分析及专家意见进行信息系统架构的持续优化、运维工具建设提高问题的预测或加快可用性的恢复三方面进行梳理。

2.3.3.1 架构的可用性标准化

不同运维领域的运维人员在局部都会有很多架构可用性建设的经验，由于我对基础设施、网络、服务器、数据库、系统等方面的可用性能力建设接触较少，故在本章只从信息系统架构的可用性进行梳理。梳理架构的可用性是希望以运维团队可以把控的角度，对信息系统的架构可用性的准入条件进行提前的标准化。从运维团队看，有些大型的互联网运维团队具备研发基础组件的能力，比如腾讯QQ团队提到的它们研发了服务名词服务模块，应用系统的开发团队按这个模块进行服务注册与消费的设计；或者是建立基于容器的PAAS平台，开发团队按PAAS平台规范进行设计等等。基于系统稳定性角度看，我觉得这些由运维团队建立的标准化模块需要建立在一个强大研发能力的运维团队与相对开放式的运维开发协同大环境之下。从相对比较普适的架构可用性建设看，可以考虑先从以下几方面进行建设：

1）应用架构高可用

双机备份

我们提到的双机备份通常有两种方式，一种是冷备，一种是热备，两者区别是，前者的主备切换需要人工介入，后而不需要人工介入。这种方式，像windows操作系统的群集管理工具，linux操作系统HACMP等具备这种双机切换的能力。从信息系统上，当前传统的关系型数据库，以及一些版本比较旧的应用系统通常是采用这种双机备份的方式。在处理双机备份时，需要重点关注主备机实时的异常探测，数据的同步问题，以及备机服务的接管能力。

通常来说，主备机之间会有一个心跳机制定时进行检测主机是否处理正常运行状况，比如windows的群集会主动探测主机的资源是否在线，这里的资源包括IP、服务等是否可用；数据的同步上，主要针对实时更新的数据更新，采用共享存储、将非共享存储作为一个资源在异常时加载到备机服务，或采用数据实时复制的方式；备机服务的接管则依靠切换软件在异常时执行提前准备好的切换脚本实现服务的接管；

运维团队需要针对双机备份的架构要求提前制定标准，避免主机异常时无法自主发现，发现后备机无法接管完整的数据，或备机服务接管需要人工进行复杂的操作介入等问题。双机备份架构虽然简单，但也有一些缺点，比如主备切换期间的业务不可用，需要突破单机的性能瓶，备份机闲置状态带来的资源浪费，备份机的可用性管理也经常出问题，容易出现紧急情况下备机不可用的情况，所以如果有条件尽量减少采用双机备份的方式。

集群&负载均衡 & 分布式

负载均衡与分布式的架构概念比较容易混淆，我的理解负载均衡架构是多个服务做一堆同类的事情，每件事情相互独立；分布式的架构则是将一件复杂的事情分解出多个部份，由多个服务去做，再通过架构实现多个分解事情处理结果的合并。

负载均衡的架构的出现主要是解决单一服务器设备或服务无法承担性能要求，因为通常对单机服务器性能的优化带来的成本远大于横向多台负载服务器的扩展，且带来更灵活的扩展性，尤其是X86化、虚拟化、容器化等云化技术的推动。负载均衡架构通常需要具备负载均衡算法、健康检查、会话保持的负载均衡软件或硬件来提供架构上的可用性，其中常用见负载均衡算法有轮询、最小连接数、最快响应时间，或基于数据包内容的分发；健康检查则通常是对网络连通性、服务端口监控等方式检测；会话保持则是需要有一个机制保证一个用户多次请求由同一台服务器处理（当然，现在互联网公司也提出无状态的解决思路）。

Hadoop的mapreduce、HDFS等组件是分布式架构典型的例子，比如mapreduce的运算过程即是“input - > map -> reduce -> output"，它的作用就是为了缩短单个计算任务的执行时间来提升效率，理论上讲由于分布式架构可能会影响某一个节点的异常导致这个业务的失败，所以类似于mapreduce、HDFS这类分布式架构在设计之初就考虑了系统可能是异常的情况，在这些组件的设计上考虑了异常机制，另外，为了进一步提高可用性还增加了一些关联组件来保障可用性比如运用yarn来实现资源的调配，运用ZK实现服务的注册消费等。

从上述三种架构看，正常情况下负载均衡/分布式架构优于双机备份的架构，至于负载均衡与分布式架构哪个好，我觉哪个更好，只有哪个更适合具体的应用场景，所以我们在架构的可用性能力标准化建设方面，可以考虑如下：

针对不同的业务模块的类型制定优先选用的架构部署方式作为运维准入的门槛，并提前提交应用系统开发团队。针对标准化架构，考虑建立统一的标准化组件模块，比如硬件的负载均衡模块，软件的负载均衡及分布式架构模块，标准化的PAAS层的集群管理模板，标准化的脚本等优化工作。在非功能性层面考虑高可用的保障，在非功能性层面的高可用保障，运维的人都知道开发团队很少主动考虑应用系统的非功能性功能的设计，比如让开发提供服务异常时的报警这件事情况上，我觉得运维在工具建设过程中需考虑更多一些，为开发提供事件集中处理平台的标准接口，方便开发团队将异常信息提供给运维。同样，在应用部署工具中考虑应用程序在多个节点上的应用同步机制；在监控工具层面考虑应用服务异常时的服务重启自愈等等，这些高可用保障方式需要有一定的标准化程序包的落地。

上述的高可用架构主要是针对同一数据中心内的部署架构，如果放在多中心的角度，还会有跨中心的高可用解决方案，比如灾备环境的业务负载能力，这就不仅从请求分流、应用负载等要求，对数据同步等能力也要求很高这里不再作进一步细化。

2.3.3.2架构优化

在架构优化方案中，运维用得比较多的是：

纵向扩展：加服务器资源，换性能更强的服务器提升服务能力横向扩展：增加节点，比如拆分数据库、增加负载均衡的服务节点、按地区分拆应用等方式提升服务能力

在一些数据量发展相对少，的系统中，纵向扩展是最快也是最有效的解决方案，但对于业务量高速扩张的应用第1种方案显然无法解决问题，这时候需要用到横向扩展的架构优化思路。具体的实施思路如下：

1）业务垂直拆分，服务化：从业务角度规划Service，Service化完成后，业务就独立了，这样DB读写权限可以得到划分。

梳理应用系统交易类型，把查多写少、查少写多的交易进行分离，再进行拆分，实现交易服务化。

2）数据库读写分流：数据库读写分流带来的好处是，数据库可以分库了。

在数据库中将不同的应用拆分不同的实例在数据库前面加上cache，减少对数据库的压力将查询类比较多的业务从交易数据库中拆分出来，并在此基础之上再进一步拆分查询类的数据库，拆分写的数据库，实现了读写分离（不是完全的读与分离，但是有侧重读与写，我们认为根据不同的应用需要有主与从数据库。分布式数据库，即将第3）点的主、从数据建立多个集群，分布式部署数据库。

USERID来区分，比如1000001是第一个库；2000001是第二个库，以此类推；按地区来区分，比如长江以南与长江以北的客户来分别部署数据库

3）服务逻辑分组：上面是物理上的分离，但硬件成本、维护成本高，所以需要从应用层对服务进行扩展，分组。

横向增加应用服务节点，通过负载均衡分发策略来实现应用性能负载。

4）应用业务流程的优化：业务流程的改造是最根本的解决，去掉一些花俏的业务功能，分拆业务流程到不同的服务，或限制业务功能的使用时间或数量等等。

5）同步改异步的方案：增加并发性。异步本身不是什么高深的技术，关键是哪些业务可以走异步，这更体现架构师的业务理解能力和综合能力。

6）限制峰值：运维人员需要知道一个应用或数据库的峰值是多少，知道峰值后就可以考虑如何限制峰值。

7）数据库监控：SQL是影响数据库性能的重要因素，系统会对慢查询SQL进行分析，分析后的慢查询自动发给相关研发和DBA进行优化。

8）适度才好：在平时，流量上来后数据库的性能出现瓶颈时，要具体问题具体分析，不能盲目的进行扩容、拆分、硬件升级等，先要根据具体的SQL效率、性能，结合数据库本身情况分析判定，也许调整一下索引，SQL语句做一下调整即可解决并发量上来后的性能问题。

2.3.3.3  工具建设辅助可用性能力的提升

以往讲运维工具体系，主要会从“监、管、控”三方面建设，随着规模不断增大，复杂度不断提升，从运维数据平台也尤为重要，详细的工具体系建设将在后续梳理。本节先从被动式的事件集中管理场景与主动式的可用性分析场景的建设来看看提升运维的可用性能力：

1）事件集中管理场景：

前面提到的” 海恩法则“提到一个重大的业务可用性问题的出现，很可能己发生了多次事件，是一个量变的过程，所以，事件的有效管理在应用可用性能力建设中起到一个很重要的作用。

一个企业的业务系统要运行良好，需要保证一系列的软硬件设施的稳定运行，比如机房环控、网络设施、服务器设施、系统软件、数据库、中间件、应用服务，以及交易与客户体验层面等等因素都与稳定息息相关。在现实工作中，由于以下两个因素影响导致一个企业监控工具很多：

运维涉及的领域很多，没有哪一个监控工具能够做到一篮子解决方案，往往硬件厂商擅长硬件监控，软件厂商擅长软件监控，DBA擅长数据库监控，业务运维擅长业务监控、性能分析团队擅长性能体验监控等。同类的监控也可能存在多套监控工具，一方面是由于同类监控的工具之间的功能也有优缺点差异，另一方面也有使用者的一些历史原因因素等；

基于上面监控工具多的问题，建立建立一个事件集中管理的场景工具，该工具具备以下能力：

事件汇总：数据层面汇总不同层次、不同专业条线、不同类型事件是监控集中管理的基础。可视化层面，提供统一的事件处理管理，提供多维的角色，整合应急操作工具等事件丰富的能力。事件收敛：前面提到同一个故障会触发多类指标的告警，同一个指标在故障未解除前也会重复产生大量的告警事件，如果将全部事件都展示出来，那对于监控处理人员将是灾难性的，所以需要进行事件收敛。事件分级：对于不同的事件需要有适当层次的事件分级，事件升级的策略。事件分级是将事件当前紧急程度进行标识显示，事件升级是对于低级的事件当达到一定的程度，比如处理时间过长，则需要进行升级。事件分析：事件分析是建立事件的关联关系，关联分析可以从纵向和横向关系进行分析，纵向是指从底层的基础设施、网络、服务器硬件、虚拟机/容器、操作系统、中间件、应用域、应用、交易；横向是指从当前的应用节点、上游服务器节点、下游服务器节点的交易关系。事件分析是形成故障树，自愈的基础。

以下总结的事件整合场景的图片：

2）主动式的可用性分析场景：

基于运维数据的主动式的运维或运营分析场景的ITOA特别值得运维团队去建设，不过一方面有不少团队忽略这个工作方向，另一方面由于AI太热，很多团队基于这类ITOA的建设直接被缩小为AIOps，聚焦到了智能算法可以应用的场景：智能监控。当然，我并不认为智能监控的场景建设不好，只是忽略了性能、可用性、运营等方面的运行分析，直接为了智能而智能的建设思路不太赞同。后续有专门一篇梳理运行分析的能力建设，这里暂不扩展。

2.3.4 可用性能力建设（管理手段）

前面一节提到了基于技术手段的可用性能力建设，本节从演练与应急两个管理层面进行梳理。

2.3.4.1 应急演练

应急演练是检验、评估、提高运维组织可用性管理的一个重要手段，通过模拟故障的发生，发现软硬件运行环境、系统架构、系统性能、应急预案、协作沟通、人员技能等存在的不足，并持续改进应急体系。由于缺少持续改进的应急演练的思路，实际的演练工作的开展通常变成一个为演练而演练的过程，比如演练方案长年不变、演练的问题反复出现、只重视主备切换而忽视其它的可用性演练等等。为了提高演练的成效，建议要将应急演练作为一个专项工作，有专人不断调整演练的目标，分步不断完善，让演练真正发挥其重要的作用。

针对上面的演练目标，可以将应急演练可以分为模拟演练和实战演练，以下简单介绍。

1）模拟演练

模拟演练是指在非业务时段或非生产环境进行的演练工作，这类演练又分为生产环境例行的可用性演练，为了某个项目而在测试环境进行演练，或为了检验应急协作沟通而开展的桌面演练。

（1）例行可用性演练

例行关机维护

系统软件在运行一段时间后会产生一些临时文件，或一些内存碎片无法释放等问题，所以运维组织通常会制定一些例行关机重启维护的工作。结合这类维护操作的演练可以发现系统是否在运行期间进行了一些配置修改在重启后引起了应用故障，系统性能的变化等问题；也可以演练当操作系统或服务器异常不可用时，应用应急恢复的时效能力。

关于这类演练可以做到计划性，可以考虑在年初制定全年的演练计划，针对不同的操作硬件、操作系统、业务系统分类制定不同频率的关机维护计划，如在实施前己临时实施关机维护则进行调整，在具体的实施当天通常排出一个例行关机的窗口，在非业务时断进行,这个窗口集中安排多个团队的关机维护工作，这样有助于提高工作效率。

高可用主备切换

虽然当前大部份系统都强调分布式部署的方式，但在实际的生产环境中还是有很多系统是主备架构，或主应用是分布式但局部是假负载的情况，所以强调主备切换在当前还很有意义。

主备切换中类似于数据库，或单服务部署的应用系统（一个OS中只部署一个应用服务），因为架构比较简单，可以参考上面例行关机维护的计划方式，甚至建议和上面例行关机放在同一个窗口执行。除了上面相对标准的模块，现实中还存在不少应用虽是分布式部署，但局部有些配置需要在故障期间进行修改，或一个操作系统部署了多个服务，这种情况则需要先进行摸底梳理。针对这种情况，如组织内有一些标准化的规范，比如必须热备、一个操作系统上必须只部署一个服务等，则需要将这类梳理出的架构进行整改，在整改前纳入应急演练。

（2）准生产环境演练

这类演练工作通常是跟进项目走，比如某个重要变更需要上线，或为了在测试环境模拟验证生产环境的真实的性能，运维会与开发、测试团队进行联合的演练工作。准生产环境可以考虑选择备机、灾备、测试，或一些企业会有专门的准生产环境，比如券商的周末通关测试会选择一部份数据在备机开展。

（3）桌面演练

桌面演练指参加演练的人员根据应急操作手册、应急协调流程等文档，借助多媒体会议等手段，对事先假定的演练情景进行交互式讨论、推演应急决策、现场处理的过程，从而发现应急预案、沟通协调等方面存在的问题。关于桌面演练，既可以考虑提前预知的方式开展演练，也可以考虑临时通知演练参与人介入演练。前者适合针对方案、沟通流程的完善，后者适合验证参与人是否理解并掌握应急过程的实施。

2）实战演练

（1）非交易期的实战切换

非交易期的实战切换和前面“例行可用性演练”中的切换差不多，只是切换后不马上切换回来，需要生产系统在备份模块中运行一段时间，或长期运行。比如，单数据中心内的双机切换、多数据中心或灾备数据中主的切换后的运行。通过这类验证，能更好的发现主备机的高可用，并在实战运行的过程中发现运维日常过程中存在的问题，比如配置未更新、程序未同步等。

（2）破坏性演练

破坏性演练是在交易期对应用某个模块，或关联系统的某个模块，当运行负载规模下降或不可用情况下的实战演练。这类演练在金融企业很少提及，在互联网公司中有提到，比如 ：Netflix为提高可用性能力，解决无法在测试环境完全模拟出真实的线上环境，可用性问题在测试环境测试时没法发现，但是在线上环境却频繁发现微服务并不是完全高可用的问题， Netflix 决定在线上环境进行破坏性测试。采取的破坏性措施包括：关闭特定服务接口，关闭特定缓存服务，关闭特定 DB 服务，增加网络丢包率，增大网络延迟等。

2.3.4.2应急手段

1）最好的应急手段

最好的应急手段是提前消灭潜在的故障， 应该要不断的反思己制定的应急场景是否有优化的空间，不断减少或更新这些场景。

2）做好应急预案

提前制定好故障应急方案是很有必要的，但在日常工作过程中我们的应急方案遇到一些问题：

应急方案缺乏持续维护，缺乏演练，信息不及时、不准确；应急方案过于追求大而全，导致不利于阅读与使用；应急方案形式大于实际使用效果，方案针对性不强；只关注应急方案的内容，但没有关注运维人员对方案的理解；

针对上述常见问题，应急方案需要做到以下几点：

（1）内容精&简

很多人可能会认为故障出现的形式各种各样，所以应急方案需要涉及到方方面面。但实际的故障处理过程中，我们可以发现其实我们的应急措施往往重复使用几个常用的步骤，所以应急方案要有重点，如果一个应急方案可以应对平时故障处理80%的场景，那这个应急手册应该是合格的。过于追求影响应用系统方方面面的内容，会导致这个方案可读性变差，最终变成一个应付检查的文档。以下是应用系统应急方案应该有的内容：

系统级：

能知道当前应用系统在整个交易中的角色，当前系统出现问题或上下游出现问题时，可以知道如何配合上下游分析问题，比如：上下游系统如何通讯，通讯是否有唯一的关键字等。

另外，系统级里还涉及一些基本应急操作，比如扩容、系统及网络参数调整等。

服务级：

能知道这个服务影响什么业务，服务涉及的日志、程序、配置文件在哪里，如何检查服务是否正常，如何重启服务，如何调整应用级参数等。

交易级：

能知道如何查到某支或某类交易出现了问题，是大面积、局部，还是偶发性问题，能用数据说明交易影响的情况，能定位到交易报错的信息。这里最常用的方法就是数据库查询或工具的使用。

知道最重要的交易如何检查是否正常，重要的定时任务的应急处理方案，比如开业、换日、对账的时间要求及应急措施。

（2）辅助工具的使用：

有时候，需要借助一些工具或自动化工具辅助分析并应急，这时需要有辅助工具如何使用的方法。

（3）沟通方案：

沟通方案涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。

上述3点内容如何都完备，相信这个应急手册己可以解决80%的故障恢复工作。

3）应急三把斧思路

故障应急方法很多，在不同的业务场景、不同的自动化水平等因素背景下，同类的故障的应急处理方法也不一样，如果对每一类的应急方法的重视程度都一视同仁，比如演练、自动化工具等工作的投入上就会失去重点，所以建议在应急方法的管理过程中也要有侧重的、分阶段的完善。比方说在众多的应急方法中，不同的团队也会有一些常用的应急方法，比如应用运维的“三把斧”：重启、回撤、切换；DBA的“三把斧”：杀锁、加索引、清理数据。在归纳出这些常用的应急方案后，就可以有针对性围绕这类重点的痛点进行完善。当然，强调应急三把斧的思路并不代表不用重视比较少出现故障的应急方案。是希望在人力资源有限的情况下，针对最常用的应急方法，要加大力度去实现自动化，并通过应急演练加强实际落地的能力。

以下以服务重启为例：

（1）痛点：

分布式部署，需要登录多个应用进行重启；重启过程中遗忘保存现场，增加故障后的问题根源分析；重启后检查方法复杂，效率不高且容易出错。

（2）解决方法：

针对最佳实践的重启应急的操作流程，先保存现场（比如针对JAVA服务先保存CORE），应急处理，汇总应检查的服务状态的数据。针对不同的操作系统，新建服务重启工具，工具支持重启应急的操作流程（保存现场、重启、技术检查），并与监控事件的丰富整合在一起，提高应急的效率。

可用性是运维KPI或SLA中很重要的一个可量化指标，在基本的底线保障的基础之上，将可用性能力的建设提炼出来，以横向的角度进行建设，有利于集中力量，积累最佳实践，是一项投入产出比很高的工作。