商业银行云模式下的技术变革.docx

商业银行云模式下的技术变革

前言
为了推进企业数字化转型，实现企业战略目标，企业上云是趋势，从 IaaS 、 PaaS 、 SaaS 到混合云，而且占据比例越来越高，运维工作量越来越大，运维难度越来越大，运维架构越来越复杂，如何有效实现云平台运维、提升运维效率？本文就云模式下总体运维架构演进进行探讨。

1 、 IaaS 运维架构
IaaS 云管平台领域分类如下：

云管平台在企业 IT 云化过程中有着独立的角色定位和使命。越来越多的企业 IT 部门面临着 IT 能力云化 / 服务化的诉求。这种诉求的背后面临着几个关键性的技术挑战，即 IT 资源服务化、 IT 资源全生命周期管理和异构 IT 及多云对接。
■ IT 资源服务化：
如果需要对企业内部各种 IT 资源进行服务化，那就需要有一个独立的用户 / 租户体系，这个用户 / 租户体系需要超越任何 IT 资源自带的用户 / 租户体系。这就是独立云管平台一个重要的产品特征。
另外， IT 资源服务化还需要能够建立起 IT 产品及能力的标准服务目录，这需要 IT 产品及能力服务目录定义、抽象以及相关的自动化能力。但是，当面对现实，你会发现企业内部不同 IT 产品及能力在服务化支持能力上参差不齐，这要求云管平台能够针对不同 IT 产品及能力的现状建立合适的 IT 资源服务化模式。独立云管平台则可以保障这个模式得以灵活构建。
■ IT 资源全生命周期管理：
企业 IT 内部的资源形态非常多样化，有云主机这样的计算资源，也有块存储、对象存储和文件存储，还有备份、监控、安全等运维管理能力。每种 IT 产品及能力因为其定位不同，使用场景不同，其生命周期管理模式也不同。云管平台需要能够提供足够的扩展能力，让不同的 IT 产品及能力的生命周期管理模式在其框架内实现。而这种扩展能力也要求云管平台能够有独立的角色定位。日常绑定特定 IT 产品和能力的云管平台很难担当起这个独立角色。
■ 异构 IT 及多云对接：
企业内部的 IT 异构主要来自于两个方面，一是企业 IT 的演化和迭代是一个长期的过程，这就意味着不同阶段的 IT 产品及能力会长时间共存。最为典型的代表就是很多企业内部 IT 计算资源会同时存在有大型机、小型机、 X86 服务器、 X86 虚拟化、 IaaS 乃至容器云等。因为这个原因，绑定一种 IT 产品及能力的云管平台很难承担起整个企业 IT 能力云化 / 服务化的使命。
云管平台运维架构演进：
一是对基础设施的混合 IT 整合，形成一体化的资源池；二是混合 IT 的对接与管理，包括与原有 ITSM 流程的自动化对接， IT 数据流转与自服务的对接等。以云管平台为纲，向兼顾稳健性和敏捷性的混合 IT 基础平台转型，全面推进基础架构的升级。

2 、 PaaS 运维架构
基于业务发展的需要和快速进步的金融科技技术，越来越多的传统银行希望从技术层面更有效地支持业务创新，如微服务架构、更好的灵活性、扩展性、高可用性、更高效的业务上线效率等，因此建设并推广适合自身的基于容器技术的云平台是关键任务。
基于 Kubernetes 集群节点的运维可以从以下几点考虑并灵活运用：
· 主要资源指标监控、告警
· Node affinity /taint
· 镜像、容器 gc 策略
· 扩展节点设备类型 - ListAndWatch / Allocate
· 节点维护状态
· 时间同步
· 节点故障、自定义 agent 上报异常情况
· 节点资源不足时的处理
在不同的底层 IaaS 平台基础上，还可以充分发挥 IaaS 的一些能力来简化或者改善容器 PaaS 的运维工作。随着 Kubernetes 自身的快速迭代，升级也就成了不得不考虑的一方面，目前提供两种升级路径， in-place 或者 data migration ，分别适合小版本升级和跨度较大的版本升级。PaaS 架构用户不需要去关心底层的基础设施，只需要专注业务应用本身，容器 PaaS 以应用为中心，标准化、自动化应用的构建（ Build ）、交付（ Ship ）、部署运行（ Run ）流程，支撑应用的完整生命周期管理。通过容器云 PaaS 提供的丰富基础服务及之上的 SaaS 服务，提高 IT 设施自服务能力以及新业务的交付效率。

3 、 DevOPS 运营
云原生价值的最大体现之一在于对企业 DevOps 的支持，它将企业开发运维部门很好地结合起来， DevOps 将打破开发、测试、运维部门之间的隔阂，让整体的应用交付变得更快速。从技术角度看， DevOps 涵盖了应用的开发、编译、构建、测试、打包、发布的自动化流程，并包含了很多 DevOps 工具链。
Devos 的构想蓝图如下：

DevOps 落地：

DevOps 起于规划，行于设计，终于运营：
1 、规模组织的 DevOPS 转型是个系统工程，任何单方面和局部的调整收效都将有限；
2 、 DevOPS 不会让运维消失，但运维必须在工作思维、工作模式和软件工程能力上跃进；
3 、快速发展的业务域是开展 DevOPS 模式的优选；
4 、研发开始就要必须入局，从设计之初就开始为系统的稳定性考虑；运维也需要和研发一起提高对业务的交付效率和质量；
5 、资源和组件服务团队、 CI/CD 工具团队及 OPS 工具团队在技术战略规划、战术展开都要参与并通力协作；
6 、工具链的建设必须服务于用户， 工具链设计需要场景化，非场景化的设计会割裂完整的工作，损失工具链在提效上的效果；工具链研发战线不要拉得太长，以敏捷的思维优先解决让用户最痛的刚性场景需求
7 、 研发进入生产环境在初期可能带来系统稳定性质量的风险，做好管控，不要止步于恐惧；
8 、 系统上云工作需把握好节奏和规划好逃生通道并做有效演练；
9 、 转型初期见效可能不明显， 甚至会出现效能和质量的下降，需要及时分析问题所在并优化，要有耐心。

4 、业务运营
银行数据中心的重点不再仅仅是提供基础资源和维护，而是提供产品和服务来支持和实现企业的业务战略。在当前环境下如何利用人工智能、网络 SDN 、容器等技术，来支持快速增产的基础资源并满足业务需求。

运维中心在保证安全运营的基础上，持续打造自身核心竞争力，提出了将运维工作敏捷化、数字化、智能化、服务化的目标，具体包括以下内容：

5 、展望未来
随着 DevOps 的深化、普及，将会形成更加标准化的应用交付流程。PaaS 会逐步弱化 IaaS 层的一些概念，在某些需求场景下甚至舍弃 IaaS ，在物理资源上直接部署 PaaS 。微服务、服务网格、 APM 等应用侧工具逐步繁荣，用户的重心向业务架构及其治理方向转移。随着云的类型增多及其复杂性的增加，多云管理、云管平台也会出现强烈需求，另外用户对“云原生”的更多理解，会带动新的开发模式、开发框架的产生，比如 Serverless 等， 最终实现企业高效、敏捷、管理、精益 IT 服务管理的目标。

-全文完-