解决新老DevOps专家之间的技能差距

如果我们要在当今市场中生存和发展，就必须将新旧合并。否则，我们将面临灭绝，因为出现了新的更好的思维方式。在本文中解释了为什么我们需要将经验与创新相结合。

我们距离DevOps运动只有几年的时间（至少以这个名字命名），人们已经开始区分旧时的DevOps专家和新手。问题在于对DevOps的误解。调查工作机会时很明显。对DevOps工程师的需求比任何其他配置文件都更高。如果不是因为没有DevOps工程师这样的事实，那对于DevOps工程师来说将是个好消息。想一想。假设sysadmin和DevOps工程师之间有什么区别？没有任何。过去负责运营或CI / CD流程和自动化的团队现在被更名为DevOps团队。一切都一样，但名称不同。好吧，那不是DevOps。

DevOps旨在弥合开发人员与运营之间的鸿沟。这是关于消除孤岛，并将这些专业组合到自给自足的团队中。这是关于改变文化。我们可以将DevOps视为敏捷实践的延续。

敏捷试图消除一些孤岛。如果我们排除那些“伪造”敏捷的团队，那么业务分析师，开发人员和测试人员现在将成为一个连贯的团队。他们都是同一个团队的成员。横向部门让位给围绕产品而不是专业的团队。敏捷试图消除由一个部门到另一个部门的交接产生的精益时间。问题在于，敏捷排除了软件开发生命周期后期的操作，系统管理员和其他专业知识。这并不是说敏捷明确地排除了它们，而是更多的是实际的实现将它们排除在外。他们没有被邀请参加聚会。

DevOps尝试通过将覆盖范围扩大到以前排除的专家来解决此问题。它包括操作员和系统管理员到自治团队中，从而使其真正自给自足。团队应该从开始（提交）到结束（部署到生产和监视）负责服务。敏捷的重命名角色（例如，项目经理成为产品所有者），而DevOps则不执行任何操作。您将继续保持自己的状态，但是您将被带入围绕某个产品形成的团队。您不再属于某个部门。您的目标与其他成员的目标没有不同。整个团队只有一个目标。以高质量，快速地将某些东西部署到生产中。

让我回到最初的问题，该问题询问了新老DevOps专家的优缺点。知道DevOps不是角色而是文化转变，所以这个问题本身是无效的。应该将其更改为新老专家的优缺点（无DevOps）。即使区别只是一句话，它还是很重要的，因为它使我们能够专注于人员专业知识，而不是错误的假设，即有人可以将品牌重命名为DevOps专家。

新鲜血液往往会给公司带来新的见解。那是除非将它们立即放入不允许他们表达自己意见的盒子中。新手，经验不足的专业人员不受其先验知识的束缚，可以开箱即用。此外，他们不知道旧的方法-他们可以适应任何工作方式。对他们的DevOps是正常的工作方式。他们不受过去的束缚。

我们中那些在相同环境中花费大量时间工作的人会变得自满。我们倾向于学习“最好的”做事方式。问题在于，没有“最佳”方法，即使存在，它也会不断变化。最佳实践的寿命往往很短，因为技术和过程的变化速度越来越快。然而，迟早，我们大多数人都会成为习惯做法的奴隶。奴隶制使我们无法采用新的更好的方法来完成工作。有能力不受约束的人通常会介绍进步。这些人通常是新手。但是，他们仍然有自己的一系列问题。

经验不足意味着我们（尚未）拥有在复杂环境中工作所需的知识。一切似乎都比实际容易。

例如：

• 误解：“可以在几周内用Go重写此应用程序。”

现实：可能不会。除非它是一个非常简单的应用程序。

• 误解：“如果我们转向微服务，我们所有的问题都会消失。”

现实：绝对不是。将您的应用程序迁移到微服务架构本身可能是一个非常重要的项目。此外，即使完成后，也永远不会消除所有问题。但希望您将拥有一个更具弹性，健壮，易于升级的应用程序。

• 误解：“ Docker将解决我们的可扩展性问题。”

现实：是的。如果使用正确，它将有所帮助。但是，如果您的环境存在资源限制，那么Docker无法解决这些问题。那么开发诉测试诉操作呢？如果所有三个团队都不接受Docker，那么一切都是白费。当然，如果团队如此孤立，那么您无论如何都不会处于DevOps环境中！

这些只是一些看起来比通常容易实现的示例。但是，这样的建议来自经验不足的专业人士也就不足为奇了。他们还没有机会真正掌握系统的复杂性。即使这是一个刚刚开始的未开发项目，经验告诉我们，随着时间的推移，它将变得更加复杂，并且需要尽早考虑到复杂性。

这是世代相传的冲突，无处不在，不仅在软件行业。经验不足的专业人员更有可能提出新想法，但缺乏成功实施这些想法的经验。更有经验的人往往会束缚自己的经验，拒绝创新。我们都需要。我们需要将经验与创新相结合。如果我们要在当今市场中生存和发展，就必须将新旧合并。否则，我们将面临灭绝，因为出现了新的更好的思维方式。无论是DevOps还是其他，我们都需要对新想法和新做事方式持开放态度。