一步步实施 DevOps （一）

什么是DevOps?

首先DevOps 不是一个产品，其次软件工程方法论也不准确。

在 DevOps 模式下，产品，设计，开发，测试和运维团队更紧密地结合在一起，贯穿应用程序的整个生命周期。

通过自动化工具替代手工操作，实现快速，高效，安全的测试，构建，部署项目。

为什么会诞生DevOps?

随着管理学的不断完善，例如工商管理，被分成很多纵深领域，行政管理，人事管理，财务管理，营销管理，项目管理……等等。

由于组织架构的需要，又把人分成很多岗位，每个岗位上紧紧需要一种知识体系。

同时我们学校也按照知识体系划分院系，本科教育程专科趋势，不重视通识教育，最终学生紧紧掌握了微观的知识。

如果说哲学是科学的科学，那么 DevOps 就是管理的管理。所以我认为 DevOps 是多维度宏观管理学。

DevOps 虽好，为什么难以普及呢？

实施DevOps 第一个遇到的问题就是人才，DevOps 需要经验丰富的跨界人才。第二个问题就是没有案例可循，无法参考。

实施DevOps需要具备管理，开发，测试，运维等等背景的人才。每个领域至少也需要三年的积累，至少需要 3+3+3+3 = 12 年工作经验，多少公司员工都比较年轻，普遍在 3~5年。

一般员工工作10年以上，遍开始转向管理岗位，或者寻找其他出路。即使转管理岗的员工紧紧负责开发管理或者测试管理…… 不太可能10年的开发，转运维部重头开始。

我上面说过我们教育模式有问题，本科教育应该培养 “T” 型人才，专科教育培养 “I” 型人才，本科教育呈专科化。学校只教会学生一项技能（如Java 开发）,而没有教会学生如何学习。

在中国企业的年龄歧视  “T” 型人才流失严重。“I”人才只能掌握一项技能解决一个领域的问题，无法完成DevOps 的实施。

DevOps 不是产品，是一种管理思想，每个企业根据自身特点，制定自己的DevOps规范，所以第二个难点就是，没有案例可循，无法参考。

软件工程的历史与进化

传统软件工程学出现的年代互联网还不普及，主要是单机运行的软件，或者C/S结构的软件，其特点是开发周期长，迭代慢，每半年或者一年交付一次。流程主张：

需求->设计->开发->测试->交付

进入互联网时代，已B/S为主的软件，交付周期缩短到一个月，在传统软件工程做了改进，放弃了瀑布开发模式，提出了快速迭代，螺旋上升，管理上也逐步完善。出现了软件项目管理，CMM5软件开发成熟度模型。

随着Web 2.0 和 云计算思想的提出，软件也在发生变化，软件运行不在限于一台物理机，而是多台服务器的集群中，传统的模块或原件，被独立部署在世界各地。

软件的开发面临前所未有的挑战：

1. 异构平台，软件不限于那种操作系统，例如Unix,Linux,As/400,windows,Mac
2. 多语言混合开发，不在紧紧使用一种语言开发软件。每一种语言都有他所在领域的优势。
3. 分布式，软件再也不是只运行在 一个CPU下，软件被分成很多模块被分布式部署到多台服务上。

这时便出现了极限编程，敏捷开发….等等，新的思想不断提出，但是仍然无法解决面临的问题。

• 产品部：需如雪片飞来，需求堆积如山
• 开发部：版本延期，质量问题频发，疲于奔命修复 BUG，刚修复了一个， 又出现新的 Bug
• 测试部：手工测试，升级后问题爆发，测试环境通过，到生产环境就出问题
• 运维部：环境不统一，每次部署都是一场灾难，配置易出错，回撤时间长，
• 团队现状：加班严重，效率地下，每天奔波救火
• 测试环境无法重现，开发人员直接在线上修改代码，跳过测试直接将代码交给运维升级
• 运维事故严重影响运营和广告投放
• 人员流动导致代码丢失

问题的原因在于，他们紧紧从各自部门的角度解决问题，同时 KPI 考核也不合理：

1. 产品从产品的角度解决产品遇到的问题。
2. 开发从开发的角度解决开发遇到的问题。
3. 测试从测试的角度解决测试遇到的问题。
4. 运维从运维的角度解决运维遇到的问题。

实际上现在的软件已经不是当年交付后一个网管就能搞定剩下的工作。同时软件开发交付周期缩的更短，一周甚至每天升级数次，遇到突发事件要做好随时准备升级。

总结这个时期实际上是： 软件项目管理 加 ITSM (IT Service Management) IT服务管理

所以聚焦微观管理解决宏观管理问题的做法是错误的，于是诞生了 DevOps。 DevOps 是多维度宏观管理学，是管理的管理。

开发，测试与运维三个部门的关系

1. 开发，测试，运维不是三个独立部门，他们相互紧密联系，但又相互制约：
2. 开发只负责写程序，将运行无误的程序提交至版本库中
3. 开发不能私自将程序交给运维部署，也不能将编译好的程序给运维测试。
4. 测试部只能从版本库提取代码，然后编译，打包，运行，测试
5. 不允许测试部将代码交给运维部部署
6. 避免代码没有经过版本库流入生产环境，线下与线上代码不一致
7. 运维部负责部署应用程序，配置管理，只接受测试部确认无误的版本，部署代码只能从版本库中提取

开发 -> 测试 -> 运维 贯穿始终。

技术规范的误区

几乎所有的技术企业都会重视技术规范，为此制定各种规范，并要求员工严格执行。同时员工会想出各种对策，就这样形成了潜规则。

流程与规范的制定需要需要满足几个条件，简单，容易掌握，容易执行，可重复执行

企业管理层擅长制定乌托邦式的流程与规范，随便拿出一条都堪称完美，无懈可击，但没有考虑到执行结果，流程规范在执行过程中每个环节都会出现问题。

我16年的职业生涯中在不同的公司任职过，几乎每到一家公司都会遇到各种规范，随着职业发展最后我也成为了规范的制定者，也曾经主持制定过开发规范，运维规范，测试规范等等。

我做过很多规范，文档无数，技术人员根本不会去看，通过开会向下传达，开会的人根本没有心思理会你的规范，规范执行阻力是很大的，效果也差。

终于有一天我意识问题的存在，开始反思，企业是否需要制定这些规范？ 我发现与企业环境/文化有很大关系。

有些强制的规范可以通过一些技术手段，避免出现。不会出现也就无需规范！

只有机器人才能100%执行流程

除了事，制定规范，后续无人跟进，

员工考虑的是尽快完成工作，

但这些规范起到的实质作用就好比“请保持室内卫生，不准乱团垃圾，禁止随地吐痰”

故事一

例如下面一个小故事，公司某部因为将开发数月的代码丢失了，导致测试无法进行，领导打发雷霆，某管理层制定了下面的规范，大意为。

1. 定期备份机制

2. 代码注释要求

3. 代码访问需要更高层的批准

4. 详细的部署文档

等等

我认为源码管理主要有两种手段，技术手段与管理手段。

我先谈谈管理手段： 例如通常通过规章制度，责任追究等等手段，要求员工达到规范标准，但通常执行力都会打折，无法达到预期，人的不稳定性因素太多。往往发现员工没有按照规范操作为时已晚，将该员工辞退也无法挽回公司的损失。

就如公司规章制度写的清清楚楚，要求员工提交代码到版本库，但各种原因没有被执行，当代码丢失，从上至下追究责任，公司的损失无法挽回。

所以我主张技术手段：

例如源码如果发布到线上，必须经过版本库，只能使用自动部署，不允许程序员私自将代码交给运维手工部署。另外发布代码的同事，可以不提供生产服务器登陆权限，他只能通过工具发布代码。

部署流程如下：

源码(程序员) 提交到development 分支UAT阶段 ----> 合并到 testing 分支Beta阶段（主管合并，程序员没有权限）------> master 分支(主管合并) -----> 自动部署系统(运维) ----> 生产服务器。

这样通过技术手段防止了代码因员工离职，硬盘损坏等等原因，导致代码丢失的可能。

代码发布者也无需对照部署文档，手动登陆服务器逐条按照部署说明书操作，防止了人员误操作，也提高了部署效率，节省了人力成本，通常在5分钟之内可以完成所有部署。

故事二

-----

我再来举另外一个例子，就是开发中的编码规范，很多软件企业都有是不是？

例如要求程序员：

if

(){}

要写成

if ()

{

...

}

等等要求不一一列举，甚至组织代码评审解决编码规范问题。

我的建议为什么不在IDE上设置自动格式化，或者在svn/git提交的时候通过hook调用格式化程序。

故事三

-----

管理层要求运维每天发送服务器状态报告，运维人员需要登录每个服务器或者从cacti等工具中获得服务器运行状态数据，然后制作一个报告文档，每天给各位发送一次。

运维需要一个专职人员做这个报告，这种报告几乎没有人看，就像“人民日报” 人民从来不看。

当运维事故该出现的时候还是会出现，老板一个一个骂，扣工资，扣奖金，运维觉得委屈，公司受到损失。平日里的这些工作并不能避免运维事故，也不能改善运维工作。

故事四

-----

在举一个例子，运维工作要求备份数据，A员工负责备份，B 员工负责检查A员工的备份。

结果两年以后出事了，需要恢复数据，发现A没有备份，而B在一年前就再没有检查A的工作。

起初前一年还是按流程备份，后来A发现B不再严格检查工作，备份工作逐渐减少，最后停止了备份，一直相安无事，直到事发。

故事五

-----

我曾经遇到过一个兢兢业业的管理者，他制定规范，要求值班的同事7*24小时，每间隔一定的时间做一次操作，验证系统正常运行，以便能够第一时间通知运维处理故障。值班的同事而偶偷懒，他就半夜起来监控他们工作。一个打工者能做到如此，真让人佩服。

但是我们有更好的方法，真的不必如此操劳且效率低下。

这些故事是一个无休止的死循环

-----

出问题 -> 发上制定规范 -> 无人看/看了慢慢淡忘/石沉大海 -> 继续出问题。连续出现问题，采用行政手段处分，扣奖金等等。很多管理者将其归咎为 “执行力” 弱，我并不这么认为。

我觉得很多规范是形式主义。我一向主张实用主义。

通过技术手段可能避免很多没有意义规范，开发自动化，测试自动化，运维自动化，这是趋势也是我的努力的目标。

很多企业为什么实施 DevOps 以失败告终？

很多企业实施DevOps 紧紧是软件堆砌，根本没有深入理解 DevOps，吧devops 相关的软件全部安装上，然后做系统集成。这时各部门一片抱怨声：

1. 管理层说：项目管理工具不好用。
2. 产品说：我不用那个Wiki写需求
3. 设计说：版本控制对于PSD这种大文件兼容不好
4. 开发说：我们不用 Docker，而我们也不用 maven
5. 测试说：怎么随意部署环境，我们还没有测试完，就清空数据了。
6. 运维说：我不敢用你的自动发布

改变现有的工作方式是非常痛苦的，任何不合理的流程和工作方式已经使用了多年，习惯已经根深蒂固。

实施devops 需要各部门收集意见，对各个部门培训，等各部门理解了 DevOps 原理和流程后，才能实施。

如果判断你的团队已经成功的实施了  DevOps ？

判断标准是：

1. 项目管理，产品，设计，开发，测试，运维已经变成一条流水线。而不是每个部门独立工作。
2. 在生产环境上使用 DevOps ，而不是紧紧给开发和测试人员用是
3. 自动化程度
4. KISS（Keep it Simple and Stupid，简单就是美）原则是最重要的

延伸阅读《Netkiller Web 手札》《Netkiller Testing 手札》《Netkiller Linux 手札》

版权声明

转载请与作者联系，转载时请务必标明文章原始出处和作者信息及本声明。