DevOps培训的三个价值

1、识别无效的工作方式（反模式），在错误的方法上花再多的时间也无法得到理想的结果。

2、建立团队共同的认知--这是协作的基础。而DevOps是关于协作的工作方法。

3、消除软件交付中的明显的浪费。当你意识不到浪费时，你就会对明显的浪费熟视无睹。

DevOps培训给企业带来什么？更频繁的交付？更高质量、更安全的交付？更快的价值实现？还是更高的组织绩效？

这些都有可能。但并不容易。作为一个团队，需要持续、渐进地改变。在你的组织中，你有多大能力影响这一改变？

好消息是，你可能不必完全依赖于遥远的、过于超出你影响范围（除非你是CIO甚至是CEO）的目标。可能改变就是来自于你原来错误的认知。

在我自己的DevOps培训中，最能让我看到学员 “啊哈“ 时刻（也就是突然 “眼前一亮” 的时刻）的是：

• 团队意识到自已一直以来的分支策略其实是低效甚至是反模式的，比如长期维护一个发布分支。
  

• 团队意识到原来更好的环境管理是每次通过一个脚本（在流水线）重新构建以及随后销毁，而非持续更新现有的环境。
  

• 团队意识到测试其实是一种反馈，结对编程也是，代码评审也是，TDD也是。质量内建其实是一个层级的系统。
  

• 团队发现数据库模式和数据的迁移，包括回滚都应该嵌入到流水线中执行，而不是作为发布时一个单独的活动进行。
  

• 团队发现微服务没有达到其效果：如果还是需要一个发布前的集成环境，而这个环境还通常伴随着代码冻结和大量的依赖关系管理。
  

• …

作为一名讲师，当然希望看到 DevOps 的所有实践（比如，在 EXIN DevOps Master 中，归结为24项核心能力）都能在组织中渐次根据重要性实现，但是受限于资源投入、领导者的认识、业务类型，往往很难做到（比如银行就不喜欢持续部署）。

DevOps的24个能力项

但是，组织可以有意识地消除浪费，而就像健身减脂一样，如果你保持着错误的认识（比如，你认为特别锻炼某个身体部位就能减少附着在该部位上的脂肪。不管你再怎么卷腹也不会特定消除腹部脂肪。），那么你的努力可能很难获得好的效果。

所以，大多数企业的DevOps的培训应该聚焦在：

• 建立软件交付工作的正确模式，让组织避免在反模式上花更多时间（你永远达不到期待的效果）。
  

• 聚焦在消除浪费上。就如同我上文中提到的“啊哈”时刻中的哪些认知。大多数IT组织的交付可以满足业务（不然已经被Fire了吧），所以全面实施DevOps的动力往往不足，但是消除浪费？每个团队，每个组织，每一天都可以做到。
  

• 建立团队共同的认知。包括术语、什么是好的实践，当前影响工作效能的最主要的卡点等。当然团队最好制定计划一起推进。这些都是只有团队达成共同认知才能带来的结果。

“A3计划-DevOps实施路线图” 画布帮助建立团队共识