“1-5-15”原则：中国联通数字化监控平台可观测稳定性保障实践

一分钟精华速览

“只知道系统有问题，但是找不到问题到底出在哪里”，这几乎是大家都面临过、或正在面临的问题。用户在投诉，但是我的指标都是正常的，到底是哪一环出问题了？本文详细介绍了中国联通在智能运维领域的应用实践，从架构师视角讲述了如何通过构建稳定性保障体系和数字化监控平台，来支撑庞大分布式系统的端到端故障处理能力，做到故障1分钟发现，5分钟定位，15分钟快速抢通。 file 作者介绍

file

中国联通软研院副总架构师——吴天昊 TakinTalks稳定性社区特邀讲师。中国联通软件研究院副总架构师，主导中国联通数字化监控平台的整体架构设计及演进，并负责中国联通数字化生产运营保障体系的建设与落地工作。致力于完善“平台+应用”生态体系，打造联通集团自动化生产和智慧化运营的生产运营平台。

温馨提醒：本文约7000字，预计花费10分钟阅读。

后台回复 “交流” 进入读者交流群；回复“1019”获取课件资料；

背景

作为中国的三大通信运营商之一，中国联通可以说家喻户晓。每次大家去营业厅办理业务，或者在手机上交话费、月租的扣除等等，所有这些都是由中国联通软件研究院（以下简称“联通软研院”）建设和维护的系统在背后默默支撑。这套系统我们称之为cBSS（Center Business Support System），也就是集约化业务系统，中国联通也是唯一一个全国31省份的业务系统集中化的运营商。

集约化带来的好处无需赘述，但同时也带来了不少挑战——系统庞大，运维难度自然提升。作为联通软研院的副总架构师，我负责联通软研院数字化生产运维保障体系的建设和落地，包括数字化监控平台的整体架构设计及演进。我们的目标是构建一个“平台+应用”的生态体系，共同打造联通集团自动化生产和智慧化运营的工作台。

而数字化转型意味着系统的重构和升级，也意味着新的运维问题将如影随形。那么，中国联通面临的问题和挑战到底有哪些？以及如何应对？接下来一起探讨，中国联通如何通过建设监控平台，实现智能运维，提升系统稳定性。

一、联通数字化转型运维遇到哪些挑战？

1.1 一些常见的问题和典型故障

这里先列举了许多可能的问题和挑战。也想先请大家思考一下，你们是否在自己的公司、团队或个人工作中遇到过这些问题和挑战？如果你们确实遇到了这些问题，希望下面中国联通的实践经验可以为你提供一些新的思考方向，从中获得一些新的启示和收获。

file 在云原生环境下，我们也经常会遇到一些典型的故障，我这里举几个例子：

单实例故障：假设有一个服务，这个服务有十个实例，其中只有一个实例出现了问题。此时，它可能会影响到上游的很多关联服务，导致这些服务变得不可用。例如，服务的JVM出现问题，或者由于一条链路的数据出现问题，导致服务实例异常。这样的问题如何发现和定位？

下游组件故障：有时候，服务本身没有问题，但是依赖的下游组件出现了故障。例如，依赖的Redis突然出现了雪崩，或者调用的ES突然查询变慢。这些问题又该如何处理？

主机故障：还有一些问题可能出在主机上，比如主机突然死机，或者主机出现故障。这将影响到主机上运行的所有组件，甚至导致上层的服务无法提供，进而影响业务，导致业务中断或者业务损失。

外部接口故障：除了自身系统内部的问题，还可能会遇到外部因素的干扰。例如，依赖的第三方接口出现了问题。这样的问题又该如何快速发现，快速感知，快速排查呢？

针对这些典型的故障，需要有一套有效的处理和定位机制。

1.2 运维面临的挑战

中国联通的系统架构从传统的IT架构转变为云原生架构，这无疑为运维带来了许多挑战。

1.2.1 分布式架构挑战

原本只需要几个JAR包就可以提供服务的系统，现在已经被解耦为成千上万个微服务。这意味着我们需要管理和维护的对象数量是几何级增加的，这无疑大大增加了运维的难度。同时，如何梳理这些微服务之间的调用关系也成了一个难题。诸如数据分片、异地存储等这类传统维护模式也难以为继。

file

1.2.2 运维生态挑战

由于各个系统都会建设自己的运维工具，而这些工具往往是烟囱式的建设，没有进行整体的拉通，导致运维能力分散，不成体系。另外，各层面的数据（如应用、数据库、中间件、云平台、基础设施等）存在孤岛，没有进行有效的整合，这也给运维带来了困扰。

1.2.3 业务连续性挑战

故障处理过于依赖专家经验，而系统服务之间的调用关系复杂，故障分析和定位困难。此外，端到端的稳定性保障体系仍有一定的缺失，各个环节在监控、应急、巡检等方面的自动化和智能化能力还有待提高。我们还需要将故障处理从被动防御救火的状态转变为主动防火的状态，合理利用运维收集到的大量数据，提前发现和处理风险隐患。

面对这些挑战，传统的运维方式已经无法满足需求。为了保障系统的稳定性和业务的高效运转，我们提出了稳定性保障体系和数字化监控平台，用于对系统稳定性和业务连续性进行全面保障。我将详细介绍我们是如何解决这些问题和挑战的。

二、数字化监控平台整体架构如何设计？

2.1 “平台+应用”体系--生产运营工作台

数字化监控平台采用了"平台+应用"的体系结构，解决了传统运维中各个应用、各个系统不同的建设运营的问题。运维人员在一个工作台上就可以进行相关的运维操作，统一了运维入口，减少了跳转登录不同系统的麻烦。

file

平台借鉴了苹果App Store的仓库模式，将所有的应用都入驻到应用仓库里。运维人员只需要下载相关的应用，就可以在工作台页面上进行选用，无需记住多个系统的用户名和密码。它不只是由联通软研院来孵化运维应用，也会邀请其他部门、各个省份公司、子公司一起共建，共同构建中国联通的整个企业运维生态。

平台上有不同的应用仓库，里面还有不同的类别，不同的类别有不同的使用方向。通过开发者能力中心将共同的能力进行共建共享。也可以看到整个应用的使用状况，以及用户的访问情况，为整体运营提供数据支持。

平台和应用的体系进行了统一的架构，应用可以快速地通过统一的应用框架构建出来，快速地入驻到平台上，实现了统一的架构、统一的登录、统一的权限和风格。同时，应用的UI是一致的，使用户始终在一个平台上进行整体的运维工作。

目前，平台已经入驻的应用有100多个，提供PC端和移动端双终端的处理能力。移动端的使用可以让运维人员不用随身携带电脑，也不用登录VPN，实现了"咖啡运维"，即在喝咖啡的同时处理运维工作。

2.2 功能架构

中国联通的数字化监控平台的功能架构分为四层：基础设施层、基础能力层、开发支撑层和核心应用层。

file

（中国联通数字化监控平台功能架构）

基础设施层：包括分布在全国各地的数据中心，其中包括北京亦庄、西安西咸、无锡、广州和呼和等地的数据中心。数据中心分布着不同的主机设备、网络设备和云平台（CCS、CKE、阿里飞天等）。针对这些数据中心来做不同数据的采集。

基础能力层：包括权限管理（用户统一管理、菜单统一管理、租户统一管理等）、数据采集能力、统一监控告警能力、作业能力，以及AI算法能力、流程引擎能力、配置能力和即时通讯能力等。

开发支撑层：提供统一框架，实现用户统一登录和账户管理；同时通过开发者中心，为不同的应用提供通用能力，如告警能力、工单管理能力等。

核心应用层：分为运行保障类和运营响应类。其中，运行保障类包括监控管理（基础设施监控、网络监控、云平台监控等）、配置管理（传统CMDB、云化CMDB等）、自动化运维（自动化作业、故障自愈等）、变更管理（任务调度平台、变更追踪等）和测试（接收测试、自动化巡检、压力测试等）、业务连续性管理（故障管理、应急预案、应急演练等）和用户体验管理。

这四层构成的数字化监控平台可以全方位地保障数字化业务的高效稳定运行。

2.3 平台技术架构

file

中国联通的数字化监控平台的技术架构可以分为五层：

基础设施层：由联通云平台提供支持，是联通内部的企业级云平台。同时，联通云也对外提供相关输出。

容器调度层：基于联通云平台，采用K8S进行双擎的容器调度。

应用部署层：主要进行应用的整体部署。

网关层：包括内部统一框架，外部应用通过统一登录进行入驻。

前端层：借鉴蚂蚁的乾坤框架，实现微前端，独立编程、构建和部署。

在数据流方面，采用开源组件，如Prometheus采集监控指标，PinPoint采集应用调用链路指标，SDK和GS采集触点层指标。采集完的指标通过Kafka消息中间件进行处理，利用Flink进行数据处理。数据存储在ClickHouse，数据缓存在Redis，基础数据存储在MySQL、MongoDB等数据库。

纵观整个监控平台，我们通过各类基础能力和核心应用，来共同构建了端到端全层级的稳定性保障支撑，以保障业务稳定性。

三、智能运维如何落地？有哪些核心应用案例？

我将为大家详细介绍中国联通在智能运维领域的一些应用实践案例。这是我们工作的重点方向，希望能够通过分享的这些实际应用案例，帮助大家更深入理解智能运维。

阿里提出的"1-5-10"原则，即一分钟内发现问题，五分钟内定位问题，十分钟内控制损失，是一个很好的参考标准。在这个原则的启发下，中国联通也制定了我们的目标，即"1-5-15"原则：1分钟故障发现，5分钟内故障根因定位，15分钟故障快速抢通。为了实现这些目标，我们分析了六个核心场景，来指导我们的工作。

file

接下来，我将逐一说明中国联通如何通过这六个核心场景，实现故障的快速发现、定位、调度、处置和整改，以及预防。

3.1 统一监控告警

首先，要明确需要监控的指标，以及这些指标涵盖哪些内容。

file （中国联通监控指标及涵盖内容参考）

针对这些全层级的监控指标，需要了解每个指标的定义和标准。为此，中国联通软院制定了364项的全层级指标规范，包括每个指标的推荐配置、必须配置的指标、每个指标的配置阈值等。

根据这些规范，让系统进行接入，以确保全面的监控覆盖。那么，如何让这些指标实现互联互通？我们采用Prometheus等工具进行监控数据的采集，并按照系统和租户的维度进行监控，以实现不同层级指标的统一管理。

file

我们的目标是打破传统的分散管理模式，实现数据的统一汇集和管理。在这些数据的基础上，借助不同工具可以实现全层级的监控告警功能。

比如，有统一的基础指标监控平台，可以监控核心业务指标、中间件指标、数据库指标、基础资源指标、容器平台指标等。还有统一的告警平台，可以统一发送告警信息。

在服务层面，使用全流程调用链进行数据采集和展示，并将相关告警推送到智能监控报警平台进行统一处理。

在前端触点层面，使用APP性能监控和PC端前端触点监控工具，以提供全面的监控告警服务。

3.1.1 工具1：智能监控告警平台

智能监控告警平台是依据全层级的指标规范进行统一的。例如，针对MySQL出现的采集情况，只需要用户输入MySQL的IP和端口，和只读用户的密码，就可以进行MySQL的指标采集。同时，也会将需要告警的指标进行套餐配置，如希望采集MySQL的运行状态、连接数、表空间等，只需要勾选，即可自动采集。

file

接下来，会进行告警的推荐配置，设定告警规则，例如，当某个指标超过阈值时，就会触发告警。同时，为了避免某些指标抖动可以做一些告警抑制的动作，比如持续2分钟后进行告警。

当在版本发布时的会产生一些告警，可以设置告警静默进行统一的静默处理，可以针对全量监控点或某一项监控点进行静默。

如果出现告警，会生成一个告警工单并通过短信、钉钉以及外呼的策略通知值班人员。告警工单分为普通级别、重要级别和紧急级别，普通级别的不需要立即电话催办，而紧急级别的会立即进行外呼。值班人员收到告警后需要点击签收，处理问题后再点击处理关闭。如果一直不签收或不处理，会一级一级的进行升级，直到打到领导层面。通过这样工单闭环的模式，实现告警的处理。

3.1.2 工具2：全流程调用链监控

这是在应用链路复杂的情况下，帮助判断应用是否存在问题的工具。我们采用基于PinPoint探针的非侵入式字节码注入方式进行数据采集，只需在启动时添加一个参数，就能采集Java应用的调用量、耗时、异常等黄金指标，并转换成可以使用的指标进行告警。

file

通过调用链路，我们可以判断应用之间的关系，定位底层故障在哪个应用层面上。调用链路是自动生成的，如果出现问题，应用层面会变红，我们可以立即看到哪里出现了问题。点击有问题的应用，可以看到它的上下游调用以及为什么变红。每分钟都会进行数据聚合，通过这种方式，可以看到整个服务的调控趋势。

我们还可以看到有哪些报错，包括业务报错和系统报错，例如连接超时的异常或业务规则限制导致的异常。我们会区分这两种异常，针对系统异常进行告警，业务异常则进行服务治理。

如果一个服务下有多个实例，一个实例出现问题，其他实例没有问题，就可以通过重启该实例解决问题。把调用链路和云化CMDB关联起来，就能知道实例所在的容器和主机以及占用的端口，然后进行关联。

有了云化CMDB，可以采集到云平台的资源情况，如容器的内存和CPU，主机的负载、CPU内存磁盘等，判断是否主机或容器的异常引发了服务异常。

另外，还可以看到服务之间是否是因为JVM或者GC的问题导致了实例不可用。

支持多维度告警能力，例如，当调用量降低20%或超过20%就进行告警；或者当超时3秒的比例大于5%或者超时1秒的比例大于10%就进行告警。这种多维度的、可配置的告警规则可帮助应用系统快速地配置监控告警规则并推送到统一的监控告警中，以便快速发现问题并通过调用链路进行问题定位。

3.1.3 工具3：跨系统分布式追踪

以上是单系统的调用，那么跨系统的调用拓扑是怎么做的？基于刚才提到的PinPoint探针技术，我们实现了跨系统的监控，包括跨云平台监控（CKE/CCS/EDAS等）。我们对探针功能进行了增强，以支持跨数据中心的链路拓扑监控。我们在各个数据中心和应用中进行整体的埋点，通过标识出不同的租户和系统间的关系，进行跨数据中心的分布式计算。然后，在各个数据中心进行单元化的支撑，并通过弹性拓展，将分布式计算的结果汇聚起来，形成跨数据中心的链路拓扑。

在亦庄主数据中心，进行汇总和串联，这样就可以看到不同系统之间的调用关系。例如，一个系统在调用另一个系统，我们可以看到这两个系统的标记，说明它们之间存在调用关系。这就实现了跨系统的实时追踪能力。

3.1.4 工具4：前端触点监控

采用JS埋点的方式，采集用户在访问过程中的性能指标，从而获取浏览器端真实的用户行为。例如，可以在用户访问页面后获取用户的行为数据，包括用户在什么时间访问、使用哪个IP、在什么地点以及使用哪个系统和浏览器。此外，还可以获取用户的具体操作，如打开页面、访问接口或弹出弹窗等。这样，就可以实时采集并获取用户的真实行为和体验数据，包括加载、点击、弹窗、JS报错等用户全轨迹追踪。

一旦发现页面响应时间过长，或者AJAX响应时间过长，或者弹窗数量突然增多，就会及时进行告警，因为这可能表明系统存在问题。同时，还可以进行故障定位。

此外，还可以通过收集工号的行为来进行分析。例如，如果有工号在频繁访问某些页面或进行同样的请求，就像机器人或爬虫一样，就可以判断出它在进行不正常的行为。这样，就可以进行安全分析，并有效地进行安全治理。

3.2 一键智能诊断

基于刚才以上提到的各类监控工具，如何有效实现统一的智能诊断呢？

file

首先，可以将调用量超时异常转换成指标，通过链路了解整个调用关系。通过增强探针能力，可以获取到异常日志、请求报文和响应报文，从而进行整体关联。因此，有了这样的关联，可以通过指标发现问题，通过链路定位问题，并通过报文和日志判断问题的根因。通过这样的三位一体的可观测性，可以实现故障的发现、定位和根因判断。

3.2.1 一键诊断流程

file

如图展示了一键智能诊断的流程。当我们发现开户业务出现报错时，利用图数据库关系，从150个服务告警中，定位到是服务X出了问题，继续通过核密度估计算法和DBSCAN聚类算法，判定该服务的3个实例中，是实例x3出现了问题。再次扫描根因服务调用的组件调用链指标、组件指标等，从多个集群中判定到根因组件是Redis 2。继续进一步检查是否某个节点、某个主机甚至交换机出现问题……通过这样的全层级贯通，可以实现一键智能诊断，快速端到端地定位问题。

3.2.2 典型故障诊断案例

目前，中国联通一键智能诊断准确率大概在70%左右。以下是一些系统案例截图和故障类型案例。

file （后台回复“1019”获取讲师课件，查看大图）

3.3 智能故障自愈

收到告警信息后，会有相关的自动化作业进行处理。这些自动化作业是由运维专家根据运维场景，提前编写并封装在自动化作业平台中的操作脚本。然后，通过AI智能引擎判断是否有异常，并自动调用整个作业能力进行故障自愈，从而节省故障处理和恢复的时间。

file

3.4 故障闭环管理

在事前阶段，我们会编制全面的应急预案，并定期进行应急演练。这些演练不仅有助于我们预防故障，也能确保应急预案非一纸空文，而是真正可执行的。我们会进行桌面演练和实操演练，前者用于检验流程的有效性和响应速度，后者则用于验证应急预案的执行能力和预期效果。通过这些演练，可以提升整个应急预案的可用性。

file （点击查看高清大图）

在故障发生阶段，主要通过监控告警、巡检、省分报告、客户投诉和舆情等方式发现故障。一旦发现业务SLO被触发，将进行故障上报，并通过一键拉会功能召集相关值班人员进行会议。这些人员包括故障调度负责人、业务负责人、技术负责人、信息通报负责人和信息记录负责人，他们各司其职，确保故障得到及时、有效的处理。

在故障结束后，我们会进行故障改进。在24小时内进行标准的故障复盘，在2个工作日内完成故障报告编写，包括故障信息、根因分析、操作处置流程及问题整改措施等内容。在10个工作日内，我们将对故障进行演练，并根据出现的问题进行整改闭环追踪。

以上就是我们在故障的事前、事中、事后全生命周期的线上闭环管理方式。

3.5 智能隐患分析

将监控指标和容量指标相结合，定期进行容量隐患评估。首先，我们需要制定容量标准，包括在业务层级、服务层级、组件层级以及资源层级上建立相关的容量水位模型，形成标准制定。

其次，我们会通过全链路压测，借助工具手段判断链路上是否存在性能瓶颈。压测分析不仅可以评估当前是否达到预定的容量水位，还能观察链路上是否有耗时增长、是否存在重复调用、线程是否已达上限、连接池是否已满等问题，从而全面分析整个链路的性能瓶颈。

我们还需要建立一个健康度模型，通过全层级指标分析，识别系统是否处于亚健康状态，进而判断相关的高、中、低风险，并进行实时系统体检，用以推送隐患报告，进而实施问题隐患的整体闭环整改。

3.5.1 系统亚健康诊断案例

下面分享一个系统亚健康的实践案例。通过全层级指标，包括网络层、平台层、组件层、服务层及触点层等不同层级的黄金指标，运用AI算法分析来建立健康度算法模型。例如，如果CPU使用率超过90%，将发出告警。但如果CPU使用率一直维持在80%左右，即使没有达到告警阈值，也能通过风险等级判断其为高风险隐患，从而识别出是否为亚健康状态。

file

通过全面的隐患分析，可以实现系统健康状态的档案化管理。可以通过日、周、月等不同的时间维度来统计系统问题和风险情况，观测系统在各个阶段的运行情况。也进行实时的系统体检和计算，通过不同的阈值判断指标异常以及风险程度。

还可以进行版本前后的性能对比。例如，如果版本更新前有10个风险隐患，更新后增加到20个，那么此次更新就是失败的，因为它增加了风险隐患。我们需要提前规避这些问题，提前治理。如果风险隐患减少到5个，那么这次更新就是有效的，可以看到它解决了哪些风险隐患。通过不同时间段的对比，可以看到整个系统性能变化的趋势。

还可以定期自动生成体检报告，通过工单形式发送给相关系统的负责人，让他们明确了解系统的风险隐患以及如何进行治理。体检报告会列出相关风险指标，并提供解决方案，助力提升整个系统的稳定性。