资深运维王明松： 自我革命的“王四条”是怎样练成的

作者的话：我们观察到：国内运维行业，不同的公司做法差异巨大，从业人员水平参差不齐，缺少普遍性行业认知，难以形成合力（这也会让 To B 的产品异常难做，不利于行业整体发展），甚至在部分公司，运维人员处在技术鄙视链最底层，我们希望为行业带来一些新的思路和发展推动力。

这需要很多行业老炮一起，输出观点，共同碰撞，才有可能形成一些先进的共识，形成行业前进的思想旗帜。所以，我们准备策划《运维百家讲坛》这么一档栏目，诚邀 100 个运维总监（或更高）级别的老炮，通过采访或约稿的方式输出他们的观点，给行业一些借鉴。

这一期我们邀请到的是王明松，王老板针对云原生应用实践，提出“王四条”，在业内广受认可。从 19 年开始，王老板所在公司的所有 IDC 业务就全部搬到了云上，体量还不小，SRE 团队却很小，有点 Netflix 的味道。这一讲，我们一起了解一下资深云上运维到底是怎么玩的。这里是接地气、有高度的《运维百家讲坛》第 7 期，开讲！

问题预览

• 初识王老板，是因为微信群里的一次讨论，王老板提出了四条云原生应用实践，认为只要做到了这四条，应用基本就是云原生的了，群友们深表认同，并且命名为“王四条”，可否请王老板给 SRETalk 的读者再分享一下“王四条”中的精粹？

• “王四条”中罗列了一些最佳实践，需要研发一起配合，在公司内部落地的时候，不知道是否会遇到阻碍？您又是如何摆平的呢？

• 最近有些文章讲述他们综合衡量 ROI 觉得下云更划算，比如 RoR 之父的文章，比如运维百家讲坛上一期途游游戏邹总，看起来您更倾向于深度用云，能否给大家分享一下您的思考？

• 最近有个文章《运维的未来是平台工程》，您认可这个观点么？在平台工程方面您的团队承担了一个什么角色和边界？您是怎么规划所谓的平台工程的呢（尤其是在多云环境下）？

• 王老板这样的工作模式下，感觉只需要非常资深的人，新鲜血液太嫩，没法承担研发教练的角色，但是没有新鲜血液，也没法长期维计，能否分享一下您是如何建设您的梯队的？

• 我们知道，明松你一直是“运维自我革命”的鼓吹手，这是“反人性”的，能谈谈这背后的思考吗？

嘉宾介绍

问：开始之前，先请王老板做个自我介绍吧。聊聊工作履历，尤其是用云的经历，给大家输入一些背景信息。

大概 2005 年前后，在学校里搞过 BBS 的运维，算是入门。毕业后入职现在已经略微没落的某互联网大厂（编者注：是指百度），跨行从 P1 级的运维开始做。2010 年跑路去了一家移动互联网创业公司，当时基本上系统网络布线机房 IT 啥都做，服务器的采购周期就算小公司也会略长，所以当时就开始考虑用云了。

2011 年开始，曾经用过一段时间曙光云，基于 Vmware 的，体验就很差，从我个人的角度来看可用性和经济性都没有，唯一就是可能上机器比 IDC 快吧。然后网络也是怪怪的，造成了很多困扰。同时期也用了一段时间盛大云，这个体验比中科曙光强一些，但是其实也是 vps 的水准吧。感觉 vpc 那层都没有做。没敢放上去太重要的资源，后来屡次拉跨就没再用了（可能是我用的方式不对加上也不好监控）。

2013 年开始用 Ucloud，这个也主要是用虚拟机，别的用的不多。但是 vpc 产品当时应该有了，会把一些重要业务往上放了。2014 年因为开始做出海，所以开始用 AWS。2019 年把所有 IDC 业务全部迁移到了云上。

采访问题

问：初识王老板，是因为微信群里的一次讨论，王老板提出了四条云原生应用实践，认为只要做到了这四条，应用基本就是云原生的了，群友们深表认同，并且命名为“王四条”，可否请王老板给 SRETalk 的读者再分享一下“王四条”中的精粹？

云原生王四条详细版的内容我放到瑞典马工的 repo（ https://github.com/lipingtababa/cloud-native-best-practices ）里了 ，欢迎大家提 issue，我也会不定期的更新云原生王四条

简要版的内容是：

1. 用对象存储静态文件；

2. 用 role 不能用 ak sk；

3. 尽量用托管服务；

4. 数据不要存在服务器上。

这四条的出发点其实基本上是围绕着应用的无状态和数据的安全来做，同时会兼顾成本，性能和可靠性，适应范围其实也不局限于云计算，传统 IDC 也可以参考来实施。

编者注：这个简版内容看起来不多，实际内有乾坤，建议大家读一下，云原生王四条这个链接如果点击不了，就移步到上面的 repo，从中找 云原生王四条.md 即可。

问：“王四条”中罗列了一些最佳实践，需要研发一起配合，在公司内部落地的时候，不知道是否会遇到阻碍？您又是如何摆平的呢？

我几乎没有遇到任何阻碍，但是这是因为我们有自己的情况。

一方面是我们当时除了上云别无选择，而且成本管控是硬指标，没有其他可以绥靖的路线可以选。

我们是团队分拆出来的一个新公司，所以只给了一年的时间做过渡，管理层给的目标就是把现有几千台机器上跑着的还挺赚钱的业务无缝的迁移出来。因为我们当时只做海外，所以压根没考虑非云的方案，但是管理层依然要求云上成本相较于之前用 IDC 要更省。

如果直接把原来的架构直接搬到云上去，那么管理层给的成本目标是肯定无法达成的（这个 pigsty 的冯老板已经写了很多类似的文章来佐证传统 IDC 对云的成本优势了），所以当时的选择只有一条：就是对现有的架构进行改造，使之适应云，从而使之迁移后即可达到成本，性能，稳定性的目标。

另外一方面，让研发在选型和成本优化上充分参与进来，大家形成共识。

我大概提前花一年时间开始对公有云做选型，并且专门参加培训来学习如何更好的使用云，也逐步形成了自己的方法论。迁移前也带领研发的主干成员去参加相关的培训，通过培训后他们也能理解我的很多做法是对的，而且实际迁移中，AWS 也提供了比较专业的方案设计。所以“王四条”的内容落地是比较容易的，比如：

1. 数据存 EBS 非常贵，那么存 S3 就是非常经济的选择，通过培训和各种方案对比，研发非常明确这个情况，所以会有比较大的意愿去做程序的修改。

2. Role 这个是安全要求，因为 AWS 的 sdk 支持的非常好，刚上手的时候使用 Role 还是 ak sk 没有任何难度区别，从一开始就把控好，对于研发而言没问题。

3. 托管服务这个，其实研发并不关心是运维去做还是用现有的服务。这个只要我们运维放得下执念就可以。

4. 数据不要存在服务器上。其实我们是经历了一次比较大的磨合。

我们这次迁移是从一个有完备的平台支持的 IDC 环境迁移到 AWS，在 AWS 的 partner 的帮助下，新架构按照 AWS 的最佳实践设计，并且满足了之前的使用习惯和要求。但是因为做了重构，使用上还是有差异的。因为使用了 ASG，所以在缩容或者故障迁移时，服务器是直接干掉的，上面如果要存持久化数据的话就没了，所以这次之后，研发基本能接受在线业务数据不存在服务器上了。而且因为这个设计，我们对于服务器存储的要求就可以能多小就多小，超过 100G 的都需要我审批。节省了大量的 EBS 成本。后续，研发在做 K8S 的部署的时候，对于这个的理解就更加深刻了，毕竟容器里的数据都是会丢的。

问：最近有些文章讲述他们综合衡量 ROI 觉得下云更划算，比如 RoR 之父的文章，比如运维百家讲坛上一期途游游戏邹总，看起来您更倾向于深度用云，能否给大家分享一下您的思考？

我其实一直在鼓吹“最佳实践”，但是我也跟大家交流过“最佳实践是投资人或者管理层的帝王之术”，使用最佳实践很可能就是要砸自己和很多人的饭碗才能达到最优，如果以不砸饭碗的前提下实现最优，选择就会更多样。

下云还是上云，得看利益出发点，也得看管理层支持的力度，还得看历史包袱。如果我在邹总或者 DHH 的位子上，也未必会坚持我现在的观点。我能坚持在云上：

一方面是管理层的认可，管理层都吃过资产闲置的亏，我做了很久的闲置 IDC 资源的优化的工作，所以加上出海自建机房也不是特别容易，上云基本上就是管理层支持的唯一方案。

另外一方面也是如上面所说机缘巧合，我们架构改造的很彻底，而且改造成本是管理层支持的，可以充分利用云的优势。

最后一点，我们的业务形态到现在还没有一个长期稳定的高负载而且无状态的业务。这种业务比较适合传统 IDC。

我相信邹总或者 DHH 现在去改造他们现有系统的架构，付出的成本太高了，即使说可以因此削减运维部门的人力成本，可能很难得到支持，因为这还涉及到其他部门的利益。但是如果是新公司新项目，我相信没有比云更合适的场景了，选一家合适的云厂商，采用云原生的架构来实现业务，使整个业务从性能和成本上都是弹性的。

很多朋友吐槽云杀猪，锁定之类的。但是从投资人或者管理层的角度看，一切要素都是为了达成业务的盈利，人/云/IDC 等 都是实现业务的要素，投资人想实现业务，不仅要为这些要素支付成本，还要能及时获取到符合需求的要素（这个更重要）。云这个要素的获取再简单不过了，相对而言非常标准的产品质量和价格，点几下就可以付款使用了，可以按需可以包周期，但是随时都可以停止使用。 但是人呢？人的获取很难，质量也很难明确，也不是标准化的，会有价格的波动（加薪），不能随便裁，离岗也不会帮你顶替一个绝对一摸一样的。人可以是很有创造力的，但是在标准化和机械枯燥的事情方面，人永远不是机器的对手，更不是 SaaS 服务的。

对于邹总的情况，如果他们业务团队不愿意改造程序架构的话，他现在的选择就是最佳实践了：稳定高负载的业务选用成本有优势的 IDC，并且租赁机器而不是购买；弹性业务的上云。

对于 37signals 的 Basecamp，从产品的定价模型设定上就决定了他们上云有点麻烦。现在大多数 SaaS 服务都是按用量或者使用人数付费的，但是 Basecamp 主要卖无限制套餐，一个月只有 199 刀。这个定价模型就导致他们无法充分利用云的弹性来盈利，而只能走低价资源的超售。不改变这个定价模式，无论怎么优化架构恐怕也不太适合云。

问：最近有个文章《运维的未来是平台工程》，您认可这个观点么？在平台工程方面您的团队承担了一个什么角色和边界？您是怎么规划所谓的平台工程的呢（尤其是在多云环境下）？

是阮一峰写的还是 Charity Majors 写的？不过这两篇我之前没看过，刚简要的看了一下。我不完全认可这个，而且我个人也不会去尝试做内部的平台工程。

首先说一下不认可的地方吧：就是那篇文章对于概念有一些误解。

首先，DevOps 不是一个岗位，我曾经试图理解了很久，最终的感觉就是这是一种开发模式。但是这个开发模式的核心是研发，所有的要素都要围绕高效的研发迭代服务。 那篇文章前面认为 DevOps 是一个岗位，后面又认为这个岗位是开发业务的，我觉得都是不妥当的理解。

其次，运维对未来的探索是很丰富的。转型不是一个新话题，大家很早就明白运维这个行业是夕阳行业了，过去这十多年，有很多运维都在尝试转型，找下一步的出路，有试图搞 CI/CD 的，有尝试做监控研发的，有尝试做自动化运维平台研发的，有尝试搞新领域（比如 K8s，大数据，AI，云计算之类的），也有尝试转向其他子项的（比如 DBA，网络安全）。

可以看出来这些转型很多都是服务于 DevOps 这个开发模式的。

平台工程或许是一种实现模式，但是以运维群体的产品力和研发水平，自己搞平台工程恐怕只能自娱自乐，甚至连稳定性都无法保证，徒增背锅可能。但是如果引入更加专业的产研团队去做，一方面是不务正业跟主营业务收入无关很难得到支持，另外一方面只是自用的平台，拉这么多人做一个没有收入的产品并不经济，更何况这种做法对于现有的运维而言没有参与感，算不上转型。

所以，我认为正确的做法是自己用成熟的平台和工具（开源/付费自建，使用 SaaS 均可），可以基于这些平台做一些定制和二开，但是不要造轮子。

最后，我对那篇文章中平台的理解也不一样。

一方面，平台本身就可以是 SaaS 的形式去提供，不需要二开整合，现在主要是国内 SaaS 环境不佳，以及软件服务也不重视相互集成兼容，而更喜欢做大而全。我们把目光放到海外就会发现海外有很多细分领域的 SaaS 或者软件，做的很好而且可以跟其他软件集成，生态很好所以集成很容易配置，没有太多二开的工作量。

另外一方面，平台的用户应该是研发，研发应该可以直接使用，而不需要运维去转达，审批。

所以未来的确需要用平台，是专业的产研团队做的平台，而不是自己做的玩具；是产研团队来直接使用的平台，而不是运维拦在中间做传话筒。

所以对于平台工程，我选择积极的使用成熟的软件或者 SaaS 服务，并且尽可能提供给产研团队直接使用。

运维只基于成本和安全做一些必要的卡口，通过策略、权限、审计来控制，保证产研团队可以正确的使用。

问：王老板这样的工作模式下，感觉只需要非常资深的人，新鲜血液太嫩，没法承担研发教练的角色，但是没有新鲜血液，也没法长期维计，能否分享一下您是如何建设您的梯队的？

这个问题很好，因为我的确也没解决。这不是这种工作模式的问题。

对于资深人才的需求，很多公司，很多工种都是有的，一样面临我现在的问题。什么工种才不需要资深人才呢？我认为是工作内容已经非常标准化，公司要求不高，随便一个人都能根据需求就能明确指示做好。甚至机器就能做好。

邹总有个说法是传统运维类似保洁，工作内容重要但是价值不高。我比较认可这个说法，这就是我们现在运维面临的困境。那么保洁团队他们自研清洁工具还是去采购？

因为采用了大量成熟的产品和外部服务，我如同保洁使用各种自动半自动的清扫工具一样，可以比较稳定的输出清扫任务。但是不需要担心某个保洁能力欠缺导致拖地不干净，不够敬业导致简单扫一遍就交差。固然要操作好这些工具，保洁需要学习的比传统工具要多一点难一点，但是总体的 SOP 要比原来要少，因为成熟的工具屏蔽了细节。

所以，我们不要在低价值的工作内容上浪费时间，这类工作用专业的软件或者 SaaS 来完成，它们有规模效应，功能好还有 SLA。我们应该把工作重心放在业务，管理层，投资人更关心的领域。

问：我们知道，王老板一直是“运维自我革命”的鼓吹手，这是“反人性”的，能谈谈这背后的思考吗？

我们现在看到的事实就是运维并不是一个蓬勃发展的行业，绝大多数企业并不会有一个庞大的运维部来支撑企业的系统运转，甚至可能只需要一个人，这个人还会兼任 IT、网管、安全之类的工作。我们没有上升空间了，运维总监极少，运维经理基本上就是极限了，以我现在管理的人数，叫我运维主管都可以。

现在业界也是这样的状态，大量培训班速成的运维，够用而且价廉。中高端运维很少，运维不像是网工或者 DBA，我们技术栈非常杂，没有权威的认证标注我们的能力，这一方面不利于我们规划职业路线，也不利于形成一个良性的人才市场。所以市场对于我们运维的定位其实就是打杂了，“不写业务代码的那个技术”可能是我们最准确的定位。

根据 DevOps 的理念，我们应该是加速业务的交付，做好服务，而不是添乱给产研使绊子。 但是运维的意义和工作不仅仅在于 DevOps，这也是我跟很多人观点不一样的地方。

一方面，运维是公司数字资产的“看门狗”，从这个角度上看，运维代表管理层和投资人的利益，对公司的数字资产进行妥善的保管，保证其能正确的使用，满足各种监管要求，参与各种内部审计。是管理层对于产研团队的制衡。这其实就是最初运维的意义。

另外一方面，国家赏饭吃。监管要求日益严格，无论是网络安全，数据安全还是个人信息保护，都需要有专人负责相关工作。对于小规模的企业而言，这些工作必然是运维来兼任，特别是数据安全，直接掌管数字资产的运维肯定要参与的。这是新时代对运维的要求。

所以如果想明白这些，你就会发现什么 DevOps，什么平台，都是运维工作的一小部分，我们应该把自己从这些纠结里解放出来，给自己解绑，也给产研团队解绑，做好我们管理和监管视角的工作。