由来

无从说起

最早2008年

Dev有敏捷了，Ops还没有，想法就是通过敏捷的方法来做运维的事情。

DevOps实际上是个帽子，DevOps工具就是老的软件工具的一些工具，只是借用了新名词。

《凤凰项目》

所有的DevOps都调速度，因为速度在软件研发里面是评估整个效率非常重要的指标。

计划和目标是为了约束变化，现在是为了适应变化。

DevOps不是工具，不是方法，是来自实践的经验。

好的架构不是设计出来的，而是演进出来的。

价值体系

价值-》原则-》方法（SCrum，kanban…） =》实践（infrastruct as code,….）=》工具（CI、CD工具，环境编排，监控工具，虚拟化和容器，全生命周期管理工具）

基础设施即代码-DevOps实践考量

也叫作Configuration as Code，让运维团队将运维服务转换为运维能力提供给开发团队。让开发团队像引用代码一样引用运维能务。运维团队以此来隔离环境的稳定性。通过这种方法开发团队将业务价值更快地交付给用户，实现研发和运维的整体敏捷。解决硬件资源要不要给开发人员，如何受控的问题。运维人员不再做重复性的工作。

支撑的工具链：源码管理工具（程序代码，环境代码）-》CI Build（编译，打包，单元测试，资源包含） =》Cloud（编排平台，都是描述目标环境，即DSC，理想环境状态管理）

实施策略框架

人：涉及哪些人，要哪些技能
过程：人与人如何交互，流程如何才合理
工具：工具如何支撑，哪些工具，工具和工具的关系，工具和人之间的关系

研发效率的衡量指标

生产能力
- 发布频率：多久发布一次
- 发布时长 release lead time：从代码完成到真正进入生产需要的时间
稳定性指标
- 平均修复时间(MTTR) mean time to recover：如何在最短时间解决生产上发生的问题

部署 VS 发布

部署到环境
发布给用户
研发效率单位：每次发布

质量左移 Quality Shift Left

Plan -》Do-》Stabilization

方法和框架都是为了能够左移，也就是在更早的时间发现问题。

devopsmmg-1

UDAD的实施框架

什么才是软件的生产制造过程？

udad-slide-2

传统的软件开发方式是错误的，犹如一辆汽车，闭眼开车想像着开眼就能到达目标的，但实际上不是。使用统计软件过程方法，成功率非常低，只有20%，在时间、成本、质量上满足了要求。

基于敏捷的开发方式才是正确软件生产方式。

敏捷让我们重新定义管理。传统研发更关注于内向型指标，没有从整体性上考虑问题。DevOps要求我们具备全局观。

有个老者去理发，30块钱，第二次只理发就让他滚蛋，还是30，第三个月，又有全套服务，第四个月又只有理发。所以他质疑30块全应该是怎么样的服务？

质量到底是什么，不是越多越好，而是与目标用户达成的一个预期是否是一致的，从软件角度讲，并不是所有bug都需要修复。所以很多内向型指标并没有意义，其实是没有理解软件的质量到底是什么。

agile-compare

敏捷就是给了一个提前的方法。

如果想要加速开发的时间，则前提是把需求弄好，拥有好的需求质量，当需求越能抽象的解题(注意不是明确的解题，一旦太明确化就失去变化的能力了)，抽象解题提供了巨观上的 Big Picture, 让我们能够看见全貌，然后据此拟定正确的开发方向，方向对了返工(rework)的次数自然变少，减少了在返工时所浪费的时间，减少了浪费的时间开发作业也就自然地变快起来了。

为何要抽象化呢? 因为抽象时比较能包容那些属于不确定的因素，也就是未来还没发生的事情，他可以减少我们提前做决策时的方向偏差。而敏捷开发对抽象化最大的贡献大概就是采用使用者故事(User Story )来描述需求了，它实现了我们用抽象化来做快速解题的能力。如果你尚未或是正准备进入敏捷开发的领域，记得从需求开始，而需求的撰写请不要忘了采用使用者故事。

如果一定要把敏捷开发说成是一种快速的开发方法的话，则应该要正名成〝一种快速处理需求变化的方法〞。是的；用来处理改变需求它就变得快得不得了了。原因是它在迭代中采用了使用者故事作为需求描述的方法，所以比起传统的文件规格更能应付需求的变化，更加拥有弹性，所以特别能够变通。而你运用使用者故事来描述需求的好坏，也决定了你应付需求变化的速度及能力。

用户故事：提供一种抽象化的需求描述，让最终用户与开发人员便于透过讨论来统一彼此对需求的认知。

需求不是用来写的，是用来沟通的。用同样的方式来沟通问题，建立统一的认知。人类不擅长记忆细节，但是善于记忆感觉。

文档不是不要，还是重要，只是工作的软件高于文档。细节还是在文档。让软件的质量从起点就能得到控制。