从人机协同角度看运维管理，监控相当于给运维团队分配了成千上万上机器人，这些机器人驻扎在硬件、平台软件等对象中，7*24不间断的采集指标数据，并将指标的异常情况实时推送出来。监控已经是发现潜在风险或异常的源头，推动监控发现的覆盖面、准确率、告警触达能力的提升，是缩短故障发现时长的关键举措。以下从被动监控、上帝视角、主动拨测三个角度分析如何提升监控发现能力。
1）被动监控
此处强调“被动”监控是为了区别主动监控，指代传统在基础设施、硬件资源、平台软件、应用可用性、客户体验多个层级的监控管理，以及统一的监控告警管理。这类监控方案通常是针对已知异常环节，采集指标数据，配置监控策略，以及触发策略后将监控告警统一推送到统一告警系统。
2）上帝视角
传统被动性的监控管理是针对已知异常，进行补丁式的增强监控的方式持续完善的过程。但运维面临三个困难，一是随着架构复杂性越来越高，运维组织面临越来越多的的未知的故障；二是数据量与风险触发因素增强后，单维指标监控监控能力不足，而多维指标让人配置又面临无法穷举的问题；三是运维对于故障发现已经在可用性故障基础上，增加了功能逻辑、数据类故障的发现要求，对于日志、链路的监控发现能力要求越来越高。
提出上帝视角是运维组织需要借助算法、海量数据、平台能力，构建一个全数字化监控感知的能力。这种感知能力需要尽量减少运维打补丁式的增加细化的指标策略，利用算法能力加深感知监控深度，利用海量数据加大感知监控广度，利用平台加快感知监控的速度与穷举的能力。当然，当前这种上帝视角对监控发现的准确率、覆盖面仍需要一个提升的过程，应该作为传统监控的一个补充手段，而非替代。
3）主动拨测
主动拨测监控是采用模拟用户访问终端、域名、页面URL、功能、API等，从客户视角监测功能可用性、感知用户端体验、检测网络链路质量，系统事务可用性，领先一步发现问题，提升客户体验。在企业推动以客户体验为中心的数字化转型中，拨测是监控发现的一种有力补充。借助机器不间断、自动化执行，提前设计好拨测执行的脚本步骤，可帮助运维执行更细粒度的功能操作，主动获取应用运行的性能体验指标，更准确地了解客户访问业务功能级的体验，以及应用层及网络层性能。同时，站在故障处置角度看拨测，当发生异常时将执行过程进行截图留痕，还可以辅助快速定位问题。
在拨测的解决方案中，通常包括公有云或私有化拨测方案，前者是通过拨测运营商提供部署在世界或全国各地的拨测源进行测试，用户不需要管理拨测终端，只要根据SLA明确的时效性、次数等付费，就可以获得拨测结果。私有化部署的拨测方案则运维组织管理拨测涉及的服务器、终端设备等环境。运维组织可以根据政策、风险、成本等维度考虑选择不同的解决方案。
2.协同反馈
虽然我们希望故障尽量由机器自动化发现，但是随着基础架构、应用逻辑、业务逻辑越来越复杂，系统一个小模块异常都可能导致系统自身甚至关联系统的业务连续性故障，建立一个在线的协同网络，提升协同节点中业务、客户、同业、开发、测试等团队的反馈的效率，仍然是故障发现的有力手段。
1）业务、客户、同业反馈
理想情况下，应尽量减少由业务与客户侧反馈的故障发现占比。但是现实中仍有部分故障，当前监控或运营分析比较难实时发现，比如功能逻辑性、数据准确性等类别，这些故障虽然不会带来全局性的可用性故障，但是站在以客户为中心角度，此类故障对个别或部份客户属于可用性故障，尤其是对公重要客户或权益类交易故障。针对这类故障，运维要提前建立一个高效的信息反馈的渠道，基于用户旅程梳理并建立全线上化的问题反馈是一个好的选择，比如：将问题反馈整合在业务系统中，系统可以获得快速获知用户反馈问题的热点信息，并通知运维处理；建立全线上化的服务台、一线、二线的问题处理流程，问题反馈的业务人员可以在线获知问题处理进度，机器可以根据问题反馈时长进行线上督办。另外，在企业内部建立必要的信息系统即时通讯沟通群，方便公司内业务人员的即时反馈，安排相应的问题服务岗位正在被很多运维组织接受。
2）开发或测试发现
开发或测试发现的故障是一个边界比较难界定，但又不可忽视的故障发现方式。边界难界定，有一些客观原因，比如很多系统或变更是带缺陷上线，这些缺陷本身在生产运行中会触发故障条件；很多线上的问题，如果是业务反馈，可能会先到达开发人员，由于故障通常在组织内会被用于质量考核，部分开发人员可能延迟问题的反馈。不可忽视，前面已经提到开发与测试反馈的故障，由于个体的重视程度或主观因素，可能导致故障处置的及时性。
3.数据运营
数据运营强调主动的运行分析。主动是当前运维组织转型的一个重点方向，对应的是当前被动响应服务请求、需求工单、监控告警、生产故障的工作模式。数智万物的运维世界为主动分析提供了数据原材料与平台赋能支持。
1）常规巡检
总体来说，巡检的常规操作性工作是一个被自动化替代的过程，巡检内容则需要运维专家不断深入，巡检的管理机制则需要不断的固化为巡检规则、任务、报告、数据感知等解决方案。从技术角度看巡检，在巡场上可以分为定时巡检与基于事件驱动的临时巡检，实现上通常需要数据采集与执行的代理（或复用现在的自动化能力），巡检策略规则，巡检任务，巡检报告、值班管理几块内容。
2）深度巡检/分析
深度巡检/分析，我更倾于命名为深度巡检，因为巡检意味着例行工作任务，对于运维数据例行的深度分析将是主动运营工作一个转变。一个潜在问题的触发，通常触发三种策略：诊断误报并取消，潜在风险挂起，发起故障响应流程。与常规巡检针对线上问题的即时反馈并发起故障响应流程，深度巡检主要是针对潜在风险的发现或预测。深度巡检通常从分析牵头方看，通常可能包括两类，一类是由运维组织内专家发起的主动性的运行分析；另一类是通常商务合同要求供应商定时执行的深度巡检。
3）运行感知
在实现上，运行感知不仅仅独立存在的实时运行看板，还应该与当前主干的运维流程结合在一起，才能不断的加深感知面与感知策略的深度。比如，将运行感知与巡检的定时任务结合在一起，要求每天都分析感知数据；将运行感知的异常数据推送到监控告警系统，融入到监控处理的流程中；将运行感知融入到故障诊断的环节，作为问题诊断、影响分析的一个工具。随着运行数据分析能力的提升，运行感知在故障发现环节中将起到越来越重要的角色。
3.4.2故障响应
故障响应指故障发现后机器或运维人员介入应急处理的过程。相比故障发现、定位、恢复，故障响应环节对协同的顺畅要求更高，通常可以围绕应急协同、告警触达、影响分析3方面进行建设。其中对故障影响初步判断是一个难点，考验运维人员的故障识别能力，不仅要求有基本的应急技能，还要对系统有深刻的理解。另外，在故障响应过程中，系统故障受理人，关联上下游系统运维人员，值班经理等各个角色的作用都尤其重要，需要不断的练习、实战来提升协同顺畅性。
1.应急协同：
1）ECC管理
ECC又叫总控中心，或监控指挥中心，是成熟运维组织对运行监控、现场值班、联络调度、事件处置等职责的日常工作场所。从人看，ECC主包括：值班经理、流程经理、一线运维、二三线条线专家、服务台（也可以将服务台归到一线运维）等岗位。从ECC形态看，ECC通常是一个独立的房间，里面有值班与应急需要的设备。在对于单个主数据中心的运维组织中，ECC里面值班的人员包括所有运维团队的值班人员，是公司最核心的应急处置场所，做好ECC管理是加快应急协同的最重要措施。
从故障响应看，ECC定位应急指挥中心的角色，需要制定一些工作机制。比如制定一线值班的工作职责，处理监控事件、应急响应与处置、问题咨询的解答、变更工单处理等，明确的工作职责有助于值班人员专注最重要的工作，提升故障响应的及时性。再比如落实好应急环境准备，里面要有运行情况的大屏，一线运维需要的办公终端，二线现场支持时需要的终端，用于应急使用的日志、运行数据、监控报警的工具系统，用于对故障临时决策讨论的房间，以及一些联络的通讯设备，故障定级、分析、联络人员的文档。
2）信息在线
由于信息的复杂性越来越高，一个业务关联的设备与系统越来越多，应急管理是一个多团队协同的工作，充分保持故障过程中的信息在线是一个重要举措。从故障响应角度看信息在线，又可以分解为协同在线、数据在线、工具在线。
3）服务台
在不同行业中，IT服务台的能力起到的作用不同，比如一些大型制造业，服务台一天可能会受理成千上万的服务工单，这些企业的服务在故障响应过程中起来极为关键的作用。要更好的支持服务台能力的提升，服务台应该提供快速响应IT部门内部呼叫涉及的渠道工具、在线的工单分派、工单级别升级等工具，让服务台工单处理全在线。比如一个涉及故障的工单的过程：请求登记、故障匹配（知识库或经验）、故障分派、跟踪状态与反馈故障处理状况、故障与应急方案解释、故障解决、客户或业务沟通。要提升故障响应效率，服务台是一个很关键的角色，需要通过提升线上化与自动化能力为服务台赋能。
2.告警触达
1）统一告警
2）告警描述
完善的监控策略需要有清晰的监控告警提示，值班人员要以根据监控告警即可作出简单的问题定位与应急处理方案。比如类似以下的监控短信：22时，【理财应用系统】中【应用服务器LC_APPsvrA10.2.111.111】的【前置应用模块】出现【应用端口：9080】不存在，该端口作用【提供理财应用处理（负载均衡部署）】，原因可能为【SERVER1服务异常停止】，监控系统己进行以下应急处理【自动执行端口进程启动】，该事件紧急程度【高】。管理员可以通过短信内容看到哪个系统、哪个应用、哪个模块出了什么问题，可能是什么原因，对业务有什么影响，是否需要马上处理（比如凌晨出现此预警是否可以延迟到次日处理）等信息。
3）告警升级
3.影响分析
在故障处理过程中，运维人员很容易钻进故障定位与恢复环节，但要加强故障响应的协同效率，让应急协同中的决策者、值班经理、上下游系统运维、开发、测试、业务、服务台共同参与到应急中，对故障现象与影响面的描述必不可少。同时在处理故障前，故障现象直接决定故障应急方案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度，清晰的故障影响面描述，有助于资源的准确调配。
1）关键指标
2）具体影响
关键指标的获知可以更加准确的调配应急资源，判断是否启动应急集结的响应机制，具体影响面的分析则通常需要故障处理现场的临时分析决策。在故障响应环节赋能具体影响的分析，通常需要提前提升运维专家技能，让运维专家加深对系统的理解，比如：系统架构、上下游关系、应用服务、应用日志、关键数据库表、关键参数配置、主要的业务流程等信息。为专家提供方便的工具也是提升影响分析的赋能手段，比如：日志、感知等工具。另外，建立在线的协同机制，让应急协同的各方在线将各环节（上下游系统、开发代码排查、测试复现、业务分析等）的分析信息同步出来也是提升具体影响的方法。
---------------故障定位与故障恢复章节大纲待完善---------------------
3.4.3故障定位
故障定位指诊断故障直接原因或根因，故障定位有助于故障恢复动作更加有效。故障定位通常是整个故障过程中耗时最长的环节，故障定位的目的强调快速恢复的基础上，而非寻找问题根因，后者由问题管理负责。通常大部分可用性故障，要借助运维专家经验的假设判断或已知预案的执行得到解决，但仍有部分故障，尤其是性能、应用逻辑、数据故障需要多方协同与工具支持。故障定位的方法通常包括专家经验驱动的假设尝试、测试复现、预案启动、代码分析四种，这个过程涉及对日志、链路、监控、数据感知、知识管理五类工具。随着系统复杂性不断提升，依靠专家经验驱动的假设尝试准确率会下降，如何将数字化手段结合专家经验，融入到协同机制中，这考验故障定位场景的设计水平。
1.定位方法：
1）专家经验驱动的假设尝试
2）已知预案启动
3）测试复现
4）代码分析
2.定位工具：
1）日志
2）链路
3）监控
4）数据感知
5）知识管理
3.4.4故障恢复
故障恢复指恢复业务连续性的应急操作，很多故障是在不断尝试验证解决恢复的动作，所以故障恢复环节与故障定位环节有一定的交叠，或在这两个环节之间不断试错的循环，即故障恢复操作可能和故障诊断是同时，也可能是诊断之后或诊断之前。在故障恢复中我们通常采用已知预案下的恢复三把斧：“重启、回切、切换”、自动或手动触发系统架构高可用策略、临时决断的恢复动作，以及恢复后的信息传递。