现在IT的新概念越来越多，要掌握这些概念不容易，但如果从概念的发端开始研究，理解第一性原理，也许能更好的理解这个概念的本质，从而更好的与既有的知识体系进行融合贯通，这样才能记得牢，用得好，学习之道大致如此吧。
在我刚开始接触Devops的时候，也是不太能理解其本质，因为Devops的实践大多发生在OLTP领域，而自己一直从事OLAP的工作，当公司很多人开始谈SCRUM、谈CI/CD的时候，自己也是一脸懵逼，觉得跟自己的数据工作隔着十万八千里。
现在自己开始从事数字化转型等相关工作，需要能够充分利用云的优势来助力企业应用和业务发展，这就是云原生，而云原生配套的敏捷开发模式，就是Devops。
然后我去刨根问底了DevOps，才发现DevOps与自己从事的数据治理、数字化转型都在解决同样的问题，只是领域不一样而已，但底层逻辑是相同的。
谈到DevOps，就必须从敏捷和精益开发说起，因为DevOps借鉴了其中的方法和理念，并发展和完善了它们的实践体系。
1、敏捷软件开发
敏捷概念在2001年出现，一方面源于传统方法变得臃肿笨重，另一方面则是进入互联网时代后，软件业对响应变化和创新的要求迅速升级，行业需求是敏捷的最好助推剂。
敏捷宣言发布后，敏捷成为了一场运动，其中Scrum和极限编程在实践上最为成功，影响最大。它们都是迭代和增量的软件开发框架，区别是Scrum只包括管理实践，而极限编程则同时涵盖工程和管理实践。
但是，早期的敏捷专注的还是研发交付阶段，似乎跟部署和运维谈不上关系。
2、精益产品开发
精益思想最早源自生产制造领域，根源于丰田在产品制造中管理和工程实践。精益思想将精益定义为：有效组织人类活动的一个新的思维方法，目标是消除浪费，以更多地交付有用的价值，包括有5个原则：
1、定义价值：站在用户的视角定义什么是价值，并把它描述为具体产品或服务;
2、识别价值流：识别和映射创造价值的流程步骤，消除不增加用户价值的步骤和活动;
3、让价值持续流动：让用户价值在流程步骤中流动起来，是它们持续、顺畅地流向最终用户;
4、用户价值拉动：由用户价值拉动流动，避免不带来用户价值的浪费;
5、精益求精：不断重复1到4步，追求完美的价值和价值流动，消除过程中所有浪费。
在这个抽象层次上，精益思想超越了其诞生的制造业，深刻影响了各个行业，这其中也包含产品开发，事实上，主流的敏捷开发方法都直接受到了精益思想的影响，遵循精益的基本原则。
与此同时，精益产品开发作为独立的实践体系快速发展，聚焦两个方面的目标：价值交付过程和价值本身。
第一：关注价值交付过程，比较有代表性的是“精益看板方法”，从关注资源的使用效率，转变为关注价值的流动效率，从局部优化转向端到端全局优化。
第二：关注价值本身，比较代表性的是”精益创业“，把价值的探索和发现融入产品交付过程，提出了”开发-测试-学习“循环，第一步即最小可行产品;第二步基于最小可行产品收集反馈并获得测量数据;第三步用数据验证假设并加以调整，持续探索商业模式和产品功能设计。
3、Devops的诞生
敏捷和精益社区都还只是关注开发侧的实践和行为，运维并没有成为他们关注的重点，但是从价值的角度看，开发和运维才构成相对完整的IT价值链，当然更完整的还包括业务。
在传统IT组织下，开发团队和运维团队之间的诉求不同，开发团队(尤其是敏捷团队)追求变化，运维团队追求稳定，双方存在利益冲突，部门墙由此建立，这不利于IT价值的最大化。为了弥补开发和运维的鸿沟，需要在文化、工具和实践方面的变革，DevOps正式登上舞台，DevOps的理念开始流行，其相关工具和实践也快速发展，期间以容器化和自动编排调度为代表的云原生技术出现也极大加速这一进程。
Kim等人总结了Devops实施的三步工作法：
流动原则：聚焦 IT 系统的整体价值流，全局优化，保证价值从左(上游)到右(下游)的快速流动;
反馈原则：创建从左到右的反馈循环，并缩短反馈周期和放大反馈效果。这样，就可以更快的响应和理解内外部客户，并即时获取改进所需的知识;
持续的实验和学习原则：创建承担风险、持续实验并从错误中学习的文化，在不断的尝试中精进能力，并提高系统的韧性。
Kim等人认为，这三步工作法是其他一切DevOps流程、实践的价值和哲学根基，稍作研究，就能够觉察，DevOps三步工作法是精益原则的翻版。
我读完这一章节的时候，才恍然大悟，原来挺IT的DevOps起于这么朴实的思想，这个思想大家都在用，因为它是非常底层的东西，即流程的高效运营。
而数字化转型的核心是什么，可以看看华为数字化转型的这篇文章《华为董事陶景文：任何不涉及流程重构的数字化转型，都是在装样子!》，讲的就是流程和价值，核心观点如下：
1、任何不涉及流程重构的数字化转型，都是在装样子，这句话就是在说，数字化转型一定先不是以技术为核心的，更主要是生产关系的调整，这个跟Devops的第一条，精益思想的第二条，第三条原则相符。
2、数字化转型一定是业务战略驱动的，一定是先折腾业务，业务站位越高，可能的效果就越大，不要为了转型而转型，这个跟Devops的第一条，精益思想的第一条原则相符。
3、数据要实时反馈，不光是在事后的统计报告发挥价值，而且可以在预测、分析、过程的干预和事后的回溯，全过程更加充分的发挥价值，这个跟Devops的第二条，第三条，精益思想的第二，第五条原则相符。
企业为实现价值创造，从输入客户要求开始到交付产品及服务给客户获得客户满意并实现企业自身价值的E2E(端对端)业务过程就是业务流。业务流天然存在，适配业务流的流程会带来价值提升，是优秀作业实践的总结和固化，推广流程的目的是让不同团队执行流程时获得成功的可复制性。
我们数字化的有很多阶段，从线下到线上，从线上到在线，再从在线到智能，所有这些都是围绕流程开展的，我们最终的目的就是基于数据驱动让流程全局最优，从而创造更高价值。
DevOps只涉及IT条线的一个流程重构，而数字化转型针对的是所有条线跟业务价值创造相关的业务流的重构，这些业务流的重构需要有文化、工具方面的支持，正如DevOps需要的那样，可以这么说，Devops是数字化转型在一个领域的最佳实践。
我现在在做的数据治理，其中最核心的一个工作就是流程重构，主要围绕数据从产生、汇聚、处理、开放和消费这一系列流动的优化和重构来推动数据要素高质量的流转。
理解了这三者在底层相通的逻辑关系，就可以产生1+1>2的效果，比如我知道数字化转型需要经历线下、线上、在线、智能等四个阶段，就可以将这种演进策略复制到DevOps领域，而如果直接看DevOps的各种专业书籍，会被各种“术”的操作晃得看不清楚方向;又比如DevOps为了做好协同，让运维提前介入软件设计评审，那我在数据治理的时候也可以如法炮制，将数据字典的编制要求前置到系统立项和设计阶段。
希望于你有所启示。