运维需要思维的突破，从Ops到DevOps，从项目到产品，从资源到应用。许多问题一直在困扰和思考。为什么大多数CMDB项目都失败了？为什么更多的讨论是关于运维自动化而不是IT自动化？为什么在线问题总是运维人员的黑锅？带着这些问题我们来一探究竟。今天，我想向大家阐述一个新的思路——建立面向应用的运维管理新思维，并以此思路寻找新的运维解决方案。因此，面向应用的管理抽象总结如下：在ITIL时代，大家都知道一个概念，CMDB是IT服务系统的元数据中心，现在应用应该是CMDB的元数据。基于运维能力面向应用的维度，面向应用的IT能力分为三个部分：1.CMDB，即IT资源管理系统，这些资源用来支撑一个应用的运行？应用占用的服务器是资源，占用的内存是资源，占用的存储是资源，占用的负载均衡器是资源。但是大家一定要注意，这个资源更多的不是后端服务，比如IaaS服务或者PaaS服务。2、action应用变更的场景有很多，按角色分类，比如应用交付、应用升级等场景。这些场景面向Dev/Test/Ops。还有就是日常维护过程中应用的变化，是面向纯Ops场景的，比如应用迁移，应用扩展。动作作用于资源。比如应用升级就是版本变更，应用扩容就是应用资源的增加。过去，传统运维始终侧重于对碎片化运维自动化能力的理解。3.Status为了衡量应用的健康状态或质量，我们需要收集各种状态数据来支撑各种场景下的应用，比如监控故障发现、故障恢复、应用服务优化等需求等等.CMDB建设的失败，一部分是制度问题，更多是方法问题。我们一直认为我们找到了强大的驱动力来构建资源维护流程和场景，但这些其实都是我们自己的想法。数据中心的基础设施部门负责CMDB的所有配置、建设和管理，资源部门根本不关心，也无法关心与资源关联的上层应用。因此，我提倡分层构建CMDB建设。业务层和资源层CMDB可以分开构建，但是应用CMDB的构建一定要以应用CMDB为主，资源层的CMDB构建要向后完善。建立以应用为中心的IT资源生命周期管理后，资源的广度不断扩展自动化的深度。但必须注意的是，CMDB信息分为两类，一类是实例信息，一类是连接信息，也称为拓扑信息。拓扑信息的构建和维护需要结合我们平时的工作思路。例如，架构视图是研发和维度转换过程中必须提供的输入，即应用架构文档。部署视图是指应用在线部署在哪些机房、哪些节点。基础设施拓扑是一种物理覆盖，它表达了基础设施级别的关系。业务流视图分为应用服务和端到端服务构建的能力视图，类似于访问流拓扑。从应用的角度来说，可以很好的维护资源信息。此时，考虑如何支持应用程序的操作。这个场景起来之后，才能真正解决CMDB数据维护的动力和价值问题。从面向应用的角度，提供完备的应用自动化和运维自动化能力。应用自动化打通Dev/Test/Staging/Prod等环境，构建面向用户的端到端自动化能力。一个典型的场景是交付管道。示意图如下：一个端到端的交付流水线可以分为四个标准化流程，将阶段、环境、动作、角色等概念进行垂直分解。1.阶段是交付阶段的逻辑划分。对于一个企业的产品，建设标准是单一的交付流水线，而不是多条交付流水线。只有单一的交付流水线才能保证整个交付过程的一致性。一般分为研发、测试、预发布和生产运维阶段。2.环境环境是上述四个阶段的进一步细分。在每个阶段，都会有多个环境问题。比如测试阶段，有UAT环境和SIT环境；在生产阶段，有正式的生产集群和容灾备份集群等。3、动作传递的能力是通过动作来实现的，这个动作是一系列的能力安排。此操作可以分解为部署操作和附加操作。部署动作是完成一个环境部署的标准化流程，如初始化环境、安装包等。附加动作是针对特定环境需要完成的一些动作，如用户验收测试、可能运行的自动化测试等在。部署动作必须保证环境间的一致性，这是部署脚本的基本能力，避免动作行为不同导致结果不同。在动作层，也可以面向封装大量的自动化流程、工具能力等，这些能力是个性化的，可以满足所有的应用场景。4.执行这些操作的角色是谁？不同的环境可以面向不同的角色，这就是权限的控制。通常分为开发、测试、运维角色，但在真实的企业中，角色的划分会细化很多；其次，这个角色也会随着管理方式的改变而改变，测试人员可能会来部署生产环境。这种自动化能力不是运维自动化，而是IT自动化。IT自动化平台可由运维搭建，保证可扩展性和插件化能力。能力可扩展是指能力可以扩展到不同角色的需求，而插件是指过去可以集成不同角色的工具能力，从而实现一个面向DevOps的应用交付平台。回到运维自动化，在面向应用的自动化场景下，依然可以通过服务编排的方式来实现。但是当涉及到其他运维资源时，就逐渐失去了与应用的联系，尤其是从管理便利性的角度来看。比如数据库维护，大家一定喜欢维护和更改数据库实例，而不是增加一个应用维度。在IaaS和PaaS能力的自动化上，可以进行面向资源的action服务编排，实现运维的自动化。Status其实是一种面向应用的衡量方式。测量离应用程序和服务越近，测量就越有效。监测方法是一种测量。我们往往把监控的报警能力和发现问题的能力作为核心手段。但从这个维度出发，警报的泛滥就成了必然。每个人都在不断的寻求提高告警的准确性，做告警收敛和告警关联。我们的方法是可视化警报分层面板。在时间维度上，告警统一展示。提高面向应用层的告警权重，降低底层告警的权重，衡量应用的健康度。其次，在统一的看板上，人的思维会发生变化，底层的告警能力会不断形成决策参考数据，而不是作为一个直接的问题，甚至告警可以保持一致。这都是因为数据是以应用为中心关联的。面向应用的运维管理新思维切实有效，为过去许多未解决的问题提供了解决方案。原因。应用贴近业务，所以应用是最大的驱动力。【本文为专栏作家“王金银”原创稿件，转载请注明出处】点此阅读更多该作者好文
