mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
99 lines
8.5 KiB
Markdown
99 lines
8.5 KiB
Markdown
容器技术对 DevOps 的一些启发
|
||
======
|
||
|
||
> 容器技术的使用支撑了目前 DevOps 三大主要实践：工作流、及时反馈、持续学习。
|
||
|
||
|
||
|
||
有人说容器技术与 DevOps 二者在发展的过程中是互相促进的关系。得益于 DevOps 设计理念的流行，容器生态系统在设计上与组件选择上也有相应发展。同时，由于容器技术在生产环境中的使用，反过来也促进了 DevOps 三大主要实践：[支撑 DevOps 的三个实践][1]。
|
||
|
||
### 工作流
|
||
|
||
#### 容器中的工作流
|
||
|
||
每个容器都可以看成一个独立的运行环境，对于容器内部，不需要考虑外部的宿主环境、集群环境，以及其它基础设施。在容器内部，每个功能看起来都是以传统的方式运行。从外部来看，容器内运行的应用一般作为整个应用系统架构的一部分：比如 web API、web app 用户界面、数据库、任务执行、缓存系统、垃圾回收等。运维团队一般会限制容器的资源使用，并在此基础上建立完善的容器性能监控服务，从而降低其对基础设施或者下游其他用户的影响。
|
||
|
||
#### 现实中的工作流
|
||
|
||
那些跟“容器”一样业务功能独立的团队，也可以借鉴这种容器思维。因为无论是在现实生活中的工作流（代码发布、构建基础设施，甚至制造 [《杰森一家》中的斯贝斯利太空飞轮][2] 等），还是技术中的工作流（开发、测试、运维、发布）都使用了这样的线性工作流，一旦某个独立的环节或者工作团队出现了问题，那么整个下游都会受到影响，虽然使用这种线性的工作流有效降低了工作耦合性。
|
||
|
||
#### DevOps 中的工作流
|
||
|
||
DevOps 中的第一条原则，就是掌控整个执行链路的情况，努力理解系统如何协同工作，并理解其中出现的问题如何对整个过程产生影响。为了提高流程的效率，团队需要持续不断的找到系统中可能存在的性能浪费以及问题，并最终修复它们。
|
||
|
||
> 践行这样的工作流后，可以避免将一个已知缺陷带到工作流的下游，避免局部优化导致可能的全局性能下降，要不断探索如何优化工作流，持续加深对于系统的理解。
|
||
|
||
> —— Gene Kim，《[支撑 DevOps 的三个实践][3]》，IT 革命，2017.4.25
|
||
|
||
### 反馈
|
||
|
||
#### 容器中的反馈
|
||
|
||
除了限制容器的资源，很多产品还提供了监控和通知容器性能指标的功能，从而了解当容器工作不正常时，容器内部处于什么样的状态。比如目前[流行的][5] [Prometheus][4]，可以用来收集容器和容器集群中相应的性能指标数据。容器本身特别适用于分隔应用系统，以及打包代码和其运行环境，但同时也带来了不透明的特性，这时，从中快速收集信息来解决其内部出现的问题就显得尤为重要了。
|
||
|
||
#### 现实中的反馈
|
||
|
||
在现实中，从始至终同样也需要反馈。一个高效的处理流程中，及时的反馈能够快速地定位事情发生的时间。反馈的关键词是“快速”和“相关”。当一个团队被淹没在大量不相关的事件时，那些真正需要快速反馈的重要信息很容易被忽视掉，并向下游传递形成更严重的问题。想象下[如果露西和埃塞尔][6]能够很快地意识到：传送带太快了，那么制作出的巧克力可能就没什么问题了（尽管这样就不那么搞笑了）。（LCTT 译注：露西和埃塞尔是上世纪 50 年代的著名黑白情景喜剧《我爱露西》中的主角）
|
||
|
||
#### DevOps 中的反馈
|
||
|
||
DevOps 中的第二条原则，就是快速收集所有相关的有用信息，这样在问题影响到其它开发流程之前就可以被识别出。DevOps 团队应该努力去“优化下游”，以及快速解决那些可能会影响到之后团队的问题。同工作流一样，反馈也是一个持续的过程，目标是快速的获得重要的信息以及当问题出现后能够及时地响应。
|
||
|
||
> 快速的反馈对于提高技术的质量、可用性、安全性至关重要。
|
||
|
||
> —— Gene Kim 等人，《DevOps 手册：如何在技术组织中创造世界级的敏捷性，可靠性和安全性》，IT 革命，2016
|
||
|
||
### 持续学习
|
||
|
||
#### 容器中的持续学习
|
||
|
||
践行第三条原则“持续学习”是一个不小的挑战。在不需要掌握太多边缘的或难以理解的东西的情况下，容器技术让我们的开发工程师和运营团队依然可以安全地进行本地和生产环境的测试，这在之前是难以做到的。即便是一些激进的实验，容器技术仍然让我们轻松地进行版本控制、记录和分享。
|
||
|
||
#### 现实中的持续学习
|
||
|
||
举个我自己的例子：多年前，作为一个年轻、初出茅庐的系统管理员（仅仅工作三周），我被安排对一个运行着某个大学核心 IT 部门网站的 Apache 虚拟主机配置进行更改。由于没有方便的测试环境，我直接在生产站点上修改配置，当时觉得配置没问题就发布了，几分钟后，我无意中听到了隔壁同事说：
|
||
|
||
“等会，网站挂了？”
|
||
|
||
“没错，怎么回事？”
|
||
|
||
很多人蒙圈了……
|
||
|
||
在被嘲讽之后（真实的嘲讽），我一头扎在工作台上，赶紧撤销我之前的更改。当天下午晚些时候，部门主管 —— 我老板的老板的老板 —— 来到我的工位询问发生了什么事。“别担心，”她告诉我。“我们不会责怪你，这是一个错误，现在你已经学会了。”
|
||
|
||
而在容器中，这种情形在我的笔记本上就很容易测试了，并且也很容易在部署生产环境之前，被那些经验老道的团队成员发现。
|
||
|
||
#### DevOps 中的持续学习
|
||
|
||
持续学习文化的一部分是我们每个人都希望通过一些改变从而能够提高一些东西，并勇敢地通过实验来验证我们的想法。对于 DevOps 团队来说，失败无论对团队还是个人来说都是成长而不是惩罚，所以不要畏惧失败。团队中的每个成员不断学习、共享，也会不断提升其所在团队与组织的水平。
|
||
|
||
随着系统越来越被细分，我们更需要将注意力集中在具体的点上：上面提到的两条原则主要关注整体流程，而持续学习关注的则是整个项目、人员、团队、组织的未来。它不仅对流程产生了影响，还对流程中的每个人产生影响。
|
||
|
||
> 实验和冒险让我们能够不懈地改进我们的工作，但也要求我们尝试之前未用过的工作方式。
|
||
|
||
> —— Gene Kim 等人，《[凤凰计划：让你了解 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)
|
||
译者：[littleji](https://github.com/littleji)
|
||
校对：[pityonline](https://github.com/pityonline), [wxy](https://github.com/wxy)
|
||
|
||
本文由 [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/
|