云资源运营工作总结
前言 -- 本文目标读者
随着云产品的同质化和停滞化，云计算产品和研发的区别越来越小了。未来公有云厂商之间、公有云和自建云之间的区别，就是要看资源运营的精耕细作能力。
本文的目标读者是：
专业做运营的表哥表妹，在不具备IT技能前提下，怎么从纯数字分析的角度看云资源运营。（本次配图用和大人）
企业高管们，日常看业务数据发愁，也常见运营和产品为数据掐架，读读本文心里有数。（本次配图用乾隆）
各位云产品和云运维，无论是想转岗运营还是更好的协作和撕逼，也可以看一看、转一转这篇文章。（本次配图用纪大人）
第一. 收益统计要划片儿
要做云资源运营决策，先要做好盈亏统计，不同公司不同领导甚至各个项目的资源盈亏统计的方法都不同：
资源盈亏的统计口径多变，执行人最好的方法就是“多问老板”和“看紧财务”，好用的笨方法是“本次统计确实和上次口径一致”。
在老板不发懵、没特殊小算盘、暂时没改变主意的前提下，我们尽量将统计口径清晰明确到纸面上。
各产品线的营收可以精细到每个账户每个时刻，但资源成本是个要划片统计的粗账大帐，最常见的资源盈亏统计范围有三种：
IaaS云因为各产品相互捆绑高度相互依赖，通盘考虑机柜、硬件和带宽接入，以“城市/节点”这类单位，进行聚堆划片统计。
我没用“Region/AZ”等产品概念，因为盈亏要看收入更要看成本，多个AZ可以共用一个备件库，多个Region也可以谈同一个运营商网络合同。有些云厂商会严格重合“节点”和“Region”，但有些厂商会更灵活的组合和拆分。 我举个另类的反面例子——“运营商带宽跨大洲合并计费”，虽然这确实是在给云厂商减负，但是运营算成本拆分和增删决策时非常头疼，很容易搞成糊涂账。 功能型PaaS和SaaS最易于做盈亏统计，直接用成本价采购IaaS资源就是成本，按产品售出营收算收入就是收入。
性能型PaaS（比如CDN和对象存储）到了成本统计层面也是IaaS；但是产研侧可以细粒度腾挪调度，在大资源池里还可以划出小资源池（设备组），产研对运营行为的影响力度也更大一些。
第二. 做分类完成资源认知
认识一个事物，最简单的方式就是套框分类；横看成岭侧成峰的把玩过程中，我们就认清了其共性和特性。
云平台要运营的资源数量和特征很多，为了从成本运营的角度去认知资源的类型，我们可以按照这五个维度去进行资源分类：
单价和月租金额：包括资源启动成本和资源维持成本，这个成本数字是做复杂运营计算的基础。
供应商稀缺度：对于垄断供应商的资源，我们态度要好、下手要快、还要接受退货失败。
部署速度：部署越快的资源可以减小预占空置了浪费；部署速度慢的资源容易带来更多关联资源的空置成本。
上游库存充裕度：上游供应商的“免费库存”到底有多大，优先给谁用，这对于大资源量快速弹性的云产品很重要。
撤销退货难度：未开封设备想退货、网线用到一半想退租、已有合同想改签，都要考虑可行性和成本。
在上述五个维度的基础上看资源，我们就能将具体资源进行详细的分类和描述。在实操环境大约有十几种类型，限于篇幅我只举五个例子。
一次性购买后按月折旧的资源：比如全款买设备买硬件，将DC改造为IDC，长租IP段。
长租只能按照供应商的规矩退租的资源：比如长租低价服务器、带宽专线和IX接口。
可能随时耗尽的稀缺资源：比如矿潮中的硬盘和显卡，比如某个国外运营商居然搞限时打折促销。
冗长交付周期和巨大施工成本的资源：比如某些地区的海关清关速度和100%的高关税。
可灵活短租和随时采购的资源：比如短信通道、融合CDN、虚拟专线网络等等。
第三. 行为定义和运营决策
我们对资源做的运营操作行为，就一堆有限也无限的工程实施行为。我们要先明确这些施工行为的上下游依赖和详细行为，也要经常为这些行为定义和更新行为触发条件。
要为每一条运营行为做好定义，这需要掌握涉及资源的特性，更要了解整套行为的目的和细节：
预期收益：如果执行某个资源采购或者撤销操作，能带来什么收益？
eg1.. 如果我买500台服务器，那我能卖3000台云主机，今年能有5000万收益。eg2.. 我们必须预留5个机架和20台备机，才能保证弹性扩容存储池10PB。
启动和工期损耗：本次运营行为带来的采购退租、施工人员、切换冗余、安抚客户等等成本，算一下总账再分一下损耗，好论证是否值得启动该动作。
行为前提条件：需要确认行为连带资源，需要确认与节点宏观规划是否相违背。eg1.. 比如扩线要看一下是否有网卡，比如扩大量服务器需要确认电力和机柜施工。 eg2.. 比如某节点大客户预计半年后迁出空置，那就避免大规模新增采购建设。
实施和项目管理：如果确认启动该操作，需要多久工期、多少执行部门去配合，这就是常规项目管理工作。
下游交维交产：资源部署完成后需要交付运维纳入生产资源池，可能也需要产品和研发做一些初始化、引导客户使用、引导业务迁回等工作，如果是缩容还可能是利旧和归库。
在明确了资源的性质和每个行为的上下游依赖以后，何时触发这些资源运营的行为变的清晰可控，具体执行找到决策责任人和更新负责人就行了。
一个决策责任人：一个资源扩缩容需求的受益人或受害人是谁，需要他来决策和推动资源运营动作。
一群更新参与者：无论是资源状态、节点定位、工期损耗、实施团队状态，甚至精细到机房有没有封网，物流有没有拥塞，这些信息都需要及时更新给决策责任人。
第四. 运营行为的外延思考
说完了正文，我对云计算资源运营行为也谈几点外延思考的碎碎碎念。
4.1 人员评估和管理
不同公司里决策人和更新者都不相同，其评估和管理就一直没什么好办法。
决策人的一锤定音给企业带来了真金白银的增收、药到病除的止损，或者呆若木鸡的遗憾、一泻千里的亏损。
那些更新关键信息的参与者，他们的信息更新速度和细致程度无法量化，可能是运营决策人的坚实后盾，也可能是麻木的工具人。
运营决策人员没有太好的管理和评价标准，都要靠资金喂出来、时间验证出来；更新参与人是多部门多名普通员工，可以靠流程拴住一点点速率，但也很难检查信息效力。
选错了运营决策人，那是企业Owner自己认栽；不靠谱的更新参与人就（和他的直属领导投诉）早点淘汰。
4.2 PM难以胜任运营工作
产品线总经理（PGM）的权限适中，经常担当运营决策人的角色；但PGM手下的产品经理（PM）并不能胜任专业运营工作。
PM的工作目标和核心技能是关注客户需求和研发进度，PM关注增收和减负纯粹是尊重顶头上司PGM。
资源运营的“现场数据”并不是技能而是信息同步，一个天才PM也不知道某段IP被污染、某个海关在休假。
精英型PM优先是投入创新产品设计和核心客户攻坚，而不是关注这类精耕细作五百年的工作。
数据中台、运营、采购等部门和PGM没有隶属关系，从跨部门责任划分的角度看，如果他们给PGM的数据出错了，嘿嘿嘿……
4.3 运营决策不依靠深度学习
深度学习最擅长的就是做模糊决策，但是资源运营这事和人工智能八字不合：
原始样本数据量非常小；
要执行的动作非常多样化；
AI做出的决策无法人工复核。
4.4 运营数据依赖产品经理协助
运营工作靠技术和产品能解决数据准确性和精密度的问题。
产品的功能改进，肯定能留存下更多细节营收数据。比如FaaS类产品未来都会发展成按次计费。
产品精细化运营，有可能留下更详细的成本数据。比如不同用户能忍受的CPU超卖比例和带宽错峰可行性。
云产品线的产研发人员，他们和数据中台的产研沟通时，更加强势和有效。非IT技术背景的专职运营，很容易和数据中台的产研沟通出问题。
结束语 模糊的魅力
我这份总结只有提纲和简略证据，但没有详细证据和明确操作方法。
首先这些内容牵扯面太广太多，展开能写一本书，字数越多阅读者脑子越乱。
不同公司、不同老板、不同时段对运营工作的需求完全不同，运营团队也不同名字。
每个公司的运营样例都是机密数据，在不涉密不泄密的前提下，我已经尽力点到为止了。
即使是成熟的CDN业务，每当客户流量变化、运营商政策变化，其盈亏平衡都要调整两个月。
云计算没有固定的运营方法论，管理层不可能对运营工作垂拱而治简单评估，也不可能一套方法适用多年。
这正是云平台运营工作的含金量，有用途也有难度的工作才值得去做。