document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

Translated by qhwdw

Browse Source
This commit is contained in:
qhwdw 2018-03-18 20:48:48 +08:00
parent 97b545808b
commit be88d60d90
2 changed files with 58 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
sources/tech/20171213 Will DevOps steal my job-.md
View File

@ -1,59 +0,0 @@
Translating by qhwdw
Will DevOps steal my job?
======
>Are you worried automation will replace people in the workplace? You may be right, but here's why that's not a bad thing.
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/BIZ_question_B.png?itok=f88cyt00)
>Image by : opensource.com
It's a common fear: Will DevOps be the end of my job? After all, DevOps means developers doing operations, right? DevOps is automation. What if I automate myself out of a job? Do continuous delivery and containers mean operations staff are obsolete? DevOps is all about coding: infrastructure-as-code and testing-as-code and this-or-that-as-code. What if I don't have the skill set to be a part of this?
[DevOps][1] is a looming change, disruptive in the field, with seemingly fanatical followers talking about changing the world with the [Three Ways][2]--the three underpinnings of DevOps--and the tearing down of walls. It can all be overwhelming. So what's it going to be--is DevOps going to steal my job?
### The first fear: I'm not needed
As developers managing the entire lifecycle of an application, it's all too easy to get caught up in the idea of DevOps. Containers are probably a big contributing factor to this line of thought. When containers exploded onto the scene, they were touted as a way for developers to build, test, and deploy their code all-in-one. What role does DevOps leave for the operations team, or testing, or QA?
This stems from a misunderstanding of the principles of DevOps. The first principle of DevOps, or the First Way, is _Systems Thinking_ , or placing emphasis on a holistic approach to managing and understanding the whole lifecycle of an application or service. This does not mean that the developers of the application learn and manage the whole process. Rather, it is the collaboration of talented and skilled individuals to ensure success as a whole. To make developers solely responsible for the process is practically the extreme opposite of this tenant--essentially the enshrining of a single silo with the importance of the entire lifecycle.
There is a place for specialization in DevOps. Just as the classically educated software engineer with knowledge of linear regression and binary search is wasted writing Ansible playbooks and Docker files, the highly skilled sysadmin with the knowledge of how to secure a system and optimize database performance is wasted writing CSS and designing user flows. The most effective group to write, test, and maintain an application is a cross-discipline, functional team of people with diverse skill sets and backgrounds.
### The second fear: My job will be automated
Accurate or not, DevOps can sometimes be seen as a synonym for automation. What work is left for operations staff and testing teams when automated builds, testing, deployment, monitoring, and notifications are a huge part of the application lifecycle? This focus on automation can be partially related to the Second Way: _Amplify Feedback Loops_. This second tenant of DevOps deals with prioritizing quick feedback between teams in the opposite direction an application takes to deployment --from monitoring and maintaining to deployment, testing, development, etc., and the emphasis to make the feedback important and actionable. While the Second Way is not specifically related to automation, many of the automation tools teams use within their deployment pipelines facilitate quick notification and quick action, or course-correction based on feedback in support of this tenant. Traditionally done by humans, it is easy to understand why a focus on automation might lead to anxiety about the future of one's job.
Automation is just a tool, not a replacement for people. Smart people trapped doing the same things over and over, pushing the big red George Jetson button are a wasted, untapped wealth of intelligence and creativity. Automation of the drudgery of daily work means more time to spend solving real problems and coming up with creative solutions. Humans are needed to figure out the "how and why;" computers can handle the "copy and paste."
There will be no end of repetitive, predictable things to automate, and automation frees teams to focus on higher-order tasks in their field. Monitoring teams, no longer spending all their time configuring alerts or managing trending configuration, can start to focus on predicting alarms, correlating statistics, and creating proactive solutions. Systems administrators, freed of scheduled patching or server configuration, can spend time focusing on fleet management, performance, and scaling. Unlike the striking images of factory floors and assembly lines totally devoid of humans, automated tasks in the DevOps world mean humans can focus on creative, rewarding tasks instead of mind-numbing drudgery.
### The third fear: I do not have the skillset for this
"How am I going to keep up with this? I don't know how to automate. Everything is code now--do I have to be a developer and write code for a living to work in DevOps?" The third fear is ultimately a fear of self-confidence. As the culture changes, yes, teams will be asked to change along with it, and some may fear they lack the skills to perform what their jobs will become.
Most folks, however, are probably already closer than they think. What is the Dockerfile, or configuration management like Puppet or Ansible, but environment as code? System administrators already write shell scripts and Python programs to handle repetitive tasks for them. It's hardly a stretch to learn a little more and begin using some of the tools already at their disposal to solve more problems--orchestration, deployment, maintenance-as-code--especially when freed from the drudgery of manual tasks to focus on growth.
The answer to this fear lies in the third tenant of DevOps, the Third Way: _A Culture of Continual Experimentation and Learning_. The ability to try and fail and learn from mistakes without blame is a major factor in creating ever-more creative solutions. The Third Way is empowered by the first two ways --allowing for for quick detection of and repair of problems, and just as the developer is free to try and learn, other teams are as well. Operations teams that have never used configuration management or written programs to automate infrastructure provisioning are free to try and learn. Testing and QA teams are free to implement new testing pipelines and automate approval and release processes. In a culture that embraces learning and growing, everyone has the freedom to acquire the skills they need to succeed at and enjoy their job.
### Conclusion
Any disruptive practice or change in an industry can create fear or uncertainty, and DevOps is no exception. A concern for one's job is a reasonable response to the hundreds of articles and presentations enumerating the countless practices and technologies seemingly dedicated to empowering developers to take responsibility for every aspect of the industry.
In truth, however, DevOps is "[a cross-disciplinary community of practice dedicated to the study of building, evolving, and operating rapidly changing resilient systems at scale][3]." DevOps means the end of silos, but not specialization. It is the delegation of drudgery to automated systems, freeing you to do what people do best: think and imagine. And if you're motivated to learn and grow, there will be no end of opportunities to solve new and challenging problems.
Will DevOps take away your job? Yes, but it will give you a better one.
--------------------------------------------------------------------------------
via: https://opensource.com/article/17/12/will-devops-steal-my-job
作者：[Chris Collins][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者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/

58
translated/tech/20171213 Will DevOps steal my job-.md Normal file
View File

@ -0,0 +1,58 @@
DevOps 将让你失业？
======
>你是否担心工作中自动化将代替人？可能是对的，但是这并不是件坏事。
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/BIZ_question_B.png?itok=f88cyt00)
>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/