F5 DevOps与NetOps调查报告：自动化是弥合数字鸿沟的关键
人们经常谈论DevOps与NetOps之间这种典型关系。我们不断听到各种“我们对他们”的论调，将双方置于对立面；应用和指责隔着那堵分隔彼此的墙来回抛掷。随着更快、更频繁地交付应用的压力不断增加，这堵墙可能演变为一道数字鸿沟，将在应用经济中脱颖而出的企业与其他企业区分开来。
值得庆幸的是，得益于IT自动化和编排，这一数字鸿沟正在缩小。我们分别对NetOps和DevOps团队进行了调查，深入了解他们对技术的使用、对彼此的看法以及所交付的应用。调查发现，双方都希望携手弥合这一数字鸿沟。对于正在推进数字化转型的企业而言，这越来越成为一个利好消息，因为只有自动化和编排才能有效实现转型所需的规模和速度。对于受困于多云环境的组织来说，这同样是个好消息，因为多云环境需要本已不堪重负的员工投入更多精力。通过自动化减轻本地环境的工作压力，可以释放资源来处理云相关项目。
884名NetOps和DevOps专业人员参与了2017年夏季开展的在线调查。我们提出了若干认知相关问题，涉及受访者对应用的总体看法，以及他们对NetOps或DevOps同行的看法；此外，还询问了他们对部署频率和成功率的看法。
结果表明，尽管NetOps与DevOps之间仍存在隔阂，但远没有相关社群讨论或其他行业报告所描述的那么严重或难以打破。我们发现，不同规模和行业的组织在多个方面存在广泛共识：都重视并希望实现生产流水线自动化，也都对双方共同致力于开发和部署的应用在安全性、性能和可靠性方面抱有信心。
自动化似乎是凝聚NetOps和DevOps的一股力量。至少在原则层面如此，即使在具体实施细节上未必一致。
尽管DevOps和NetOps对于应通过自助服务和自动化开放多大程度的管道访问权限仍存在分歧，但总体而言，双方大多认为对方的方向是正确的。82%的DevOps人员和76%的NetOps人员认同对方优先处理了“正确的事项”。显然，即使双方在组织架构中并非总能达成一致，但至少在目标和关注重点上，已经跨越数字鸿沟找到了共同点。
在持不同意见的NetOps人员中，当被问及DevOps对哪些方面重视不足时，最常见的回答包括安全性。可靠性也经常被提及，是NetOps人员对DevOps感到不满的一个方面。
不出所料，DevOps对NetOps优先事项较为常见的意见之一集中在自动化上。更确切地说，是缺乏自动化。
这种意见分歧很可能是下一项关键发现的根源。该发现揭示了开发人员和DevOps无法通过自动化和自助服务访问生产流水线，对云以及IT部门之外的解决方案采用所产生的影响。
自动化影响云采用
现在，他们听到您的诉求了。 长期以来，业界普遍认为，无论对业务利益相关者还是DevOps利益相关者而言，采用云的一项驱动因素是无法自助访问生产部署流水线，导致部署周期漫长。遗憾的是，我们的调查证实了这一观点：27%的DevOps受访者表示，这对其选择云解决方案的决策影响“很大”，38%表示有“一定”影响。好消息是，NetOps并非没有意识到这一影响。超过65%的NetOps受访者表示，DevOps采用云的决策对其推动自动化并提供生产流水线自助访问的意愿有“一定”或“很大”影响。
主要发现
- 大力支持自动化。 双方高度认同交付和部署流水线自动化的重要性。在5分制的重要性评分中，DevOps的平均评分为4.0分，NetOps为3.5分。总体而言，受访者还表示，当生产流水线的自动化程度超过50%时，他们对应用的可靠性、性能和安全性更有信心。双方也几乎一致认为，对方“确定了正确的优先事项”。
- 自动化影响云采用，反之亦然。尽管双方认同这一点，但两个群体之间确实存在意见分歧，并会带来相应后果。其中一个分歧是对生产流水线访问权限的看法不同，我们认为这推动了多云的兴起。在DevOps方面，65%的受访者表示，缺乏生产流水线访问权限会影响他们寻求云和外部解决方案的决定。相反，接近半数的NetOps受访者（44%）表示，DevOps转向云的决定会在“一定程度上”促使他们愿意提供该流水线的访问权限，另有21%的受访者承认，这会对他们产生“很大”影响。
- 围绕管道访问权限的分歧以交付应用为重点、旨在提高内部效率和加强外部互动的数字化转型工作，必须跨越开发与生产之间的鸿沟。我们发现，两者之间的壁垒依然存在，对于应向开发人员和DevOps开放多少生产管道访问权限，各方看法不一。DevOps受访者中，占比最高的一部分认为，应通过自助服务和自动化开放超过75%的生产管道。NetOps的态度相对保守，但双方的分歧并不像普遍看法所认为的那么大。
- 当前部署频率已足够合适DevOps和NetOps人员都高度认同当前的部署频率“已经足够”。这也符合目前对两个群体之间存在分歧的普遍看法：NetOps人员认为部署频率“过高”的可能性是DevOps人员的两倍。DevOps人员中只有少数（4%）认为发布确实可能“过于频繁”。
广泛支持自动化
相互指责的局面已经结束。与常见说法不同，事件发生后，NetOps和DevOps并非总是相互推诿。我们发现，有证据表明，双方对彼此的看法要积极得多。
由于无法访问流水线而感到受挫的人员转向云，这在很大程度上推动了多云的兴起，也带来了相关的安全和性能挑战。由此产生的“影子IT”让相关人员疲于应对，他们也经常指出这些问题。尽管网络运维团队仍在努力通过自动化和自助服务，提供对私有云或类云系统的访问，但组织已在外部云解决方案上投入大量资源，这些投入不太可能被忽视。因此，组织需要管理、监控和保护多个云解决方案及环境，增加了在数字经济中运营的复杂性。
现在的问题不再是“是否提供生产流水线的自助访问权限？”，而是“开放到什么程度？”
围绕流水线访问权限的分歧
多少才算合适？ 对于应通过自动化和自助服务功能向开发人员及DevOps开放多大程度的流水线访问权限，各方意见存在显著分歧。DevOps显然希望获得更多生产流水线访问权限，但这超出了NetOps愿意提供的范围。
虽然我们并未询问NetOps为何不愿向DevOps开放更多流水线访问权限，但原因或许与其是否具备相应技能有关。NetOps受访者普遍认为，完成工作所需的技能与目前掌握的培训和知识之间存在差距。
事实上，在职责和技能组合相似的情况下，无论是NetOps还是DevOps，自认为是“开发人员”的受访者都更倾向于相信，自己的工作在5年后仍然具有价值。信心最低的是自认为是网络运维人员的受访者，NetOps和DevOps双方均是如此。
NetOps端生产管道自动化的现状似乎反映了这一技能差距带来的影响。其自动化程度明显落后于DevOps交付管道，这并不令人意外。11%的NetOps人员表示生产管道完全没有实现自动化，而DevOps人员中仅有5%表示应用交付管道同样未实现自动化。
值得关注的是，我们发现流水线自动化程度与成功部署频率呈正相关。在表示流水线自动化比例较高（75%或以上）的网络运维人员中，86%还报告称，非常成功（成功率达90%或以上）的部署频率更高。
但这并非唯一因素，因为应用变更频率似乎也会影响成功部署的频率。
当前部署频率已足够
目前这样就很好，谢谢。 部署频率或许仍是文化差异最显著的领域。部分DevOps团队以极快的速度将应用部署到生产环境（12%的团队每天将变更部署到生产环境不止一次），而NetOps团队似乎更倾向于以较慢但更稳定的节奏部署这些变更。
总体而言，多数受访者似乎在每月和每周的交付频率上达成了一定共识。不出所料，DevOps比NetOps更倾向于提高交付频率。具体而言，在希望提高交付频率的26% DevOps受访者中，28%每周交付一次，26%已经每天交付多次。
不同群体对变更交付速度是否足够快的看法各不相同。但值得注意的是，两个群体中的大多数受访者（DevOps为70%，NetOps为74%）都认为变更频率“足以满足我们的需求”。
双方的共同点仅止于此。仅有4%的DevOps人员认为当前的变更频率“过高”，而持相同看法的NetOps人员比例则是其两倍。超过四分之一（26%）的DevOps人员希望加快变更速度，而希望提速的NetOps人员不到五分之一（18%）。
不过，如果不考虑主观意愿，只看实际结果，就会发现一种可能兼顾速度与成功率的“理想”部署频率。在部署成功率超过90%的NetOps人员中，有65%“每周一次”将变更推送到生产环境；DevOps人员中这一比例为57%。
结论
应用从交付到部署仍需跨越数字鸿沟。部署流水线的许多环节仍依赖手动操作，这将继续推动应用迁移到云端。随着DevOps决定采用云服务，NetOps也将提供更多必要的自助访问能力，帮助加快这一进程。
自动化是弥合这一数字鸿沟的关键，它让NetOps和DevOps能够更智能地协作，而不是一味增加工作量，并共同扩展运营规模以满足业务需求。
方法论
本报告的数据来自2017年7月分别开展的两项在线调查。两项调查旨在了解自动化技术在应用从开发到部署的整个生命周期中的使用情况，以及参与其中的两个主要群体对此的看法。两个群体的受访者均获得了参与奖励。
附录：调查问卷节选
以下是从NetOps和DevOps受访者中选取的部分其他问卷回答。虽然并非完整列表，但这些回答可作为所收到反馈类型的示例。为确保准确性，产品名称已作编辑；除此之外，评论将按收到时的原文发布，不作修改。
NetOps
如果您对“开发团队是否合理安排了各项工作的优先级？”回答“否”，您希望他们如何调整优先级？
- 稳定性、质量和长远眼光。大家往往为了赶期限而冲刺，质量通常首当其冲。此外，如果只关注当前任务，最终会造成大量返工，解决方案也不尽如人意（东拼西凑出来的东西或许能用，但无论如何都谈不上理想）。
- 开发团队与系统管理员团队需要加强协作。我们摆脱手动管理的速度还不够快。
- 我希望开发团队更加重视运营可靠性、架构一致性以及不同开发团队之间的协作
- 应用开发人员没有考虑网络或安全问题，安全团队对开发工作仅略有了解，而网络团队要等到开发完成后才会得知运维方面的变更。
在理想情况下，您会如何改善开发团队与运维团队之间的互动、沟通和协作等？
- 改进指标、监控和可见性，让开发和运维团队都能了解性能情况。实现流水线自动化，加快服务交付。配置充足的容量，避免交付时间过长。
- 换成更聪明的人
- 不要再把彼此视为障碍，让所有团队都能在最能创造价值的环节发挥作用。自动化固然很好，但如果缺乏适当监督，实施的解决方案或许能够奏效，却往往还有更好、更优化的实现方式。
- 进一步打破开发团队与运维团队之间的界限。双方应被视为“一个团队”，共同致力于以尽可能低的开销交付应用，使其能够在现有基础设施上扩展并保持良好性能。
- 如果对方就像一块打着领带、毫无理解力的石头，沟通也无济于事。
- 在开发周期中更早让F5团队参与其流程。
- 在开发周期的更早阶段引入运维团队
- 共享代码并提高流水线的可见性。可通过代码管理的工具越多越好（例如，我们无法合理地通过代码管理F5 BIG-IP，这是我们流程中的一个薄弱环节）。
DevOps
如果您对“运维团队是否合理安排了各项工作的优先级？”回答“否”，您希望他们如何调整优先级？
- 我希望他们优先考虑在云环境中以自动化且不依赖特定云平台的方式创建资源。实现一键式基础设施是切实可行的，并且对开发、QA和运维团队都很有帮助。
- 他们需要适应将经手的一切工作自动化，不再担心因此失业
- 手动工作过多，缺乏自动化，也不了解核心技术问题。为开发人员赋能。
- 他们往往倾向于投入大量资金来解决问题：购置更多（昂贵的）设备，增加人手来维持运转，而不是采用自动化。
在理想情况下，您会如何改善开发团队与运维团队之间的互动、沟通和协作等？
- 我希望运维团队提供更多工具，以便将运维环境的具体细节抽象化
- 我是一名开发人员，我们需要部署基础设施并实现自动化。运维人员需要学习自动化和一些相关工具。
- 将运维团队转型为基础设施支持团队，实现基础设施管理自动化。这样，开发人员就能以服务的方式使用基础设施，而不必依赖运维团队执行升级、服务器管理等工作。我还会安排运维团队成员加入其他团队担任联络人，协助提升应用管理的便捷性。
- 需要扩充运维团队，并让其直接参与开发和测试。运维团队不应只是受理请求的部门，而应成为深入一线的协作伙伴。