[translated]20181211 DevOps is for everyone

This commit is contained in:
alim0x 2018-12-23 22:27:21 +08:00
parent a4d918e096
commit 1fcee3b5fe
No known key found for this signature in database
GPG Key ID: A0DDA620979B21FB
2 changed files with 74 additions and 75 deletions

View File

@ -1,75 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (alim0x)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: subject: (DevOps is for everyone)
[#]: via: (https://opensource.com/article/18/11/how-non-engineer-got-devops)
[#]: author: (Dawn Parych https://opensource.com/users/dawnparzych)
[#]: url: ( )
DevOps is for everyone
======
A non-engineer explains why you don't need to be a developer or an operations person to fall for DevOps.
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/team-game-play-inclusive-diversity-collaboration.png?itok=8sUXV7W1)
I've never held a job as a developer nor in operations—so what am I doing writing an article about [DevOps][1]? I've always been interested in computers and technology. I also have a passion for people, psychology, and helping others. When I first heard about DevOps, the concept piqued my interest, as it seemed to merge many of the things I was interested in, even if I don't write code.
My first computer was a TRS-80, and I loved writing BASIC programs on it. I took the only two computer programming classes my high school offered. A few years later, I started a computer company. I made custom mailing labels, stationery, and built a database to store addresses.
The problem was I didn't enjoy writing code. I wanted to teach and to help people, and I didn't see writing code as an opportunity to do this. Yes, technology can help people and change lives, but writing code didn't spark my passion. I need to feel excited about my work and do something I love.
* The culture, not the code
* The journey, not the result
* Building an environment where everybody can continuously improve
* Communicating and collaborating, not working independently
I found that I love DevOps. To me, DevOps is about:
Ultimately, DevOps is about being part of a community working towards the same goal. DevOps merges psychology, people, and technology. DevOps isn't a job title; it is a philosophy for life and work.
### Finding my people
Almost four years ago, I attended my first [DevOpsDays][2] conference in Seattle. I felt like I had found my people. I felt welcomed and accepted, even though I work in marketing and don't have a computer science degree. I could geek out over psychology and technology.
At DevOpsDays, I learned about the ["Three Ways" of DevOps][3]—flow, feedback, and continuous experimentation and learning—and new (to me) concepts such as Kaizen and Kaikaku. As I learned, I found myself saying things like, "I do this! I didn't know there was a name for this!"
[Kaizen][4] is the practice of continuous improvement and learning. Small, incremental changes over time can yield significant results. I found parallels between this and Carol Dweck's idea of a [growth mindset][5]. People aren't born experts. Becoming skilled at something takes time, practice, and often failure. Recognizing incremental improvement is necessary to make sure we don't give up.
[Kaikaku][6], on the other hand, is the notion that small changes over time sometimes won't work, and you need to make a radical or disruptive change. Quitting a job without having a new one lined up or moving to a new city can be pretty disruptive—yes, I've done both. But these radical changes can reap great rewards. I might not have learned about DevOps if I hadn't quit my job and taken some time off. Once I decided to return to work, I kept hearing about DevOps and started researching it. This led me to attend my first DevOpsDays, where I began to see all my passions come together. Since then, I have presented at five DevOpsDays and regularly write about DevOps topics.
### Putting the Three Ways to work
Change is hard and learning something new can be scary. The Three Ways of DevOps provide a framework for managing change. For example: How is information flowing? What is driving you to make a change? Once you know a change is needed, how do you get feedback about whether the changes you are making are the right changes? How do you know if you're making progress? Feedback is essential and should include both positive and constructive elements. The hard part is making sure the constructive elements don't outweigh the positive.
For me, the third Way—continuous experimentation and learning—is the most important part of DevOps. Having an environment where people are free to experiment and take risks can lead to unexpected outcomes. Sometimes those outcomes are good, sometimes not so good—and that's OK. Creating an environment where it is acceptable if things don't work out encourages people to take risks. We should all strive to continuously experiment and learn something new on a regular basis.
The Three Ways of DevOps provides a method of trying something, getting feedback, and learning from our mistakes. A few years ago, my son told me, "I don't ever want to be the best at something, because then I can't learn from my mistakes." We all make mistakes, and learning from them helps us grow and improve. We aren't willing to make mistakes if our culture doesn't support experimentation and learning.
### Being part of the community
I've worked in technology for over 20 years and often felt like an outsider until I found the DevOps community. If you're like me—passionate about technology but not the engineering or operations side of things—you can still be a part of DevOps, even if you work in sales, marketing, product marketing, technical writing, support, and more. DevOps is for everyone.
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/11/how-non-engineer-got-devops
作者:[Dawn Parych][a]
选题:[lujun9972][b]
译者:[译者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/dawnparzych
[b]: https://github.com/lujun9972
[1]: https://opensource.com/resources/devops
[2]: https://www.devopsdays.org/
[3]: https://itrevolution.com/the-three-ways-principles-underpinning-devops/
[4]: https://en.wikipedia.org/wiki/Kaizen
[5]: https://en.wikipedia.org/wiki/Mindset#Fixed_and_growth
[6]: https://en.wikipedia.org/wiki/Kaikaku

View File

@ -0,0 +1,74 @@
[#]: collector: (lujun9972)
[#]: translator: (alim0x)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: subject: (DevOps is for everyone)
[#]: via: (https://opensource.com/article/18/11/how-non-engineer-got-devops)
[#]: author: (Dawn Parych https://opensource.com/users/dawnparzych)
[#]: url: ( )
所有人的 DevOps
======
让一名非工程师来解释为什么你不必成为一位开发者或运维就能爱上 DevOps。
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/team-game-play-inclusive-diversity-collaboration.png?itok=8sUXV7W1)
我没有过开发或运维的工作——那怎么我在写一篇关于 [DevOps][1] 的文章?我一直都对计算机和技术有兴趣。我还对社群、心理学以及帮助他人充满热情。当我第一次听到 DevOps 时,这个概念激起了我的兴趣,因为它看起来融合了很多我感兴趣的东西,即便我是不写代码的。
我的第一台电脑是 TRS-80我喜欢在上面编写 BASIC 程序。我只上过两门我的高中开设的计算机编程课程。若干年后,我创办了一家计算机公司。我定制邮件标签和信纸,并建立了一个数据库来存储地址。
问题是我并不能从写代码中获得享受。我想要教育和帮助人们,我没法将写代码看作这样的一个机会。是的,技术可以帮助人们并改变生活,但是写代码没有点燃我的热情。我需要对我的工作感到兴奋并做我喜欢的事情。
* 文化,而不是代码
* 过程,而不是结果
* 建立一个所有人可以持续提升的环境
* 沟通与合作,而不是独立工作
我发现我爱 DevOps。对我而言DevOps 指的是:
归根结底DevOps 是指成为社区工作的一部分实现共同的目标。DevOps 融合了心理学、社群、技术。DevOps 不是一个职位名称,它是一种生活和工作的哲学。
### 找到我的社群
快四年前,我在西雅图参加了我的第一个 [DevOps 日][2] 会议。我感觉我找到了我的社群。我觉得受到了欢迎和接受,尽管我从事营销工作而且没有计算机科学文凭。我可以从心理学和技术中寻找乐趣。
在 DevOps 日,我学到了 [DevOps“三步工作法”][3]——流动反馈持续实验和学习——以及新对我而言的概念如Kaizen改善和Kaikaku改革。随着我的学习深入我发现我在说这样的话“我是这样做的我都不知道这样做还有个名字
[Kaizen改善][4]是持续改进和学习的实践。小的量变积累随着时间的推移可以引起质变。我发现它和卡罗尔.德韦克的[成长型思维][5]的想法很相似。人们不是生来就是专家。在某方面拥有经验需要花费时间,练习,以及常常还有失败。承认增量的改善对确保我们不会放弃是很有必要的。
另一方面,[Kaikaku改革][6]的概念是指,长时间的小的改变有时不能起作用,你需要做一些完全的或破坏性的改变。在没有找到下份工作前就辞职或移居新城市就足够有破坏性——是的,两者我都做过。但这些彻底的改变收获巨大。如果我没有辞职并休息一段时间,我也许不会接触到 DevOps。等我决定继续工作的时候我一直听到 DevOps我开始研究它。这引导我参加了我的第一个 DevOps 日,从那里我开始看到我的所有热情开始聚集。从那时起,我已经参加了五次 DevOps 日活动,并且定期撰写关于 DevOps 话题的文章。
### 将三步工作法用到工作中
改变是困难的学习新事物可以听起来很吓人。DevOps 的三步工作法提供了一个管理改变的框架。比如:信息流动是怎样的?是什么驱动着你做出改变?一旦你认为一个改变是必需的,你如何获得这个改变是否正确的反馈?你如何知道你在取得进展?反馈是必要的,并且应该包含积极和有建设性的要素。困难的地方在于保证建设性的要素不要重于积极要素。
对我而言,第三步——持续实验和学习——是 DevOps 最重要的部分。有一个可以自由地实验和冒险的环境,人们可以获得意想不到的结果。有时这些结果是好的,有时不是太好——但这没事。创建一个可以接受失败结果的环境可以鼓励人们冒险。我们都应该力争定期的持续实验和学习。
DevOps 的三步工作法提供了一个尝试,获得反馈,以及从错误中获取经验的方法。几年前,我的儿子告诉我,“我从来就没想做到最好,因为那样我就没法从我的错误中学到东西了。”我们都会犯错,从中获得经验帮助我们成长和改善。如果我们的文化不支持尝试和学习,我们就不会愿意去犯错。
### 成为社区的一部分
我已经在技术领域工作了超过 20 年,直到我发现 DevOps 社区前,我还经常感觉自己是个外行。如果你像我一样——对技术充满热情,但不是工程和运维那方面——你仍然可以成为 DevOps 的一部分即便你从事的是销售、营销、产品营销、技术写作、支持或其他工作。DevOps 是属于所有人的。
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/11/how-non-engineer-got-devops
作者:[Dawn Parych][a]
选题:[lujun9972][b]
译者:[alim0x](https://github.com/alim0x)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/dawnparzych
[b]: https://github.com/lujun9972
[1]: https://opensource.com/resources/devops
[2]: https://www.devopsdays.org/
[3]: https://itrevolution.com/the-three-ways-principles-underpinning-devops/
[4]: https://en.wikipedia.org/wiki/Kaizen
[5]: https://en.wikipedia.org/wiki/Mindset#Fixed_and_growth
[6]: https://en.wikipedia.org/wiki/Kaikaku