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

前言

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

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

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

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

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

稳定性五大规范

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

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

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

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