“外部质量验收驱动技术债务消除”的理念：
技术债务的形成往往是由于赶进度忽略了非功能质量特性而导致的，由于内部质量的不佳（设计或代码质量不高）导致外部质量的低下。
传统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等）实现，举部分例子如下：
某系统的心跳信号的检查，通过脚本发送心跳检查访问接口的数据包，接收响应数据包，检查进程是否工作。
某系统依赖FTP服务，通过脚本模拟用户ftp登录，获取返回信息，检查是否提示正常登录。
某接口机属于集群，需要查看某个节点状态，检查执行Shell脚本：
六、业务感知可监控性设计的验收
业务感知可监控性是指业务处理过程的关键环节信息的可观测性、透明程度、信息获取的实时程度。
例如：订单流程涉及订单录入、优惠组合接口的查询、支付接口的调用等关键环节，由唯一的标识串联，还原客户的一笔完整业务交易过程，并将相关信息输出、存储、统计分析。
七、运维前移 – 业务感知可监控性需求分析与设计
为了实现端到端的统一监控，提升客户感知，在系统开发阶段，需在系统间、模块间调用时，以及业务处理过程的关键环节中输出足够的监控信息。而运维与开发、QA应该在早期就一起（DevOps）分析定义和评审系统业务感知可监控性的需求和设计。
特别是，由于目前各层级之间的调用基于服务接口或函数，没有标识调用来源的唯一性，导致一笔业务调用中的各环节无法串接成一个整体。因此，为串联业务办理过程的各个处理环节，应用软件需要输出可以用于串联前后端处理环节的标签。
目前比较火的APM工具，是从后端通过技术手段实现业务感知、用户体验、业务流串联分析，例如，借助中间件的JVM动态插桩分析，获取Java代码调用流程，往数据库提交的SQL语句，由SessionID等标签串联并还原成客户的业务调用流程。
这种方式无疑减轻了开发和运维在业务感知体系设计方面的工作量，但是不可避免地会碰到一些技术上的问题，例如某些组件的开发技术不支持，信息无法获取，导致串联断流。
所以，我建议还是要从根本上解决问题，在开发设计过程中就考虑业务感知的可监控性设计，有了这样的基础信息，后续运维自己开发统计分析平台或借组APM这类工具支撑业务感知监控，都会方便很多！
八、交付运维 – 业务感知可监控性的验收验证
交维的时候，QA和运维应该对业务感知可监控性设计对应的实现进行验证检查和确认验收。
业务感知的设计需要重点考虑节点输出和信息完整性两个方面：
节点输出
每笔业务调用的所有服务或程序均需要输出相关的监控信息，如web应用、中间件、后台服务、其他应用程序等。这样才能在运维过程中接到业务失败投诉的时候，快速定位问题原因，出现故障的位置！
信息完整性
监控输出的信息包括但不限于以下内容：可用于串联各处理环节的标签、用户号码、渠道来源、操作工号、调用时间、响应时长、成功或失败、详细报文。其中特别是业务处理失败时，要求必须输出详细的异常信息，日志内容清晰完整，辅助定位问题原因。
因此，对业务感知可监控性的验收验证也要对照需求和设计，重点检查节点输出信息的全面性，以及输出信息的完整性。
另外，对监控信息的输出性能（时效性）也要进行检查，例如：延迟时间不高于3分钟。
其次，对监控信息存储的方式也要做合规检查，例如：
监控信息支持的存储方式完整性检查（监控信息支持文件、数据库表等多种保存格式）。
监控信息存储正确性检查。
最后，还要对开启业务感知监控对系统性能影响进行验证评估。
例如：在验收测试环境或准发布环境进行两轮测试，第一次不开启业务感知监控，第二次开启，对比两次测试的性能结果，确保业务感知监控信息的输出不对系统的处理能力带来较大的影响（例如：处理能力和资源消耗损失在3%以内）
九、小结
本文从可运维性角度，结合运维前移的理念，强调需求设计阶段对非功能需求中的运维可监控性进行详细考虑的必要性，并提出交维阶段对可监控性设计和实现的验收验证方法、技术和工具的应用方法。
作者介绍 陈能技
【DBA+社群】原创专家，新炬网络首席APM架构师。
14年开发测试与质量架构经验，擅长DevOps及APM、Docker、持续集成、持续交付在企业中的落地实施。
著有《软件性能测试诊断分析与优化》、《软件自动化测试成功之道》、《深入浅出性能测试与LoadRunner实战》等书。
本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-04-12
