背景挑战

故障频发

• 故障1：xx服务故障，原因为系统设计不合理，导致晚高峰流量突破系统瓶颈，而相关服务缺少过载保护措施。幸好主流程有对应的稳定性措施，未造成大规模影响。
• 故障2：xx服务故障，原因未开发同学误操作接入层现网配置，且相关变更未同步到团队其他人，另外接入层问题相对隐晦，定位耗时比较长。影响部分用户体验。
• 故障3：xx服务重构，因老系统交接N手，新接手同学未考虑到老版本的特殊需求，上线后问题一直未大规模暴露。直到某节假日现网问题集中反馈才暴露。

研发效率、质量差

• 开发、测试环境冲突，缺少系统集成测试环境：因为业务的复杂性，大部分业务都需要依赖平台相关服务，而平台业务却很少考虑业务的诉求，导致环境各异，开发、测试冲突时有发生。
• 版本兼容性：业务的特殊性，终端还有N年前的版本在线上，这些都需要后台兼容。后台祖传的服务太多，交接过多手后不清楚哪些特性还在使用，哪些已经废弃。不敢重构。
• 系统容灾能力考虑不足：容灾措施评估不足，或者年久失修，没有真正经历过故障的考验。当故障发生时发现跟预估的效果差别较大。

目标及原则

目标

原则

• 避免重复造轮子。借用平台能力或参与中台共建，降本增效，人力有限的背景下最大化产出

  当前团队属于业务性团队，人力配比上主要还是支撑业务，几乎不可能有单独的时间留给团队进行技术栈的升级改造工作，而且从长期维护角度看，使用中台或者参与共建是最好的选择（当时没有提到均摊中台成本一说）。

• 团队全员参与：避免成为少数几个人的项目，让团队意识到项目的意义更为重要。骨干同学负责各项技术能力的对比预研以及方案评审，在部分项目上实验后再团队整体宣讲、推广，同时最小化接入成本，避免过滤侵占其他人时间。

措施

研发阶段

研发规范建设

• 仓库标准：仓库目录、分支、CR等命名相关规范。在切到git之前就已有了，但是后面随着业务的发展，部分已经没有遵守。
  • 评估手段：有仓库扫码工具，定期扫描业务代码库，对规范异常直接告警。
• 组件规范：统一团队技术栈，降低维护成本。
  • 开发基础：统一框架、服务发现、配置系统、可观测组件、基础能力。
  • 稳定性：标准化兜底及熔断能力，避免业务自定义实现或者缺失
  • 中间件：MQ、Redis、Mysql等相关平台及使用流程
  • 公共库：业务公共库，包括产线渠道获取、域名隐藏、IP库等基础能力
  • 评估手段：除团队宣讲外，主要靠leader审批把关。

辅助工具

• 脚手架：复用平台脚手架的能力，自动化生产仓库、CI/CD流水线能力，统一流水线模板。
• *CR：**有效的CR，避免流于形式。单侧覆盖率、规范检查等基础指标由流水线保障，CR主要关注业务逻辑合理性。
  • 评估手段：团队有CR考核指标，人均评论数、分数大于xxx。
  • CR方式上结合集体评审以及线下评审两种方式。会有相关robot提醒CR任务以及CR指标进展。

系统设计

• 通用容灾容错能力补齐：存量服务补齐通用的容灾容错能力，提升系统健壮性。
  • 兜底：除业务自身容错外，接入层建设统一的兜底能力。如果请求下游失败时，或下游返回错误码时，用缓存的数据代替下游回包进行响应。
    • 目的：利用平台能力，轻量、标准化的兜底方案去保障后台各微服务的可用性。
    • 方法：接入层能为面向外网的 HTTP 服务提供缓存/兜底能力，可以灵活指定请求包中部分值作为 cache key，缓存/兜底数据的回包作为 value。
  • 业务模块过载保护与熔断：使用公司runtime接入。对系统的出入口做好稳定性保护。
• 业务逻辑的降级策略：保障非核心路径失败时不影响主流程，需要在各微服务中做好容错。
• 基础组件的兜底能力：包括配置系统等业务常用等公共组件的失败时，能够不影响线上业务。需要考虑标准化的容错措施。
• 评估手段：团队定期（双周四下午）具体设计方案评审，包括老系统架构review、新系统建设方案评审。给出方案评审模板，稳定性措施必须有体现。

测试阶段

开发自测

• 单测：核心逻辑必须要单测。
  • 评估手段：流水线会卡增量代码的测试覆盖率，至少30%。
• 流量重放测试：对老服务重构必须进行现网流量测试。netflix之前也有过类似的介绍，使用logreplay等工具抓取现网流程在新系统重放，然后比较结果的一致性来保障新系统的兼容性。
  • 评估手段：leader卡发布流程。
• 全链路压测：
  • 目的：①使用公司压测平台，对系统负载极限以及瓶颈做到心中有底，这样在重点项目保障时能够做好精确的扩容预估。②模拟故障，校验各种频控、兜底措施是否完善，以及终端表现是否与预期一致。
  • 方式：未避免影响线上环境，几个重点措施
    • 在测试环境或者金丝雀环境压测，与现网流量隔离。压测各个服务进保留一台容器即可。
    • 上下游通知或者mock，避免对上下游造成冲击。
    • 后台需要校验结构数据的准确性，但终端也要评估兜底时的用户体验，此过程最好卷入相关产品团队。后续在重大项目保障期间也会作为标准的降级措施提前宣讲&准备。
    • 容灾演习：系统重构，重大保障活动前，建议对核心功能做一遍压测，确保相关功能仍然完整可用。
  • 评估手段：重保前的必须流程。

测试团队

• 环境治理：解决环境冲突问题，使用金丝雀能力支持多套环境灵活定制。
  1. 建设集成测试环境，用于集成测试、线上验证和灰度发布；
  2. 建设特性环境，用于特性开发；
  3. 建设预发布环境，用于发布前测试；
  4. 建设测试环境， 用于基线稳定测试环境。

部署

• 接入层：接入层的变更要做好细致的权限控制，接入层故障发生时后台服务可能无法感知，所以需要缩小权限范围，同时有特定的发布流程。
• 微服务部署规范：使用表转化的CD流水线，自动通知、审批等流程。
• 配置变更：配置变更也属于发布的一部分，要求各系统必须具备审批、通知能力。
• 评估手段：建设业务变更日志系统，可用于查询、通知相关变更记录，第一时间发现问题。

运营阶段

• 扩容：容量保障（半）自动化
  • 动态扩缩容：这个是基础，利用平台的动态调度能力能够根据负载实时扩缩容。团队也有自行实现巡检脚本，针对业务的特殊性优化。比如业务周末流量高峰过后会大跌，需做好及时缩容等。
  • 突发容量管理：接入公司SRE系统，解决计划内突发业务场景的容量管理系统。通过建立全链路服务容量和业务指标之间的联系，基于计划性的活动事件给出的预估指标进行提前扩容，实现业务服务容量全流程管理，从而解决热点事件（如春晚）带来的洪峰流量对业务系统的冲击，帮助业务提高对自身容量掌控的深度和广度，在保障业务容量充足的情况下，提高资源利用率。
• 可观测：快速发现、定位问题
  • 维度
    • Logging
      • 客户端：本地日志，随用户异常反馈时上传
      • 服务端：流水日志，受限于成本，仅保留核心系统日志或者采样上报。
    • Tracing
      • 接入公司链路追踪系统，核心链路+采样/白名单上报。
    • Metrics
      • Infra：基础设施，依赖容器平台等各平台的监控
  • 层级
    • 终端：从终端监控服务质量
      • 客户端cgi质量上报：客户端采样，上报cgi访问质量、cdn访问质量。采样默认比例1:10。服务端接收流水，上报到统计的Prometheus平台并告警。优势能覆盖所有现网接口&产线，且能快速定位产线、渠道等。不足：无现网流量时不能发现问题。
      • 拨测：从运营商&地区的角度来观察厂商到后台的服务质量。使用腾讯云的云拨测平台，配置核心接口告警策略。考虑到成本问题，仅配置核心接口以及重点地区+运营商。优势是不受终端网络质量（如开机场景下的cgi质量较差）、性能等影响，也可以覆盖香港、东南亚等小众场景。缺点：有一定的成本（配置、运营成本）
      • web：hippy、web等接入云APM监控（现在为腾讯云RUM），监控接口质量、首屏时长等指标。
    • 接入层
      • 公司接入层：公司接入层已有监控，优势是服务端最前端的监控，不受后台微服务的影响。不足是只能监控http相关指标，包括qps、状态码、延迟、rs状态等，无法兼顾业务错误码。
      • 业务自有接入层：能够自定义一些业务的监控措施。比如具体的cgi以及业务错误码（依赖公共公共header）
      • 后台统一接入层access(路由、统一鉴权、兜底、频控)：统一接入层，具备服务路由、鉴权以及统一的兜底、频控机制。
    • 后台微服务：rpc框架自带
      • 主被调、容器负载
      • 业务自定义监控
    • 综合指标监控
      • 用户反馈：用户反馈接入反馈平台，自动分析&告警。
      • 核心服务看板：借助公司Prometheus平台建设数据看板，对核心场景搭建核心场景的全链路的看板。
      • SLI平台：将业务服务质量数据接入SRE平台，以更加科学的方法来评定后台对外服务的长期质量情况。目前前后台已接入约100各服务/场景。

故障处理及复盘

• 问题处理手册&工具建设
  • 项目维护文档、问题定位工具建设
• 复盘
  • 复盘流程标准化：包括
    • 文档整理：影响评估、详细原因分析、改进措施预案（长期、短期）
    • 复盘评审机制：外部评委、开发、leader、总监以及相关团队。
    • 改进措施跟进，定期push&同步。

总结

1. 做好压测能力或混沌功能的建设。这个是校验系统稳定性措施是否完整的唯一且有效手段。个人感觉在落地上可以交互进行，避免负责人评估自己系统系统时出现盲目乐观的情况。
2. 监控：监控指标的重要程度就不提了。主要提醒的是后台同学通常仅关注自己的服务本身，缺乏全局的监控思维。这里需要负责人有全局监控视角，将监控覆盖到从终端到底层各层可能出现的意外情况。避免一叶障目不见泰山的情况。
3. 架构评审：推动过程中发现评审不仅能完善系统能力，同时也是一个技术交流的过程。这种机会对新人来说非常有帮助，同时也使得团队能够达成各种标准的统一。