运维百家讲坛，通过采访和约稿的方式，请运维领域老炮输出深刻洞见，共同碰撞，以期形成一些先进的共识，推动行业更好得前进。
这一期我们邀请到的是王明松，王老板针对云原生应用实践，提出“王四条”，在业内广受认可。从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，我也会不定期的更新云原生王四条
简要版的内容是：
- 用对象存储静态文件
- 用role不能用ak sk
- 尽量用托管服务
- 数据不要存在服务器上
这四条的出发点其实基本上是围绕着应用的无状态和数据的安全来做，同时会兼顾成本，性能和可靠性，适应范围其实也不局限于云计算，传统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，什么平台，都是运维工作的一小部分，我们应该把自己从这些纠结里解放出来，给自己解绑，也给产研团队解绑，做好我们管理和监管视角的工作。
