mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
59 lines
7.6 KiB
Markdown
59 lines
7.6 KiB
Markdown
|
DevOps 将让你失业？
|
|||
|
|
======
|
|||
|
|
|
|||
|
|
>你是否担心工作中自动化将代替人？可能是对的，但是这并不是件坏事。
|
|||
|
|
|
|||
|
|
|
|||
|
|
>Image by : opensource.com
|
|||
|
|
|
|||
|
|
这是一个很正常的担心：DevOps 最终会让你失业？毕竟，DevOps 意味着开发人员做运营，对吗？DevOps 是自动化的。如果我的工作都自动化了，我去做什么？实行持续分发和容器化意味着运营已经过时了吗？对于 DevOps 来说，所有的东西都是代码：基础设施是代码、测试是代码、这个和那个都是代码。如果我没有这些技能怎么办？
|
|||
|
|
|
|||
|
|
[DevOps][1] 是一个即将到来的变化，将颠覆这一领域，狂热的拥挤者们正在谈论，如何使用 [三种方法][2] 去改变世界 —— 即 DevOps 的三大基础 —— 去推翻一个旧的世界。它是势不可档的。那么，问题来了 —— DevOps 将会让我失业吗？
|
|||
|
|
|
|||
|
|
### 第一个担心：再也不需要我了
|
|||
|
|
|
|||
|
|
由于开发者来管理应用程序的整个生命周期，接受 DevOps 的理念很容易。容器化可能是影响这一想法的重要因素。当容器化在各种场景下铺开之后，它们被吹嘘成开发者构建、测试、和部署他们代码的一站式解决方案。DevOps 对于运营、测试、以及 QA 团队来说，有什么作用呢？
|
|||
|
|
|
|||
|
|
这源于对 DevOps 原则的误解。DevOps 的第一原则，或者第一方法是，_系统思考_ ，或者强调整体管理方法和了解应用程序或服务的整个生命周期。这并不意味着应用程序的开发者将学习和管理整个过程。相反，是拥有各个专业和技能的人共同合作，以确保成功。让开发者对这一过程完全负责的作法，几乎是将开发者置于使用者的对立面—— 本质上就是 “将鸡蛋放在了一个篮子里”。
|
|||
|
|
|
|||
|
|
在 DevOps 中有一个为你保留的专门职位。就像将一个受过传统教育的、拥有线性回归和二分查找知识的软件工程师，被用去写一些 Ansible playbooks 和 Docker 文件，这是一种浪费。而对于那些拥有高级技能，知道如何保护一个系统和优化数据库执行的系统管理员，被浪费在写一些 CSS 和设计用户流这样的工作上。写代码、做测试、和维护应用程序的高效团队一般是跨学科、跨职能的、拥有不同专业技术和背景的人组成的混编团队。
|
|||
|
|
|
|||
|
|
### 第二个担心：我的工作将被自动化
|
|||
|
|
|
|||
|
|
或许是，或许不是，DevOps 可能在有时候是自动化的同义词。当自动化构建、测试、部署、监视、以及提醒等事项，已经占据了整个应用程序生命周期管理的时候，还会给我们剩下什么工作呢？这种对自动化的关注可能与第二个方法有关：_放大反馈循环_。DevOps 的第二个方法是在团队和部署的应用程序之间，采用相反的方向优先处理快速反馈 —— 从监视和维护部署、测试、开发、等等，通过强调，使反馈更加重要并且可操作。虽然这第二种方式与自动化并不是特别相关，许多自动化工具团队在它们的部署流水线中使用，以促进快速提醒和快速行动，或者基于对使用者的支持业务中产生的反馈来改进。传统的做法是靠人来完成的，这就可以理解为什么自动化可能会导致未来一些人失业的焦虑了。
|
|||
|
|
|
|||
|
|
自动化只是一个工具，它并不能代替人。聪明的人使用它来做一些重复的工作，不去开发智力和创造性的财富，而是去按红色的 “George Jetson” 按钮是一种极大的浪费。让每天工作中的苦活自动化，意味着有更多的时间去解决真正的问题和即将到来的创新的解决方案。人类需要解决更多的 “怎么做和为什么” 问题，而计算机只能处理 “复制和粘贴”。
|
|||
|
|
|
|||
|
|
并不会仅限于在可重复的、可预见的事情上进行自动化，自动化让团队有更多的时间和精力去专注于本领域中更高级别的任务上。监视团队不再花费他们的时间去配置报警或者管理传统的配置，它们可能专注于预测可能的报警、相关性统计、以及设计可能的预案。系统管理员从计划补丁或服务器配置中解放出来，可以花费更多的时间专注于整体管理、性能、和可伸缩性。与工厂车间和装配线上完全没有人的景像不同，DevOps 中的自动化任务，意味着人更多关注于创造性的、有更高价值的任务，而不是一些重复的、让人麻木的苦差事。
|
|||
|
|
|
|||
|
|
### 第三个担心：我没有这些技能怎么办
|
|||
|
|
|
|||
|
|
"我怎么去继续做这些事情？我不懂如何自动化。现在所有的工作都是代码 —— 我不是开发人员，我不会做 DevOps 中写代码的工作“，第三个担心是一种不自信的担心。由于文化的改变，是的，团队将也会要求随之改变，一些人可能担心，他们缺乏继续做他们工作的技能。
|
|||
|
|
|
|||
|
|
然而，大多数人或许已经比他们所想的更接近。Dockerfile 是什么，或者像 Puppet 或 Ansible 配置管理是什么，但是环境即代码，系统管理员已经写了 shell 脚本和 Python 程序去处理他们重复的任务。学习更多的知识并使用已有的工具处理他们的更多问题 —— 编排、部署、维护即代码 —— 尤其是当从繁重的手动任务中解放出来，专注于成长时。
|
|||
|
|
|
|||
|
|
在 DevOps 的使用者中去回答这第三个担心，第三个方法是：_一种不断实验和学习的文化_。尝试、失败、并从错误中吸取教训而不是责怪它们的能力，是设计出更有创意的解决方案的重要因素。第三个方法是为前两个方法授权—— 允许快速检测和修复问题，并且开发人员可以自由地尝试和学习，其它的团队也是如此。从未使用过配置管理或者写过自动供给基础设施程序的运营团队也要自由尝试并学习。测试和 QA 团队也要自由实现新测试流水线，并且自动批准和发布新流程。在一个拥抱学习和成长的文化中，每个人都可以自由地获取他们需要的技术，去享受工作带来的成功和喜悦。
|
|||
|
|
|
|||
|
|
### 结束语
|
|||
|
|
|
|||
|
|
在一个行业中，任何可能引起混乱的实践或变化都会产生担心和不确定，DevOps 也不例外。对自己工作的担心是对成百上千的文章和演讲的合理回应，其中列举了无数的实践和技术，而这些实践和技术正致力于授权开发者对行业的各个方面承担职责。
|
|||
|
|
|
|||
|
|
然而，事实上，DevOps 是 "[一个跨学科的沟通实践，致力于研究构建、进化、和运营快速变化的弹性系统][3]"。 DevOps 意味着终结 ”筒仓“，但并不专业化。它是受委托去做苦差事的自动化系统，解放你，让你去做人类更擅长做的事：思考和想像。并且，如果你愿意去学习和成长，它将不会终结你解决新的、挑战性的问题的机会。
|
|||
|
|
|
|||
|
|
DevOps 会让你失业吗？会的，但它同时给你提供了更好的工作。
|
|||
|
|
|
|||
|
|
--------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
via: https://opensource.com/article/17/12/will-devops-steal-my-job
|
|||
|
|
|
|||
|
|
作者：[Chris Collins][a]
|
|||
|
|
译者：[qhwdw](https://github.com/qhwdw)
|
|||
|
|
校对：[校对者ID](https://github.com/校对者ID)
|
|||
|
|
|
|||
|
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|||
|
|
|
|||
|
|
[a]:https://opensource.com/users/clcollins
|
|||
|
|
[1]:https://opensource.com/resources/devops
|
|||
|
|
[2]:http://itrevolution.com/the-three-ways-principles-underpinning-devops/
|
|||
|
|
[3]:https://theagileadmin.com/what-is-devops/
|