技术干货 |如何保障 IM以及音视频的系统稳定性、安全性、可靠性？看这篇就懂！

在当今快节奏的商业环境下，to B 行业客户对产品质量的要求越来越高，尤其是对于 IM 及音视频服务端稳定性的要求更加突出。随着技术的不断进步，这些服务的使用量不断攀升，因此稳定性建设显得尤为重要。从技术角度上，需要重视系统性能、可靠性、安全性等方面的提升，在流程上需要建立完善的开发、测试、部署流程，以确保服务端稳定性的提高。同时，需要加强对于系统监控、故障排查、灾备恢复等方面的投入，避免服务中断、数据丢失等情况的发生。在这样的背景下，to B 行业企业需要深入了解客户需求，持续优化产品质量，不断提升服务端的稳定性，以满足客户追求高品质服务的需求。

戳我了解云信详情~

那么云信到底是用什么手段来保障服务的稳定性呢？其实整个网易数智都做了不少探索。我们有一套系统成熟度的评估体系，认真执行了各业务线的评估，掌握了系统的不足，同时做了非常多的改进措施，并且形成了预案及演练的一组常态化操作。在这个过程中收获最大的结论是：故障驱动的手段来进行稳定性建设，是最行之有效，也是最省资源的方法。以下的篇幅单从故障驱动的思路来行文。

依赖故障驱动的主思路，在 Google 等一些大厂的实践经验的指引下，结合云信业务现状，保障内部 SLA 达到四个 9，无  P0、P1 故障，内外部客户口碑树立，并制定了一系列的行动。如下图：

度量它，才能管理它

服务水平目标（SLO）的建设目标是为服务或产品定义可衡量的指标，以便客户或用户能够了解所提供服务的质量水平。可以帮助团队跟踪和监测服务的质量，以便在出现问题时能够及时进行纠正。可以帮助团队做出更好的决策，以便在资源有限的情况下，优先考虑对用户最有价值的功能和服务。可以帮助团队与客户或用户建立信任和透明度，因为 SLO 可以让客户或用户了解服务的质量水平，并且可以衡量团队是否遵循承诺。

 现状说明 

在云信的系统服务中已有很多的服务监控，大盘数据，业务指标等，如下图。这些多半是研发同学根据自己所属的业务需要建设的一系列的数据感知能力，作为内外部友好沟通的窗户与桥梁。它能非常直观的或是早于客户发现系统层面的问题。但是是点状的，无法成体系的拉通观察或总结整体服务质量水平，无法从全局来度量它。从我们全年预设的目标来看，要客观评价对内的 SLA，就必须得建立一套客观度量体系。于是我们就从服务水平目标（SLO）开始了。接下来重点围绕 SLI、SLO、SLA 的一条链路的建立具体讲一讲云信的实施落地。

因为云信研发团队是一个稳重且靠谱的组织，要拉通一个全局性的规则落地，就必须让大家有认同感。只靠个别人的理解与宣导是无法达成的。首先管理层下定决心从组织层面对其的重要性和必要性进行了宣导。其次也引进了业内著名的 SRE 专家。再者共同参考了《SRE Google 运维解密》、Define SLOs、Adopt SLOs[3]、Service Level Objectives[4]、Implementing SLOs，网易内部游戏、音乐、电商等兄弟部门的最佳实践。也做了一些头脑风暴，最终形成了贴合云信自己业务的一套方法论进行了落地执行。

 指标建立 

参照对外的 SLA 服务标准，我们先制定了一套内部的故障定义规则：事故损耗可用率时间 = 事故时长 * 影响用户数在云信整体占比 * 服务重要因子。然后制定了一套内部 SLA 可量化的规则，需要各业务梳理出核心、次核心、非核心的业务流程和功能及其涉及到的服务。然后梳理出能直接反映核心功能健康度的接口级监控指标，例如业务的成功率、延迟等，建立黄金指标（核心）。

站在业务的角度，对用户请求的全链路设置监控项，监控完整的业务流程。监控的项目一般是成功率和延迟，建立业务指标（全局）。这个指标需要有全链路的基础数据或平台作为支撑。

针对单个服务的监控。包括服务进程的存活，进程所在容器或虚机或物理机的系统指标：CPU、MEM、DISK、NIC 等。还有对外提供的服务的健康程度的监控，例如错误日志的监控、成功率、错误数等。同时还包括该服务调用下游依赖服务以及中间件（KV、MQ、DB）的成功率，延迟等指标，建立服务指标（单服务）。

系统指标，这里是指 IAAS 层，和 PAAS 层服务的监控项目，一般业务不关心，SRE 和 PE 及 SA 会关注。例如虚机和容器的底座 K8S、openstack；KV、MQ、DB 等基础服务；接入层 Nginx 集群；公网 DNS；第三方的 CDN；中心 IDC 机房的公网入口等的监控。建立系统指标（IAAS、PAAS 层）。这个指标在此之前已有告警指标。

针对一个业务线建立一套 SLI/SLO/SLA 的指标体系到落地，从 2022 年 8 月份开始操作到完成，花费了巨大的时间成本。具体操作流程是，先讨论确定方案，进行 SLO 拆解，如下表，这个表需要研发与 SRE 共同制定并认可。

接下来就是分到模块负责研发同学进行各自的模块梳理，产出可行动文档，文档包含服务概述、服务分级、SLI 选择（需要充分讨论）、SLO 定义、5XX 错误码梳理，进行组内评审、定稿、开发、数据源输出。如下图：

 指标呈现 

数据指标直接输出到日志，或消息中间件，或自有采集端，这个根据不同业务形态自由选择，最终传递到数据分析平台，有了数据源之后就有了稳定性平台-SLO 目标模块的一个架构思路，如下图：

可观测可评价的一套工具就由此开始了。建立了应用状态灯机制，以业务线->应用状态等级（P0，P1）为维度的应用状态观察。分红、黄、绿灯，可以实时的反馈应用当前状态。一个应用有可能有多单元集群或大客户集群，又建立了集群消耗的不可用时长。集群消耗不可用时长主要根据两块来计算，其一：集群 SLO 告警历史数据，其二：由成功率+延迟+加权折算计算公式，数据源最终展现成可读数据，便是通过告警历史来进行展现，是粒度最小的，这个告警的实时性比较高，一般告警出来必然有 SLO 的折损，所以研发及运维同学十分关注它。有了以上实时性的观测指标就可以计算出天级消耗，周、月、季、年等周期可用性指标。力求做到有故障必有 SLO 告警，当发生 SLO 告警必须关注并能产生优化代办项的实际驱动价值。

当有了度量手段只是一个开始。上述内容就是基于整系统纬度的成功率等相关指标的一个量化。当说起对外 SLA，用户体验感受层面的量化，观测用户活跃程度，超高频用户等对成功率的影响，可以研究 Google 的这篇论文：Meaningful Availability[6]，对外的 SLA 云信也挑选了类似登录成功率等相关指标进行了量化。要有力的故障预防与驱动就必须管理它，接着往前探索。

管理它，才能分析它

故障管理系统建立的目的是为了在系统运行过程中及时发现、记录、跟踪、解决和预防故障，以确保系统的稳定性和可靠性。可以帮助收集、分析和统计系统的故障信息，从而发现故障的分布规律、故障发生的原因和故障的趋势，为系统优化和改进提供数据支持。同时，可以帮助识别和分类故障，并建立故障处理流程和方法。再者，还可以帮助进行故障预测和预警，及时发现并解决潜在的故障问题，降低系统故障率和停机时间。

 现状说明 

我们会在一个阶段进行一次线上故障的梳理与分析，以及 SLO 的达成情况进行分析。怎么才能更好的集中管理故障，进行问题集类分析？早在年初目标制定时我们手动分析了一波 2021、2022 年的所有故障与事件。发现确实有不少共性问题。这些问题都可以抽象出来做一次性的整改。下图是手动分析的一些资料样本，但是手工统计这些确实是有一些费时费力。

 系统建立 

于是就有了自己的故障管理系统。围绕故障整体生命周期，辅助研发运维人员提升故障发现、故障处理分析、故障复盘的效能。其中故障发现来源的异常事件处理，关注全自动的告警，半自动的 OnCall，人工发现的异常现象进行升级处理，关联故障报告。故障处理提供故障处理过程中基于 Timeline 的信息查询。故障复盘包含三块：

• 故障报告：聚焦故障处理结束后的复盘工作，通过标准化的报告记录，可以辅助回顾故障发生，处理过程中的问题，总结出更有效的改进。

• 故障改进：聚焦故障的改进措施，辅助推进改进的合理排期和快速落地。

• 数据统计：提供基本的统计分析功能，通过数据挖掘故障。

如下图：

当发现 SLO 有比较大的波动时，OnCall 系统感知变化后可以自动创建事件或事故单。当确认是事件时，可以手工或自动调用故障查询工具来立即查询出当前的影响状态。如：核心功能 受影响应用、用户比例，TOP 应用或前向同学关注的应用，以及功能纬度受影响的应用与用户比例。有此数据可以快速判别事件的影响情况。如下图：

分析它，才能建设它

故障分析的目的是为了深入了解故障发生的原因和机制，从而制定更有效的故障处理策略。通过故障分析，可以找到故障的根本原因，避免仅仅解决表面现象或者症状，导致问题反复出现。也可以制定更深层次的系统优化行动项，将顽疾连根拔起。还可以从中发现突出问题列出专项重点整治。同样可以制定基线值指标作为下一阶段的具体行动方向，一定周期内拿实际结果与基线值指标对比查看达成情况来评判稳定性建设成果。

 分析过程 

通过故障管理系统，我们可以做一些故障分析。针对云信整体的情况，我们发现每个季度每条业务线的故障数比较稳定在 N 个以内。于是我们把 N 定为故障个数的基线值。通过减少故障数量来促进稳定性建设。

通过以下模型又进行了具体分析：

 基线值确定 

得出如下表格：P0 - P4+事件，通过四分位计算+专家判断方法得出故障的几个时间节点，定为基线值。专家判断是根据实际情况剔除可避免的长耗时。在 H2 的整个生命周期都围绕着它进行改进。

 客观行动项 

通过基线值的确立，分析得出一些客观的行动项：运维发布、人为操作、三方依赖。如果这几项内容能在后续的故障中杜绝，就能很确定的达成目标。下图为故障管理系统的分析结果。得到如下行动项：

• 变更管理规范，常规变更与标准变更应加强落地，完成变更管理平台的上线及各工具的接入，降低人为误操作的影响。Overmind 研发全生命周期流程工具推荐在云信推广使用，降低标准变更引发的故障率。

• 三方依赖事项，完成 15 分钟无法恢复问题列表的分析，需协同杭研公技及运维部门完成中间件的稳定性体系建设及高可用监控与改进。

• 功能及性能缺陷，需研发配合 QA 进行研发流程的精细化管理，针对研发规范及测试卡点新增动作和目标。

 主观行动项 

通过基线值的确立，分析得出一些主观的行动项，这些主观的行动项虽然主观，但是它也代表了要达到 0-1-5-10 这样一个目标的一种具体行动路径，是一个长期的建设过程。

• 故障发现时长：通过系统告警，业务告警，SLO 告警，链路异常告警等纬度的感知数据作为核心指标继续建设。

• 故障响应时长：通过 OnCall 工具的拉通可以建立起一条畅通的告警发现，问题响应，上传下达的半自动人工通道。

• 故障定位时长：通过告警诊断，自动诊断，人工诊断等手段缩短定位时长。

• 故障处理时长：通过建立起快恢中心，使有预案且能快恢的场景能做到工具一键快恢。

 预案情况 

预案覆盖率，有助于故障恢复的速度提升，凡是有预案 95% 以上都能快速恢复基本都从故障转为事件了，凡是无预案基本都是 P0-P4 故障（80%），恢复时长基本 300+（平均 2 万+）分钟以上，但预案的可操作性还有非常大的空间，下图为分析结果，得到如下行动项：

• 通过告警+SLO+OnCall 轮值的一条通路,建立起必要预案制定+演习+快恢脚本沉淀，分配并落实指标。

• 改进告警和 SLO 及与 OnCall 的关系，通过工具强关联三者，让 OnCall 的工作数据化。

• 建立云信自己的预案工具系统+快恢系统，做到部分故障可半自动或全自动恢复。

不管是客观的，还是主观的，只要在有限的成本预算下，多做一点，就可以多避一点坑。秉承着这一原则，我们开启了一个稳定性专项，开始建设它。期望着一个好的改进结果。

IM 即时通讯 - 稳定可靠的通讯服务 - 网易云信

建设它，才能改进它

不管是 SLI、SLO、SLA 的建设，还是故障的分析管理，它仅仅是一个观测和评价的事后管理过程。它只能让我们更了解整个系统的当前运行状态及历史状态以及未来的趋势。无法让我们的系统在未来的某一个时期更加的稳定。但是这个管理过程能使我们得出一些分析结果，正如上述的改进项。通过这个分析结果与改进方向来规范流程及建设工具来监督与优化我们的系统服务，持续这个过程，我们将可以对未来产生期待。本文通过几个典型工具来满足短期内的建设需求。

 变更管理工具 

首先建立了一套云信银河变更系统，为什么要建立变更系统？为什么不用 KF？有何区别？它能做什么？能解决什么问题？下面一一回答。

上面的故障分析结果得出：人为变更、运维发布及流程性问题。

在云信故障总占比中占据重要位置。我们先是立口头协议，但是不同的人在不同的环境下操作起来仍然缺乏有力的宣导与约束。后来就有了文件上的《变更管理规范》在各种场合上推行，发现力度仍然太弱。后边就想着用工具来强制卡点规范作业，于是就有了这个系统。KF 是基础变更工具，目前处于维护阶段，无法新增需求，现有无法做到与云信已有工具做更好的融合。它能做到与现有的界面管理工具、命令行无界面工具做到无缝结合，为现有工具集提供变更流程卡点环节，为线上变更提供安全性。如下图：

目前各个组内的变更平台囊括云信的多项变更功能，例如各平台配置中心、RTC 配置下发、授权、SDK 发布、IM 频控和山茶花配置等。这些功能涉及在线上配置参数的修改和调整。然而，在当前的修改过程中，大多数情况下缺乏流程卡点和新老参数对比功能，这会导致误删或错误修改等问题的发生。如果出现这些问题，很难进行纠错和追溯，从而大大增加了事故发生的可能性。为了解决这些问题，应该在这些功能的上层添加审批流程屏障，以提高修改配置时的二次确认能力，降低错误操作带来的风险。

系统架构设计如下，即一个标准的流程引擎外加自有业务的定制，将所有与流程相关的系统都可以无缝地结合，支持动态配置、能力接口自适应配置接入、复杂场景可以做到线上发布流程、应用编排，后期应用于海外一键发布等快恢工具流程中去。

 OnCall 工具 

建立了 SLO 目标监测体系之后，为了更快的得到告警响应，又建立了 OnCall 流程机制，定了轮值时间表，但是经过一段时间的运转发现响应积极性逐渐变弱，为了加强整个流程机制的运转，建立了北斗 OnCall 平台，可能世面上没有这个工具，基本上都是和事件系统或者告警系统关联的。我们建设的思路是从医院医生开病理单，诊断过程等一条龙服务流程的灵感而来。研发或运维就是医生，OnCall 工具就是那个开病理单的系统。这么听起来不那么人性。但是一整个诊断的过程确实都记录下来了。虽然有些手工的工作在。但为后续的自动化打基础，设定了如下目标：

• 事件轻量录入、分析、统计。可人效分析及为系统改进助力。

• 强化 OnCall 人员对于告警的响应与处理意识，缩短故障的发现时长、响应时间。

• 与故障系统打通，告警便捷转故障管理记录 MTTR，可应急通告。

• 针对清淅排查流程可转换为自动诊断、初次烦锁、再次自动得根因。可运维提效。

• 与自动诊断系统打通，为人工 OnCall 减负，可提高 OnCall 效率。

• 与预案及快恢系统联动，无法做到自动快恢的案例，人工判断后可一键恢复，缩短故障恢复时长。

• 与知识库联动，为知识库提供最佳实践案例，可借助知识库快速定位重复问题，可提高 OnCall 效率。

下图为 OnCall 平台的核心处理逻辑，以人为本，以告警群为触发点，以同类问题自动诊断为核心，以未知问题人工分析与轻量录入为补充，以事件/故障半自动记录+故障应急通报为功能增强，以确定预案故障一键快恢为终极目标。贯穿故障整个生命周期。

 代码合规工具 

针对研发规范相关，目前落地了一款 CodeReview MR 合规工具，借助于 gitlab 的 merge request 功能和 hook 事件机制，完成了提交代码的控制，多人 review，通过提交审批流程进行最终的审核与合交确认。让整个代码的合入有充分的相互监管。避免操作自己不熟悉的模块时非标准操作的问题存在及及时修正。同时也会对合规情况进行统计输出，并每周晾晒做得优秀的与不达标的。当然在研发流程上的卡点远不止这一个，比如云信已自建的 CI/CD、Hawk、Marvel 等平台。都是为了提高研发流程规范与效率的有力工具。

 快速恢复工具 

为了使一些固定的场景缩短恢复时间，准备建立自己的快恢平台，针对 RTC CID降级、CDN 熔灾、大网降级熔断、IM 与 RTC 的一键扩缩容等功能。针对快速恢复，要么场景及关联关系非常简单，要么就是有十足的前期准备条件。比如：快恢的可执行接口的可用性与安全性，会不会因为它的问题导致事情适得其反？再比如：快速平台的可靠性，是否能博得业务线同学们的信任。平台当前处于规划阶段，业务先行，提供可靠安全的 OpenAPI 供平台调用。快恢要想安全稳定成体系的执行必须得和预案关联起来，如下图诠释了一个查找到预案进行执行的一个标准系统流程：

 诊断定位工具 

为了使一些全局场景或已知场景缩短问题定位时间，准备建立故障诊断系统，针对 IM 的全链路故障的诊断与定位。目前已部署全链路追踪系统提供全局链路采样的数据源，服务日志数据源，业务上的自我依赖诊断的数据源，变更事件等信息源，相关数据源准备阶段。方案已制定，待实施。

 容量管理工具 

每个业务都有一个业务峰值时段，有些业务因一些大客的接入，事先无法非常清晰的预估流量，导致流量急增，达到系统瓶颈，最终引发故障。为了避免以上问题，正在建立容量评估工具，要达成的目标如下：

• 可以准实时（5 分钟内误差）预估系统容量：给出结论意见：xx 应用当前共 x 台物理机，x 台云主机，x 个容器 pod，当前水位：60%，上限水位：80%，单节点（分主机类型）可承载 20万 连接（或 1 万 TPS），整集群当前水位 500 万连接（200 万 QPS），还可增长 20%（100 万连接）或下线 x 台物理机（x 台云主机，x 个容器 POD）。

• 可缩容预警及缩容方案推荐：推荐分批下线批次，给出分批下线的服务主机列表。

• 需扩容预警及扩容方案推荐：当到达上限水位时，自动触发告警，给出扩展主机规格和个数。

• 可以按照指标项展示细粒度的系统指标：CPU、MEM、IO、网卡流量、带宽、PPS、TCP。业务主观指标（基准值）。

改进它，才能消灭它

通过故障驱动的思路来建设系统稳定性。能提高故障响应能力：可以帮助研发运维更快地响应故障，迅速定位问题并解决问题。强化故障预测能力：通过对之前的故障进行分析，我们可以发现一些潜在的问题，并提前采取措施避免故障的发生。加强故障分析能力：可以帮助我们更加深入地分析故障原因，从而不断完善系统的设计和运维流程。促进持续优化：可以帮助我们不断改进系统，累积经验，提高系统的可靠性和稳定性。

当然这种思路也有一些弊端。容易陷入被动：故障驱动的思路容易让我们陷入被动，等待故障的发生并进行处理，而不是主动预防故障的发生。重视短期效果：故障驱动的思路容易让我们重视短期效果，而忽略了长期的系统稳定性。容易忽略非故障因素：故障驱动的思路容易让我们忽略一些非故障因素对系统稳定性的影响，如人为因素、环境因素等。

所以我们在实施的过程中必须虚实结合，从主观上也能采取一定的行动，才能扬长避短，可能不好量化，但是只要用心的做了就会产生效果。那么它的结果怎么样呢？有没有产生好的效果？且听下回分解。路虽远行则将至，事虽难做则必成！

以上是今天跟大家分享的干货经验，希望能带来一些帮助~

附上干货资料可查看领取或✉LTT936

《网易数智年度技术精选合集》

《2023泛娱乐出海白皮书》

《2023年全球即时通讯（IM）PaaS市场洞察白皮书》

戳我立即推荐好友，取更多豪礼~

更多干货合集，等你来收获~👇