您可能已经注意到，我们正在撰写一个系列文章，主题类似于“弥合……之间的鸿沟”
这篇谈的是如何弥合团队之间的隔阂，但我一开始觉得这像是个陷阱。
我看过太多文章把DevOps团队和NetOps团队对立起来，甚至几乎演变成针对个人的冲突。这无助于解决问题，因为问题不在于个人或团队，而在于塑造这些团队的种种限制和期望。团队中的成员大多都喜欢在工作中做同一类事情：有意思的事。我们都希望做出让自己引以为豪、切实有用，而且确实很酷的成果。
团队之间的差异，以及决定我们日常工作方式的因素，在于工作范围、工作影响和可用工具。DevOps团队通常负责解决某个应用或一组服务的问题。NetOps团队则要解决一家企业的问题；对于云NetOps团队而言，可能要面对数百家企业（没错，这样的团队确实存在）。大多数网络团队至少有一部分工作涉及物理世界，因为总得有实际设备将光子和电子从一处传送到另一处。大多数DevOps团队则在虚拟世界中工作，几乎可以瞬间创建和销毁资源。开发和DevOps团队可以轻松地将代码和业务逻辑与底层架构的繁杂细节抽象分离，这样做完全合理，但其中隐含着一种信任：有人会确保API调用正确到达目的地并返回。每个人都希望快速推进，也都希望系统不会出故障；即使出现故障，也能轻松诊断和修复。只不过身处其中时，他们眼中的世界可能略有不同。
问题往往始于这两种现实的交界处。显然，在许多组织中，不同团队的工作方式和SLA要求之间确实存在差异。虽然这种摩擦可能被视为新问题，但我们早在十多年前就已观察到这种情况，因为F5技术一直连接着以应用为中心的团队和以基础设施为中心的团队。无论只是后端服务器数量发生变化，还是应用行为有所改变，应用架构的变化始终需要反映在应用交付层，因为安全检查、内容路由或负载均衡都在这一层进行。如今，开发人员正以更具迭代性的方式组织工作流，这些变化发生得越来越快，相关问题也因此愈发明显。
正因如此，现在才如此令人振奋，因为我们迎来了弥合这一分歧的难得机遇。F5一直在开发越来越多的工具，将高度稳健的企业级技术融入更敏捷的自动化工作流。我们一直在为所有希望了解这些新工作方式的人提供培训，同时也在转变内部的工作方式。
但要弥合分歧，关键在于相互理解和共享经验。支持这一过程的工具和流程固然重要，但如果缺少协作这一黏合剂，也无法发挥作用。我最期待的是与NGINX开展更深入的合作，借此跨越隔阂，从他们的角度，更重要的是从他们客户的角度，了解流程分歧带来的不同体验。通过携手合作，我们可以帮助共同客户增进参与交付安全、快速且创新应用的各团队之间的理解。当然，其中会涉及技术，毕竟这是我们的专长。但这些技术将涵盖更广泛的用例，并以更全面的DevOps和NetOps愿景为指引，满足我们最关注的群体，也就是客户和用户的需求。
关于作者
相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。