一“Dev”一“Ops”:DevOps之运维篇

写在前面的话

本文共分三篇：运维篇，开发篇，测试篇。分别从三个角度看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

阅读原文：https://www.genedock.com/blog/2017/05/22/%E4%B8%80%E2%80%9CDev%E2%80%9D%E4%B8%80%E2%80%9COps%E2%80%9D-DevOps%E4%B9%8B%E8%BF%90%E7%BB%B4%E7%AF%87/