[干货] DevOps 落地经验十四则（上）

导读：5 月 6 日，优维科技与数人云主办了 [ DevOps&SRE 超越传统运维之道 · 深圳站] ，6 月北京站敬请关注~本文是优维科技 CEO 王津银关于 DevOps 与传统的融合落地实践的精彩分享

第一则：理念与价值先行

☆ 第一、二点 这里面一定不是简单谈文化的，一定谈工程实践落地的因素。

☆ 第三点：端到端持续服务交付流程的改革 这里面不是讲的结果而是讲的过程，process 不是过去讲的 IT 服务流程，把过程的变革，一旦工具进来简化我的流程或者是自动化的流程都带来变革。

☆ 第四点：对新的应用和服务，加快且缩短实现价值交付的时间。

这里面讲的怎么样有一个想法，快速实现这个想法，把这个想法反馈回来，让我持续的改进，不影响安全性和持续性，这一点我觉得蛮有意思的，比如说在国内讲双态运维的理念，双态运维根源上有双态 IT 形态的存在，

但是运维的本身没有所谓的双态的差别，你使用的方法论、工具自动化套路都是一致的，因为我管理的 IT 都是从本质上干几件事情，把命令传过去、文件传过去、数据采集回来，就干这三件事情，本质上这个流程该形成有效的设计，兼容安全和性能的要素。

第二则：顶层设计、全局规划。

这个是之前给一个物流行业做咨询的时候提出来一个模型，DevOps 运维的体系分成 6 个维度＋一个文化，这里面包括组织、过程、架构、工具、基础设施、度量＋文化。

☆ 第一点：组织 DevOps 首先必须打破组织之间的隔阂，其实 DevOps 团队建立面向产品而非项目的协作文化。 ☆ 第二点：过程 过程不是流程，轻量级流程和自动化的工具完美结合，确保企业的高度敏捷性、自动化为先、而后再流程。

☆ 第三点：架构 架构是应用的架构、基础的架构和数据的架构，数据的架构谈起来虚一点，应用的架构和基础的架构是比较明确的，应用的架构更多讲微服务的架构，基础架构是标准化的基础设施，像 Saas、paas 平台。

☆ 第四点：工具 强调的平台层面上，怎么样把 IT 能力平台化，从 DevOps 整个过程构建持续交付的平台，到运营构建 IT 运营管理的平台，都是很重要的，只有它们能够把所有的质量成本和效率几者维度兼顾起来，具备可落地化。

回到顶层设计和平台层面来说，IT 运营管理平台到底应该怎么样的设计？这里面讲到的云数据平台和 iaas 平台。在上面面向不同的 IT 管理过程，我做一些域设计的细分，比如说 ITIL，分成基础、高级的、运维服务平台、研发的服务平台。

☆ 第五点：基础设施 对应的 IaaS、PaaS 部分，怎么样做持续反馈？监控，端到端的监控，从底层的基础设施，到上层的应用服务组建，从基础设施到接口、用户测量的监控这个端到端的能力怎么构建？这个构建成数据采集的基础。

☆ 第六点：度量 今天看监控是面向数据化的思维做监控，今天数据的特征发生了变化，不仅仅是结构化还有非结构化的数据。比如说日志，怎么样把日志当成流式数据的处理？

有了这样的数据采集基础，这里面有分析的平台，结合运维的场景，容量、可用性、业务连续性等等进行分析，结合 IT 的规模形态发生变化，所要看到的指标也会不一样，比如说基于云端要看成本和费用分析都不一样的，需求也不一样的。

IT 服务中心是把整个 IT 服务能力怎么样的目录化，同时结合自动化的工具两者衔接起来。这个讲的变更中心，有一个梳理的方法，现在的传统企业，比如说国信证券，结合 CMDB 管理的对象，把这个管理的对象整理出来，通过 IT 服务中心给变更能力目录化，同时表达标准化，最后对接工具自动化。

再往上可以提供各种的服务编排的能力，这种服务编排是跨越了各种工具的，再往上是构建运维的统一模库。这是顶层设计和全局规划。

第三则：Start Small，从小做起。

DevOps 这么大的体系，大平台上又有这么多，是不是全都要落地？一定要 Start Small，这个准则很好梳理，基于每个角色＋某个场景从小做起，一定要把 IT 部门的角色梳理出来，比如说到运维这边，有业务运维、系统管理员，网络运营。

第二可以基于每个系统和每个功能实施导入，比如说今天就做监控库，我看传统的企业很多做 CMDB 导入，切忌贪大求全，给你画的图景是很美好的，很多人说 DevOps 很好，怎么样落地呢？一定要 Start Small。

第四则：构建元数据基础平台 CMDB

下一个阶段要把它名字改为 IT 资源管理平台，因为我觉得现在需要把 CMDB 的管理资源和职责范围缩小，其实在不同的阶段，我们管理也不能贪大求全，把所有的配置全部管理起来，最后发现自己转不动了。上面的场景又起不来，现在很难把场景构建起来，场景起不来的时候，结果把 CMDB 做死了，我们一直讲这个数据的鲜活性，结果做不起来。

今天我把范围缩小了，只管基础设施的资源和应用的资源，基础设施是属于目前应用的，这个资产状况管理起来我从应用的角度看，到底用了哪些资源？

把这两层的维度强关联起来，然后在应用上层构建应用的各种的管理场景，比如说应用的发布、应用的部署、应用的监控等等。应用的数据分析，由它来进行进一步的驱动 CMDB 的流转，因为在应用的维度上，才符合以前讲的高频的特征。

今天到任何一个组织，其变更的场景来说，应用是最频繁的，比顶层基础设施更频繁。如果符合高频的特征可以理解场景化的能力最强的，场景化的能力强那驱动力就是最强的，今天把 CMDB 转化成 IT 资源管理，以应用的视角看资源。这个平台里它的核心作用是毋庸置疑的，应用是 CMDB 平台的元数据。

这里面怎么样的上层联动？ CMDB 这么多的数据，其实就是一类的实例的数据。比如说这里面到底有多少服务器、服务器有多少的虚拟机？这是实例的数据，然后就是拓扑的数据。我的服务摆在机柜上，介入的上面数据是什么。同样是根据顶层的资源拆出来的，一个基础资源一个是应用的资源，分成实例管理和拓扑管理。

今天很多人讲自动化，其实资源有生命周期的状态，一定不能通过自动化来替代的。比如说这个 IP 地址从资源池里面分配出来给业务池使用，一定要通过一个流程申请出来，无论是自动化的还是以前离线流程的，这是一个生命周期的状态，IT 地址退还不能保留业务使用，这个一定要有流程控制的，这里面自动化不能代替人工的流程，流程是聚焦在事前的管理。

再往上是场景应用，要找各种的场景应用，构建出来这一层做的形象的比喻就相当于今天的地图一样的，比如说百度地图，这个地图可以在不同的场景用，大众点评可以用，滴滴也可以用，今天的 CMDB 也起到这样的作用。这么多场景建设的时候，事件平台是一个很好的入口。

因为今天看到传统的行业太多的监控系统，这个监控系统都要进行收敛，怎么收敛？把所有的监控实践发到统一事件系统，由统一事件系统根据底层的 IT 对象关系自己来进行收敛，现在老的监控系统基于 CMDB 收敛是很难的，基本上找不到监控厂商来修改，提一个需求要带来大量的成本。

为什么一直在讲 CMDB 核心的管理模型是应用的管理模型，IT 形态发生变化了，这个模型不用改变的，不用调整的，比如说是公有云。CMDB 模型的扩展力是把所有的资源管理起来，这个资源分成本地资源和第三方的资源，本地资源是应用部署在同一主机上的资源，比如说程序包、操作系统的版本，使用的内存，或者是这里面的配置的版本等等，甚至在本机占用了端口甚至是接口服务都是我们的资源。第三方资源如阿里云，这些资源都可以通过应用管理维度集中起来。

第五则：痛苦的事情优先解决

基于角色和产品如何梳理管理能力？运维的复杂度为什么复杂？在这儿，因为运维角色太多了，管理的对象太多了，产品太多了，最终出来的能力管理流程也可以太多。开发测试没有如此复杂，开发就开发，测试就测试。这里面一定要通过角色＋场景，最后导出我应该构建什么样的能力管理的平台出来，一定要有这样的思路。

今天讲的运维自动化，最后我变成配置管理或者是工具的自动化或者是调度的自动化，这个远远不够，其实运维自动化弥漫在每一个角色、每一个场景里，今天说的基于容量的自动扩容不算自动化吗？ CMDB 的自动发现不算自动化？基于监控事件故障自愈不算自动化吗？都算。基于这个图把自动化的场景收敛一样，作业和调度的能力是底层平台化的能力，在各个子系统使用。

第六则：工具也是一种文化

这里面讲的作业管理和调度的管理应该是平台级的能力，不需要进行场景化的理解。在自动化的构成要素里有一个原子化的事务，同时有调度编排原子化的事务，有两个要素有够了。再往上是面向角色的场景化收敛和归类，工具可以把我们的能力拼装起来，在各个场景下使用。工具是真正推动变革的有效手段，好的经验一定是通过自动化的手段沉淀管理过程。