如何在数改浪潮下持续保障业务稳定性、连续性，一直是政务云客户非常关心的问题。在第八期阿里云用户组（AUG）杭州站活动中，阿里云高级产品专家付来文（郁松）从阿里十多年稳定性建设过程中遇到的问题和痛点谈起，以浙政钉为最佳实践案例，讲解了如何通过一站式运营运行管理中心（ZOC），帮助浙政钉打造了高质量的基础设施，有效保障了浙政钉的稳定运行。阿里集团稳定性建设的挑战
相信大家一定会好奇，阿里巴巴各个事业部、各个业务模块，如此大的业务体量、业务链路如此复杂、并且全面上云的情况下，是如何做好稳定性的。在支撑淘宝、天猫、支付宝、菜鸟、钉钉、阿里云等业务快速发展的过程中，阿里集团投入了非常多的技术、人力资源去保障业务丝滑体验背后的稳定性，并且经历了从关注基础设施的稳定性逐步转向关注业务连续性的过程。本文将围绕我们在阿里的稳定性建设最佳实践经验，结合我们沉淀的产品、服务、规范、运营体系，讲述如何更好地服务浙江政务云上的业务应用。阿里稳定性建设过程中遇到的问题与痛点
我们对阿里集团稳定性建设过程中遇到的问题及痛点进行了总结提炼，在跟云上的很多客户沟通时，我们也发现这些问题有一定的代表性，很多厅局也遇到过，只不过影响程度上有差异。阿里遇到过的这些问题痛点，在我们 10 多年的实践下，沉淀了对应的解决方案，并取得了一定成效。
应急协同困难，无序易出错
组织发展到了一定规模后，各个团队职能分工越来越专业、越来越纵深，遇到故障时往往需要协同大量团队人员进行排查定位、处置恢复，而业务体量越大，往往同一时间会发生多个故障/问题，如没有成熟的应急流程及协同机制，整个故障处理将会变得无序，并且发生处置操作“撞车”的情况。整个组织需要有 1 套包含处理优先级及影响程度的故障等级定义、涵盖各个角色职能的应急流程、统一问题处理信息的协同处理平台，来将所有人的专业能力串联起来。 现问题滞后，导致故障影响
快速地发现问题，是解决问题的第一步。任何问题延后 1 分钟处理，带来的业务影响可能都非常大，如电商 GMV 的影响、民生应用异常引起线下排队等。需要建立一套完善的监控体系，确保能够先于用户发现问题。 故障未闭环管理，导致故障重复发生
生产环境的每个问题/故障，都需要在复盘后进行结构化的沉淀，明确责任及改进动作，并结合数据运营机制闭环管理，不断提升生产环境稳定性，形成统一的故障管理体系。 问题处理经验未沉淀，导致处理问题低效
专家经验是非常有价值的组织过程资产，结合日常问题及故障的处理经验，形成可复用的知识体系，基于 CMDB 及算法进行关联，提升问题及故障的处理效率，降低运维新人的上手门槛。 运维/研发随意变更，导致出现人为故障
变更是引起生产故障的主要来源之一，对于生产环境的变更要保持敬畏之心，避开业务高峰期，严格评审变更方案，变更过程中做好业务观测，降低因变更带来的业务影响。 运维操作不当，缺乏工具规范管控，导致出现低级问题
所有的规范均需要产品工具的支撑，才能确保可落地性，否则就是“纸上谈兵”，容易出现低级操作事故。阿里稳定性建设经验在厅局数改中的应用
在支持浙江政务云的过程中，我们也一直在不断的探索跟实践：浙江政务云作为基础设施在支持好数改应用的前提下，如何更好地提升民生核心应用的业务连续性。
我们将阿里稳定性建设沉淀的经验，抽象为事前、事中、事后三个环节：事前做预防，把可预见的故障消灭在业务影响前；事中做快速恢复，对于已发生的故障，先恢复再排查根因；事后演练强化，落实改进措施，杜绝重复故障的发生。我们不能简单地将阿里沉淀的体系照搬到政务云，每个业务都有各自的特性及差异，需要结合政务云应用的实际运行情况“因地制宜”，所以我们最先对政务云上某核心应用的稳定性建设进行了探索，并在此过程中沉淀了适配政务云应用的稳定性体系。政务云核心应用稳定性建设探索及优化
政务云核心应用稳定性体系的建设，项目历程从去年的 5 月份到 11 月份初步建成。建设的周期跟应用本身的复杂度、稳定性建设的深度、业务连续性要求的高度都强相关。
首先是项目准备阶段，针对稳定性建设目标进行逐层拆解，明确项目计划、风险及需要的资源支持。- 业务梳理分析阶段，主要对政务云核心应用业务模块进行访谈、梳理，输出业务功能的结构树，后续的监控、事件、故障、人员协同均将基于这个业务功能结构树进行关联，形成业务 CMDB。
- 产品工具部署阶段，针对需要的产品工具进行资源评估及部署。
接下来进入并行进行机制及监控体系的建设，包括故障等级定义、应急场景、业务监控、应急机制等建设内容，由于整个体系监控建设尤为关键，需要结合业务进行逐个梳理，因此跨度周期较长，可通过业务的监控覆盖率作为过程指标进行考核跟踪。
在业务 CMDB、机制、监控建设完成后，进入试运行阶段，对稳定性相关的运维研发测试运营管理等角色人员，进行宣导、贯彻执行，过程中不断优化机制流程。最后进入持续的数据运营阶段。任何应用的稳定性建设想要得到质的提升，没有“一招鲜”，需要基于各个阶段所沉淀的结构化数据，进行数据化运营、分析，包括改进措施的制定、完成、演练，结合故障案例的稳定性宣导，对故障关键指标数据进行横向对比、分析，过程中为了更好地保障稳定性不断改进产品工具。所以要做好应用的稳定性，光从云的角度看还远远不够，需要从应用组件、业务模块、用户使用等维度去做综合性建设。一站式运营运行管理中心（ZOC）
基于政务云核心应用持续的建设、探索、实践，并取得了成效后，我们结合政务云应用的特色，进行了梳理总结，形成了一整套政务云特色的稳定性建设方案：一站式运营运行管理中心（ZOC）。整个解决方案以技术产品、规范机制、专业能力三大维度构成，源于政务云核心应用的实践场景孵化，接下来将以浙江政务云为底座，结合 ZOC 能力，助力各政务云应用从云平台运维升级至业务连续性保障，拉通全省重点业务监控及运维能力，共同支撑好浙江省数改应用的高质量发展。
其中 ZOC 技术产品包含监控、工单、事件、日志分析、APM、知识库、数据运营、AIOPS 等产品能力，监控系统用来发现系统层面的问题，工单系统用于收集管理用户使用问题，应用性能监控系统用于发现应用自身运行性能问题，日志分析系统用于进一步定位异常根因，所有问题基于统一的事件及故障系统进行协同及信息流转，并打通知识库进行关联推荐，加速定位及解决效率，底层基于 CMDB 进行精细化的资源及关联关系管理，将所有监控指标、日志及事件进行关联分析。基于整体过程所产生的数据指标，进行持续的数据运营，生成故障分、稳定性分等综合数值，打通大屏以应急指挥视角进行数据展示。结合 AI 领域已有的成熟算法应用，进行应急指挥及运维管理提效。规范机制主要围绕稳定性建设所需的应急及故障管理，包括协同各职能人员的应急流程、故障全生命周期的管理流程、运维操作规范及变更三板斧操作规范，同时建立机制确保规范体系能协同运作起来，形成稳定性文化，包括针对故障的问责机制、故障影响的警示机制、固化稳定性意识的学习考试、明确高危操作风险的红线制定。专业能力以业务连续性运维及持续数据运营为主，业务连续性运维主要围绕建设时期，包括整体稳定性保障体系的设计、业务梳理明确分级后的监控覆盖、持续的故障机制运营管理，故障发生时组织应急确保协同有序、制定规范并持续优化规范。持续数据运营以稳定性建设后的持续治理优化为主，围绕故障分、稳定性分、1-5-15 度量分、相关明细数据报表进行持续的运营及影响管理决策。接下来针对稳定性建设的部分重点：数据度量、应急指挥、指挥提效进行延展介绍。数字度量体系：稳定性建设也需要数改
“数据多跑路，群众少跑腿”已经是数字化改革的核心宗旨，同样，政务云应用的稳定性建设也需要“数改”，需要构建一套基于指标的数据度量体系。
指标体系围绕稳定性建设的事前、事中、事后三个环节，每个环节都会沉淀大量数据指标，包括平均响应时长（MTTA）、平均处理时长（MTTR）、事件故障的结构化数据、监控相关指标、应急协同指标等等，我们将这些数据按照能力指标（1-5-15 达标率）、结果指标（故障分）、过程指标（稳定性分）进行汇聚计算，形成数字化的评估体系，用于管理决策。其中 1-5-15 指的是“1分钟发现、5分钟定位、15分钟恢复”，是对稳定性能力衡量的目标，政务云上的应用可结合自身建设情况，进行目标调整，1-5-60 或者 1-30-120 都可以，稳定性建设需要持续运营，根据建设成效调整目标。针对稳定性的建设结果，围绕结构化沉淀的故障数据进行综合度量，形成故障分体系，是直接反应故障数量、故障时长、故障等级的综合值，能直观地对所有应用稳定性结果进行横向拉通、对比分析，故障分计算参考公式如下，同样各应用可结合自身建设情况进行公式调整。针对稳定性的建设过程，包含资源管理、研发测试、运行管理、业务指标4个阶段的资源利用率、容量水位、测试覆盖、发布规范、监控覆盖、故障改进、业务可用率等多级指标，围绕规范进行全方面的政务云应用稳定性评估，并基于数据指标推动相关团队人员进行优化整改。
整体数据度量体系，底层需要一套运维数据中台来支撑，对所有运维相关工具的指标进行抽取、清洗、计算。应急指挥：一屏观全貌，一眼知平稳
稳定性建设的核心成效之一，即是一体化的应急指挥，实用并能帮助做管理决策是应急指挥建设的核心指导方针。以医保的应用为案例，它的应急指挥视角如下。左侧为云底座 IAAS 信息，人员值班信息、资源分布、ECS \ RDS CPU TOP5 实例、云底座的关键异常事件，其中：
- 人员值班信息：包括应急指挥值班长及具体值班人员信息，方便应急指挥的参与人员发现问题后快速联系对应值班人员处理异常；
- 资源分布：涉及云底座相关的实例资源分布，了解支撑整体业务的云资源情况；
- ECS \ RDS CPU TOP5 实例：突出显示核心实例的运行情况，将 CPU 利用率 TOP5 的实例进行轮播展示，及时发现异常 CPU 上升的实例信息；
- 云底座异常事件：主要为云操作系统发生的异常，如 VPC 虚拟网络异常、SLB 负载均衡异常、OSS 底层存储异常等事件信息，方便了解底层云 IAAS 是否存在异常。
中间为业务关键运行指标，包括核心指标当前成功量、耗时、运行趋势、TOP 排序分布，其中包括：
- 医保结算的当天实时成功量，以及门诊、住院的结算耗时，方便了解核心业务的实时运行情况；
- 医保结算具体结算区域、结算机构、结算类别 TOP1，便于了解当天结算量最高的区域、机构、类别信息；
- 联网结算实时运行趋势、联网结算区域 TOP10、联网结算机构 TOP10、联网结算类别 TOP10，方便进一步了解业务运行实况，出现异常可第一时间发现。
右侧为故障相关实时事件信息，包括无故障时长、监控指标分布、变更信息、事件信息、报警收敛率，其中：
- 无故障时长：当前系统持续无故障的时长，表示系统运行的健康度；时间越长，系统越健康；
- 监控指标分布：包括基础设施、应用个数、业务指标数，监控指标越多，代表线上业务监控粒度越细；
- 变更信息：关联应用的变更列表，便于在业务异常时，第一时间关联对应的应用变更，快速定位及回滚；
- 事件信息：主要为关键的业务指标所产生的异常事件，便于进一步跟进处理、了解线上业务运行情况；
- 报警收敛率：同类原始报警会持续收敛为 1 个事件中，避免报警风暴，通过收敛率可进一步了解报警风暴的抑制情况。
后续：通过 AI 能力提升指挥效率（AI+OPS）
最后是产品的部分规划，除了稳定性领域的持续建设，围绕运营运行，我们也在探索是否借助 AI 算法来提升整体的运维或管理效率。
当前已有 AI 能力进行生产应用，围绕稳定性建设领域。如基于政务云核心应用，已有智能基线及预测的 AI 应用，检测是否即将到业务高峰期，并提前采取运维动作。如基于云平台的使用及运维，政务云技术运营团队沉淀了大量的问题解决知识库，结合机器人及语义识别进行智能问答，当前机器人已上线运行近 1 个月，整体命中率及采纳率还需运营及提升。如针对核心民生应用的关键业务指标，基于异常检测算法进行监控预警，降低静态阈值无法覆盖导致监控漏报的风险。业务影响分析，是基于智能基线及异常检测的综合应用，在故障发生时，通过 AI 识别同异常类型的业务指标，帮助用户更快速地了解故障影响面，当前还在探索应用中。同样，AI 也不是稳定性“银弹”，所有的 AI 应用均需要大量的结构化数据沉淀，是对数据度量体系的补充，需要进行持续的投入进行探索、实践，来提升应急指挥及运维管理效率。（正文完）
你可能还想看
关注我们欢迎关注加星标✨ 每日推送不错过