系统架构的演变

随着互联网行业的发展，电商、短视频等应用的架构也在快速发展。总体来说，系统架构大致经历了：单一应用架构->分布式架构->微服务架构的演变。当然，它现在已经演变为服务网格。

早期，一般网站流量较小，采用单体应用架构，即将系统中所有功能、模块、组件等耦合到一个应用中，通常运行在同一个进程中，共享一个数据库。该模型简单直观，可以降低开发、部署和维护成本，适合小型应用的快速开发。但其缺点也很明显：无法水平扩展、模块耦合度大。

向分布式架构演进时，将重复的业务代码抽象出来，作为统一的服务，供其他业务代码或模块调用，形成服务层和表现层。服务层封装了具体的业务逻辑供表示层调用，由表示层负责处理。与页面的交互。分布式架构提高了代码的复用性，提高了整体访问性能。但这种架构调用关系也比较复杂，难以维护。

​

微服务架构就是将一个大应用拆分成多个小应用。这些小应用程序相对独立，有自己的运行进程，相互之间通过消息传递或远程调用进行通信。系统中的每个微服务都可以独立开发、独立部署、独立运营。每个微服务都是松耦合的，有利于扩展和维护。但其开发成本高、系统复杂、难以保证数据一致性等问题。

架构变更带来的问题

随着架构越来越复杂，应用越来越多样化，特别是在K8s场景下，服务之间的调用层数越来越多，这对业务系统的稳定性和运维工具的有效性提出了挑战:

对于架构变更带来的稳定性问题，尤其是用户规模和流量越大，影响就越致命。除了保证业务上线时进行必要的测试外，还需要提供针对性的保障。例如，新推出游戏业务时，会专门安排一两个月的再保险操作。

另外，现有的系统保护方法只能在问题发生后提供补救措施。能否利用运维工具快速发现问题并预警，提前进行主动运维？这就要求我们开发和采购在监控可观测领域产品能力更强的运维工具（比如现在的云原生可观测运维产品），实时收集系统运行指标，并基于异常情况根据指标情况，提前进行故障预测，利用智能分析算法提供根本原因分析并提出修复建议，快速发现和解决问题。

这就需要进行故障演练，提前发现问题、解决问题。如果运维工具存在指标不够、报警不够、根因分析不够等问题，也必须组织演练。

为什么需要故障排除

随着云原生技术的发展，微服务架构和容器化技术的广泛应用，软件架构的复杂度不断增加，服务之间的依赖带来的不确定性也呈指数级增长，任何一个环节都会发生突发事件。或者异常的变化可能会对其他服务造成很大的影响。因此，有必要构建故障演练平台和机制，提高系统架构的容错能力和恢复能力，验证整个故障定位能力和恢复系统。

下图展示了不同演练阶段在不同演练环境下执行的演练任务。目的也是为了通过故障注入案例验证系统的稳定性以及运维报警平台在测试环境、灰度环境、生产环境下的有效性。开展的一系列活动。

另外，根据故障处理的一般流程，故障演练还可归纳为三个阶段：

故障演练主要用于模拟线上环境中可能遇到的各种问题，提前进行充分的测试。它们不仅可以测试业务系统的稳定性，还可以测试运维工具的综合能力。

在生产环境中进行的故障演练是最高级别的演练，考验的是案例注入的丰富性和系统的控制编排能力（混沌工程）、可观察平台的告警和根因分析能力、数据隔离能力。这就会涉及到下一节讨论的全链路压力测试。

如何进行全链路压测？

故障演练已经有了，为什么还要进行全链路压测？这是因为某些问题只有在真正大流量的情况下才会暴露出来，例如网络带宽、系统间影响、基本依赖关系等。

很多人可能还会问，双十一等重大促销期间，全链路压测是如何进行的？全链路压测不仅仅是压测，更是一次大促的真实预演，统一验收计划演练、限流验证、破坏性演练等高可用方案。

全链路压测需要考虑的一个重要问题是生产环境的数据隔离：在生产环境进行写压测时，需要保证线上服务的正常运行不受影响，同时保证线上服务的正常运行。正在进行压力测试。采用的解决方案是将压测产生的数据与真实生产数据隔离存储，避免脏数据对线上业务的影响。目前有两种隔离方案：影子表方案和影子数据库数据隔离方案。

本文简单介绍一下影子库解决方案，即在同一个实例上建立对应的影子库。用户服务挂载的压测探针获得流量标志后进行相应的旁路处理；如果是影子流量，则会从影子连接池中获取影子连接供业务方使用，从而绕过压测流量产生的数据。对应影子数据库的路径，达到数据与生产数据库隔离的效果，从而避免压测流量产生的数据污染生产数据库。

经过故障演练和全链路压测后，业务即可上线。我们的运维工具会不会就没用了？答案是肯定或否定。一般来说，大规模的云原生系统会使用可靠的可观察工具来保护业务系统。那么，经过故障演练、全链路压测验证过的运维工具就成为我们选择工具的重要参考。需要设计各种故障演练场景来进行“打稿”活动。

故障演练场景有哪些？

故障演练场景有很多。从单系统应用角度和集群组件角度构建案例来测试我们业务系统的稳定性。更重要的是，提前发现问题的能力对运维工具的要求越来越高。要求和挑战越来越大。

从垂直技术架构层面设计演练场景：

从集群和组件维度设计演练场景：

通过针对不同的业务场景和部署场景进行演练，可以对运维工具进行全面的评估。例如，利用混沌工程打造网络丢包案例，运维工具是否能够在毫秒内报错，是否可以从应用监控维度发现连接失败、超时等问题，并上报是否存在问题。错误点在OS内核、云场景下云网络丢包、或者物理网络丢包。

如果构建一个访问空指针导致系统宕机的场景，集群维运维工具能否快速检测到单节点故障，捕获vmcore信息，分析宕机根本原因，进而上报节点健康状况？状态，并根据影响做出迁移动作，这对运维工具的综合能力是一个很大的考验。

如何评估工具

从上面故障演练的介绍可以看出，运维工具在问题预警、问题发现、根因排查等方面发挥着非常重要的作用，对于快速发现业务系统的稳定性、及时解决问题起到了关键作用。令人震惊，并进行根本原因分析。运维工具的丰富程度、报警是否及时、指标是否有效等，稳定轻量、易用、功能全面、社区支持等也是重要的参考指标。因此，结合故障演练来评估运维工具是一种非常有效的方法。

在成熟的业务系统上，部署一套运维工具，尤其是定期开启的监控工具。例如，分析通常用于可观察的场景。系统性能分析往往会给业务系统带来一定的性能开销。就是我们的运维工具安装后，一定要保证对原有系统的影响小，即选择功能丰富、性能开销小、存储成本相对较低的工具。能够预测故障、提供报警、提供根因分析和修复建议（即具备智能分析能力）的运维产品将是一个重要目标。

综上所述，运维工具的评价会考虑以下几个方向：

下面我们分别对功能、报警、观察指标评价项进行详细讨论。

功能评价项目

1、基本功能完备性：

2.报警配置灵活：

3、故障定位精度：

报警评估项目

1、报警延时检测：

2、报警通道覆盖范围：

3、报警触发阈值灵敏度：

4.报警通知频率控制：

观察指标评价项目

1、可观测数据来源丰富：

2.数据可视化效果：

3、分析的洞察力和深度：

4.可扩展性和兼容性：

通过对以上评价项目的量化评价，可以全面了解运维产品的功能准确性、报警及时性、观察有效性。同时，评估过程需要结合具体场景和用户需求，确保评估结果具有针对性和实用性。

系统运维联盟工具评测

由于业务系统涉及数千个行业，市场上的混沌工程种类繁多，运维工具参差不齐，运维技术始终追随国外，行业发展受到阻碍。运维生态也呈现出没有问题无人关注、出现问题运维人员承担责任的现象。他们对故障没有尊重，对运维工具的作用没有足够的认识。

随着人工智能和云原生技术的发展，系统变得越来越复杂，调用层次也越来越多。国内外在可观测性和AIOps运维方向的探索不断。涌现出很多优秀的工具，但也有很多工具质量低、重复、难用、兼容性差。为了让运维行业蓬勃发展，让优秀的工具脱颖而出，重要的工作之一就是将不同的运维工具放在一起进行评估和评价，通过将故障注入到具体的业务系统中，并通过评分机制排行榜，同场竞技，驴马都能拔出来！

SOMA（系统运维联盟）是平台厂商、运维厂商、高等院校和科研院所、事业单位和行业用户基于平等自愿的原则共同组建的。是一个以推动系统运维技术进步、促进产学研合作为目的发起成立的组织。运维联盟通过建立故障注入平台和运维产品实力评估体系，在平台厂商、运维厂商和客户之间建立起沟通的桥梁和纽带，让用户对运维有一个整体的了解产品拼图。

运维联盟进行的运维工具评测主要包括四个体系：案例注入、被测系统、评估体系、报告评分体系。通过向被测系统（被测系统采用标准的微服务系统）注入不同类型的案例，借助标准化接口给评估系统给出故障期望，并将评估系统发送到测试点（如作为运维工具暴露的标准接口，或者第三方的标准观测系统）采集现场指标，匹配预期指标进行范围匹配。评估完成后，生成相应产品的评估分数和测试报告。后期会对这些评分结果进行排名，发布行业报告，并进行一些商业化行动。

具体流程：

1. 输入故障案例和混沌控制项目

包括客户案例、厂家案例、评估案例。前两个案例主要是为了方便客户和厂家随时注入案例、模拟故障行为，让客户充分了解和评估故障的表现形式以及运维工具的能力。评价案例主要针对运维工具资质的审核、排名、打分，规范可信。

2、评价体系采集指标

在评估过程中，业务系统的选择考虑了一些因素：可持续维护、微服务应用、丰富的调试接口。复旦大学彭欣教授团队开发的火车票微服务应用目前作为业务基准（也可以基于线上精品）。评估系统的基准指标来自于故障注入系统，业务系统指标也必须从运维工具输出的接口中采集。目前大部分运维工具都没有这些接口或者接口不完整，需要制定一些标准。

3、指标对比及范围匹配

评估系统需要得到注入系统的预期输出指标作为基准，与运维工具本身得到的指标进行比较。根据指标类别制定一组标准，然后确定指标偏差范围来对工具进行评分。

4.评分，输出工具等级分布，并生成单独的测试报告

5、根据分数发布排名及年度运维行业报告

从故障演练到评估的操作流程及数据接口图：

通过以上分析，评估系统的关键问题是制定一套评估项目和标准，以确定哪些指标可以自动评估。其指标范围需要在具体场景下进行标准化。最好在能够确定预期范围时使用故障注入，例如 CPU 使用率、内存使用率或系统延迟。所有人都必须有确定性的期望。

运维联盟所做的最具挑战性的工作就是定义这套标准，并根据标准实现自动化评估能力。我们也希望越来越多对此感兴趣的个人和公司为此做出贡献。

目前，基于Chaos Mesh的故障注入系统（由联盟成员云管求豪团队开发）已在龙里社区开源（）。目前提供了网络、存储、K8s故障案例。希望大家一起贡献案例。您可以通过龙力社区首页进入运维联盟网页体验：​​​​

我们结合联盟成员之间的运维平台，针对不同的评估类型形成了以下评估知识图谱：

系统运维联盟评价方向

从上面的评测知识图谱可以看出，我们按照运维联盟划分了评测的相关领域：

每个领域都有自己的评价项目、评价内容和评价方法，其中有些是共享的和重叠的。但无论如何，请进行包括以下要点的审查：

由于业务系统较多，每种运维工具都有自己的侧重点。系统运维联盟会针对这两类热门的工具进行研究，一是可观察方向，二是AIOps方向。

在可观察方向，我们使用特定的功能点进行评估：通过聚合指标反馈节点的健康状态（健康、亚健康、不健康等）。这些子指标包括饱和度、系统错误和系统延迟。 、网络流量，以下是相关评价项目：

另外，当运维工具安装后，如何判断其对原有系统的影响，即对系统资源的损害。我们首先使用第三方标定工具作为可信来源，例如Prometheus的采集工具，通过将标定工具的指标与被测试工具输出的指标进行比较来对工具进行评分和评估。该评测项目目前由联盟成员云山网络团队正在开发，即将开源。

相关评论项目：

最终，我们评估工具的等级将包括以下几个方面：

每个评估项目不同，分数和工具级别的对应关系可能不一致。今后将介绍这方面的研究成果。

AlOps 工具回顾

在评估AIOps工具时，需要针对具体问题进行根本原因分析，利用混沌工程模拟多种故障场景，测试AIOps解决方案的有效性和鲁棒性。通过指标收集、日志收集、链路跟踪Trace，提供了一套标准化的评估指标和数据集，为用户选择合适的AIOps工具提供参考。为运维应用开发者和科研人员提供学术研究、产品测试和评估的真实数据和场景。

龙蜥社区系统运维联盟与清华大学裴丹教授发起的OpenAIOps社区（）合作，共同建立AIOps领域的评测能力。

评论和排名的吸引力？

系统运维联盟今年最重要的任务是建立评价最低值体系，即建立从故障注入到评价评价、从运维工具打分到发布评价报告并制定评价体系运维排名。中国信息通信研究院还将参与评估项目和评估标准的制定以及评估报告的发布。通过接入联盟成员的运维产品进行公开评测打分，并通过类似Gartner的年度行业报告提出重点推荐，展示我们的肌肉，增加曝光率，获得商业回报。

只要这个最低值体系开放，其他运维产品就会愿意进来评估。为了获得更高的分数，他们会更愿意丰富故障注入的评估案例，同时发挥各自领域的优势，针对各个运维方向制定标准和评估。物品能达到良好的循环。这就是评价和排名驱动运维工具能力提升的魅力。

​

参考：

1、云原生背景下故障演练体系构建的思考与实践——云原生混沌工程系列指南：

​​​​

2、全链路压测：影子库与影子表之争：

​​​​