私有云在银行业的实践：运营策略与管理思考

       上云已成为企业数字化转型的必经之路，出于安全、稳定、自主可控等考虑，金融、政务行业往往会选择自建私有云。银行自建私有云一般采用主流云厂商提供的搭建方案，而云的运营却需要银行结合自身情况独立思考。如何做好云运营，是上云马拉松的后半程，是用好云、管好云的深水区，是一家企业上云经验的沉淀。

        此前部分金融企业没有严格区分运营和运维，但当业务大规模上云时，私有云建设成本持续快速投入，云资源的治理等问题突出，有必要将云运营与云运维进行拆分。云运维面向的对象是云基础设施，目标是“活着”，关注云平台各组件的可用性、算力资源池的稳定、各站点的容量、变更升级与自动化等；云运营面向的对象是用户，目标是“活得好”，关注用户体验、运营模型、流程治理、运营规范、成本管理等。笔者尝试从“运营模型、运营流程、运营规范、成本管理”这几个方面来讲述怎样做好私有云运营。

01 以应用为中心的云运营模型

    模型是云运营的框架，设计云运营模型需要考虑的第一个问题是如何处理好“人”、“云资源”、“应用”三者之间的关系。如图1所示，对于大部分公有云来说，需要注册一个账号来申请云资源，账号与账号之间资源隔离，而账号的背后是人，所以公有云建立的是人与云资源的直接关系。公有云里有“项目”的概念，用户可以根据自己需求来新建一个项目，例如可以根据组织架构、业务拆分、应用系统等维度来创建项目，然后再为该项目申请资源，这里的项目相当于云资源的集合或者属性标签，项目属于账号，实际上维护的还是人和资源的关系。

图1 公有云资源归属模型示例

    在私有云中，如果云资源也直接归属账号，会让账号成为一个重要且需要维护的资产，一方面需要考虑账户的安全，另一方面在企业内部人员岗位调整或离职的时候，就需要对账号进行交接或清理，或者需要联系云平台管理员手动将云资源迁移至新账号，这些都会提高云资源运营的复杂度，并不适合银行的管理模式。

图2 建议私有云资源归属模型示例

    比较好的做法是以应用为中心对云资源进行运营管理，将人与资源解耦。如图2所示，资源归属于应用，当某人是该应用的管理员时，才有权限来为该应用申请资源和管理该应用下的资源。而应用与人的关系则由银行负责应用管理的处室按既定流程维护；应用的立项、架构等由银行项目管理、架构管理处室维护；人员信息由人力系统统一维护；互相解耦。

    “以应用为中心”还包括按照应用系统生命周期不同阶段来对云资源精细化管理。一个应用系统从项目立项到系统下线会经历开发、测试、投产验证、生产上线等不同阶段，每个阶段对云资源的需求不同。例如应用系统在生产运行阶段，要求高可用、性能稳定等，这时就需要多AZ部署且资源池不能高超分；而在开发阶段，应用并不正式对外提供服务，不需要多AZ部署，从资源节约的角度，使用单AZ高超分的资源即可满足。

图3 云运营模型示例

    如图3所示，把应用对云资源不同需求的这些阶段定义为各个“云环境”，每个云环境设置“租户管理员”，负责本租户内云资源的分配、审计、治理。在每个租户内为每个应用系统设置“应用管理员”，负责该应用系统下的云资源的申请与管理。应用之间资源隔离，且不同环境下的相同应用也是资源隔离的。在开发测试等环境提高超分比来提升资源使用率，非功能和生产环境重点保障应用的稳定性，从而实现云资源精细化管理。

02 贴合组织架构的云运营流程

    流程是承担不同职责角色间的接力赛跑，好的流程可以驱动云运营各项工作高效稳定运转。云运营流程的设计应包括“流程的目的、不同角色的设置、角色的职责范围、角色间协作机制、SLA时效性考核”等，银行可根据自身实际情况来梳理。设计与组织架构相匹配的运营流程，是避免出现个别工作职责无人管或扯皮的有效手段，笔者认为云运营流程中应包含“六个关键角色”和“三条关键流程”：

• 应用管理员：应用所使用云资源的直接责任人，可以为自己负责的应用系统申请云资源，有该应用云资源的操作权限。应用不同环境管理员不同，开发环境管理员为项目组开发人员，测试环境为测试管理员，生产运行环境为负责该应用生产运维的应用管理员；

• 租户管理员：某一环境下应用云资源的统筹者，负责该环境下应用云资源的发放审批、云资源操作及变更的审计/审批、云资源优化治理等，租户管理员有该环境下所有云资源审计查看权限、没有资源操作权限。租户管理员可划分为开发租户、测试租户、投产验证租户、生产租户等；

• 上云咨询师：银行内部很多项目组或管理员对上云过程并不了解，不能很好设计出应用在云上的部署架构。上云咨询师负责设计不同类型应用的云上部署架构，同时负责和各应用项目组沟通，确定该应用系统的上云计划及需要申请的云资源类型和规格;

• 云运营管理员：一是负责治理租户，跟据底层资源池扩容情况来动态管理各租户的云资源配额，同时监督各租户资源使用和治理情况；二是根据各租户云资源使用情况协调与跟踪云底座管理员扩容计划；三是牵头组织云运营规范的建立与云管理平台的建设；

• 云底座管理员：负责云平台本身及各组件的运行维护与升级变更、算力设备的选型与采购、云资源池的容量管理、扩容计划等，负责向基础设施组提设备上架布线等需求并跟踪；

• 基础设施组：基础设施组是设备管理员、网络管理员、机房管理员的统称，是云运营流程中的后台角色，负责算力设备到货盘点、上架布线、交换机、访问关系、机房建设与巡检等。

图4 云运营流程示例

• 云资源采购及入池流程：用来维护云资源池算力设备的预算与采购、扩容计划、租户资源配额管理等；

• 云资源交付流程：应用所需云资源的确定与交付；

• 云资源治理流程：考核应用云资源运行情况，依照云资源治理原则推动提升云资源的使用率。

    其中云资源采购及入池流程的详尽设计能够简化云资源交付流程，首先收集各应用系统各个环境的资源预算，汇总编写云资源签报，根据资源池情况分批次购买、入池，资源池每次扩容量按各环境需求比例扩充至各租户可用配额中，租户管理员便可跟租户内应用需求情况自主决定云资源使用计划。这样做到了云运营的权力下放，让更了解应用该环境情况的组织来交付和管理。三条流程具体运转详情如图4所示，这里不再赘述。

03 企业级的云运营规范

    运营规范是把各项IT能力转化为标准化IT服务的关键，银行IT系统建设过程中，引入一个新产品或技术组件，就是一项新IT能力的引入，需要制定配套的标准与规范来约束这项能力如何使用和运转，规范化的能力才能对外提供服务。企业级规范是指规范的发布与评审等由银行专门负责维护标准与规范的处室按行内既定的流程统一维护，而不是某个管理员写一个规范就可以自己运营。银行私有云的建设，就是各项云能力的引入过程，出于安全可控、稳定、成本等考虑，往往会引入多家云厂商的多款云产品，这些云产品之间大多是技术异构的，甚至同类产品间原生的管理理念、相同技术点的概念也不尽相同，需要银行科技部门自己消化吸收并加以抽象。

图5 云服务目录部分清单示例

    笔者认为银行云运营规范应包括“云服务目录”以及配套的“云服务规范”与“管理原则”。云服务目录相当于一家餐厅的菜单，菜单上每一道菜都标有售价、菜名甚至照片等信息，菜单会让我们对这家餐厅有个全局的认识，知道这家餐厅能做哪些菜。对于一家星级餐厅来说，菜单上每道菜都有固定的制作工艺与流程，这样能保证菜品质量而不依赖于某位大厨，云服务规范就相当于每道菜背后标准化的制作工艺。除此之外星级餐厅为了保障顾客的用餐体验，会制定一些餐厅管理制度，比如每日消毒、盘子要刷三遍、及时清理顾客用餐垃圾、不许吸烟喧哗等等，这些提升用户体验、规范用户行为的制度就相当于云运营规范中的管理原则。

图6 云服务规范与管理原则及设计方法示例

    在ITIL中阐述了对服务目录的定义和相关要求，概括地说，服务目录应包括“服务范畴、服务描述、服务提供者、服务级别”。银行云服务目录中每项云服务提供者应为该云产品的引入或建设者，他是最了解这项技术的人，他需要负责设定服务范畴、设计该项云服务的规范与管理原则。如图6所示，规范与原则应依照业务场景来设计，以“职责清晰、简单易懂、实用高效”为设计原则，注重提升云服务的用户体验。云运营管理员负责制定基础通用类管理原则，负责制定云服务规范的编写标准，同时也负责初步评审各云服务提供者所编写的运营规范与管理原则，并将之汇总为体系化的云运营管规范，报由银行规范管理处室审核并面向全行发布。

04 基于FinOps的云成本管理

    随着应用系统的大规模快速上云，银行科技部门需要持续的投入，这些科技投入不直接产生经济价值，而是通过保障业务敏捷投产、业务稳定、提效降本等方式支持业务来创建价值，评估科技的投入产出比是一个比较复杂的问题。

    银行科技投入涉及的相关方主要包括财务部门、科技部门、业务部门，三者管理诉求不同，财务部门一般相对缺少对云资源采购预算的决策依据，较难精准判断科技部门的预算申请的合理性；科技部门缺少对业务云资源需求合理性的精确评估手段，对科技投入产生的业务价值较难评估；业务部门，发展为重，可能会超量申请云资源，造成资源浪费。面对这些问题，需要一套融合三方视角的云成本闭环管理方案，算清云的成本和效能，达成共识。

图7 FinOps理念框架

    FinOps是“Finance”和“DevOps”的组合词，图7是Linux基金会对FinOps理念框架的描述，FinOps强调在运营过程中进行成本管理和资源优化，倡导各方彼此合作，通过精准的云服务成本评估、云资源分类和成本分摊来塑造成本可视化能力，并分派资源优化任务，实现提效降本。

    依照这个思路，首先需要建立云服务成本模型，计算出单位云服务的交付成本，进而通过业务实际的用量将云投入成本公平、准确地分摊至业务（应用）。云服务成本模型应包括固定资产成本（算力设备、网络设备、机房成本等）和无形资产成本（数据库、中间件、操作系统等）以及人力成本（运维、运营、开发、科技外包等）。再者，需要考虑不同云服务的属性特征，例如云主机与裸金属等消耗库存（CPU、内存、存储等）的云服务，应与DNS域名、公网IP这些不直接消耗库存的云服务定价策略进行区别。依据云服务成本模型与不同种类云服务的定价策略，合理的对每项云服务进行定价。

图8 云资源计量计费方案示例

    如图8所示，需要建立计量计费模型，根据应用云资源用量和使用情况出具计量与计费结果。计费结果侧重的是应用的云资源价值，包括计费详情和账单，目的是算清业务的云资源成本，实现科技投入对业务的分摊；计量结果侧重的是应用云资源的合理性，包括资源运行数据、健康评分、优化建议等，并分配资源优化任务，推动提升云资源效能。

图9 云资源优化建议示例

各应用可根据云资源运行情况自行优化，对于使用率低的云资源，应优先考虑是否降配至较低的规格来释放资源。再者可以如图9所示对不同云资源进行深度优化。云运营管理员负责监督应用的资源优化情况，按照云资源治理流程，进行‘应用红黑榜’晾晒考核，并对长期黑榜的应用进行降配或回收，提升云资源使用率，盘活云资源流转。

结束语

 笔者认为做好模型设计、流程梳理、规范制定、成本管理是做好云运营的关键，是将小饭馆变为星级餐厅的必要途径。除此之外，需要一个将它们落地执行的定制化开发的平台工具—云管理平台，作为云运营的入口来统一服务、统一管理、统一运营。希望以上内容能为各位同仁提供参考，共同探索应用高质量上云！