社交APP搬迁过程中高可用架构与监控体系优化实践

来源：《华为云SRE确定性运维专刊》第三期

本文作者：周扬帆、刘宝起、李益廷、杨薇

      1    项目背景
      Y公司在2021年XX月成功升级，打造一条引领所有业务前往元宇宙的新赛道，形成自己的产品矩阵。同时，Y公司将业务搬迁至华为云，打开云云协同的合作局面，面对超速增长的业务，搬迁期间的高可用架构设计、监控告警能力建设、风险识别及应急预案制定、混沌工程故障演练等构成了未来业务稳定所需执行的核心动作，同时也是保障业务快速稳定上线的关键要素。
      2    业务保障整体策略
      从保障组织、风险识别、日常保障三大维度落地12项措施，多角度保障客户业务平稳运行。

      2.1    成立保障组织，提升响应效率
      （1）分配专属服务经理。
      （2）根据客户业务特点与进度安排生成专家资源池，组建保障团队。
      （3）建立IM群，前后端所有保障团队人员7*24及时响应。
      （4）客户现场进行驻场值守，及时响应同步客户诉求。
       2.2    高可用架构设计，确定性风险应对
      （1）进行高可用架构设计，缩小故障的爆炸半径；分析已完成上线的业务，打开各链路进行可用性检查识别风险；对识别出的风险组织专家评审，确保识别的风险完整、可信。
      （2） 完善风险的应急预案，梳理风险场景的触发机制，明确监控方案、监控指标、监控阈值和监控发现时间，制定风险消除责任人，明确恢复时长和恢复操作，构筑确定性故障恢复时间及恢复能力。
      （3） 通过业务压测、故障演练验证业务容量的风险和故障应对措施的可行性，完善资源监控方案和应急预案。
      2.3    日常保障，确保业务环境的稳定性
      （1） 例行巡检：设计各服务的健康度指标，各时段针对性巡检。
      （2） 变更管控：隔离业务租户，避免由于变更引发的服务故障。
      3    联合运作
      客户、华为1+1结队成立联合保障组推进各个保障专项，从四个重点方向进行业务梳理和风险识别：
      •   架构可用性专项组：拉通上层业务、底层资源整体架构的可用性审视，风险识别，跨AZ高可用方案推进。
      •   容量及压测专项组：主业务流全链路容量性能分析及压测，识别业务瓶颈。
      •   监控告警优化专项组：客户、华为监控联动，告警处理对接机制，提升故障触达率。
      •   故障演练专项组：底层资源故障对业务的影响实操，应急恢复能力的演练及验证。
      同时成立领导组和总体组，领导组负责资源协调投入，重大决策；总体组负责保障项目整体管理，包括计划、风险管理等。
      4    高可用架构设计
      对客户部署架构庖丁解牛，识别底层资源、上层业务存在的风险，明确对应的风险等级和应急预案，并结合关联的场景完善监控及故障演练用例，为后期问题快速发现、快速定位、快速处理奠定基础。同时需了解当前行业的业务特点，如社交、游戏类行业对时延要求高，在架构设计时需考虑到跨AZ的服务时延会增大等因素。
      4.1   联合分工
      •   细化当前业务架构，逐层拆解分析部署架构及流量方向。
      •   现场人员与后端支撑专家配合识别当前项目中存在的风险，制定详细的应急预案，包含相关弹性或降级方案。
      •   对现阶段已识别的风险内容共同明确应对方案，以业务稳定性为前提进行局部调整，对关键节点服务创建主备实例。
      4.2    架构的高可用设计方法

      建立可靠性/可用性能力模型，将客户常见故障归纳至上图的能力模型，包括：冗余、容灾、过载感知和过载控制、故障检测和故障恢复、数据安全、逃生通道。
根据分类，结合业务流，建立可靠性/可用性能力模型的评估清单：
      •    高可用集群：是否存在单点，如单台虚拟机或单命名空间部署的业务等；
      •   跨域高可用部署：是否支持AZ或Region容灾，如是否存在OBS的单AZ桶，RDS、DCS是否为跨AZ实例；
      •   过负荷控制：是否具备高负载的限流及弹性伸缩能力；
      •   资源共享最小化：中间件资源实例是否尽量做到业务单一使用，降低爆炸半径；
      •   数据备份和恢复：是否有数据备份等数据保护措施；
      •   故障定界定位：云服务的核心监控指标，是否具备监控告警能力以及是否完成配置监控告警；
      •   故障运维：针对实例故障的应急预案，是否明确风险触发条件，核心指标的监控方案，监控发现时间，风险消除责任人和风险恢复时间，核心资源信息的集中管理。
      以上从系统可用性、数据可靠性、运维可靠性三个类别进行客户的高可用架构设计，建立客户架构的中长期优化策略。
      4.3    案例：数据库的高可用设计
      数据库选型与设计规划从来都不是一件一次性到位的工作，业务软件发展的每个周期，对数据库的要求不同，但贯穿整个业务应用软件生命周期，数据库底座的基本要求应该包含性能、高可用、容灾、稳定性、成本等。
      •   高可用：业务快速增长，数据库压力陡增，XXX个9的SLA挑战目标；利用数据库开源高可用组件，结合华为云资源跨AZ部署解决业务对高可用诉求，同时保障宕机能自愈，RPO与RTO达成秒级。
      •   告警监控：在数据库实际监控数据中，具有预测性与观察性的指标是慢查询与主备复制时延，这2个指标直接影响社交类业务体验。数据库的CPU和IO等传统指标作为参考，项目组通过统一运维监控平台，纳管云上云下数据库节点，实现告警模板定制化，数据库关键指标建立SLA预警体系。
      •   性能：快速增长的业务对数据库的性能要求是非线性的，通常是指数型上涨，仅仅通过传统的垂直扩容与水平扩容的方式，并不能应对指数上涨的性能要求，而在业务快速增长期，数据表等对象的频繁发版变化，数据库运维DDL与DML性能也需要考虑在内；该项目通过云数据库自研内核、云原生数据库产品与数据库设计使用规范，建管结合，保障数据库在业务快速增长期性能抗得住。

      4、数据分层：拒绝简单粗暴的CS架构和all in one DB，接纳微服务化改造。项目组对数据面设计立足数据分层架构，高频访问数据去事务化改造，采用高性能缓存架构，一次生成多次使用，业务缓存命中率高达98%，避免数据库被击穿。

      5    持续告警优化
      5.1    监控告警能力建设
      监控告警优化通过高效的运维系统来提供高质量的IT服务，从底层资源到上层应用，全方位监控系统的运行状态，并快速响应各类问题，最终保障业务稳定性，提升用户体验。监控能力的缺失将导致无法正常监控各个服务的运行隐患，从而提前发现故障风险，也会在故障发生后耗费大量时间定位问题。
监控告警能力搭建的关键步骤：
       •   分析业务：针对云上资源的告警情况、负载情况和健康情况进行检查，从监控的角度分析业务场景和历史故障，识别关键监控项，结合华为云运维实践，提供针对性的优化建议。
       •   梳理监控现状：梳理客户监控配置现状，包括华为云运维工具（CES/AOM）及客户自建监控系统。
       •   提供优化建议：根据客户监控配置现状，结合《华为云上监控告警配置实践》，协助客户完善监控配置，保证业务顺畅运行。
       •   持续优化：根据客户业务的迭代变化持续跟踪优化监控告警项。
      根据客户的业务特点和运维人员结构情况，将告警接收策略定制如下：
      •   按职责定义告警分组。
      •   精细化告警分类。
      •   资源服务分组。
      •   设置告警优先级和告警方式。
      •   设置告警规则。
       5.2    全链路监控
      华为云CES服务和AOM服务提供对各服务资源及容器的监控能力外，也可通过设置自定义监控大屏，进行全链路监控。如：通过选取云专线、NAT网关、ELB、ECS等资源的关键指标进行监控展示，方便客户在一个显示屏中查看业务的运行情况。

      5.3    非标场景
      客户业务有大量使用ECS自行搭建应用的场景。DNS、数据库、中间件等均使用自建的方式部署在ECS上，使得为ECS设计的告警场景和告警阈值无法通用。比如，普通业务的ECS的CPU使用率通常将阈值设置为90%，若该ECS上部署的为Redis服务，当CPU使用率达到90%时，ECS中部署的服务已经处于高负载异常状态，90%的CPU使用率告警阈值就不再适用。针对这种情况，需要将客户的ECS资源进行分组，结合部署业务的特性单独配置适合各服务特征的告警阈值。
针对自建业务场景，CES提供CES-普罗插件和CES-Grafana插件，AOM提供AOM-Grafana插件接口监控告警对接接口，与客户的自建的监控体系对接，拓展监控告警能力。
      6    全链路容量分析与性能测试
      6.1    明确性能目标，全链路业务流分析
      容量分析和全链路压测，可准确评估性能目标，如客户APP的性能目标为XX DAU所需的资源需求，消除流量突增过载导致的流量损失风险。
      6.2    设计资源增长模型，识别风险资源
      根据未来业务增长情况、压力模型和当前服务资源的压力情况，评估各资源实例的规格是否满足业务增长需求，确定容量风险和需要提升的规格。通过细化分析关键指标使用率，明确增长的趋势和入口流量趋势的关系，确定入口流量与实例指标增长的倍数对应关系，输出精细化的容量增长模型。

       6.3    业务瓶颈点识别，提前扩容
       •   ECS的实例规格、CPU使用率、内存使用率、磁盘使用率、网络连接数如果超过80%建议分析业务风险进行扩容。
       •   ELB七层查询速率、新建连接数、并发连接数、接收速率、发送速率每个指标预测使用率超过80%需要进行审视，评估扩容。
       •   RDS预测CPU使用率如果超过50%建议分析业务风险，超过60%建议进行扩容；如果内存使用率超过80%，CPU使用率不及内存使用率，需要分析CPU低内存高场景下的风险和业务优化点，评估扩容的规格。
      •   DDS内存使用率如果超过80%需要进行分析，内存使用率比CPU使用率高时需要分析业务优化点；磁盘建议将告警阈值设置为80%，达到阈值后及时扩容。
      •   DCS预测内存使用率如果超过70%建议分析业务风险；超过80%建议进行扩容；CPU使用率如果超过70%需要对Redis命令进行分析，优化对CPU冲高的复杂度命令；连接数使用率如果超过70%需要分析是否是正常业务行为，并进行相应优化。
      通过以上方案保障客户业务快速稳定上线，助力企业完成数字化转型。