为什么说 DevOps 是一种文化，而不是一种角色

“DevOps 不是一个职位名称，而是一种思维模式，它改变了团队共同构建和运维软件的方式。”

目录

1. 介绍
2. 问题：对DevOps的误解
3. DevOps 作为一种文化转变
4. 为什么 DevOps 不是一个职位名称
5. 有趣的统计数据
6. 现实世界的影响
7. 常见问题解答
8. 要点总结
9. 结论

1. 引言

DevOps 是软件开发领域最具变革性的变革之一，但同时也是最容易被误解的变革之一。许多组织将 DevOps 视为一个职位或部门。他们聘请“DevOps 工程师”，并期望交付速度、可靠性和协作能力能够立即得到提升。
但事实是，DevOps 不是一个职位，而是一种文化。DevOps
的核心在于打破开发和运维之间的壁垒，促进责任共担，并实现软件的快速、安全和持续交付。DevOps 的成功不在于某个人，而在于团队的协作方式。

2. 问题：对 DevOps 的误解

尽管DevOps已被广泛采用，但它经常被误解：

• DevOps 作为职位名称：公司聘请“DevOps 工程师”，并期望他们能够凭借一己之力改造整个流程。
• 工具优先心态：团队专注于 CI/CD 工具，但忽略了文化、协作和流程。
• 职责孤立： DevOps 变成了一个独立的部门，而不是一种共享的理念。
• 运维交接仍然存在：开发团队仍然将代码一股脑地扔给运维人员，希望他们能够运行它。

这种方法完全误解了DevOps的本质。如果没有文化变革，工具和角色都无法发挥其全部优势。

3. DevOps 作为一种文化转变

真正的DevOps成功始于思维模式和协作，而非招聘或工具。以下是真正DevOps文化的定义：

3.1 共同责任
开发团队和运维团队都对软件生命周期（从代码到客户）负责。不再有“这不是我的工作”这种心态。

3.2 协作而非交接
团队从一开始就协同工作。开发人员了解他们的代码在生产环境中的运行情况。运维团队了解开发人员需要什么才能快速推进项目。

3.3 持续反馈循环
监控、告警和可观测性使双方都能了解系统运行状况。开发人员响应问题，运维人员在规划阶段提供洞察。

3.4 信任与自主
开发人员有权部署自己的代码。运维团队提供安全的基础设施和保障措施。团队成员彼此信任，并各自承担相应的责任。

3.5 从失败中学习
团队不会互相指责，而是进行回顾总结。他们通过共同学习来发现流程改进点并增强韧性。
真正的DevOps文化意味着每个人都对质量、性能和交付速度负责。

4. 为什么 DevOps 不是一个职位名称

DevOps 不是某个人“做”的事情。以下是为什么将 DevOps 视为一种角色会产生误导的原因：

4.1 加强了信息孤岛
招聘“DevOps 人员”通常意味着将管理基础设施和自动化的重担交给一个团队——而其他所有人则继续像以前一样工作。

4.2 它限制了协作
团队可能会认为“DevOps工程师”负责部署和监控，因此开发人员脱离了运维工作，反之亦然。

4.3 它没有抓住重点
DevOps 的本质在于转变团队协作方式，而不是将工作委派给专家。每个团队成员都必须树立这种思维模式。

4.4 DevOps工程师依然存在
尽管如此，支持DevOps文化的岗位仍然具有价值：

• 站点可靠性工程师（SRE）
• 平台工程师
• 基础设施工程师
• 这些角色能够赋能和指导团队，但它们并不能取代文化转型。

“你可以聘请一名 DevOps 工程师，但如果没有文化上的改变，你只是增加了一个新的信息孤岛。”

5. 有趣的统计数据

• 高效DevOps团队的部署频率高出973倍，恢复速度快6570倍。（来源：高效DevOps）
• 83%的开发者表示DevOps提高了工作满意度。（来源：开发者）
• 拥有强大 DevOps 文化的公司，其客户满意度得分是其他公司的两倍。（来源：客户满意度）
• DevOps实践可将变更失败率降低3倍。来源：变更失败率

6. 现实世界的影响

传统团队模式：
开发人员完成一个功能后，将其移交给运维团队，然后继续进行下一个项目。如果出现问题，开发团队会说：“在我机器上运行正常。”运维团队只能仓促地在不了解情况的情况下进行修复。紧张气氛不断升级，互相指责也随之而来。

DevOps 文化团队的
开发人员和运维人员从一开始就紧密合作。部署脚本、监控和回滚计划都包含在拉取请求中。当出现问题时，开发人员和运维人员会共同排查故障。他们不断学习、适应和改进。
例如：Netflix
Netflix 通过以下方式体现了 DevOps 文化：

• 由开发团队提供全方位服务
• 利用混沌工程测试系统弹性
• 强大的反馈循环和实时可观测性使他们能够每天部署数千次而不会影响用户体验。

“DevOps 成功的关键在于让每个人都对质量、性能和交付负责，而不仅仅是某个人或团队。”

8. 常见问题解答

问：小型团队可以采用 DevOps 文化吗？
答：当然可以。事实上，由于部门壁垒更少、沟通更直接，小型团队往往能更快地采纳 DevOps 原则。

问：DevOps 和敏捷开发一样吗？
答：不一样，但它们是互补的。敏捷开发侧重于迭代开发；DevOps 将这种理念扩展到交付和运维阶段。

问：我需要DevOps工程师来做DevOps吗？
答：不一定。重点应该放在文化和流程的变革上。设立专门的DevOps工程师职位可以帮助推动这种转变，但不应该独自承担全部责任。

问：如何开始构建DevOps文化？
答：从共同目标入手，自动化小型任务，引入CI/CD，并改善开发团队和运维团队之间的沟通。

9. 主要收获

• DevOps 是一种文化，而不是一个职位或部门。
• 它强调共同所有权、协作和快速反馈
• 仅仅聘请一名“DevOps工程师”是不够的——团队必须采纳新的行为方式。
• 强大的 DevOps 文化能够带来更快的发布速度、更快乐的团队和更具弹性的系统。
• 从小处着手，衡量影响，并不断发展

10. 结论

DevOps 是一种变革性的力量——但前提是它必须被理解并作为一种文化变革来实施。仅仅招聘一位头衔里带有“DevOps”字样的人才并不能神奇地解决你的交付难题。那么，什么才能真正解决问题呢？答案是：构建一种协作、持续改进和责任共担的文化。
当 DevOps 成为每个人的职责——而不仅仅是一个职位——它才能成为高效团队和世界一流软件交付的基石。

作者简介： Narendra 是AddWebSolution的 DevOps 工程师，专门从事基础设施自动化，以提高效率和可靠性。