注：该文为我对网上发布的DevOps知识库Ledge的一个阅读笔记整理。Ledge(源自 know-ledge，意指承载物)知识平台是基于我们所进行的一系列 DevOps 实践、敏捷实践、精益实践提炼出来的知识体系。
DevOps知识框架概述
对于DevOps研发运维一体化，我在前面也写过了不少文章，包括了基础知识，敏捷研发，持续集成和交付，流水线设计，DevOps和容器云的集成，开源工具集，DevOps能力成熟度模型等方面的内容。
对于DevOps我在前面文章已经强调是企业进行数字化转型，微服务架构转型，云原生解决方案实践的一个关键内容。但是DevOps本身不是简单的类似配置管理，测试，构建，持续集成，发布等开源工具集的集成，更加重要的是整个开发组织敏捷文化的改进。
为何发布了这个框架?
简单来说就是企业数字化转型过程中，究竟对如何实施DevOps，自己应该先做哪些基础技术积累，应该采用哪些开源工具，整个研发管理和开发过程如何改进，实施应该如何分阶段循序渐进等并不清楚。
这就导致很多企业在实施DevOps的时候往往仅仅是个别的开发小组或项目在进行一些敏捷和持续集成的实践，而很难将整个DevOps上升到组织级，形成组织过程资产。
这个知识框架，从发布者的介绍主要包括了如下节点：
- DevOps 工具元素周期表。帮助您进行数字化时代的 DevOps 工具选型。
- DevOps 设计工具。帮助您设计组织内的 DevOps 流程，涵盖了流程、人、工具、制品等等。
- 案例学习。从社区的知识库中，我们总结了传统企业走向 DevOps 的经验，并浓缩到易于使用的内容和材料中。
- 最佳实践。我们从海量的 DevOps 内容中，提炼出了一系列的最佳实践，以更好地帮助企业进行 DevOps 实践。
- 模式与原则。基于我们的实践，我们提炼了位于它背后的模式与原则，帮助个人和组织更好地了解 DevOps 文化。
- 操作手册。只凭实践与原则，无法让中小型 IT 团队进行 DevOps 转型，所以我们准备了详实的操作手册，以帮助您一步步前进。
- 度量。KPI - 度量、度量 - KPI、KPI - 度量，帮助您更好地度量 DevOps 转型情况。
- 报告。我们尝试从丰富的 DevOps 报告中，提炼出有用的实践和工具。
- Mobile DevOps。我们相信移动应用的 DevOps 改进，才是大多数公司的挑战。
- 工具。工具，工具，工具是最好的生产力，工具比人的记忆力更加可靠。
今天重点是对当前已经发布的内容做下初步分析和整理。
DevOps流水线定制
不同的企业在实施DevOps的时候可以根据企业实际情况定制不同的流水线。
注意流水线设计最基础的是要实现持续集成和持续部署能力，里面涉及到最基本的内容包括了源代码和配置管理，编译构建，自动化部署。
在整个DevOps最佳实践中实际包括了敏捷研发和过程管理，因此可以看到整个DevOps流水线涉及到了类似Scrum敏捷研发工具之间的集成。而集成的重点主要是组织，团队，产品，项目，项目版本，任务，缺陷。
原来谈的比较多的是CI/CD，即持续集成和持续部署。而在DevOps实施中谈的比较多的是持续集成和持续交付。持续集成过程不包含最终生产环境面向客户的部署和交付过程，而持续交付则单独出来。
持续集成和持续交付的分离，也带来了流水线设计上的区别。简单的流水线你可以从编译构建，一直编排到测试验证到生产环境发布。而在持续集成和持续交付分离后，往往交付流水线需要进行单独设计。
其次，在DevOps和容器云集成的时候，整个自动化部署过程发生了变化，即编译构建完先制作镜像，推送到制品库，然后再从制品库提取镜像+配置信息进行部署。因此在这个阶段还涉及到和容器云的集成，比如常见的实现和Kurbernetes的接口集成等。
在完成了基本的敏捷研发+持续集成+容器云集成这条主线后。还剩余两个重点，其一是测试和质量管理，其二是后续的监控运维。
对于测试和质量管理包括了很多内容，从上面的DevOps元素周期表的橙红色部分也可以看到这块占据了相当大部分内容。如下：
- 静态测试：代码规范性检查，安全检查，漏洞扫描
- 自动化测试：单元测试，接口测试，UI界面自动化测试
测试本身是一个系统工程，需要覆盖从测试场景分析，测试设计，测试执行，测试评估完整生命周期。中间还需要对测试用例脚本，测试数据等进行管理。
而从DevOps实施角度，更多的是考虑整个测试过程如何自动化，通过将测试过程集成和编排到整个DevOps流水线执行过程中，真正实现研发和QA之间的自动化协同能力。
案例学习
这是一个大的版块，但是实际上这块的内容相对的薄弱，或者说有点乱。虽然整体给出了类似招行，中行，携程，阿里，华为，小米，美团相关的案例，但是整体都很单薄。更多的介绍内容没有，还不如直接看案例介绍里面链接到的具体企业演讲PPT。
上图是大型银行DevOps转型给出的几个阶段，其中给出了三种典型路径如下可以作为参考：
- A. 团队级敏捷：以小团队为单位开展敏捷转型，当试点结束后，组织往往会继续拓展敏捷转型的范围，鼓励更多的团队加入敏捷的阵营;
- B. 产品级敏捷：以整个产品的价值流为单位开展敏捷转型。产品级敏捷意在拉通产品价值流的上下游，将相互依赖的团队纳入同一个敏捷框架里;
- C. 业务级敏捷：经历了团队级敏捷到产品级敏捷，产品从无到有，直到产品发布的整个过程都已纳入了敏捷范围。但是这还不够，一些支持部门，比如人力资源、行政、财务、市场和销售等部门也应该被纳入敏捷转型的范畴。
在华为的大规模敏捷开发实践案例里面，给出了大规模敏捷实施DevOps的14条最佳实践也可以作为参考：
- 实践 1：组织结构和产品架构螺旋相适配;
- 实践 2：Two pizza team，全功能团队，特种作战;
- 实践 3：按周迭代，小步快跑，持续规划;
- 实践 4：服务自治，独立需求排序，开发，部署上线;
- 实践 5：兼听则明，持续规划，价值排序;
- 实践 6：与客户联合敏捷，众创，对齐客户商业价值;
- 实践 7：架构解耦，服务 / 微服务化;
- 实践 8：云基础设施下，猴子军团出没，耐抗才能高可用;
- 实践 9：兼顾效率与安全的软件仓库，高速下载，便捷实用;
- 实践 10：自动化流水线，缩短上线时间，Built-In Quality;
- 实践 11：企业级仪表盘，基于数据科学决策;
- 实践 12：运维、监控、运维专家经验沉淀到系统;
- 实践 13：灰度发布，友好 / 公测，运营运维配合;
- 实践 14：VoC 驱动，持续规划，数据分析，动态调整，有错就改。
企业组织级DevOps和大规模敏捷实施不容易，从scrum敏捷方法论到SAFe大规模敏捷框架，再到DevOps过程实践解决方案，整个敏捷方法论从开发团队到整个企业，整个团队也从几十人扩大到上百人甚至上千人的规模。这个时候需要就是组织架构设计，开发团队的划分，开发团队和整个持续集成过程的协同等。
而一个好的DevOps案例学习和最佳实践至少应该包括如下内容。
- 问题和现状分析，关键诉求
- 期望通过DevOps达到的目标
- 组织团队设计，研发过程设计
- 开发框架选项和架构设计
- 持续集成和持续交付最佳实践
- 测试最佳实践
- 后期自动化监控运维最佳实践总结
- 整体实施效果和收益分析总结
DevOps原则和模式
数字化技术(信息技术)的本质目的是创造价值，它的载体是软件，提供价值的是功能特性。越早发布功能特性，便能越快创造价值。采用逐渐增加功能特定的增量式开发方法，能让我们在最短时间内开发出最小可用(MVP)产品。
围绕它周围的优秀技术实践，可以让我们开发出运行良好的软件，并且设计也是好的。这个过程需要自上而下的为之付诸行动。
这块的内容整体给我启发比较大的还是如果构建DevOps文化和学习型组织，里面又涉及到整个知识体系构建，组织和团队人员能力模型和技能评估，架构金字塔等。
架构金字塔，即把软件架构按照不同的粒度进行分组。通过分组的细分，我们能有针对性地对系统架构，进行更好的管理和设计。
一个软件系统是由一系列的应用组成的，而一个应用则由一系列的模块组成，进一步的模块是由代码组成的。举个示例，一个现代的系统是由一系列的后端服务、客户端应用组成的;拆解开一个微服务，则是由一系列的模块组成的。
对于复杂软件系统，需要进行分层和分级，如下：
- 系统级，即整个系统内各部分的关系，诸如于如何通讯，以及如何与第三方系统如何集成等。
- 应用级，即单个应用的整体架构，及其与系统内单个应用的关系等。
- 模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。
- 代码级，即从代码级别保障架构实施。
对于DevOps原则模式这块内容，整体感觉分类还是欠缺，整体还是应该基于组织团队，研发过程，持续集成交付，测试管理等关键过程域给出可行的原则和模式。
对于信通院发布的DevOps能力成熟度模型还是可以作为一个重要的参考标准。该系列标准分为敏捷开发管理、持续交付、技术运营、应用设计、安全风险管理、组织结构及系统和工具等部分，涵盖了软件开发到运维的全生命周期，如下图：
整个评估模型我可以看到融入了多方面的内容，核心是如下三方面
- 研发项目管理和敏捷研发方法论
- 软件工程，特别是持续集成方法论
- IT管控和治理，包括对原来ITIL思想体系融入
在这三方面以外，我们又看到整个成熟度评估里面很多评估要求的达到本身又希望你采用微服务架构思想，通过容器云来实现持续集成和交付等。这也和我们经常谈到的，微服务和容器云是实践DevOps的另外一个关键要素。
DevOps最佳实践
实际上对于案例学习和最佳实践本身是相互融合的内容，案例很多就是最佳实践。一个DevOps的实施往往涉及到持续集成交付，自动化测试，敏捷研发多个过程域的最佳实践。当然这些最佳实践的侧重点可能不同。
但是所有的最佳实践仍然是围绕DevOps成熟度模型展开。
- 比如你可以只讲自动化测试过程的最佳实践，讲清楚自动化测试过程如何和敏捷研发，整个DevOps流水线持续集成融合在一起实现完整过程的自动化。
如果要将最佳实践分离，应该包括：
- 敏捷研发过程最佳实践
- 持续集成和持续交付最佳实践(配置管理，流水线，工具链集成，制品库，灰度发布等)
- 测试管理和自动化测试执行最佳实践
- 微服务架构改造和DevOps集成最佳实践
- DevOps和容器云集成
- 自动化运维和监控
以上即是最佳实践的一些关键内容点。
DevOps实施手册
知识框架里面将DevOps实施分为如下几个关键步骤：
- 建立愿景与方向
- 度量：组织、系统现状
- 准入条件。查看是否满足实施 DevOps 的准入条件。
- 探索可行方案。即 MVP 尝试
- MVP。一次快速的 DevOps 过程和结果的 showcase。
- 精细化 DevOps 实施
- 回顾优化
- 规模化 DevOps 落地
在前面我就谈到了DevOps实施本身可以分为几个阶段，从最开始的单纯实现持续集成到后续的敏捷研发过程集成，容器云集成，持续交付能力提升等。
当重新思考DevOps的时候，实际上DevOps的实施往往伴随着微服务架构的改造和优化实施，容器云的改造和实施等。即最终实施的是一个完整的云原生技术平台和解决方案，而不是一个简单的DevOps持续集成和交付过程。
从这个意义上讲，DevOps实施实际包括了敏捷研发过程改进，持续集成和持续交付，微服务架构和开发标准规范体系，自动化测试，自动化运维等关键内容。而所有这些内容的实施仍然需要在前期先进行现状分析评估，给出差距分析。然后再结合差距分析情况给出具体的实施演进路线设计。
简单总结
虽然当前DevOps知识平台还不够完善，但是仍然给出了从DevOps基础知识概念，到能力框架，案例和最佳实践，实施路线指引的完整知识架构框架。
个人建议该知识平台还是围绕DevOps能力成熟度模型进一步树立和结构化完善。并对最佳实践里面的一些案例进一步文字化总结和梳理。
