一 研发阶段典型流程

二 需求阶段

一般在需求阶段都是产品经理写需求，程序员和架构师参与需求评审，确定实现需求的可行性和代价。一个高效的团队要有一套需求管理的系统，该系统能够展示需求的状态，是“未评审”“开发中”还是“已发布”等，并且记录整个需求的生命周期，通过该系统协同产品、设计、开发、测试等多个团队一起工作。

在评审需求时，产品经理要保证需求的完整性——开发人员和测试人员通过阅读需求单就可以进行后续工作，而不是还要通过开会才能详细了解需求。产品经理要保证文档尽量详细，内容无歧义。

目前可选用的工具是腾讯的 TAPD，业内也有许多其他类似的敏捷开发平台产品。开发团队依托于敏捷开发管理系统，管理项目在生命周期内的流转，需求管理系统为多团队敏捷开发提供了基础工具平台。

作为架构师，在需求评审阶段要为产品经理提供决策所需要的必要信息，包括实现的可行性、难度，大致工期的数量级（数量级可以为周、月、季度等）。有时要了解产品经理的真正需求，在需求评审阶段交换意见，最终确定实现目标的最优方案。否则可能会因为实现难度大，或者交付系统后用户不认可，最终返工。

三 开发阶段

1 架构评审

在开发阶段要进行架构评审，由具体开发人员和架构师设计系统的架构方案，然后同团队的资深工程师进行集体架构评审，主要是对架构的合理性和方案的优劣进行评审。

什么样的方案需要进行架构评审？通常开发的工作量超过三人天的方案，就可以进行架构评审。因为三人天是一个比较长的工期，对于长工期的工作，为了防止设计有偏差导致返工，花一些时间编写架构评审文档是值得的。如果工期很短的方案修改，则可以不经过评审。

架构设计模板

• 需求背景
• 系统限制
• 设计思路
• 整体架构
• 对外接口
• 数据结构和算法
• 主要流程描述
• 数据库表设计
• 性能分析

2 代码开发

如果团队采用 Git ，则可以使用 Gitflow 工作流程，保证团队开发井井有条、高效协作。

当然 Git 只是一个工具，即使团队采用其他的工具，也可参考 Gitflow 流程，或者指定一套符合实际情况的代码开发流程，保证多个开发人员多条线进行开发代码时代码不冲突。

3 开发环境和运维环境分开

在开发过程中，针对不同的目标构建多种运行环境。

• 开发环境：开发工程师开发代码时使用的环境，主要用于本地调试。
• 自测环境：开发工程师自测时使用的环境，用来和上下游关联的系统联调时使用。可以长期部署稳定的代码，在提交到测试环境前，一般都会使用。
• 测试环境：测试人员测试时使用的环境，开发人员不会对该环境进行操作，当开发人员提交测试申请时，测试人员根据提测的代码分支，把代码部署到这个环境中进行测试。
• 预发布环境：在系统正式上线前，开发人员把要上线的代码发布到预发布环境，用于系统上线前的验证和测试。
• 正式环境：外部用户所访问的环境，代码发布时的最终环境。

4 完善日志，设置告警百分比

在开发阶段就要把相应的日志、上报属性都添加好。

添加完日志和上报属性后，也要设置合理的告警，一般告警的属性值占全部属性上报量的 30 % 左右。

设置告警值的几种场景如下：

• 出现异常，需要人为干预的场景
• 超过正常请求量阈值的场景（发送消息数量超过了日常数值）
• 请求量降低到正常值以下的场景
• 资源消耗超过合理阈值的场景（CPU、内存、磁盘、网络带宽）

5 代码 review

代码提交测试前要进行代码评审工作，代码经过评审后才能提交测试。

评审代码是工程师之间互相学习的好方法，可以站在另一个人的角度发现代码的问题，增强开发人员的代码质量。

四 测试阶段

代码完成后，代码功能的正确性要通过测试来验证。

在将代码发给专职的测试人员之前，开发人员还需要自己进行测试。

自测主要验证两个方面：

• 逻辑正确性
• 性能瓶颈

逻辑正确性一般通过自动化测试和单元测试进行测试。

衡量测试工具是否合适有两点：

• 测试用例是否方便执行
• 测试执行是否快速

一般单元测试用例都在代码库里，当提交代码的时候，会自动触发集成程序运行用例，保证用例启动，并且执行成功后会反馈测试结果。

由于保留了测试用例，接手程序的新开发人员通过测试用例就可以了解程序的内部原理，这也是一种快速熟悉项目的方法。

还有一种自动测试的方法就是构建测试平台，测试平台以外部用户的角度进行黑盒测试。开发人员在提交代码后，触发测试平台进行自动化测试。测试时可以看到测试用例运行的效率和正确率。

除了验证逻辑正确性，在后台程序中，还要通过压测来验证程序的性能，找到程序的性能瓶颈。压测相对于对程序的一个小规模的模拟演习。

开发人员自测和测试人员测试的角度是不同的。测试人员的测试更多是对程序的边界，以及是否符合产品需求类对程序验证。开发人员的自测关注程序内部逻辑多一些，更多关注输入与输出是否符合预期。两种测试实现互补。

五 发布阶段

发布主要分为大版本和小特性发布。

大版本发布的是软件的一个新版本，通常涉及很多功能的变更，或者是一个从 0  到 1 的新系统。产品经理、项目经理、开发人员、测试人员、设计人员等都要在上线前体验预发布环境，验证发布的版本是否符合预期。一都会有一个 Checklist，针对每个角色需要做的工作，由相应负责人按照模板检查后一一填写结果。最终确定没问题后，开发人员和运维人员再按照发布节奏发布软件。

这里的 Checklist 大多是一些例行事务的检查。以开发为例，包含以下内容。

• 确认发布时间
• 确定发布顺序
• 检查需要的资源和权限
• 评审执行的脚本命令
• 检查依赖软件是否正常安装并配置正确

如果是小特性发布，那么一般是为了增强系统提供的能力、修复 bug 等，可以直接创建特性分支。在小特性发布前，仅需要开发人员内部进行检查，然后发布即可。小特性发布相比大版本发布参与的角色会少很多，但对于开发侧，执行的方式，还有待发布的认真程度是一样的。凡是对运营环境进行变更操作，我们都要有敬畏之心，要保持谨慎的态度，以系统稳定为首要目标。

开发完成之后，还要写部署文档，下面是一个模板示例。

• 业务背景
• 业务流程
• 业务模块上下游负责人
• 实际部署架构图
• 申请权限
• 监控视图地址
• 部署机器的IP地址
• 对环境是否有要求
• 项目代码路径
• 其他

六 运营阶段

在运营阶段，工程师要多关注运营数据、程序上报日志和告警，针对运营环境的变化对程序部署进行处理。

在运营阶段，有时会因为一些变更，或者外部原因导致程序触发 bug，运行的程序产生异常，对用户造成影响，形成事故。

处理事故时要注意以下两点：

• 及时将事故同步给 Leader 和相关人。
• 尽快恢复业务。

在业务恢复后，再查找事故具体原因，对程序进行修复和加固。针对事故的原因和问题进行复盘，寻求解决方案。可以按照事故报告模板进行书写和跟进。

书写事故报告是为了积累经验，从事故中学习事故的处理方法，而不是为了处罚，要以正确的心态对待事故报告。

事故报告主要包含下面内容：

• 事故的具体描述
• 处理过程
• 事故影响
• 问题分析
• 改进措施

七 管理机制

1 值班机制

在互联网行业，一般在节假日期间，用户的访问量会突增。但这个时候往往也是开发人员最少的时候，在节假日，开发人员要保持手机畅通，能够通过 VPN 处理紧急事故。同时要有人在节假日期间安排值班，观察服务是否正常，快速处理隐患。

2 项目交接

互联网业务发展比较快，行业人员变动比较大。项目有时要进行交接，由于开发频率很快，所以文档即使完善，也达不到传统软件文档的完备程度。

一个成熟的团队要有一套完备的项目交接流程。

最基本的要求是要让接手人熟悉项目架构文档和项目部署文档，了解项目设计原理和实际部署情况。

八 文化

1 工具文化

如果一个操作，你已经手工做过三次，那么要尽快用工具来实现这个操作。

对于反复重复的工作，都要思考是否能将其做成服务化的模块，或者变成自动的。

2 学习分享

互联网技术更新速度快，我们要持续学习，才不至于落后，对于新技术要有敏锐的嗅觉，多接触外界的新技术，新想法，多多 demo 进行测试，然后试验项目，最终达到大规模应用的目的，最好还能输出方法论。

3 就事论事

在开发过程中，对于技术方案，团队成员之间的理解不一定一致，这种情况下要直言不讳，针对需求或方案提出自己的观点，其他人的反对观点也要直接说出来，就事论事，站在技术的角度去讨论需求或方案。这样才能发现问题，团队技术能力才能提高。