缩短价值实现时间： 流程和并行化

圣诞节期间人们常有这样的哀叹。 这是从屋顶上和松树多刺的树枝下传来的歌声。

“当一盏灯灭了，所有的灯就都灭了！”

这是被串联电路中的灯困住的人的呼喊。 我不想详细解释为什么会出现这种情况，但我可以说，一个烧坏的灯泡是一个阻碍因素。

对于那些拥有并联电路中串联灯的人来说，情况并非如此。 一个灯泡可能坏了，但其他灯泡仍能继续明亮地亮着。

这与时间价值和applications有什么关系？ 一切。 因为事实证明，传统 IT 实际上是在串行电路中推动生产的，而现代应用程序开发则是在并行电路中全天候运行。

过程

Pivotal Global Field 首席技术官James Urquhart在最近的一篇博客中提出了持续 IT 的重要图景，该图景恰当地强调了流程而非产品。 他称之为“生产之路”。

生产路径的理念实际上与流程有关，对于传统 IT 而言，还与并行有关。 这个概念是现代application开发和架构的核心。 将应用程序分解为单独的、集中的组件（有时称为微服务）自然会导致并行开发。 这是因为较小的团队同时处理不同的组件。 这最终使敏捷成为一种机制，以实现更快的速度并减少applications的价值实现时间。 这不是规模较小的团队。 这不是较小的应用程序。 这是在applications的开发和交付中利用这些概念实现的并行化。

同样的方法也适用于生产之路。 也就是说，实现规模和确保applications安全所必需的生产组件（服务）是更大流程的一部分，其中一些可以并行开发和交付。

而阻碍这一进程的正是传统 IT。 連續 IT。 瀑布式开发方法蔓延至生产池。 我们将网络构建为串行通道，因为数据在网络中串行流动。 从路由器到防火墙到负载平衡到应用服务器到数据库。 数据按照可预测的路径从网络的一端流到另一端。 因此，我们以相同的方式实现和交付这些application服务：采用可预测的、序列化的过程，自然遵循数据路径。

这不再起作用了。

首先，因为现在有多条数据路径。 不仅仅是穿越北向和东西向的数据路径，还有偏离其他基本方向的数据路径。 NE 到云端去检索脚本。 SW 用于检索精灵和网络字体。 WSE 抓取地图并将其嵌入到我们的应用程序中。

但如今，不仅仅是数据路径的分布使得生产路径的并行化成为必要。 这是对效率和速度的追求，又称优化。

并行化

为了加快执行速度以满足当今的价值期望，并行开发是必要的。 不仅仅在应用程序开发方面，而且在核心 IT 方面也是如此。 如果我们观察当今企业所使用的application服务的广度，我们可以看到并行化可以在多个领域帮助加快部署。

传统 IT 并非完全孤立。 毕竟，微服务架构的结果是数十或数百个小型孤立的团队，每个团队都专注于一组非常有针对性的application功能。 传统 IT 已经是孤岛中的孤岛。 问题在于，敏捷开发实践鼓励在其孤岛内进行并行开发，而传统 IT 仍然以有条不紊、序列化的方式贯穿生产流程。

问题在于团队之间的交接，以及我们在生产过程中镜像网络流量的方式。 这不是一个串行的过程，只要我们可以并行化开发和交付服务，我们就应该这样做。

这意味着跨职能的团队结构应该尽早鼓励合作。

通过在所有关注点采用更多敏捷实践来并行化流程，组织可以在生产过程中实现更快的速度和更高的效率。

过程即产品

正如詹姆斯所暗示的，生产之路实际上是一个过程。 流程是由步骤组成的。 任何一位六西格玛黑带流程忍者都会告诉你，加快该流程的关键在于发现并消除效率低下之处。 在生产中，这些低效率表现为部署过程中严格的序列化步骤之间的等待时间（交接）。

工具可以提供帮助。 但最终的改进将需要对流程进行长期、认真的审视，并寻找机会将application服务的交付作为生产路径的一部分并行化。

文化——特别是合作文化——不是可有可无的。 它对行为和实践有着非常现实的影响。 单是团队结构就极大地改变了管道自动化，传统的单一功能团队就落后于当代的 DevOps 驱动的团队。 推动更具协作性的团队结构。 同样，协作团队应该在关键指标上保持一致。 共享指标使 NetOps 和安全部门能够致力于持续部署而不会受到惩罚。 目前，近四分之三的 NetOps 是根据网络正常运行时间来衡量的。 他们几乎不关注部署的频率。 他们将专注于维护网络正常运行，因为这是他们必须关注的。 共享指标使 NetOps 能够专注于业务需求——更快、更频繁的部署。 

最后，需要同理心。 你们都在同一个团队，而且——你可能会惊讶地发现——重视同样的事情。 NetOps 可能与 DevOps 一样高度重视管道自动化。 请记住，DevOps 在解决和克服集成、工具和技能方面的障碍方面比 NetOps 领先了十年。 协作团队可以通过促进从交付到部署的工具（如 Jenkins 和 GitHub/GitLab）的标准化来提供帮助。

生产的路径不是产品。 这是一个过程。 而且，这个过程需要尽可能地协作和并行交付，以缩短价值实现时间并实现成功的application部署。