mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-10 22:21:11 +08:00
【完成翻译】20180928 What containers can teach us about DevOps.md
This commit is contained in:
sd886393
parent
67073384c7
commit
fe84ddf525
@ -1,101 +0,0 @@
|
||||
容器技术对指导我们 DevOps 的一些启发
|
||||
======
|
||||
|
||||
容器技术的使用支撑了目前 DevOps 三大主要实践：流水线，及时反馈，持续实验与学习以改进。
|
||||
|
||||
|
||||
|
||||
容器技术与 DevOps 二者在发展的过程中是互相促进的关系。得益于 DevOps 的设计理念愈发先进，容器生态系统在设计上与组件选择上也有相应发展。同时，由于容器技术在生产环境中的使用，反过来也促进了 DevOps 三大主要实践：[DevOps 三个实践][1].
|
||||
|
||||
|
||||
### 流水线的原则
|
||||
|
||||
**容器流**
|
||||
|
||||
每个容器都可以看成一个独立的封闭仓库，当你置身其中，不需要管外部的系统环境、集群环境、以及其他基础设施。而在容器内部，
|
||||
A container can be seen as a silo, and from inside, it is easy to forget the rest of the system: the host node, the cluster, the underlying infrastructure. Inside the container, it might appear that everything is functioning in an acceptable manner. From the outside perspective, though, the application inside the container is a part of a larger ecosystem of applications that make up a service: the web API, the web app user interface, the database, the workers, and caching services and garbage collectors. Teams put constraints on the container to limit performance impact on infrastructure, and much has been done to provide metrics for measuring container performance because overloaded or slow container workloads have downstream impact on other services or customers.
|
||||
|
||||
**Real-world flow**
|
||||
|
||||
This lesson can be applied to teams functioning in a silo as well. Every process (be it code release, infrastructure creation or even, say, manufacturing of [Spacely’s Sprockets][2]), follows a linear path from conception to realization. In technology, this progress flows from development to testing to operations and release. If a team working alone becomes a bottleneck or introduces a problem, the impact is felt all along the entire pipeline. A defect passed down the line destroys productivity downstream. While the broken process within the scope of the team itself may seem perfectly correct, it has a negative impact on the environment as a whole.
|
||||
|
||||
**DevOps and flow**
|
||||
|
||||
The first way of DevOps, principles of flow, is about approaching the process as a whole, striving to comprehend how the system works together and understanding the impact of issues on the entire process. To increase the efficiency of the process, pain points and waste are identified and removed. This is an ongoing process; teams must continually strive to increase visibility into the process and find and fix trouble spots and waste.
|
||||
|
||||
> “The outcomes of putting the First Way into practice include never passing a known defect to downstream work centers, never allowing local optimization to create global degradation, always seeking to increase flow, and always seeking to achieve a profound understanding of the system (as per Deming).”
|
||||
|
||||
–Gene Kim, [The Three Ways: The Principles Underpinning DevOps][3], IT Revolution, 25 Apr. 2017
|
||||
|
||||
### Principles of feedback
|
||||
|
||||
**Container feedback**
|
||||
|
||||
In addition to limiting containers to prevent impact elsewhere, many products have been created to monitor and trend container metrics in an effort to understand what they are doing and notify when they are misbehaving. [Prometheus][4], for example, is [all the rage][5] for collecting metrics from containers and clusters. Containers are excellent at separating applications and providing a way to ship an environment together with the code, sometimes at the cost of opacity, so much is done to try to provide rapid feedback so issues can be addressed promptly within the silo.
|
||||
|
||||
**Real-world feedback**
|
||||
|
||||
The same is necessary for the flow of the system. From inception to realization, an efficient process quickly provides relevant feedback to identify when there is an issue. The key words here are “quick” and “relevant.” Burying teams in thousands of irrelevant notifications make it difficult or even impossible to notice important events that need immediate action, and receiving even relevant information too late may allow small, easily solved issues to move downstream and become bigger problems. Imagine [if Lucy and Ethel][6] had provided immediate feedback that the conveyor belt was too fast—there would have been no problem with the chocolate production (though that would not have been nearly as funny).
|
||||
|
||||
**DevOps and feedback**
|
||||
|
||||
The Second Way of DevOps, principles of feedback, is all about getting relevant information quickly. With immediate, useful feedback, problems can be identified as they happen and addressed before impact is felt elsewhere in the development process. DevOps teams strive to “optimize for downstream” and immediately move to fix problems that might impact other teams that come after them. As with flow, feedback is a continual process to identify ways to quickly get important data and act on problems as they occur.
|
||||
|
||||
> “Creating fast feedback is critical to achieving quality, reliability, and safety in the technology value stream.”
|
||||
|
||||
–Gene Kim, et al., The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, IT Revolution Press, 2016
|
||||
|
||||
### Principles of continual experimentation and learning
|
||||
|
||||
**Container continual experimentation and learning**
|
||||
|
||||
It is a bit more challenging applying operational learning to the Third Way of DevOps:continual experimentation and learning. Trying to salvage what we can grasp of the very edges of the metaphor, containers make development easy, allowing developers and operations teams to test new code or configurations locally and safely outside of production and incorporate discovered benefits into production in a way that was difficult in the past. Changes can be radical and still version-controlled, documented, and shared quickly and easily.
|
||||
|
||||
**Real-world continual experimentation and learning**
|
||||
|
||||
For example, consider this anecdote from my own experience: Years ago, as a young, inexperienced sysadmin (just three weeks into the job), I was asked to make changes to an Apache virtual host running the website of the central IT department for a university. Without an easy-to-use test environment, I made a configuration change to the production site that I thought would accomplish the task and pushed it out. Within a few minutes, I overheard coworkers in the next cube:
|
||||
|
||||
“Wait, is the website down?”
|
||||
|
||||
“Hrm, yeah, it looks like it. What the heck?”
|
||||
|
||||
There was much eye-rolling involved.
|
||||
|
||||
Mortified (the shame is real, folks), I sunk down as far as I could into my seat and furiously tried to back out the changes I’d introduced. Later that same afternoon, the director of the department—the boss of my boss’s boss—appeared in my cube to talk about what had happened. “Don’t worry,” she told me. “We’re not mad at you. It was a mistake and now you have learned.”
|
||||
|
||||
In the world of containers, this could have been easily changed and tested on my own laptop and the broken configuration identified by more skilled team members long before it ever made it into production.
|
||||
|
||||
**DevOps continual experimentation and learning**
|
||||
|
||||
A real culture of experimentation promotes the individual’s ability to find where a change in the process may be beneficial, and to test that assumption without the fear of retaliation if they fail. For DevOps teams, failure becomes an educational tool that adds to the knowledge of the individual and organization, rather than something to be feared or punished. Individuals in the DevOps team dedicate themselves to continuous learning, which in turn benefits the team and wider organization as that knowledge is shared.
|
||||
|
||||
As the metaphor completely falls apart, focus needs to be given to a specific point: The other two principles may appear at first glance to focus entirely on process, but continual learning is a human task—important for the future of the project, the person, the team, and the organization. It has an impact on the process, but it also has an impact on the individual and other people.
|
||||
|
||||
> “Experimentation and risk-taking are what enable us to relentlessly improve our system of work, which often requires us to do things very differently than how we’ve done it for decades.”
|
||||
|
||||
–Gene Kim, et al., [The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win][7], IT Revolution Press, 2013
|
||||
|
||||
### Containers can teach us DevOps
|
||||
|
||||
Learning to work effectively with containers can help teach DevOps and the Three Ways: principles of flow, principles of feedback, and principles of continuous experimentation and learning. Looking holistically at the application and infrastructure rather than putting on blinders to everything outside the container teaches us to take all parts of the system and understand their upstream and downstream impacts, break out of silos, and work as a team to increase global performance and deep understanding of the entire system. Working to provide timely and accurate feedback teaches us to create effective feedback patterns within our organizations to identify problems before their impact grows. Finally, providing a safe environment to try new ideas and learn from them teaches us to create a culture where failure represents a positive addition to our knowledge and the ability to take big chances with educated guesses can result in new, elegant solutions to complex problems.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/9/containers-can-teach-us-devops
|
||||
|
||||
作者：[Chris Hermansen][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[译者ID](https://github.com/sd886393)
|
||||
校对：[校对者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/
|
||||
@ -0,0 +1,105 @@
|
||||
容器技术对指导我们 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/
|
||||
Loading…
Reference in New Issue
Block a user