稳定性建设杂谈

目录

前言

需求评审

技术评审

开发编码

自测&QA测试

代码合并

上线评估

日常维护

故障响应

权限管理

分支管理

Scrum迭代

总结

前言

        稳定性建设，是个比较宽泛的话题。从广义上来说，可以贯穿到软件开发中的方方面面，因为任何一个小的点没有做好，都可能最终影响线上生产环境的稳定性。而除了软件开发过程（功能迭代和技术改进优化），基础建设对于系统稳定性也至关重要。本系列以Java技术栈和Scrum敏捷开发为背景，以功能迭代为主要线索，以方法论为主，不涉及太多具体的技术选型，谈一下如何保障系统的稳定性。

        从研发视角来看软件开发大致可以分为需求评审、技术评审、开发编码、自测&QA测试（测试阶段）、上线评估、代码合并、发布上线、日常维护和故障响应等九个阶段。后面的行文也会按照这个思维导图来进行展开。

需求评审

        在一般互联网公司中，需求（feature）评审阶段主要是由产品经理牵头，组织相关业务侧的产品、研发等同学一起参加（如果有必要甚至可以拉上测试）。在这个评审过程中，开发的同学需要基于对原有系统的认知，评估需求的合理性和可操作性。如果是开发量大，影响面大的需求，应该有高P或者manager级别的同学在场，帮助把控和判断。

技术评审

        在前面需求评审结束之后，负责开发的同学需要在开发前产出dev design文档。在该文档中，开发同学需要定义开发的边界（todo & not todo）、接口定义、数据库定义、数据流程、风险评估等。文档的产出，一来可以作为评审的材料，评审通过后可以进行实际的开发工作。二来可以作为存档，记录项目的迭代进程，以便之后回顾和追溯。

        这个步骤在管理侧的执行细则可以视具体情况灵活制定，如果改动面、影响面、开发量不大，可以从简执行。这个阈值需要团队协商产生，例如小于3个点的开发量，就不开这个技术评审会了；小的改动可以通过jira任务的形式让团队知晓，文档的记录可以由多个小改动合并而来，等等。

开发编码

        这个部分是纯技术的部分，前面在技术评审时应该确认清楚开发方案和影响面。包括以下方面但不限于：对数据库的影响（是否影响线上已有数据、是否能达到产品需要的效果、是否等留有因应中长期数据增长所需要的扩展性）、对业务上下游的影响（对其他服务的接口产生的qps评估、如果需要能否保证接口幂等和消息幂等、提供出去的接口是否友好、上下游消息消费速度是否会相差过大以致堆积）、对中间件的影响（是否正确使用分布式锁、缓存会不会产生大key、缓存有没有过期淘汰机制）、对前端的影响（给前端的接口返回耗时能否满足产品需求）、对自身服务的代码的影响（有没有按照代码规范做到低耦合高内聚、会不会产生频繁minor gc/full gc）。另外还要养成写单测的习惯，这个习惯在我见识过的程序员里并不多见，但往往高质量的单测能提前发现很多低级bug。

自测&QA测试

        自测部分，我理解既包括自己代码的测试，也包括可能的与前端、其他后端服务的联调。自己代码的测试部分，如果有条件可以在本地测试，尽可能采取本地测试的方式，不管是mock数据、mock请求的方式或者用现成的测试数据，总之研发侧都需要走一遍核心的业务流程，尽可能测一些edge case。至于联调，就需要各方的代码都具备一定的健壮性，否则由于木桶效应，降低人效。

        QA测试部分，就需要QA部门和研发部门的协调。（注