[译]一个系统管理员眼中的DevOps

前言

原文发表在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，从这种合做文化中看到了价值。

这些公司将这种协做模式认为是一种「独家秘方」，可让他们在竞争中取胜。

这是为何呢？

由于它认识到个体不是一种资源，而是一种应对在这个复杂的世界中存在的挑战的智慧。

附：

参考文献：

一、John Willis, What devops means to me

二、Damon Edwards, what is devops

三、Israel Gat, boundary objects in devops

四、Amazon Architecture

五、John Allspaw, 10 deploys per day - dev and ops cooperation at flickr

六、Jesse Robbins, Operations is a competitive advantage

每日干货分享，传递互联网世界有价值的讯息，尽在「技术汇」