这个标题不算太夸张，云计算和很多IT岗位都有缘，但是和运维（SRE）岗位的缘分最深。
“深读实证”系列文章都会结合一些外部事件，点明分析《云计算行业进阶指南》书中的内容。本次分享介绍了下列内容：
我以运维/SRE的身份而自豪，感谢诸位运维大佬把我当做自己人。
运维是最主要的云用户，天然了解云产品，也最多接触云厂商。
最值钱的云产品都是资源型云产品，而运维是最了解IT资源的工程师。
运维交付的就是业务承载能力，这种心态更适合做企业技术服务。
云计算重度改变了甲方的运维工作，比如DevOPS和多云冗余。
结束语和本次活动宣传海报。
注意：本文的运维指的精通IT技术的业务运维，我个人更习惯将此岗位叫做“运维”，而SRE-elite的朋友们更习惯叫SRE。那些只负责盯监控、打网线、上架设备的“运维”，我尊重每一个劳动者，但这些工作和本文没有任何关系。
1. 老运维从云端回家看看
我经常说自己天生适合做云，其中一多半原因是我做运维（SRE）时的技术水平还不错。在云产品规划设计、云用户促销推广、云资源调度分配等等工作，都需要用到我做运维积累的知识。
很高兴接到SRE-elite的邀请，我将参加6月22日小米科技园举办的“SRE精英联盟北京站”活动，能够现场学习《SRE实践白皮书》，也期待能认识一些参会的新朋友。这本《SRE实践白皮书》非常硬核，全部都是体系化的SRE工作标准。
SRE-elite确实是个“精英联盟”，包含了成哥、书记、宇聪、黄亮、亚丹、石鹏等运维高手。这几位高手都愿意和我商业互吹，主要是因为我至今能够胜任SRE技术专家工作，我和他们是“自己人”，只是我的志向是做云计算而已。
本次开会时会介绍，《SRE实践白皮书》更新到了到1.0.3版。这本白皮书介绍都是最硬核的运维工作，深入介绍了“可靠性架构设计”“研发保障”“入网控制”“发布管理”“故障应急”等等工作流程。
我上篇文章刚解释，我写的“进阶指南”不会包含实操过程，然后我看了看SRE白皮书……嚯……这本白皮书比我的书还要硬核，全部介绍的是“这一流程有哪些步骤，这些步骤要做到什么程度”。
这本白皮书是一座无言的丰碑，它不会讨好读者，但读者想做好SRE工作，就要一板一眼的执行操作步骤。这些操作步骤的关键词已经足够清晰，很方便读者自行搜集实操资料；但如果读者投机取巧想想省几个步骤，那就是自己在给自己挖坑……。
为保障阅读体验，活动相关海报放在文末了。
2. 运维是云计算的主要用户
我的书《云计算行业进阶指南》中出现了50多次“运维”这个词。因为运维是最主要的云用户，天然了解云产品，和云厂商的接触也对最多。
我对云计算的定义，云产品的操作员必须是计算机工程师。这个工程师群体包括运维、架构、后台开发。抛开全能个人开发者来看，运维的人数远比其他工程师要多得多。
运维天然了解云产品，这是因为IaaS云产品的设计目标就是“模拟基础设施”，PaaS产品的工作就是“模拟中后台服务”。研发不会跟运维抢基础设施的工作，中后台服务从搭建到维护到监控到备份也是SRE运维的工作范畴。
在甲方技术团队中，运维和云厂商打交道的经验最多，既要面对云销售和云售前套消息，还要找云售后投诉，还要面对云产研来访谈和忽悠，就算是PaaS云也要做好监控、多云冗余和对账。因为总和云厂商打交道，在日常交流中，运维工程师也最容易发现“云厂商养了一堆草包，彼可取而代”的事实。
下图选自本书第13页，在第一章就有连续多段内容都提到了“运维”。
3. 运维天生更理解资源
要做好运维工作，必须深入了解软硬件IT资源的质量特性和承载能力，而云厂商能带来大额营收的云产品只能是资源型云产品。这种天然理解资源的技能底蕴，让运维工程师转岗到云厂商时，有充分的择业自由空间。
只有资源型云产品才能为云厂商贡献大额营收，无论是制作还是使用资源型云产品，都要掌握理解IT资源的特性、用量和状态。《SRE实践白皮书》中高频率用到了“资源”“群集”“平台”“用量”“成本”“账单”等等IT资源相关的技术用语，我也在向SRE-elite的大佬们提意见，在后续版本的白皮书中，很可能会加入专门的资源定义章节。
当站在甲方客户、云销售、云售前、云售后这些产品外部视角工作时，我们需要评估云产品的资源质量，优先使用优质或廉价资源，并监控用量余量等信息，这些信息也会广泛的应用到云厂商商务PK和用户保障工作中。
当站在产研内部视角看问题时，“掌握理解IT资源”这个技能的价值就更大了。首先云产品线也需要资深SRE工程师；产品经理需要掌握资源相关技能，才能完成产品设计、销售、实施的一系列工作；我比较看重的资源运营岗位，那更是直接写明了优先招聘运维工程师。
请注意，运维跳槽到云厂商有广泛的选择空间，并不代表我推荐各位运维去所有岗位都实验一遍，云职场没那么宽容，每个人的职场选择都要具体问题具体分析，比如我专门写过《工程师为什么不转销售》。
下图选自书稿的16.1章节，276页：
4. 运维思维更适合做技术服务
我写过多篇强调云厂商要做好技术服务的文章，本文是谈运维的，所以换个角度解释技术服务。
云厂商给客户吹嘘“我能提供无限服务”时，根本不是服务思维，而是产品经理对未知领域随手画大饼的习惯；云厂商实际执行过程中萎缩成“我只提供产品和资源”，这是标准的研发心态，只保障自己100%能保障的工作。相比之下，运维向公司承诺的是“保证平稳承载业务”，这种兜底心态和积极的工作范围更适合做好企业服务。
我的书中多次强调，“云产品、云资源、云服务”，这三个名词在很多语境下可以无缝互换。但是，很多云从业者只尊重云产品，不了解云资源，对云服务那是肆意随性的画大饼但永不兑现，就是因为他们对服务没有任何概念。但运维出身的朋友，对服务承诺都有天生的敬畏之心。
企业客户最烦云厂商的并不是虚假承诺，而是云厂商认栽摆烂。比如，云厂商出现意外后，产研销售很容易做好赔偿、丢单甚至失业的准备，然后蹲在路边等事态进展。这几个角色的工作习惯就是“只有认栽，没有兜底”，而运维的工作心态是“认栽没意义，必须本人兜底”。
除了工作心态之外，运维跳槽到云厂商做服务，还有个天然的优势；云厂商的服务对象也是运维，老熟人不仅仅是产品技术的沟通效率高，对很多职场潜台词也是心意相通的。我在书中第290页对这种默契做了明确的介绍，下图虽然提到都是“技术服务专家”，但该岗位最佳的人力来源就是甲方运维。
5. 云计算改变甲方运维的工作
要跳槽到云厂毕竟是个长期规划，云计算也深刻影响着运维的日常工作。大家读我的书能理解很多云产品的资源秉性，也知道如何更顺畅的和云厂商打交道。云产品是各位运维开展工作必须依赖的资源，基于这些资源，我们才能做好DevOPS、多云冗余等务实技术。
我在云主机的产品介绍中就明确解释了，只有软件定义的虚拟硬件，外加弹性极大的公共资源池，运维工程师才能够施展开DevOPS技术。如果是固定锁死的资源池、缓慢变更的真实硬件，SRE能做的资源调度工作会极大受限。
各位SRE不要盲目信任单云可靠性，多云冗余是必须做的技术选型；《SRE实践白皮书》制订过程中也有对“多云”“混合云”的重度考量。云厂商出不出故障，不影响运维要为业务稳定性兜底，跨云弹性部署，是运维圈最流行的技术。
云厂商面向客户确实有很多不实宣传，但客户也要适度理解一下，供应商老实坦白的话，在你们眼里就变成了土鳖和摆烂。本书中对很多云产品、云岗位进行了祛魅揭露，让大家能减少被不实宣传误导的概率，这也是一个重要的帮助。
6. 结束语和活动海报
我年轻时做运维工程师，做过很多稀奇古怪、毫无价值的“瞎折腾工作”。从事云计算行业以后，那些无聊苦涩的经历，居然都兑现成了工作能力和认知深度。因此我很感谢云计算行业，这让我的折腾变得更充实有意义；当然，我也忘不了运维，因为这些工作折腾都是在强化兜底思维和服务意识，也让我比大部分云从业者更了解资源和技术。
下图是SRE精英联盟北京站的活动海报，时间下周六，地点小米科技园，我也会去现场。我不会尬聊推销图书，但也不会摆谱装高冷，所以我选择在会议茶歇时段，循环播放一段无声视频，有兴趣的朋友可以看看，会议间歇也可以当面聊聊这本书。
 FrameBuffer 应用编程)
