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

中国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的角色会拖累整个应用迭代速度和效率，这样的角色更多的会分解到整个职能当中，这个过程会有一些不一样的地方，比如说把传统应用进行改造，迁移到云，不会把整个应用架构推翻出来，因为这个做法会导致企业花费大量的时间和精力重新构建应用，尤其是一些企业的核心应用，更多的是考量如何把它容器化。所以，应用直接的各个组件仍然是具备比较强的依赖关系，我们在统一部署的时候需要考量每个开发部署的模块，上线之后的依赖性有没有满足，如果满足了就进行统一部署。云原生，从状态的检查包括运营之后能够提供的，可以允许微服务来进行对接和考量，包括安全稳定等的角色，自己都可以把控，所以对于每一个微服务从开发到部署，都是单一的。

（编辑：西安站长网）

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