没技术，但有技术含量的云指南

最新推荐文章于 2024-09-03 12:15:00 发布

云算计

最新推荐文章于 2024-09-03 12:15:00 发布

阅读量844

点赞数 23

本文链接：https://blog.csdn.net/weixin_48558260/article/details/139585631

版权

我的新书《云计算行业进阶指南》已经上架，尚不了解本书的朋友，可以查看我写的书籍介绍和小黑羊写的书籍介绍。

本文是“卖书三部曲”的终章，相比第一章谈云计算是否流行的强硬表态，相比第二章对云厂商盈利模式的复杂推演，本章内容就是轻松唠嗑做科普复盘。

工程师朋友说，这本书读起来很爽，但没有技术实操内容，是一本行业和产品书。工程师读者都是讲道理、懂逻辑的，我就跟大家慢悠悠地解释一下，这本书的技术含量一直很充足。

1. 不讲实操才是尊重读者

我书籍的序言部分，就很正式的介绍，本书没有任何实操的内容，我的读者不需要阅读这些的内容。这种刻意设计，是我既了解云产品的工作范围，也知道读者最需要了解的是什么内容。

本书的定位是“进阶指南”，并不是“入门科普”。本书序言和宣发稿，已经预设读者拥有熟练操作云产品的能力。如果云计算就是简单的掌握本职工作这点事，我不会写这本书，而是开零基础手把手培训班。
所有和业务逻辑并无强绑定关系的中后台IT工作，都属于云产品的工作范围。这么广泛的工作范围，给云计算行业巨大的发展空间，但是，也没有哪本书能装下这么多实操内容。
云产品云资源之间存在着广泛的依赖和联动，每个从业者都需要了解其他产品、技术和岗位的工作方法。但人的精力是有限的，为了让读者快速掌握产品能力和依存关系，我只能压缩掉这些实操内容。

2. 他者眼中，这就是技术

对于技术需求部门（管理者、项管、销售、售前、市场、培训）来说，我这书写的就是“硬核技术”。希望本文能让各位低头实操的工程师，有一些产品思维和全局思维。

需求部门对“技术”的定义非常有趣：一个工作和IT有点关联，也不需要背业绩KPI，又看不懂实操细节，这就是技术工作。比如产品设计和资源运营从业者既不提交代码也不登录服务器，思考决策过程需要依赖IT技术实力，在需求部门来看，这就是硬核技术工作。
需求部门不关心技术实操过程，只关心技术产出结果和客观能力限制。需求部门主要了解“能帮客户做什么”、“能给公司卖钱吗”、“撤销该产品会出什么篓子”，谁能解释这些问题谁就是技术大牛，如果谁能解释清楚“产品的可行性”“需求和环境的变化”，这就是技术天才。
本书将对技术的描写限制在产品的能力范围和岗位的沟通界面，是避免需求部门做出一知半解的瞎指挥。很多技术人员会抱怨需求方不懂技术瞎提需求，但是请换位思考一下，如果需求部门对技术执行有一知半解的了解，他们会从瞎提需求升级成“机枪阵地向左移动五米”的瞎指挥工作。

3. “做云”的技术太广阔

搭建云服务云平台需要用到非常多的技术，但这些技术“又多又难又不通用”，且早已有纸质书出版。我的书只讲解“技术可行性”，才是看透了云行业“人力替代、分工迁移”的本质。

云计算要覆盖所有和业务逻辑无关的中后台IT工作，比如软件定义和虚拟化、监控调度和管理、操作系统、数据库、消息队列和中间件，这些技术都非常很重要，只能相互协作无法互相替代。我没有写这么多种技术书的能力，而且这些技术都有现成的书籍，只是书名上没挂“云计算”而已。
曾经，IT技术人员很愿意学习各种高并发、高稳定性、弹性伸缩的后台架构技术，并且在本公司就能找到用武之地。在云计算的分工隔离之下，这些高精尖技术会成为云厂商的自留地，现在再写这类技术书籍，感兴趣的读者不会超过万人，能指导实操的工程师不会超过百人。
作者写书就是为了扩散个人影响力。我现在的书籍定位足以覆盖全体云计算从业者，还能兼顾上百万甲方工程师。靠着讲解每款产品的“工作目的”和“技术可行性”，每个岗位能够输出哪些“有效信息”，我每天都能接待几名充满激情和谢意的读者。

4. “用云”的技术无变化

我很重视“用云”相关的技术，这些技术投入可以减少客户流失、调度优质流量、提供原厂收费支持。但是，我的书中仍然没有做“用云”技术的详细介绍，因为这些技术同样是旧有IT技术的模拟平移，没有什么炫酷热门的变化。

IaaS云产品的目标是模拟客户自建IDC环境，用户对IaaS云产品的合格评价是“和自建服务一样易用且稳定”，IaaS云产品的“弹性伸缩”是个已经被广泛实践的产品优势。IaaS云产品的使用方法一直就有难度有价值，但十年前这些技术就已经有明确的标准了，学得慢的人更容易每天都惊愕有新技术。
PaaS云产品的典型特点，就是只向用户开放API和SDK，这让PaaS云产品的“用云”技术非常简化。普通开发者不需要掌握什么技术，高级开发者才需要做客户端容错和客户端调度。至于PaaS产品常见的性能参数PK，比如CDN比延迟比卡顿，其实是没其他可比项了，只能鸡蛋里挑骨头。
在云产品刚问世时，客户意识不到多云冗余的重要性，各云产品也有明显差异，此时需要做用云技术科普。但现在大客户普遍完成了多云部署，每次云厂商出故障都会自动迁移；为了满足快速迁移的需求，大客户会要求云厂商提供和友商无差异的云产品，所以这些技术很通用，不值得刻意研究了。
“云原生”既不是技术也不是产品，而是一套“免费的用法建议”，本书对云原生未做任何分析，已经是我充分克制和表达善意了。我不反对云厂商用任何噱头做品牌宣传，但是我不相信“因为公鸡打鸣了，太阳才肯升起”。无论有没有云原生宣传，云产品线和客户都会努力做好用云实践，各种软件的云化部署是自然发展的必然结果。

5. 跳槽到云厂商的技术准备

我欢迎甲方技术工程师跳槽来云厂商，云厂商需要优秀的工程师来研发和运维各种中后台IT服务，也需要这些工程师为客户提供原厂技术支持。

虽然我经常批评云厂商的职场冗员低效，但是云厂商依旧严重缺乏有真才实学的工程师。我一直在呼吁云厂商给客户做好原厂技术支持，如果云厂商开展了这些技术服务工作，云厂商的技术人才缺口还能继续翻倍。
对于资深的研发、测试、架构师来说，在云厂商做后台技术工作和在大企业工作并无本质区别。无论有没有云计算，大家都已经拥有明确的技术成长路径，而云平台是最佳的技术实践场所。这也是侧面证明，云计算不是技术创新，而是“新瓶装旧酒”的产品创新。
我对运维（含DevOPS和SRE）的工作了解较深，所以单独给运维一个建议。首先，甲方运维很适合转岗做云产品经理或资源运营经理（本书第16章），也可以给老同事做原厂技术支持（本书第17章）。如果大家想跳槽来云厂商继续做运维，在甲方和云厂商之间的工作切换有点差异，毕竟每个新场景要维护的软件、要达成的业务目的都有明确的差异。
本段不是广告，而是学习建议。有志于去云厂商做运维的工程师，我推荐学习ZStack的官方文档。在私有云软件方案中，ZStack的功能完备、管理逻辑完善，关键是文档写得非常简单清晰，而且搭建测试环境足够轻便。在此处学到的知识，可以尽量拉近和业务之间的距离。