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

单体式应用之下，开发到运维有一系列的最佳实践，包括管理角色的划分也非常明确，我们有专门的开发组，有运维组，有管控技术架构的部门，有明确合规性的安全方面的要求，但是我们在部分应用往私有云，乃至公有云迁移的时候，会发现整个应用很多能力需要进行整合，比如面向敏捷精准开发的一些角色和团队，他们需要构成一个团队来提供整个容器微服务全站式的完整供应链。另外，在部署上线之后，从基础架构到应用，整个运行状态需要有一个端到端，能够去把控安全稳定这样的管理角色，就是站点可靠性的工程师。应用上云跟传统在固定环境下运行有很大的区别，具有非常灵活的伸缩性，包括对于计算存储资源等等的一些使用都会不断的发生变化，需要有一些代码编写能力，对于应用依赖的所有要素具有这样的把控，所有的应用上线之后的微服务化整个过程，需要能够具备集中化的策略配制和部署，治理合规审计等等，以及应用所依赖的各个外部要素和内部要素之间的接触定义能力，以及急救人员在应用出现任何故障之后，如何快速有效的去恢复服务。另外，在公有云对接部署的过程当中，我们需要去跟一些第三方的云服务提供商，比如阿里云，公有云的服务商打交道，有一部分原来我们企业内部需要去考量的，尤其是在基础架构运维中的角色，通过第三方的云服务商来提供。对于很多直接通过云上构建部署一些企业的应用，包括新创公司，他们的角色会相对更单纯一点，只需要考量如何去构建应用代码，然后把代码上传到云平台，云环境，所以只需要提供一个全站式的开发。站点是否可靠，全部交给第三方的云服务提供商，由他们来帮助我们满足战略可靠的角色。交互流程的改变，在整个开发部署过程中会涉及到不断的迭代开发和变更，我们有一个很重要的角色叫CAB，就是变更评估委员会，无论是小组还是某一个具体的角色，需要变更整个前因后果，包括可能会带来什么样的风险，以及上线之后的影响，有一个统一的了解。所以，CAB的角色对于我们传统单体式用开发部署和变更来说是非常重要，同时我们有明确的一些变更记录，会同步到CNDB当中。但是在快速迭代的环境之下，CAB的角色会拖累整个应用迭代速度和效率，这样的角色更多的会分解到整个职能当中，这个过程会有一些不一样的地方，比如说把传统应用进行改造，迁移到云，不会把整个应用架构推翻出来，因为这个做法会导致企业花费大量的时间和精力重新构建应用，尤其是一些企业的核心应用，更多的是考量如何把它容器化。所以，应用直接的各个组件仍然是具备比较强的依赖关系，我们在统一部署的时候需要考量每个开发部署的模块，上线之后的依赖性有没有满足，如果满足了就进行统一部署。云原生，从状态的检查包括运营之后能够提供的，可以允许微服务来进行对接和考量，包括安全稳定等的角色，自己都可以把控，所以对于每一个微服务从开发到部署，都是单一的。

（编辑：核心网）

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