开发流程就是一个生产系统

软件开发者在职业生涯早期就知道，没有比修复生产环境故障更紧急的事情了。放下一切！全员待命！

然而，我们的开发工具、构建系统、QA 环境以及软件开发流程中的其他部分遇到问题时，却很少得到同等的重视。但对开发团队而言，开发流程就是一个生产系统。

软件开发者的工作是为公司交付价值。有时这意味着构建新功能，有时意味着为客户的生产系统修复关键 Bug。但当软件开发流程中出现故障时，这一切都无法进行。

如果代码无法编译，开发者就无法完成工作，团队就无法产出软件。对开发团队来说，这就是生产故障。修复它应该成为最高优先级。

如果 QA 服务器宕机，测试人员就无法完成工作，团队就无法交付可正常运行的软件。对 QA 团队来说，这就是生产故障。修复它应该成为最高优先级。

在制造业中，有大量流程和规程用于预防和减少装配线的停机时间。1 类似流程也存在于IT 服务故障中。但我发现，这些流程大多针对的是面向客户的服务故障，而非面向构建和维护服务的人。

我建议思考从“客户提出需求”到“需求交付给客户”的所有环节：

• 问题报告与变更请求系统，如 GitHub Issues、Jira 等
• 开发者直接用于构建软件的工具，如 IDE、构建工具（Gradle、Maven 等）、包仓库（npm、Maven Central、内部仓库等）、本地数据库、容器等
• CI/CD 工具（Jenkins、GitHub Actions 等）
• 失败的测试套件（你肯定不会在测试失败时部署到生产环境吧？）
• QA 服务器故障（你肯定不会在 QA 尚未测试通过时部署到生产环境吧？）
• 流程中任何阻止你修改代码并部署到生产环境的步骤

开发流程故障的团队无法产出软件，必须将其视为生产故障。

1 有趣的是，制造业常常称之为“生产线”。软件领域中“生产”一词的使用是否与其在制造业的历史有关？ ↩