mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-01 21:50:13 +08:00
106 lines
8.4 KiB
Markdown
106 lines
8.4 KiB
Markdown
容器技术对指导我们 DevOps 的一些启发
|
||
======
|
||
|
||
容器技术的使用支撑了目前 DevOps 三大主要实践：流水线，及时反馈，持续实验与学习以改进。
|
||
|
||
|
||
|
||
容器技术与 DevOps 二者在发展的过程中是互相促进的关系。得益于 DevOps 的设计理念愈发先进，容器生态系统在设计上与组件选择上也有相应发展。同时，由于容器技术在生产环境中的使用，反过来也促进了 DevOps 三大主要实践：[支撑DevOps的三个实践][1].
|
||
|
||
|
||
### 工作流
|
||
|
||
**容器中的工作流**
|
||
|
||
每个容器都可以看成一个独立的封闭仓库，当你置身其中，不需要管外部的系统环境、集群环境、以及其他基础设施，不管你在里面如何折腾，只要对外提供正常的功能就好。一般来说，容器内运行的应用，一般作为整个应用系统架构的一部分：比如 web API，数据库，任务执行，缓存系统，垃圾回收器等。运维团队一般会限制容器的资源使用，并在此基础上建立完善的容器性能监控服务，从而降低其对基础设施或者下游其他用户的影响。
|
||
|
||
**现实中的工作流**
|
||
|
||
那些跟“容器”一样独立工作的团队，也可以借鉴这种限制容器占用资源的策略。因为无论是在现实生活中的工作流（代码发布、构建基础设施，甚至制造[Spacely’s Sprockets][2]等），还是技术中的工作流（开发、测试、试运行、发布）都使用了这样的线性工作流，一旦某个独立的环节或者工作团队出现了问题，那么整个下游都会受到影响，虽然使用我们这种线性的工作流有效降低了工作耦合性。
|
||
|
||
**DevOps 中的工作流**
|
||
|
||
DevOps 中的第一条原则，就是掌控整个执行链路的情况，努力理解系统如何协同工作，并理解其中出现的问题如何对整个过程产生影响。为了提高流程的效率，团队需要持续不断的找到系统中可能存在的性能浪费以及忽视的点，并最终修复它们。
|
||
|
||
|
||
> “践行这样的工作流后，可以避免传递一个已知的缺陷到工作流的下游，避免产生一个可能会导致全局性能退化的局部优化，持续优化工作流的性能，持续加深对于系统的理解”
|
||
|
||
–Gene Kim, [支撑DevOps的三个实践][3], IT 革命, 2017.4.25
|
||
|
||
### 反馈
|
||
|
||
**容器中的反馈**
|
||
|
||
除了限制容器的资源，很多产品还提供了监控和通知容器性能指标的功能，从而了解当容器工作不正常时，容器内部处于什么样的工作状态。比如 目前[流行的][5][Prometheus][4]，可以用来从容器和容器集群中收集相应的性能指标数据。容器本身特别适用于分隔应用系统，以及打包代码和其运行环境，但也同时带来不透明的特性，这时从中快速的收集信息，从而解决发生在其内部出现的问题，就显得尤为重要了。
|
||
|
||
**现实中的反馈**
|
||
|
||
在现实中，从始至终同样也需要反馈。一个高效的处理流程中，及时的反馈能够快速的定位事情发生的时间。反馈的关键词是“快速”和“相关”。当一个团队处理大量不相关的事件时，那些真正需要快速反馈的重要信息，很容易就被忽视掉，并向下游传递形成更严重的问题。想象下[如果露西和埃塞尔][6]能够很快的意识到：传送带太快了，那么制作出的巧克力可能就没什么问题了（尽管这样就不太有趣了）。
|
||
|
||
**DevOps and feedback**
|
||
|
||
DevOps 中的第二条原则，就是快速收集所有的相关有用信息，这样在出现的问题影响到其他开发进程之前，就可以被识别出。DevOps 团队应该努力去“优化下游“，以及快速解决那些可能会影响到之后团队的问题。同工作流一样，反馈也是一个持续的过程，目标是快速的获得重要的信息以及当问题出现后能够及时的响应。
|
||
|
||
> "快速的反馈对于提高技术的质量、可用性、安全性至关重要。"
|
||
|
||
–Gene Kim, et al., DevOps 手册：如何在技术组织中创造世界级的敏捷性，可靠性和安全性, IT 革命, 2016
|
||
|
||
### 持续实验与学习
|
||
|
||
**容器中的持续实验与学习**
|
||
|
||
如何让”持续的实验与学习“更具操作性是一个不小的挑战。容器让我们的开发工程师和运营团队，在不需要掌握太多边缘或难以理解的东西情况下，依然可以安全地进行本地和生产环境的测试，这在之前是难以做到的。即便是一些激进的实验，容器技术仍然让我们轻松地进行版本控制、记录、分享。
|
||
|
||
**现实中的持续实验与学习**
|
||
|
||
举个我自己的例子：多年前，作为一个年轻、初出茅庐的系统管理员（仅仅工作三周），我被要求对一个运行某个大学核心IT部门网站的Apache虚拟主机进行更改。由于没有易于使用的测试环境，我直接在生产的站点上进行了配置修改，当时觉得配置没问题就发布了，几分钟后，我隔壁无意中听到了同事说：
|
||
|
||
”等会，网站挂了？“
|
||
|
||
“没错，怎么回事？”
|
||
|
||
很多人蒙圈了……
|
||
|
||
在被嘲讽之后（真实的嘲讽），我一头扎在工作台上，赶紧撤销我之前的更改。当天下午晚些时候，部门主管 - 我老板的老板的老板来到我的工位上，问发生了什么事。
|
||
“别担心，”她告诉我。“我们不会生你的气，这是一个错误，现在你已经学会了。“
|
||
|
||
而在容器中，这种情形很容易的进行测试，并且也很容易在部署生产环境之前，被那些经验老道的团队成员发现。
|
||
|
||
**DevOps 中的持续实验与学习**
|
||
|
||
做实验的初衷是我们每个人都希望通过一些改变从而能够提高一些东西，并勇敢地通过实验来验证我们的想法。对于 DevOps 团队来说，失败无论对团队还是个人来说都是经验，所要不要担心失败。团队中的每个成员不断学习、共享，也会不断提升其所在团队与组织的水平。
|
||
|
||
随着系统变得越来越琐碎，我们更需要将注意力发在特殊的点上：上面提到的两条原则主要关注的是流程的目前全貌，而持续的学习则是关注的则是整个项目、人员、团队、组织的未来。它不仅对流程产生了影响，还对流程中的每个人产生影响。
|
||
|
||
> "无风险的实验让我们能够不懈的改进我们的工作，但也要求我们使用之前没有用过的工作方式"
|
||
|
||
–Gene Kim, et al., [凤凰计划：让你了解 IT、DevOps以及如何取得商业成功][7], IT 革命, 2013
|
||
|
||
### 容器技术给我们 DevOps 上的启迪
|
||
|
||
学习如何有效地使用容器可以学习DevOps的三条原则：工作流，反馈以及持续实验和学习。从整体上看应用程序和基础设施，而不是对容器外的东西置若罔闻，教会我们考虑到系统的所有部分，了解其上游和下游影响，打破孤岛，并作为一个团队工作，以提高全局性能和深度
|
||
了解整个系统。通过努力提供及时准确的反馈，我们可以在组织内部创建有效的反馈模式，以便在问题发生影响之前发现问题。
|
||
最后，提供一个安全的环境来尝试新的想法并从中学习，教会我们创造一种文化，在这种文化中，失败一方面促进了我们知识的增长，另一方面通过有根据的猜测，可以为复杂的问题带来新的、优雅的解决方案。
|
||
|
||
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://opensource.com/article/18/9/containers-can-teach-us-devops
|
||
|
||
作者：[Chris Hermansen][a]
|
||
选题：[lujun9972](https://github.com/lujun9972)
|
||
译者：[译者ID](https://github.com/littleji)
|
||
校对：[校对者ID](https://github.com/校对者ID)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]: https://opensource.com/users/clhermansen
|
||
[1]: https://itrevolution.com/the-three-ways-principles-underpinning-devops/
|
||
[2]: https://en.wikipedia.org/wiki/The_Jetsons
|
||
[3]: http://itrevolution.com/the-three-ways-principles-underpinning-devops
|
||
[4]: https://prometheus.io/
|
||
[5]: https://opensource.com/article/18/9/prometheus-operational-advantage
|
||
[6]: https://www.youtube.com/watch?v=8NPzLBSBzPI
|
||
[7]: https://itrevolution.com/book/the-phoenix-project/
|