首先，找到二者的边界，主要有三点，持续交付，持续交付的边界需要泛化持续集成和持续部署，第二是业务监控，业务监控的范围需要涵盖研发组织和运维组织，第三是容量管理，容量管理可以从成本的角度对研发的资源预测和实际的线上表现进行评估。从本质上来说， 一个DevOps平台需要提供对源...

首先，没有进行低代码平台的引入，CMDB的功能并不包括组件丰富性能力，但具备数据的丰富性能力，将CMDB作为IT数据的集散中心，或IT服务目录的数据中台，涵盖了IT管理数据，运维领域、研发领域、安全领域、需求领域、测试领域的数据，可以通过数据的关联和映射，实现丰富的数据场景，供给DevO...

我的理解devops落地，需要这几个工具的支持：1，微服务的架构，包括微服务基础组件等2，容器以及容器平台3，持续集成、持续发布4，监控综上，我推荐的开源工具是Kubersphere

个人看法，Devops体系下对网关模式选择，实际是一个上层建筑决定下层基础的情况。上层原云生平台的架构模式选择，决定了是否会使用集中存储？如果完全采用分布式架构，那么存储网关没有用武之地。如果Devops体系中，部分业务还有较重的IO，特别是关系型数据库类的，那么可以考虑集中存储...

devops开发运维一体化是有一定适应条件和适应范围的，也并不是只有好处没有坏处。我觉得这适用于频繁更新优化且各方面规范比较好的应用系统。通常情况下，开发关注重代码的管理，运维关注执行程序的稳定安全，共同关注业务需求功能的实现情况。devops会增加执行码和网络互通等方...

个人觉得，IT体系中从头到位参加“价值交付”全流程的有两个角色，一个是项目经理，一个是运维，因此这两个角色是进行DevOps推进最合适的。在DevOps工具链中，运维工具是最多的，数据中心，基础架构、云平台，支撑平台，监控，组织体系数据。因此，需要构建运维自动化工具链的工具形成持续交付...

代码评审环节，线上发起，线下评审。度量和分析环节，线上质量监控，线下质量运维。

这种方法只能说是理论。在很多环境中。这种技术债务其实都存在。也都很难避免归结起来可以是有几下几方面。1 如同装修一样。甲方对技术不了解。有时候也没有明确的需求。在项目落地的过程中，往往甲乙两方都缺乏对项目技术的详细规划，这种情况在一些中小企业中格外明显。...

其实基础体系不分细分领域的产品，只分工具链的整合，大致有三类。1、 配置管理系统，如代码库，配置中心，调度中心，路由中心 2、各细分领域的自动化系统，如运维自动化、测试自动化 3、可伸缩的、自服务的虚拟化系统或者容器系统有了这三个，基本上工具链就成型了，怎么组合，那就根据推进...

1、运维左移，理论上说，运维要掌握所有的技能，尤其是基础架构、应用架构、安全架构和业务体系的知识， 左移和右移不一样， 左移是真正的做事， 右移是补救。2、DevOps有自己的组织架构体系，这是以IT价值为目标的组织架构体系，如果说细分领域的角度看看待组织架构，最好的方式是牵头推...