企业核心业务“云化“：可用性保障经验谈

文章来源：《确定性运维专刊第6期》

企业核心业务‘上云’后，相较于传统场景会发生显著变化，如何保障‘上云’场景下系统可用性成为每个软件‘上云’项目必须解决的问题。本文通过分享GTS软件核心业务‘上云’过程中在可用性保障方面的实践经验，旨在为其他类似产品或项目提供可借鉴思路与方法。

一、背景

随着公有云业务的迅猛发展，越来越多的企业将核心业务系统迁移至云端，云服务正以空前的速度重塑传统IT架构。Gartner报告显示，到2025年，全球云服务收入的增长率预计将高达138%，届时云服务市场规模将超越传统IT服务，成为企业技术投入的主要方向。

GTS软件作为运营商领域的重要软件供应商，拥有多款自主研发的核心业务软件。在传统模式下，这些软件由GTS软件提供给运营商，随后由运营商负责在本地机房进行部署和运维，并以此对外提供服务。然而，在软件‘上云’趋势的推动下，GTS软件将系统部署于公有云平台，运营商只需订购服务即可快速开展业务，而系统的运维工作则由GTS软件全面接管。本文聚焦GTS软件在运营商核心业务‘上云’场景下的可用性保障实践，探讨如何确保系统稳定性和高效运行。

二、变化与挑战

软件业务“上云”和传统场景相比发生了3个变化： 

• 系统部署位置发生变化：从客户机房变成云上（如华为云/云服务厂商等）；
• 软件物权归属发生变化：从客户变成软件供应商（如GTS软件等）；
• 系统承载客户发生变化：从唯一客户变成了多租形式面对多客户。

3种变化带来的3类挑战：

• 挑战1：运维责任主体发生变化，运维模式从“被动”变为“主动”：“上云”后软件物权归属和运维主体变成软件供应商，软件供应商转身为服务供应商，运维模式从“被动响应”变成“主动运维”。
• 挑战2：运维组织变得复杂：“上云”后，南向I层运维依赖云SRE，北向业务依赖客户系统，端到端的运维需要软件供应商、云SRE及运营商三个团队配合，相比传统场景的双向配合，运维组织变得复杂。
• 挑战3：系统外部边界复杂，问题定界和应急恢复挑战变大：“上云”以后，典型业务流涉及“云上I层设备”→“云上软件业务系统”→“网络专线”→“客户第三方系统”等，系统的外部边界变得复杂，故障定界和应急恢复挑战变大。

三、实现方案

围绕软件“上云”后的诸多挑战，GTS软件SRE运维团队在过去三年开展了一系列针对软件“上云”后的可用性保障的实践，本章节将从策略，团队，成本，产品与云等维度展开介绍。

1. 策略：定义模型，系统性构建软件“上云”可用性保障能力

企业核心业务“上云”的可用性保障是一个系统工程，需要依赖公有云、产品自身、产业投资力度、团队发现/解决/恢复等能力。对此，我们定义了“软件“上云”的可用性保障层次关系”模型，如下图所示。

可用性保障层次关系模型图

• 团队能力：高效的保障团队是可用性目标达成的必要条件，业务“上云”后，对内要有专业组织，主动负责运维事务；对外需要联合云和客户协同运作，定期展开演练等措施保障可用性目标达成。
• 成本投入：成本的投入决定了可用性的上限，成本投入和可用性是天平的两端，可用性越高，成本投入越大，如何平衡两者，需要结合业务发展和客户诉求综合分析，以实现成本和系统可用性的最佳结合。
• 产品能力：产品的可靠性能力是可用性达成的基石，问题的快速发现、定界/恢复、计划性失效时长等产品能力的建设是“上云”可用性达成的基础。
• 云的依赖：公有云的能力决定了可用性的下限，在‘上云’后，基础设施（I层）资源由云服务商提供，其承诺的可用性服务级别目标（SLO）以及能够提供的保障支持服务，是构成可用性保障的基线

2. 团队：构建高效的保障团队

实践1：对内成立SRE运维中心，对业务可用性和客满负责

GTS软件的‘上云’业务覆盖全球多个区域，为保障业务高可用性，我们成立了‘软件SRE运维中心’。经过三年的发展，逐步构建起由1个机关中心和4个区域中心组成的全球化组织布局。这一布局不仅能够有效支撑全球业务的开展，还能够满足各地法律法规的要求，同时克服时差和语言差异带来的挑战，为业务的稳定运行提供坚实保障。

机关中心和区域中心定位和职责说明：

应用情况：已覆盖海外6大区域，保障XX个项目SRE运维事务。

典型应用案例：基于SRE作战室与客户互动，让客户放心，提升客户满意度

背景：A客户是某国某行业规模最大企业，同时也是世界500强企业。在将其S业务迁移到软件“上云”模式后，客户对无法面对面接触运维团队感到担忧，并对系统稳定性是否能得到有效保障表现出一定的焦虑。

实践过程： 针对客户的顾虑，软件SRE运维中心迅速响应，主动策划并与客户的技术负责人及专家团队开展了远程视频交流。整个交流过程依托SRE作战室进行，围绕客户关心的核心问题，详细介绍了SRE的人员配置、组织架构、运维流程以及关键能力，包括主动监控、主动运维、变更管理及问题处理机制等。通过这一系列澄清与沟通，有效缓解了客户的担忧，增强了其对系统稳定性的信心。

效果：

1. 客户非常认可本次交流，其负责人表示通过本次交流让他们看到了我们系统性和专业性，消除其焦虑。
2. 通过本次交流，与B客户建立起例行交流机制。
3. 将此实践，在全球多个重点客户开展。

实践2：构建智能运维机器人，利用AI提升运维效率

软件SRE运维中心成立后，团队成员分布在中国及4个区域中心（国家），如何高效实现全球运维知识共享成为组织建设的一大挑战。为此，我们基于大语言模型（LLM）技术构建了智能运维机器人“数字SRE”，支持全球范围内的运维知识共享和自动化运维能力。

如下图所示，当运维人员向数字SRE发送消息时，系统会首先判断消息类型为“问答命令”或“运维命令”，并根据类型执行不同逻辑处理。数字SRE底层集成内部大模型和微调流水线，依托平台支撑层和原子能力层，实现了从“知识问答”到“自动化运维”的全流程串联。

软件数字SRE架构和典型应用意图

目前智能机器人已成为运维中心不可或缺的工具助手，并在日常工作中得到常态化应用。

实践3：明确责任矩阵，协同运作

针对“运维组织变得更加复杂”的挑战，我们从范围、职责、组织三个维度识别差异，并明确“上云”场景的各方责任矩阵。

如上图所示，“上云”场景中各方运维责任矩阵变化点如下：

• 运维组织：增加公有云团队；
• 运维范围：增加“云租户管理”事务
• 运维职责：

• 客户三方运维仍由客户负责。
• “业务运维” 由软件负责、客户支撑。
• “云租户管理” 由软件团队负责、公有云支撑。
• 设备管理等事务由公有云负责

基于“上云”场景的责任矩阵，我们在重点项目中与云服务商和客户协同合作，目前已在6个区域与两家公有云团队组建联合团队，并与客户共同开展联合保障工作。

实践4：识别关键故障点，定期开展跨团队联合演练

业务“上云”使得业务流程更加复杂，组织间协作难度加大，问题定界和应急恢复的挑战也随之增加。为此，我们从端到端的角度识别关键故障风险点，并制定相应的应急预案。同时，定期联合云服务商和客户开展应急演练，在演练中发现产品、团队及流程中的潜在问题，并针对性地进行改进，从而持续提升应急恢复能力。

如下图所示，我们定义了每个产品/项目必须开展的应急演练事务，整体分为3个阶段。 

阶段 1：内部演练：依托研发内部演练环境，持续开展自动与红蓝对抗演练，针对典型业务故障识别并改进产品可靠性短板，提升软件应急恢复能力。

阶段 2：联合演练（云）：基于现网测试床，针对云及云与软件配合相关故障，开展云与软件联合演练，排查并解决云依赖风险点，提升双方应急协同恢复能力。

阶段 3：联合演练（客户和云）：在现网生产环境中，经客户审批后，针对典型业务、云及第三方故障场景，开展客户、云和软件三方联合演练，验证生产环境健壮性与协同应急恢复能力。

如下是软件某产品典型故障场景涵盖软件自身“业务故障”、客户侧“第三方故障”和“I层云故障”三大类。每个场景明确主导恢复组织与支撑恢复组织，所有应急演练均围绕这些典型故障展开。

目前，软件SRE运维中心已将与客户及云的定期联合演练纳入日常工作。2024年共开展XX次客户联合演练，客户反馈演练让运维从“黑盒”变得透明。此举不仅赢得客户对运维价值的认可，也有效提升了团队的应急能力。

3. 成本：寻找成本投入与可用性的平衡点

业务“上云”的成本包括硬件、软件、人员及维护等方面的投入，这些与系统可用性密切相关：  

• 高可用性依赖更多资源支持，如冗余服务器、负载均衡和备份系统等，这会增加硬件成本；反之，减少投入可能降低可用性，导致系统故障或延迟风险上升。
• 不同服务级别对应不同的运维成本，高可用系统需要复杂的监控工具和更多技术人员支持，成本更高；而选择低可用性虽可节省开支，却可能影响用户体验和业务连续性。  

因此，软件“上云”需根据业务发展需求，在成本与可用性之间找到平衡并持续优化实践。

实践5：根据业务发展，逐步加大投入提升可用性

针对性选择组网方案是软件“上云”平衡成本与可用性的实践之一，依据项目进度和客户需求选择合理部署方案：

• 建设期：不提供商用业务（或对可用性要求低的客户受限使用），以最小投入搭建可供体验的系统，助力市场拓展。
• 发展期：提供可用性一般的服务，逐步加大投入，严控业务和服务承诺。
• 成熟期：业务快速发展，前期已验证产品和团队保障能力，且项目收入可覆盖成本。 

以B产品为例，该产品为中小运营商客户提供服务，一套系统对接多个客户、承载多个租户，部署在某伙伴云。其投入与可靠性变化过程如下：

• 阶段1：客户体验和试用阶段，对可靠性无高要求，采用单站点组网，成本低。
• 阶段2：部分对可用性要求低的租户上线，组网扩展为应用层双AZ双活，提升可用性，成本投入中等。
• 阶段3：高可用性要求的租户上线，生产环境扩展为3AZ多活组网，成本投入高。

实践6：弹性伸缩适应业务变化

软件“上云”时，产品的“弹性伸缩”能力是平衡成本与可用性的重要实践。通过业务负载动态对实例数量进行调整，实现云资源的高效利用，在不同阶段达成可用性与成本的最优平衡。

案例实践：以C产品为例，其采用双AZ双活组网，在接入层（EIP）、应用层（CCE 容器集群、ECS计算资源）、中间件(DMS分布式消息、DCS分布式缓存)具备端到端的弹性伸缩能力；数据库为双AZ主备，具备自动主备切换能力。正常情况下，由AZ1承载业务，AZ2保留最小资源；当AZ1故障时，通过接入层切换到AZ2并快速扩容承接全部业务；业务恢复后，资源回切并释放。

软件上云的成本和可用性之间呈正向关联，可以在项目不同阶段选择合适的组网方案，通过“弹性伸缩”帮助系统合理配置资源等方式，找到平衡点，实现成本的最优化。

4. 产品：打造产品的高可维/可靠能力

产品能力是保障系统可用性的核心基础。为此，软件内部应建立一套体系化的产品可运维性标准，涵盖可靠性和可维护性两方面，并明确了最小能力要求。每个产品在发布和上线商用前，都必须遵循该标准构建相应能力，确保满足特定要求后方可投入使用。

• 主动运维：构建主动告警、监控和系统健康检查能力，确保问题快速或提前发现。
• 故障处理：从日志的可获得性、故障诊断、故障恢复三方面构建能力，确保问题快速定界与恢复。
• 变更管理：构建版本/补丁升级不中断能力，降低计划性失效时长。
• 防人因故障：构建主动防呆能力，减少人员误操作造成的故障。

实践7：产品关键可靠性能力构建

• 过载控制

上云后，系统承载多租户服务，而不同租户的业务形态差异较大，容易引发业务浪涌。因此，必须具备完整的过载控制能力，以确保在浪涌场景下系统的稳定性。

• 过载前：
• 资源规划：依系统容量和性能规格合理规划部署资源，预留冗余。
• 过载分析：根据业务流、架构、组网和场景分析，识别瓶颈点与过载场景。
• 过载预防：业务和架构设计避免大流量、性能瓶颈与过载扩散。
• 过载中：
  • 弹性伸缩：优先在线弹性调度资源，提升系统处理能力。
  • 过载控制：依系统处理能力进行流量控制，调整业务接入量。
  • 业务降级：通过熔断牺牲非核心业务，保障核心业务。
• 过载后：释放弹性伸缩新增资源，降低硬件成本。

“上云”后的系统应具备灵活扩容能力，应对过载时，整体策略依序为弹性伸缩、业务降级，最后才考虑业务丢弃。

• 保持冗余

系统发生单点故障时，可通过冗余单元接管故障业务，确保系统或设备功能正常运行，从而提升业务可用性。软件业务中常用的冗余技术包括云资源池、负载均衡、主备部署及多副本备份等。

结合公有云站点可靠性方案，软件业务特性的冗余技术主要应用如下：

• 公有云站点建设：遵循3个可用数据中心的可靠性要求，软件适配开展多AZ多活或容灾部署。
• 公有云资源池：按网络、计算和存储划分，可规避云服务单点故障，为上层应用业务的高可用提供支撑。
• 云化软件：部署于业务区，具备不依赖底层的冗余能力，常采用多实例、反亲和性、主备等部署方式，保障业务自身高可用。

• 故障隔离

当系统中某个单元出现故障时，为限制故障影响范围，可将故障单元从系统中分离，保障系统其他单元不受干扰、正常运行。

D产品软件组网显示，与传统软件组网相比，上云后运用微服务化和Grid设计，能更高效地实现故障隔离，缩小故障影响范围：

• 业务应用微服务化：从隔离角度出发，将应用拆解为多种基础业务与平台业务，各业务流程对应独立的微服务和数据库，当某一业务流程异常时，不会对其他基础或平台业务造成影响。
• Grid设计：每个Grid集成整套端到端的服务网元，具备完整系统功能。依据特定路由规则，用户请求被转发至相应Grid，当单个Grid服务不可用时，不影响其他Grid的业务运作。
• 
  

• 系统健康度检查

为帮助运维人员及时掌握业务系统健康状况，我们开发了自动系统健康度检查功能。该功能可定时、全自动采集系统关键KPI，生成健康度简报，并通过邮件或短信推送，让运维人员随时随地了解系统状态，提前发现潜在隐患。其主要特性如下：

• 检查范围覆盖基础设施、平台层、业务层和运营层4个层级。
• 数据处理包含指标建模、数据采集、数据存储、数据分析和报告生成5个步骤。
• 数据分析融合性能/告警分析、日志分析、健康度经验规则以及AI预判等方法。

目前，系统健康度检查功能已经在软件业务所有项目中间应用。

实践8：提升系统定界能力

客户核心业务“上云”后，需通过“网络专线”对接机房业务或通过接口与第三方系统集成，这使系统组网更复杂、外部边界增多。一旦发生故障，快速定位问题并提供恢复方案成为运维工作的主要挑战。

上图展示了GTS软件“上云”业务与客户其他业务的对接情况，红线标注了系统与云及客户第三方的外部边界，这是故障定界的关键位置。我们通过强化边界监控能力和日志记录，提升问题定位能力。关键边界监控点分为云故障和客户第三方故障两类，已全面应用于所有“上云”项目，效果显著。

应用案例 1：提前客户感知第三方系统，获客户认可

X客户拥有十几家第三方渠道，但缺乏有效监控手段，技术团队对第三方问题的感知常滞后于业务团队，陷入被动。为此，我们为客户搭建了三方渠道监控大屏，半年内运维团队抢先发现第三方问题20余次，赢得客户认可。

应用案例 2：建立网络时延BenchMark，消除客户疑虑

Y项目所在国家基础设施落后，网络条件不佳，网络问题易致业务量大幅下滑。我们强化该项目网络时延监控，与客户明确网络时延BenchMark，时延超出标准时及时通知客户，成功消除客户疑虑，获得客户认可。

5. 云：强化与公有云的支持和协同机制

实践9：精准匹配与洞察，强化与云的支持服务

• 精准匹配，选择自身最适合的云服务

业务 “上云” 后，I层设备与部分P层服务由云提供，其可用性保障也由云负责。业务人员需熟悉云承诺的可用性指标与支持服务，结合自身业务诉求进行选择：

1）挑选合适SL服务，依据业务特性在99.95%或99.975%可用性服务中抉择。

2）选择适配的云侧支持服务，明确TAM（大客户支持）接口人并建立顺畅沟通机制，确保及时处理现网问题。

以华为云为例，其提供基础级、开发者级、商业级、企业级四个等级的支持服务。GTS软件“上云”多承载中大型企业业务，需最快事件响应机制，通常选择企业级支持服务。

• 精准洞察：联合云满足自身特定需求

因业务特殊性，若云资源在功能和性能上无法满足需求，需主动与云沟通，提前协同公有云解决问题，防止业务上线后出重大问题。以下是部分对云有特定诉求的问题点。

实践10：构建与云的问题处理和变更协同流程

说明：此实践因为GTS软件和华为云是同一家公司，所以可以构建商务合同之外的协同 ，其他厂商无法直接借鉴，如有需要请与华为云单独交流。

GTS软件“上云”业务服务于中大型企业核心业务，对系统可用性和重大问题恢复的SLA要求极高。为高效应对重大问题和业务变更，我们按区域联合华为云组建线下保障团队，明确双方在问题处理与变更运作中的流程，并开展联合保障。

• 问题处理和协同运作流程
• 软件侧：统一受理客户事件单，识别问题影响、定义级别。若涉及云，同步问题至联合工作组和云，重大问题按软件流程组建软件侧 Warroom攻关。
• 云侧：同步建立问题工单，当云侧发生重大故障时，按规则启动Warroom运作。
• Warroom运作：针对双方启动Warroom的问题，协同运作、共享信息，共同定位问题、恢复故障。

• 现网变更流程
• 变更规划：云和软件侧规划重大且需双方共同保障的变更时，主动知会联合工作组。
• 联合保障：针对此类重大变更，联合工作组组织双方开展变更方案联合评审，制定联合保障方案并进行联合保障。
• 变更执行：变更发起方按各自流程操作。变更准备期确认是否需联合保障，若涉及则发起联合，确定联合变更与保障方案。

四、总结与经验分享

经过3年建设，GTS软件业务完成软件SRE运维中心的全球布局，为软件业务全球化发展提供有力支撑，保障了XXX个“上云”项目的稳定运行。“上云”后，系统部署位置变化、业务流程延长、运维协同复杂度提升，可用性保障成为一项系统工程，需要从以下四个方面重点落实：

• 构建团队能力：组建专业 SRE 运维组织，负责 “云上” 业务可用性，协同云与客户，定期开展跨组织应急演练。
• 平衡成本投入：系统可用性与业务系统紧密相关，需结合产业发展、客户需求、产品能力，权衡成本与可用性。
• 提升产品可维 / 可靠能力：持续建设产品冗余、故障隔离等可靠性能力，强化系统边界监控与定界能力。
• 强化与云团队的支持和协同机制：清晰了解云服务可以提供的支持服务，理顺与云的重大问题及变更协助机制。