我正在尝试评估从devops风格的工作流程转移到传统的dev-then-ops（不确定该怎么称呼）是否一个好主意。

一个小型的5人部门，藏在4000名员工的传统媒体（例如非软件）公司中。两年前，我们开始构建软件，以使我们的部门能够显着扩大生产规模。我们已经取得了相当大的成功，更大的公司开始注意到这一点。迄今为止，我们已全权负责已成为约10个服务的AWS微服务平台的设计，开发和部署。我们的团队不会将其识别为DevOps，但毫无疑问，我们正在生活在DevOps的生活中，每个开发人员都非常熟悉代码及其运行的系统。

我们将面临的问题之一不久，我们与母公司的IT部门就可以共享什么“效率”。与内部学习相比，我们的项目所有者通常更喜欢外包，因此在我们的案例中，这些效率可能意味着尽可能多地“脱离我们的工作”进行IT工作。目前，我想说我们的团队在编码经验和基础架构经验之间有70/30％的比例。 IT部门扎根于IT领域，没有明显的软件开发交叉。

我们的项目所有者（非技术人员）希望通过将尽可能多的工作交给IT来完成团队，我们每减少一小时的运营工作，就会将生产率提高1：1左右。我对此表示怀疑。我们的产品仍处于测试阶段（尽管已经是一项重要的业务资产），并且由于我们在IT部门的有限经验，通常会发生诸如文件系统权限更改之类的简单事情的严重延误。

目前，我理想的解决方案是让IT部门“采用”我们并允许我们继续部署自己的工作，同时确保我们满足IT部门的标准和要求。我不确定那有多现实。另外，这几乎是我们项目所有者提倡的相反方法，因为它会在短期内增加其他操作工作。

在我们的情况下，与DevOps方法和处理方式保持一致可能有哪些利弊关闭IT？

评论

我认为您已经对后果有正确的认识，这与个人和公司密切相关。可以确定的是，工作负载不会按1：1的比例进行传输，每传输一小时的运维，您就有一部分可以帮助运维团队进行调试和处理延迟...（这并不是真正的答案，因此，仅将其作为评论）

#1 楼

这不是一个好主意。

根据我的经验，您会同时遇到这两种缺点，而任何预计的优点都将无法实现。

分项：


您会失去速度。
IT会遵守自己的标准。 （对于他们而言）新任务将遵循他们现在所有工作中相同的“缓慢”模板。要做好准备，他们会发现它具有挑战性-速度甚至比标准的简单操作还要慢。
您将无法卸载。
每个异常都会使IT依靠你们。您将努力使一个人快上一步-接下来您将要重复自己的事情，因为以下任务/问题/天又会有一个新人。
将需要文档，但这样做无济于事。
模板的行为再次是，简短的手册将无法捕获所有异常情况，并且太长的文字也不会被阅读。因此，这里的任何投资都将是损失，同样，实施改进以使您的工具达到“收缩包装”的质量也需要付出巨大的努力。

最后但并非最不重要的一点是，所有问题都会反映在你们身上。 Tar，tarbrush原理。

如果上面的说法听起来很愤世嫉俗，那恐怕我去过那里。反复。

该怎么办？

去IT部门购物，找到一个有用的候选人，并让这个人“借调”以减轻工作量。

#2 楼

您可以在DevOps调查的结果中找到许多答案，应要求产品负责人阅读。这是一个专门为商务人士编写的文档，这些商务人士几乎不懂技术术语，只是用他应该理解的术语进行交谈。

平均而言，每4个人将需要一名额外的开发人员来保持相同水平的功能开发（38 ％与49％的时间花费在新工作上。
您从故障中恢复的平均时间将减少25倍。您的工作将减少20％的乐趣，而您推荐给朋友的工作的可能性将降低40％。仅这三个事实就足够了。

#3 楼

融入IT组织将使您失去的是DevOps小团队的“ Dev”部分。当团队被划分为NetOps，SysOps和Dev的人为角色时，您会遇到以下问题：



不必要的繁文tape节和隔离-开发人员要做的任何事情必须向IT部门提交票证并等待他们实施。他们将不再能够自己实现并与之交互-直到并包括其Dev和QA实例，这将限制他们可以编程的基础架构。它们被卡在虚拟机壁垒上，而不是能够在整个堆栈上进行编码。如果他们提交给IT部门的内容看起来像DevOps代码，那么他们将没有足够的能力来处理它，并且可能会恢复为手动部署。

忽略-另外，他们可能只是按原样部署它，然后忽略野兽，因为他们不知道如何与之互动-而且他们不是开发人员，所以代码不是他们的问题。

中断-DevOps经常被忽视的好处之一是它的程序性。当然，通过将服务器视为代码来部署该服务器可能需要更长的时间，但这可以自动消除人为错误。它进入开发人员的方式就是他们进入质量检查/测试的方式就是进入产品的方式，从而减少了停机。当开发人员无法访问网络设备时，他们需要部署服务或计算基础结构，不仅需要花费更长的时间，而且还引入了容易出错的人员，这将导致更多的中断。

文档-在某种意义上，DevOps代码是自我记录的。您知道服务器的构建和部署方式，因为代码告诉您。在5年内，当需要升级到CentOS 8或任何其他版本时，再也没人会知道如何部署您的应用程序了-包括在网络，存储，监视和备份层。

简而言之，您应该建议您的项目所有者花些时间阅读《神话般的月》，以免他或她认为您将看到生产率与1：1的关系，而凤凰计划则是一个很好的创新（和娱乐性）说明非技术人员使用非技术语言开发DevOps会获得和失去的东西。如果项目所有者有任何通勤方式，可以使用The Phoenix Project的有声读物。

#4 楼

我建议您采用一些IT团队，并为他们提供有关新系统的全面培训。

一旦他们完全了解该系统，便可以将其卸载给他们。

否则，您将成为IT支持中心-在他们学习新系统的复杂性时花大量时间进行消防工作。