likes
comments
collection
share

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

作者站长头像
站长
· 阅读数 16

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

前言

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

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

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

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

在机制和规约上,需要有整套规范的保障, 和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报警不做要求不做要求不做要求微信群

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

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

总结

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

转载自:https://juejin.cn/post/7167626191451947039
评论
请登录