技术Review:不同体量设计安排经验更加丰富同学Review,架构师、主管、外部架构师的Review、定期系统整体Review等。 代码Code Review:建立规范和标准,通过CR认证合格同学执行code review动作。 单测:不同风险的系统设定尽量高的行覆盖 & 分支覆盖率标准,复杂逻辑类追求100%分支覆盖。 回归测试:持续积累回归用例,在上线前和上线后执行回归动作;上线前线上引流测试也是一种模拟测试方式,端类型系统还可以用monkey工具做随机化测试。 发布机制:设计发布准入和审批流程,确保每次上线发布都是经过精细设计和审核的,上线过程要做到分批、灰度、支持快速回滚、线上分批观察(日志确认)、线上回归等核心动作。建立发布红线等机制,不同系统设计合适发布时段以及发布灰度观察周期。 团队报警值班响应机制 (报警群、短信、电话):确保报警有合适人员即时响应处理,团队层面可定期做数据性统计通晒,同时建立主管或架构师兜底机制。 定期排查线上隐患:定期做线上走查和错误日志治理、告警治理,确保线上小的隐患机制化发现和修复。例如在钉钉针对企业用户早晚高峰的特点,设计早值班机制,用于高峰期第一时间应急以及每天专人花一定时间走查线上,该机制在钉钉技术团队持续践行多年,有效发现和治理了钉钉各个线上系统的隐患。 用户问题处理机制:Voc日清、周清等。在钉钉也经历Voc周清到日清的持续机制精进。 线上问题复盘机制:天内、周内问题及时复盘,确保针对每个线上问题做系统和团队精进。 代码质量抽查通晒:定期抽查团队同学代码,做评估和通晒,鼓励好的代码,帮助不好代码的改善。 成立稳定性治理专门topic:合适同学每周做好稳定性过程和精进。 定期压测机制:定期机制化执行,核查线上容量情况。 日常演练机制:预案演练,模拟线上故障的不通知的突袭演练提升团队线上问题应对能力。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。