我们来看国内信通院的云管理服务等级的白皮书等级要求：
Gartner 认为提供云管理服务时需要具备三方面的能力：
第一，具备云管理平台（Cloud Management Platforms，以下简称 CMP），便于用户进行资源管理；
第二，能够提供托管服务，有相应的运维专家支撑；
第三，能够提供专业服务，即向公有云迁移的咨询和实施服务；
在信通院侧认为，云管理服务商提供了三个阶段的服务：咨询阶段服务（规划）、建设阶段服务（交付）、运营阶段服务（工具），追溯到90年代，一度认为是企业的IT托管服务商。代表厂商：IBM、HP等。随着云的出现，交付形式的彻底转变。这给很对专注做企业内IT托管服务的技术服务团队带来了‘趋势’上的利好信息。即：对外进行扩展业务触角，放大技术边际成本运营带来的营收。
数据，我们除了要学会看，更要消化成观点，国内有不少这样的内容分析服务商，比较有代表性的：虎嗅、亿欧、特大妹、云头条。其中还存有不少自媒体。所以观点有限且有内涵的输入，都是很多做业务和管理者的需要。
公开调研报告显示：
企业用云策略报告：
企业用云情况：
云管理服务商在国内特殊的行业背景下，衍生出来两类：
A.面向公有云的云管理服务 |
B.面向私有云的云管理服务 |
面向公有云的云管理服务需求通常来自于 互联网、媒体、零售等行业。这类行业企业上云更倾向于采用公有 云部署的方式，公有云的弹性扩展可以快速解决企业新系统上线、 客户高并发访问等问题，相应地也激发了面向公有云的云管理服务 需求 |
面向私有云的云管理服务需求通常来自于政府、金融、电信 等行业。这类行业企业对云的需求主要是从业务发展创新倒逼而 来，由于企业自身业务特点和对安全性方面的考虑，这类企业更倾 向于采用私有云部署的方式，因此这些传统行业也爆发了大量面向 私有云云管理服务的需求 |
云管理服务提供商组织全面转型：从管理支撑升级为转型赋能
A. 技术革新方面
B. 生产方式方面
C. 管理架构方面
D. 安全合规方面
PS：详情请参考信通院白皮书
六类云管理服务商：
在云管理服务白皮书里提到：人员、流程和工具是云管理服务的关键要素，且同时更加提到了‘ITIL’的中国特色两原则概括：
一、是从散乱的支持方式转变成集成的端到端的服务模式
二、是服务从尽力而为到服务可度量（确立SLA）服务等级
新的时期对MSP厂商的挑战和要求也会越来越密集而严格：其核心发展基于云原生敏捷适配业务的开发交付能力（这里要避开大集成的认知，必须是有业务思考并结合开发能力孵化出来的新的产品原型，并非交付盒子类产品的云原生（开发）能力（人头生意）。）
E. 资源层服务的技术要求「需要对云计算领域基础设施如OpenStack、VMWare、KVM 等上下游技术有较强的把控和应用能力，同时随着大数据、AI 类应用的规模化，对 GPU、高性能一体机、超融合等技术服务化的要求越来越高」
F. 平台层服务的技术要求（一是应用修补后迁移，二是应用云原生重构）「按照所服务的应用负载不同，平台化技术分为各类数据库技术、中间件技术、应用框架技术等统一云服务化管理体系的构建」
G. 迁移领域的技术要求「对应用的统一模型、体系的构建，对数据在各类存储介质中的迁移、同步、验证等方面技术要求提升，同时对云管理服务的灾备技术要求提升，尤其在混合云环境下」
H. 运维领域的技术要求「由于构建的体系复杂度攀升，基于机器学习、深度学习的 AIOps 领域的技术应用、自动化运维的应用场景越来越多，对人工智能赋能 IT 领域的技术要求提升」
PS：详情请参考信通院白皮书，此处不做展开
一个持中肯态度的话题:到底是合作共赢，还是主动进攻?
产业合作持续加强，上下游生态将逐步建立，云管理服务商需要拓展合作生态，完善自身短板。在云管理服务领域中，合作生态的建设尤为重要。云管理服务商须构建综合生态，通过多方合作满足复杂性和多样性云计算需求。云管理服务商需要和应用厂商、云厂商以及安全厂商建立合作生态，其中应用厂商包括传统软件开发商和 SaaS 厂商。
I. 软件开发商方面，云管理服务商可以和传统的应用厂商达成合作协议，深入了解业务的应用场景与软件逻辑，在云架构规划时提出应用的改造意见；
J. SaaS 厂商方面，云管理服务商可以与 SaaS 厂商建立合作关系，提早应对未来企业用户的复杂性需求；
K. 云厂商方面，云管理服务商需要与多家云基础设施提供商深度合作，尽快弥补局部能力短板，构建全生命周期云管理服务体系和灵活的服务整合交付能力；
L. 安全厂商方面，云管理服务商应在云厂商安全服务基础之上，结合安全厂商的产品或服务，为企业客户提供整体安全解决方案
注释：来自信通院工作研究报告（白皮书）
在国内很多MSP后起之秀也好，还是已经以MSP（管理服务提供商）价值形式经营多年之久的老牌MSP。都或多或少可能没有想过这个问题——到底是合作共赢，还是主动进攻？我们知道，MSP的定义是为用户提供不仅限上云迁移、云上管理以及各类数字化能力的服务商。其生意的形态可谓是超强多样化，举个实际例子：
M. 外包人力资源（研发资源、运维资源、顾问资源）
N. 混合云IDC托管
O. 各类云的专线生意
P. 企业中台的建设承接
Q. 各类云的转售代理
R. 各类第三方产品的转售
S. 等保服务的转售
又或者说，业务的未知性以及现有的不确定性，我们没有办法想到很远很全，这个话题在很多地方高层交流过程中获得的回答“没考虑过、想过但很难想好”
其特色可以用；大而全、多而杂，来总结。基本上把所有可以面向用户提供基于IT底座的技术服务全部包揽其中。所以大家也能明白这是一个非常重的野心思维，每次出现新的‘概念’‘口号’‘行业理念’可以比喻的理解为，新兴产业为了‘攻城略地’的‘行业二代保护伞’。过去做总集分销的，现在做云转售（或总集或区域铂金伙伴），在技术的底蕴上确实有了非常大且颠覆性的改变，比如交付形式。中小型（小而美）的企业的快速启动（冷启动、热启动）等等，都给他们带来了（成为明星创业公司）机会和生机。云的背后带来的商业、就业、行业都是相当利好的信息。
但不好的是，众多资本进入该行业后，给企业主带来的营收压力，业务增长上焦虑。这也是导致大部分后起之秀和‘老大哥’慢慢在‘strategy’和‘vision’开始越喊越大、越做越多。又加上云厂商（CSP）按照1000次/m的迭代速度，对产品性能和体验的狂轰乱炸的背景下，MSP自身在已经涉猎上的产品线上开始显得吃力。为何？主要是MSP的企业主要的‘企业主价值’为实实在在的技术交付落地实力。
换句话说，生意越大，人就越来越多。生意若没有连续性（e.g：第一年签完，第二年有风险续签，第三年有较高风险丢单），盛况maybe昙花一现。所以思考的核心点在于，在大量签单/丢单的时间间隙中，你给自身立一个什么样的长达3年以上的主线？可以围绕产品，可以围绕主营形式，也可以围绕某一个行业。当然这也是企业自身定位精不精准的话题，所以推荐在进场前要想好自己的定位。
1）短期定位———自给自足（云相关业务扩展、自负盈亏、产品雏形）
2）中长期定位——产品与服务驱动（产品驱动市场行为，定位逐渐清晰）
3）长期定位———产品+服务+组织（接受庞大组织，优化组织效率，产品做精做深）
注释：以上是常规的思考路线，仅供参考
最后也出于经验之谈，聊几个过去经历过的思考点，如果你打算起一一块MSP的话，不妨可以当作个‘花边新闻’看一看。
警惕点1：扩展业务触角时，注意勿打差异化，应重视MSP边际成本运营本质，比如堆人头
警惕点2：扩展业务触角，不是重复造轮子，勿陷入成熟领域再造‘天地’，比如第一阶段云管模块
警惕点3：切勿做着做着，把所有垂直厂商都作成了竞品or友商，比如迁移
从信通院的云管理服务白皮书的要求中，我们看到来自国家队分析的云管理平台的演进路线，当然仍然有看得见的趋势和看不见的技术不确定性。以下是从MSP主要核心的定位产品工具上来看，如果要做好云管，面向用户的广度产品的基本推荐思考方向（仅供参考，若有雷同纯属巧合）
定位：产品型
部署方式：私有化、定开
第一阶段：
T. 资源纳管聚合（多元化环境，多元化环境带来的console管理多而杂的混乱）
U. 统一的监控平台，（监控难度增大，报警‘浪潮般’，监控聚合的必要性）
V. 费用管理（云上资源费用收集管理）
W. 基础自动化功能（批量脚本（类ansible、saltstack））
X. 云管理平台的安全基础能力之用户权限矩阵管理
定位：产品服务型
部署方式：私有化、saas
第二阶段：
Y. 云上云下资源费用（原生）与自有计费逻辑模块结合，云经济效益的优化（费用分析），费用账单聚合（跨云厂商）的账单标签功能——成本治理能力
Z. 企业级流程合规治理（基础服务流程衔接，弥补用户方与厂商之间的流程管理缺失）
AA. 建立ticket受理实时服务平台，建立第一道护城河（接管厂商基础产品服务能力）
BB. 出现自服务门户Portal（云资源服务、第三方SAAS服务、第三方管理服务购买）
CC.资源聚合后的基础环境操作的（服务器开通、vpc、计算相关功能）开通接管
DD. 环境应用的编排能力（自动化+环境联动配置）
EE. 出现敏捷运维的管理理念和工具（从脚本备份执行到平台服务化）
FF. 拥有基础知识wiki库
定位：产品服务型
部署方式：私有化、saas
第三阶段：
GG. 开放工具平台集成能力，出现API或异构等围绕用户价值的工具，类似集成Jumpserver
HH. 服务网格能力
II. 容器平台接管&部署维护能力
JJ. 厂商云经济效益能力IAAS/SAAS/PAAS（公开产品）动态分析能力（可动态观察各家厂商的费用性价比能力）
KK. IT治理管理大屏信息平台
LL. 知识智库/图谱（智能自助服务工程师机器人）
MM. 项目管理协作平台能力
NN. 私有化部署能力
OO. 灵活可任意源到任一目的的迁移自服务平台（可基层厂商自有平台，迁移平台集成的思路）
PP. 行业洞察力资讯分发平台（细分市场内容分发平台）
QQ. 代码仓库接管能力
注意点4：MSP核心显性产品是云管，隐性产品是交付（ops/dev），始终要以平台为基座集成多个垂直厂商产品（场景）能力，站队无法避免，要慎重选择伙伴
注意点5：走技术驱动，还是走销售驱动，定性在前发力再后
注意点6：开发者对public cloud的掌握成熟度，直接决定业务对外制造场景的适配效率，从零到壹难，从壹到拾不难。
将警惕点与注意点结合起来看，进入MSP行业也好，做MSP业务扩展自身的技术能力也好。在很多专有和行业的场景里，如果没有比较明确的‘做什么事’的定位，很容易业务不增反降（包含士气），因为sale-self这件事对工程师来讲其实是有一个天然的势在必得的目标结果。所以KPI考核的设计，尽量别让工程师上来直接扛，前车之鉴~！！
