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

419 阅读9分钟
原文链接: blog.csdn.net

Patrick Debois

前言

原文发表在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)。

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

技术汇

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