当您正准备享用期待了一整天的美食时，却发现食物没有熟透。失望之下，您严厉地责备服务员，甚至可能少给小费。尽管这并不是服务员的错，他们仍然微笑着承受这一切。毕竟，食物并不是他们做的。但他们是您与后厨沟通的窗口，最终却要为那些发生在视线之外的失误付出代价。
无论是餐厅服务员，还是<在此插入服务名称>的客服代表，一旦出现问题，通常都是与您直接沟通的人承受您大部分的焦虑、不满和愤怒。
数据中心也是如此。
随着IT部门推进自身数字化转型，以实现更高程度的优化并提升速度，NetOps团队最有可能与内部“客户”互动。因此，当流程推进速度未达预期时，他们往往首当其冲，承受不满用户的抱怨。
需要认识到，阻碍最新技术、应用或服务部署的并不总是“NetOps”。组织在推动IT运营转型时，速度受阻往往是因为未能采纳DevOps的全部理念。
您是在践行DevOps，还是仅仅实现了自动化？
CAMS是传播DevOps核心理念的常用方法。CAMS分别代表：文化、自动化、度量和共享。
在这四项原则中，自动化最容易受到积极采纳。而在提高IT服务交付速度的过程中，其他三项原则往往会被搁置，甚至完全忽视。
尤其值得注意的是，这三个常被忽视的概念相互关联。如果团队仍按职能彼此隔离，并专注于对其他团队无关紧要的指标，就很难改变这种文化。考核什么，我们就会努力实现什么。如果考核的是网络正常运行时间，我们就会专注于此，即使运维团队的同事正努力提高应用正常运行时间。
具体来说，您可能还记得我们开展的《网络自动化现状研究》。在这项研究中，我们与Red Hat携手，深入探讨DevOps、NetOps和自动化这一复杂领域。研究发现，NetOps所关注的指标（衡量标准）与开发和运维团队所关注的指标存在显著差异。
近四分之三（73%）的网络运维人员将“网络正常运行时间”列为首要指标。相比之下，59%的开发和运维人员表示，“应用正常运行时间”是他们的首要指标。反过来，以部署频率作为衡量指标的开发和运维人员（30%）几乎是网络运维人员（16%）和安全人员（17%）的两倍。
为什么这种差异很重要？如果我的首要目标是确保网络可用，我就会把时间用于关注网络。检测和监控（后者对DevOps的共享环节至关重要）会首先关注网络，然后才可能关注应用，前提是还有时间。没有人有时间顾及安全，而且安全也不在任何人的考核指标之列。事实上，安全专业人员最常提到的衡量指标是<请听鼓声>“网络正常运行时间”，有59%的安全专业人员按此指标接受考核。
人仍然是IT的核心，也是负责实施自动化和编排的团队成员，但他们的目标未必一致。造成这种目标错位的一个因素，是各运维领域持续相互隔离。网络运维和安全团队更倾向于采用“单一职能”团队模式。网络运维只关注网络。安全团队呢？只关注安全。运维团队呢？只关注系统运维。
但问题远不止于此。因为大孤岛内部还存在更小的孤岛。就像俄罗斯套娃一样，NetOps内部有许多不同的团队。这个看似简单的“新站点”请求必须流转至这些团队，才能最终完成。要完成此类请求，需要预配并接入大量基础设施和应用服务。新站点不仅需要用于托管的计算和网络资源，还有许多其他要求，包括Web服务器及其存储、访问控制、证书和密钥管理、负载均衡、防火墙规则等。这个“简单”请求需要经过的IT内部孤岛不胜枚举。
而且，如果NetOps孤岛内的这些孤岛中有任何一个未实现自动化，整个流程就会戛然而止。完成此类请求可能会因此多花数天，甚至数周。
在外部人员，也就是请求者看来，NetOps似乎只是没有尽到职责。作为“对接方”“联络人”和“IT合作伙伴”，NetOps不得不承受请求者的焦虑和质疑：一个看似简单的请求，为什么要这么久才能完成？我们责怪NetOps，就像不熟悉技术的人遇到互联网连接不稳定时会责怪本地服务提供商一样，而真正的问题其实出在骨干网深处的一台路由器上，它由另一家服务提供商管理。
做支持者，而非对立者
对于许多组织而言，向更具协作性和透明度的IT转型仍只是初现端倪。虽然部分IT团队认识到了这种必要性，并积极推动所需的变革，但并非所有团队都如此。在我们开展应用服务研究的5年间，“DevOps”始终未能达到应有的战略重要性，因而不足以真正推动必要的文化和组织变革，实现业务期望且必需的速度。相反，组织纷纷采用自动化，却忽视了对DevOps至关重要的另外三个组成部分。
令人担忧的是，人们未能认识到，IT领域的DevOps运动并不只是自动化。要提高速度，就必须实现流水线自动化，而这条流水线几乎贯穿IT内部的每个运维领域和孤立团队，但人们并未认识到这一点。这意味着所有受影响的人员都必须转向自动化，否则就无法达到所期望的部署速度和频率。仅仅采用自动化并不能确保成功。当自动化需要跨越各个孤立团队的边界时，如果没有重大的文化变革，就无法取得成功。
所需的变革必须自上而下推动，组织变革尤其如此。毕竟，我们无法自行重组，对吧？我们也无法自行调整目标优先级，并采用一套完全不同的衡量指标，对吧？
我们做不到。除非我们让那些能够推动必要变革的人了解情况并说服他们，否则即使管道的其他环节都已实现自动化，我们仍会受困于手动流程。
因此，不要再把NetOps当作替罪羊，也要认识到他们可能同样感到沮丧。相反，应提醒决策者重新评估组织结构，并重新确定衡量指标的优先级，以便更好地与业务及持续交付流水线的其他环节保持一致。
对一线网络运维人员大吼大叫，或许会让人觉得解气，但这并不能真正改变最初引发愤怒的局面。如果不做出改变，流水线也不会加快。
支持网络运维团队，而不是与他们对立。他们需要尽可能多的帮助。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。