中国IDC圈讯 12月11日-13日，由中国IDC产业年度大典组委会主办，中国IDC圈、CloudBest承办的以“赋能企业数字化转型”为主题的第十三届中国IDC产业年度大典（简称“IDCC2018”）在北京国家会议中心隆重召开。
13日上午，IDCC2018分论坛智能运维安全论坛正式召开！本次论坛由威客安全和中国IDC圈承办，汇聚了来自来自运营商、互联网、数据中心、云计算等多领域多行业的企业高管、嘉宾、媒体等。与会嘉宾们在大典现场，共话数字经济时代，聚焦数据安全问题，探讨智能化与可视化运维的新方向与新趋势。
会上，IBM混合云顾问黄卫先生，为大家带来《多云环境下的智能运维》的主题演讲。以下为演讲实录（未经本人核实）：
IBM混合云顾问黄卫
我今天分享的内容是多云环境下智能运维，聊一聊混合云。在国内，这几年出于合规安全等方面的考虑，各个企业走向云的过程还是相对比较谨慎的，尤其欧美有很多企业，很多核心应用都已经迁移到云，甚至公有云上，比如新加坡发展银行，他们所有的应用也都放在公有云上。我们国内现状跟IBM现在最关注的领域是非常吻合的，在十年前IBM就提出未来的战略方向，对行业来说是混合云，而不是单一的云，或者是多云，大量企业在相当长时间内是一个混合状态，也就是核心计算、核心业务还是本地运行，一部分跟用户比较贴近的应用放在云上。但是比如测试、开发等等，会通过私有云来构建，为了加速需求方面的供应以及资源的有效性。
我今天会跟大家先分享一下企业从传统安全走向云的过程当中，对运维会带来什么样挑战和变化，以及IBM是怎么样去看待这个问题。IBM有大量的传统运维产品和技术，也面临同样的一个改变，需要去适应企业从本地逐渐往云上走的过程当中，所面临着得问题，就是产品应该怎么去适应这样一种变化，以及IBM为什么按照这样的一个思路和方向做这样的变化。因为时间关系，我不想讲IBM有什么，更多的分享一下IBM为什么做这样的改变，希望能给大家带来一些启发。
古希腊哲学家说生命唯一不变的是变化，这个理念在大量的行业和领域当中依然存在，只是用来形容IT还不够准确，我们知道其实IT系统，尤其从运维的角度，它永远是在变，但是我们从传统环境走向云的过程当中，它并不是说原来从不变到变，而是变化速度、频率、以及能够把控的部分是越来越少了，频率越来越快。我们最关注的其实是应用，服务都是依赖于各种不同的应用，应用的变化最显著。有哪些变化呢？比如刚开始开发的时候我们就明确了应用以后在什么硬件平台，什么样的物理服务器，基于怎样的平台和服务器做统计的考量和构建，开发。但是后来发现这个应用所依赖的物理环境没有办法把控，尤其是走到公有云之后，都是由云服务商帮我们提供。所以，如果我们去从基础架构来考虑应用方面，其实是有失控的可能性。所以，应用依赖的基础架构，它的变化会越来越快，越来越大，我们在构建应用时候就不能有过多的对于基础架构的依赖性的定义。另外，应用本身的程序架构也在发生变化，从单体式、到微服务、到容器化，内部的依赖我们需要去把它尽可能的避免掉，减少相互的依赖。到微服务之后，每个服务是相对独立的生态，状态的变化不应该依赖于其他的要素、其他的微服务，我们需要重新去设计微服务化的架构。
企业上云之后带来的开发模式也会发生大的变化，我们知道以前传统会有各种的最佳实践，包括开发商的一些最佳实践，走上云之后所有模式都会发生变化。当然，传统的最佳实验本身也在不断的完善和适应，会逐渐融入，在敏捷，精准开发方面的一些内容，所有这些变化对于我们运维都会产生很大的影响，后面我们会具体看一看。另外，运行的边界以后会越来越模糊，早期我们通过CS或者是BS的方式，应用发生问题，帮助你部署确定位置，确定运营环境过程中发生了问题，可以有足够的能力，能够定位前因后果。但是我走到云之后，包括从IaaS，从环境虚拟化到PaaS，从容器微服务统一构建之后，会发现所有运行依赖要素都在不断的发生改变和漂移，大量对运营本身的健康状况考量需要去结合最终用户使用的习惯来做整体端到端的考量。所以，从容器化、微服务的使用，包括单一应用配制到多种交付模型选择，把控的难度会越来越大。我们可能会需要应用上线之后端到端，整个状态的可视化要求会变得越来越迫切。
两个方向的管理，无论是传统IT运维还是对于云化的运维来说，都是非常重要的，当问题从技术架构，或者是应用所依赖的要素发生变化之后，对于上层的应用运行，以及应用所依赖的服务状态会有什么样的影响，需要有这个能力能够快速的定位和把控。另外，很多问题是从用户方发现、报出来以后，我如何能够有一个手段快速的挖掘这个问题，是由于应用本身的代码所引起的，还是由于应用所依赖的一些运行要素，比如说计算资源，存储资源不够等等原因所导致的，我需要有这样的一个两个方向的能力。但是在传统相对变化没有那么大的情况下，可以通过成熟的工具快速的定位。随着不断的构建私有云，乃至把一部分应用迁移到公有云之后，我们会发现工具的选择越来越多，无论是从开源组件还是商业组件，对于工具供应的速度越来越快。比如IDC的企业，有超过一半以上都是使用有十多种，甚至更多的工具，包括现在大型的企业，比如国内几大行，有非常强的自我开发的能力，也利用各种技术，开发各种各样的工具。但是都面临一个问题，在混合云上面构建了应用出现问题之后，这些工具能够给我们企业拿到足够多的数据，但是让我如何能够及时快速的定位这个问题，前因后果，如何把这个问题快速的解决，这个能力还是缺失。
现在越来越多的企业往云上迁移，我们在云上的应用出现问题之后，对于企业的服务损失，包括收入的损失，影响也非常大，如何在任何一个层面的问题发生之后，能够快速的了解到前因后果，对企业来说变得尤其重要。因为动态化的原因，确定场景，能够去定位在什么样的服务器上出现什么问题，会对应用导致什么后果，这样的能力在混合云的情况下是很难做到的。有什么办法呢？可以从数据入手去做这样的端到端的主动性的智能化的分析。
单体式应用之下，开发到运维有一系列的最佳实践，包括管理角色的划分也非常明确，我们有专门的开发组，有运维组，有管控技术架构的部门，有明确合规性的安全方面的要求，但是我们在部分应用往私有云，乃至公有云迁移的时候，会发现整个应用很多能力需要进行整合，比如面向敏捷精准开发的一些角色和团队，他们需要构成一个团队来提供整个容器微服务全站式的完整供应链。另外，在部署上线之后，从基础架构到应用，整个运行状态需要有一个端到端，能够去把控安全稳定这样的管理角色，就是站点可靠性的工程师。应用上云跟传统在固定环境下运行有很大的区别，具有非常灵活的伸缩性，包括对于计算存储资源等等的一些使用都会不断的发生变化，需要有一些代码编写能力，对于应用依赖的所有要素具有这样的把控，所有的应用上线之后的微服务化整个过程，需要能够具备集中化的策略配制和部署，治理合规审计等等，以及应用所依赖的各个外部要素和内部要素之间的接触定义能力，以及急救人员在应用出现任何故障之后，如何快速有效的去恢复服务。另外，在公有云对接部署的过程当中，我们需要去跟一些第三方的云服务提供商，比如阿里云，公有云的服务商打交道，有一部分原来我们企业内部需要去考量的，尤其是在基础架构运维中的角色，通过第三方的云服务商来提供。对于很多直接通过云上构建部署一些企业的应用，包括新创公司，他们的角色会相对更单纯一点，只需要考量如何去构建应用代码，然后把代码上传到云平台，云环境，所以只需要提供一个全站式的开发。站点是否可靠，全部交给第三方的云服务提供商，由他们来帮助我们满足战略可靠的角色。交互流程的改变，在整个开发部署过程中会涉及到不断的迭代开发和变更，我们有一个很重要的角色叫CAB，就是变更评估委员会，无论是小组还是某一个具体的角色，需要变更整个前因后果，包括可能会带来什么样的风险，以及上线之后的影响，有一个统一的了解。所以，CAB的角色对于我们传统单体式用开发部署和变更来说是非常重要，同时我们有明确的一些变更记录，会同步到CNDB当中。但是在快速迭代的环境之下，CAB的角色会拖累整个应用迭代速度和效率，这样的角色更多的会分解到整个职能当中，这个过程会有一些不一样的地方，比如说把传统应用进行改造，迁移到云，不会把整个应用架构推翻出来，因为这个做法会导致企业花费大量的时间和精力重新构建应用，尤其是一些企业的核心应用，更多的是考量如何把它容器化。所以，应用直接的各个组件仍然是具备比较强的依赖关系，我们在统一部署的时候需要考量每个开发部署的模块，上线之后的依赖性有没有满足，如果满足了就进行统一部署。云原生，从状态的检查包括运营之后能够提供的，可以允许微服务来进行对接和考量，包括安全稳定等的角色，自己都可以把控，所以对于每一个微服务从开发到部署，都是单一的。
变更之后，会有CMDB的考量，我们制订最近的状态，包括这个应用依赖的所有要素，以及要素之间的逻辑关系，都可以在CMDB上找到，基于CMDB可以很容易确定这个应用在发生问题之后，或者是有依赖的要素出现之后，对它会有什么影响。无论是云支持还是云原生上线之后，我们就不能去过多的依赖CMDB来得到这样一个依赖关系，我们去定位一个问题的前因后果，更需要从数据，需要从我们对于每个应用或者服务上线之后动态运行的状态来得到这样的关系。所以，这个拓扑和关系，包括前因后果排查的技术要素，都会发生很大的改变。包括我们在出现问题之后，如何去应对？传统会开工单，帮助进行分配和解决，在云原生IT下，这个逻辑已经跟不上我们用户或者业务的要求速度，现在有越来越多的企业会提出一个协作的概念和方式，从开发到运维相关所有角色，他们会基于类似ChatOps的工具，形成一个共享合作的平台和能力。
前面讲了那么多，从传统到云运行所使用到的最佳实践或者方法，以及工具，都有很大的区别，但是我们不可能抛开任何一个，比如说传统的，也不可能抛开我们提出的最佳实践，所以这两者之间需要有一个有机的融合，无论是对企业也好，还是对于类似IBM这样的技术和产品的服务商也好，都需要统筹去考虑。
如何统筹考虑？我们可以基于这样一个流程来看一下，无论是在传统环境还是在云环境下，我们首先面对的是服务出现问题之后发出的这样一些告警或者事件，或者是服务的事故。服务的事故，我们在这个平台之上我们会做记录，然后去指派，但如果能够通过一些软件工具把它做自动的压缩，再去分派给不同角色的人员，并且基于一个共享合作的平台，那么很多工作就可以在有把控的情况下自动化的去完成。比如在监测的层面，无论是传统的单体式的环境，还是在云上使用工具，得到的数据都需要经过统一的关联压缩过程，这个关联压缩之后的结果基于历史上曾经已经处理过的问题记录，包括运维角色方面的关联，知道这个问题应该通知哪一个运维角色，以及这个运维角色如果需要其他角色的帮助，会通过我们的协作平台来实现一个双向的沟通，以及基于一对一的自动化作业来触发问题的修复。
整个过程中会涉及到这样一些步骤，首先是问题的检测，这些问题是重复的还是独立的，去完成和之前数据的对比，来压缩掉大量重复的问题，然后再去关联这个问题各种上下文的依赖要素，来确定这个问题的整个前因后果，再基于这样的输出，自动化的派发，从开发到运维不同角色的互动，最终把这个问题进行解决。
所以，从IBM来说提出一个全站式的运维管理，左边更多是在基于传统核心的运维之下，我们需要具备的能力，包括所有的问题，如何借助智能化的手段，我们在不断变化的环境中需要更多的从数据当中去提炼前因后果和特征规律，提炼出了这样的一些结果，来指导我们整个运维的流程，每个人得到不同的数据，会去进行比对，基于一些自动化的手段来快速的把这个问题给解决掉。
在面向云上运维的重要概念，包括事件告警问题自动化的提炼，以及自动化的通知和自动化的作业。
从传统到混合云，对于问题的压缩、关联和定位，IBM提出有智能化的概念，整个过程中，比如在传统的IT运营环境当中，我们有一些确定的依赖性关系，我们可以去定义他们之间是有什么样的承载，包含依赖互联等场景。问题发生之后，我们可以把这样的关系快速的挖掘出来，然后提示我们的运维管理人员整个问题发生是什么样的前因后果。往云上走之后，会发现这样的关系往往不可靠，经常会发生变化，需要在数据中心提炼内在的特征和关系，而数据的提炼基于不同的算法，我们会去定义从事件告警日志等等非结构化的数据，具备什么样的特征和规律，以及基于性能指标结构化的数据，具有什么样的特征和规律。这是基于不一样的产品模块来帮助我们实现，这个问题确定之后，整个解决过程可以通过闭环学习的流程，自动的去产生我们经验以及整个解决问题之后的一个记录匹配，这个问题如果之前已经解决了，那么整个解决过程基于自动化的工具，可以在下一次解决的时候去自动匹配，自动修复，或者自动的提炼，就不需要过多的人工干预。
这张图给大家看一下，这是实际用户生产的效果，比如原始事件有650多万，经过一步一步的压缩，关联和基于场景化的分析，以及基于机器学习认知之后形成的一个压缩结果，以及再去匹配这些问题是否有影响业务，以及影响的程度等等，最终我们只需要去派发21个工单，所有工单数量是102个。
后面给大家简单看一下实践过程中场景能力，比如说在混合云下面需要依赖各种技术，这些技术如何得到内在的跟IT要素之间的关系，通过不同的API可以得到整个端到端的，整个应用所依赖的各方面要素之间的总关系，以及这些关系在什么情况下会发生改变，比如说应用出现问题之后，上下文可以打开，依赖的要素在最近的5分钟，或者10分钟之内发生什么样的改变，比如说这个服务器，或者是某一个容器，在最近5分钟之内减耗显示是被删除掉了，很有可能删除这个动作导致了这个问题发生。所以，我们可以确定基于时间段的变化追踪。另外，前面讲到很多问题自动化的通知和自动化恢复，在混合云运维过程中都是基于不同组件来帮助我们去实现一些能力。所有的问题如何去收集，进到统一的协作平台，做自动化的通知，包括在多云环境下如何把多个数据中心的应用进行统筹的管控，如果应用的资源出现瓶颈，快速部署到另外一个数据中心上面。
目前，管理工具，管理平台的容器化，也是越来越多的趋势，IBM形成的能力越来越基于容器微服务化的方式来提供。对于用户来说有多种选择，如果完全云化的，无论是单级还是多云，可以基于IBM云优先的方案之下，更多的是基于协作来实现快速问题的定位和解决，如果是在本地和基于云工具共存的情况下，一部分数据是基于传统的系统来得到，另外一部分和云相关的数据是基于云监控平台，或者是监控工具来得到，它们之间要实现耦合的集成，能够基于统一的管理平台和看到端到端云上云下所有数据和结果。涉及到不同模块，这边列出来了，就不一一说了。
基于本地传统工具的管理，中间更多的是一些智能化的，基于传统工具能力的增强。
因为时间关系，更多的内容大家可以从这个链接中看到，谢谢大家！