标准化对 NetOps 有利

标准化有时被视为对创新的攻击。 被迫放弃多语种自助餐并采用更为有限的菜单听起来确实令人窒息。 这可能是因为标准化通常与监管合规标准相关，这些标准具有听起来很正式的名称，如 ISO 8076.905E，并且附带检查表、审计员和监督委员会。

现实情况是，只有很少的标准（事实上我想不出一个）来规范企业组织对语言、协议和框架的选择。 推动企业标准化的是更多实际的考虑，例如人才的可用性、可持续性以及软件和系统整个（通常相当长的）生命周期的总拥有成本。

研究表明，过去二十年软件的平均寿命约为6至8年。 有趣的是，以代码行数（LOC）来衡量，程序越大，其寿命就越长。 拥有超过一百万行代码的系统和软件的寿命似乎可以超过十年，持续 12 到 14 年。 尽管您可能认为这无关紧要，但重要的是要认识到，归根结底，网络自动化系统是软件和系统。 它们需要与您的开发组织生产的软件相同的关心、支持和维护。 如果您要将生产管道视为代码，那么您必须接受该自动化管道的很大一部分将是代码。

那么，在该软件或系统的整个生命周期中，可以肯定有多组操作员和开发人员将负责更新、维护、操作和部署该软件或系统的更改。

这正是推动标准化的核心，特别是对于 NetOps 而言，因为他们致力于开发和维护系统，以自动化和协调网络和应用服务基础设施的部署和运营。 

筒仓用于农场

如果您（或您的团队）选择 Python，而另一个人选择 PowerShell，那么您实际上是在构建一个阻止技能共享的运营孤岛。 根据《2018 年网络自动化状况》报告，NetOps 面临的最大挑战是缺乏技能（49% 的人表示），通过引入多种语言和/或工具集来制造额外的摩擦似乎是愚蠢的。 同样，选择您当地没有人才支持的语言和工具集也是一个坏主意。 如果其他组织和附近的大学正在教授 Python 而您选择使用 PowerShell，那么您将很难找到具备使用该系统所需技能的人员。

一个组织很少会对单一语言进行标准化，但他们确实倾向于只对几种语言进行标准化。 NetOps 应该从开发和 DevOps 标准中获得启发，因为这将进一步扩大人才库。

价值实现时间很重要

许多 NetOps 组织在满足 DevOps 和业务持续需求方面已经发现自己处于劣势。 NetOps 和网络自动化的不幸现实是，它是一个异构的生态系统，几乎没有预先打包的集成可用。 我们在网络自动化状况调查中发现，“缺乏集成”是自动化面临的第二大挑战，47% 的 NetOps 表示同意。

在可能的情况下对工具集和基础设施（如应用服务）进行标准化，可以减轻整个组织的集成负担。 一个团队开发的东西，其他团队可以利用来缩短其他自动化项目的价值实现时间。 重用是提高价值实现时间的一个重要因素。 我们看到开发人员对开源的倾向的重用，以及当今 80-90％ 的应用都是由第三方/开源组件组成的事实。 这加快了开发速度并减少了价值实现时间。 通过利用现有的集成，可以将相同的原理应用于网络自动化。

建立跨运营领域的共享和重用文化，以获得标准化的好处。

激励创新

标准化非但不会像一些人最初认为的那样阻碍创新，反而会成为创新的催化剂。 通过跨操作领域标准化和共享软件和系统，您将拥有更强大的思维和经验，能够在新的需求和系统上进行协作。 您正在组织内建立一个人才库，他们可以提供新特性和功能的意见、构思和实施，而无需有时冗长的入职周期。

由于熟悉，标准化也加快了实施速度。 你使用同一种语言、库和工具集的次数越多，你的能力就越强。 这意味着生产力的提高，从而减少制造车轮的时间，而将更多的时间用于考虑如何利用新功能进行差异化和增加价值。

标准化是一个机会

标准化最初可能会让人感到压抑，特别是当你擅长的语言或工具集被从团队中剔除时。 但是，将标准化作为构建自动化系统和软件坚实基础的机会将使企业受益，并为 NetOps 在整个持续部署工具链中增加价值提供新的机会。

但不要仅仅为了标准化而标准化。 考虑现有的技能组合和当地人才的可用性。 调查大学和其他企业，了解自动化和运营技能和人才的现状，以确保您不是唯一采用特定语言或工具集的组织。

为了获得最佳的长期效果，不要将标准化视为安全性，并将其留到完成实施之后。 在自动化工作的早期阶段就采用标准化，以避免受到运营和架构债务的困扰，这些债务会拖累您并使以后的标准化变得困难。

标准化——就像安全性一样——早点实现总比晚点好。