前言
原文发表在Patrick Debois大神的官网上，传送门>>
通篇围绕运维工作进行阐述，始终是在强调运维人员和开发人员需要通力协作，这大概也是DevOps理念的核心价值所在吧！大概是因为作者来自比利时吧！翻译的时候还是有些吃力。尽量保证原汁原味，不足之处，敬请指正！
写作背景
2011年的LISA (Large Installation System Administration)峰会有一个关于「DevOps」的主题。
与会者都是从事了相当长时间的自动化工作，并且很多人都认为每天都在做着有关于DevOps的工作。
然后，他们想请我为Usenix ;Login magazine写一篇文章，从系统管理员视角阐述一下DevOps。因为看这篇文章还需要订阅这本杂志，所以我干脆把它发表到我的网站，供其他读者阅读。
介绍
尽管对于DevOps还没有一个真正意义上的定义，但是DevOps大致可以分为四个关键点（CAMS）：
- 文化（Culture）
- 自动化（Automation）
- 度量指标（Measurement）
- 分享（Sharing）
在这篇文章里，我们可以看到这四要素是如何影响系统管理员的。
作为一名系统管理员，你或许对自动化（Automation）和度量指标（Measurement）两部分比较熟悉，业界也有最佳实践，使得自动化的工作变得更快速和可重复。此外，为了确保系统运行更流畅，收集一些系统运行指标，采取一些必要的监控措施已经成为日常工作不可或缺的部分了。
痛点
长期以来，运维（通常是系统管理员的工作的一部分）已经被视作是软件交付的最后一个步骤了。
在整个项目中，开发人员的编码工作独立于运维工作，并且一旦软件已经开发完毕了，他们认为是时候将其交给运维部门执行了。
在开发过程中暴露出了很多问题。在开发和测试环境中，一些典型的用例并不能代表在生产环境也有效，或者是说缺乏有效的备份和还原策略。在项目开发过程中，去修改系统架构和代码结构显然是为时已晚，开发人员也只能给出一些临时解决方案。
这样的摩擦导致了开发人员和运维人员相互的不尊重。开发人员认为运维人员根本不了解自己所开发的软件，而运维人员认为开发人员对于服务器运行一无所知。
将这两个部门独立管理，彼此之间沟通甚少，导致两个部门之间形成了一道隔阂：混乱之墙（Wall of Confusion）。
合作的艺术（Culture of collaboration）
事实上，有两个因素驱动着DevOps的发展：
第一个是敏捷开发。敏捷开发模式使得很多公司的运维人员的部署工作比以前要多很多。（译者注：小步试错，快速迭代）
第二个就是大规模的云计算和云存储的运维要求，在这种规模下，开发和操作需要更紧密的协作。
每当出现问题了，公司经常是创建一个多任务的工作组来解决生产问题。可现实是，如今的IT基础设施环境以及变得非常复杂了，不是靠一个人或是一个组织能完全管理的。因此，与其像之前那样让开发和运维人员分开，不如将他们合并起来。
不过这方面我们还需要更多的实践，我们始终坚信：熟能生巧（if it's hard, do it more often）。
DevOps理念认为只有发布到生产环境，软件才能发挥价值，而一个没有运行任何软件的服务器是毫无价值可言的。
研发部门和运维部门的共同目标是服务客户，而不是各自为政。
尽管系统系统管理员已经和其他部门有过协作，但是这种合作从来不被认为是一种战略优势。DevOps的核心文化价值是为了更好地满足业务需求，促进跨部门间的持续协作。DevOps不失为一种减少冲突，促进跨部门/跨学科交流的手段。
开始协作的一个突破口是讨论经常要改进的地方：部署、打包、测试、监视、构建环境。
这些都可以视为“边界对象”，每个人对其都有自己的理解。同样也是技术债务累积的重灾区，所以也涵盖了平常工作的种种痛点。
分享的艺术（Culture of sharing）
在公司里面会出现形形色色的隔阂，不仅是存在于开发人员和运维人员，有的公司甚至在运维部门内部就有很多隔阂：网络、安全、存储、服务器等部分都没有很好的协作，各自在自己的世界里运行。这被称为「Ops-Ops」的问题，因此，在极客语言中，DevOps实际上被描述为devops*。（译者注：即开发部门需要对接多个运维部门）
DevOps并不意味着系统管理员需要懂得编程，也不是说所有开发人员需要知道如何部署服务器。就协作本身的意义来看，两个部门的人员其实可以相互学习，在日常工作中也能及时回应彼此。这是在敏捷开发中，用于开发人员和测试人员沟通的一个手段。DevOps可以视作是将系统管理员引入敏捷开发工程的一个延伸。
有时候，开发人员和运维人员开启一段交流是需要一定的勇气的，但是考虑到这样做的好处，也是值得的：随着应用规模的增长，你可以在这个过程中不断学习，并且你可以通过自己的投入来积极地塑造它。
系统管理员能够给开发人员提供很多内容：你（运维人员）知道生产环境是怎么样的，所以你可以据此构建一个更具代表性的开发/测试环境（译者注：与 痛点 一小节提到的问题进行呼应），你可以参与到压力测试、故障转移测试中，或者你可以安装一套监控系统，让开发人员能够看到究竟哪里出错了。并且开发生产环境的日志访问权限，以便开发人员了解应用在生产环境真实运行情况。
（运维人员）分享信息和知识的一个很好的方式是与开发人员或同事结对：当你（运维人员）在部署的时候，他（开发人员）会对所部署的代码进行影响评估，而且你可以直接向他提问。
这样的互动对于了解彼此的工作是非常有价值的。
回顾自动化（Revisiting Automation）
就像敏捷宣言（Agile Manifesto）所说的，DevOps重视“个体和互动高于流程和工具”。工具的伟大之处在于，它们是具体的，并且可以直接受益于文化。
如果不真正开始实践，是很难领会虚拟化和云技术带来的影响。各种工具可以塑造我们的工作方式，进而改变我们的行为。
配置管理（Configuration Management）和架构即代码（Infrastructure as code）就是一个很好的例子。
许多人都称赞自动化的强大和灵活，如果你从节约时间成本方面考虑，你会发现它还有一个非常大的好处：就像创建了一种“共享”语言，它允许你与其他同事交流管理系统的方法，甚至可以在GitHub上发布cookbook。
因为我们（运维人员）知道一些版本控制和测试的概念，我们和开发人员都会有一些共通的问题。最重要的是，自动化将我们从琐碎的事情中解放出来，让我们可以讨论和关注那些真正重要的事情。
回顾度量指标（Revisiting Metrics）
协作的指标不能简单的用沟通次数来衡量，毕竟再多的沟通也不一定意味着会有更好的效果。它类似于黑洞，你必须观察附近的物体。
所以，你该如何看待情况有没有改善呢？
作为一个运维工程师，你收集有关于生产事故的次数，部署失败/成功的次数等相关指标。与其将这些数据保留在部门内部，还不如将它们分享给公司的其他部门，以便让其他部门的人也能从中学到一些东西。与所有利益干系人一起做事后检查，并进行改进。
与此同时，这也改变了度量和监控的焦点，从运维人员的快速修复变成了及时反馈到整个组织。目标就是从整体上进行优化，而不仅仅是局限在自己工作的部分。
独家秘方（The secret sauce）
有几家“新”公司在这些实践中都是领先者。
Google的 two-pizza team，Flick的 10 deploys a day 都算是这个领域的先行者。
但也有很多传统的公司，比如National Instruments，从这种合作文化中看到了价值。
这些公司将这种协作模式认为是一种「独家秘方」，可以让他们在竞争中取胜。
这是为什么呢？
因为它认识到个体不是一种资源，而是一种应对在这个复杂的世界中存在的挑战的智慧。
附：
参考文献：
1、John Willis, What devops means to me
2、Damon Edwards, what is devops
3、Israel Gat, boundary objects in devops
4、Amazon Architecture
5、John Allspaw, 10 deploys per day - dev and ops cooperation at flickr
6、Jesse Robbins, Operations is a competitive advantage
每日干货分享，传递互联网世界有价值的讯息，尽在「技术汇」