mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
74 lines
6.0 KiB
Markdown
74 lines
6.0 KiB
Markdown
[#]: collector: (lujun9972)
|
||
[#]: translator: (alim0x)
|
||
[#]: reviewer: (wxy)
|
||
[#]: publisher: (wxy)
|
||
[#]: 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: (https://linux.cn/article-10386-1.html)
|
||
|
||
所有人的 DevOps
|
||
======
|
||
|
||
> 让一名非工程师来解释为什么你不必成为一位开发者或运维就能爱上 DevOps。
|
||
|
||
|
||
|
||
我从未做过开发或运维的工作 —— 那怎么我在写一篇关于 [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)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [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
|