mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-24 02:20:09 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
14a56d0173
@ -3,18 +3,17 @@
|
||||
|
||||
为开源项目作贡献最好的方式是为它减少代码，我们应致力于写出让新手程序员无需注释就容易理解的代码，让维护者也无需花费太多精力就能着手维护。
|
||||
|
||||
在学生时代，我们会更多地用复杂巧妙的技术去挑战新的难题。首先我们会学习循环，然后是函数啊，类啊，等等。 当我们到达一定高的程度，能用更高级的技术写更长的程序，我们会因此受到称赞。 此刻我们发现老司机们用 monads 而新手们用 loop 作循环。
|
||||
在学生时代，我们会更多地用复杂巧妙的技术去挑战新的难题。首先我们会学习循环，然后是函数啊，类啊，等等。当我们到达一定高的程度，能用更高级的技术写更长的程序，我们会因此受到称赞。此刻我们发现老司机们用 monads 而新手们用 loop 作循环。
|
||||
|
||||
之后我们毕业找了工作，或者和他人合作开源项目。我们用在学校里学到的各种炫技寻求并骄傲地给出解决方案的代码实现。
|
||||
|
||||
哈哈， 我能扩展这个项目，并实现某牛X功能啦， 我这里能用继承啦， 我太聪明啦！
|
||||
*哈哈，我能扩展这个项目，并实现某牛 X 功能啦，我这里能用继承啦，我太聪明啦！*
|
||||
|
||||
我们实现了某个小的功能，并以充分的理由觉得自己做到了。现实项目中的编程却不是针对某某部分的功能而言。以我个人的经验而言，以前我很开心的去写代码，并骄傲地向世界展示我所知道的事情。 有例为证，作为对某种编程技术的偏爱，这是和另一段元语言代码混合在一起的 [一行 algebra 代码][1]，我注意到多年以后一直没人愿意碰它。
|
||||
我们实现了某个小的功能，并以充分的理由觉得自己做到了。现实项目中的编程却不是针对某某部分的功能而言。以我个人的经验而言，以前我很开心的去写代码，并骄傲地向世界展示我所知道的事情。有例为证，作为对某种编程技术的偏爱，这是用另一种元编程语言构建的一个 [线性代数语言][1]，注意，这么多年以来一直没人愿意碰它。
|
||||
|
||||
在维护了更多的代码后，我的观点发生了变化。
|
||||
|
||||
1. 我们不应去刻意探求如何构建软件。 软件是我们为解决问题所付出的代价， 那才是我们真实的目的。 我们应努力为了解决问题而构建较小的软件。
|
||||
|
||||
1. 我们不应去刻意探求如何构建软件。软件是我们为解决问题所付出的代价，那才是我们真实的目的。我们应努力为了解决问题而构建较小的软件。
|
||||
2. 我们应使用尽可能简单的技术，那么更多的人就越可能会使用，并且无需理解我们所知的高级技术就能扩展软件的功能。当然，在我们不知道如何使用简单技术去实现时，我们也可以使用高级技术。
|
||||
|
||||
所有的这些例子都不是听来的故事。我遇到的大部分人会认同某些部分，但不知为什么，当我们向一个新项目贡献代码时又会忘掉这个初衷。直觉里用复杂技术去构建的念头往往会占据上风。
|
||||
@ -23,7 +22,7 @@
|
||||
|
||||
你写的每行代码都要花费人力。写代码当然是需要时间的，也许你会认为只是你个人在奉献，然而这些代码在被审阅的时候也需要花时间理解，对于未来维护和开发人员来说，他们在维护和修改代码时同样要花费时间。否则他们完全可以用这时间出去晒晒太阳，或者陪伴家人。
|
||||
|
||||
所以，当你向某个项目贡献代码时，请心怀谦恭。就像是，你正和你的家人进餐时，餐桌上却没有足够的食物，你索取你所需的部分，别人对你的自我约束将肃然起敬。以更少的代码去解决问题是很难的，你肩负重任的同时自然减轻了别人的重负。
|
||||
所以，当你向某个项目贡献代码时，请心怀谦恭。就像是，你正和你的家人进餐时，餐桌上却没有足够的食物，你只索取你所需的部分，别人对你的自我约束将肃然起敬。以更少的代码去解决问题是很难的，你肩负重任的同时自然减轻了别人的重负。
|
||||
|
||||
### 技术越复杂越难维护
|
||||
|
||||
@ -31,13 +30,13 @@
|
||||
|
||||
而在现实中，和团队去解决问题时，情况发生了逆转。现在，我们致力于尽可能使用简单的代码去解决问题。简单方式解决问题使新手程序员能够以此扩展并解决其他问题。简单的代码让别人容易上手，效果立竿见影。我们藉以只用简单的技术去解决难题，从而展示自己的价值。
|
||||
|
||||
看， 我用循环替代了递归函数并且一样达到了我们的需求。 当然我明白这是不够聪明的做法， 不过我注意到新手同事之前在这里会遇上麻烦，我觉得这改变将有所帮助吧。
|
||||
*看，我用循环替代了递归函数并且一样达到了我们的需求。当然我明白这是不够聪明的做法，不过我注意到新手同事在这里会遇上麻烦，我觉得这种改变将有所帮助吧。*
|
||||
|
||||
如果你是个好的程序员，你不需要证明你知道很多炫技。相应的，你可以通过用一个简单的方法解决一个问题来显示你的价值，并激发你的团队在未来的时间里去完善它。
|
||||
|
||||
### 当然，也请保持节制
|
||||
|
||||
话虽如此， 过于遵循 “用简单的工具去构建” 的教条也会降低生产力。经常地，用递归会比用循环解决问题更简单，用类或 monad 才是正确的途径。还有两种情况另当别论,一是只是只为满足自我而创建的系统，或者是别人毫无构建经验的系统。
|
||||
话虽如此，过于遵循 “用简单的工具去构建” 的教条也会降低生产力。通常用递归会比用循环解决问题更简单，用类或 monad 才是正确的途径。还有两种情况另当别论，一是只是只为满足自我而创建的系统，或者是别人毫无构建经验的系统。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
@ -46,7 +45,7 @@ via: http://matthewrocklin.com/blog/work/2018/01/27/write-dumb-code
|
||||
|
||||
作者：[Matthew Rocklin][a]
|
||||
译者：[plutoid](https://github.com/plutoid)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,88 +1,81 @@
|
||||
容器技术对指导我们 DevOps 的一些启发
|
||||
容器技术对 DevOps 的一些启发
|
||||
======
|
||||
|
||||
容器技术的使用支撑了目前 DevOps 三大主要实践：流水线，及时反馈，持续实验与学习以改进。
|
||||
容器技术的使用支撑了目前 DevOps 三大主要实践：工作流，及时反馈，持续学习。
|
||||
|
||||
|
||||
|
||||
容器技术与 DevOps 二者在发展的过程中是互相促进的关系。得益于 DevOps 的设计理念愈发先进，容器生态系统在设计上与组件选择上也有相应发展。同时，由于容器技术在生产环境中的使用，反过来也促进了 DevOps 三大主要实践：[支撑DevOps的三个实践][1].
|
||||
|
||||
有人说容器技术与 DevOps 二者在发展的过程中是互相促进的关系。得益于 DevOps 设计理念的流行，容器生态系统在设计上与组件选择上也有相应发展。同时，由于容器技术在生产环境中的使用，反过来也促进了 DevOps 三大主要实践：[支撑 DevOps 的三个实践][1]。
|
||||
|
||||
### 工作流
|
||||
|
||||
**容器中的工作流**
|
||||
#### 容器中的工作流
|
||||
|
||||
每个容器都可以看成一个独立的封闭仓库，当你置身其中，不需要管外部的系统环境、集群环境、以及其他基础设施，不管你在里面如何折腾，只要对外提供正常的功能就好。一般来说，容器内运行的应用，一般作为整个应用系统架构的一部分：比如 web API，数据库，任务执行，缓存系统，垃圾回收器等。运维团队一般会限制容器的资源使用，并在此基础上建立完善的容器性能监控服务，从而降低其对基础设施或者下游其他用户的影响。
|
||||
每个容器都可以看成一个独立的运行环境，对于容器内部，不需要考虑外部的宿主环境、集群环境、以及其它基础设施。在容器内部，每个功能看起来都是以传统的方式运行。从外部来看，容器内运行的应用一般作为整个应用系统架构的一部分：比如 web API，web app 用户界面，数据库，任务执行，缓存系统，垃圾回收等。运维团队一般会限制容器的资源使用，并在此基础上建立完善的容器性能监控服务，从而降低其对基础设施或者下游其他用户的影响。
|
||||
|
||||
**现实中的工作流**
|
||||
#### 现实中的工作流
|
||||
|
||||
那些跟“容器”一样独立工作的团队，也可以借鉴这种限制容器占用资源的策略。因为无论是在现实生活中的工作流（代码发布、构建基础设施，甚至制造[Spacely’s Sprockets][2]等），还是技术中的工作流（开发、测试、试运行、发布）都使用了这样的线性工作流，一旦某个独立的环节或者工作团队出现了问题，那么整个下游都会受到影响，虽然使用我们这种线性的工作流有效降低了工作耦合性。
|
||||
那些跟“容器”一样业务功能独立的团队，也可以借鉴这种容器思维。因为无论是在现实生活中的工作流（代码发布、构建基础设施，甚至制造 [Spacely’s Sprockets][2] 等），还是技术中的工作流（开发、测试、运维、发布）都使用了这样的线性工作流，一旦某个独立的环节或者工作团队出现了问题，那么整个下游都会受到影响，虽然使用这种线性的工作流有效降低了工作耦合性。
|
||||
|
||||
**DevOps 中的工作流**
|
||||
#### DevOps 中的工作流
|
||||
|
||||
DevOps 中的第一条原则，就是掌控整个执行链路的情况，努力理解系统如何协同工作，并理解其中出现的问题如何对整个过程产生影响。为了提高流程的效率，团队需要持续不断的找到系统中可能存在的性能浪费以及忽视的点，并最终修复它们。
|
||||
DevOps 中的第一条原则，就是掌控整个执行链路的情况，努力理解系统如何协同工作，并理解其中出现的问题如何对整个过程产生影响。为了提高流程的效率，团队需要持续不断的找到系统中可能存在的性能浪费以及问题，并最终修复它们。
|
||||
|
||||
> 践行这样的工作流后，可以避免将一个已知缺陷带到工作流的下游，避免局部优化导致可能的全局性能下降，要不断探索如何优化工作流，持续加深对于系统的理解。
|
||||
|
||||
> “践行这样的工作流后，可以避免传递一个已知的缺陷到工作流的下游，避免产生一个可能会导致全局性能退化的局部优化，持续优化工作流的性能，持续加深对于系统的理解”
|
||||
|
||||
–Gene Kim, [支撑DevOps的三个实践][3], IT 革命, 2017.4.25
|
||||
—— Gene Kim，[支撑 DevOps 的三个实践][3]，IT 革命，2017.4.25
|
||||
|
||||
### 反馈
|
||||
|
||||
**容器中的反馈**
|
||||
#### 容器中的反馈
|
||||
|
||||
除了限制容器的资源，很多产品还提供了监控和通知容器性能指标的功能，从而了解当容器工作不正常时，容器内部处于什么样的工作状态。比如 目前[流行的][5][Prometheus][4]，可以用来从容器和容器集群中收集相应的性能指标数据。容器本身特别适用于分隔应用系统，以及打包代码和其运行环境，但也同时带来不透明的特性，这时从中快速的收集信息，从而解决发生在其内部出现的问题，就显得尤为重要了。
|
||||
除了限制容器的资源，很多产品还提供了监控和通知容器性能指标的功能，从而了解当容器工作不正常时，容器内部处于什么样的状态。比如目前[流行的][5] [Prometheus][4]，可以用来收集容器和容器集群中相应的性能指标数据。容器本身特别适用于分隔应用系统，以及打包代码和其运行环境，但同时也带来了不透明的特性，这时，从中快速收集信息来解决其内部出现的问题就显得尤为重要了。
|
||||
|
||||
**现实中的反馈**
|
||||
#### 现实中的反馈
|
||||
|
||||
在现实中，从始至终同样也需要反馈。一个高效的处理流程中，及时的反馈能够快速的定位事情发生的时间。反馈的关键词是“快速”和“相关”。当一个团队处理大量不相关的事件时，那些真正需要快速反馈的重要信息，很容易就被忽视掉，并向下游传递形成更严重的问题。想象下[如果露西和埃塞尔][6]能够很快的意识到：传送带太快了，那么制作出的巧克力可能就没什么问题了（尽管这样就不太有趣了）。
|
||||
在现实中，从始至终同样也需要反馈。一个高效的处理流程中，及时的反馈能够快速地定位事情发生的时间。反馈的关键词是“快速”和“相关”。当一个团队被淹没在大量不相关的事件时，那些真正需要快速反馈的重要信息很容易被忽视掉，并向下游传递形成更严重的问题。想象下[如果露西和埃塞尔][6]能够很快地意识到：传送带太快了，那么制作出的巧克力可能就没什么问题了（尽管这样就不那么搞笑了）。
|
||||
|
||||
**DevOps and feedback**
|
||||
#### DevOps 中的反馈
|
||||
|
||||
DevOps 中的第二条原则，就是快速收集所有的相关有用信息，这样在出现的问题影响到其他开发进程之前，就可以被识别出。DevOps 团队应该努力去“优化下游“，以及快速解决那些可能会影响到之后团队的问题。同工作流一样，反馈也是一个持续的过程，目标是快速的获得重要的信息以及当问题出现后能够及时的响应。
|
||||
DevOps 中的第二条原则，就是快速收集所有相关的有用信息，这样在问题影响到其它开发流程之前就可以被识别出。DevOps 团队应该努力去“优化下游”，以及快速解决那些可能会影响到之后团队的问题。同工作流一样，反馈也是一个持续的过程，目标是快速的获得重要的信息以及当问题出现后能够及时地响应。
|
||||
|
||||
> "快速的反馈对于提高技术的质量、可用性、安全性至关重要。"
|
||||
> 快速的反馈对于提高技术的质量、可用性、安全性至关重要。
|
||||
|
||||
–Gene Kim, et al., DevOps 手册：如何在技术组织中创造世界级的敏捷性，可靠性和安全性, IT 革命, 2016
|
||||
—— Gene Kim 及其他，DevOps 手册：如何在技术组织中创造世界级的敏捷性，可靠性和安全性，IT 革命，2016
|
||||
|
||||
### 持续实验与学习
|
||||
### 持续学习
|
||||
|
||||
**容器中的持续实验与学习**
|
||||
#### 容器中的持续学习
|
||||
|
||||
如何让”持续的实验与学习“更具操作性是一个不小的挑战。容器让我们的开发工程师和运营团队，在不需要掌握太多边缘或难以理解的东西情况下，依然可以安全地进行本地和生产环境的测试，这在之前是难以做到的。即便是一些激进的实验，容器技术仍然让我们轻松地进行版本控制、记录、分享。
|
||||
践行第三条原则“持续学习”是一个不小的挑战。在不需要掌握太多边缘的或难以理解的东西的情况下，容器技术让我们的开发工程师和运营团队依然可以安全地进行本地和生产环境的测试，这在之前是难以做到的。即便是一些激进的实验，容器技术仍然让我们轻松地进行版本控制、记录和分享。
|
||||
|
||||
**现实中的持续实验与学习**
|
||||
#### 现实中的持续学习
|
||||
|
||||
举个我自己的例子：多年前，作为一个年轻、初出茅庐的系统管理员（仅仅工作三周），我被要求对一个运行某个大学核心IT部门网站的Apache虚拟主机进行更改。由于没有易于使用的测试环境，我直接在生产的站点上进行了配置修改，当时觉得配置没问题就发布了，几分钟后，我隔壁无意中听到了同事说：
|
||||
举个我自己的例子：多年前，作为一个年轻、初出茅庐的系统管理员（仅仅工作三周），我被安排对一个运行着某个大学核心 IT 部门网站的 Apache 虚拟主机配置进行更改。由于没有方便的测试环境，我直接在生产站点上修改配置，当时觉得配置没问题就发布了，几分钟后，我无意中听到了隔壁同事说：
|
||||
|
||||
”等会，网站挂了？“
|
||||
“等会，网站挂了？”
|
||||
|
||||
“没错，怎么回事？”
|
||||
|
||||
很多人蒙圈了……
|
||||
|
||||
在被嘲讽之后（真实的嘲讽），我一头扎在工作台上，赶紧撤销我之前的更改。当天下午晚些时候，部门主管 - 我老板的老板的老板来到我的工位上，问发生了什么事。
|
||||
“别担心，”她告诉我。“我们不会生你的气，这是一个错误，现在你已经学会了。“
|
||||
在被嘲讽之后（真实的嘲讽），我一头扎在工作台上，赶紧撤销我之前的更改。当天下午晚些时候，部门主管 —— 我老板的老板的老板 —— 来到我的工位询问发生了什么事。“别担心，”她告诉我。“我们不会责怪你，这是一个错误，现在你已经学会了。”
|
||||
|
||||
而在容器中，这种情形很容易的进行测试，并且也很容易在部署生产环境之前，被那些经验老道的团队成员发现。
|
||||
而在容器中，这种情形在我的笔记本上就很容易测试了，并且也很容易在部署生产环境之前，被那些经验老道的团队成员发现。
|
||||
|
||||
**DevOps 中的持续实验与学习**
|
||||
#### DevOps 中的持续学习
|
||||
|
||||
做实验的初衷是我们每个人都希望通过一些改变从而能够提高一些东西，并勇敢地通过实验来验证我们的想法。对于 DevOps 团队来说，失败无论对团队还是个人来说都是经验，所要不要担心失败。团队中的每个成员不断学习、共享，也会不断提升其所在团队与组织的水平。
|
||||
持续学习文化的一部分是我们每个人都希望通过一些改变从而能够提高一些东西，并勇敢地通过实验来验证我们的想法。对于 DevOps 团队来说，失败无论对团队还是个人来说都是成长而不是惩罚，所以不要畏惧失败。团队中的每个成员不断学习、共享，也会不断提升其所在团队与组织的水平。
|
||||
|
||||
随着系统变得越来越琐碎，我们更需要将注意力发在特殊的点上：上面提到的两条原则主要关注的是流程的目前全貌，而持续的学习则是关注的则是整个项目、人员、团队、组织的未来。它不仅对流程产生了影响，还对流程中的每个人产生影响。
|
||||
随着系统越来越被细分，我们更需要将注意力集中在具体的点上：上面提到的两条原则主要关注整体流程，而持续学习关注的则是整个项目、人员、团队、组织的未来。它不仅对流程产生了影响，还对流程中的每个人产生影响。
|
||||
|
||||
> "无风险的实验让我们能够不懈的改进我们的工作，但也要求我们使用之前没有用过的工作方式"
|
||||
> 实验和冒险让我们能够不懈地改进我们的工作，但也要求我们尝试之前未用过的工作方式。
|
||||
|
||||
–Gene Kim, et al., [凤凰计划：让你了解 IT、DevOps以及如何取得商业成功][7], IT 革命, 2013
|
||||
|
||||
### 容器技术给我们 DevOps 上的启迪
|
||||
|
||||
学习如何有效地使用容器可以学习DevOps的三条原则：工作流，反馈以及持续实验和学习。从整体上看应用程序和基础设施，而不是对容器外的东西置若罔闻，教会我们考虑到系统的所有部分，了解其上游和下游影响，打破孤岛，并作为一个团队工作，以提高全局性能和深度
|
||||
了解整个系统。通过努力提供及时准确的反馈，我们可以在组织内部创建有效的反馈模式，以便在问题发生影响之前发现问题。
|
||||
最后，提供一个安全的环境来尝试新的想法并从中学习，教会我们创造一种文化，在这种文化中，失败一方面促进了我们知识的增长，另一方面通过有根据的猜测，可以为复杂的问题带来新的、优雅的解决方案。
|
||||
—— Gene Kim 及其他，[凤凰计划：让你了解 IT、DevOps 以及如何取得商业成功][7]，IT 革命，2013
|
||||
|
||||
### 容器技术带给 DevOps 的启迪
|
||||
|
||||
有效地应用容器技术可以学习 DevOps 的三条原则：工作流，反馈以及持续学习。从整体上看应用程序和基础设施，而不是对容器外的东西置若罔闻，教会我们考虑到系统的所有部分，了解其上游和下游影响，打破隔阂，并作为一个团队工作，以提升整体表现和深度了解整个系统。通过努力提供及时准确的反馈，我们可以在组织内部创建有效的反馈机制，以便在问题发生影响之前发现问题。最后，提供一个安全的环境来尝试新的想法并从中学习，教会我们创造一种文化，在这种文化中，失败一方面促进了我们知识的增长，另一方面通过有根据的猜测，可以为复杂的问题带来新的、优雅的解决方案。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -90,8 +83,8 @@ 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)
|
||||
译者：[littleji](https://github.com/littleji)
|
||||
校对：[pityonline](https://github.com/pityonline)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user