---- 前言 ---- 五年前我偶然了解了云计算这个概念，然后我就把IT技术文章都删了，发了一篇关于云计算文章，文章中原文是“云计算会在短则五年、长则十年的时间里将大部分运维的饭碗抢走。”。 五年过去了，我从业务运维一步步转行去做云计算，无论是售前、产品、设计、实施、售后都做了一遍，我对行业的判断对了，无论是收入、见识还是能力都在快速增长。 前段时间我写过七篇云计算现状介绍，现在我写这篇未来展望，乐观的看这个充满希望的行业。 一、时代大幕刚刚拉开 历史和现状总是藕断丝连，如果用《三国》形容云计算行业，那前奏刚刚结束，大戏还没开场，正是黄巾军将要被平定，天下诸侯自立为王的阶段，一董二袁崭露头角，曹操刘备还没登场。 首先看谁是黄巾军？那些OpenStack创业厂商。他们衣衫褴褛阵型混乱，但对旧秩序有无穷尽的破坏力，经过这批厂商的教育开拓，每个客户都认可了云计算，且客户将期望值控制在合理范围内。然后这批厂商该招安的都招安了，该消失的也在消失。 然后看天下诸侯，纵然现在有一二三名，但从第一名到第十名都能业绩翻倍，说明行业还远未饱和竞争。

传统IT时代业务持续性到99.999%、数据可靠性再加两个9已经够用了，这个标准同样适用于云计算时代。

中国的云计算是个快速发展的行业，业内里的玩家很拼，也围观了很多临渊慕鱼的人。我在曾经和很多人聊过如何设计、采购、投资或者监管云计算，现在将我的观点通过网文分享给大家。 以前写了几篇万字长文但可读效果不好，听朋友建议这次拆成七个独立的短文了。 这是第一篇——成本篇，如果你要一个云计算平台，那你要付出哪些成本。 本文目标客户群，云计算公司的老板和雇员，云计算行业投资人，重大采购客户也要看看评估成本。 要做好云计算必须的成本主要分六大类，听我讲完这六大类成本，我再和大家聊聊谁有成本优势，谁能如何发力。 1、硬件成本 硬件成本主要就是采购服务器、交换机及其零部件的成本，富豪大厂还会采购硬件负载均衡和硬件存储，科研大厂还会自研整柜服务器。这里小厂商只能用媒体价买服务器，大厂商一次采购上万台服务器，能把供应商的利润压榨到低于余额宝收益。 我一直说Intel是云计算行业最大赢家，每个云计算大会Intel都会慷慨赞助，因为只要你的技术选型不太生僻都要采购Intel的硬件。

前言 上篇文章《中国云计算现状——成本篇》（特大号首发改名为《做好云计算要花多少钱》）讲的是成本问题，即什么企业有可能能做云计算。本文是第二篇产品篇，目标客户是云计算产品经理和云计算标准用户。我从一个老用户的角度谈谈每种云计算产品该如何使用，哪些产品改进是刚需放心吐槽，哪些产品有内因就是改不了。本文主要说用云产品的问题，买云产品的问题在采购篇单聊。 正文 现在是2017年，云计算服务是物理硬件的优质替代方案，客户很认可云计算极低的采购和交付成本优势。这时候我们要少被企宣PPT洗脑，追求华而不实的远景，这些PR文章的受众是风险投资、客户决策层和创业者。我们应该摸清楚云方案和硬件方案比有什么特点和局限性，客户明白特点才能使用得心应手，客户明白局限性才会早作备用方案，产品经理心里不慌才会关注核心功能。 一、IaaS产品 IaaS平台的本质是，产品以做硬件资源的虚拟化为本，业务上承接物理硬件替代需求，其优势是最快速度最低成本交付，客户为预占的物理资源付费。IaaS产品是最经典的云计算服务，核心组件是云主机，如虚拟网络、云硬盘和安全组都是为支撑云主机业务而服务的。

政府和大型国企不仅能采购云计算，早晚也会走向发展云计算的路。 本文不谈任何技术细节和商业情怀，而是从政企的角度说明什么是云计算。 本文包含如下内容。 从大时代背景来看什么是云计算，云计算为什么会兴起。 云计算如何带动地方经济，这是个不需要物流就可以服务全球的行业。 做云计算要满足哪些条件，如何才能筑巢引凤。 挑选合格的云计算合作厂商，每类厂商有哪些特点。 云计算不是万能药，它无法解决哪些问题。 什么是云计算 近20年来，互联网引爆了全球的信息技术革命，我国借助这次技术革命的大好机会，已经追上乃至领跑此次技术革命。 互联网技术深刻的改变着我们的生活，其行业生态也在逐步分化扩大，这一现状客观促进了云计算技术的发展。 上世纪80年代，计算机仅应用于科研等少数行业，全国计算机从业人员不超过万人，从业人员大都有很深的学术背景。 上世纪90年代，门户、论坛、邮件系统开始影响部分群众的生活，国内从业人员约为十万人，可以分为软件和硬件两类工程师。 进入2000年，无纸化办公、游戏、社交、电商改变了大众的生活的方式，国内从业人员已经远超百万，按技术分类有数十种工程师。

笔者以前就规划过和用过这些系统，写本文的目的也是为了催促各个云平台开放此类功能。 第六进阶补充系统 除了上述核心业务系统外，云管平台还可以有一些补充子系统，让用户像在用像一个标准云平台。 面向客户的API系统。高级用户会有调用API管理资源的需求，云管平台需要逐步开放面向客户的API或SDK。 客户智能化操作系统。云管平台可以更贴近用户业务，主动替客户完成一些运维操作。简单的如滚动快照云主机，复杂的如根据LB负载动态扩容缩编Web服务器。云管平台离客户的业务足够近，又对云端资源有深入了解，完全可以以此为切入点，从资源贩售发展为技术输出。 日志系统。无论是计费日志还是操作日志都可以逐步记录和开放出来。 通知和工单系统。此系统不用过多描述。 附录：我们亲眼看到CDN服务从各自为战变成了智能融合，随着计算业务的成熟发展，希望计算服务也能如行云流水般想迁就迁。 配图是早期火车和马车赛跑但输给马车的照片，但是后来火车赢了。

点击”确定”后，系统开始进行算力卡计费。算力卡计费规则：毎分钟进行计费，如不满1分钟则不计费(例如使用了1分钟50秒, 则只计算1分钟的算力卡消耗)，毎6分钟进行一次汇总，并在”算力卡明细”页面中显示消耗算力卡总数。 进入系统，可以看到项目环境中已经包含V100资源 当您关闭浏览器时，资源不会立刻回收，而是会继续运行2小时，2小时之后将会被中止。如果希望关闭浏览器后立即回收资源，请在”我的项目”列表中直接中止(中止并重置环境的过程需要1-2分钟)。手动退出成功或2小时自动中止后即停止计费。 9. 您可以回到”算力卡明细”页面查看剩余算力卡余额和本次算力卡消耗的明细。 怎么样，心动吗? 心动不如赶快行动，立即点击申请吧！ 如在使用中有遭遇什么问题，可以联系AI Studio官方邮件组：aistudio@baidu.com

当前云计算技术的势头很好，但因为技术和市场等原因还需要慢慢发展，而且云计算做的是“锦上添花”的事情，企业用不用云计算对自身业务功能影响不大。我们运维人员从做事的可靠性、有全局意识，凭借这些特性仍然能活的很好。运维这个岗位可能会消失，但做过运维的人还是有很多路可以走的。 大家都知道黑云压城也该未雨绸缪了，如果你已经是个运维老鸟或者很快就投身运维工作，我建议大家往这几个方向上动动脑子： 1、企业采用公有云方案后，仍然需要一个懂行的人解决公有云平台的监控、评估、采购、报修这类问题。但这个职位应该一个公司公司只需要一个人，且再等上十年云计算彻底标准化后还会再次消失。当然了，我相信能胜任这个岗位的人，在云计算已经规范到不需要专人维护的时候，他们也会有能力找到更合适的岗位。 2、进行云计算服务器维护；几大云服务供应商自己也要维护服务器，那些大中型企业肯定会自己做私有云，在这个云计算平台里也是需要运维人员进行从低端监控到高端架构的一系列维护工作，但自动化运维技术会让运维人员的数量大大减少，可能每个公司都只有一两个小团队了。

过去大家卖IDC、CDN、服务器和软硬件积累的个人商誉，是可以应用到云计算领域的。而云服务的高科技光环褪去、产品同质化以后，企业的核心竞争力仍然是有商誉的销售-售前-售后团队，这类人才永远是稀缺资源。 附录 请各位多琢磨评估本厂的云服务到底哪些组件是靠谱的，不要让信赖你的客户受伤又受骗。如要学习云计算相关知识，可以多关注我往期云计算文章，比如说 云计算最重要的工作是配合销售和服务客户：云客户需求引导管理--实战型IT太极拳 中国云计算现状系列汇总： 做云计算要花哪些钱，请看第一篇成本篇，原创链接。 云计算产品各有什么特色该如何分类，请看第二篇产品篇，原创链接 客户的采购人员如何看云计算，厂商如何锁定采购人员需求，请看第三篇采购篇，原创连接。 如果我们？ 时无英雄使竖子成名，但这也是机遇， 看云厂商花式作死的九种方法 。

引言拨云见日 云计算离不开一个大趋势，全世界的计算、存储和分发需求急剧增大。云计算厂商降低了企业上马IT项目的门槛，但是没帮客户降低IT技术决策的风险。 客户上云的重要动力是缺少IT执行层人才，客户同样也缺乏IT决策层专家。 我们见多了各种各样愚蠢圈标的招标书，各种重复浪费IT投资，各种含糊不清的交付规范，各种虎头蛇尾的全局规划，似乎看不到闹剧的尽头，而所有旧乱局背后都有新机遇： 5年前我在甲方做IT，我发现招不到会扎网线和加载log4j的员工；纵然当时云产品从设计/性能到稳定性都像一坨屎，但我还是看好并投身云计算行业。 甲方无力进行合理的设计、提出合理的需求、进行合理的验收、推进合理的规划，甲方又为这些掏钱买单，并承担更重了业务损失，虽然云咨询还是探索阶段，但我也看好云咨询行业。 我做云计算最遗憾的是这个公众号写晚了，我以为我懂的常识别人也懂，不值得写不值得嚷嚷；现在规划和推广云咨询，我不会默不作声了，必须最早最快的吼出来。 1.云咨询是IT决策专家 当客户缺少IT决策专家，或自有专家不便发声，这就需要引入外部云咨询。

3.主体贩售资源分析 云供应商不可能靠软件和服务做到亿元销售额，只有以资源为载体，客户才会给到亿元大单。这个观点跟前文的“资源可以用做计收载体，但不能做为上云目的分析”并不是冲突而是印证。 以软件和服务做亿元营收载体，采购决策人会承担巨大决议风险；但平庸的贩售资源又会陷入价格战和关系战之中，云厂商追求市值和利润都不能讲这些老套路了。 我们先列出来哪些资源是单体贩售能过亿的，云厂商把这些资源和其他的软件服务资源做打包混淆集中交付，云厂商就不是卖资源而是卖梦想了。 3.1 IaaS计算池 IaaS计算池，交付给客户的是CPU+内存+本地盘+本地网+IDC电力，产品形式可以是虚拟机、裸金属、容器，或者预装了数据库-大数据-队列等服务的模板化云主机，决定资源池成本的是硬件和电力的价格，以及内部浪费程度。销售铁三角对硬件资源池的包装，完成资源成本分析、交付服务展示和付款周期核算；在硬件资源池交付时，云厂商的优势长处是大规模交付和成本控制，至于短处么——家家有本难念的经。

但套用过去管理虚拟机的经验，管理IaaS和PaaS服务时要有资源池隔离，不同部门和项目的主机资源要分别计费和管理。 一个很常见的场景是，人事部的OA系统申请了15万云主机费用，生产车间的ERP和销售部的CRM系统不设上限，外部客户A项目预算是50万，B项目是200万，等等等等。 如果没有资源池的概念，就是一个账户管所有资源的“大通铺”模式，客户要把脚趾头都掰完了才能算清各项目的消费金额；万一云平台调整了资源价格，较真的客户又要从头重算一次。 这个“大通铺”最尴尬的不是计费繁琐，而是一个账户下所有资源毫无权限隔离，客户或者只有一个人去登录云平台，或者将不同业务注册完全孤立的账户。互联网公司无法理解传统企业和自然人有关的流程是多沉重，客户选一个云平台管理员完成所有操作，客户的项目越多管理员员就越晕越累。将不同业务区分为不同账户也解决不了问题，因为客户和云平台都要将这批账户统一管理，但实际扣费进度总会超出意外，项目欠费停机或者追加预算，挨骂受累的都是平台管理员。

附录参考 我以前写的文章，解决方案架构师职位定义； 我以前写的中国云计算系列文章文章，不同客户的不同部门的不同诉求，在03采购篇和06客户篇中有类似的观点展示。

10年前的电脑培训班，很可能是培训PhotoShop，20年前的电脑培训班，主课程可能是五笔打字；但现在谁会把平面设计师当做电脑工程师，而打字已经是不能牟利的基础能力。设计师和打字员的IT技能部分和业务工程师一样，都是把业务逻辑转述为计算机可以完成的工作。现在IT劳动力不足引发的哄抬人价，但业务逻辑转述工作没有稀缺性门槛。我知道0基础0经验的泡面工程师，干活没名校名企的绣花工程师精细，但云厂商和技术大牛在做的各种容错和简化机制，就是要让三流泡面工程师做出可以凑合的交付物。很多公司只有二流销售、运营和后勤一样活得好好的，为什么IT工程师必须找一流熟练工？《太吾绘卷》的创始人说程序员入职没多久就跑路了，然后他只能自学编程把游戏写出来了；一堆程序员还开开心心说游戏代码写的烂要重构，创业公司的游戏程序员要担心失业好吧？这个游戏制作人也可以算三年工作经验的“程序员”，这算不算群体泛化扩张。时代发展冲击的是行业，但对个人更多是机遇，没人规定你是世袭业务工程师。本文不是让大家抱团取暖抵制云计算和技术革新，而是想着拥抱变化早做打算。

云计算历经多年发展，从最初的概念模型，到被大众熟知，再到现在全行业拥抱上云，取得了巨大的进步。云的主要客户已从最初的中小初创公司逐步渗透到各行各业的大型企业。可以说，企业上云已是企业发展的必由之路。部分数据敏感的企业结合自身数据的安全性、所有权和控制权等综合因素考虑，会选择搭建自己的私有云或者混合云环境。 但是在上述环境中，用户的机器都需要自行管理，这就必然给云运维人员带来很多意想不到的麻烦。 其实我们面临的问题从来就没有什么大的变化，唯一不同的只是机器规模越来越大，人心越来越复杂。 Q如何在1台机器上部署基础设施？A 一切都源于那个亘古不变的道理：扔一个文件到机器上，然后跑一个命令。 Q如何在10台机器上部署基础设施？A 写个for循环搞定。 Q如何在10000台机器上部署基础设施？A 这个也好办！定制操作系统镜像CUSTOM.iso装机自动化安装！ then…… Q如何快速升级所有机器上的基础设施？ Q服务因异常挂掉，能自动重启保活吗？ Q公司做活动，预计流量突增，能扩容吗？ Q公司活动结束，为节约成本，能缩容吗？ Q新开发的基础设施服务有问题，能立马回滚吗？

Apollo中的控制算法由一个或多个控制器组成，可以轻松更改或替换为不同的算法。 每个控制器将一个或多个控制命令输出到CANbus。 Apollo中的默认控制算法包含横向控制器（LatController）和纵向控制器（LonController）。 它们分别负责横向和纵向的车辆控制。 新的控制算法不必遵循默认模式，例如，一个横向控制器+一个纵向控制器。 它可以是单个控制器，也可以是任意数量控制器的组合。 添加新的控制算法的步骤： 创建一个控制器 在文件control_config中添加新控制器的配置信息 注册新控制器 为了更好的理解，下面对每个步骤进行详细的阐述: 一、创建一个控制器 所有控制器都必须继承基类Controller，它定义了一组接口。

事实上是使用者自己设计维护可以弹性伸缩、自动运维、容灾冗余的程序，无论是用物理机、虚拟机还是容器（进程），本来能弹性的服务还是能弹性，没容灾的服务还是在赌命。 合格的架构和运维都瞧不上这些废话，因为十年前我们用裸机就能实现这些功能了。但世上没有那么多合格的架构师，云计算要解决的就是缺人的问题。最早的云主机也是类似夸张无赖的宣传，我第一眼看云主机也觉得是个噱头，这些遗毒至今还在误导客户。本文是为说清容器的能力特性，我们该如何用好容器编排系统。 容器的基础特性 容器和虚拟机都属于IaaS云的范畴，按申请资源量付费，不关注客户业务逻辑和访问频率。容器只是隔离出一个进程，而虚拟机是模拟了一整套操作系统，这是双方的本质区别。 进程的创建就是申请内存、端口等系统资源，但应用的初始化仍然需要时间，所以容器启动到服务可用仍然需要几秒甚至更久。容器的快速部署优势在于CI/CD环境里，快速部署不只是说程序启动的快慢，而是决策的快、操作的简单。 容器是一个进程，本地文件系统是容器最大短板。文件和设备的所与者都是“用户/OS/虚拟机ID”这类长效标识，不可能是“进程ID/容器ID”这类临时状态。

这次他联合了 Google 的工程师终于把算法变成现实。在这次攻击中，他们使用了 CPU 来计算碰撞块的第一个 block，使用 GPU 来计算碰撞块的第二个 block。碰撞块的第一个 block 的第一次碰撞消耗了 3583 核-年的计算量，第二次碰撞消耗了 2987 核-年的计算量。在第二阶段，除了 CPU 外，还是用了 GPU 集群进行运算。GPU 集群的计算量相当于 114 块 K20 计算一年， 或是 95 块 K40 计算一年，或是 71 块 K80 一年的计算量。如果使用商业的云 GPU 服 务，租用 71 块 K80 计算一年，就将耗费 56 万美元。 对于第二个问题，该攻击做了非常巧妙的构造。我们借用热心网友的回答 [17] 来做分析。首先，SHAttered 攻击是一个共同前缀攻击，所以构成的 pdf 一定是有一个共同 的 pdf 头部，参见图 3。 图 3 SHAttered 攻击的 PDF 结构 两个 PDF 的头部共同部分包括:PDF 文件头和 image 对象的一部分。在 image 对象 中，包括了属性表引用、content 结构，和属性。