DevOps 是 90% 的改变和 10% 的技术

图像来自于：opensource.com

Jen Kriege 在 80 年代早期就用上了她的第一台电脑，自从那时候起就一直保持对技术的浓厚兴趣。她的职业生涯从金融分析师开始，最终进入信息技术领域，由此获得软件开发与发布的专业知识。Jen 使用过很多开发方法，从瀑布流到敏捷。

如今，她是红帽为 Atomic、Docker 和 Kubernetes 这些项目工作的团队的敏捷教练。今年，Jen 在 DevNation 大会上讲述了作为 DevOps 工程师意味着什么，在这次访谈中，她告诉我们实施 DevOps 的挑战，分享给工程师们的一些建议，等等。

说一说你自己，你的背景，以及你是如何进入到 DevOps 的。

我是在 80 年代早期真正得到自己的第一台电脑的，当时我爸爸从公司买回家一台崭新的康柏便携式电脑。从那以后，我就一直以某种方式从事技术工作。我为漫画图书行业的一些人运行网站，自学了一些编程语言，但是我意识到自己有数学方面的才能，所以就成为迈阿密一家公司的金融分析师。

就是在这家公司，我把金融技巧和技术结合在一起，最终进入了他们的 IT 部门。我学习了开发和部署软件的基础，亲身经历了瀑布流项目的艰苦工作，以及最终体会了使用敏捷带给我的自由。

虽然我真的很感谢这些经历，但是我和这个行业中其他人的交流使我意识到还欠缺一些东西。软件过于紧密耦合，我们缺乏自动化测试，软件的发布还是要花费太长时间。最重要的是，我们看重闭源软件，所以我们每次看到一个解决问题的工具，又是一笔没人愿意支付的数额巨大的软件账单。

在 2012 年，我接受了红帽的一份工作，在他们的 IT 部门做敏捷系列产品的经理。我做了一段时间，然后抓住机会成为 DevOps 实践团队的产品负责人。该团队的任务是缩短该部门发布软件的时间。就是在这里我见到了所有技术宅想要的软件。然而，最重要的是，有一刻我意识到用容器技术部署软件可以有多快——不是因为有人告诉我，而是因为有人给我看了这是可能的——这是革命性的。

我现在是红帽 Atomic 项目团队的敏捷教练（即首席牧猫人 Chief Cat Herder），这些团队开发 Atomic 主机、Docker、Kubernetes 以及许多其它软件。这项工作要求很苛刻，不过我觉得我自己能和这样有才华的一群人一起工作是格外幸运的。

DevOps 到底是干什么的？

问 10 个人这个问题，你会得到 10 个不同的答案。虽然在我最初几个月试图搞明白这究竟是什么时，这对我是无尽的挫折，但是现在我明白了为什么每个人有不同的答案。每个 IT 工作环境，基于使用的工具、开发和支持的软件和基础设施、以及负责这些事情的人，也会是不同的。任何人都可以查找维基百科中的定义，得到其含义的教科书版本。DevOps 对我意味着什么？这很简单：如果你一直是从同一家公司获取报酬，尽你最大的努力做正确的事情。

DevOps 涉及开源吗？

是的，我为 Opensource.com 写了一大篇关于这个的博客。这在 DevOps 的文化转变中是个很好的起点。

“开源并不是通向成功的简单按键。不过，它能够做的是为个人和组织提供可以遵循的一套价值，让你的组织走上通向成为有效的 DevOps 社区的道路。”

DevOps 有多大部分是关于文化和改变的？

对我来说，90％是关于文化的改变，10％才是关于技术。不过，我的看法是由我过去 15 年软件开发的经验和这期间的交流形成的。是的，大部分这样的交流肯定起始于技术问题。我多次提到的是我和一位在一家闭源公司任职工程师的朋友的谈话。她说，她希望在她的工作中哪怕有可能使用象 Jenkins 这样的持续集成（continuous integration，CI）工具，但是这恐怕永远也无法得到批准。不过，接着她又说，就算她得到批准，她也有可能让她的老板生气，因为老板告诉她这不是要优先考虑的事情，而且她担心（老板说这话）更深层的含义。所以，市场上有什么工具，免费或者要钱，都不重要——如果你公司的整体文化不认为改进内部流程重要，那么任何工具也帮不了你多大的忙。

在一个组织中实施 DevOps 最大的挑战是什么？

人。我再怎么说也不过分——人是整件事情中最棒和最糟糕的部分。他们是你的未知数，而且你可以肯定这一定会在最糟糕的时候出现。

你要给在 DevOps 环境中工作的工程师什么建议？

不断学习，保持好奇，不断追问事情是如何运作的。如果你发现对现状不满，那就采取行动。

不过最重要的是，绝对不要期望别人会提供你要的东西。如果有要做的事情，你知道这件事应该做，而且看起来没有人去做？找到一个影响你周围的人的方法，把它实现。到我的红帽 DevNation 谈话来吧，听听更多关于如何做到这一点的，“那么你想成为一名DevOps 工程师？”。

DevOps 会成为默认的 IT 工程实践方法吗？

也许吧。我觉得明智、有远见的公司会尽快地尽力拥抱这项技术。但如果这要成为默认的方法，还要花很多年——类似于接受敏捷所经历的过程。关键将取决于规模较大的企业是否能够解决技术和人员的负担，而同时调整为交付软件的新方法。最终，我相信良好 DevOps 体验的基本概念——通过自动化快速整合、测试和部署软件；监测环境，构成丰富反馈回路，等等——都会是有才能的工程师要成功所期望的。仅考虑这一点——工程师在面试中问“你们使用什么持续集成系统？”。他们用这个问题的回答来评估他们想要工作的地方。这就是 IT 的未来。我甚至可以说现在已经是这样了。

最后还有什么想法要分享？

很多过去和我一起工作过的工程师告诉我，我的秘密武器是，在需要搞清楚接下来会发生什么事情时，我总能知道应该和谁谈话。如果你出席红帽大会和 DevNation，请来找我，做一下自我介绍——我想听听你的故事。

DevNation 演讲者采访

DevNation 2015 是由全球开发者为全球开发者自己组织的一个开源会议，本文是其中的演讲者访谈系列的一部分。

查看英文原文： DevOps is 90% change and 10% technology

感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。