系统稳定性方法论 - 降发生

IT Panda

于 2021-04-25 07:09:10 发布

阅读量915

点赞数 1

分类专栏：沉淀 | 方法论架构 | 编码 | 设计模式文章标签：稳定性架构方法论

本文链接：https://blog.csdn.net/ilfrost/article/details/116115666

版权

13 篇文章 1 订阅

订阅专栏

4 篇文章 1 订阅

订阅专栏

上一篇<系统稳定性方法论 - 序篇>中提到了系统稳定性的4大抓手，今天就先说说其中的第一个 降发生

何为"降发生"

降发生指的是，从设计阶段开始，开发阶段、测试阶段、上线前的准备阶段、上线阶段到最后上线后的回归测试阶段，在这整个过程中，对所有阶段进行把控，将能出现异常的可能性消除。

这一阶段需要考虑的主要问题：除了最基本的"实现功能性需求"之外，更要设计和思考"如何实现非功能性需求"，而对于系统稳定性方向来说，就是如何设计系统防止被别人搞死。

举几个常见的"非功能性需求"

以上这些都是需要在设计阶段就决定好的，不能急于实现”功能性需求“去交差，而忽略这些”非功能性需求“…

不写bug是对所有开发者的最基本要求，也就是别被自己搞死…

开发阶段还需要考虑，代码的性能、维护性、可复用性…

首先要落地落实code review，很多时候code review都成了走过场，失去了code review的意义… 不仅做不到提前发现问题，更做不到知识共享。

那如何做好code review呢？说说理想情况下的code review：

首先与自己的backup做peer review，如果连你的backup都无法正确理解你的代码，那么怎么能指望团队的其他同学理解你的代码呢？
之后是团队code review，可以设置一个小型会议，大家坐在一起共同review代码，提出疑问与改进建议；这一阶段的code review效果与团队的技术氛围密切相关…

这里也吐槽一下，正确使用GIT也是code review的一大前提，发现很多开发者只做commit、merge… 怎么简单怎么来… 有时间也出一篇如何正确使用GIT的分享…

测试是上线前的重要环节，可以提前发现问题，也是上线前投入精力最多的一个阶段。

单元测试不能省，好的单元测试可以覆盖大部分场景，test coverage甚至可以作为RD的OKR。

很多团队都不做压力测试的，更别提全链路压力测试，其中有主观原因也有客观原因…

做好全链路压力测试不简单，涉及链路梳理、入口压测标识改造、系统间以及系统内部压测标识传递、中间件改造、影子库、流量回放等众多难点…

给自己再挖个坑，找机会出一篇全链路压测的分享

上线过程需要制定上线SOP，滚动发布、灰度发布，每发布一点就做一次检查，不要一次性的全量上线。上线后也要做线上的回归测试。

总结一下：
在这里插入图片描述

关注