摘要
在当今数字化转型步伐不断加快的时代，IT应用系统的稳定运行成为了企业的业务正常运转的重要基础，因此，运维管理体系的构建也从围绕着数据中心转向围绕着应用系统方向，首个专门面向应用运维的理论体系——SRE，由Google发布后，受到了越来越多的企业的青睐，很多国内企业已经纷纷效仿Google建立SRE团队，旨在为各个业务应用系统提供更好的稳定性保障能力，为业务保驾护航。
企业转型与快速发展带来的业务异构化必然导致了IT环境的多样化异构化，在不同业务架构和应用架构下，IT践行SRE理念、建设一个先进的稳定性平台也必然是一个循序渐进的过程，本文主要参考SRE中的部分核心理论，从运维标准化和技术工具层面阐述如何建设稳定性能力。
关于SRE和稳定性
SRE的理论很多人都已经比较熟悉，最早是Google的一本书《Site Reliability Engineering: How Google Runs Production Systems》分享了他们如何构建、部署和运维监控他们庞大的软件系统。
SRE提出的目标：
只要是软件，就可能存在bug或者各种运行上的问题。而SRE就是聚焦于的软件系统的稳定性运行。
SRE提出的管理体系：
SRE提出了要有服务质量目标（SLO）、on-call轮值、变更和事故管理、故障复盘、应急响应机制等一系列的管理手段。
SRE提出的组织体系：
SRE强调以软件工程的方式来解决这些稳定性问题，SRE团队中所有的人都具有软件开发能力，其中50% ~ 60%是纯软件工程师，40% ~ 50%既具备软件开发技能，又具备运维技术（PS：如果运维能有这样的人员配比，感觉“永不宕机”指日可待）。
SRE提出的技术体系：
人员能力目标太难达到，我们还是从“事”的角度出发吧。Google认为SRE的职责在于负责软件系统的可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理相关的工作。
前面提到，在企业IT环境异构化的情况下，稳定性能力建设绝不是一个简单的话题，它需要标准化、流程化、数据化，需要将ITOM的配置、监控、自动化、流程等能力融合，需要我们结合多年的运维经验和不断涌现的各种运维技术来逐步构建、升华。
稳定性能力建设的基础
首先，标准化先行。
运维界现在在大谈AIOps，但我们知道，除了关键的AI算法能力外，有质量的数据也是AI的基础。对于运维来说也是如此，高质量的运维数据是AIOps落地的基础，高质量的运维数据不会凭空出现，需要IT标准化。同样，稳定性的践行，要求我们实现一定程度的标准化。
对于大部分企业来说，由于处于数字化转型高速发展的阶段，并且由于历史的原因，业务应用架构短期内很难以实现标准化，异构化一定是一种常态，那运维在标准化诉求面前是否就束手无策了呢，其实未必，我们仍然可以找到另一条标准化的道路，就是把我们的运维基础能力抽象、标准化，来适配各种不同的业务架构。
01 CMDB标准化
CMDB标准化有以下两个基本原则：
以应用为中心建设CMDB，并且标准应用部署拓扑模型，如业务-环境-子系统-集群-模块（参考下图），让其能支撑传统、分布式、云原生等各种应用架构。
从配置消费（发布、监控、自动化等）角度出发，在CMDB中标准化应用系统及其相关资源的模型信息，如应用进程、API、网站、应用调用关系，应用关联的数据库，容器工作负载、容器集群和命名空间配置模型等等（参考下图）
除了上述两点之外，在运维新时代，要做好一个CMDB，不仅仅是工具，还需要配套的标准规范、组织、流程，这里不进行一一赘述，有兴趣的同学可以翻阅过往的文章：
【深度好文】回归本质，重新认识CMDB ——CMDB项目建设思考
02 监控标准化
在以业务系统稳定性为目标的前提下，我们对监控提出了新的要求：
监控对象标准化
监控系统需要与以应用为中心的CMDB打通，监控系统中的监控对象来自于CMDB中标准化管理的应用资源对象，从而具备以应用视角的监控展现和分析能力。
监控指标标准化
每个应用系统所提供的业务功能各不相同，应用系统的架构和资源组成也多种多样，但我们仍可以需要从各个层次、各个维度来抽象出一套相对通用的应用系统可观测性指标（见下图）。
03 能力标准化
经过抽象之后，自动化运维的底层能力主要包括以下几种：
命令通道能力
提供基于os之上的各种命令执行通道，如shell、bat、perl、sql等等。
文件通道能力
提供快速的文件传输能力。
数据通道能力
提供标准的数据采集框架支持各种类型数据采集，如日志、系统性能、数据库、脚本和自定义协议采集等。
API通道能力
提供统一的API Gateway来管理和对接各个业务系统或运维系统的接口。
持续拓展能力
其他自定义协议对接。
04 运维场景标准化
要实现稳定性的目标，还需要不断积累各种标准化运维场景能力，如故障分析场景、故障自愈场景、应急处置场景。
其次，标准化之后，我们还需要考虑流程化，比如CMDB的配置入库流程，监控告警的处理闭环流程，发布变更流程，故障处理流程、故障复盘及知识库沉淀的流程等等。
最后，数据化则是稳定性践行的关键基础，举个故障分析定位的例子，一个故障可能是配置变更或软件版本更新导致，可能是依赖的外部服务故障导致，可能是自身的数据库、进程或代码运行问题导致，定位问题的过程，一定要能够整合这些配置、流程、监控等数据，才能实现一定程度的故障分析定位自动化。这里额外提一下，在当前企业架构多样化的情况下，基于AI的告警收敛和关联，只是故障分析中的一个能力组成，而不是理想主义者所期望的，基于AI去分析海量告警信息就能直接实现根因定位。
如何建设稳定性平台
基于SRE的理论，应用运维应该打造自己的稳定性保障平台。“稳定性”仍然是一个比较泛的概念，因此我们可以从它的反面——“故障”来切入。
结合ITIL中事故管理和问题管理的理论，应用运维构建故障分析和处置平台能力，可以参照以下故障管理的闭环进行开展：
01 故障预防阶段
1. 需要基于标准化的CMDB和监控告警系统构建容量分析体系，以提前预测发现应用性能瓶颈，避免故障发生（见下图）
2. 积累标准化的和应用个性化的应急处置自动化预案，以便于应用在发生故障时可以快速恢复
3. 根据应用高可用架构标准，自动评估各个应用系统的架构可用性能力
4. 针对关键的业务系统，构建混沌工程来检验业务系统对故障的自动屏蔽和消除能力，并不断积累通用的混沌工具场景
02 故障发现阶段
1. 从Metric、Logging、Tracing三种方式实现应用系统的全方位监控和告警
2. 基于自动化的能力实现应用系统组件和业务功能的主动健康检查
3. 基于单指标异常检测的算法实现一定程度的故障预测能力。
03 故障分析和定位阶段
要实现故障的分析定位，首先，我们得对应用系统故障源有清晰和全面的了解。根据多个行业及客户的调研数据，应用系统的故障一般会有以下几种来源：
A、基础设施可用性问题
包括域名不可达、网络设备或主机故障、主机磁盘空间爆满、进程卡死或停止等。
B、基础设施性能问题
包括数据库、中间件、消息队列、负载均衡、操作系统等遇到性能瓶颈等。
C、应用调用链问题
由一个服务引发了另一个服务的异常。
D、代码异常问题
业务逻辑设计或代码隐藏缺陷引发的可用性或性能问题，或由于变更更新引发的应用故障。
在标准化的CMDB、监控和流程等运维体系的基础上，我们希望故障分析和定位系统，能够结合以上这些运维经验帮我们排查和定位问题：
从应用视角进行基本可用性分析
从应用视角进行基础资源问题分析
基础资源问题分析展示
从应用视角进行用户体验问题分析
从应用角度进行应用性能问题分析
应用运行日志告警展示
故障影响分析能力
基于CMDB中应用调用关系、资源关联关系提供故障传播链，展示故障上游受影响组件和下游可能的故障源组件。
容量分析能力
根据容量分析能力判断当前资源容量是否能够支撑业务访问量或交易量。
近期变更前后关键指标对比分析
获取近期变更数据，展示和对比变更前后应用系统关键的可用性和性能指标数据。并结合故障时间点进行关联分析。
故障汇总与定位看板
汇总展示关键指标告警及分析结果。
04 故障处理阶段
- 提供应用快速启停能力
- 提供灾备切换自动化能力
- 根据应用架构特征，提供快速的限流降级、服务熔断的微服务自动化运维能力
最后，在故障复盘阶段，除了分析相关的RPO/MTTR/SLA等指标，还需要通过流程等手段沉淀新故障场景到知识库中，以不断提升故障分析和处置能力。
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/144846.html