共计 2388 个字符，预计需要花费 6 分钟才能阅读完成。
对于一个开发工程师，一个团队的负责人，系统稳定是我们的追求，或者说是要求，如果做到系统稳定呢，总体还是在于规范研发流程，如下是我工作几年来总结的能有效确保系统稳定的点
需求评审
1 能跟产品经理撕是一种能力，从经验上来看，不稳定的系统，产品需求就存在很多不合理的地方，
如果不能有效的梳理需求，明确业务上想要的是什么东西，稳定性无从谈起。产品经理设计的系统是否易懂易用是一个需要仔细评估的点，线上百分之八十的运营事故都是由于系统难用，信息不对称造成的
2 时间节奏也是个问题，要倒逼产品经理在什么时间点必须要搞定，如果按照约定的节奏还有问题就需要上浮。
最优的实践是按照固定的迭代节奏开发，比如两周一个开发节奏，到点交付没有问题的 prd。
很多项目的延期都是由于在设计开发阶段还在跟产品经理聊需求导致的，在架构设计之前一定要确认所有需求问题。
架构设计
1 架构设计要遵循简单原则，同等条件下哪个方案是最简单的，最容易理解的，哪个就应该是第一选择，遵循奥卡姆剃刀原则。
2 架构设计图中最重要的是 ER 图和时序图和状态机，为什么 ER 图重要呢，ER 图确认了模型，只要数据模型设计的好，代码即便是有点问题也不会造成大问题。不要求严格遵循三范式，但是一定要明确哪些是主数据，哪些是冗余的数据，冗余数据有没有更新机制，为什么冗余一定要想清楚。
在现在微服务背景下，对于不会变更的数据如果能冗余就冗余下，减少对其他方的调用
时序图能明确系统间的调用，详细完善的时序图能帮助开发理清逻辑，通过时序图能一眼就明白这个系统做了什么，所以时序图很重要
状态图为啥重要呢，业务状态机是事件驱动的，在业务状态较多的情况下，状态机尤其重要
3 架构设计好之后需要架构评审，评审需要架构师和测试同学的参与。要确保这套架构师方便测试的，容易测试，能以在测试或者冒烟环境验证的架构就是烂架构，稳定性无从谈起
4 要有固定的评审模板 checklist，确保不要遗漏任何应该注意的问题，架构评审 checkList 将架构设计的过程制度化流程化
编码 / 开发测例完善
1 编码一定要遵循开发规范，按照团队规定开发原则或者严格要求遵循阿里开发规范编码，如果是 java 语言需要强制要求全员安装 p3c 插件；协同软件的规范也很关键，比如 git, 要明确好团队 git 等协作软件的标准姿势
2 完善的测试用例能规避不少线上问题，通过测例检查工具规范测试用例的完成情况，不符合要求的不允许提测
测试用例评审
上一步讲的是开发的自测测试用例，这一步说的是测试同学的用例，很多人都会忽略这一步，这一步其实是很关键的，QA 同学编写好测试用例之后，
在评审的过程中，开发同学去检查一下是不是两边有理解不一致的地方，有没有 gap 可以确保 QA 会测试到你写的任何逻辑，有效保证系统稳定性
codeReview
代码 review 很多团队都搞不起来，原因无非是因为觉得没必要浪费时间，二来是没有轻松的环境能做这块，review 成了大型怼人现场，所以团队氛围很重要，TL 对这块的引导很重要，codeReview 的作用第一是看问题，看代码可读性怎么样，这块没有工具，只能人肉，在这个过程中 QA 也可以参与，相当于大家一起白盒测试了
第二是引起大家的重视，如果你的代码会被 codereview，为了不丢人，质量肯定会更高一点
灰度上线 / 发布 sop
1. 上线后一定不能全量，在架构评审阶段就要想好怎么灰度，按照什么维度灰度，要确认好灰度节奏。如果讲 bug 没法避免，灰度而不是全量至少会将问题缩小，在灰度阶段如果发现问题影响面更小
2. 上线发布需要严格遵守公司及部门的发布 sop，比如先发一台机器，再慢慢发布完一个机房，再全量等，还有发布的时候要注意查看监控，有明确的回滚策略等
资损核对
很多公司的研发流程都没有资损核对这一环, 没有工具做核对，没有专门的系统搞这块，因为这块确实会耗费人力，但是对于问题发现却很有必要，业务层和能力层的核对，主订单和子订单的核对，模板和业务的核对，数据存储字段跟列值是否匹配等都能提前发现很多问题，对于稳定性相当重要。实时和离线的资损 / 核对系统能发现系统性的风险，相当于给业务系统上了一道保险，
监控 / 报警和报表
1. 监控系统现在是各公司的标配，在现有各大厂都是微服务背景是监控的重要不言而喻，对于稳定性最重要的其实是监控系统中的打点告警，通过在代码中植入打点，在监控系统配置各种类型的监控可以有效的提高稳定性，比如调用忽然变多，变少或者掉底，都有可能有潜在的问题，在用户 / 业务反馈之前提前发现问题，解决问题是一个高可用系统必须的要求。
2. 跟大数据计算相关的服务，要配置数据质量校验脚本，对于 olap 类型任务，数据质量校验应该是标配
3. 监控报警能发现都是单个问题，T+ 1 报表能从全局发现问题，同比环比分析能发现很多隐藏的点，尤其是跟业务相关的，开发要站在全局视角看是不是有问题，虽然 T + 1 晚了一天，没有实时性，但是总比过了好几天才发现问题要好。
复盘 / 反思改进
代码是人写的，如上环节任何一环如果执行的不彻底，都有可能有 bug，出现 bug 一定要复盘，复盘的第一个作用反思改进流程，梳理总结踩过的坑，避免其他人再踩，
第二个作用是通过流程化的复盘，使得大家重视这块
写在最后
研发流程复杂，重要的是流程化，不管是体现在项目管理系统还是走邮件都是很好的形式，要有仪式感，这本质是个管理问题，TL 要通过一系列的流程来怪范，而不是靠自己督促。机器是靠谱的，流程是靠谱的，人是不靠谱的，任何人为没有流程化，想到哪算哪的点都有问题
如上基本上总结了整个研发流程的所有过程，这些点需要有开发去落实，只有所有的开发能意识到稳定性的重要性，并在激励层面愿意做那些看不见的地方，稳定性才能有保证，团队的执行力决定了系统的可靠性，所以本质上都是人的问题，靠谱有担当并且能力强的开发才是稳定系统的关键，一切能为团队找到高 P 开发的方法都是值得的
