深入探讨运维驱动的可监控性设计

陈能技 2016-04-12 15:09:59

我在《消除技术债务？DevOps可以这么用！》这篇文章中探讨技术债务处理方法时提到了“外部质量验收驱动技术债务消除”的理念：

技术债务的形成往往是由于赶进度忽略了非功能质量特性而导致的，由于内部质量的不佳（设计或代码质量不高）导致外部质量的低下。

传统IT领域通常有上线前的验收测试，如果能够在验收测试过程中重点关注非功能需求的实现质量，则可以“由外而内”地驱动开发团队在开发过程中重视和改善软件系统的内部质量。

本文来尝试详细探讨一下怎么个“驱动”法！

运维与开发的关注点不同，运维会更多地关注非功能需求。我们从非功能需求中的“可监控性”来展开看看，运维应该如何应用DevOps思想，驱动开发改善软件系统的质量。

一、什么是可监控性？

首先我们来对可监控性作出定义：

可监控性是指系统的运行状态、运行关键信息、业务调用过程的透明化程度，信息的可获取、可输出、可转存储程度。

系统的可监控性对于运维及时有效地进行故障定位、对于QA和开发进行缺陷定位及调试都至关重要，因此属于DevOps技术领域的核心实践范畴。

设备、应用在上线以后，不仅要新增监控点，也要调整现有的相关监控。在系统的运行过程中，同样要对运行的关键信息，特别是业务调用过程加以监控，否则会造成系统故障无法预警，也难以定位问题原因。例如，由于新增进程但是没有增加监控，导致进程僵死却浑然不觉；或者由于没有针对系统积压量的监控而导致数据大量积压却没有及时处理；或者由于关键环节没有输出监控信息从而影响客户感知。

因此，可监控性可以从“上线变更监控”、“系统运行监控”和“业务感知监控”这三方面进行规范。

二、监控的变更控制

现在一般稍具规模的系统运维都配备了各种各样的监控工具，尤其是针对基础设施（例如：主机、中间件、数据库等层面）的监控，开源的Nagios、Zabbix等都实现了不错的监控功能，新炬也有AMP这类自动化运维平台支持广泛类型的监控。

然而，随着系统的不断上线变更，在缺乏有效实施DevOps规范流程的企业中，往往出现设备、应用在上线变更时没有明确相关的改动点，运维侧没有及时部署和调整监控的情况。例如，新增了某些设备、新开启了某个端口、新加了某个应用进程等，而运维缺乏详细的变更清单，导致忽略了监控的调整，后续生产出故障也无法及时定位到。

那么监控的变更控制如何有效实施呢？我认为应该把监控也纳入配置管理进行维护，从管理流程上进行优化：交维时开发需要提交完整的设备、应用监控变更清单；QA和运维需要组织资源进行检查验证和确认，包括变更点的确认检查、新旧监控点的差异对比，确保每个监控点有对应的监控说明（监控脚本或监控工具配置），确保每个监控点的有对应的监控信息输出。

纳入监控配置管理的应该包括但不仅限于：

DNS域名清单：应用、域名、VIP地址、设备端口、IP地址。

WEB与APP调用关系清单：模块、WEB实例名称、APP集群组名称。

进程清单：进程类型、进程描述、归属子系统、主机名、IP、主机用户、应用部署目录、日志目录、监控脚本、启动脚本、停止脚本。

接口清单：接口类型、进程描述、进程编码、归属子系统、主机名、IP、主机用户、应用部署目录、启动脚本、停止脚本、日志目录、端口。

三、系统运行可监控性设计的验收

系统运行的可监控性是指系统运行状态、业务运行信息、系统健康信息的可观测性、透明程度、信息获取的实时程度。

例如：系统定时发出心跳信号，用于判断进程是否仍在工作。

为了实时监控系统的状态，保证系统健康运行，系统在开发阶段，需输出系统的运行数据，或提供相关的访问接口，便于维护采集观测。而运维与开发、QA应该在早期就一起（DevOps）分析定义和评审系统运行可监控性的需求和设计。

四、运维前移 – 系统运行可监控性需求分析与设计

在需求阶段就应该作出系统运行可监控性的要求（运维前移），否则会造成以下问题：

1、如果需求没有明确需要包含哪些可监控性的要求，那么设计开发人员就不会在实现系统时加入可监控性的设计以及监控访问接口的实现。例如，业务积压量的记录和统计，这样的话，后续运维过程中，一旦发生大量的业务积压量，运维收到投诉，前端用户访问缓慢、业务无法处理，但是也无从知道是否是业务积压，积压量有多少，故障范围无法精确定位，瓶颈无法快速查找！

2、运营人员需要的业务处理量信息，例如，业务访问量、高峰访问量、业务分类统计等信息，也无法便捷地获取到，对运营分析不利；另外，QA或测试人员如果想做业务性能建模、业务等级划分等工作也没有精确的参考数据。

3、无法真正做到开发运维一体化，系统运维缺乏实时透明化的数据（对开发人员有意义的数据），例如系统出错监控信息缺乏，导致开发无法及时响应故障诊断分析和处理；而反过来说，这些数据的缺失，其实是因为需求、设计阶段就没有考虑进去！

五、交付运维 – 系统运行可监控性的验收验证

交维的时候，QA和运维应该对系统运行可监控性设计对应的实现进行验证检查和确认验收。系统运行的可监控性验证应该包括但不限于以下内容：

心跳信号：系统定时发出简单的消息（数据包），用于判断进程是否仍然在工作。

登录量：系统记录客户端的登录信息，包括登录账号、登录时间、IP地址等，用于统计用户数。

处理量：系统记录业务处理信息，包括业务类型、发生时间、处理时间、处理账号、进程编号等，用于统计已经处理的笔数。

积压量：系统记录等待处理信息，包括业务类型、发生时间等，用于统计等待处理的笔数。

错误量：系统记录业务处理失败信息，包括业务类型、发生时间、报错时间等，用于统计处理失败的笔数。

我们可以把它们大致分成几类：

运行状态类：例如，心跳信号等。

业务运行信息类：例如，登录量、处理量、积压量等。

系统健康状态类：错误量等。

那么，检查验收的具体方法呢？我觉得主要从完整性和有效性两方面来检查验收：

通过对照需求、设计对系统运行可监控性的要求，对监控点的完整性进行检查，例如，如果对系统的业务运行信息有监控要求，那么就看具体的要求有哪些，逐一对照系统实际的监控输出，看该有的监控信息是否都有，这个可以通过QA或测试进行冒烟测试、主业务流程的测试的同时，对日志文件、监控接口访问、数据记录表等监控信息输出位置进行检查。

对于某些可监控性的检查，例如系统健康状态类，需要注意检查其有效性，通过在验收测试环境或准发布环境中模拟错误的出现，例如网络故障、进程故障等，触发业务处理失败，查看相关监控点的输出有效性，确保业务类型、错误发生时间等关键信息得以保存、方便统计分析。

对于某些检查验证，尽量形成自动化脚本（例如Shell脚本、Python脚本等），或借助自动化工具（例如soapUI、Selenium、RobotFramework等）实现，举部分例子如下：