终止DevOps工作流程的利弊？

我正在尝试评估从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. 您将失去速度。
   IT将遵守自己的标准。（对于他们而言）新任务将遵循他们现在所有工作所具有的相同的“缓慢”模板。要做好准备，他们会发现它具有挑战性-因此速度比标准的简单动作还要慢。
2. 您将无法卸载。
   每个异常都会使IT依靠你们。您将尽全力使一个人变得更快-接下来您将要重复自己的下一件事，因为接下来的任务/问题/天将有一个新人。
3. 需要提供文档，但无济于事。
   同样，模板的行为将是，简短的手册将无法捕获所有异常，并且太长的时间不会阅读详尽的文本。因此，这里的任何投资都将是一项损失，同样，为实现工具的“收缩包装”质量而进行的改进也需要付出巨大的努力。

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

如果以上听起来令人愤世嫉俗，那恐怕我去过那里。反复。

该怎么做呢？

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

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

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

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

1. 不需要的繁文and节和隔离 -做任何事情，开发人员都必须向IT提交票证并等待他们实施。他们将不再能够自己实现和与之交互-直到并包括他们的Dev和QA实例，这将限制他们可以编程的基础架构。它们被卡在虚拟机壁垒上，而不是能够在整个堆栈上进行编码。如果他们提交给IT部门的内容看起来像DevOps代码，那么他们将无能力处理该代码，并且可能会恢复为手动部署。
2. 忽视 -或者，他们可能只是按原样部署它，然后忽略野兽，因为他们不知道如何与之交互-他们不是开发人员，所以代码不是他们的问题。
3. 中断-DevOps经常被忽视的好处之一是它的程序性。当然，通过将其视为代码来部署服务器可能会花费更长的时间，但这可以自动消除人为错误。进入开发人员的方式就是进入质量检查/测试的方式就是进入产品的方式，从而减少了停机。当开发人员无法访问网络设备时，他们需要部署服务或计算基础架构，不仅需要花费更长的时间，而且还会引入更多易犯错误的人员，这将导致更多的中断。
4. 文档 -从某种意义上讲，DevOps代码是自我记录的。您知道服务器的构建和部署方式，因为代码告诉您。在5年内，当需要升级到CentOS 8或任何其他版本时，没有人会再知道如何部署您的应用程序-包括在网络，存储，监视和备份层。

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

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

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

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