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

前言

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

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

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

在机制和规约上，需要有整套规范的保障，和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、线上报警响应和升级标准

报警级别	响应&处理	解决（要求）	报警升级（标准要求）	系统提醒
P0报警	立即响应;0 ~ 10min 内响应	尽快解决;0 ~ 30min内需解决	10min内如没有响应，报警需升级至团队TL30min内如没有解决，报警需升级至团队TL备注：响应后30min内不再电话重复报警通知同一人	电话，微信群，私信
P1报警	尽快响应;0 ~ 1h内响应	尽快解决;0 ~ 2h内需解决	1h内如没有响应，需升级报警为P0级别报警2h内如没有解决，需升级报警为P0级别报警	微信群，私信
P2报警	尽快响应;0 ~ 12h 内响应	尽快解决;0 ~24h内需解决	P2由业务负责人决定要不要升级	微信群
P3报警	不做要求	不做要求	不做要求	微信群