从四个具体案例谈谈技术和成本

因为最近我们内部也在实施成本优化和管控的事情，再加上之前写文章对一些技术和成本效率问题上的一些总结，发现这个事情还有点意思，是值得反复思考和玩味的一个问题，所以简单分享下感受。

先说几个我经历过的，挺有意思的案例：

第一个，数据库 FIO 卡的使用，我 15 年初到蘑菇街，当时蘑菇街还没有专职 DBA，是其他几位运维工程师兼职维护，X86 架构+MySql 水平集群，因为之前维护的运营商的系统，都是小机+Oracle RAC 集群+高端 SSD 存储，同时配备非常专业的厂家售后服务团队，所以很难想象这么几个非专业 DBA 是怎么玩转这么复杂的电商体系下的数据库的。

当时，最让我好奇的问题是，之前我们经常会遇到一条烂 SQL 就可以搞挂整个 Oracle 集群的事情，SQL 调优是一项非常专业的技能，有时得请专业的原厂服务或经验丰富的 DBA 搞定，一般的人是根本玩不转的，即使是这样，也是整天被这种烂 SQL 搞的很头疼。但是，到了蘑菇街，我发现貌似这类的问题好像基本没有。

后来，我仔细去了解才知道，当时蘑菇街使用了 Fusion-io 卡，超高速的闪存设备，性能非常好，当然，也非常的贵，比当时的 SSD 要贵好几倍。所以一般的 SQL 语句只要不是太烂，一般都不会导致严重性能问题。当然，优化余地还是很大，只是这个问题在那个阶段变得不是那么阻塞了而已，其实这个债，早晚是要还的。

那个时候，我的第一反应是，靠，这么特么土豪，运营商都不舍得买这么好的存储卡，蘑菇街一买就是 10 几块，我特么加入这么土豪的公司，这个选择没有错。

但是后来，我跟团队同事聊下来，发现这里面的逻辑是这样的，一开我们用的也是主机上的 SATA 盘，后来换到 SAS，业务量不大，一切都好说，但是业务量上来了，同样也是各种 DB 性能问题。

但是，当时我们实在是招不到，其实是吸引不到，好的 MySql 工程师（优秀的 DBA 人才一直很紧缺），再加上又是开源产品，也没有所谓的原厂服务，出了问题就得自己上，谁也依赖不了。

所以，越往后越发现，团队投入的人力上的精力和成本就越来越高，但是还没有效果，所以索性尝试了 FIO，没想到问题就极大的缓解了，这样人力上就得到极大的解放，也可以去做其他的事情。

看上去貌似花了很多成本，但是带来的收益确是不可言语的，这个算是典型的硬件升级带来的成本优化，在某些阶段，直接减少了甚至取代了专业人力投入。

作为对比，这里还有个有意思的小插曲，有一次，我们跟网易的 DBA 团队交流，我们仅有的 3 个 DBA 过去，没想到对方一屋子 2、30 个 DBA 在等着，他们也很诧异，你们怎么就这么几个人，问的最频繁的一个问题就是，平时你们不做 SQL 和存储性能优化吗？当他们听到我们使用了 FIO 卡之后，一群人也是羡慕的了不得，土豪土豪。

后来一聊，才知道，网易内部一直在推行严格的成本控制，数据库使用的都是自己的内部的云主机+SATA/SAS 的存储，不允许随便使用高端存储，所以 SQL 的优化，以及存储性能优化，就需要投入非常大的人力。当然，这样的极端情况下，网易 DBA 团队的技术能力也是被磨练的非常突出，沟通下来，技术能力比我们还是要高出很多。

讲到这里，问个问题，网易如果全部都采用了 FIO，是不是也可以节省很多人力呢？他们这么抠门不让使用高性能存储，投入了这么的专家级的人力，成本是不是消耗更高呢？

这个问题，大家还是自己琢磨下。

第二个，微服务架构的实行，算是上面的延续，我 15 年到蘑菇街的时候，整个技术栈还是以 PHP 为主，单体巨石工程+分层架构，后来因为耦合性强导致开发效率下降，所以转向了非常流行的服务化架构，技术栈转到了 JAVA 上，关于这一点我前面的文章分享过很多次，这里就不赘述了。

还是谈谈先进技术的引入，服务化，说的洋气一点就是我们现在无时无刻不再讲的微服务，实行这样的架构之后，在业务响应上，需求分解上，以及组织架构和职责的明确上，确实要比之前清晰很多，对业务的支持和响应速度也大幅提升。

但是，我想说的是，这些仍然是有代价的，微服务引入之后，应用多了，管理复杂了，你会发现，微服务引入后，如果没有周边配套的效率和稳定性保障体系，是压根玩不转的，为此我们专门成立了平台技术部，下设中间件、稳定性、运维以及虚拟化等团队，招聘了大量的级别较高的专业人才，就是为了专门支撑这样的体系架构。

所以，单纯看基础平台人力投入成本，增加了很多，这还没有算业务研发上人力的增加。

另外一点，从资源成本上，我大致对比过，因为应用数量的增加，以及容量评估手段不够精确，在资源上我们的浪费和闲置还是非常严重的，直到当前。

作个对比，我之前在运营商支持的一个阅读类互联网项目，13 年左右，每日就有 6、7 亿的 PV、2000w+的交易订购笔数，业务体量比蘑菇街要大一些，一直采用的是分层架构，资源规模上跟我 15 年到蘑菇街时是差不多的，但是后来我们实行了服务化之后，资源体量至少是之前的 2-3 倍，从每个应用使用的资源来看，看上去貌似都是合理的，最小化冗余，业务量再小，也得双机互备，双机房就得 4 台。但是整体来看，资源浪费和闲置就是非常严重。

这里其实会暗含着整体架构设计上的问题，业务架构师水平不一样，业务领域划分和应用拆分体现出来的架构合理性，以及对资源成本消耗的合理性都是不一样的。

接第一个问题，因为业务体量和数据量的高速增长，分布式数据的架构被广泛采用，大量的分库分表，数据库实例的数量大幅增加，如果还是都以 FIO 卡为标配，成本直线上升。

所以，到了这个阶段，从成本角度，我们引入先进技术架构后：

• 成本是降低了，还是升高了？

• 如果是升高了，为什么还要这样做？

• 成本上升，我们应该怎么控制？

这个阶段，成本所面对的问题，又不一样了，该怎么办？

第三个，业务上云，我之前在极客时间专栏文章中提到过的，我们为什么要选择上云，单单是因为资源的成本问题吗？其实不是，我们测算过，上云之后，单纯从显性的资源成本角度来看，云是不会比自建或自运维的 IDC 机房模式便宜的，反而会更贵。

但是为什么还会这样做，具体原因我就不赘述了，大家可以直接看我极客时间里的文章，里面有非常综合性的考虑。

第四个，技术开源，以业务为导向的公司，玩内部技术的开源是否有必要？是否划算？这个也是个很有意思的事情，后面专门写篇文章分享下我的观点。

稍作总结，技术和成本这个东西，是紧密，且复杂相关的，真的不是一两句话能够讲的清楚的，是个需要全局思考的东西。同时，特别重要的一点，一旦把角度切换到成本角度，你就会发现:

1、成本有显性的，也有隐性的，且，往往我们看不到的隐性成本是更高的，所以成本控制和优化，有时候是取决于我们对隐性成本的发掘和控制，有时候可能我们都意识不到。

2、技术不是唯一的手段，说的直白的一点，有时候，在某些情况下，技术都不见得好使，而且越从技术角度出发，反而成本可能会更高，搞的更复杂，这个我暂且不表，后面再专门写。

3、技术手段不是唯一的，但是到了一定体量和复杂度之后，是最重要，且是决定性的手段，后面专门写。

4、不同阶段，所面临的成本问题不一样，要区别对待，BAT 管理成本的方式，不一定适合中小公司，一是学不来，二是技术水平也达不到。

最后先收住，给一些我的建议：

1、技术人员，特别是架构师，要有点全局成本意识，我现在发现很多的架构师都在讲技术上怎么能够更牛逼，更深入，但是实际中，很多架构师能够考虑到效率维度，但是真的很少有架构师能做到从成本角度来考虑。

另外，我这里强调是的全局成本意识，不是局部的，大家可以自己思考下。

当然，如果站到成本角度开始思考问题了，说明站的维度已经比较高了，所以，我前面一篇文章在讲，技术也好，管理也好，不是二选一的关系，多考虑怎么为团队创造价值，其实成本就是很重要的一块，这个绝对是技术 VP、CTO、还有 CEO 做梦都想搞定的事情，站得层面越高，考虑的越全局，个人价值就越高，格局就越不一样。其实架构师到了一定程度，拼的就是不是技术深浅和技术高低了。

大家可以看看 BAT 这样的大厂，每年的技术大奖，有绝大部分都是被成本优化类的项目给拿走了。

2、贴着业务走，重要的是把技术利用好，而不是把技术研究好，这一点尤其是对于业务导向的公司，比如蘑菇街这样的公司，比如我们提到的云、数据库上的 FIO，还有当前技术门槛较高，对数据积累要求很高的 AI 和机器学习等产品，这些我认为要充分利用起硬件发展和大厂多年积累和打磨出来的技术红利，而不是投入大量的专业人才、时间和宝贵的精力去从头研究，去重复造轮子。

说的现实一点，即使自己做，不见得比别人做的好，做到一定程度，基本就停滞不前了，这不是技术和能力问题，毕竟 BAT 的业务体量和场景不是每家公司都能具备的。这种情况下不如选择合作，我们也可以把精力聚焦到跟业务相关的研发上。

3、其实还有，我后面再补吧

啰啰嗦嗦，一不小心又写长了，其实还没写透，后面再写几篇文章分享下吧。

本文转载自成哥的世界公众号。

原文链接：https://mp.weixin.qq.com/s/hQ8C-oGnBpo7BziAuX-Bng