善学者,假人之长以补其短

(本文由GeneDock公司Senior DevOps Engineer王皓撰写,转载请保留转载信息和原文作者及链接)

写在前面的话

本文共分三篇:运维篇,开发篇,测试篇。分别从三个角度看DevOps究竟是什么,也许“答案在风中飘扬”。同时也邀请你一起为GeneDock的DevOps之路出谋划策。

DevOps像什么?

过去的两三年里,DevOps是在互联网行业乃至整个IT业,发展迅猛的一个“词语”。这里之所以只说它是个“词语”,是因为在各种书籍里,网络上,关于DevOps是什么的说法太多了,有的说DevOps是一种文化,运动,惯例;有的说是一个过程,方法和系统;后来又发展成为一个岗位,一种职业,前几天还看到了有机构在做DevOps的认证。所以我觉得很难给出一个一言以概之的解释,我们只说说DevOps“像”什么:


1. DevOps起源于敏捷方法论,或者我们说的精益原则,目的是为了产品发布更加快捷、频繁和可靠。


2. IT价值流在DevOps的带动下将快速贯穿开发至生产全过程,虽然字面上我们只看到一个“Dev”和一个“Ops”,感觉像是“一带一路”似的,其实包括了从开发到测试,再到发布生产各个环节,下图被经常用到解释DevOps和已有的研发部门角色之间的关系。(其实还应该包括企业的架构师)




“DevOps是在整个IT价值流中实施精益原则的结果。IT价值流将开发延伸至生产,将由程序员这个遥远的祖宗所繁衍的所有子孙给联合在一起。”
以上是Gene Kim对DevOps的解释,供大家参考。


DevOps Check List


这里简单粗暴的列出一些Check List,大家可以对号入座,但不要过分纠结:


1. 开发团队,测试团队和运维团队之间应该没有障碍。三者皆是DevOps统一流程的一部分。


2. 每个团队的输出都是经过自验证的,这样才能保证DevOps的闭环顺利运转。分享一个DevOps闭环图:




3. 开发、测试和发布环境标准化,可以很容易将之扩展并进行部署。


4. 每个团队之间的通信线路都很明确,保证沟通效率。


5. 所有的团队成员都有时间去为改善系统进行试验和实践。


6. 每次学习到的经验都应该文档化下来并分享给相关人员。事故处理成为日常工作的一部分,且处理方式是已知的。


运维的“革命”


运维可以说是DevOps这场“IT运动”中受到影响最大的角色,从传统运维到DevOps,就是一场“革命”。


Google的SRE(Site Reliability Engineer),从前一段时间开始,被人们热捧,有的公司马上把自己的运维岗位换名为SRE,确实显得B格高了一点点。甚至有人把SRE和DevOps划了等号,这样做真让人觉得槽点满满。我认为SRE其实是运维“革自己命”的产物,客观讲,这样的转型是很高明的,一定是经验积累,加思考,再加探索得出的。


SRE是Google的运维团队从实践中总结出来的一套方法论,将工程研发、日常运维和应急响应等任务较好的结合并落地,当Google的运维团队开始在做SRE的时候,DevOps的概念可能还不为人所知。


所以我们是否应该首先想到是,如何学习Google的运维团队走出适合自己的转型之路,我们的运维团队未来是什么?


运维的未来是什么?


—一切皆自动化


“运维的未来是,让研发人员能够借助工具、自动化和流程,并且让他们能够在运维干预极少的情况下部署和运营服务,从而实现自助服务。每个角色都应该努力使工作实现自动化。”——《运维的未来》


说到自动化,感觉又是槽点满满,也许有人和我一样都经历过为了自动化而自动化的尴尬,在大公司里,不乏专门做自动化工具的团队,每年出一套工具,“紧跟时代潮流”,然后被迫使用这些自动化工具的团队怨声载道;但是有经验的开发、测试或者运维工程师一定能体会到,“自动化”对于DevOps来说,是刚需。


—工具的合理选择


同样对于DevOps来说,工具是必要条件,但工具不是充要条件,如果沉迷于各种工具的堆砌,那么可能跑偏,下面是我们经常会提到的一些工具:


代码管理(SCM):GitHub、GitLab、BitBucket、SubVersion
构建工具:Ant、Gradle、maven
自动部署:Capistrano、CodeDeploy
持续集成(CI):Travis、Jenkins
配置管理:Ansible、Chef、Puppet、SaltStack
容器:Docker、LXC、第三方厂商如AWS
编排:Kubernetes、Core、Apache Mesos
服务注册与发现:Zookeeper、etcd、Consul
脚本语言:python、ruby、shell
日志管理:ELK、Logentries
系统监控:Datadog、Graphite、Ganglia、Nagios
性能监控:AppDynamics、New Relic、Splunk
压力测试:JMeter、Blaze Meter、loader.io
应用服务器:Tomcat、JBoss、IIS
Web服务器:Apache、Nginx
数据库:MySQL、Oracle、PostgreSQL等关系型数据库;mongoDB、redis等NoSQL数据库
项目管理(PM):Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker


面对茫茫“工具海”,传统运维团队在日渐式微,而构建工具的团队日益壮大起来,这些工具包括持续集成环境和持续交付等等。运维能力应该逐渐延伸到构建和维护基础设施服务、配置管理、日志管理、容器管理以及监控等多方面。我的建议是,不选别人认为对的,只选最适合自己的。


—熟悉业务


在实践中我们发现,熟悉业务是团队最难实现,颗粒度最难把握的一部分。


传统运维会有很详细的分工,包括团队之间和团队内部。有的团队之间会做隔离,举个小例子,“今天上线的内容,我需要你每一步都写的清清楚楚,我只负责执行,不问为什么,出了问题我不负责”,听上去是否耳熟?其实问题不在于要求上线申请写的多清楚,问题是对业务相关“我不负责”。在传统运维团队内部,一般有专门负责部署上线,跑脚本的同事;有DBA,数据库所有操作就是“我”来;有做监控的同事等等。当然各个公司情况或许有所不同,但如果你曾经试着说服运维团队去靠近业务层,你碰到的问题应该类似,那就是或多或少的抵触。


DevOps中的运维团队需要对业务负责,这点毫无疑问,我想大家都没有必要再“害羞”了。事要知其然,且知其所以然。当然循序渐进的过程是有必要的,所以在GeneDock我们选择了一条自己的运维之路。


GeneDock的运维之路


GeneDock的运维团队在2017年二季度开始践行DevOps,努力的方向有两个:一是推进自动化落地;二是在原有的“知其然”基础上,要求团队成员“知其所以然”。


自动化的切入点是持续集成和部署,一步一脚印的向DevOps方向前进。目前主要围绕GitHub和jenkins,构建了线上(公有云)和线下(私有云)混合模式的持续集成和部署框架。如下图所示。




业务层面,运维团队在开发团队的大力帮助下,从上线后故障排查,以及配置管理问题的复盘开始,不断在实际问题中总结,并形成文档。同时也通过优化部署流程帮助整个研发团队提高发布效率。团队间相互促进,形成良性循环。

GeneDock的DevOps才刚刚起步,运维团队正在一边完善自己的日常维护工作,一边不断的学习新的工具,新的技能。相信不久后的GeneDock运维团队会再上层楼!也欢迎大家拍砖,不吝赐教,一起成长,“践行”渐远。


参考文章
《DevOps是什么鬼》:https://en.wikipedia.org/wiki/Consensus_(computer_science)
《运维的未来》:http://cs-www.cs.yale.edu/homes/arvind/cs425/doc/fischer.pdf
《SRE是什么鬼》:https://en.wikipedia.org/wiki/CAP_theorem