DevOps培训总结（part1）
还记得上周的DevOps Master培训么，小伙伴已经觉得看到价格很震惊吧，不过对于收获来说是巨大的，觉得不值的应该是你学了没办法变现而已！
从我听说敏捷到现在可能也有快10年了，在我看来敏捷很好但是非常不适合国情，主要原因无非是我们自己能力的问题，做不到敏捷所要达到的精干团队，从一开始的基本TDD、PP、CI等都很难做到，哪怕到了现在各种开发模式下来，我能看到开发解耦做好的还是很少很少。而最近几年热门的DevOps也包括我在做的DevOps产品线支持，都是围绕着“后敏捷”，对大家来说看到的都是CI&CD以及DevOps流水线下的工具链，到底什么是DevOps我自己也存在的一些模糊的地方的，而这次培训让我想清楚了很多事情。
首先提出DevOps不是一个工具问题解决的问题，大多数公司在落地敏捷的时候往往是开发按照自己的理解为了快速发版做了一套流程，然后把部署文件丢给运维（测试），然后就和自己无关了。而部署上线出问题后，运维百思不得其解只能再去问开发，结果往往是部署问题（大多数情况是部署流程依赖于人）或者是Bug（开发会推脱为测试的责任或者快速发布的时间问题），而解决的过程就是运维怼开发，开发怼运维。如果这个公司大一点，那么会有个测试部门在中间做一个缓冲，就会成为测试怼开发，开发怼运维，运维怼测试的循环。
上面一张图结合所谓的Facebook没有测试，就可以看到在开发的看法中，自己测了就行了，所以原本的三件马车（Dev、Test、Ops）就只剩下的DevOps了。
那么DevOps究竟是啥呢？引用一下官方文档
DevOps不能简单认为是一种工具、方法、技能或组织结构，DevOps的框架是结合所有这些元素来建立一个流水线的过程，使业务更快地运营，并能更快地应对变化。DevOps还可以通过戴明博士的计划（戴明环）来提升其成熟度。企业级的DevOps不仅仅是增强的敏捷开发和持续交付，同时也通过IT服务管理和应用程序管理来实现和促进业务增长并保障业务连续性。
在这里首先要澄清，DevOps基于敏捷和持续交付，但是并不仅仅局限于此！在我看来DevOps更是以One-piece-flow单件流模式追求Ji-Kotei-Kanketsu (JKK)质量的一种最佳实践模式。
DevOps依赖于3大支柱（敏捷、持续交付、IT服务管理）和1个基础（TPS理念为基础），这里对这个基础做点扩展。TPS（Toyota Production System）包含了JIT（Just In Time）和自动化，希望通过建立一个流水线式的单件流模式来进行生产，而出现问题时能够随时停止。这一段可能会很难理解，简单来说就是要让软件工程中的每一个人成为流水线上的一个小员工，每一个UserStory好比是流水线上的一个最终产品，能够串行的（非并行）拼装，如果中间任何一个环节出现问题都能暂停排查，将影响控制到最小。这个思路和传统流水生产线的思路是几乎相同的，极大的降低了错误修复的成本并更快的交付用户最终产物，配合了工业4.0的定制化需求。
那么DevOps工具链也就是这条自动化生产线，但并不是装一条生产线就能够有效的解决问题；而在整个软件周期以及DevOps中，最关键的人物反而不是开发，更多的时候瓶颈在于测试！开发在10年前已经开始做敏捷转型了（互联网快速发布下的推动，让开发必须走敏捷），运维在5年前已经开始做云以及智能运维了（从100台到10000台服务器的维护，让运维人员必须走智能运维，开发运维），而测试只有在最近2年开始有开发测试的概念，而且仅仅局限在简单的自动化上，试想开发和运维已经将自己的处理能力提升了100倍了，而测试似乎并没有什么进展，这也是为什么在整个DevOps流水线上瓶颈会体现在测试上的原因，简直就是4个王者带一个会点自动化自我感觉良好的铂金（可能还是只会点的青铜）节奏。（关于生产线的问题以及测试瓶颈的问题在后续沙盘项目中进行介绍）
测试欠的技术债还很多，当开发、运维冲在一线在努力的解决问题的时候，大多数测试还在心安理得的做着后勤的工作，现在当测试面临着跟不上就淘汰的局面，未来是光明还是黑暗？
我很看好，而你呢？
（未完待续）
关于TestOps更多优秀文章：