【DevOps运维】构建面向应用的运维管理新思维

运维需要思维的突破，从Ops走向DevOps，从项目走向产品，从资源走向应用~

很多问题一直在困扰、在思考，为什么CMDB大部分项目都是失败的？为什么讨论的更多的是运维自动化而不是IT自动化？为什么线上问题永远是运维人的黑锅？带着这些问题我们来一探究竟。

今天要和大家阐述一个新的思路——建立面向应用的运维管理新思维，带着这个思路去寻找运维新的解决方案，因此把面向应用管理抽象总结如下：

在ITIL时代，大家都知道一个概念，CMDB是IT服务系统的元数据中心，而现在应用更应该是CMDB的元数据。把运维的能力建立在面向应用的维度上，把面向应用的IT能力分成三部分：

CMDB建设的不成功，部分是系统的原因，但更多是方法论的问题。我们总以为找到了很强的驱动力来建设资源维护的流程和场景，其实这些都是自己的设想。数据中心的基础设施部门统揽CMDB的一切配置建设和管理，资源部门，根本不关心且没法关心资源所关联的上层应用是什么。

因此我主张把CMDB建设分层建设，业务层和资源层CMDB可以分开建设，但一定以应用的CMDB建设为主，倒推资源层的CMDB建设完善。以应用为中心的IT资源生命周期管理建立起来之后，资源的广度不断拓宽自动化的深度。

但一定要注意CMDB的信息分成两类，一类是实例信息，一类是连接信息，也称为拓扑信息。拓扑信息需要结合我们平时的工作思路来建设和维护，比如说架构视图，是研发转维的过程中，必须要提供的输入，就是应用架构文档。部署视图，是指这个应用上线部署在哪些机房，哪些node。基础架构拓扑是物理overlay，这个地方表达的是基础设施层面的关系。业务流视图分成应用服务和端到端服务构建的能力视图，类似访问流拓扑。

从应用的角度，资源的信息都能够很好的维护起来。此时就考虑如何支撑应用的动作了。这个场景起来之后，真正能解决CMDB数据维护动力和价值问题。面向应用的视角，提供完整的应用自动化和运维自动化能力。应用自动化打通Dev/Test/Staging/Prod等环境，构建面向用户的端到端自动化能力。典型的场景就是交付流水线，示意图如下：

可以把一个端到端的交付流水线，分成了四个标准化过程，纵向就分解了阶段、环境、动作和角色等概念。

这个自动化能力就不是运维自动化，而是IT自动化。IT自动化的平台可以由运维来建设，确保可扩展、插件化的能力。扩展的能力，是能力可以延伸到不同角色的需要，插件化是可以集成不同角色过去的工具能力，从而实现一个面向DevOps的应用交付平台。

再回到运维自动化，在面向应用的自动化场景上，依然可以通过服务编排的模式来实现。但是回到其他运维资源上，就逐渐失去和应用的关联，从管理方便性的角度来说，更是如此了。举个例子，比如说数据库的维护，大家肯定都是喜欢对数据库的实例进行维护和变更，而不是再加一个应用的维度。在面向Iaas和PaaS能力的自动化上，可以面向资源进行动作服务编排，从而实现运维的自动化。

状态其实是面向应用的一种度量手段，度量越贴近应用，越贴近服务，度量的有效性就越强。监控手段是度量的一种，大家很多时候把监控的告警能力、发现问题作为核心手段。但从这个维度出发，告警泛滥成为必然，大家不断的去看提升告警的准确性，做告警收敛和告警关联。我们的做法是告警可视化分层面板，在时间这个维度上，把告警统一展示，面向应用层的告警权重增大，底层的告警权重变小，衡量应用的健康状况。其次在统一的看板上，人的思维会发生变化，底层的告警能力会不断形成决策参考数据，而非当成直接的问题，甚至可以告警一致。这都是因为以应用为中心，数据有了关联所致。

面向应用的运维管理新思维，是切实有效的，给过去的很多未解问题提供了解决方案，这也是我过去不断强调要“建立以应用运维+运维研发为核心的组织体系”的原因。应用的是贴近业务的，因此应用是驱动力最强的。