前言：在
运维数据的系列文章中，系统的阐述了有关数据运营的一些阶段和过程，众所周知，运维技术栈是没有边界的，因此通过这种属性进行运维能力输出的延伸存在很大的主观判断性。随着运维能力的不断增强，主观判断的不确定性随之放大，给运维能力输出的稳定性保障带来了极大的挑战，同时也让我们认识到，面向过程与操作的运维能力输出模型将难以为续，这一特性在DevOps和AiOps的建设上表现的尤为突出。在本篇中，我们将通过监控平台来系统的阐述“面向终态”，来解决运维数据运营中的一系列问题。
一、 什么是面向终态
需要明确的是，面向终态是一种设计方法，在运维领域，有核心的四个能力域，分别是安全、稳定、高效、低成本。这四个能力域也匹配着运维能力输出的四个阶段，分别是手工运维、自动化运维、DevOps、AiOps。在这四个阶段中，运维的对象始终贯穿了系统、用户、业务、业态，因此面向终态重点在于终态的对象和范围。
以系统为例，面向终态描述了系统的最终形态，用户只需要描述自己需要什么，不需要详细规划执行路径，系统会根据线上的实时状况以及运维知识库来动态调整，来达到系统安全稳定的目的。举个通俗易懂的例子，在灰度过程中，会根据灰度的需求来自动执行灰度策略来动态分配流量。
以用户为例，面向终态描述了用户的最终需求，重点在于系统内部的控制逻辑，主要核心在于声明式API，用户只需要描述最终需求，不需要提供详细的逻辑设计，系统会根据需求通过声明后提交给系统，最终完成用户期望的结果，和面向系统的终态不同的是，面向用户的终态主要是暴露给用户的使用方式。
二、 监控平台的意义
随着科技的不断发展，线上业务占比不断攀升，信息科技越来越成为核心生产力，因此一些非功能性的需求逐步上升到一个比较高的程度，可用性、可靠性、业务连续性的兜底都需要监控来完成。另一个方面，数据存储成本、数据价值输出、数据衍生能力也需要将核心业务数据扩展到一个较宽泛的范围，这也是面向终态的监控平台。
在运维领域来说，业务保障域是监控平台的核心功能，具备全方位无死角的监控覆盖范围，以业务为顶层视角，系统为主体数据输出模式，对故障进行检测、诊断、恢复、预测，其中故障预测是基于运维经验沉淀和积累的结果，对数据的分析来总结出故障的模式，从而进行预测。在IT数字化方面，监控数据是重要的数据资产，因此监控平台需要承担核心数据集散地的作用，为业务数据提供补全，为技术数据提供支撑。在成本预测方面，容量管理和采购管理需要相应的资源利用率提供数据支撑，还包括投入产出比来进行优化建议。
因此，基于系统的面向终态，监控平台应该包括以下几种特性。①基于业务的实时链路监控；②基于平台的应用异常实时监控；③基于用户的子域数据汇聚；④基于数据交换的实时输出；⑤基于预警的统一集中收敛。
基于用户的面向终态，用户的最终需求涵盖了故障处理的事前、事中、事后的全流程，在事前阶段，用户关心有没有做监控，在事中阶段，用户关心监控是否及时，相关指标的准确率高不高，事后阶段，用户关心故障复盘是否能够达到既定的目的。因此监控平台应该应该包括以下几种特性。①以服务目录的方式对监控对象进行解读；②能够以自动化的方式对监控对象进行全覆盖；③能够智能的对报警阈值和等级进行定义；④对故障处理流程进行学习，并形成知识库。
从输出能力来罗列，面向终态的监控平台应该对监控数据进行全生命周期管理，以达到运行态监控、安全审计、业务分析和数据输出的功能，并以数据集散地的形态来提供第三方数据的接入和接出。
从监控平台的目标来看，需要发挥的作用主要有以下，①能够实时的采集数据；②能够实时的反馈业务的运行态状态；③能够智能的预知故障和告警；④能够支撑能力子域进行辅助故障定位；⑤能够支撑研发人员对系统进行针对性的优化；⑥能够对容量规划进行辅助分析。
从监控平台的数据覆盖度来看，横向需要进行数据宽度的延展，从网络、服务器存储、系统、应用到最终的业务层进行数据的采集和汇聚。纵向需要进行打通用户终端、流量出入口、系统集群、产品运营进行端对端的数据多维度关联。
通过一张图进行简单的理解。
三、 现有监控方案的一些问题
现实中，企业已经采取各种各样的监控软件来达到业务域保障的目的，比较典型的是以为Zabbix、ELK为代表的开源软件，在实际使用中都取得了很好的效果。但从面向终态的方法来看，还存在一些需要改进的点。主要有以下，
① 对于企业来说，监控能力的全局性较弱，现有的监控系统只针对某个领域或者某个能力聚焦，无法对全局有全面的掌控。
② 无法将业务层往下的子域的链路关系、数据关系形成逻辑汇聚，因此造成排错时间长，业务恢复缓慢。
③ 监控告警多且杂。正因为有很多领域级的监控软件，这些不同的监控软件造成了各种独立的告警，导致告警风暴。
④ 不支持对其他能力子域的系统接入，尤其涉及到业务链路级、接口级、方法级的数据自动获取，导致监控漏配、错配引起的准确率和召回率不达标。
⑤ 作为数据的接入接出的集散地，对数据的聚合和二次计算支撑不够，导致数据的资产能力大打折扣。
⑥ 对大规模的时间序列分析和根因定位存在功能缺失。
四、 面向终态的监控设计
在面向终态的监控设计过程中，需要更加友好的面对监控对象和监控使用者，因此和普通监控所不一样的，第三方的数据接入需要在服务目录的范畴。在面向终态的服务目录设计中，包括如下特性。
1、 提供可视化的服务内容，使用更为便捷，降低使用成本，提升用户人群的覆盖度，把监控视角提升至业务优先。
2、 将第三方数据统一以服务中介的方式进行进行接入，服务中介在于端到端的数据开箱即用方式，如外接接口管理平台，接口的新增、废除能够自动的进行统计、计算和分析。
3、 由服务中介指定相应的服务提供给监控平台用户，通过对数据标签的方式自动的进行关联，根据实时、近线、离线不同方式的处理，最终呈现给特定的标签用户。
4、 监控平台用户可自定义的接入可用的服务对象。
在数据的处理方面，更偏重于清洗和指标分层计算，在此之前，需要数据源的多样化匹配，支持kafka、clickhouse或victoriaMetrics等多数据源的接入，最终需实现实时消息、文件的接入和数据的实时聚合。在数据聚合的需求梳理中，需达到多个维度和指标对数据进行聚合。数据衍生是面向终态的最直接表现，需支持根据不同的指标进行运算，得到用户想要的多维复合数据。
其中，在清洗阶段，需要实时的接收数据，进行数据的处理、转换、清洗，任务一般基于storm或flink实现，经过清洗任务处理后的结构化数据通过
消息队列进行数据流转或回流。在指标计算阶段，对结构化数据进行相关指标的计算，需达到高吞吐量，标准SQL等特性，还需要加强时间窗口、去重等能力的匹配。根据标签数据和标签用户的不同特性，动态的对数据进行实时处理和离线更新。
在数据的回流输出方面，面向终态的监控平台，需要根据监控的目标不断的去回检当前系统状态，从而为面向终态执行决策的时候，提供部分的依据，因此模型管道的构建必不可少，这也是我们常说的异常检测的功能，下图为数据反馈图。
在异常检测方面，可以从告警分析和根因分析来落地。在告警分析方面，基于系统的面向终态需要实现，①对告警的时间顺序进行趋势分析；②对指标对比进行分析，降低指标预警的召回率；③对已知的告警进行标记，辅助优化模型，间接提升指标预警的准确率。在根因分析方面，通过数据的下钻和关联数据的收敛，根据最终的影响因素来对算法分析出的主因进行判断标记，通过主因判断的结果符合度指标来进行算法调优。
在基于面向终态的监控平台设计中，平台应有如下分层。①用户体验层；②服务能力层；③数据分析层；④数据加工层；⑤后台管理层。
五、 写在最后
面向终态继承了aiops的理念，通过运用大量的声明式api来提高“无条件”的极致用户体验，同时运用机器学习来加强了数据的输出和变现能力，这种设计方式将技术进行反向解耦，在服务能力的范围之内，将数据纳入到用户体验中，提升数据的反馈能力，拓展了监控平台的用户范围，更安全、稳定、高效、低成本的践行高效运维理念，也解决了运维数据运营中的一系列问题。在本篇中，主要描述了面向终态的设计方法，此为本系列的开篇，后续会对基于面向终态的监控平台进行详细的阐述。