DevOps 的根本在于改变 IT 组织的文化吗？
这个看似简单的问题有时会引发激烈的争论，尽管如果深入细节，会发现这更多是关于如何看待转型，而不是关于最终状态的争论。
退后一步——你可以将 DevOps 视为介于两个极端之间。
一个极端是各种“devops-y”工具：Jenkins、Chef、Puppet、Ansible、Salt、New Relic 等等。这些工具涵盖了从持续构建到配置管理到应用程序性能管理等广泛领域（这只是一个随意的抽样）。它们吸引了不同的受众，我们可以就单个工具与持续改进等 DevOps 理念的契合程度进行长时间的讨论。无论如何，如果你站在这个极端，你就会认为 DevOps 就是购买合适的软件（或者至少你想让你的客户相信这一点）。
另一个极端是，DevOps 完全是关于彻底的文化转型。例如，Parker Yates 在这篇文章中认为，“DevOps 具有太多的文化内涵，无法在很长一段时间内转变信徒；DevOps 需要重组，而不是细微的转变。”
为了避免被指责为树立稻草人，这种思想流派通常承认实施某些流程和运营实践的可取性，但它仍然通过组织的文化来看待 DevOps。鉴于这种设定，我可能认为 DevOps 兼具工具和文化两个方面，这可能是显而易见的。但我希望以稍微不同的方式来构建事物。
对于这种替代框架，值得思考制造业（DevOps 的类比经常由此而来）是如何随着时间推移而演变的：标准化零件——通常可以追溯到 1765 年用于大炮的 Système Gribeauval 系统。Brunel 和 Maudlay 应用于帆船滑轮以在 19 世纪初实现生产标准化的工艺和机械。汽车制造业的许多创新，包括高度自动化的装配线、可重复使用的汽车平台、精益生产以及“丰田之道”等系统方法。
这些事物中的许多都可以被认为是文化转变：从手工艺到工厂，从临时观察到统计质量控制，缩短周期时间以及装配工人的赋权。基本上在所有情况下，它们都代表了与往常业务的果断和深思熟虑的转变。但是，我基本上同意 JP Morgenthal 在他认为“当 DevOps 采用完成时，对于文化的外观没有单一的公认标准”时的观点。他补充说，“每个企业的挑战都不同，驱动这些挑战的行为也不同。”
在讨论企业 DevOps 所需的顶级技能时，Andi Mann 指出
“对 DevOps 的讨论几乎立即集中在文化上——例如对同事的同理心、灵活和适应性强、寻求持续改进、建立关系等等。然而，虽然文化在 DevOps 中至关重要，但文化是一种结果，而不是一种输入；而且这些属性大多是天生的或缓慢获得的。文化不容易被教会。”
在最近于硅谷举行的 CloudExpo 上，JP、Andi 和我就墨西哥食物讨论了这个问题，我非常同意。如果我们使用“文化”作为导致文化的众多因素的简写，那么我们“只是”不精确。但这不仅仅是一个语义上的吹毛求疵，因为它会分散我们对可操作步骤的关注，例如创建正确的组织结构、正确地调整激励机制，以及——是的——实施适当的工具。
我看到了开源方法与此有很多共同之处，并且稍微有点情感地说，开源生活方式可以帮助公司走上 DevOps 采用之路。开源正日益成为软件技术开发的默认方式。从云计算到大数据再到移动，开源无处不在。如果没有个人和组织学习如何更有效地使用开源来创建软件，这种演变就不会发生。开源不仅仅是开放你的代码——它也是一种非常特殊的开发和协作方式。
DevOps 从根本上来说是采用许多相同的开源最佳实践。敏捷。透明。协作。迭代快速发布。持续集成。这些结合在一起，随着时间的推移，创造了一种开源的生活方式和文化。它们同样可以结合在一起，使 DevOps 蓬勃发展。
这需要愿景和管理层的强力支持，但这并不是要从高层强加一种千篇一律的文化。而是要发展组织的许多方面，从而创造一种适合该组织并使其更有效的文化——无论是关于 DevOps 还是其他活动。 这也关系到拥有正确的价值观和激励机制，以创建一个有效的 DevOps 社区，该社区重视开放交流、系统思考和广泛参与。
1 条评论