IDCC2018｜IBM黄卫：传统运维or云上运维，大不一样

变更之后，会有CMDB的考量，我们制订最近的状态，包括这个应用依赖的所有要素，以及要素之间的逻辑关系，都可以在CMDB上找到，基于CMDB可以很容易确定这个应用在发生问题之后，或者是有依赖的要素出现之后，对它会有什么影响。无论是云支持还是云原生上线之后，我们就不能去过多的依赖CMDB来得到这样一个依赖关系，我们去定位一个问题的前因后果，更需要从数据，需要从我们对于每个应用或者服务上线之后动态运行的状态来得到这样的关系。所以，这个拓扑和关系，包括前因后果排查的技术要素，都会发生很大的改变。包括我们在出现问题之后，如何去应对？传统会开工单，帮助进行分配和解决，在云原生IT下，这个逻辑已经跟不上我们用户或者业务的要求速度，现在有越来越多的企业会提出一个协作的概念和方式，从开发到运维相关所有角色，他们会基于类似ChatOps的工具，形成一个共享合作的平台和能力。

前面讲了那么多，从传统到云运行所使用到的最佳实践或者方法，以及工具，都有很大的区别，但是我们不可能抛开任何一个，比如说传统的，也不可能抛开我们提出的最佳实践，所以这两者之间需要有一个有机的融合，无论是对企业也好，还是对于类似IBM这样的技术和产品的服务商也好，都需要统筹去考虑。

如何统筹考虑？我们可以基于这样一个流程来看一下，无论是在传统环境还是在云环境下，我们首先面对的是服务出现问题之后发出的这样一些告警或者事件，或者是服务的事故。服务的事故，我们在这个平台之上我们会做记录，然后去指派，但如果能够通过一些软件工具把它做自动的压缩，再去分派给不同角色的人员，并且基于一个共享合作的平台，那么很多工作就可以在有把控的情况下自动化的去完成。比如在监测的层面，无论是传统的单体式的环境，还是在云上使用工具，得到的数据都需要经过统一的关联压缩过程，这个关联压缩之后的结果基于历史上曾经已经处理过的问题记录，包括运维角色方面的关联，知道这个问题应该通知哪一个运维角色，以及这个运维角色如果需要其他角色的帮助，会通过我们的协作平台来实现一个双向的沟通，以及基于一对一的自动化作业来触发问题的修复。

整个过程中会涉及到这样一些步骤，首先是问题的检测，这些问题是重复的还是独立的，去完成和之前数据的对比，来压缩掉大量重复的问题，然后再去关联这个问题各种上下文的依赖要素，来确定这个问题的整个前因后果，再基于这样的输出，自动化的派发，从开发到运维不同角色的互动，最终把这个问题进行解决。

所以，从IBM来说提出一个全站式的运维管理，左边更多是在基于传统核心的运维之下，我们需要具备的能力，包括所有的问题，如何借助智能化的手段，我们在不断变化的环境中需要更多的从数据当中去提炼前因后果和特征规律，提炼出了这样的一些结果，来指导我们整个运维的流程，每个人得到不同的数据，会去进行比对，基于一些自动化的手段来快速的把这个问题给解决掉。

在面向云上运维的重要概念，包括事件告警问题自动化的提炼，以及自动化的通知和自动化的作业。

从传统到混合云，对于问题的压缩、关联和定位，IBM提出有智能化的概念，整个过程中，比如在传统的IT运营环境当中，我们有一些确定的依赖性关系，我们可以去定义他们之间是有什么样的承载，包含依赖互联等场景。问题发生之后，我们可以把这样的关系快速的挖掘出来，然后提示我们的运维管理人员整个问题发生是什么样的前因后果。往云上走之后，会发现这样的关系往往不可靠，经常会发生变化，需要在数据中心提炼内在的特征和关系，而数据的提炼基于不同的算法，我们会去定义从事件告警日志等等非结构化的数据，具备什么样的特征和规律，以及基于性能指标结构化的数据，具有什么样的特征和规律。这是基于不一样的产品模块来帮助我们实现，这个问题确定之后，整个解决过程可以通过闭环学习的流程，自动的去产生我们经验以及整个解决问题之后的一个记录匹配，这个问题如果之前已经解决了，那么整个解决过程基于自动化的工具，可以在下一次解决的时候去自动匹配，自动修复，或者自动的提炼，就不需要过多的人工干预。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!