鄢晶 众安科技 平台架构技术负责人 高级技术专家
我今天的分享分几个点：第一部分是运维的现状，大家都会遇到的难点问题，以及运维需要关注的一些重点。第二部分是服务可视化领域，实现服务可视化用到的即有的基础设施。第三部分是站在巨人的肩膀上，在监控基础设施之上，建设一站式立体化的监控平台。第四部分是引入AI技术，通过AI赋能来建设新一代的智能运维体系。最后是未来的畅想部分。整个分享的内容可以理解为就是众安运维体系的演进路线。
首先介绍下运维的现状，重点与难点。建设运维体系可以从目标出发，运维的目标更多是为了保证上层业务的高效稳定以及安全的运行。为了达到此目标，企业需要建设完善的稳定性保障体系，具备发现问题、预测问题、快速处理问题的能力。通过工具平台提供实时监控、实时反馈通道，提供捕获、定位、处理、跟踪的抓手。
接下来是运维关注的重点，也可以说是DevOps能够带来的价值，总结来说就是多、快、好、省。我今天的分享主要是讲稳的部分。稳指的是系统稳定，关注两个核心指标，一个是平均故障间隔时间MTBF，是指一次故障结束到下一次故障开始的平均间隔时间，MTBF越大表示系统越稳定。另外一个指标是平均修复时间MTTR，指的是从出现故障到故障修复的平均时间。MTTR越小，表示故障恢复成本越小。MTBF和MTTR可以导出系统可用性，一般我们会用系统可用性等级来进行可用性的衡量，也就是我们常听到的“几个9”。99%，一年总故障时间不能超过87.6H，99.9%，一年总故障时间不能超过8.8H。三个9一般是行业的标准水平。4个9和5个9，基本上是质的变化，4个9，意味着系统全年的故障时间不能超过53分钟，要求业务基本上不能出现中断。这就需要我们系统基础设施具备一定的故障自动恢复能力。
我们发现在实现运维目标的过程中会遇到一系列的难点问题。首先第一点，架构在演进，系统越来越复杂，从单体架构到SOA架构，再到现在的微服务架构，调用关系愈发错综复杂，运维数据量指数级上升，获取关键运维信息成本越来越高。第二则是越来越多的企业不再限制我们的开发语言栈，尤其是互联网企业可能在这块尤为突出，java，go，c++，python百花齐放。我们会面临多语言、多技术栈的挑战，带来复杂的运维问题。系统复杂的背后必然会带来故障频发，定位困难的问题。还有海量的运维数据，虽然有一些工具手段做辅助，但是数据量实在太庞大了，我们都淹没在茫茫多的无效告警里，我们都是在盲人摸象式的问题定位。另外我们可能都在拥抱云原生架构，发现系统具备弹性的能力，却又好像不够弹性，比如说我们使用kubernetes作为基础架构，k8s具备HPA横向自动扩缩容的能力，真正用到的企业又有多少？可能有些企业已经在深度使用容器自动扩缩容，在iaas层基础设施级别，这块的弹性又是一个问题。
第二部分介绍下可视化运维的基础设施。
监控一般是面向三个领域，一个是日志，可能是系统的日志，也可能应用输出的日志。另外就是度量指标，比如说我们的主机的表现情况，我们应用的表现情况和我们业务的表现情况，这些都是度量的范畴。另外就是链路，链路是我们进行问题定位的关键。这三块不是完全相互独立的，会有交叉，比较典型的场景比如链路和日志，将链路ID写到日志中，出现一个错误的时候可以日志找到链路ID，来查看整个链路的请求情况，同时通过链路ID也能获取到完整的上下文日志。
接下来分享下如何使用基础工具建设监控平台。监控平台一般会分几个部分，采集、数据处理和数据应用。从基础设施到数据到应用到网络，相应的都会有一些数据采集手段。日志的采集我们会选择filebeat，考虑到他的开源生态，低资源占用及采集效率。指标类数据采集我们选用prometheus，链路数据采集则是基于jaeger的二次开发，考虑到他多语言的支持。数据经过处理之后会对应不同的存储方式，一般日志类放到ES，时序数据放influxdb，基于这些数据做可以实现简单的监控应用，比如数据可视化呈现，数据异常检测，告警通知。
基于上述的逻辑可以实现一些监控场景。下面简单介绍两个监控场景。我们有一些面向C端用户的场景，会发现C端用户的监控很难却又很重要。例如用户打开一个APP，可能会有卡顿，图片加载不出来，闪退等各种各样的问题，这些问题往小来说是用户体验的不友好，严重了，可能会带来非常多的用户投诉。对于这个场景，我们可以在H5端或者客户端进行SDK集成实现埋点，将数据以一个旁路的形式传送到监控服务器。将数据进行清洗加工，提取设备、地域、运营商等信息作为数据标签。这些数据可以通过聚合分析产生具备维度属性的数据，并通过可视化页面实现数据的呈现。右边是我们前段监控的一个看板样例，我们可以通过看板看到请求、卡顿、崩溃的走势信息，同时可以对一些异常事件按地域、运营商、设备等维度进行分布，在问题定位时可以帮助确认是不是因为客户端问题引发的异常。在前端性能数据应用这块我们也可以将数据传送到流计算平台进行实时计算产生一些指标数据，像请求次数、异常状态码、平均耗时等的一些指标。对这些指标进行阈值判定，出现了问题准实时通知到相关负责人，先于客户发现、反馈问题。
第二个场景介绍下调用链的一些应用。调用链大家使用到的比较多的地方一般是链路的追踪，例如某一个请求可能慢，通过调用链工具提供的瀑布图可以很快定位到耗时慢究竟是发生在哪。除了辅助定位问题，调用链的数据还可以进行一些实时分析。我们可以对链路数据的来源与目标进行关联分析构建有向无环图，产生服务的运行时的拓扑。以拓扑图的形式清晰地看到应用间的调用关系。同时可以在调用关系上呈现端到端的性能表现。
前面是通过开源工具以及我们对开源工具的二次开发进行监控平台的建设，接下来则是通过AI赋能建设我们的新一代的运维体系，在这块分享一些正在进行的实践。
首先是异常检测，我们常规的异常检测是怎样的呢？一般会是出现了错误日志认为是异常，发一条告警邮件，容量指标超出了阈值，发一条告警邮件。很显然，我们会遇到告警轰炸的问题。另外规则更多会是依托于经验，更多是单一指标维度，判定不精准。
通过一些AI算法可以帮助我们摆脱对经验的依赖，并且可以实现多指标多维度的联合判定。我们知道异常一般会是出现概率较低的数据。我们可以通过多维高斯分布构建以应用为中心的多指标分布模型。
关于异常检测接下来我分享一下基于孤独森林的异常检测，举个例子，假如说我们有一堆黄豆，夹杂了几颗黑豆，要去找到异常的豆子。一般我们会设计一个条件判定，颜色是黑色的认为是异常的豆子。乍看下来问题不大，但是实际上我们是先入为主了觉得黑色的就是异常豆子。就像我们认为级别是错误的日志是异常一样。如果给到一堆豆子，有各种颜色，大小不一，如何去寻找异常的豆子呢？孤独森林的核心思想是对数据样本随机取一个维度进行二分法分割，循环随机维度及二分分割的操作，直到数据样本无法再切分。基于此算法构建二叉树，树的高度最低的叶子节点即为异常数据。就好比是某些方面跟旁人格格不入的人容易被孤立。应用到主机容量指标上如何做异常检测呢？假设有一个主机容量的数据样本，像这张片子上有十个监控指标，有CPU、MEM，网络流入流出四个指标维度。孤独森林会取其中一个维度，将我们当前的数据样本按照当前维度的平均值进行划分，一部分出现在左边，一部分出现在右边，再对两边数据随机取一个维度继续划分。可以看到P4这个点，通过内存维度划分的时候，因为跟其他数据差异较大，划分后样本数量很小，导致它在整颗树中高度最小。我们认为P4是异常的点。上面只是简单的例子，实际上的应用会复杂得多，我们要将整个应用相关的指标形成一张大的数据维度表，业务指标、容量指标以及相关的指标结合在一起进行高维的孤独森林异常检测。
接下来是故障诊断部分。我们常见的故障诊断思路是什么样的呢？收到一个告警，我们可能会先去看日志，dump内存，查看调用链，查看主机表现。我这边称之为盲人摸象式的故障排查。这种方式极度依赖经验，人员流动、系统迭代都会影响故障排查的效率。另外不够精准，工具平台可以告诉我们的信息很少，信息之间也没有关联性。
下面是我们基于事件传播链分析和决策树诊断的故障诊断方案，首先是刚才介绍到的通过链路追踪绘制的服务间的动态拓扑，然后则是基于ITSM流程和CMDB数据产生的服务与资源之间的静态拓扑。我们知道，故障是会传播的。举个例子，主机出现了问题，将会影响在主机上运行的服务，这些服务又会影响依赖了它的服务。一般我们会收到一堆没有关联性的告警邮件，在这些茫茫多的邮件轰炸下抓瞎。
我们可以通过一个时间窗口内的告警对象，基于动态拓扑和静态拓扑绘制一张事件的传播链。故障定位就是对树的根节点进行检索的操作。
接下来是信息推荐的部分，一般我们获取监控信息的手段是有问题去找监控看板，或者安排一些人盯屏。这些都是典型的人找信息的思路。信息找人说白了就是信息推荐。我们将整个监控看板设计为以应用为中心的应用看板，可以对这个看板做两层推荐。第一层是给应用打分，基于应用局部的指标进行异常特征提取，有异常特征会产生扣分，将分数最低的应用在呈现在最前面。我们需要关注的就是排在最前面的应用。第二层则是应用这边具体的指标健康状况的排序，每个指标项都有一个相应的分数，将分数最低的指标项排在前面。通过这种方式开发同学一看到面板就知道需要重点关注哪个应用，最可能出现问题的是哪个指标。确保看到的信息就是你想要信息能够极大的降低获取信息的成本，有效辅助问题排查。
未来的畅想部分。我们的未来不是指3-5年，而是明年上半年，因为现在这个这块内容当下正在建设当中，明年上半年将会有一些产品落地。我们希望建设交互式的运维。传统的运维方式是黑屏，很多运维的操作都会在控制台上通过命令行上进行，我们要把黑屏变成白屏，将所有事放在IM工具里，在聊天室里实现人与人的协同，人与机器的协同。假设我想看系统的健康状况，通常的做法做法会登入监控平台，或者通过一些命令或者通过开源工具获得应用监控信息。在交互式的运维场景下，我们可以直接给运维助手发一个消息：我想看监控的状况，系统将以卡片的形式直接将监控信息、诊断结果推送给我们。又假设创建应用这么一个简单的场景，通常的创建应用可能会通过OA发起一个创建应用的审批流程，做得好的会用自动化手段创建应用数据和相关的代码仓库。交互式运维会怎样呢，向运维助手发送一个创建应用的指令，它就会推一个创建应用的卡片，在卡片上填入应用基本信息，提交后卡片会推送到相关审批人。审批通过后运维助手自动创建应用，创建代码仓库，甚至是基于脚手架导入代码框架。这是比较典型人机交互和人与人的交互协同的场景。
实现逻辑可参考这张片子，最重要是语义识别，事件总线和运维控制管道。对语音输入、文字输入或者格式化命令的输入进行解释，进行领域模型的匹配，触发相应的事件，系统作出内容推送和执行命令调度的动作。
我这边的分享就到这里，感谢大家！
点击蓝字
关注我们
