F5 DevOps 和 NetOps 调查报告： 自动化是缩小数字鸿沟的关键
人们非常重视 DevOps 和 NetOps 之间的原型关系。 我们不断受到“我们对他们”的言论的攻击，这些言论挑拨我们与他人的关系，跨越分隔我们的墙壁来回抛出applications和指责。 随着更快、更频繁地交付应用程序的压力越来越大，这堵墙可能成为将应用程序经济中的赢家与其他人区分开来的数字鸿沟。
幸运的是，由于 IT 自动化和编排，这种数字鸿沟正在缩小。 当我们分别调查每个小组，深入了解他们的技术使用情况、对彼此的看法以及他们提供的applications时，我们发现 NetOps 和 DevOps 都希望合作缩小这一数字鸿沟。 对于那些需要只有自动化和编排才能有效实现的规模和速度的数字化转型的企业来说，这是一个越来越好的消息。 对于那些在多云环境中苦苦挣扎的组织来说，这也是一个好消息，因为这些组织需要已经不堪重负的员工给予更多的关注。 通过自动化减轻现场压力可以释放资源来处理与云相关的项目。
884 名 NetOps 和 DevOps 专业人士回应了 2017 年夏季进行的在线调查。 我们询问了几个与感知相关的问题，这些问题涉及一般applications以及 NetOps 或 DevOps 中的对应应用程序，以及针对部署频率和成功率的感知的问题。
结果显示，尽管他们之间的隔阂仍然存在，但它并不像社区内部对话或其他行业报告所声称的那么高或那么不透明。 我们发现，各种规模和行业的组织在生产流程自动化的重要性和愿望方面存在很多共同点，并且对两个团队努力开发和部署的applications的安全性、性能和可靠性有着共同的信心。
自动化似乎是 NetOps 和 DevOps 的统一力量。 至少在原则上是这样，但如果在具体实施细节上则不然。
尽管 DevOps 和 NetOps 对于应通过自助服务和自动化提供多少管道访问仍存在分歧，但总体而言，双方都认为对方走在正确的轨道上。 82% 的 DevOps 和 76% 的 NetOps 同意彼此优先考虑“正确的事情”。 显然，尽管在组织结构图中并不总是如此，但至少在目标和重点上，数字鸿沟是存在的。
在 NetOps 方面的反对者中，对于 DevOps 没有足够重视安全性的最常见回应。 可靠性也经常成为 NetOps 同行对 DevOps 感到失望的一个原因。
可靠性和安全性与交付速度同样重要。 安全仍是事后才考虑的事情。 性能、安全性、可靠性。
毫不奇怪，DevOps 在 NetOps 优先排序方面最常见的说法之一就是以自动化为中心。 或者更确切地说，缺乏这一点。
自动化 自动化 自动化。 我希望他们优先考虑在云空间中实现自动化、与云无关的资源创建。 自动化、devops、云、安全。
这种意见分歧很可能是我们下一个关键发现的根源，该发现揭示了开发人员和 DevOps 缺乏通过自动化和自助服务访问生产流程对采用云和 IT 以外的解决方案的影响。
自动化影响云采用
他们现在能听到你的声音了。 长期以来，人们一直认为，企业和 DevOps 利益相关者采用云的驱动因素之一是缺乏对生产部署流程的自助访问，从而导致部署周期过长。 不太好的消息是，我们的调查证实了这种看法，27% 的 DevOps 表示，它对他们采用基于云的解决方案的决策“很大”影响，38% 的表示“部分”影响。 好消息是，NetOps 并没有忽视这种影响。 超过 65% 的 NetOps 表示，他们希望实现生产流程自动化并提供自助访问，而这在一定程度上或很大程度上受到了 DevOps 拥抱云的决定的影响。
主要发现
- 对自动化的坚实支持。 人们一致认为自动化交付和部署流程非常重要，按 5 分制计算，DevOps 的重要性平均评分为 4.0，NetOps 的重要性平均评分为 3.5。 总体而言，当生产流程自动化程度超过 50% 时，受访者对applications的可靠性、性能和安全性更有信心。 两个群体也绝大多数同意对方“优先考虑了正确的事情”。
- 自动化影响云采用，反之亦然。 尽管达成了协议，但两派之间的意见分歧确实存在，并会产生后果。 其中之一就是对生产管道访问的不同看法，我们认为这导致了多云的兴起。 在 DevOps 方面，65% 的受访者表示缺乏生产管道访问影响了他们寻求云和外部解决方案的决定。 相反，几乎大多数 NetOps（44%）表示，DevOps 转向云端的决定对他们提供管道访问的愿望产生了“一定”影响，另有 21% 的人承认这对他们产生了“很大”影响。
- 管道接入方面的不和谐。 数字化转型工作专注于提供applications以提高内部效率和外部参与度，必须跨越开发和生产之间的鸿沟。 我们发现两者之间的隔阂仍然存在，对于应该向开发人员和 DevOps 开放多少生产管道访问权限存在不同的看法。 大多数 DevOps 受访者认为，超过 75% 的生产流程应该通过自助服务和自动化来实现。 NetOps 不那么慷慨，但也没有普遍的看法那么遥远。
- 当前部署频率良好。 DevOps 和 NetOps 都一致认为当前的部署频率“足够好”。 按照目前对这两组人之间分歧的看法， 与 DevOps 相比，NetOps 认为部署频率“过于频繁”的可能性是其两倍。 只有少数 (4%) DevOps 方面人士表示，他们认为存在“过于频繁”的发布。
对自动化的坚实支持
指责游戏已经结束。 与流行的说法相反，在事件发生后，NetOps 和 DevOps 陷入无休止的指责游戏，我们发现证据表明，每个群体都以更为积极的态度看待对方。
那些因缺乏管道访问而感到沮丧的人对云的使用在很大程度上导致了多云的兴起及其与安全性和性能相关的挑战，正如那些为其所造成的“流氓 IT”而苦苦挣扎的人经常指出的那样。 即使 NetOps 继续致力于通过私有云或类云系统的自动化/自助服务提供访问，但在外部云解决方案方面仍然存在大量难以忽视的投资。 这使得组织需要管理、监控和保护多种云解决方案和环境，从而增加了数字经济中运营的复杂性。
现在的问题不是“我们是否提供对生产流程的自助访问？”而是“我们暴露了多少信息？”
管道接入方面的不和谐
多少才够？ 通过自动化/自助服务功能为开发人员和 DevOps 提供适量的管道访问引起了一些显著的意见分歧。 DevOps 肯定希望获得比 NetOps 愿意提供给他们的更多的生产流程访问权限。
虽然我们并没有要求深入了解 NetOps 为何不愿意为 DevOps 提供更大的管道访问权限，但答案或许可以在可用的技能中找到。 NetOps 受访者普遍认为，他们完成工作所需的技能与他们现有培训/知识之间存在差距。
事实上，将自己视为“开发人员”的 NetOps 和 DevOps 都更有可能相信，鉴于相似的职责和技能，他们的工作在五年内将是有意义的。 最不自信的是那些自称是网络运营商的人——无论是在墙的两边。
NetOps 方面的生产流程自动化的现状似乎反映了技能差距的影响。 发现它远远落后于 DevOps 交付流程并不奇怪。 虽然 11% 的 NetOps 承认生产流程没有实现自动化，但只有 5% 的 DevOps 承认application交付流程没有实现自动化。
由于我们发现管道自动化与成功部署的频率之间存在正相关的关系，因此管道自动化的状态值得关注。 86% 的 NetOps 表示管道自动化比例更高（75% 或更高），并且报告的非常成功（90% 或更高）的部署频率也更高。
但这不是唯一因素，因为application变化的频率似乎也会对成功部署的频率产生影响。
当前部署频率良好
我们很好，谢谢。 也许最大的文化鸿沟仍然在于部署频率领域。 虽然部分 DevOps 能够以极快的速度将应用程序投入生产（12% 的应用程序每天向生产环境提交多次变更），但 NetOps 似乎更愿意以较慢但较稳定的速度部署这些变更。
总体而言，大多数受访者似乎对每月和每周的频率达成了一定程度的共识。 毫不奇怪，DevOps 比 NetOps 更喜欢频繁地交付。 也就是说，在希望更频繁交付的 26% DevOps 中，28% 每周交付一次，26% 每天交付一次以上。
不同群体对于变革实现速度是否足够的看法不尽相同。 然而值得注意的是，大多数人（70% 的 DevOps 和 74% 的 NetOps）都认为变更频率“对我们来说已经足够好了”。
共同点就到此为止了。 虽然仅有 4% 的 DevOps 人员声称他们目前的计划“太频繁”，但 NetOps 方面认为交付频率“太频繁”的人数增加了一倍。 超过四分之一（26%）的 DevOps 希望加快速度，而不到五分之一（18%）的 NetOps 希望加快步伐。
然而，忽略愿望并检查结果，就会发现什么可能是平衡速度和成功率的“理想”部署频率。 在 65% 的 NetOps 和 57% 的 DevOps 中，部署成功率超过 90%，变更每周都会投入生产一次。
结论
applications从交付到部署所必须跨越的数字鸿沟仍然存在。 部署管道的大部分内容仍由手动驱动，这将继续推动applications走向云端。 反过来，DevOps 决定转向云将使 NetOps 提供更多必要的自助服务访问，以加快这一进程。
自动化是弥合数字鸿沟的关键，因为它使 NetOps 和 DevOps 能够更智能地工作而不是更努力地工作，并扩展运营以共同满足业务需求。
方法论
本报告的数据来自 2017 年 7 月进行的两项独立的在线调查。 两者旨在调查从开发到部署的应用生命周期中自动化的使用情况，以及所涉及的两个主要群体的看法。 两组受访者均受到了参与的激励。
附录： 调查摘录
下面还包括来自 NetOps 和 DevOps 受访者的对调查问题的额外精选回答。 虽然这不是一个完整的列表，但它们在这里作为收到的反馈类型的样本呈现。 产品名称已编辑以确保准确性；否则，目的是发布未经编辑且按收到的原样的评论。
网络运营
如果您对“您的开发团队是否正确地安排了事情的优先顺序？”的回答是“否”——您希望他们以什么不同的方式安排事情的优先顺序？
- 稳定性、质量和愿景。 人们常常急于赶赴约会，但约会的质量却成了主要问题。 此外，不考虑当前任务之外的事情最终会导致大量的返工和不太理想的解决方案（垃圾拼凑在一起可能会有用，但无论如何都不是最优的或理想的）。
- 我们需要开发和系统管理团队之间更多的合作。 我们没有足够快地摆脱手动管理。
- 我希望开发团队更加关心操作可靠性、架构一致性以及不同开发团队之间的合作
- 应用程序开发人员不会考虑网络或安全，安全只是稍微了解开发情况，而网络会在开发完成后了解操作的变化。
在理想世界中，您如何改善开发和运营团队之间的互动、沟通、协作等？
- 改进指标、监控和可视性，以便双方都了解绩效。 自动化管道以加快服务交付。 提供足够的能力以避免较长的交货时间。
- 用更聪明的人代替他们
- 不要再将彼此视为障碍，让所有团队在最能增加价值的地方做出贡献。 自动化很棒，但如果没有一些监督，解决方案虽然可能有效，但通常有更好、更优化的方法可以实现。
- 开发团队和运营团队之间的界限更加模糊。 应被视为“一个团队”，具有共同的目标，即以最小的开销以可扩展且在可用基础架构上表现良好的方式交付applications。
- 如果您正在与精神上相当于打结的石头的人交谈，那么沟通就无关紧要。
- 让 F5 团队尽早参与到 DEV 周期的流程中。
- 在开发周期早期引入运维
- 共享代码和管道的可见性。 可以通过代码管理的工具越多越好（例如，我们无法在代码中合理地管理 F5 BIG-IP，这是我们流程的一个弱点）。
DevOps
如果您对“您的运营团队是否正确地安排了事情的优先顺序？”的回答是“否”——您希望他们以不同的方式安排哪些优先顺序？
- 我希望他们优先考虑在云空间中实现自动化、与云无关的资源创建。 按钮基础设施，对于开发人员、QA 和操作来说绝对是可实现且有用的。
- 他们需要适应自己接触的一切自动化，不再担心失业
- 手工工作太多，没有自动化，缺乏对核心技术问题的了解。 赋予开发人员权力。
- 他们倾向于用金钱来解决问题。 更多（昂贵）的设备。 需要更多的人力来推动机器运转，而不是依靠自动化。
在理想世界中，您如何改善开发和运营团队之间的互动、沟通、协作等？
- 我希望运维团队能够提供更多工具来抽象出运维环境的细节
- 我是开发人员，我们需要部署和自动化基础设施。 操作人员需要学习自动化和一些工具。
- 将运营团队转变为基础设施支持团队，实现基础设施的自动化管理。 这将允许开发人员将基础设施更多地用作服务，而不是依赖操作来执行升级、服务器管理等。 我还将运营团队成员嵌入到其他团队中作为联络人，以帮助简化applications的管理。
- 运营团队需要扩大并直接参与开发和测试。不再是一个处理请求的地方，而更像是前线的综合合作伙伴。