概述
在日常运维和稳定性保障中，监控是发现问题、感知业务异常、感知用户使用落差的重要手段之一。2017年双11，整体规模空前，在这期间任何一个业务问题和影响都会被放大，在保障过程中如何让问题更快速、更全面地被发现感知、响应处理、防止问题的劣化，在线上异常对用户的影响大范围扩散之前达到解决或止血就变得尤为重要。过往的双11我们的问题更多的是通过用户反馈－客服受理－各层级分拣的方式去发现，然后上报－解决－回访形成闭环，这极大地增加了问题处理开销，用户受业务影响的时间也将延长，在稳定性上将承受客户影响面扩大的风险。
因此在2017年双11，如何更全面地覆盖问题范围、更快速地发现问题、更快速地流转和处理问题成为我们必须要解决的问题，因此我们启动了2017双11稳定性监控专项，从双11监控部署、数据存储归档、监控系统稳定性保障等方面做了充足的准备，欲知详情，请看以下分享。
双11监控部署
在日常运维和客诉故障处理过程中问题的来源主要来自于用户上报、舆情吐槽、监控报警；那么要解决双11快速响应、快速止血的问题，我们就需要让我们的问题更快地被处理者感知、更快地执行处理。为了达到这些要求我们将监控部署分为四层：
客服&舆情监控：主要是为了解决用户的问题能够快速地通过监控实现报警，并投递到处理人处进行处理从而形成闭环；同时也是为了舆情问题能够被快速、准确地分拣出有效的问题，并智能投递到对应方进行处理和响应形成闭环。
业务监控：主要是从活动玩法、资损、业务常规等维度去发现业务异常从而实现业务异常的主动响应；同时也会从资金流维度监控以实现全局业务资金流向的全局透明管控，并提供业务决策支持。
系统水位监控：主要是从业务底层和依赖层的系统水位层面去抽象基础监控的标准，保证基础层异常在业务侧透出前实现提前预警、提前处理。
基础设施监控：主要是现有的系统实现了单元云化，为了提前感知云基础设施出现异常、减少云基础设施的抖动和异常对业务造成影响，所以从云基础设施的角度去透出云本身的业务异常，提前处理。
在响应上通过监控报警、监控大盘、监控大屏的方式透出了监控，将监控按照重要性进行等级区分，通过群订阅、盯屏报警、个人订阅等方式去处理报警，打通整个业务异常响应链路。
在处理上进行了风险、预案、监控的联动探索，通过针对业务风险点的预案进行提前管理，在报警触发时实现及时预案推荐，在问题流转到处理方时可以实现快速执行预案。
客服&舆情监控
客服&舆情一直是用户感知到使用异常后透传给服务提供方的有效手段，当一个问题被用户感知并通过客诉渠道、舆情广播的方式透出时，代表用户的服务已经受损；在双11这样大体量的情况下，任何的问题都可能会被快速地放大，面对海量的客服&舆情问题，如何快速地让问题透传到后端排查同学、快速处理并止血、防止影响扩大是双11期间我们首要需解决的问题。
以往的问题处理流程：客满同学收到用户的反馈--->通过线下经过用研、行业PD等过滤后找到相应的业务同学进行排查--->排查结果通过线下回传给反馈同学，同时手动记录到管理平台中。
以往的这种处理方式存在人肉成本高、透传时效受主观进行优先判断影响等的问题。面对海量问题如何快速投递、对于海量舆情如何进行快速智能的分拣投递？
2017双11，我们基于机器人工厂，在客诉和舆情问题进入后，通过机器人和算法进行了智能分拣、智能收敛聚类、智能投递。
业务逻辑如下图：
- 业务监控*
业务监控是一种从实际业务影响的角度去监测、反应业务是否正常的监控手段。在部署过程中，如何保证足够全面、准确地把监控部署到位是我们要解决的问题。
在2017年双11期间，主要从活动玩法、资损、业务常规监控（日常业务监控）等维度进行了监控的梳理和部署。
维度说明
活动玩法监控：主要从活动玩法链路的透出、发放、消费核销等节点上去覆盖业务的可用性监控。
资损监控：主要从数据一致性、业务超时、对账等角度去覆盖可能有资损的业务风险点。
业务常规监控：主要从业务主链路上去覆盖业务向用户透出、下单、支付、物流、及逆向等节点的可用性。
监控梳理
为了保证监控能够覆盖到尽可能多的核心业务节点，需要针对集团涉及的业务做全面的基于架构和业务链路的梳理，进而埋点、部署，以实现监控。
监控齐全度梳理：（从业务链路和架构上去梳理和验证该业务节点是否需要监控）
是否会阻断业务／玩法链路
是否会影响业务向用户透出
是否会造成用户体验下降
是否会造成用户损失
监控质量把控
针对海量的业务及其各个层面的监控，监控是否有效、报警泛滥等问题成为我们必须要关心的问题，双11期间我们从监控有效性检验（从监控本身的应用上去评估监控是否有效）和监控准确性检验（从监控报警策略上去优化报警，防止响应惰性）的各个维度去测量相关的指标验证监控的质量。
- 监控有效性校验：*
监控是否有数据
监控是否配置报警
监控报警是否被人订阅or群订阅
监控数据是否被监控大盘or其它系统引用
业务架构、调用链路、日志是否有变更
是否能反应当前节点的异常
- 监控准确性性校验：*
监控报警是否得到响应，响应率是多少
监控项日均报警量多少，正常反应的问题有多少
监控报警的原因是否是业务异常的体现，误报率多少
演练时故障监控发现率有多少
系统水位监控
系统水位监控（基础监控）主要是在业务和用户反应前，在业务机器水位、基础调用上升时发现业务异常。
2017双11主要通过监控平台承载了CPU使用率、MEM使用率、磁盘使用率、网络重传率、FGC次数、HSF成功率、读Tair成功率、写TDDL成功率、读TDDL成功率等基础指标去计算应用系统健康分，并根据健康分进行排序来实现异常的发现。在双11期间可以通过系统水位监控发现的故障相比用户上报的时间早60+分钟，比业务监控报警早3-6分钟。
基础设施监控
基础设施监控主要是指针对底层依赖的系统的健康性进行监控，以期发现底层异常，提前处理和执行预案，减少基础设施影响业务的可能性。
2017年双11针对业务云依赖的云基础设施情况从基础云产品的运维指标（ECS/SLB/VPC/OSS/CDN）、针对集团大促业务云上业务指标（电商／视频／图片／聚石塔／物流云）、云单元核心产品的水位（ECS/SLB/VPC/OSS/CDN）进行了稳定性监控的部署。同时通过分单元、分集群的多维度聚合透出问题。
数据存储归档
数据存储归档主要是针对从全链路压测开始到双11当天的所有核心业务监控和核心业务异常监控的数据进行离线存储，以便后续进行Review以及来年进行使用时参考之用。
监控系统稳定性保障
在大促监控部署过程中，涉及的业务量、日志量都远超日常，在监控部署的过程中我们需要考虑核心监控系统的数据接口稳定性、计算和采集的实时性，从而保障双11期间的监控系统SLA。
2017年双11，在全链路压测期间借用全链路压测流量，对监控系统也进行了压测，同时针对历史遗留的监控和核心监控项进行了分级保障，优先保障核心监控项的可用性。
监控系统稳定性保障从以下几个方面来进行：
1、压测验证：COPY配置压测环境监控，在全链路压测期间，让监控系统经受高压态的日志和计算洪峰，观测和发现监控系统的稳定性情况并修复出现的问题；
2、断网演练：对于监控系统的核心依赖进行断网演练，验证监控系统的容灾能力，对于极端情况下系统的稳定性提供应急预案；
3、实时性改造：针对大屏的数据时效要求进行架构改造，优化计算资源和数据接口，保障数据采集到计算完成透出的时效从20s提升到10s；
4、日志改造：替换大日志为小日志，减少监控日志对机器磁盘的占用；
5、监控降级策略：针对监控按照重要程度和健康性评分进行分级管理，在紧急情况下优先保障核心监控项的稳定、可用；
6、历史垃圾监控回收：针对存留的垃圾监控进行资源回收清理，减少垃圾监控对资源的占用。
写在最后
当业务系统庞大到一定程度的时候，业务系统的复杂度已经很难通过市场上既有的开源监控系统去解决监控的问题，也很难通过单一的监控逻辑去解决所有业务的稳定性问题，而在双11期间，任何一个细微的稳定性问题都可能被放大。今年我们通过稳定性监控专项的运作，实现了从面向用户的前台到技术中后台的全面监控，助力保障了双11的整体业务流畅。
