IT 领导者需要参与并接受 DevOps

IT从业人员都是动手能力强的人。 对于负责将应用程序部署到生产中并维护其可用性、安全性和性能的人来说，DevOps 作为一种文化转型通常不够切实。 但现实是，文化转变 — — 打破群体间和群体内的隔阂 — —必须发生，而且要尽早发生。 

当谈到新兴趋势和架构对网络的影响时尤其如此。

许多以网络为中心的领导者和从业者并没有过多关注不断变化的应用程序架构格局。 例如，除了我们的基础设施也有一个 API 之外，我们在网络领域很少真正讨论向 API 和微服务的转变。因为 SDN（或 SDDC）。

但是他们需要意识到这些变化，以及它们将如何（不是是否会发生，而是会）影响网络和向苛刻的消费者和同事提供这些应用。 即使看似完全应用架构的决策也可能对网络架构以及网络性能和要求产生重大影响。 例如，是否采用多租户还是单租户微服务的决定会对从安全性到基本路由和交换的网络服务产生重大影响。 如果未能认识到将 HTTP/2 或 HTTP/1 与微服务结合使用的架构决策，可能会导致网络出现严重问题并降低性能。

开发人员越来越意识到他们的架构在其领域内外的影响。 服务延迟（两个服务通过网络进行通信所需的时间）是高度分布式应用架构中一个众所周知的问题。 开发人员不知道的是网络（及其服务堆栈）如何帮助减轻这种环境对性能（和弹性）的负面影响。 

这是网络人士所知道的。

问题在于，直到一百亿个微服务投入生产时，网络人员才会参与其中。 他们没有被征求意见，并且在他们参与的时候提出建议可能意味着对服务或应用进行大规模的返工。 即使是将可扩展性插入到网络而不是应用程序内部的简单改变也会成为一场噩梦。 但如果服务架构中考虑到了网络可扩展性，那么这将是一个顺利的运行。

但事实并非如此，而且这10 名高管中有 9 名感受到了更快推出应用程序的压力？ 他们感受到的压力更大，因为需要时间来对网络进行必要的改变以提供如此多相互连接、相互关联、相互依存的服务。

IT 中有四个操作：基础设施、网络、存储和安全。 并且所有四个筒仓（或者如果你更喜欢一个中世纪的比喻，可以称之为塔楼）必须在彼此之间搭建桥梁，以促进在开发周期早期的协作和沟通。 关于架构选择的协作应该在设计期间而不是部署期间进行。 这种合作可能需要由对每个组织有深入了解的领导者发起，以便了解何时考虑新技术和架构。

DevOps 不仅仅涉及自动化——它是一种实现目标的工具和技术。 自动化可以在减轻负责部署和交付应用程序所需服务的人员的负担方面发挥重要作用，从而释放四个运营领域的专家。 让他们能够自由地参与组织之间的更大协作（共享），以提高应用经济中至关重要的应用的规模、性能和安全性。

业务成功和增长不仅取决于 IT 部门内部的协作，还取决于领导层的协作。