我刚刚和一个DevOps的人交谈，他对成为一名DevOps工程师的努力提出了一些非常好的观点，即使他是由16名工程师组成的团队，有时也会感到自己像一支单兵的军队。

他戴着许多不同的帽子，但坐在开发团队中从事基础设施工作。他爱他开始工作的自动化，云计算，集装箱等与-负载凉爽高科技，但他挣扎，他做的唯一的人ops，在一个dev团队。他向开发经理报告，但与基础架构经理更紧密地合作。

我与很多DevOps专业人员交谈时就是这种情况。可以采取什么措施来帮助DevOps工程师减轻自己的孤独感？

我的第一个想法是“为什么他是开发团队中唯一从事运维的人，尤其是当他开始从事自动化工作时？”​​。我认为这里有解决孤独狼综合症的机会。尤其是在开发环境中，“基础结构即代码”为共享负载提供了一个很好的框架。Ops人员应该是确定和定义应用程序基础结构需求的专家，但他们也应该能够构建一个平台，使开发人员角色能够独立完成尽可能多的工作。

听起来像是一个团队中的孤岛。旧习难改。编码人员可能不愿意松开并加固服务器，但是在纯devops模型中，他们应该拥有这样做的工具。devops团队中的ops人员不应该负责为应用程序本身提供基础结构，但是他们应该提供对所需内容的一些见解，以及有关应用程序开发人员如何自行实现的指南。它几乎是一个元基础架构模型；ops工程师构建的基础架构可以根据开发团队的要求按需构建基础架构。

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

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

他向开发经理报告，但与基础架构经理更紧密地合作。

DevOps是旨在消除孤岛的文化转变。如果仍然存在孤岛，那么您想说的就是这位工程师。从事运营开发的工程师，自动化专家，自动化基础架构的开发人员-但该工程师不是DevOps工程师。
实际上，“ DevOps工程师”并不是真正的角色，它更像是一个“起头”，因为它可以包含在一个共同团队中工作的开发人员，系统管理员，QA测试人员和架构师。

我经常看到的一个问题是，人们将DevOps视为流行术语，将其视为职务，但他们并不真正了解DevOps是什么。通过以这种方式查看DevOps，他们常常最终变得孤立无援，感到孤独，将失败和缺点归咎于没有管理和组织支持的“孤单狼”。

正如您所描述的那样，该工程师是开发团队中唯一从事操作的工程师。那并没有使他成为“ DevOps工程师”。（这在他的组织中意味着什么）他之所以孤立工作，是因为该工作以“ DevOps工程师”的身份出现，但是他的团队中的其他人似乎并不希望从事该工作。

坦白地说，总会有操作和开发人员，devops背后的主要思想是分担责任，这样就不会将产品从开发人员转移到操作人员，也不会仅由操作人员为开发人员提供平台。主要目标是为团队带来更多的协作。称此角色为“ DevOps工程师”是通过建议您以相同的专业知识水平做到这两者的目的来打破这个想法的，这很少是真的。

我认为要做的第一件事是向团队介绍操作工具，并向每个人提供有关工具的基本知识，然后将配置/编码操作工具的职责转移给整个团队。其背后的主要思想是从“完成所有操作的人”过渡到“支持并为团队提供参考实现的人”。

通过提供比管理重组更简单的第一步可操作的方法，这可以补充其他答案。

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

获得管理承诺

一旦到位，对于这样的DevOps工程师来说，事情变得容易了。尤其是当（来自各方面的）抵抗出现在游戏中时。相信我，会有这样的抵抗，这些挑战包括：

• 为什么我们必须改变？我想继续做X年了！
• 我不想失去我所拥有的（技术）能力，并完成各种工作流程程序，以愚蠢地解决生产问题，这将使我花费5分钟而不是5个小时（或几天……）。
• ...（我可以在这里再添加十二发子弹...）。

每当遇到这些挑战时，所有DevOps工程师都必须说的是：

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

获取所需预算

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

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

1.自动化的好处

由于只有2（!!!）位计算机操作员的罢工（他们不再键入他们期望输入的控制台命令），因此不得不在2个工厂之间的一半位置暂停火车（因为工厂使用的系统火车要驶向的位置下降，因此无法获得有关处理火车的重要数据）。

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

2.降低软件许可成本

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

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

3.降低运营成本

一些主要的保险公司正在使用一些FTP软件将软件修补程序转移到全国大约13.000台中型计算机（AS / 400s），并且只要有“ a”修补程序就可以使用。一次这样的转移的成本约为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秒钟使他们损失了1.000.000美元。

这很可能也是为什么这样的公司在很长一段时间内已经使用完善的DevOps工具的原因，这已经有几十年了。因为每一秒钟他们都不在生意上，所以要花掉他们一大笔钱。

TL; DR：由于高层管理人员通常是善变的，容易发怒，所以我建议尝试一点点弯腰以获取不同的观点，同时逐步使事情变得更好。

（我假设他的麻烦主要是与那些勉强的开发者有关，而不是他的其他主要从事经典操作的操作同事。）

IMO，即使您正在使用DevOps，也不一定意味着每个开发人员都必须是成熟的DevOps专家。我发现在给定的一群人中只有一两个真正的专家，而其余的或多或少会很正常，这是很正常的。只要那个人的工作量不太大，并且只要他设法将自己的知识封装在脚本等中，而不是自己构建筒仓，对我来说就很好。

一件不应该发生的事情是，DevOps的家伙在做他的自动化，而其他人则尽最大的努力避免所说的自动化（即，越过CI / CD管道并在其中一种环境中手动完成工作）。对此，IMO是必须停止的主要工作。解决该问题的一种方法是非常努力地采用“非宠物”方法，即尽快不停地拆卸左右虚拟机或容器，并不断旋转新的容器。

其次，当然，每个人都需要知道自动化的工作，至少在理论上，也许经过一些挖掘，才能够启动自动化机制（即，如果一切都从提交/推送开始，那么开发人员需要了解并非常及时地了解，当他们提交时，后台会发生一些事情。CI（/ CD）管道必须非常明显，并且应该是每个人都经常意识到的事情（即，当开发人员中断它时）。

第三，“一个人”当然必须注意，他不会为同事做繁琐的日常任务（例如，在Dockerfile之后为他们的工件创建Dockerfile ...）。

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

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

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

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

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

但是您的DevOps同事抱怨的是，使DevOps充满挑战和困难的本质，尤其是当被任命为DevOps工程师时，而不仅仅是成为一种文化观念。

就我个人而言，我喜欢成为孤独的狼，因为我仍然可以做出宝贵的贡献，而且可以设定自己的极限，同时说服他人自助，从而帮助我打破IT孤岛。

一些筒仓保持完好无损，这是可以的，DevOps的任务就是要解决此问题，并尝试使筒仓尽可能微不足道或不可见。

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

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

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

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

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

从一开始就让他参与高级架构，以便他可以介绍他的专业知识。（在拥有DevOps之前，我们的架构图总是掩盖诸如负载平衡器和冗余服务器之类的“小东西”。现在，这些东西已经成为最初的草图的一部分。）

期望开发人员承担一些日常的Ops任务，既可以在团队中建立冗余，又可以公平地分配“繁琐的”工作。

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

可以采取什么措施来帮助DevOps工程师减轻自己的孤独感？

套用- 有什么可以一个DevOps的工程师做自己 / 她自己感觉不那么像一个孤独的狼？

缺乏文化和管理支持只是其中的一部分。在我看来，另一部分是，详细的DevOps知识通常是指复杂的上下文，因此对工作示例提供建议和参考很重要。

因此-不要觉得自己像孤独的狼；参加像这样的DevOps社区或工具特定的小组和GitHub-感觉至少不是唯一的孤独狼;-)