image.png
业务大盘
业务指标和系统指标、服务指标不同，需要业务方根据不同的业务自行上报监控数据。业务大盘作为业务运维系统的使用入口，可以让开发人员快速查看自己关心的业务指标的实时状态以及最近几天的走势。
image.png
业务大盘不光需要展示业务监控指标，还需要有很强的对外扩展能力，比如：
① 当出现业务指标异常时，根据后台的监控数据分析，可以手动或者自动进行事件标记，告知开发人员是什么原因引起了业务指标的波动，做到用户信息量的快速同步。
② 可以带着时间戳与类型快速引导开发人员进入其它监控系统，提高开发人排查问题的效率。
核心链路
核心链路也是系统主要的使用入口，用户可以通过核心链路快速定位是哪一个调用链出现了问题
① 我们需要给核心链路上的服务节点进行健康评分，根据评分模型来界定问题严重的链路。这里我们会根据服务的各个指标来描绘一个服务的问题画像，问题画像中的指标也会有权重划分，比如：当服务出现了失败率报警、TP99报警，大量异常日志则会进行高权重的加分。
② 当我们确认完某条链路出现了问题，在链路上越往后的节点可能是引起问题的根节点，我们会实时获取该节点更多相关监控指标来进行分析诊断，这里会融合开发人员日常排查问题的SOP，最终可能定位到是这个服务节点某些服务器的磁盘或者CPU等问题。
image.png
最终会发出问题诊断结果，这个结果在发出之后，还需要收集用户的反馈，判断诊断结果是否准确，为我们后续优化评分定位模型与诊断模型提供有力的数据支持。在核心链路建设前期，建议开发人员进行相应的服务保护预案触发，当我们的诊断结果足够准确之后，可以针对固定问题场景自动化触发服务保护预案，以缩短解决问题的时间。
服务保护&故障演练
image.png
服务保护&故障演练模块是让我们的业务运维体系形成闭环的重要部分，该模块需要具备的核心功能如图所示
针对不同的保护需求，我们会有不同类型的服务保护开关，这里主要有如下几种：
① 降级开关：由于业务快速发展，在代码中会有成百上千的降级开关。在业务出现异常时需要手动进行降级操作。
② 限流开关：有些针对特定业务场景需要有相应的限流保护措施。比如：针对单机限流主要是对自身服务器的资源保护，针对集群限流主要是针对底层的DB或者Cache等存储资源进行资源保护，还有一些其他限流需求都是希望可以在系统出现流量异常时有效地进行保护。
③ Hystrix自动熔断：可以通过监控异常数、线程数等简单指标，快速保护我们的服务健康状态不会急剧恶化。
在出现生产事故时可能会涉及到多个开关的切换，这里就需要针对不同的故障场景预先设置服务保护预案，可以在出现问题时通过一键操作对多个服务保护开关进行预设状态的变更。我们既然有了应对不同故障场景的服务保护预案，就需要时不时来验证这些服务保护预案是否真的可以起到预期的效果。
生产对应的事故不常有，肯定也不能只指望生产真的出现问题才进行预案的验证，还需要针对不同的故障进行模拟。当我们生产服务出现问题时，不管是因为网络原因还是硬件故障，大多数表现在服务上的可能是服务超时或者变慢、抛出异常。我们前期主要针对这几点做到可以对核心链路上任一服务节点进行故障演练，生产故障可能会同时多个节点出现故障，这里就需要我们的故障演练也需要支持预案管理。
服务保护是业务运维终端措施，我们需要在软件上可以让用户很方便地直达对应的服务保护，这里我们可以很容易就将服务保护与业务大盘、核心链路进行整合，在开发人员发现问题时可以方便地进入对应的服务保护预案。有了这些保护措施与故障演练功能，结合与核心链路的关系，就可以与故障诊断与全链路压测进行自动化方面的建设了。
全链路压测
image.png
整个系统建设中，自动化方面的建设主要集中在以下几个方面
异常点自动检测
image.png
在做核心链路建设的时候，需要收集各个服务节点的报警事件，这些报警事件有服务调用时端到端的监控指标，还有服务自身SLA的监控指标。在和开发人员进行沟通的时候了解到他们平时配置这些监控指标的时候耗费了大量的人力，每个指标的报警阈值都需要反复调整才能达到一个理想状态，基于这些监控痛点，我们希望可以通过分析历史数据来自动的检测出异常点，并自动计算出应有的报警阈值并设置
根据不同监控指标的特点，选择不同的基线算法，并计算出其置信区间，用来帮助我们更加准确的检测异常点。比如我们的业务周期性比较强，大多数监控指标都是在历史同期呈现出正太分布，这个时候可以拿真实值与均值进行比较，其差值在N倍标准差之外，则认为该真实值是异常点。
自动触发服务保护
image.png
服务保护措施有一部分是通过Hystrix进行自动熔断，另外一部分是我们已经存在的上千个降级、限流开关，这部分开关平时需要开发人员根据自己的运维经验来手动触发。我们如果能够根据各种监控指标准确的诊断出异常点，并事先将已经确定的异常场景与我们的服务保护预案进行关联，就可以自动化的进行服务保护预案的触发
压测计划自动化
image.png
定期进行全链路压测，需要召集相关业务方进行准备和跟进，这其中涉及的数据构造部分会关联到很多业务方的改造、验证、准备工作
我们需要进行如下工作的准备：
- 针对真实流量的改造，基础数据构造、数据脱敏、数据校验等尽可能通过任务提前进行。
- 进入到流量回放阶段，我们可以针对典型的故障场景进行故障预案的触发（比如：Tair故障等）。
- 在故障演练的同时，我们可以结合核心链路的关系数据准确定位出与故障场景强相关的问题节点。
- 结合我们针对典型故障场景事先建立的服务保护关系，自动触发对应的服务保护预案。
- 在整个流程中，我们需要最终确认各个环境的运行效果是否达到了我们的预期，就需要每个环节都有相应的监控日志输出，最终自动化产出最终的压测报告。
整个压测计划的自动化进程中，将逐渐减少系统运行中人为参与的部分，逐步提升全链路压测效率。希望，用户点击一个开关开始压测计划 ，然后等待压测结果就可以了。
image.png
在整个业务运维系统建设中，只有更加准确定位问题根节点，诊断出问题根本原因才能逐步自动化去做一些运维动作（比如：触发降级开关，扩容集群等）。如上图所示，我们会在这些环节的精细化建设上进行持续投入，希望检测到任意维度的异常点，向上推测出可能会影响哪些业务指标，影响哪些用户体验；向下依托于全链路压测可以非常准确的进行容量规划，节省资源。
网友评论