网站建设的部署,杭州画册设计公司,农场会员营销网站建设,吴江住房和城乡建设局网站前言
稳定性是数学或工程上的用语#xff0c;判别一系统在有界的输入是否也产生有界的输出。若是#xff0c;称系统为稳定#xff1b;若否#xff0c;则称系统为不稳定。
前端稳定性的体系建设大约可以分为了发布前#xff0c;发布后#xff0c;以及事故解决后三个阶段…前言
稳定性是数学或工程上的用语判别一系统在有界的输入是否也产生有界的输出。若是称系统为稳定若否则称系统为不稳定。
前端稳定性的体系建设大约可以分为了发布前发布后以及事故解决后三个阶段。
在稳定性这一领域 人的意识和经验与平台能力支撑一样重要。需要依赖平台提供的稳定性工具但也需要对开发的过程和处理机制进行进一步规范加强大家的稳定性意识。所以也分为了机制规约 和 工具平台能力两部分。
在机制和规约上需要有整套规范的保障 和RCA的介入。小范围的线上问题 都需要经过系统性的复盘。在处理线上问题过程中处理动作和流程需要遵循规范。
平台能力支撑方面主要可分为线上问题的排查能力、报表分析能力、用户行为串联以及白屏率指标和智能报警能力。
稳定性五大规范
原则线上稳定性是第一优先工作
线上已知的稳定性问题永远是第一优先级* 收到报警先评估影响如果是稳定性问题必须停下一切去处理* 线上服务即使是偶发的Crash也必须追查触发原因* 线上稳定性隐患需要记录并在每次迭代的时候考虑修复排期敬畏每一条报警不能无视线上报警* 拆分重要报警和不重要的提醒* 重要的报警可以设置电话报警* 业务负责人/值班人夜间需要保持电话畅通“当时在……” /“因为……没看到报警”都是可耻的辩解行为* 设置合适的互备人员* 把报警发到群里就算不是自己负责的业务也需要尽量补位* 就算不是自己负责的服务看到线上问题都可以通告、找人确认确保已经有人在跟进
处理问题先通告后处理先止损再查因
先通告后处理* 线上出现问题后除了既定的快速止损 SOP 外一定要先通告后处理。* 通告的好处* 避免多人操作冲突* 和团队通报进展* 引入更多人复查先止损再查因* 【回滚】上线过程出问题不要想为什么直接回滚* 【切流】单可用区出现问题优先尝试切流* 【降级】夜间高峰期出现失败率增长大概率是容量问题优先尝试降级限流和扩容
线上变更有灰度做检查不跨区可回滚
变更有灰度* 灰度常见方式是Canary实例、分区操作等* 实验属于策略灰度从稳定性角度看是全局的每个节点做检查* 光有灰度也不行需要在灰度等待足够时间并且完成明确的检查项* 检查项需要经常更新如果有误报需要及时清理避免狼来了现象单次操作不跨区* 对于已经双活部署的服务操作时需要分可用区操作这样如果操作有问题可以通过切流尽快止损所有变化可回滚* 可回滚回滚总时间 变更总时间* 每一个对线上的变更操作都需要有明确的回滚方案* 尽可能采用幂等操作或声明式接口去执行操作
高可用设计Design For Failure
考虑最坏情况任何单个基础设施都是会故障的* 公有云上任意单一资源 ID 代表的设备“无论他承诺了多高的可用性”都是会故障的处理超时* 设置backup request控制长尾超时而不是设置很大的超时* 拆分不同响应时间的业务场景分别设置超时对数据做兼容性/完整性检查* 0值空值特别需要注意
管理要求允许试错、严惩违规
允许试错* 大胆假设小心求证* 踩坑是正常的* 特别鼓励不畏困难解决历史遗留问题的行为严惩违规* 明确定下的规则需要被严格遵守* RCA后的Action Item需要及时处理* 写出 BUG 是正常的但不做任何测试就上线是违规的* 上线出现问题回滚是正常的但上线过程不做检查是违规的* 偶尔的误操作是可以被谅解的当然还是尽量不要出现但企图掩盖误操作的行为是违规的
前端发布SOP
1、发布计划 开发时间3PD项目均需要给出发布计划 需求背景简单介绍本次需求背景实现方案开发设计方案文档 系分方案主要改动点改了那些页面那些业务模块影响范围评估改动影响范围发布顺序结合后端发布计划确定发布顺序service、配置、前端项目的发布顺序。监控指标确定当前版本需要监控指标比如白屏接口okrjs 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道面试题并对每个问题作出了回答和解析。 有需要的小伙伴可以点击文末卡片领取这份文档无偿分享
部分文档展示
文章篇幅有限后面的内容就不一一展示了
有需要的小伙伴可以点下方卡片免费领取
