一、前端稳定性规约该如何制定

theme: channing-cyan

前言

稳定性是数学或工程上的用语，判别一系统在有界的输入是否也产生有界的输出。若是，称系统为稳定；若否，则称系统为不稳定。

前端稳定性的体系建设大约可以分为了发布前，发布后，以及事故解决后三个阶段。

在稳定性这一领域， 人的意识和经验与平台能力支撑一样重要。需要依赖平台提供的稳定性工具，但也需要对开发的过程和处理机制进行进一步规范，加强大家的稳定性意识。所以也分为了机制&规约 和 工具&平台能力两部分。

在机制和规约上，需要有整套规范的保障， 和RCA的介入。小范围的线上问题， 都需要经过系统性的复盘。在处理线上问题过程中，处理动作和流程需要遵循规范。

平台能力支撑方面，主要可分为线上问题的排查能力、报表分析能力、用户行为串联以及白屏率指标和智能报警能力。

稳定性五大规范

原则：线上稳定性是第一优先工作

• 线上已知的稳定性问题，永远是第一优先级
  • 收到报警先评估影响，如果是稳定性问题必须停下一切去处理
  • 线上服务即使是偶发的Crash，也必须追查触发原因
  • 线上稳定性隐患，需要记录并在每次迭代的时候考虑修复排期
• 敬畏每一条报警，不能无视线上报警
  • 拆分重要报警和不重要的提醒
  • 重要的报警可以设置电话报警
  • 业务负责人/值班人，夜间需要保持电话畅通
• “当时在……” /“因为……没看到报警”都是可耻的辩解行为
  • 设置合适的互备人员
  • 把报警发到群里
• 就算不是自己负责的业务，也需要尽量补位
  • 就算不是自己负责的服务，看到线上问题都可以通告、找人确认，确保已经有人在跟进

处理问题：先通告，后处理；先止损，再查因

• 先通告，后处理
  • 线上出现问题后，除了既定的快速止损 SOP 外，一定要先通告，后处理。
  • 通告的好处：
    • 避免多人操作冲突
    • 和团队通报进展
    • 引入更多人复查
• 先止损，再查因
  • 【回滚】上线过程出问题，不要想为什么，直接回滚
  • 【切流】单可用区出现问题，优先尝试切流
  • 【降级】夜间高峰期出现失败率增长，大概率是容量问题，优先尝试降级限流和扩容

线上变更：有灰度，做检查，不跨区，可回滚

• 变更有灰度
  • 灰度常见方式是：Canary实例、分区操作等
  • 实验属于策略灰度，从稳定性角度看是全局的
• 每个节点做检查
  • 光有灰度也不行，需要在灰度等待足够时间，并且完成明确的检查项
  • 检查项需要经常更新，如果有误报需要及时清理，避免狼来了现象
• 单次操作不跨区
  • 对于已经双活部署的服务，操作时需要分可用区操作，这样如果操作有问题，可以通过切流尽快止损
• 所有变化可回滚
  • 可回滚：回滚总时间 < 变更总时间
  • 每一个对线上的变更操作，都需要有明确的回滚方案
  • 尽可能采用幂等操作或声明式接口去执行操作

高可用设计：Design For Failure

• 考虑最坏情况，任何单个基础设施都是会故障的
  • 公有云上，任意单一资源 ID 代表的设备，“无论他承诺了多高的可用性”，都是会故障的
• 处理超时
  • 设置backup request控制长尾超时，而不是设置很大的超时
  • 拆分不同响应时间的业务场景，分别设置超时
• 对数据做兼容性/完整性检查
  • 0值，空值特别需要注意

管理要求：允许试错、严惩违规

• 允许试错
  • 大胆假设，小心求证
  • 踩坑是正常的
  • 特别鼓励不畏困难，解决历史遗留问题的行为
• 严惩违规
  • 明确定下的规则，需要被严格遵守
  • RCA后的Action Item需要及时处理
  • 写出 BUG 是正常的，但不做任何测试就上线是违规的
  • 上线出现问题回滚是正常的，但上线过程不做检查是违规的
  • 偶尔的误操作是可以被谅解的（当然还是尽量不要出现），但企图掩盖误操作的行为是违规的

前端发布SOP

1、发布计划

开发时间>3PD项目，均需要给出发布计划

• 需求背景：简单介绍本次需求背景
• 实现方案：开发设计方案文档 & 系分方案
• 主要改动点：改了那些页面，那些业务模块
• 影响范围：评估改动影响范围
• 发布顺序：结合后端发布计划，确定发布顺序（service、配置、前端项目的发布顺序）。
• 监控指标：确定当前版本需要监控指标，比如白屏，接口okr，js error，客户端crash率，OOM率等等
• 应急预案：降级开关/预案、切流开关/预案、回滚方案

2、发布分支

必须是master分支

3、发布时间

• 法定工作日（不含加班日）尽量避开业务高峰期（各业务需自行判断）
  • 例如以下系统，10点～11点尽量不要做发布，建议中午12点～2点，下午3点之后进行发布
    
• 灰度canary实例的时间至少经过一个业务高峰，灰度满两小时

4、发布前提

• Bug确认修复完毕
• UI走查通过（有设计稿）
• 产品验收完成
• Code review完成
• 依赖方确认发布完成

5、发布流程

线上问题处理SOP

1、线上反馈定级与评判标准

1.1、问题类型

• 线上问题：由于开发的代码或技术设计问题，导致项目发布后产生的bug
• 外部依赖问题：由于系统依赖的上游系统出现故障导致的bug
• 系统遗留bug：已知的系统Bug，可能由于系统设计初期遗留的问题，或短期无法解决的问题
• 产品需求bug：产品在需求设计上没有考虑充分，导致存在的漏洞
• 稳定性问题：
  • 系统波动：对用户操作有一定的影响，一般排查较为困难，和用户电脑配置、环境或者用户操作等也有一定的关系
  • 系统故障：影响面比较大，用户无法操作及使用

1.2、常用解决步骤

• 线上问题：需要根据Bug定级标准评估后，由开发、测试、产品共同决定应该立即回滚、立即修复或排期修复
• 外部依赖问题：明确上游依赖系统的技术对接人，及时反馈问题，跟踪解决
• 系统遗留 bug：此类bug优先级一般不高，且存在较久，需要衡量投入产出比后，开发排期修复
• 产品需求bug：产品根据优先级评估，完善产品流程后，排期优化
• 稳定性问题：
  • 系统波动：查看日志，监控等确认问题。
  • 系统故障：反馈SRE & 基建相关方处理

1.3、问题定级

• 致命(critical) 功能影响：系统主流程无法工作，阻碍核心功能使用。
  • 影响范围：影响范围广
  • 采取策略：
  • 业务上线导致：执行回滚计划，立即回滚
• 严重(high) 功能影响：阻碍特定常用模块功能使用，或问题影响大部分用户。
  • 影响范围：影响部分用户
  • 采取策略：评估是否能立刻修复（半小时内），否则立即回滚
• 一般(medium) 功能影响：不影响主流程和常用模块，低频模块功能受阻，或小的特性影响，例如显示异常、UI展示错误，接口响应慢等。
  • 影响范围：影响小部分用户
  • 采取策略：上线导致的bug：开发评估，是否能短期修复（1d内），产品及测试评估，是否集中修复上线，否则走下一个周期产品排期迭代
• 轻微(low) 功能影响：文案错误，美观体验性、易用性、遗留问题、合理性建议等问题。
  • 影响范围：影响极少数用户
  • 采取策略：走下一个周期产品排期迭代

2、线上报警响应和升级标准

3、线上问题修复与处理流程

总结

本文主要针对稳定性相关定义了一系列的规范，如之前所说流程上的规范和平台能力的建设一样重要。