在DevOps中，通常使用“道”、“法”、“术”、“器”这四个方面来总结其核心概念：
“道”是目标、价值观，对价值的定位。快速交付价值，灵活响应变化，这是从价值层面的追求，或者是从第一性原理的角度来讲，我们做这个事情最终目标是什么；
“法”是实现价值观的战略、方法，这个层次的主要思路是全局打通敏捷开发和高效运维。
“术”是战术、技术，最佳实践的层次，我们要系统化的应用有效的方法、合适的技术，很多最佳实践帮助我们实现DevOps。
“器”是工具层次，主要思路是用工具提升效率，将复杂的问题简单化。因为上面的层次有了很好的技术和方法，我们最终要把它落地、固化到工具平台上，并且希望实现整个软件交付流程端到端相互融合和贯通。
道、法、术、器自上而下是系统思考的层次，自下而上是解决问题的层次。我认为DevOps的规划和实施可以用这四个层次来概括。
1、道
首先是“道”的层次，主要目标是快速交付价值和灵活响应变化。谈到敏捷，谈到DevOps，可能第一个诉求就是要快速交付价值。在互联网的时代，交付的速度是非常关键的。
原来的瀑布模型需要等到最后一个环节实施完成才向用户交付价值，而敏捷和DevOps倡导小批量、增量式的交付价值，这就使交付价值的速度、面向市场的频率得到大幅提升。
在价值交付这个层次，我们最终希望达成一个目标，就是通过DevOps打造一条高度自动化的IT服务供应链，能够快速、高质量地交付用户的价值。
2、法
左侧这张图来自DevOpsMaster的知识体系，主要讲敏捷、持续交付、精益、ITSM这些方法的适用范围和相互关系。
3、术
“术”的层次的主要思路是系统的应用各类技术、指导原则和最佳实践。这个层次涵盖的内容就非常多了，我们可以通过一张图来展示。
在工程维度也对应了很多的技术和实践，包括配置管理、自动化测试、持续集成、持续交付、灰度发布、持续监控等等。以上这些组成了我们“术”的层次。下面来看一下工程维度的内容，首先是持续交付框架。
除了框架的指导，我们还有很多最佳实践的集合。
上图是持续交付的光谱图，发布频率从100天发布一次到一天发布多次，所采用的分支模型、测试模式、系统架构、发布模式、基础设施和数据库的管理模式，都会有很多的实践需要变化。
我认为作为我们从业者来讲，是非常好的指导和参考，如果希望将交付的频率变得更快，稳定性变得更高，需要把这些实践调整和落地。
4、器
“器”是指工具的层次，工具需要把上面层次提到的方法、实践固化和落地。工具通用需要考虑很多维度，比如说管理维度、工程维度、基础设施维度，而最重要的，是要把这些工具做很好地联通和整合。
这四者之间存在密切的关系，它们相互依存，共同构成了DevOps的综合框架。下面是它们之间的关系：
道与器的关系：文化也影响了对工具和技术的选择。在一个注重自动化、持续交付的文化中，团队更有可能选择并有效地使用支持这些实践的工具。文化塑造了对工具的需求和期望。
法与术的关系：实践和方法直接影响了工作流程和流程的设计。持续集成、持续交付等实践的采用会直接改变团队的工作方式，推动流程的优化和自动化。
术与器的关系：工作流程和流程的设计需要相应的工具来支持。例如，如果团队决定采用自动化测试，就需要相应的测试工具。工作流程的改变通常需要引入或调整使用的工具。
总的来说，这四个方面相互交织，互相支持。文化为实践和流程提供了基础，实践和流程指导了工具的选择和使用。而工具的支持又促进了实践和流程的实施。成功的DevOps实践需要平衡并整合这四个方面，以实现持续交付、高效协作和自动化。
二、平台工程的三大支柱
根据流行定义：平台工程是一门设计和构建工具链和工作流的学科，软件工程师团队在这些工具和流程的帮助下，获得自助服务的能力。这些工具和流程被称为内部开发平台，经常会被简称为平台。平台团队的目标是提高开发生产力、加快发布节奏、提高应用稳定性、降低安全及合规风险，以及降低成本。
以我所见，平台工程面在三个方面为组织提供支持基础设施、规范和工具：
现代软件运行需要大量的基础设施，除了传统的网络、计算、存储之外，还包括大量的服务化
的中间件等能力，OpenStack、Kubernetes等资源编排工具也属于是传统管控难题。平台团队可以综合基础设施自有的管控运维能力，使用Terraform、KubernetesCRD、等资源抽象和自动化手段，为开发团队及其产品，规划、搭建、自动化和优化可靠、安全、高性能的基础设施，以支持业务的运行和发展。
企业IT环境通常会有一系列的规范，例如设施命名、账号管理、IP分配等等；另外操作系统、容器集群等具有极大灵活性的基础设施，也通常是需要有一定的规范化管理的，这里提到的规范至少包括：
平台工程的主要产出就是一个被称为idp（内部开发平台）的工具，以此工具为开发团队提供支持，在实际工作中，工具部分的工作内容至少包括：
三、工具平台设计的四个原则
1、自动化
自动化：自动化很好理解，DevOps讲究”自动化一切”，这正是DevOps精髓”CALMS”中的A（Automation），研究表明高效能企业在自动化构建、自动化测试、自动化环境创建和部署、自动化监控和可观测性等方面要远远高于中低研发效能企业；
2、自助化
自助化：自助化代表上下游角色可以通过平台紧密衔接，工具平台被某种角色创建出来之后，上下游其他角色应该都可以按需、自助地使用，降低了对于某种角色或者某个人的依赖，这样组织协作效率才能提升；
3、场景化
4、生态化
生态化：在互联网大厂搭建研发效能平台普遍遇到的难点就是业务复杂、规模庞大，业务独特、场景众多，很难通过一个团队的努力就能满足整个公司的需求。但是各个业务部门如果什么都自己做、重复造轮子、甚至相互恶性竞争就更不好了。所以，作为平台建设者应该更加开放，分离平台底座和原子能力的建设，即通过生态合作伙伴关系，促进公司研发效能平台的良性发展。从公司角度来看，减少重复建设和避免内耗，也都是'反内卷'的表现。
要落地上面四个原则，需要实现三个可编排
1、基于角色场景的作业桌面的可编排
用户可以基于角色自定义工作桌面，工作桌面可以基于卡片自助自定义编排，工作桌面可以展示任务待办，数据可视等内容，点击卡片可以进入对于应用。
2、基于业务流程的应用可编排
用户可以根据产品和项目差异，自定义业务流程和进行应用编排，研发工具提供统一应用管理平台
3、基于流水线的自动化运行可编码
流水线平台提供自动化原子服务管理能力，流水线流程可编排，自动化调用。