一步步实施 DevOps （一）
Netkiller Management 手札
Mr. Neo Chan, 陈景峯(BG7NYT)
中国广东省深圳市望海路半岛城邦三期
518067
+86 13113668890
<netkiller@msn.com>git
Copyright © 2010-2018 netkiller程序员
版权声明github
转载请与做者联系，转载时请务必标明文章原始出处和做者信息及本声明。编程
|
|
|
|
什么是DevOps?windows
首先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 和 云计算思想的提出，软件也在发生变化，软件运行不在限于一台物理机，而是多台服务器的集群中，传统的模块或原件，被独立部署在世界各地。
软件的开发面临史无前例的挑战：
- 异构平台，软件不限于那种操做系统，例如Unix,Linux,As/400,windows,Mac
- 多语言混合开发，不在牢牢使用一种语言开发软件。每一种语言都有他所在领域的优点。
- 分布式，软件不再是只运行在 一个CPU下，软件被分红不少模块被分布式部署到多台服务上。
这时便出现了极限编程，敏捷开发….等等，新的思想不断提出，可是仍然没法解决面临的问题。
- 产品部：需如雪片飞来，需求堆积如山
- 开发部：版本延期，质量问题频发，疲于奔命修复 BUG，刚修复了一个， 又出现新的 Bug
- 测试部：手工测试，升级后问题爆发，测试环境经过，到生产环境就出问题
- 运维部：环境不统一，每次部署都是一场灾难，配置易出错，回撤时间长，
- 团队现状：加班严重，效率地下，天天奔波救火
- 测试环境没法重现，开发人员直接在线上修改代码，跳过测试直接将代码交给运维升级
- 运维事故严重影响运营和广告投放
- 人员流动致使代码丢失
问题的缘由在于，他们牢牢从各自部门的角度解决问题，同时 KPI 考核也不合理：
产品从产品的角度解决产品遇到的问题。
开发从开发的角度解决开发遇到的问题。
测试从测试的角度解决测试遇到的问题。
运维从运维的角度解决运维遇到的问题。
实际上如今的软件已经不是当年交付后一个网管就能搞定剩下的工做。同时软件开发交付周期缩的更短，一周甚至天天升级数次，遇到突发事件要作好随时准备升级。
总结这个时期其实是： 软件项目管理 加 ITSM (IT Service Management) IT服务管理
因此聚焦微观管理解决宏观管理问题的作法是错误的，因而诞生了 DevOps。 DevOps 是多维度宏观管理学，是管理的管理。
开发，测试与运维三个部门的关系
开发，测试，运维不是三个独立部门，他们相互紧密联系，但又相互制约：
开发只负责写程序，将运行无误的程序提交至版本库中
开发不能私自将程序交给运维部署，也不能将编译好的程序给运维测试。
测试部只能从版本库提取代码，而后编译，打包，运行，测试
不容许测试部将代码交给运维部部署
避免代码没有通过版本库流入生产环境，线下与线上代码不一致
运维部负责部署应用程序，配置管理，只接受测试部确认无误的版本，部署代码只能从版本库中提取
开发 -> 测试 -> 运维 贯穿始终。
技术规范的误区
几乎全部的技术企业都会重视技术规范，为此制定各类规范，并要求员工严格执行。同时员工会想出各类对策，就这样造成了潜规则。
流程与规范的制定须要须要知足几个条件，简单，容易掌握，容易执行，可重复执行
企业管理层擅长制定乌托邦式的流程与规范，随便拿出一条都堪称完美，无懈可击，但没有考虑到执行结果，流程规范在执行过程当中每一个环节都会出现问题。
我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 相关的软件所有安装上，而后作系统集成。这时各部门一片抱怨声：
管理层说：项目管理工具很差用。
产品说：我不用那个Wiki写需求
设计说：版本控制对于PSD这种大文件兼容很差
开发说：咱们不用 Docker，而咱们也不用 maven
测试说：怎么随意部署环境，咱们尚未测试完，就清空数据了。
运维说：我不敢用你的自动发布
改变现有的工做方式是很是痛苦的，任何不合理的流程和工做方式已经使用了多年，习惯已经根深蒂固。
实施devops 须要各部门收集意见，对各个部门培训，等各部门理解了 DevOps 原理和流程后，才能实施。
若是判断你的团队已经成功的实施了 DevOps ？
判断标准是：
- 项目管理，产品，设计，开发，测试，运维已经变成一条流水线。而不是每一个部门独立工做。
- 在生产环境上使用 DevOps ，而不是牢牢给开发和测试人员用是
- 自动化程度
- KISS（Keep it Simple and Stupid，简单就是美）原则是最重要的
延伸阅读《Netkiller Web 手札》《Netkiller Testing 手札》《Netkiller Linux 手札》