我公司的一个组织部门正在为一个相对较大的客户提供应用程序支持；也就是说，他们使某些业务应用程序保持24x7全天候运行，无论是从root帐户向上执行任何操作（无硬件/网络）。诸如保持卷，RAM，CPU充足，将故障单路由到需要的地方，备份和恢复之类的东西。所有应用程序（许多）都处于相当稳定的状态，几乎没有开发。
它是100％经典的，即100％的运维。偶尔与开发人员接触时会遇到常见的问题（不信任，偏见等）。
客户认为它要变得现代，并且正在引入“ DevOps”-没有清楚了解其实际含义。他们只是知道他们不想拥有一个运行大型服务器集群的大型实体，并不真正了解软件的深入知识，而是各个团队应该构建并支持自己的应用程序。请注意，没有容器技术或类似的技术-他们正在进入OpenShift，但是步伐缓慢。一切都很经典...麻烦票证系统，多层支持级别，定期解决很多票证，但它们本身都很容易（例如，卷满时等），偶尔也需要开发人员输入困难的问题。
因此，我隶属于我们的一个工作组，负责提出构想。我有很多咨询开发团队的经验，可以使开发团队更加“ DevOps”，即更多的自动化，更多的工具，保持开发/测试/产品环境相同的东西。从他们的角度来看，很清楚如何进行。但是在我当前的示例中，我不清楚要提出什么建议。他们确实有问题，但更多的是“操作”方面的问题（例如找到足够的优秀员工来进行24x7的轮班工作等等）。似乎并没有真正要解决的“ Dev-Ops”问题。
问题
在仅进行少量开发的繁琐的部门中，DevOps的一些实践，文化变化，流程变化等很可能是有益的，无论如何他们到目前为止做的很容易
不太容易引起恐惧和本能的抵制（在第一次会谈之后似乎有很多情况发生）
例如，在开发团队中，我将向他们展示如何处理容器，12因子或...以及它解决了什么具体问题，这通常向他们表明没有什么可担心的，并且有真正的好处要收获。从那以后，它就达到了他们想要使用的目的。阅读资料（由于缺乏知识），在某些情况下，这将有助于解决/路由错误报告等。
主要的主观问题似乎是他们认为对开发人员真的不好。 （据他们说，那些人懒惰，挑剔，不想做24x7，只是通过“重新滚动容器”等来解决每个操作问题。）。
#1 楼
提出解决方案的关键始终是首先发现问题。如果团队觉得您没有解决任何问题，那么他们将拒绝您的建议。您的Ops团队面临的具体问题我们尚不知道，但是有一些常见的问题：获取不可操作的警报
花费大量时间进行辛苦工作
版本升级很麻烦
部署很麻烦
无法了解应用程序在做什么
等等。一旦知道了他们所遇到的问题，就可以针对解决这些问题的解决方案。
文化变革很难做到（通常最简单的方法是雇用具有您想要的哲学的人，并逐渐淘汰老年人）。但是，将运营工程师与开发人员联系在一起可以为这一工作提供巨大帮助。我曾在几家小型公司工作过，这些公司只有一个工程团队（而我碰巧主要从事运维工作），所以这个想法对我来说很自然，但是对于那些一直只与一个运营团队一起工作的人来说，与开发人员长时间接触很少，可能很难调整。但是移动办公桌与他们在一起，参加他们的聊天频道，和他们一起吃午餐-所有这些都有助于操作人员和开发人员意识到对方实际上是人类。这也为操作人员提供了更好的机会，利用他们的专业知识为那些本来不会浮出水面的开发人员解决问题（例如，他们正在尝试做某事，而您提供了一个快速的shell脚本，该脚本可以比手动方式更快地解决它）他们一起去），这建立了信任和情感预算，您可以在需要时花些钱。