[摘要] 可用性是运维KPI或SLA中非常重要的量化指标。 在基本底线保障的基础上，从纵向角度细化和构建可用性能力建设，有利于集中力量、积累最佳实践，是一项投入产出比较高的工作。
【作者简介】彭华胜，腾讯TVP，10+年金融领域运维工作，期间负责参与运维组织、流程、工具建设，包括主要业务系统的实施以及数据中心工程项目、标准化工作流程的建立、以及平台工具系统的规划与开发、数字化转型研究与实施等，对金融领域的运维有全面的了解。 更多内容请参考个人公众号“运维之路”
1. 可用性考虑
随着业务的不断演进，系统数据量不断膨胀，技术栈越来越复杂，系统模块越来越多，导致信息中断的风险场景越来越多系统，中断的频率和类型继续下降。 并且相当一部分风暴会导致业务中断，可用性问题越来越严重。 严重的业务可用性问题一般是架构高可用、监控能力、自动化工具能力、应急响应能力等多个层面的可用性保障失败的结果。因此，运营商的风暴管理能力维护组织非常强大。 重要的是，我们应该本着“不浪费故障”的理念，深入挖掘故障背后的问题，不断建立各个环节的缺陷（其实我们并不提倡以问责的形式来分析故障） 。 “海恩定律”可以用来进一步解释可用性问题从量变到质变的过程：
海恩定律：每一次重大飞行安全事故的背后，都有29个车祸迹象，每个迹象背后都有300个车祸迹象，每个迹象背后都有1000个车祸隐患。 可见，忽视隐患、征兆、症状是突发安全事故的主要帮凶。 ——百度百科
海恩定律指出两点：一是车祸的发生是数量积累的结果；二是车祸的发生是数量积累的结果。 二是人自身的修养和责任感。 把规则运用到运维领域，我觉得可以从技术和管理手段上打造可用性能力。 其中，技术手段主要是运维控制技术框架的高可用标准化策略的生产环境准入门槛、利用数据分析和专家意见对信息系统结构的持续优化、改进问题的预测等。运维工具建设，或者可用性恢复的提升； 管理手段主要从演练和应急处置方面进行分解。
2. 可用性标准方法
在梳理可用性能力建设之前软件高可用性，我们先来了解一下关于可用性的一些基本概念和技术。 在方法论研究方面，我还没有看到一种完全针对信息系统运维可用性的构建方法论，所以暂时会使用BCM（业务连续性管理）以及googlesrc中提到的对可用性的理解存在。 这种方法论有助于培育系统的知识体系，链接运维可用性能力的知识片段。
2.1 可用性概念
可用性是运维组织最重要的KPI指标。 国家标准可靠性和服务质量钳工术语中解释为：在保证所需的外部资源的前提下，产品在规定的条件和规定的时间下。 或者说在一定时间间隔内处于能够执行指定功能的状态的能力，这是产品可靠性、可维护性和维修支持性的综合体现。 ——百度百科
业界一般用N个9来强调可用性程度。 估算方法为：可用性=平均故障间隔时间MTBF/（平均维修间隔时间MTTR+平均故障间隔时间MTBF）
直观数据如下：
实际情况下的可用性估计可能会进行一些局部调整：
在运维保障过程中，影响可用性的因素一般包括性能问题、功能问题、设备问题、应急响应效率等，后面会提到相关的保障形式。
说完可用性的概念，我们再来看看RPO和PTO的恢复能力标准。 RPO（Recovery Point Objective）是指灾难发生时业务系统允许的最大数据丢失量，用于判断容灾系统。 数据冗余备份能力，RTO（Recovery Time Objective，恢复时间目标）是指信息系统从灾难状态恢复到运行状态所需的时间，用来判断容灾系统的业务恢复能力。
以下是《信息安全技术信息系统容灾规范》根据RPO和RTO两个指标将容灾数据中心分为6个相应级别：
在明确了灾备建设中灾备能力水平的目标之后，另一个重要的问题是具体建设中应该考虑哪些资源要素。 下表是容灾建设的七要素：
2.2 业务连续性管理
从业务角度来看，信息系统运维可用性的能力建设可以转化为业务连续性管理。 业界标准的业务可用性管理是BCM。 以下是百度百科对BCM的定义：
业务连续性管理（Business Continuity Management，简称BCM）是一个全面的管理流程，它使企业能够识别潜在的危机和相关影响，并制定应对、业务和连续性恢复计划。 总体目标是提高企业的风险准备能力，以有效应对计划外的业务中断并减轻不利影响。 ——百度百科
下面是从网上下载的关于BCM的整体解决方案思路，从中我们可以看出业务连续性管理涉及到方方面面
从上图可以看出，BCM方法论是一种系统的业务连续性管理，从灾难恢复、风险管理、应急管理等维度进行分解。 许多行业都提出了相应的业务连续性管理指南：
其中，保监会2011年发布的《商业建设银行业务连续性监管指引》从多个角度规定：
上述指引是系统化、持续化的管理，超出了我目前的分析和梳理能力。 有兴趣的朋友可以找到具体的指南，研究一下BCM方法论。
2.3 Google SRE的可用性保证
对于googleSRE的理解已经在本次梳理的第一篇文章中进行了总结，下面仍然引用那篇小文章中的理解：
SRE这个术语最早来源于《Google SRE运维揭秘》一书。 全称是Site Reliability Engineering，翻译过来就是：站点可靠性工程师。 Google对SRE责任的描述是：确保网站的可用性。 为了实现这个目标，一方面他需要熟悉站点所涉及的系统和组件，同时还要关注生产运行时的状态。 因此，他需要开发和维护很多工具和系统支撑系统运行，比如手动发布系统、监控系统、日志系统、服务器资源分配和编排等。SRE是一个综合素质很高的全才。 如果把他的能力细分的话，主要有三个部分：
总体来说，BCM更侧重于管理层面的可用性能力建设理论，而Google SRE则从Google现有的共享来看，更侧重于技术层面的可用性能力建设。 两者都值得我们在可用性能力建设方面参考。 ，以下只是我所理解的可用性能力建设的一些方面的部分回顾。
3、可用性能力建设（技术手段）
在技术手段方面的可用性能力建设，我们将从运维控制的技术框架的高可用标准化策略的生产环境准入门槛入手，持续优化信息系统架构。数据分析和专家意见，以及运维工具建设的完善。 梳理预测或从三个方面推动可用性恢复。
3.1 架构可用性标准化
不同运维领域的运维人员在本地都会有很多框架可用性建设的经验，因为我接触的基础设施、网络、服务器、数据库、系统等可用性能力建设很少，所以在本章中我只针对信息系统框架的可用性进行了梳理。 梳理架构可用性的目的是从运维团队可以控制的角度，提前规范信息系统架构可用性的准入条件。 从运维团队的角度来看软件高可用性，一些小型互联网运维团队具备开发基础组件的能力。 例如，腾讯QQ团队提到，他们开发了服务术语服务模块。 应用系统开发团队基于该模块设计服务注册和消费。 ; 或者构建一个基于容器的PAAS平台，开发团队会根据PAAS平台规范等进行设计。从系统稳定性的角度来看，我认为这种运维团队完善的标准化模块需要构建在强大的研发能力运维团队和相对开放的运维开发协作环境。 从相对通用的框架可用性构建的角度来看，我们可以首先考虑以下几个方面的构建：
1）应用架构高可用
我们提到的双机备份一般有两种形式，一种是冷备份，一种是热备份。 两者的区别在于，后者的主备切换需要人工干预，而后者则不需要人工干预。 这些方法，比如windows操作系统的集群管理工具，linux操作系统的HACMP，都具备在这两台机器之间进行切换的能力。 在信息系统方面，目前的传统关系型数据库以及一些老版本的应用系统一般都采用这些双机备份的形式。 在处理双机备份时，需要重点关注主备机的实时异常检测、数据同步问题以及对备机服务的接管能力。
运维团队需要提前针对双机备份的架构要求制定标准，防止出现主机异常时无法检测、发现备机无法接收完整数据、或者需要人工复杂的操作来接管备份机的服务。 双机备份架构其实很简单，但也有一些缺点。 比如主备切换时业务不可用，需要突破单机的性能瓶颈、备份机空闲状态造成的资源浪费、备份的可用性管理等机器。 紧急情况下，备用机无法使用，所以如果可以的话，尽量减少双机备份的使用。
负载均衡和分布式架构的概念很容易混淆。 我的理解是负载均衡架构是指多个服务做一堆类似的事情，每个事情都是相互独立的； 每个部分由多个服务来完成，然后通过框架，实现多个分解的处理结果的合并。
负载均衡架构的出现主要是为了解决单个服务器设备或服务无法承受的性能需求。 因为优化单台服务器性能的成本一般要远低于多台负载服务器的纵向扩展，而且带来更灵活的扩展性，尤其是X86化、虚拟化、容器化等云技术的推广。 负载平衡架构通常需要具有负载平衡算法、运行状况检查和会话持久性的负载平衡软件或硬件，以提供架构上的可用性。 其中，常见的负载均衡算法有协程、最小连接数、最快响应时间、或者基于数据的包内容分发等； 健康检测一般是测量网络连通性、服务端口监控等； 会话持久需要一种机制来保证来自同一个用户的多个请求都由同一台服务器处理（事实上，当今的互联网公司也提出了无状态的解决方案）。
Hadoop的mapreduce、HDFS等组件是分布式架构的典型例子。 例如mapreduce的运行过程是“输入->map->reduce->输出”，其作用是缩短单个估计任务的执行时间，以提高效率。 理论上来说，分布式架构可能会因为某个节点的异常而影响业务的失败。 因此，MapReduce、HDFS等分布式架构在设计之初就考虑到了系统可能出现异常的情况。 这里这些组件的设计就考虑了异常机制。 另外，为了进一步提高可用性，减少了一些关联组件来保证可用性，比如使用yarn实现资源分配，使用ZK实现服务注册和消费。
从以上三种架构来看，一般情况下，负载均衡/分布式架构要优于双机备份架构。 至于负载均衡和分布式架构，我认为哪个更好，也只有哪个更适合具体的应用场景，所以我们在框架可用性能力的标准化建设方面可以考虑以下几点：
上述高可用架构主要针对同一数据中心内的部署架构。 如果放在多中心的角度，就会有跨中心的高可用解决方案，比如容灾环境的业务负载能力。 除了要求卸载、应用负载等要求外，还有对数据同步等能力的高要求，这里不再进一步细化。
3.2 架构优化
架构优化方案中，运维使用较多：
在一些数据量比较小的系统中，水平扩展是最快、最有效的解决方案。 但对于业务量高速扩展的应用来说，第一种方案似乎很难解决问题。 这时候就需要垂直扩展。 架构优化思路。 具体实现思路如下：
1）业务垂直拆分，面向服务：从业务角度规划服务。 服务完成后，业务就会独立出来，这样就可以定义DB的读写权限了。
对应用系统的事务类型进行梳理，将检查多写少的事务和检查少写事务多的事务分开，然后进行拆分，实现事务服务。
2）数据库读写拆分：数据库读写拆分的好处是可以将数据库分为数据库。
3）服务的逻辑分组：前面是化学分离，但硬件成本和维护成本较高，所以需要从应用层对服务进行扩展和分组。
纵向减少应用服务节点，通过负载均衡分配策略实现应用性能负载。
4）应用业务流程的优化：业务流程的改造是最根本的解决方案，去除一些花哨的业务功能，将业务流程拆分成不同的服务，或者限制业务功能的使用时间或数量等。
5）同步转异步解决方案：减少并发。 异步本身并不是什么深奥的技术，关键是哪些业务可以异步，这进一步体现了架构师的业务理解能力和综合能力。
6）限制峰值：运维人员需要知道应用程序或数据库的峰值，知道峰值后才能考虑如何限制峰值。
7）数据库监控：SQL是影响数据库性能的重要因素。 系统会对慢查询SQL进行分析，分析出的慢查询会手动发送给相关研发和DBA进行优化。
8）适度为好：平时，当流量上来后数据库性能出现麻烦时，要具体问题具体分析，不要盲目扩容、拆分、硬件升级等，首先根据具体的SQL效率和性能，结合数据库本身的情况进行分析判断，其实调整索引和SQL语句就可以解决并发量增加后的性能问题。
3.3 工具构建辅助易用性提升
前几年，运维工具体系主要从“监督、管理、控制”三个方面进行构建。 随着规模不断缩小、复杂度不断增加，运维数据平台也显得尤为重要。 详细的工具体系构建将在后续进行梳理。 本节我们首先从被动风暴集中管理场景和主动可用性分析场景的构建来看如何提升运维可用性：
1）风暴集中管理场景：
后面提到的“海恩定律”指的是出现了重大的业务可用性问题。 很可能发生过很多场风暴，这是一个量变的过程。 因此，风暴的有效管理对于应用可用性能力建设具有重要作用。 非常重要的作用。
企业业务系统要良好运行，需要保证机房环境控制、网络设施、服务器设施、系统软件、数据库、中间件、应用服务等一系列软硬件设施的稳定运行。交易和客户体验水平等与其他激励措施的稳定性密切相关。 在实际工作中，企业监控工具要好得多，因为以下两个因素：
针对以往监控工具过多的问题，构建并完善了风暴集中管理的场景工具。 该工具具有以下功能：
2）主动可用性分析场景：
基于主动运维或者基于运维数据的运营分析场景的ITOA非常值得运维团队打造，但一方面很多团队忽视了这个工作方向，另一方面因为AI是太冷了，很多团队都是基于这种ITOA的AIOps构建，直接还原为AIOps，重点关注智能算法可以应用的场景：智能监控。 其实我并不认为智能监控的场景建设好，但是我不认同直接为了智能而建设智能，忽略性能、可用性、操作性的运行分析的想法。 后续会有专门的文章进行梳理分析操作的能力建设，这里暂时不展开。
4.可用性能力建设（管理手段）
下面提到基于技术手段的可用性能力建设。 本节从演练和应急响应两个管理层面进行梳理。
4.1 应急演练
应急演练是检验、评估和改进运维组织可用性管理的重要手段。 通过模拟故障发生，发现软硬件运行环境、系统架构、系统性能、应急预案、协作沟通、人员技能等方面的缺陷，并不断完善应急响应体系。 由于缺乏持续改进应急演练的思路，实际演练工作一般都做成了为了演练而演练的过程。 例如，演练方案多年未变，演练问题屡屡出现，只注重主备切换而忽视其他问题。 可用性练习等等。 为提高演练效果，建议将应急演练作为一项专项任务，由专人不断调整演练目标，分步制定，使演习真正发挥其重要作用。
根据里面的演习目标，应急演习可以分为模拟演习和实战演习，下面简单介绍一下。
1）模拟练习
模拟演练是指在非工作时间或非生产环境中进行的演练。 此类演练分为生产环境中的常规可用性演练、针对某个项目的测试环境中的演练，或者为测试应急协调和沟通而举行的演练。 桌面练习。
(1) 日常可用性练习
系统软件运行一段时间后，会形成一些临时文件，或者一些显存碎片难以释放，所以运维机构一般会制定一些例行的死机重启维护工作。 结合这种维护操作，可以发现系统运行过程中是否进行了某些配置更改，导致应用程序故障、重启后系统性能变化等问题； 还可以练习操作系统或服务器异常不可用时应用程序的紧急恢复。 时效能力。
可以计划这种类型的练习。 可以考虑在年初制定全年演练计划，针对不同的运行硬件、操作系统、业务系统制定不同频率的崩溃维护计划。 如果崩溃是临时实施的，则在实施维护之前进行调整。 具体实施当天，一般会安排例行崩溃窗口，并在非营业时间进行。 该窗口集中安排多个团队的崩溃维护工作，有助于提高工作效率。
虽然目前大多数系统都指出了分布式部署的形式，但在实际生产环境中，仍然存在不少系统采用主备架构，或者主应用分布但部分存在误负载，因此指出主备而待机切换现在仍然有意义。
主备切换类似于数据库、单业务部署的应用系统（一个操作系统中只部署一个应用服务）。 由于架构比较简单，可以参考之前例行崩溃维护的规划方法，甚至推荐和之前例行一样。 崩溃放置在同一窗口中执行。 里面不仅有比较标准的模块，而且现实中还是有很多应用是分布式部署的，只是在故障时需要改变一些本地配置，或者一个操作系统部署了多个服务。 在这些情况下，有必要首先研究梳子。 针对这些情况，如果组织内存在一些标准化规范，比如双机热备、一个操作系统上只能部署一项服务等，就需要对整理出来的架构进行整改，纳入应急之中整改前进行演练。
(2)准生产环境演练
这种演练工作通常是为了跟进项目。 例如，需要启动一项重要变更，或者为了在测试环境中模拟验证生产环境的真实性能，运维团队会与开发、测试团队进行联合演练工作。 对于准生产环境，可以考虑选择备份机、容灾、测试，或者有的公司会有专门的准生产环境。 例如，经纪商的假期清关测试会选择部分数据保存在备份机上。
(3)桌面练习
桌面演练是指参演人员按照应急操作指南、应急协调流程等文件，利用多媒体会议等手段，对预想的演练情况进行互动讨论，推演应急决策过程。 ，并现场处理，然后制定应急预案并沟通。 协调等问题。对于桌面演练，可以考虑以提前预测的形式进行演练，或者临时通知演练参与者介入演练。 后者适合于制定计划和沟通流程，前者适合验证参与者是否理解和掌握应急流程的实施。
2）实战演练
（一）非交易期间实际切换情况
非交易期间的实际切换与上面“例行可用性练习”中的切换类似，只不过切换不是立即切换回来，生产系统需要在备份模块中运行一段时间，或全年运行。 例如单数据中心、多数据中心的双机切换或者容灾数据主备切换后的操作。 通过这样的验证，我们可以更好的发现主备机的高可用情况，并在实际操作过程中发现日常运维过程中的问题，如配置未更新、程序不同步等。
(2) 破坏性机动
破坏性演练是指在交易期间应用某个模块，或者关联系统的某个模块，在运行负载规模增大或不可用时进行的实战演练。 这样的练习在金融公司很少被提及，但在互联网公司却被提及。 例如，为了提高可用性，Netflix解决了测试环境中完全模拟真实有线环境的困难。 在测试环境中无法检测到可用性问题。 并且线上环境频繁发现微服务不完全是高可用问题，Netflix决定在线上环境进行破坏性测试。 采取的破坏性措施包括：关闭特定服务套接字、关闭特定缓存服务、关闭特定DB服务、降低网络丢包率、降低网络延迟等。
4.2 应急措施
1）最佳应急手段
最好的应急方法是提前消除潜在的故障。 您应该不断反思所准备的应急场景是否有优化的空间，并不断减少或更新这些场景。
2）制定应急预案
It is necessary to formulate a failure emergency plan in advance, but our emergency plan encounters some problems in the course of daily work:
In response to the above common problems, the emergency plan needs to do the following:
(1) Concise & concise content
Many people may think that failures can occur in various ways, so contingency plans need to cover all aspects. But in the actual fault handling process, we can find that although our emergency measures often repeat several common steps, the emergency plan must be focused. If an emergency plan can deal with 80% of the normal fault handling scenarios, then this emergency guide should be qualified. Excessive pursuit of content that affects all aspects of the application system will cause the readability of this solution to deteriorate, and eventually become a document that can be tested. The following are the contents of the application system contingency plan:
(2) Use of auxiliary tools:
Sometimes, it is necessary to use some tools or manual tools to assist in the analysis and emergency response. At this time, it is necessary to have the skills of how to use the auxiliary tools.
(3) Communication plan:
The communication plan involves the address book, including upstream and downstream systems, third-party units, business departments and other channels.
The content of the above 3 points is complete no matter what, I believe this emergency guide can solve 80% of the fault recovery work.
3) Thinking of Three Axes in Emergency
There are many fault emergency methods. Under the background of different business scenarios, different manual levels and other incentives, the emergency response methods for the same type of faults are also different. If the degree of attention to each type of emergency response is the same, such as drills, automation The focus will be lost in the investment of tools and other work, so it is recommended to pay attention to and establish in stages during the management of emergency methods. For example, among the many emergency methods, different teams also have some commonly used emergency methods, such as the "three axes" of application operation and maintenance: restart, rollback, and switch; the "three axes" of DBA: killing locks, Index and clean data. After summarizing this commonly used emergency solution, it can be targeted to build around such key pain points. In fact, pointing out the idea of three axes for emergency response does not mean not paying attention to emergency solutions that are less likely to fail. It is hoped that in the case of limited human resources, for the most commonly used emergency methods, more efforts will be made to realize manualization, and the ability to actually implement them will be strengthened through emergency drills.
The following takes service restart as an example:
(1) Pain points:
(2) Solution:
Availability is a very important quantifiable indicator in operation and maintenance KPI or SLA. On the basis of basic bottom line guarantee, the construction of usability capability is refined and constructed from a vertical perspective, which is conducive to concentrating strength and accumulating best practices , is a job with a high input-output ratio.
Original title: Enterprise IT operation and maintenance usability capacity building (technology + management means)
