介绍

我第一次听到 “devops” 这个词是在 2010 年底。当时我正在大学里做一个研究项目，我真的不明白那是什么意思。明年我开始在里约热内卢的一家小公司工作。我们有一个小团队，我们最有经验的开发人员负责部署应用程序。我们的团队开始壮大，我们认为让具有系统操作专业知识的人来处理所有事情会更好。那是一个糟糕的想法……在这篇文章中，我想谈谈我对 devops 的一些想法，以及我如何相信这与敏捷软件开发有很多共同点。

关于 DevOps

我做了一些研究，以了解开发社区何时开始谈论 devops。在 Patrick Debois ( @patrickdebois ) 撰写的 2008 年敏捷大会上的一篇文章中，有一些关于他们的基础架构团队如何进行一些实验的见解，将他们的应用程序视为其基础架构的客户端。

每个应用程序都被视为数据中心的客户。通过这种方式，他们开始编制积压工作，并分配了不同的优先级。

在此之前，开发人员和运营/基础设施团队之间存在很大的分离。在帕特里克的文章中我们可以看到一种新思维方式的开始。

深入挖掘后，我发现了由 John Allspaw ( @allspaw ) 和 Paul Hammond ( @phammond ) 撰写的 2009 年速度会议的演示文稿。当时他们在 Flickr 工作，他们的突破点是 他们每天至少在他们的网站上进行 10 次部署 。

试着想象一下它的影响。在那之前，部署就像一个特殊事件。这是开发人员走出他们的避难所，深入运营中心，看到他们的创造被运营人员的双手赋予生命的时刻，他们无法理解产品的珍贵。

“像开发人员一样思考的运维人员。像运维人员一样思考的开发人员。”

他们呈现的是一种看待事物的新方式。开发人员的工作不再只是向系统添加新功能，运维工作也不再只是保持系统正常运行。 开发人员和运营人员都有相同的目标：启用业务 。

这不是 敏捷软件开发所说的吗 ？人们应该协作以支持业务并以 客户始终满意的 方式响应变化？为什么操作人员被排除在外？

我学到的是

回到我的故事，关于我们雇人只是为了照顾我们的部署和生产环境的想法是多么糟糕。这里的问题是没有人来执行这项工作。 问题在于团队对他的心态以及他对产品的心态 。

从开发团队的角度来看，我们有一个运营人员必须尽一切努力来保持我们的应用程序运行。我们不关心 我们的日志记录是否糟糕 ，我们 是否没有提供任何监控信息 ，或者 我们的部署过程是否详尽且容易出错 。我们只希望他能保持应用程序运行良好。

从运营人员的角度来看，我们是一群傻瓜，总是在改变一些东西，而且不关心应用程序的稳定性和性能。

看？我们创造了其他公司已经拆除的墙。我们之前将产品交付给客户的承诺更改为将其交付给运营人员。运营人员的承诺是部署应用程序并将开发人员的产品交付给客户，而不是他的产品。

我不必说这不是很好。我没有关于这如何影响我们产品质量的任何统计数据，但我可以说 我们降低了产品质量 。我们不再担心昂贵的查询、内存泄漏和所有事情，毕竟这些都是运维人员关心的问题。让他受苦并创建数据库索引或让他在半夜被唤醒以重新启动服务器，这不是我们作为开发人员的工作。甚至我们与他们的个人关系也受到影响。我们感觉不像是同一个团队。

经过大量会议和计划后，我们决定停止使用运营人员。我们再次开始部署并保持我们的应用程序运行。我不能说这是个坏主意，但我相信这不是最聪明的主意。毕竟，为什么我们不能利用运营人员在服务器和网络方面的所有知识和经验来为我们谋利呢？

今天，当我回头想想时 ，我认为我们应该把运营人员带到我们的团队中 。我们本可以教他更多关于我们产品的知识，让他建议我们如何优化查询、避免内存泄漏以及如何使用自动化流程增强我们的部署流程。在那之后，我相信 他会对产品更加投入，我们会开始把他当作我们的一员 。

结论

我所说的一切如何适用于敏捷软件开发？每个团队都应该有一个运营人员吗？

好吧，我不能说在团队中拥有一名运营人员是一件坏事，但我们知道有时由于公司预算或文化的原因这是不可能的。我认为，作为开发人员，您应该将自己置于操作人员的位置。不要认为他是一个试图阻止你创新的人，而是想想你如何才能让他的生活更美好。
作为一名运营人员，您应该尝试更好地了解您使用的产品，并尝试找到使其成为更好产品的方法。

在 他们的演讲 中，John 和 Paul 分享了他们如何在 Flickr 上应用这些概念的一些技巧。他们使用的工具和他们所做的文化改变。我想在这里重点介绍其中的一些内容，但我真的建议您查看他们的演示文稿。

工具

• 自动化基础设施 ： 持续集成 、 应用程序容器 、 云基础设施 ……关于这个话题要谈的太多了，它会成为一篇文章中的一篇文章。关键是尽可能自动化一切以避免错误。 请记住，作为人类，我们很容易出错 ；
• 一步构建和部署 ：这是前者的一个专题。我只是想特别注意它；
• 共享指标 ：不仅仅是操作人员应该知道应用程序的行为方式。团队中的每个人都应该能够随时看到它（我会说即使是客户也应该能够随时看到它，但我知道有时这是不可能的）；

文化

• 尊重 ：尊重他人的专长、意见和责任。请记住，团队中的每个人都想要相同的东西：创造一些很棒的东西。
• 可见性 ：不要隐藏东西！开诚布公地讨论潜在问题，并尝试共同制定应急计划。每个人有时都会搞砸，最好尽快找到它来修复或收容它。
• 信任 ：每个人都需要相信其他人都在为企业尽最大努力。让运维人员参与功能讨论，让开发人员参与基础设施讨论，让他们能够访问系统。你们都在同一个团队！
• 对失败的健康态度 ：失败会发生，你不能浪费时间寻找罪魁祸首。发生错误时，最好浪费时间思考该怎么做。 “如果你认为你可以防止失败，那么你就没有发展你的反应能力” ；

我认为最重要的是：记住 你在产品中做了什么并不重要，但你要像其他人一样对它负责 。致力于产品并互相帮助以获得更好质量的软件。

参考

• Patrick 关于敏捷基础设施的文章
• IT Revolution 的博文： DevOps 的融合 ( http://itrevolution.com/the-convergence-of-devops/ )
• 2009 年 Velocity Conf 演示文稿： 每天 10 次以上部署：Flickr 的开发和运营合作 ( http://velocityconf.com/velocity2009/public/schedule/detail/7641 )