有人可能会说，容器和 DevOps 是天生一对。当然，容器生态系统受益于 DevOps 实践的迅速普及，这体现在设计选择以及开发容器技术的团队对 DevOps 的使用上。由于这种并行演变，在生产中使用容器可以教会团队 DevOps 的基本原理及其三大支柱：三种方法。
流动原则
容器流动
容器可以被视为一个孤岛，从内部来看，很容易忘记系统的其余部分：主机节点、集群、底层基础设施。在容器内部，可能看起来一切都运行良好。然而，从外部的角度来看，容器内部的应用程序是构成服务的更大应用程序生态系统的一部分：Web API、Web 应用程序用户界面、数据库、工作程序以及缓存服务和垃圾收集器。团队对容器施加约束，以限制对基础设施的性能影响，并且已经做了很多工作来提供衡量容器性能的指标，因为过载或缓慢的容器工作负载会对其他服务或客户产生下游影响。
现实世界的流动
这一教训也适用于在孤岛中运作的团队。每个流程（无论是代码发布、基础设施创建，甚至是 Spacely's Sprockets 的制造），都遵循从概念到实现的线性路径。在技术领域，这种进步从开发到测试再到运营和发布。如果单独工作的团队成为瓶颈或引入问题，则整个管道都会感受到影响。传递到下游的缺陷会破坏下游的生产力。虽然团队自身范围内的损坏流程可能看起来完全正确，但它对整个环境产生了负面影响。
DevOps 和流动
DevOps 的第一种方法，流动原则，是将流程视为一个整体，努力理解系统如何协同工作，并理解问题对整个流程的影响。为了提高流程的效率，需要识别并消除痛点和浪费。这是一个持续的过程；团队必须不断努力提高流程的可见性，并找到并修复故障点和浪费。
“将第一种方法付诸实践的结果包括永不将已知的缺陷传递到下游工作中心，永不允许局部优化造成全局退化，始终寻求增加流动，并始终寻求深刻理解系统（根据戴明的说法）。”
–Gene Kim，《三种方法：DevOps 的基本原则》，IT Revolution，2017 年 4 月 25 日
反馈原则
容器反馈
除了限制容器以防止对其他地方产生影响外，还创建了许多产品来监控和趋势化容器指标，以便了解它们正在做什么，并在它们行为不端时发出通知。Prometheus 例如，非常流行，用于从容器和集群收集指标。容器非常擅长分离应用程序，并提供一种将环境与代码一起交付的方式，有时以不透明性为代价，因此做了很多工作来尝试提供快速反馈，以便可以在孤岛内及时解决问题。
现实世界的反馈
对于系统的流动来说，也是如此。从概念到实现，高效的流程可以快速提供相关反馈，以识别何时出现问题。这里的关键词是“快速”和“相关”。让团队淹没在成千上万条不相关的通知中，使得他们难以甚至不可能注意到需要立即采取行动的重要事件，而即使是太晚接收相关信息也可能使小的、容易解决的问题向下游移动并变成更大的问题。想象一下，如果露西和埃塞尔 立即反馈传送带速度太快——那么巧克力生产就不会出现问题了（尽管那样就没那么有趣了）。
DevOps 和反馈
DevOps 的第二种方法，反馈原则，完全是关于快速获取相关信息。通过即时、有用的反馈，可以在问题发生时识别出来，并在影响到开发过程中的其他地方之前解决。DevOps 团队努力“为下游优化”，并立即采取行动修复可能影响到后续团队的问题。与流动一样，反馈是一个持续的过程，旨在识别快速获取重要数据并根据发生的问题采取行动的方法。
“创建快速反馈对于在技术价值流中实现质量、可靠性和安全性至关重要。”
–Gene Kim 等人，《DevOps 手册：如何在技术组织中创建世界一流的敏捷性、可靠性和安全性》，IT Revolution Press，2016 年
持续实验和学习原则
容器持续实验和学习
将运营学习应用于 DevOps 的第三种方法：持续实验和学习 稍微更具挑战性。试图挽救我们可以掌握的比喻的边缘，容器使开发变得容易，允许开发人员和运营团队在生产环境之外本地且安全地测试新代码或配置，并将发现的好处纳入生产环境，这在过去是很难做到的。更改可以是激进的，并且仍然可以进行版本控制、记录和快速轻松地共享。
现实世界的持续实验和学习
例如，考虑一下我自己的经历：多年前，作为一名年轻、经验不足的系统管理员（刚入职三周），我被要求更改大学中央 IT 部门网站运行的 Apache 虚拟主机。在没有易于使用的测试环境的情况下，我对生产站点进行了配置更改，我认为这将完成任务并将其推送出去。几分钟之内，我听到隔壁隔间的同事说
“等等，网站是不是宕机了？”
“嗯，是的，看起来是这样。这是怎么回事？”
其中涉及了很多翻白眼。
我很羞愧（这种羞耻感是真实的，伙计们），我尽可能地缩到座位上，并拼命地试图撤销我引入的更改。当天下午晚些时候，部门主管——我老板的老板——出现在我的隔间里，谈论发生了什么事。“别担心，”她告诉我。“我们没有生你的气。这是一个错误，现在你已经学到了。”
在容器的世界里，这本可以很容易地在我的笔记本电脑上更改和测试，并且在它进入生产环境之前很久，更有经验的团队成员就可以识别出损坏的配置。
DevOps 持续实验和学习
真正的实验文化促进了个人发现流程中的更改可能在哪里有益的能力，并在没有害怕失败后遭到报复的情况下测试该假设。对于 DevOps 团队来说，失败成为一种教育工具，可以增加个人和组织的知识，而不是应该害怕或惩罚的事情。DevOps 团队中的个人致力于持续学习，这反过来又使团队和更广泛的组织受益，因为这些知识得到了共享。
随着比喻完全崩溃，需要关注一个具体的点：其他两个原则乍一看似乎完全侧重于流程，但持续学习是一项人类任务——对于项目、个人、团队和组织的未来至关重要。它对流程有影响，但它也对个人和其他人有影响。
“实验和冒险使我们能够不断改进我们的工作系统，这通常要求我们以与几十年来的做法截然不同的方式做事。”
–Gene Kim 等人，《凤凰项目：关于 IT、DevOps 和帮助您的企业获胜的小说》，IT Revolution Press，2013 年
容器可以教给我们 DevOps
学习有效地使用容器可以帮助教授 DevOps 和三种方法：流动原则、反馈原则以及持续实验和学习原则。从整体上看待应用程序和基础设施，而不是对容器之外的一切视而不见，这教会我们考虑系统的所有部分，并理解它们的上游和下游影响，打破孤岛，并作为一个团队工作，以提高全局性能和对整个系统的深刻理解。努力提供及时和准确的反馈教会我们在组织内部创建有效的反馈模式，以便在问题的影响扩大之前识别出来。最后，提供一个安全的环境来尝试新想法并从中学习，这教会我们创建一个文化，在这种文化中，失败代表着对我们知识的积极补充，而对有根据的猜测进行大胆尝试可能会为复杂问题带来新的、优雅的解决方案。
3 条评论