有缺陷的DevOps

当您的DevOps实现有缺陷时，您该怎么办？绕圈跑，尖叫和叫喊？

DevOps很难实现。无论团队多么努力，这都不是一夜之间就能发生的事情。它需要合规、协作和愿意尝试新事物。没有一种方法可以在整个团队中实施DevOps。据我所知，不同公司的很多团队都有不同的做法。然而，虽然有不同的实践，但这些团队执行相同的核心原则，这些原则基本上相当于多个团队一起工作，在快速测试和部署的同时相互支持。[1]。

不幸的是，实施DevOps时最大的问题之一(以我的经验，但大多数人都会同意)是文化转变。这就是DevOps的困难所在。不是工具的问题，而是人的问题。你可以更换工具，让它们发挥作用，这是最容易的部分。但是你不能改变别人，你只能说服他们。

造成这种情况的原因当然要视情况而定。这可能是因为领导层缺乏知识，他们可能仅仅因为不了解这条新道路而不愿意走这条路。因此，他们可能会感到受到威胁。另一个原因可能是不想改变。因为谁想要或需要改变呢？事情一直很好，我们从来不需要这样，因为一切都运行得很好。这完全有道理，因为在科技领域，事情进展缓慢，没有进步这回事。[2]。

当然，您可能会花时间在内部发布多个演示文稿，对您的团队甚至技术主管进行一对一的培训，以将冲突降至最低，并在要求更改时对情况进行社会工程以影响他们。然而，无论你怎么努力，结果都是不完美的。你现在的处境比开始时好多了。但这不是你需要去的地方。因为您的DevOps实现是半途而废的。是谁把前面的紫色栅栏重新漆成红色，而把后面漆成紫色的？

那你是做什么的？当然，你不想要战争。你的工作不是当兵，你知道你应该远离政治。在这种情况下，最好尽量减少冲突。因为你明白，如果没有领导力，这种过渡是行不通的。

问题似乎是沟通。您如何联系到您的领导？当然，演示文稿并不奏效。还有别的事吗？你变得多疑了。你需要把音量调低一点。你太热情了。别这么激动，否则你会失望的。

等着瞧。让它发生吧，最终当事情失败时，你会有很多例子来说明为什么当前的流程不够好，这就是为什么你必须全力以赴的原因。

不幸的是，这不仅是迫使DevOps；而且做你开始做的事情所需要的。然而，一旦你行使了所有的选择，这是唯一的选择，因为一旦你行使了所有的选择，培养领导者就不起作用了。这是持续改进的一部分。我个人认为，在这样的情况下，让事情失败是很重要的。原因是您有一个示例可供参考，例如，……这就是我们应该标记COMMITS的原因。因此，我们可以跟踪不同环境之间的变化，例如。

将DevOps实践引入新团队时，重要的是要了解这需要时间。因此，你必须降低你的期望值。你也不应该抗拒。如果你被聘为DevOps工程师，那是因为你的团队或组织需要它。无论领导层或开发人员是否立即接受它，如果有任何问题，他们都会被曝光。所以你必须屈服，忍受抵抗。

失败比教育更能克服变革的阻力，因为在某种程度上，失败本身就是一种学习工具。你召开了会议，介绍了为什么要实现开发运营需要做出改变。虽然这没有奏效，但你任由事情失败。从错误中学习是我们从小就开始学习并继续学习的东西。它让我们成为更好的人类。诸如此类的事件与同样的理念息息相关。这是这一过程的一部分。这不仅是领导力的学习经历，也是开发运营工程师的学习经历。

如果事情出了差错，你可能也会觉得有责任，或者因为事情出了差错而受到指责，这没什么。责怪文化是剧毒的。它没有生产力，而且造成了一个不舒服的工作环境。然而，这也是整个过程的一部分，因此你必须在如何回应时保持坚忍。最终，这些失败将成为他们自己的例子，你将能够收拾残局。

在这篇文章的开头，我提到了DevOps在不同的组织中是如何不同地实现的。然而，重要的是要注意，无论如何，如果团队选择没有开发环境，仍然有一些事情必须独立于需要遵循的工具来实现，否则您将失败。

轻柔地对待这件事。如果领导层拒绝遵循原则，或者为没有足够的时间实践DevOps的原则而找懒惰的借口，重要的是要有一种这样的态度。让一切顺其自然，因为最终一切都会崩溃。因为DevOps实践不是你可以精心挑选并期望奏效的东西。你必须一路走下去。

我会借此机会澄清一下。虽然这不是关于什么是DevOps的帖子，但我不想误导，所以我会明确声明DevOps的目的不仅仅是推送代码，而是改善流程。↩︎