大神教你如何构建面向应用的运维管理新思惟

今天要和你们阐述一个新的思路——创建面向应用的运维管理新思惟，带着这个思路去寻找运维新的解决方案，所以把面向应用管理抽象总结以下：

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

CMDB即IT资源管理系统

支撑一个应用运行到底占用了哪些资源?应用占用的服务器是一种资源、占用的内存是一种资源、占用的存储是一种资源、占用的负载均衡是一种资源。但你们必定要注意，这个资源不是更可能是一种后端服务出现，好比说IaaS服务或者是PaaS服务。

动做

应用的变动有不少种场景，按照角色来归类，好比说应用交付、应用升级等场景，这些场景是面向Dev/Test/Ops的。还有一种应用在平常维护过程当中的变动，面向纯Ops场景的，好比说应用的迁移、应用的扩容。动做是做用于资源的，好比说应用升级是版本发生变化，应用扩容是让应用的资源新增等等。过去的传统式运维，老是聚焦碎片式的运维自动化能力理解上。

状态

为了实现对应用的健康情况或者质量的度量，咱们须要采集各种状态数据，从而支撑各种场景的应用，好比说监控故障发现的需求，故障恢复的须要，应用服务优化的须要等等。

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

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

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

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

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

阶段

是对交付阶段的逻辑划分，对于一个企业的某个产品来讲，建设的标准是单一交付流水线，而不是多交付流水线，单一交付流水线才能保证整个交付过程的一致性。通常分红研发、测试、预发布和生产运维阶段。

环境

环境是以上四个阶段的进一步细分，在每个阶段会存在多环境的问题，好比说测试阶段，有UAT环境、SIT环境;在生产阶段，有正式生产集群、有容灾备份集群等等。

动做

交付的能力是动做来实现的，这个动做是一连串的能力编排。这个动做能够分解成部署动做和附加动做。部署动做是完成一个环境部署的标准化过程，好比说初始化环境、安装程序包等等，附加动做是针对特定环境要完成的一些动做，好比说针对用户接受性测试，可能会运行自动化测试等等。部署动做要确保在各个环境之间的一致性，这是部署脚本的基本能力，避免动做行为异化致使结果不一样。

在动做层，还能够面向封装大量的自动化流程、工具能力等，这些能力都是知足一切应用场景的个性化。

角色

谁来执行这些动做，不一样的环境能够面向不一样的角色，这是权限的控制。一般分红开发、测试和运维角色，但真正到企业内，角色的划分会细致的多;其次这个角色也是随着管理模式变化而变化的，测试人员可能来作生产环境的部署。

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

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

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

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

 

原文来自：http://os.51cto.com/art/201611/522832.htm

本文地址：http://www.linuxprobe.com/operation-maintenance-management.html