1. 构建基于云计算架构的涵盖持续集成与持续部
署的 DevOps 管道
1.0 版
2016 年 12 月 25 日
追 梦 人
专注 AWS 云架构、DevOps 管道、Atlassian 工具集、信息系统基础架构方案
邮箱：clickpurase@outlook.com QQ 群: 548734401

2. 近年来，除了云计算，另一个在 IT 业界被热炒的概念可能要属 DevOps。
一些初创公司以拥有一套 DevOps 系统来吸引潜在投资者；一部分的软件开发商和系统集
成商声称只要使用了他们提供的某一款或几款软件就能构建起完美的 DevOps 生态系统，以此
忽悠客户；更有不具实力的无良培训机构向初入职场的社会新人吹嘘，只要经过他们的短期培训
或者考取何种证书，就能步入 DevOps 职业生涯，获得让人羡慕的高工资，来敛取不义之财；
还有一些公司，所需的可能只是系统运维人员，却打着 DevOps 的招牌，面向社会招揽优质人
才。可谓乱象种种。
作为一个从业 10 多年的 IT 职场人士，我觉得虽然 DevOps 真正的门槛确实不低，但远非
能带来云计算那般的深远影响。此外，架构合理，并且功能完善的 DevOps 系统故而能提高研
发和部署效率，但鲜有能真正将 DevOps 的全部优势发挥出来的公司或团队。因为它对架构、
实施全套 DevOps 系统的人员的要求是极其广泛的。由此，我想对 DevOps 下一个相对简短的
定义：
适用软件研发团队或公司，基于信息技术基础架构，涵盖软件开发流程系统，并通过持续
集成和持续部署工具将两者结合起来的，能够提高软件研发和系统部署效率与成功率的一套系
统。
那么构建一套 DevOps 系统需要些什么，或者说 DevOps 有哪些要素呢？网络上有关于此
的报道和文章也是很多，但是那些众多带有宣传性倾向的短文，几乎无一例外没有提到“信息系
统基础架构”。我无法想象脱离了 Windows、Linux 服务器系统，离开了 TCP/IP 网络，也没有存
储系统支撑（PC 电脑里的机械硬盘、网盘都是存储系统的一种形式，而非只有动辄数十万，数
百万的 NAS，SAN 才是存储系统）的 DevOps 系统该如何运行。也许在一些比较大的公司里，
有专门的信息系统基础架构团队和 DevOps 团队，但是如果架构 DevOps 系统的团队没有对信
息系统基础架构的深入了解，是无论如何不可能设计出功能完善的 DevOps 系统的。因为，不
管是研发过程中用到的 dev, 用于测试的 uat 系统，还是后期系统上线时的 prod 系统，都需要信
息系统基础架构的支撑。所以，我认为一套成熟的 DevOps 管道应该涵盖如下子系统：
1. 传统信息系统基础架构或者公有云架构
2. 代码管理系统
3. 持续交付系统
4. ticket 跟踪系统
5. 配置管理、监控、日志系统
6. 文档管理、消息协作
7. 人，能深刻理解如上各子系统，并能将其整合的高素质的人（人类社会，离开了人如何
谈事？）
传统信息系统基础架构或公有云架构
对于这部分，在网络上已有大量详实的资料，在此只作简短的概括。
a. 服务器系统
学好 Windows 和 Linux，即可走遍天下。忘记 BSD, Solaris, HPUX, AIX 吧，这些都是正在消
亡的操作系统。除了操作系统本身，运行于其上的 Web 服务器、数据库系统（主要有 MySql,
MSSQL, Oracle, Hadoop, NoSql 等）、基础架构服务器（LDAP, DNS, DHCP, FTP, NTP 等）、
文件与打印服务器、邮件系统、系统更新与包管理系统（Windows Update, Yum, APT）、以及
相关的远程控制和远程访问也是必须掌握的技能。此外，在各种云架构系统大行其道的今天，必
须掌握 AWS 和 Azure 这两大 IaaS 公有云架构系统。
学习资源介绍：微软官方推出的培训资料（例如考取 MCSE 所需通过的认证课程的官方原
版教材）、红帽(RedHat)官方推出的培训资料（例如考取 RHCA 所需的认证课程的官方原版教
材）、白皮书、脚本编程书籍、官方在线帮助系统、操作系统和服务器系统自带的帮助系统（个
人感觉最新 Windows 系统自带的帮助系统和 XP 系统时代相比，有点渣）、两台通过网络互联
的中等配置的电脑（用虚拟机也可以凑合，但有限制，无法完全模拟出实际环境）。

3. 虽然我推荐通过阅读微软、红帽、思科和 VMware 的官方培训体系教材，来学习 Windows,
Linux、TCP/IP 网络和 VMware 虚拟机的知识，我本人也有 MCSE, CCNP 等证书，但我强烈不
建议职场人士浪费钱去考这些所谓具有“含金量”的证书。它们在你的职业生涯中所能带来的帮助
微乎其微。真正具有含金量的知识是不会出现在由商业机构推出的培训体系中，为他人所羡慕的
知识和技能，大部分时候需要我们自己去发掘并学习。
b. 网络系统
弄明白 TCP/IP 网络的七层机制，了解包封装、物理地址、逻辑地址、三层交换、路由、代
理、防火墙、无线网络、WAN 链接等的工作原理和实现机制，搞清楚 VLAN、VPN、 NAT、子
网划分、访问控制、RIP 路由协议（觉得不够用就再学点 OSPF 吧，不过估计用 OSPF 路由协
议的环境，基本不需要也不愿意由 DevOps 技术人员去动网络），再把操作系统上与网络相关
的几个命令用熟，基本就够用了。
在我们的职业生涯中，应该能看到整个地球完成从 IPv4 至 IPv6 的迁移，故必须注重储备
IPv6 的知识。
学习资源介绍：如果无从下手，建议阅读思科 CCNA、CCNP 认证体系的官方原版教材。
实操练习，可以使用路由交换模拟器软件（如 Dynamips, Boson Netsim）和装有 Windows
和 Linux 的 X86 电脑。
c. 存储系统
严格的来说，存储系统主要有 DAS, NAS, SAN，以及云端存储系统（如 Amazon Glacier, S3）
几个类别。可有时也把 PC 电脑内部的硬盘作为存储系统的一个特殊类别。从存储架构角度来考
量，存储系统又可分为块存储系统、文件存储系统和对象存储系统。
通常，对于 DevOps 架构师来说，只有大数据研发项目才需涉及中高端存储系统。在大部分
项目中只需涉及基于 FTP, NFS, SMB 协议的传统文件服务和 S3 这样的云端存储。哪些来自
EMC, NETAPP, HDS, IBM 等公司的中高端存储系统，在绝大部分研发团队中是不会配备的，甚
至很多中小公司的生产系统中也根本不会考虑使用来自这些公司的设备。原因无它，一个字“贵”。
所以，很多时候，对于 DevOps 工程师来说，掌握了之前所说的服务器系统的知识和技能便已
够用。
但如果你是一名 DevOps 顾问，那么有必要了解一些来自存储大厂的相关产品的知识。因
为，存储系统是传统 IT 行业内一个相对不透明的领域。同一功能，不同的存储厂商可能有不同
的称谓（乱）；很多高级功能的开通（只是开通而已）都需要额外付费购买许可证（黑）；性能
参数的描述更是夸张而不实（虚）；售后服务难觅合格的厂商技术人员，因为有别于系统工程师
在 PC 电脑上装上服务器操作系统就可以在家学习，中高端存储系统的知识和经验没有实际使用
经历根本无法掌握，而存储厂商们显然不可能招人后花大量时间去进行在职培训，导致整体售后
技术支持团队的素质渣渣。作为 DevOps 顾问的你，在设计了一整套流程后，在实际部署中很
有可能遇到因为存储系统的限制而导致项目延期的情况。所以，有时间的话，在项目设计阶段，
最好预先研读一下存储大厂的在线文档。
学习资源介绍：对于传统文件服务，可以在安装有服务器操作系统的 PC 上进行联系；而
云端存储服务，可以通过注册个人账户来学习；但对于中高端存储系统，除非公司内有现成的
资源，否则是无法自我学习的。
d. 系统和网络安全
系统和网络安全对于任何一家企业来说都是一个严肃的话题，一般都有专人负责。在 DevOps
领域，需要注重了解的主要有补丁包、严格的密码策略、OSI3 至 7 层包过滤技术、加密通讯、
端口屏蔽、IP 地址屏蔽、并发控制、入侵检测与入侵阻止系统等几个方面。

4. 注意：禁用生产环境中服务器系统的自动更新功能。因为操作系统厂商有意或无意发布的
带有缺陷的补丁包导致生产系统崩溃的事件时有发生，所以请禁用或关闭系统的自动更新功能。
可能的话，请搭建自己的更新服务器。
学习资源介绍：来自社区和标准化组织的公开资料是很好的学习资源，大多数情况下你只
需有概念性了解即可。因为有了扎实的理论知识作为依靠，在实际项目中，只需浏览下相关产
品的厂商文档，即可将其集成入你的项目中。
e. 高可用性和高可靠性
从整个 IT 架构的角度来考虑，这是一个包含从机房供电、机柜供电、Internet 接入、交换路
由设备、服务器硬件（电源适配器、网络适配器、磁盘阵列等）、负载均衡系统、服务器系统、
甚至 DevOps 系统本身在内的一个繁杂而广泛的综合体。但在大部分的项目中，需要 DevOps
相关人员考虑的主要有负载均衡、Web 服务器、数据库服务器、和 DevOps 系统本身。
DevOps 管道的核心系统（源代码系统、持续交付系统），在发生系统崩溃的情况下，必须
能快速恢复（少于 10 分钟），以免影响开发进度。一个简单易行的解决方案是将 DevOps 核心
系统通过 CloudFormation 部署于 EBS 存储介质上。
学习资源介绍：主要是来自开源社区和相关厂商的最新版的正式文档，家庭局域网和数台
PC 电脑。
我数次提到阅读官方原版教材，因为市场上现有的翻译资料真的让人难以理解原著精髓，
甚至很多时候翻译的牛头不对马嘴，所以，掌握熟练的英语技能（最起码阅读熟练）可能也得
被归为所有 IT 从业人员必备技能之一。
代码管理系统
当前主要有 git，svn，cvs 这三个类别的代码管理系统，但在大多数情况下，一般都选用 git。
简单的来说，git 的分支创建功能非常好用，程序员无不喜欢它的。并且在将基于 git 的代码管理
系统与持续集成工具（如 jenkins, bamboo）集成时，能更好的与持续集成工具相结合，实现某
些高级功能。而 git 本身又有多种变种。例如，github，其本身又有免费版和付费版区别；gitlab,
一些程序员说比 github 好用；还有一个叫 Stash (或者 Bitbucket)的产品。对于日常开发来说，
这几个 git 变种常用的几个命令都一样。但是从易用性、持续集成、代码安全角度考虑，Stash
可能是最好的。首先，是因为它可以被安装在你自己的服务器上，有别于 github 的云系统; 其次，
它可以更容易的与消息协作系统（如：Slack）集成，由 git 命令所驱动的事件能够被实时发送给
消息协作系统，而不只是发送一封极有可能被忽略的邮件；再者，Stash 能够更好的被集成到统
一身份验证系统中去，而无需用户记住海量的登录名和密码。
在对安全要求较高的环境，除了通过设置访问权限防止代码外泄以外；还需在代码下载和
递交过程中使用加密通道，防止代码在网络传输过程中被监听；代码库所在服务器的存储系统或
者文件系统的物理安全也是必须考虑的因素。
在 Agile, Scrum 概念大行其道的今天，对研发团队来说，如何协同使用代码库才是重中之
重。 master, release, dev, uat, prod 等等这些分支的创建与合并需要研发团队形成共识并严格
遵守；并与搭建 DevOps 系统的团队人员及时共享相关信息。而在搭建 DevOps 管道的持续集
成系统时，应该尽可能保证持续集成系统中相关“持续集成项目”（不同的持续集成系统可以对此
有不同的称谓）的简洁。理想情况下，一个为验证代码更改而创建的“持续集成项目”应该能被尽
可能多的研发人员所共用而不相互产生影响。
学习资源介绍：github, gitlab, stash 任选其一，结合 Agile 或者 Scrum 理念，即可一通
百通。

5. 关于 Agile 和 Scrum, 事实上很少有能严格贯彻的团队。我个人的观点也是不同的团队有
不同的实际情况，不能一一照搬。如果总是跟着别人指定的标准前进，那就意味着你总是在追
赶别人。有调侃说，每天早上参加 Standup，说自己是 Agile，你所在的团队就是遵循 Agile 了。
持续交付系统
何为“持续交付系统”？许多社区和商业公司会告诉你“就是 TeamCity, Jenkins, Bamboo”。
对此，我想再次打破常规，给予重新定义。
我认为所谓持续交付系统，是由持续集成与持续部署工具，将代码管理系统、操作系统部
署模板、配置管理工具、脚本相结合起来的一整套系统。
事实上，我尚未见过一个案例是安装并简单配置完 TeamCity, Jenkins, Bamboo 这些所谓
的持续交付系统后就能真正实现持续交付功能的。离开了操作系统自动化部署系统或者云架构自
动化部署模板，如何快速进行系统的扩展（scale up）和收缩（scale down）？没有配置管理工
具，如何对大量的服务器进行快速集中配置更改？脱离了用户自己编写的脚本，能自动完成应用
的分发吗？
一个高度自动化的 DevOps 管道，经由研发人员的一个代码递交事件即可触发持续交付系
统的执行，并进而完成整个应用的部署。当然，对于 dev, uat, prod 等系统应区别对待，可总体
思路不变，那就是以尽可能少的人为干预自动化应用部署。
库（repository）管理系统
设想有一天，客户跟你抱怨说之前功能正常的一个模块在系统升级后停止了运作或持续报
错，导致系统无法正常运行。而你的技术团队一下子又找不出 bug 所在，为了能让客户的系统
尽快恢复正常运转，你打算进行系统回滚，重新部署之前正常运行的软件版本。可是当你急着找
出之前用于发布的 artifacts 版本时，却发现该 artifacts 在一次服务器维护过程中被清除了。事实
上，因为在持续集成与持续部署服务器运行过程中会产生大量的垃圾文件，而由于 artifacts 隐藏
的目录一般都较深，其文件也无任何特殊标记，所以在服务器维护过程中很容易将其误清除。虽
然通过查找日志记录，可以发现上一次发布软件时的代码版本，重新进行编译再发布，但显然这
将耗费大量的时间。
2015 年，某软件包分区社区发生过这样一件事。因为某个开源大神在其编写的某个软件包
中所使用的名字与一家商业公司的某个注册名称相重叠，故被该商业公司要求其更改名字。不过，
大神就是大神，人家没鸟那个公司。可是，那个公司后来找到了该软件包分发社区的管理公司，
然后那个管理公司就接着又找到大神。大神一怒之下，直接将他写的软件包从开源社区撤下，直
接导致全球数以万计的程序员和 DevOps 工程师在 Internet 上咆哮。
可如果有了 repository 管理系统，那你就能对 build artifacts 进行有效的版本化管理，使得
应用版本回滚操作变得极其简单。此外，由于 repository 管理系统一般都自带库依赖管理，你可
以将你所需的依赖库都放置到 repository 系统上，进行统一分发管理。对于，一些从 internet 下
载的依赖库，repository 能进行自动缓存，提高后续访问的效率。所以，即便是对于只涉及前端
开发的团队，repository 服务器也是很有用的。
所以，repository 管理系统有助于构建一个高效而可靠的持续交付系统。时下流行的两大
repository 软件是 Nexus 和 Artifactory.
就工具本身来说，对比 TeamCity, Jenkins, Bamboo, 目前应用更为广泛的是后两者。
Jenkins 是来自开源社区的一款优秀的开源工具，而 Bamboo 是来自 Atlassian 的一款商业软件。
两者都有来自开源社区和第三方的广泛支持，拥有大量的各类免费和付费插件。并都能与代码管
理系统、ticket 跟踪系统、协作系统紧密结合，可以无缝集成入项目流程管理系统。但是从用户
体验、客户支持、功能完善角度综合考虑，以我个人的使用体验来说，这三款软件中最优秀的是
Bamboo.

6. 学习资源介绍：Jenkins 或 Baboo，二选一；阅读 Advanced Bash-Script Guide、Intermediate
Python 或者 Intermediate Perl 等书籍（如果你的脚本编程技能还不是很娴熟）；来自开源社区
的一个简单的应用；repository 系统（Nexus 或 Artifactory）；一台中高性能电脑(如果想跑的顺
畅，需要 16GB 内存）；一个公有云账户（如果是纯 Docker 部署，你也可以使用 VMware 虚拟
机）。
Ticket 跟踪系统
也许用于记录 bug、新功能请求、开发进程跟踪、任务分配的 Ticket 系统应该被划归项目
管理的范畴而非 DevOps 管道。不过，在很多团队中，有将 Ticket 系统与持续交付系统和消息
协作系统相集成的使用习惯，所以，将 ticket 系统集成入 DevOps 管道是时下的一种通行做法。
主流 ticket 系统有 mantis、bugzilla、bugfree、JIRA 等。可分为 SAAS 云端系统和服务器
版系统两大类别。基于 SAAS 的 ticket 系统，只需注册一个在线账户，即可开始使用；而服务器
版 ticket 系统需要用户在服务器上安装后才能使用，但能更好的与 IT 基础架构系统相互集成，
并且可以避免将敏感信息暴露于 Internet。从所涵盖的功能来评判，JIRA 是这几款中最全面的。
而以我个人的使用体验来说，我觉得 Bugzilla 也是一款非常优秀的简洁易用的系统。
配置管理、监控、日志系统
配置管理工具四剑客 Puppet、Ansible、Chef、SaltStack，这四款软件相互间的商业战争
可谓如火如荼，网络社区也到处都是有关孰优孰劣的争论。从应用角度来说，在满足实际需要的
前提下，选用你或者你所在团队熟悉的配置工具即可。
在 DevOps 开发过程中，大多数时候，只需找到合适的模板（template 或 modules），进
行二次开发（有一种说法认为像编写 puppet manifest file 本身，其实属于模块化程序开发的范
畴，而不只是系统管理）即可实现我们的需要。但也有些时候，需要我们自己写模板。我本人是
发自的内心的讨厌 puppet ERB 所用的 ruby，所以一直到今天都没有好好的学习这门语言。我
个人更喜欢 Python，故不久前开始我对 Ansible 的关注相对更多一些。
应用程序开发团队所需的“监控”不局限于硬件资源利用概况、系统健康状况、服务运行实时
动态，他们更关心应用程序本身的运行状况和性能。今天，被大部分公司所用的一款明星级产品
是 New Relic。虽然它所提供的很多功能只需简单配置即可，但是一些自定义应用，需要用户编
写脚本才能实现。
如果你跟我一样，曾经是一名系统工程师，相信在学习 Windows，Linux 的过程中，已经
对 syslog, eventvwr 等日志系统有所理解。在此，我想推荐的是 ELK（ElasticSearch, LogStash,
Kibana）系统。其实，这 ELK 系统不仅能收集、过滤日志，并以文本形式呈现给用户，更可对
数据库报表进行统计、检索、过滤、分析，并以可视化图表呈现给用户。可以说，其本身就是一
套数据分析系统。
文档管理、消息协作
普通的记事本一般的文档系统已经不适应现如今的需求了，今天大部分企业所用的文档系
统基本都是图文并茂，且能在线进行编辑。通过工程制图软件，生成矢量图并导出 JPG 格式的
图片，再上传至文档系统这样的低效工作流程已不适合现代办公节奏。为此我又要推荐一款好用
的软件，名为 confluence。这是我目前发现的唯一一款好用的文档管理软件。
消息协作，一般包含即时消息（Slack，Skype，QQ），语音系统（PBX 或者 VOIP），邮
件系统（推荐云端企业邮件系统，Exchange 虽然功能全面，但管理维护的负担实在太大了），
日程系统等。按需选择，在此就不展开了。

7. 当然，并非所有的 DevOps 管道均需用到如上所列举的各个子系统。不同的开发和应用环境有
着相应各自的独特需求。对于拥有数据中心的开发团队，可能更倾向于在已有的服务器平台上进
行开发和测试；而如果是初创公司，可能更加喜欢将研发和生产系统全部构建于云计算系统之上，
这能让他们尽可能合理的分配有限的资源，并更好的适应灵活的办公环境。
DevOps 开发人员工具推荐
文本编辑 Atom, Slim, vim
Python 开发 PyCharm
搜索引擎 Google(百度所能返回的真实有用信息太有限了）
远程访问 ssh, rdp, teamviewer
远程文件传送 scp
代码库访问客户端 git
云系统客户端 aws cli, azure cli
特定需要 VPN（不多解释，自己参悟）
大家如果对本文档感兴趣，之后我会推出实战案例介绍。感谢阅读！