如何帮助DevOps工程师减少孤独感？

#1 楼

我的第一个想法是“为什么他是开发团队中唯一从事操作的人，尤其是当他开始处理自动化工作时？”​​。我认为这里有解决孤独狼综合症的机会。尤其是在开发环境中，“基础结构即代码”为共享负载提供了一个很好的框架。 Ops人员应该是确定和定义应用程序基础结构需求的专家，但他们也应该能够构建一个平台，使开发人员角色能够独立完成各自的工作。一个团队;旧习难改。编码人员可能不愿意松开并加固服务器，但是在纯devops模型中，他们应该拥有这样做的工具。 devops团队中的ops人员不应该负责为应用程序本身提供基础结构，但是他们应该提供对所需内容的一些了解，以及有关应用程序开发人员如何自己实现的指南。它几乎是一个元基础架构模型； ops工程师构建的基础结构可以根据开发团队的要求按需构建基础结构。

咨询，沟通和责任分担对于devops团队的成功至关重要。

#2 楼

我认为第一个缺陷是这句话：


他向开发经理报告，但与
基础架构经理更紧密地合作。
DevOps是一种文化变革，旨在消除孤岛。如果仍然存在孤岛，那么您想说的就是这位工程师。进行操作开发的工程师，自动化专家，自动化基础架构的开发人员-但是这位工程师不是DevOps工程师。
实际上，“ DevOps工程师”并不是真正的角色，它更像是一个“起头”。包括在一个共同团队中工作的开发人员，系统管理员，质量检查测试人员和架构师。真的不了解什么是DevOps。通过以这种方式查看DevOps，他们通常最终会变得孤立无援，感到孤独，将失败和缺点归咎于没有管理和组织支持的“孤单狼”。开发团队中只有一名操作员。那并不能使他成为“ DevOps工程师”。 （这在他的组织中意味着什么）他之所以孤立工作，是因为该工作被称为“ DevOps工程师”，但他的团队中的其他人似乎都不希望从事运营工作。

老实说，总会有操作和开发人员，devops背后的主要思想是分担责任，这样就不会将产品从开发人员转移到操作人员，也不会仅由操作人员为开发人员提供平台。主要目标是为团队带来更多协作。称此角色为“ DevOps工程师”是通过建议您以可以同时具有相同专业知识水平的名义建议这两个想法的方法，这是不合法的。我认为要做的第一件事是向团队介绍操作工具，并向每个人提供有关工具的基本知识，然后将配置/编码操作工具的责任转移给整个团队。其背后的主要思想是从“做所有操作的人”过渡到“支持并为团队提供参考实现的人”。比管理层重组更简单的第一步。

#3 楼

在这种情况下，对于DevOps工程师而言，最重要的事情是获得（a）管理承诺和（b）所需预算。继续阅读以获取有关这两个方面的更多详细信息。

获得管理承诺

一旦到位，对于此类DevOps工程师而言，事情变得容易了。尤其是当（来自各方面的）抵抗出现在游戏中时。相信我，会有这样的阻力，例如：


为什么我们必须改变？我想继续做我X年以来的工作！例如5分钟而不是5个小时（或几天）。
...（我可以在这里再添加十几发子弹...）。 DevOps工程师应该说的是：


很抱歉，我只是在做我的工作...根据高层的指示。


获取必需的预算

获取必需预算的有效方法是创建/提交适当的业务案例，该案例通过将各种DevOps做法应用于某些案例来解释其有形和无形的收益适用于公司本身的真实案例。

下面是我经历的一些实际案例，我是一些发生这种情况的公司聘请的SCM顾问。我知道，SCM只是DevOps的一部分，但这是我所擅长的领域...

1。自动化的好处

由于只有2（!!!）名计算机操作员（他们不再键入控制台命令，因为他们希望键入这些命令）会引起罢工，因此必须将火车停在一半的位置在两个工厂之间的距离（由于火车前往的工厂的系统故障，无法获得有关火车的重要数据）。

通过实施SCM系统，许多操作员命令得以自动化。

2。降低软件许可成本

一些软件供应商已决定增加（过时的）SCM软件的年费，但管理层不同意。为此，他们创建了一个特殊的项目，使它被某些替代的SCM软件取代。

该项目的预算等于他们不想继续支付的年费。其中包括来自其他大陆（如我）的工程师的飞行，以使该项目成功。

3。降低运营成本

一些主要的保险公司正在使用一些FTP软件将软件修补程序传输到全国大约13.000台中型计算机（AS / 400s），并且只要有“ a”修订版就可以使用。 1次这样的转移的成本约为4美元（单次转移... 13.000 x 4 = 52.000美元）。该软件包含120.000个组件，由大约150个开发人员开发/维护。算一下，有1个开发人员在这120.000个组件中的任何一个中犯了1个（微小）错误的可能性，这使它投入生产并需要紧急修复，这将花费另外的52.000美元（仅用于转让！）。 />
通过实施适当的SCM系统（具有托管的测试环境，批准等），该公司实现了成本的大幅降低。仔细考虑一下，如果SCM系统可以避免仅20次紧急修复的需求，那么成本降低了52.000 x 20 = 1.040.000 USD（相当一部分预算来实施SCM系统，他们只需要一小部分来完成工作）。

4。减少不可用的成本

如果上述情况不足以令人信服，请考虑一下主要信用卡公司的系统在世界范围内不可用。有人告诉我，一秒钟的不可用性使他们损失了1.000.000美元。

这很可能也是为什么这样的公司在很长一段时间内已经使用完善的DevOps工具的原因，这已经有几十年了。因为它们每秒钟都不从事业务，因此要付出巨额财富。

#4 楼

TL; DR：由于高层管理人员通常是善变的，容易发怒，所以我建议尝试改变主意以获得不同的观点，同时逐步使事情变得更好。我以为他的麻烦主要是因为勉强的开发人员，而不是其他似乎主要从事经典操作的操作人员同事。每个开发人员都必须是成熟的DevOps专家。我发现在给定的一群人中只有一两个真正的专家，而其余的人或多或少会很正常，这是很正常的。只要那个人的工作量不太大，并且只要他设法将自己的知识封装在脚本等中，而不是自己构建筒仓，对我来说就很好。不应该发生的事情是DevOps的家伙在做他的自动化，而其他所有人都尽最大的努力避免所说的自动化（即，通过CI / CD管道并在其中一种环境中手动进行操作）。对此，IMO是必须停止的主要工作。解决该问题的一种方法是非常努力地采用“非宠物”方法，即尽快不停地拆卸左右虚拟机或容器，并不断旋转新的容器。

第二，当然，每个人都需要知道自动化的工作，至少在理论上，也许经过一些挖掘，才能够启动自动化机制（即，如果一切都从提交/推送中运行，那么开发人员需要请注意并非常及时地了解，当他们提交时，后台会发生一些事情。 CI（/ CD）管道必须非常明显，并且应该是每个人都不断意识到的东西（例如，当开发人员将其破坏时）。请注意，他不会为同事执行繁琐的日常任务（例如，在Dockerfile之后为他们的工件创建Dockerfile ...）。

第四，开发运维人员创建的解决方案当然必须以某种可衡量的方式实际上优于过去的手动方法。在这种情况下，他应该有可能证明自己的进步；例如，演示如何使每个人都变得更容易，或者在管道的后期阶段似乎不可能引入错误，等等。如果这似乎不可能，那么DevOps家伙需要认真思考一下他在做。如果可能的话，这需要参加棕色袋会议并在他的团队中进行大量的宣教。

很显然，在这种勉强的环境中，您可能不会很快就获得全自动CD解决方案或基于主干的开发。但是我不会太担心被选中。他是专家，并且如果他做得很好，整个团队将会非常逐步地进步。

最后，如果经过多年的辛劳，他的同事们没有明显的进步，那么总有可能寻找其他途径（无论在公司内部还是外部）。如今，拥有所有DevOps经验是寻找工作的绝佳基础...

#5 楼

我在这里看到许多很好的答案，它们在谈论DevOps作为一种文化，有关如何与管理人员合作的建议，并帮助定义DevOps团队或工程师的“有为有”。我认为他们每个人都很棒，真的可以很好地说明许多答案，而且彼此之间仍然有很大不同，甚至完全不明确... DevOps！

这个答案这只是我从经验中得出的独特观点，可能并不代表规范或最佳实践...

但是您的DevOps同事抱怨的是，本质上是使DevOps充满挑战和困难的原因，特别是当被任命为DevOps工程师时，不仅要成为一种文化思维。说服其他人自助，从而帮助我解决IT孤岛。 。

您的同事可能意识到或尚未意识到e或她不喜欢成为DevOps工程师。

#6 楼

相对而言，devops的概念是新的，在我看来仍在定义自己。我目前担任devops工程师。对我来说，这意味着我可以促进和开发我们的开发和运营团队所使用的工具和流程，从而使他们可以专注于为公司创造收入的产品。运维团队和开发团队根据需要启动自己的服务器。我只是为我们的产品添加了CI，确保我们的流程有意义，并找出可以改进/自动化的流程。我会见我们所有部门，从销售到仓库，再到开发人员和操作人员（质量保证和发布经理），以了解他们的工作以及如何改进他们的流程。

#7 楼

对我而言，DevOps意味着软件系统的开发和运营将由一个团队负责，而不是由单独的开发和运营团队负责。这是一条双向路。最好的团队由“ T形”人员组成，他们是一个领域的专家，并且熟悉多个相关领域。


具有Ops经验的团队成员应做的最好（即Ops），向其他人讲授他们最擅长的基础（即Ops），并学习和从事相关领域的工作（即Dev任务）。
具有开发经验的团队成员应尽其所能（即开发），向其他人教授其最擅长（即开发）的基础知识，并学习和从事相关领域的工作（即Ops任务）。

因此，为了使DevOps工程师不再像孤单的狼，请他教开发人员如何运行系统，同时承认他是设计基础架构的专家。

从一开始就让他参与高级建筑，以便他可以介绍他的专业知识。 （在开发DevOps之前，我们的体系结构图总是掩盖诸如负载平衡器和冗余服务器之类的“小东西”。现在，这些东西是最初草图的一部分。）日常的Ops任务，既可以在团队中建立冗余，又可以公平地分配“繁琐的”工作。

如果没有像Ops这样的任务要完成，请期待他为开发工作做出贡献。我知道有些DevOps似乎发现数据库工作是其专业领域的自然延伸，不确定是否可以推广。

#8 楼

可以做些什么来帮助DevOps工程师减轻自己的孤独感？像孤独的狼一样？

缺乏文化和管理支持只是其中的一部分。在我看来，另一部分是，详细的DevOps知识通常是指复杂的上下文，因此对工作示例提供建议和参考非常重要。参加像这样的DevOps社区或工具特定的小组以及GitHub-感觉至少不是唯一的孤独者;-)