生产运维那些事儿－监控篇

生产运维那些事儿－监控篇
原创 宫虎波 金融新观察 今天

监控能力是保证信息系统安全运行的核心能力，监控系统是系统持续服务的守护神。因此，监控体系的建设、监控能力的提升一直是生产运维工作的重点。如何建设一套适合自身企业架构的监控体系，构建一套高效、有效的企业级的生产监控平台，是各级运维管理者要面对的问题。
本文以IT生产运维工作的全生命周期为线索，在生产运维生命周期的各个阶段，从业务架构、组织架构、技术架构的角度，对监控能力、监控系统及体系建设做了分析和探讨。期冀抛砖引玉，引发读者的深入思考，结合自身企业文化、组织架构和管理要求，建起适合自身需要的监控体系。

引子

“安全生产大于天”，互联网浪潮引发的信息革命，在各行各业产生了巨大影响，信息化成为常态的背景下，信息系统的安全运行尤其重要，而作为信息系统守护者－“监控”，是重中之重。
从一般生产运维活动的全生命周期看，大致可以划分为几个阶段：
（1）持续运行阶段：系统健康状况良好，可持续对外提供服务。本阶段的核心活动是系统健康检查、系统运行指标监测。
（2）故障发生、发现及通知阶段：系统发生故障，如响应率下降、服务不可用等。在故障发生后，能够及时发现故障是一项很重要的能力，不能等到客户投诉、客服人员找上门来才发现故障，此时的系统故障面可能已扩大，业务影响已不可挽回。本阶段的核心活动是监控告警。
（3）故障定位、处置及修复阶段：确定故障发生部位；进行故障点隔离，保证故障之外的其他部分的可用性、保证业务不中断；以恢复生产为第一目标（不是先查明原因再做处置修复，而是优先考虑如何快速恢复对外服务能力），进行应急处置，有预案的按预案处置，无预案的应急团队确定应急方式后再行处置。本阶段的核心活动是应急处置。
（4）原因分析阶段：系统恢复后，对故障原因进行深入分析，确定故障的根因所在，有针对性的制定改进措施。通过故障复盘、日志分析、监控数据分析等手段进行。本阶段的核心活动是故障复盘。
（5）加改进固阶段：按照确定的改进措施，及时对系统进行升级加固，确保同类问题后续不再发生。同时，要举一反三，对其他系统类似的问题隐患进行排查、整改。本阶段的核心活动是系统加固。
下面就按照上述五阶段，从监控的角度出发，对运维活动中与监控有关的产品、技术及组织架构进行探讨。

一、持续运行阶段

系统持续运行期间，主要任务是监测系统的健康状况。系统的健康状况，可以分三个等级：
一等：系统是活着的。系统部分或全部功能是可用的。
二等：系统是正常的。系统全部功能正常，可正常对外提供各项服务。
三等：系统是健康的。系统的各项指标消耗均处于较低的水平，系统可正常对外提供服务，也有充足的余量承受更大业务量带来的压力。
从产品层面看，对系统健康状况进行监测的主要手段包括：运行指标监测、心跳监测、日志监测、系统验证、大业务量营销活动监测等。
1，指标监测
指标监测是监测的核心内容。按自上而下的顺序，指标分多个层级：
应用系统层：重点交易的成功率、响应时间、交易量等。
系统软件层：包括操作系统、数据库、中间件等，对数据库来说，一般要监测锁的数量、内存消耗、表空间、长事务等。
硬件服务器层：CPU、内存、存储空间（阵列、带库、NAS等）、虚拟主机资源、云资源等。
网络层：带宽消耗情况、交换机路由器、负载均衡设施等。
基础设施层：空调、机房环境、电力、安防等。
对于这些监测指标，要关注如下几个点：
（A）指标基线：即指标的正常值，如：某交易的响应时间为5ms为正常值。正常值的取得，一般是依据系统实际运行数据总结出来的经验值。但在实践中用经验值的方法存在不少弊端：
总结经验值所依据的数据样本不充分，设立的指标基线设置不科学；受临时业务运营促销等业务量变化的影响，如：某项业务促销期间，相关交易的交易量会较一般值大幅增长；受工作日与非工作日、日间与夜间等指标值差异的影响，如：交易量在日间明显高于夜间。
因此，需要建立动态的指标基线。在不同的日期、不同的时点，指标基线的值是不同的。建立动态指标基线，可以通过人工对日期、时间段进行细分设立，这种方式实现简单，但工作量大、精度不高，且需要随时根据业务变化进行调整。近年来，随着机器学习等AI技术的深入应用，使用机器学习的手段形成指标基线成为更准确、更高效的手段。通过机器学习，从积累的历史数据中学习该指标的变化情况，形成指标基线，并且通过不断对新产生的数据进行迭代学习，可以自动对该指标基线进行修正，适应性很强。
（B）阀值：当指标的实际运行值超过指标基线多大比例时，就认为系统可能存在异常，发出告警。如：当某交易的响应时间超过正常值30%时（即:5＋5*30%=6.5ms），认为该交易出现异常。这里的30%即是阀值。
（C）指标的组合：以单个指标的异常作为系统异常的判断依据，有时会导致误判，造成运维资源的浪费。可以设立多个指标的组合告警策略，当组合中的多个指标出现几个以上的指标告警或者组合中全部的指标出现告警时，才认为系统出现异常。这里有个度的问题，组合的指标过多或者组合不合理，也可能导致系统出现异常时未及时发出告警，带来生产风险。
2，心跳监测
心跳是确保系统是“活着”的一种验证手段。通常的实现方式，是由监测系统定期向被监测系统发送心跳报文，如果被监测系统可正常回应心跳报文，表明系统是“活着”的。心跳监测机制只能保证系统是活着的，并不能保证相关服务一定是可用的。
3，自动验证
自动验证也是检验系统是否正常的一种手段。从验证的颗粒度看，可将验证分为两类：一是分区级验证，目前的系统多为集群架构，应用部署于多台服务器或分区，分区级验证可以检验某个分区的可用性。二是交易级验证，将整个系统视为黑盒，通过调用某个验证交易，验证整个系统的可用性。
分区验证容易理解，这里重点谈一下交易验证。首先，需要定制适当的验证交易。定制验证交易的原则：一是尽量不要使用真正的生产交易，可能造成生产用户密码、真实交易报文结构的泄露，也容易对生产上该支交易的正常运行造成影响；二是验证交易尽量是查询性的功能；三是验证交易应尽量覆盖真正交易的全部链路，当前系统架构极为复杂，包括各种渠道、前置、中台、后台、与其他系统间接口调用等，验证交易应尽量保证与真实交易的路径相同。
验证交易定制完成后，一个用途是可以在收到疑似故障的告警时进行系统可用性验证，另一个用途是可以在监控平台定期（如：每间隔10分钟）调度该交易，以验证系统的可用性。在验证交易符合上述定制原则的情况下，只要验证交易成功，系统基本可以确认是正常的。自动验证是辅助检验系统健壮性的重要手段。
4，日志监测
对错误码出现频次的监测，有助于及早发现系统运行过程中的异常。有些系统出现异常的初期，在成功率、响应时间等指标上体现并不明显，但可能某种错误码出现的频次明显上升。通过实时/准实时获取系统运行日志，实时分析，可以及时发现这种错误码或者某种特征字符串出现频度的异常，提前发现系统中可能存在的问题。这种分析往往要依赖于实时流计算等计算加工能力。
5，大业务量营销活动联动
业务营销活动往往是导致交易量剧烈变化的主要原因，而交易量的剧烈变化，是导致系统运行不稳定的因素之一。因此，应建立业技联动机制，在进行可能导致大交易量的业务营销活动前，业务部门应向科技部门报备，科技部门应评估当前系统的处理能力、容量等，根据业务量变化提前进行扩容。

从技术架构层面，重点对指标监测和日志监测做一下分析：
1，指标监测
一种实现方式，是可以使用被监测系统“直连”监控平台的方式，采集并加工相应指标，发往监控平台。在监控平台通过规则引擎定制告警规则，当指标超出阀值时调用短信、邮件等接口发出告警。这种实现方式是侵入式的，需要被监测系统做修改，且采集指标是有性能损耗的，在一个成熟的IT组织内推行这一方式，是需要一定代价的。另外一种实现方式，则是基于所谓的“旁路”技术，从网络交换机以旁路的方式获取全量原始交易报文（如IP报文），通过对报文解密、解析，还原出可识别的应用交易报文，再根据拆解的报文进行指标加工。这种方式的优点是被监测系统是无感的，不需要被监测系统做任何修改。但缺点也同样存在：一是需要对各系统的报文结构、通讯协议、加密解密方式准确掌握，才能对报文进行有效解析；二是解析报文消耗极高，需要很大的算力支撑。
2，日志监测
日志监测技术相对比较成熟，分为日志的采集、处理、存储和分析展示。如，可以采用时下比较成熟的ELK框架实现。用FileBeats采集日志数据，通过LogStash收集各数据源的日志数据并发送至ElasticSearch，通过ES检索分析日志，通过Kibana可视化展示分析结果等。在日志监测方面，要关注的点有：一是FileBeats工作在产生日志的应用系统所在的服务器，要有合理的管控机制，避免消耗应用系统所在服务器过多的资源，喧宾夺主。二是要有统一的标准化日志格式，各应用系统应按照统一格式记录日志，降低日志处理的复杂度。三是日志的接收侧要有缓冲机制，如：用Kafaka实现缓冲，避免日志处理能力不足情况下，日志数据流产生堵塞。四是日志文件的脱敏问题。日志文件中记录了若干敏感的数据。在进行日志监测时，应对日志中并不使用的敏感字段进行脱敏处理，避免产生信息泄露的风险。
组织架构层面，在应用系统持续运行期间，通常是按一线（生产运维人员）、二线（开发人员）、三线（如厂商等）组织生产运维活动。一般生产事件，由一线生产运维人员实施，当遇到一线人员无法解决的问题时升级到二线解决。一线生产运维人员，一般还包括应用系统运维人员、系统软件运维人员、硬件运维人员、网络基础设施运维人员等。

二、故障的发生、发现及通知

通过系统监测发现故障，是最好、最及时的方式。如果系统有故障未及时监测到，通过客户投诉、外部监管部门告知等方式得知故障，说明系统的监控手段失效，需要立即着手整改。在故障发现及通知环节，需要关注的点有：
(A)告警压制与防抖动机制：当某个单位时间内，同一类超过阀值的情况累计出现一定次数时，才发出告警。这一措施，是为降低无效告警采取的，系统运行过程中，受多种因素影响，不可避免的出现一些抖动或毛刺，其实系统并无异常。
(B)告警通知的分级机制：对告警应该区分轻重缓急，建立分级管理机制。可将告警分为严重、重要、一般、轻微几个等级，不同等级的告警，报告的层级、采取的处置手段都可以不同。如：我们认为某交易的响应时间超过阀值，并不是一个严重事件，只要还可以正常响应即可，此时，可将该交易的响应时间设置为一般告警，此告警只发送到该系统的运维负责人和研发人员，提醒他们关注这一现象，并不上升报告层级，也不需应急处置。再如：我们认为某交易的成功率必须大于99%，此时，一旦出现交易成功率低于阀值，应发出严重告警，必须立即组织应急处置。这种分级的策略，要适应各公司的组织架构和管理要求，其目的是为了用尽量少的运维资源来保证系统的正常运行。
（C）告警的认领与关闭机制：当系统发出告警后，应设立明确的认领路由表。5分钟内第一认领责任人应认领该告警，如超时无人认领，则应按照路由表升级至该责任人的上级。引发告警的故障得到处置、系统恢复后，该责任人还应及关闭时告警。设立这一规则的目的，是确保告警发出后，是有确定的责任人接收处置的，要避免出现三个和尚没水吃的局面。
（D）告警的回调与自愈：当告警被确认，通过短信、邮件、电话等发出告警，这是最一般也是最简单粗暴的处理方式，将系统的异常情况通知到人，由人介入做判断处置。在某些情况下，还有其他更优级的选择：脚本回调或自愈，当某种特定的告警发生时，可以自动回调预设的脚本，例如：检测到某个进程异常退出，此时可以自动化的对进程进行重启操作。
（E）告警的屏蔽：在实施系统投产变更期间，系统中止服务是正常现象。在此情况下，应提前将相应告警进行屏蔽，避免变更实施期间发出无意义的告警。
（F）告警的过滤：当某个系统功能或服务持续异常，应设置相同告警的最大报警次数限制。如：采取逐步拉长告警时间间隔的策略，对于相同告警，从初次告警发出到最后，按照5分钟（第2次告警）、15分钟（第3次告警）、半小时（第4次告警）、一小时（第5次及后续告警）的间隔设置。
（G)告警的有效性评价：告警的代价是高昂的，无效的告警会带来徒劳的运维成本上升。为提高告警的有效性，除去合理设置告警阀值、预估指标基线之外，还应建立告警有效性的回顾评价机制.对于每一个告警，都应在关闭告警的同时，对该告警的有效性进行评价。这个评价可以是量化的，例如：100是完全有效告警，0是完全无效告警，可以根据收到告警后对系统故障的确认情况做出评价。每间隔一定时间，都应输出告警有效性分析报告，对于有效性低于10%的，应强制关闭规则。对于有效性低于30%的，应强制优化规则。
（H）告警风暴与告警合并：在一些情况下，一次故障可能引发多个相关告警策略的报警，一个模块出现故障后，往往还会引发其上下游系统或模块的告警。例如：某台数据库服务器宕机，服务器层面、数据库层面、使用该数据库的应用层面、使用这些应用的关联应用层面都会触发告警。如果某一网络链路或交换机出现故障，引发的告警风暴可能更加严重。告警风暴会导致应急人员不能精确判断故障情况，很容易引发混乱，延误应急处置。因此，应建立避免告警风暴的有效机制：
（1）人工建立告警规则关联，实现告警合并：这是最简单的处理告警风暴方式，但也是最费力的。要实现告警合并，首先要将存在关联的告警规则梳理出来并设置关联关系。如上面提到的数据库服务器的例子，将数据库层面的告警规则（rule1）与使用该数据库的应用层面告警规则（rule2）建立关联关系。当监控平台在一定时间范围内（如：1分钟）收到rule1和rule2触发的告警，可以直接将两条告警合并为一条后发出。梳理这种告警规则间的关联，是费时费力的事，并且存在风险：如果将不应该合并的告警进行了合并，可能导致生产事件未及时发出告警。
（2）通过机器学习的方法为告警规则建立关联：为解决人工方式带来的问题，可以引入机器学习的手段，从历史的告警数据中进行分析，挖掘告警规则间的关联关系。例如：历史上每次A模块的rule1告警规则被触发时，B模块的rule2告警规则也经常同时被触发，当这种经常出现的机率大于80%时，我们就认为rue1和rule2是关联告警，在二者间建立告警规则关联。
在技术架构层面，需要特别关注的是通过机器学习建立告警规则间的关联关系，前面已简单涉及，此处不再展开。
组织架构层面，本阶段主要是按告警处置路由表派发告警信息，并由告警第一处置人（通常是该应用系统的运维负责人）负责跟踪、确认告警，组织对系统进行可用性验证，确认系统是否存在故障。
图片

三、故障的定位及处置
一旦确认故障真实发生，应立即组建由开发项目组人员、外部厂商技术专家、应用运维人员、系统运维人员等组成的战时应急团队。团队应设有决策人或联合决策机制，可以参考当前比较流行的SRE机制，对故障进行诊断定位、应急处置修复故障。
这里要强调两点：一是应急处置不应以查找根因作为首要目标，而应以第一时间恢复生产作为第一原则，采取多种手段，尽快恢复生产。二是强调有效应急预案的重要性。很多项目是将预案作为项目结项的规定动作来看待的，预案空洞无物，形同虚设，当出现故障后，根本无法使用。应急预案不是本文的重点，不展开讨论。
如何迅速定位故障点，是应急成功与否的关键。找到了病因，才能因病施策，确定修复方案，否则应急人员只能手足无措不知如何着手。在故障定位方面，全链路监控技术是可用的一项技术。下面就全链路监控的实现原理简要做一介绍。
随着系统架构复杂度的不断增加，一只完整的交易跨越的链条越来越长，先是渠道接入，经过前置预处理（可能是多层前置），再到后台，可能还涉及访问第三方。这个过程中，还会通过各种API接口调用访问其他系统提供的服务。随着微服务架构、组件化技术的普及应用，这种链条将越来越长、链条上节点间的关系也日趋复杂。在如此复杂的系统间调用关系面前，当系统出现故障后，如何能够迅速定位到故障点，是个难题。全链路监控技术可以较好的解决这一问题，首先定义统一的全链路监控协议、约定监控报文格式，然后在各个模块或应用内埋点（这个过程是侵入性的，要对系统进行改造），用于获取交易经过该模块时的监控数据并传送至全链路监控平台。在平台建立全链路监控数据收集、汇聚机制，用于收集交易经过各个模块时的监控报文，并根据唯一跟踪ID汇聚报文，还原交易的完整链条，可视化展示该交易流经的各个环节、在各个环节的错误情况及报文细节。
在系统出现故障后，可以将某支报错交易的交易链路进行还原，快速判断交易在链条的哪个环节出现了错误，再在该模块内进行分析，判断该模块出现相应错误的原因，从而明确故障点及故障原因，为后续故障隔离与处置恢复提供依据。
应急处置手段，一般包括隔离、限流、熔断、服务降级、按预案恢复等，本文重点讨论监控问题，关于应急处置的细节，将在后续相关专题中展开讨论。
技术架构上，对全链路监控技术略做介绍。一是需要定义统一的全链路监控报文，其中必须包括唯一全局标识某笔交易的TraceID，这一ID用于在全链路监控平台还原交易链路时，用作某笔交易的唯一标记。二是在监控的系统各模块埋点、采集交易数据并上传全链路监控平台，采集的数据中应包括TraceID，且某笔确定的交易所经过的各个环节（渠道、中台、后台等），各环节上传的埋点数据报文中，该ID是相同的；三是在全链路监控平台利用实时流计算技术，如Flink，对接收到的监控报文按照TraceID进行分组，再按照时间戳进行排序，就得到了某笔交易的完整时序调用关系图。
组织架构上，在此阶段主要涉及应急处置团队。应急处置团队应是跨专业协同的，且团队应有明确的决策机制，可迅速做出应急决策，避免决策机制不明确、互相推诿浪费应急时间。

四、原因分析及改进加固阶段

这两个阶段属于生产应急之后的善后工作，与监控之间的关系相对较少。例如，在进行根因分析时，需要分析监控数据包括全链路监控数据。在此不再赘述。
以上从监控的视角对生产运维过程进行了简要的分析探讨。IT技术的发展日新月异，新的技术特别是AI技术的发展，为更高效的生产运维提供了可能，生产运维正由工具化走向智能化，从DevOps走向AIOps。作为生产系统守护者的监控模块，应时刻关注新技术、新要求带来的新变化，不断应用新技术、实现新目标，做信息系统稳定、高效运行的守护者。