引语
2018年正好是改革开放40周年，在改革开放之前，有个很好听的名字“计划经济”，统筹规划国民经济，小到居民用的煤油火柴棒，大到国家大型水利枢纽工程、国防建设等，事无巨细，国家都统筹规划着。随着这个“解放思想，实事求是”的改革开放，政府部门开始转变职能——抓大放小，逐渐转变成主导国计民生的大工程，其它都是民营经济补充、相辅相成，因此慢慢激活了市场经济，未来一定会以转到服务民生为本，更丰富了居民百姓的方方面面……
何种组织能驾驭云服务管理平台
■ 企业IDC中的组织架构剖析
作为IT数据中心，IT资源粒度小管理，某种程度上真有点类似于改革开放前后的对比。数据中心一般都需要规划和管理（manage）数据中心IT资源（resources）方方面面。当云能统一维度IT资源时，于是就产生了如何规划和管理这个资源粒度的问题，便有了各种精细化、精益化等各种高大上词的管理平台，毫无例外，都是从管理者（administrator）角度去考虑如何更精准管理、如何更便捷实用、操作好用地管理IT资源。因此如何找到周边环境和定位关系，是云服务管理平台生命力所在。
■ 带有自研团队的大中型企业IDC
比如借鉴中国人寿保险股份有限公司的组织架构，可以清晰看到信息技术部、研发中心和数据中心，共同来维护业务运营中心，因此需要心云的运营和运维在数据中心就有运营场所，同时信息技术部对云技术选型、架构评审等进行协助，通过研发中心的技术投入，可以完成对云服务管理平台的定制化落地，数据中心的这种运营机制、组织架构及其运转流程来适应性开发实现云服务管理平台落地。
■ 云服务管理平台成功的关键因素
找准周边关系各种环境后，融合、集成、整合之类统一纳管（cover）IT资源范围（scope），也便有了不同类型IT资源管理工具（tool）链专业化平台逐渐产生。即便如此，也还是需要逐步统一操作（operate）、统一流程（process）、统一门户（portal）、统一开发（develop）及其框架（framework），统一各种引擎（engine），统一编排（orchestrate），最终自动化（automatic）交付，而这些交付最终都期待以数字（data）化形式，通过面板（dashboard）展示（visible）。目标就是各种IT资源都以粒度交付，让这些不看见粒度资源变成面板上的图标和数字，让人更有实体感。实质感受还是从管理平台到被管理环境进行控制管理。
对于整个平台首先要对数据中心的环境先适应，即覆盖环境的所占百分比，对于云服务管理平台在整个数据中心的定位，即与数据中心周边环境的进行交互的元素和接口，也需要梳理，并且建立协作机制和接口通信规范。
针对接口规范需要采用统一的接口服务能力，比如当下采用API-gateway 来实现所有数据交互对外输出服务，需要完成数据标准化、粒度化统一，如此既保证了平台本身的对外数据和服务输出的稳定性、安全性、标准化，也更易于推进自动化交付内容。
云服务管理平台需求源
云服务管理平台的面向使用者范围，就决定了需求源的范围，根据这个范围，需要规划根据需求交付的服务目录和服务内容。这就是云服务管理平台的生命力和交付内容的管理生命周期。
■ 使用者定位
使用者定位一直是所有产品都很难界定的事情。作为数据中心企业内容服务平台，在数据中心规模小的情况下，在成长过程中，通过平台和系统可以使管理员释放出更多的时间和精力来管理整个数据中心的交付和运营、运维，此时的云服务管理平台是面向资源管理员的操作平台。
随着时间的推移，当数据中心规模越来越大，同时业务也百花齐放，异彩纷呈，根据不同业务，对数据中心的服务也要求形态各异，服务特殊的要求和标准与日俱增，此时需要的是通过平台将这些资源粒度服务逐步释放到业务应用需求的手中，业务可以随心所欲地在规定的场景下使用资源，大大释放资源管理员的时间和精力，此时的云服务管理平台是将数据中心资源作为商品服务，可以任由业务使用者进行搭配使用。云服务管理平台体现的是自助服务和服务目录所需要的服务开发核心能力。
■ 云服务管理平台构建面向用户类型、覆盖资源环境、数据粒度规范
云服务管理平台将数据中心的资源作为服务粒度统一交给平台进行服务推广，因此定义服务所覆盖的内容，内容要素所构建的资源粒度标准，就是云服务管理平台在服务输出过程中需要交互的数据粒度规范。而这些数据粒度就是覆盖资源环境的适应性来体现，适应性广度越大、精细化越深，面向使用者交付内容的深度也就越深，服务内容开发要求也就越高，用户使用起来也就越能体现专业化和服务化。
■ 面向使用者的统一门户
统一门户是时下所有数据中心都必须面对的交付。首先需要用户安全统一认证，用户安全认证后，不同部门所在组织架构中，面向不同用户使用的资源范围就不同，交付服务也就不同，当然根本还是用户关注的内容也不一样。
因此，统一门户下，通过不同操作控制台，完成资源或者业务应用+资源的自动化交付，这是作为云服务管理平台需要集中的功能交付，实现的内容以场景化交付。当然这个过程必然会涉及到不同组织的审批流程、这个流程和业务及属主的配置管理库（CMDB）及其关联的资源关系。这些在日常中组成了ITIL模式下的变更管理及组织运作的流程审批环境。这些都需要通过梳理业务CMDB和资源关系，以保证业务和资源场景全链路数据闭环。
云服务管理平台规划设计
有了使用用户的定位、锁定了需求来源、限定了交付内容，云服务管理平台的架构基本就以保障业务运行为中心任务进行规划，其设计交付内容就以满足用户使用为目的，构建服务研发团队，对服务内容——将数据中心资源进行服务化改造进行输出。
■ 平台规划交付实现路线图
首要任务是数据中心将资源交付自动化能力输出，释放资源管理员时间和精力，转而通过资源管理员日积月累的能力进行服务化改造，即将资源管理员的能力上升到服务目录下的服务内容进行输出。将这些服务内容逐步优化以提升用户体验，以迭代和持续改进的递进方式不断修复优化整个云服务管理平台。因此路线图先以自动化为中心进行交付，然后逐步将自动化内容按用户进行服务化改造，当然这其中的数据粒度逐步改造是必不可少，也必须将这些数据分层次、优先级进行持续实现。
■ 满足内容交付的技术选型和架构选型探讨
对于技术实现，在当前大环境下，宜采用自主可控技术体系，即架构安全、技术开放、高可用、高可靠、支持持续改进和服务化改造。数据中心的企业架构，无论是技术底层和网络环境都相对复杂，因此需要考虑架构适应数据中心环境，比如两地三中心，基础资源多个版本共存，用户访问安全、数据安全和易访问性的冲突等。总之，相对于云服务管理平台来说，一般将资源放入管理方和被管理方，业务应用运行环境放入被管理方，以IaaS、PaaS、SaaS 不同形态的服务输出，平台只是将这些服务进行组合编排提供给不同角色用户进行使用。
每一种用户需要完成的服务流程大体一致，提出申请，经过若干审批后获取到所需要的资源服务，有的以 IaaS 资源，业务用户自行定义和改造，自定义资源的使用内容；有的以 PaaS资源，直接渗入业务应用开发当中，减轻业务应用开发对资源的维护需求；有的以 SaaS 服务进行输出，将业务作为完整服务对外输出。
以上综合的描述，大致可分为资源规划方、资源管理者、资源需求方、资源使用方、资源操作维护方等。其实这些都有相应的组织部门去对应，而且每个人对这些资源关注点都各有千秋，说到底就是各方都希望看到各自的资源全貌，每个人都期望看到自己关注的内容。
由此可见，数据中心IT资源管理需要满足不同人不同的关注内容，有的要求功能实现，有的要求数据按其关注点展示，有的要求流程连贯，有的要求统一门户，有的要求操作便捷，而且安全也要统一认证，凡此种种，包罗万象，都希望一个服务门户就能涵盖。这真有点像：百姓有问题就找政府、找警察，仿佛这两者就能管理一切。这大概就有点类似当下云服务管理平台的定位。
云服务管理平台交付实践
不同的技术选型、不同服务交付内容、不同的面向用户定义，完全有不同的云服务管理平台身份，本次实践是面向所有业务用户进行云服务管理平台实践。因此需要对资源交付到使用者相关的安全权限打通、设计防火墙、堡垒机等均要全链路闭环。
当前实践采用了基础设施即代码（Infrastructure as Code – IaC）的理念进行云服务管理平台技术架构进行框架设计，围绕自动化交付内容进行对接集成，以业务用户的视角进行服务化设计和实现，围绕数据中心安全对业务运营进行安全保障的宗旨进行数据粒度交互全链路闭环。
功能架构上，可以通过将各资源管理平台汇聚到云服务管理平台，当然这其中需要做各种协调和妥协，毕竟不能作为专业化平台操作使用，但是对于诸多普通用户的操作使用，是完全可以的。因此功能架构就要覆盖资源范围广度和深度，要找到足够对接驱动接口。从技术实现角度，目前很多采用openstack作为这一层的驱动层（软件定义），当然也有自行研发或采用开源的诸如terraform 等对接各种资源，也可以自主开发纳管资源模块的接口驱动层。这一层一旦选定，基本上功能模块、纳管资源类型范围基本上确定，也可以说是覆盖数据中心资源的比例基本上确定。当然如果对接资源接口驱动层是开口，即可以由应用自行开发对接插件（IaC基础设施即代码-plugin），随着时间的推移和投入，覆盖资源范围和深度将逐步增加。
数据架构上，需要映射各种不同维度的数据，甚至强行将这些数据带上属主、属组，之后同步入云服务管理平台的数据层（或者统一数据层）进行角色和权限加工，目的就是为了使用户对数据的感受是自己在用自己的专属数据，这部分数据梳理工作量和设计数据展示耗费诸多人力和时间，当然也要在数据层保留相当冗余量的数据，并随时为用户提出的需求而响应并启用这些数据。这部分数据来源主要可以分为两类，一类是资源属性相关及其操作过程附带添加各种标签，另一类便是纯粹用于管理和安全考虑加上的关联关系和识别标签，这二类数据要相辅相成，实现用户使用目的性和便捷性。
从用户角度，每位用户都希望独自拥有属于自己的操作界面和数据，并且将相关联的数据、权限、角色、资源等均属于自己范围内的数据，在平台的功能服务下，满足用户日常操作和控制管理，而并不期待从过多数据和过大范围中寻找属于自身的内容。因此不关注，更不期待这些不必要的内容影响自己的日常使用。
从管理者角度，任何 I T 资源都脱不开的一个命运，就是生病（出问题或事故）和上手术台（变更），任何些许的变动，都会影响到诸多使用方，因此如何评估资源变更带给使用方影响，就需要各方管理者提供方便的查询，或者反过来，资源管理者通知使用变更了，与使用方确认是否受影响。
■ 交付团队角色定位及可持续优化战略实施
云服务管理平台交付团队是连接业务用户和资源管理员的中枢纽带，对上（北向）业务应用户视角查看业务所需要资源支撑的种类、容量、运行效率，及其业务应用涉及的所有资源维度数据及相关负责人信息进行展示、构建及勘误更新等。
考虑资源的服务交付逐步完善，因此将安全、网络、各式存储、资产管理、用户安全及相关PaaS服务、云桌面集中于统一门户，并以服务目录的方式进行可持续优化升级和改造，不断提升用户体验。
■ 平台覆盖环境及其数据粒度标准
用户服务全流程闭环，即要通过云服务管理平台将资源数据粒度与业务用户和管理资源属性粒度保持关联和一致性，这就需要一个强大的CMDB进行融合，没有强大的CMDB将这些粒度数据进行关联，难以将大相径庭的两者粒度数据进行全流程闭环。这个两个维度的粒度数据的关联是要将各自维度的数据进行模型化改造。
■ 自动化交付内容和使用者需求的挑战
自动化交付是所有数据中心都梦寐以求的努力方向，但是自动化的深度是极其难以用数字化和用户体验来形容的。诸如IaaS 服务，如果仅供给异构虚拟化下的各种虚拟机，比较简单；如果不同版本且异构虚拟化就有点难度了；若按照业务应用架构进行编排后自动化交付资源架构（同时通过自动化将所要基础软件也进行不同版本进行自动化交付），这其中的客户化和自动化脚本编排和管理就变得异常复杂。那么如何在自动化交付和实现这些自动化所需要的开发间做一个平衡？不同的组织和不同业务需求有各自的需求，难以有一致的标准。因此云服务管理平台对于不同组织，是有不同的交付内容的，甚至可以说有些组织是难以驾驭这个地道的、以服务为中心的云服务管理平台的。
云服务管理平台运营
数据中心所有平台最终多需要交付运营和运维，运维由开发团队可持续维护并且迭代升级，这是数据中心平台的生产方式。
■ 使用者角色、权限和职责探讨
云服务管理平台定位如果如前所述，那么云服务管理平台的核心是什么？脱口而出的答案就是服务目录，服务目录背后就是各种专业平台或者工具的能力，云服务管理平台真的就是统一的入口且带有内容（服务目录）的门户。
云服务管理平台的周边环境可就复杂了，有要去对接的控制入口，有要验证的各种服务，有要同步的各种数据，有要集成的专业化页面或者功能模块，有要能提供所有数据的对外服务接口，不同角色的人关注的内容都得有，不过还有一个极其重要的、需要云服务管理平台做的，就是将这些专业化平台或工具所提供的数据进行分角色、分属组、分权限去展示。这大概就是云服务管理平台需要大力做的内容，可以说是核心，本质是将这些各种渠道来的数据带上属主和属组及其角色，再添加权限管理。
■ 平台实现团队与运营团队关系
运营团队要为实现团队提供运营过程种所产生的相关问题和用户反馈，如果能提炼并且区分优先级，平台实现团队与运营团队就会是完美的结合，为云服务管理平台的愿景提供更完善的服务。
■ 平台分享粒度数据完整性、一致性和鲜活性的前提条件
所有平台的集成性都是以数据交互为媒介，实现数据完整性、一致性的服务传递，当然在平台的每一个部分都有数据鲜活性的保证和前提条件输入。自动化采集能力、日常操作的数据更新，是保证数据鲜活性的必备条件。
■ 平台功能与粒度数据维护职责界限
平台功能不应该以人工维护数据粒度和数据准确性作为平台的功能性存在，而应该是关系映射、粒度模板标准化来推行数据完整性、一致性和鲜活性，数据属性具备中子性，不以传递的变化为目的进行数据变更和切换，而应该以关联为依据做界限条件，如此能保证平台与周边系统完成数据交互集成。
未来需要面向的开放问题
所以云服务管理平台面向谁使用，在IT数据中心中真的决定了该平台的生命力。至于架构、专业功能模块、接口等，都需要满足用户的真实操作，因此需求多数以满足实际用户操作为要。云服务管理平台门户面向的用户决定了功能和数据内容，因此定制化开发等因素要与真实用户操作需求相关联，具体内容应用户需求而关注。正因为如此难于将数据定出属主、属组和增添权限管理，因此很多把云服务管理平台作为产品及服务对外销售时，多数仅关注从资源管理员（administrator）的角度去实现功能和交付内容，通过管理员这个角色分配和连接各个不同关注点的人员。本意是通过平台将IT资源的服务更加透明和精细化给用户使用，却变成了通过各类管理员去使用或分发资源数据。所以平台的使用局限仍然在资源部门。想通过平台释放操作和管理资源重复劳动分发到用户手里，变得如此的遥不可及。
■ 平台功能架构设计
云服务管理平台作为服务枢纽中转站或说汇聚点，如何能将各方资源的数据汇聚后，找到属主、属主而添加权限管理，这就需要云服务管理平台功能架构和数据架构做出更大的职能和协调。从技术角度实现来说，无论是选取什么底层技术，比如Openstack, Terraform 或其它相关管理平台，都需要适当的开发团队来完成各个资源组控制、网络可达及自动化交付。如果光采用产品，那么这个平台的生命力肯定仅限于在资源管理团里使用和维护，这就是其生命力的范围。
■ 技术先进性探讨
当然，目前几乎所有的IT资源或者业务应用架构都会说高可用或分布式，但无论怎么高可用或分布式，一旦资源变更（哪怕某个物理重新启动）都会担心影响业务应用是否正常运行。因此高可用或分布式，是在理论上正常运行的情况下，一旦某台或某批次设备变更时，一定会实现谋求业务应用允许可变更的时间窗口。
因此云服务管理平台对于服务内容其实不光限于资源本身的服务，也影响甚至配置了与业务应用相关的服务，比如云服务管理平台一般会将日常业务应用变更升级的发布部署也融入该平台，作为一个服务大类供给业务应用的维护人员。可以说资源服务提高了业务响应能力。
