为什么 CMDB 大部分项目都是失败的？
作者简介：
王津银（老王）
精益运维发起人
07年进入腾讯公司接触运维，经历服务器从百到万的运维历程，先后在YY和UC参与不同业务形态的运维，期间带过前端运维、数据存储运维、YY语音、游戏运维、运维研发等多种运维团队，对运维有着全面的理解。
极力倡导互联网价值运维理念，即面向用户的价值是由自动化平台交付传递，同时由数据化来提炼和衡量。
导语
运维需要思维的突破，从 Ops 走向 DevOps，从项目走向产品，从资源走向应用~
很多问题一直在困扰、在思考，为什么 CMDB 大部分项目都是失败的？为什么讨论的更多的是运维自动化而不是IT自动化？为什么线上问题永远是运维人的黑锅？带着这些问题我们来一探究竟。
一、面向应用的运维管理新思维
今天要和大家阐述一个新的思路——建立面向应用的运维管理新思维，带着这个思路去寻找运维新的解决方案，因此把面向应用管理抽象总结如下：
在 ITIL 时代，大家都知道一个概念，CMDB 是 IT 服务系统的元数据中心，而现在应用更应该是 CMDB 的元数据。把运维的能力建立在面向应用的维度上，把面向应用的IT能力分成三部分：
1. CMDB 即 IT 资源管理系统
支撑一个应用运行到底占用了哪些资源？应用占用的服务器是一种资源、占用的内存是一种资源、占用的存储是一种资源、占用的负载均衡是一种资源。
但大家一定要注意，这个资源更多是以一种后端服务形式出现的，比如说IaaS 服务或者是 PaaS 服务。
2. 动作
应用的变更有很多种场景，按照角色来归类，比如说应用交付、应用升级等场景，这些场景是面向 Dev/Test/Ops 的。
还有一种应用在日常维护过程中的变更，面向纯 Ops 场景的，比如说应用的迁移、应用的扩容。动作是作用于资源的，比如说应用升级是版本发生变化，应用扩容是让应用的资源新增等等。
过去的传统式运维，总是聚焦在碎片式的运维自动化能力理解上。
3. 状态
为了实现对应用的健康状况或者质量的度量，我们需要采集各类状态数据，从而支撑各类场景的应用，比如说监控故障发现的需求，故障恢复的需要，应用服务优化的需要等等。
二、CMDB 的建设新思路
1. CMDB 建设失败的原因分析
CMDB 建设的不成功，部分是系统的原因，但更多是方法论的问题。我们总以为找到了很强的驱动力来建设资源维护的流程和场景，其实这些都是自己的设想。
数据中心的基础设施部门统揽 CMDB 的一切配置建设和管理，资源部门根本不关心且没法关心资源所关联的上层应用是什么。
2. CMDB 的建设需分层进行
因此我主张把 CMDB 建设分层进行，业务层和资源层 CMDB 可以分开建设，但一定以应用的 CMDB 建设为主，倒推资源层的 CMDB 建设完善。
以应用为中心的 IT 资源生命周期管理建立起来之后，资源的广度不断拓宽自动化的深度。
但一定要注意 CMDB 的信息分成两类， 一类是实例信息，一类是连接信息，也称为拓扑信息。 拓扑信息需要结合我们平时的工作思路来建设和维护，比如说架构视图、 应用架构文档， 是研发转交运维的过程中，必须要提供的输入。
相关知识点：
部署视图，是指这个应用上线部署在哪些机房，哪些 node。
基础架构拓扑，是物理 overlay，这个地方表达的是基础设施层面的关系。
业务流视图，分成应用服务和端到端服务构建的能力视图，类似访问流拓扑。
3. CMDB 建设需考虑如何支撑应用的动作
从应用的角度，资源的信息都能够很好的维护起来。此时就考虑如何支撑应用的动作了。这个场景起来之后，真正能解决 CMDB 数据维护动力和价值问题。面向应用的视角，提供完整的应用自动化和运维自动化能力。
三、构建面向用户的端到端自动化能力
应用自动化打通 Dev/Test/Staging/Prod 等环境，构建面向用户的端到端自动化能力。典型的场景就是交付流水线，示意图如下：
可以把一个端到端的交付流水线，分成了四个标准化过程，纵向就分解了阶段、环境、动作和角色等概念。
1. 阶段
是对交付阶段的逻辑划分，对于一个企业的某个产品来说，建设的标准是单一交付流水线，而不是多交付流水线，单一交付流水线才能保证整个交付过程的一致性。一般分成研发、测试、预发布和生产运维阶段。
2. 环境
环境是以上四个阶段的进一步细分，在每一个阶段会存在多环境的问题，比如说测试阶段，有 UAT 环境、SIT 环境；在生产阶段，有正式生产集群、有容灾备份集群等等。
3. 动作
交付的能力是动作来实现的，这个动作是一连串的能力编排。这个动作可以分解成部署动作和附加动作。
部署动作， 是完成一个环境部署的标准化过程，比如说初始化环境、安装程序包等等；
附加动作， 是针对特定环境要完成的一些动作，比如说针对用户接受性测试，可能会运行自动化测试等等。
部署动作要确保在各个环境之间的一致性，这是部署脚本的基本能力，避免动作行为异化导致结果不同。
在动作层，还可以面向封装大量的自动化流程、工具能力等，这些能力都是满足一切应用场景的个性化。
4. 角色
谁来执行这些动作，不同的环境可以面向不同的角色，这是权限的控制。
通常分成开发、测试和运维角色，但真正到企业内，角色的划分会细致的多；
其次这个角色也是随着管理模式变化而变化的，测试人员可能来做生产环境的部署。
这个自动化能力就不是运维自动化，而是IT自动化。IT自动化的平台可以由运维来建设，确保可扩展、插件化的能力。
扩展的能力， 是能力可以延伸到不同角色的需要；
插件化， 是可以集成不同角色过去的工具能力，从而实现一个面向 DevOps 的应用交付平台。
再回到运维自动化，在面向应用的自动化场景上，依然可以通过服务编排的模式来实现。但是回到其他运维资源上，就逐渐失去和应用的关联，从管理方便性的角度来说，更是如此了。
举个例子，比如说数据库的维护，大家肯定都是喜欢对数据库的实例进行维护和变更，而不是再加一个应用的维度。在面向 Iaas 和 PaaS 能力的自动化上，可以面向资源进行动作服务编排，从而实现运维的自动化。
四、告警建设的新思路
状态其实是面向应用的一种度量手段，度量越贴近应用，越贴近服务，度量的有效性就越强。监控手段是度量的一种，大家很多时候把监控的告警能力、发现问题作为核心手段。
但从这个维度出发，告警泛滥成为必然，大家不断的去看提升告警的准确性，做告警收敛和告警关联。
我们的做法是告警可视化分层面板，在时间这个维度上，把告警统一展示，面向应用层的告警权重增大，底层的告警权重变小，衡量应用的健康状况。
其次在统一的看板上，人的思维会发生变化，底层的告警能力会不断形成决策参考数据，而非当成直接的问题，甚至可以告警一致。这都是因为以应用为中心，数据有了关联所致。
总结
面向应用的运维管理新思维，是切实有效的，给过去的很多未解问题提供了解决方案，这也是我过去不断强调要“建立以应用运维 + 运维研发为核心的组织体系”的原因。 应用是贴近业务的，因此应用是驱动力最强的。
与 “老王” 相约GOPS2016 · 北京站
在12月16-17日两天， 以“DevOps 2.0：重塑运维价值”为主题的 GOPS2016 · 北京站将在国际会议中心举办，汇集国内一大批运维界牛人，带来50多场时间更加持久的培训式演讲。
本次 GOPS2016 · 北京站特设【老王专场】（12月17日 周六 上午），精益运维发起人 王津银 作为国内运维行业大师级人物，准备了超级精彩的内容同大家分享，旨在让大家感受不一样的运维，进一步探索运维的商业化。
高效运维建立 DevOps CN 微信群，方便运维界同仁们相互探讨学习 DevOps 运维体系，共同进步。（请大家选择性入群）
华北
华东
华南
今日起，购买普通票或团体票的小伙伴将可在GOPS大会现场 免费领取《凤凰项目 - 一个IT运维的传奇故事》特别版！
想了解更多，请点击" 阅读原文 "进入GOPS2016 · 北京站官网
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
