青岛网站建设 青岛博采网络最近新闻大事
前言
稳定性是数学或工程上的用语，判别一系统在有界的输入是否也产生有界的输出。若是，称系统为稳定；若否，则称系统为不稳定。
前端稳定性的体系建设大约可以分为了发布前，发布后，以及事故解决后三个阶段。
在稳定性这一领域， 人的意识和经验与平台能力支撑一样重要。需要依赖平台提供的稳定性工具，但也需要对开发的过程和处理机制进行进一步规范，加强大家的稳定性意识。所以也分为了机制&规约 和 工具&平台能力两部分。
在机制和规约上，需要有整套规范的保障， 和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、线上问题修复与处理流程
总结
本文主要针对稳定性相关定义了一系列的规范，如之前所说流程上的规范和平台能力的建设一样重要。
最后
整理了一套《前端大厂面试宝典》，包含了HTML、CSS、JavaScript、HTTP、TCP协议、浏览器、VUE、React、数据结构和算法，一共201道面试题，并对每个问题作出了回答和解析。
有需要的小伙伴，可以点击文末卡片领取这份文档，无偿分享
部分文档展示：
文章篇幅有限，后面的内容就不一一展示了
有需要的小伙伴，可以点下方卡片免费领取