软件开发人员在职业生涯早期就会了解到，没有什么比修复生产故障更紧急的事情了。放下手中的一切！全体员工上阵！然而，对于我们开发工具、构建系统、质量保证环境以及软件开发流水线其他部分的问题，往往没有给予同样程度的紧迫感。但对于开发团队而言，开发流水线就是一个生产系统。软件开发者的工作是为公司创造价值。有时这意味着构建新功能，有时则意味着为客户的生产系统修复关键性错误。但这一切在软件开发流水线出现故障时都无法进行。如果代码无法编译，开发人员就无法履行自己的职责，团队也无法生产软件。对于开发团队而言，这就是一次生产故障。修复此问题应该是首要任务。如果QA服务器宕机，测试人员就无法履行自己的职责，团队也无法生产出可用的软件。对于QA团队而言，这也是一次生产故障。修复它应该是首要任务。你不会惊讶地发现这是我自己画的。在制造业中，有大量的流程和程序来防止和减少装配线上的停机时间。而类似的流程也存在于IT服务停机的情况下。但我发现大多数这些流程关注的是为客户提供服务时的停机，而不是负责构建和支持这些服务的人。我建议考虑所有将你从“客户想要某物”带到“某物交付给客户”的组件：问题报告和变更请求系统，如GitHub Issues、Jira等；开发人员用来直接构建软件的工具，如IDE、构建工具（Gradle、Maven等）、包存储库（npm、Maven Central、内部存储库等）、本地数据库、容器等；CI/CD工具（Jenkins、GitHub Actions等）；故障测试套件（如果测试失败，肯定不应该将其部署到生产环境？）；QA服务器故障（如果QA没有测试，肯定不应该将其部署到生产环境？）；过程中的任何一步，阻止你进行更改并将其部署到生产。一个拥有损坏开发流水线的团队无法生产软件，必须将此视为生产故障。 有趣的是，他们通常称之为“生产线”。软件业中“生产”这个术语的使用是否与制造业的历史相关？