【.com速译】MikeLoukides在将O'ReillyMedia的长文《DevOps是什么?》以书的形式发表时，取了一个家喻户晓的副标题：InfrastructureasCode。那篇文章只有20页长，提出了几个要点：基础设施进入代码。运行软件的云系统是由代码创建的。运营角色将进入团队。监控对平台的访问。我们从代码创建的用于服务软件的虚拟机将包括内置监控。八年后，可能是时候问问这些预测是否属实、我们学到了什么以及接下来会发生什么。基础设施即代码Loukides的文章引用了几个著名的例子，例如Netflix的ChaosMonkey，它们是完成基础设施工作的成熟计算机程序。当时最流行的想法是，运营人员将成为成熟的计算机程序员，用Python或Ruby编写程序来设置一系列运行应用程序代码的虚拟机。客户需要管理资源、规模和可用性等。事实证明，这很难编写，更难调试，而且几乎不可能保持运行。该行业确实在几个方面做出了强有力的回应。首先在2013年的Python大会上，SolomonHykes和SebastienPahl介绍了Docker，这是一种用于Linux系统的轻量级虚拟化工具。一年后，谷歌开源了Kubernetes。Kubernetes和Docker在传统的“基础设施即代码”之间引入了一个很大的区别：它们不是由代码驱动，而是由配置和命令驱动。流行的术语是声明式DevOps。简而言之，不是编写常规的经典代码来告诉计算机“如何”创建服务器，而是创建一个配置文件来告诉计算机“什么”并运行命令。在Kubernetes术语中，它是一个清单文件，而不是来自命令行的一系列Kubectl命令，或者更糟的是，一个运行kubectl命令的Python程序，在无限的“while”循环中运行，试图监控系统并采取纠正措施。顾问兼培训师BobReselman表示，清单文件将创建更易于审计和控制的可重用资产。虽然“基础架构即代码”并未接管软件的所有方面，但它在促进微服务的兴起方面发挥了至关重要的作用，团队通常可以自行运行微服务。运维进入团队至少对于微服务来说，运维现在可以说是软件开发团队的一部分。也就是说，对于新服务，我看到团队支持他们创建的服务。这并不是说与我合作的每个组织都是如此，但这些变化并非无处不在。另一项创新是全新的工作类别，即软件可靠性工程师或SRE。SRE负责系统可用性、延迟、性能、应急响应和容量等。他们监控大量网站和服务并采取纠正措施。这是一种“DevOps”工作，因为它将软件开发的严谨性带到了操作中。我个人感到有点难过，因为我们发明了一种全新的工作类别，而不是开发和运营团队一起工作。它似乎确实适用于有可扩展性问题的大公司。较小的团队只是将操作部分交给团队。监控进入平台电话和路由器、网络服务器、微服务、数据库，甚至可能出错的物联网设备之间的许多链接。Kubernetes方面还没有出现的一件事是支持我们一直想要的监控。云托管公司确实提供了用于查看服务器运行状况的优秀仪表板，但跟踪消息（这是可观察性的一部分）是大多数团队自己计划的事情。这可能属于下一步。下一步是什么？虽然Windows容器确实有效，至少在理论上适用于特定操作系统，但我还没有看到一家公司实际使用它。Kubernetes仍然主要是Linux系统的解决方案，尤其是Web服务器和可能的数据库服务器。目前，敬业的工程师将不得不习惯于在传统操作人员继续工作的异构操作环境中工作。然后是监控。有像Istio这样的软件包和开源系统可以检测云系统并自动创建监控系统和审计跟踪。我看到的问题是它们需要大量的CPU/Member，这意味着云中的大量费用。他们还可以将网络要求大致翻倍。有多少次我看到一家公司花费数万甚至数十万美元加上多年的工程人力来实施监控系统，结果却以关闭监控系统而告终，因为系统要求实际上会影响生产。原标题：HowDevOpshaveevolvedsince2012，作者：MatthewHeusser
