选择"平凡技术":如何用最稳妥的方式构建可靠系统
在快速迭代的互联网行业,技术选型永远是一个充满争议的话题。每个工程师都希望使用最先进的工具,每个团队都渴望通过技术创新获得竞争优势。然而,硅谷前Etsy首席架构师Dan McKinley在2015年发表的一篇影响深远的文章《选择平凡技术》(Choose Boring Technology)却提出了截然不同的观点:与其追求新奇刺激的技术,不如选择那些经过时间验证、运维成熟的"平凡"技术。这篇文章一经发表,便在技术社区引发了广泛讨论。时至今日,其核心理念依然被无数企业奉为圭臬。那么,什么是"平凡技术"?为什么它比"最佳工具"更适合大多数公司?本文将深入解析这一理念的内涵,并结合实践案例,探讨如何在复杂多变的技术环境中做出明智的选择。
**从Kellan的启示说起:平凡技术的力量**Dan McKinley在文章开头提到了他职业生涯中最重要的一次经历 - - 在Etsy工作期间,他的上司Kellan Elliott-McCrea对他的技术决策产生了深远影响。Kellan的技术理念简单却极其有效:选择那些成熟稳定、运维负担小的技术栈,而不是追求新奇的解决方案。这种理念帮助Etsy在早期阶段避免了许多常见的技术陷阱,并为公司的长期发展奠定了坚实基础。McKinley在文中坦言,正是Kellan的这种"平凡技术"理念,让他能够专注于构建真正有价值的产品,而不是在技术选型上浪费精力。这种思维方式不仅让他个人受益匪浅,也为整个团队带来了显著的效率提升。从这个角度来看,"平凡技术"并非保守或落后的代名词,而是一种对资源和时间的理性分配。
**创新令牌理论:为什么我们需要限制技术冒险**为了更好地解释"平凡技术"的价值,McKinley提出了一个生动的比喻 - - "创新令牌"(Innovation Tokens)。在他看来,每个公司在特定时期内拥有的创新资源是有限的,这些资源可以用来尝试新技术、新架构或新方法。然而,这种资源并非无限,一旦用完,公司就必须回到基础的、经过验证的技术栈上。例如,选择Node.js作为后端框架可能消耗一个创新令牌,因为团队需要学习新的编程范式、调试工具和生态系统。同样,采用MongoDB这样的NoSQL数据库也可能消耗一个令牌,因为团队需要重新设计数据模型、优化查询性能,并处理与关系型数据库不同的运维挑战。而如果选择自建数据库这样的极端方案,则可能消耗多个令牌,甚至导致项目失败。
这种理论的核心在于提醒我们:技术创新并非越多越好。相反,明智的选择是将有限的创新资源集中在真正能够为公司带来竞争优势的领域,而不是在每个技术细节上都追求"最佳"解决方案。对于大多数公司而言,业务本身的复杂性已经足够高,没有必要在技术栈上雪上加霜。**平凡与优秀的辩证关系:如何界定"好技术"**许多人误解"平凡技术"等同于"落后技术"或"低效技术"。然而,McKinley在文中明确指出,平凡技术并不意味着技术本身的质量低下,而是指其成熟度和可预测性。换句话说,一项技术是否"平凡",取决于它是否经过了时间的考验,其故障模式是否为人熟知,以及运维团队是否能够轻松掌握。
以数据库为例,MySQL和PostgreSQL都是典型的"平凡技术"。它们经过数十年的发展,故障模式、性能瓶颈和优化方法早已被业界广泛理解。相比之下,一些新兴的分布式数据库虽然功能强大,但其运维复杂性和未知故障模式可能为团队带来巨大风险。在这种情况下,选择"平凡"的MySQL或PostgreSQL不仅能降低运维成本,还能提高系统的稳定性。同样,编程语言中的PHP、Python,缓存系统中的Memcached,代理服务器中的Squid,以及任务调度中的Cron,都是"平凡技术"的典范。它们或许不如某些新兴语言或框架那样炫目,但它们的可靠性和易用性使其成为构建可扩展系统的理想选择。
**未知的未知vs已知的未知:技术风险的本质**在技术选型过程中,我们常常面临两种类型的风险:已知的未知(Known Unknowns)和未知的未知(Unknown Unknowns)。已知的未知指的是我们清楚自己"不知道什么",例如"不知道当数据库负载达到100%时会发生什么"。而未知的未知则更加危险,因为我们甚至不知道自己"不知道什么",例如"不知道垃圾回收机制会导致服务暂停"。对于成熟的技术,其已知的未知相对较少,因为社区已经积累了大量的实践经验。然而,对于新兴技术,未知的未知往往数不胜数。例如,某些新的分布式系统在面对网络分区或节点故障时可能表现出意想不到的行为,而团队可能需要花费数月时间才能发现并解决这些问题。
McKinley在文中引用了前美国国防部长唐纳德·拉姆斯菲尔德的著名言论,以讽刺那些对未知风险视而不见的技术决策者。在他看来,选择"平凡技术"正是为了最大限度地减少未知的未知,从而降低系统的整体风险。**全局优化vs局部优化:为什么"最佳工具"可能害了你**在技术选型中,我们经常听到"选择最适合的工具"的口号。然而,这种思维方式往往忽视了一个关键问题:技术选择并非孤立存在,而是会对整个系统、团队和组织产生深远影响。以Ruby和Python为例。如果团队已经在使用Ruby构建系统,那么突然引入Python可能会带来巨大的认知负担和运维复杂性。
尽管Python在某些场景下可能更适合,但从全局来看,这种选择可能得不偿失。类似地,如果团队已经熟悉MySQL,那么突然切换到Redis或其他缓存系统可能会导致开发效率下降、调试困难,甚至系统不稳定。McKinley在文中批评了那种"选择最佳工具"的片面思维。在他看来,工程师的真正职责是确保公司业务的长期成功,而不仅仅是追求某个特定问题的最优解。因此,技术选择应该基于全局优化的原则,即选择那些能够在最大程度上降低长期运维成本、提高系统稳定性的技术栈。**案例分析:Etsy的平凡技术实践**为了更好地理解"平凡技术"的价值,我们可以看看Etsy在早期阶段的实践。
在Etsy的发展初期,团队选择了PHP作为主要编程语言,MySQL作为数据库,Memcached作为缓存层,Gearman作为任务调度系统。这些技术虽然看似"平凡",但为Etsy的快速发展奠定了坚实基础。例如,Etsy的活动动态功能最初是基于Memcached构建的。尽管Memcached并非专门为这种场景设计,但它的简单性和高性能使其成为理想的选择。随着时间的推移,活动动态功能的用户量增长了20倍,但由于底层技术栈的稳定性,系统依然能够正常运行,无需进行大规模重构。相比之下,如果Etsy在早期选择了Redis或其他更"高级"的缓存系统,可能需要投入大量精力来处理运维问题,而这些精力原本可以用于改进核心业务功能。
因此,选择"平凡技术"不仅降低了运维成本,还为团队节省了宝贵的开发时间。**如何平衡新技术与平凡技术**诚然,完全拒绝新技术也是不现实的。McKinley在文中也强调,选择新技术有时是必要的,尤其是在现有技术无法满足业务需求的情况下。然而,引入新技术必须经过严格的评估和流程控制。首先,团队需要明确引入新技术的动机。例如,是因为现有技术无法解决某个具体问题,还是仅仅因为某些工程师对新技术感兴趣?如果是后者,那么这种动机显然不够充分。
McKinley在文中提到,他曾目睹过一个团队因为对图数据库感兴趣而决定尝试新技术,结果导致项目进度严重延误。其次,团队需要评估新技术的长期成本。这包括学习成本、运维成本、迁移成本以及与现有系统的集成成本。只有当新技术的预期收益远大于其成本时,才值得考虑引入。最后,团队需要建立明确的技术引入流程。例如,可以要求提出新技术建议的工程师首先回答以下问题:1. 现有技术栈是否真的无法解决当前问题?2. 新技术的引入将对团队的认知负担和运维复杂性产生什么影响?3. 是否有明确的迁移计划和时间表?通过这种方式,团队可以确保新技术的引入是经过深思熟虑的,而不是基于一时的冲动。
**平凡技术的长期价值:专注核心业务**McKinley在文中最后强调,选择"平凡技术"的终极价值在于让工程师能够专注于更重要的问题。在他看来,技术本身并不是目的,而是实现业务目标的手段。当团队不必为复杂的技术栈而分心时,他们才能将更多精力投入到产品创新、用户体验和业务增长上。以Etsy为例,正是因为选择了稳定可靠的技术栈,团队才能在早期阶段快速迭代,并最终成长为全球知名的电商平台。相反,那些过度追求技术创新的公司,往往在运维和调试上耗费大量时间,最终错过了最佳的发展时机。**结语:技术选型的艺术**选择"平凡技术"并非保守或懒惰的表现,而是一种对资源和时间的理性分配。
在快速变化的技术环境中,明智的选择往往是那些经过时间验证的、成熟稳定的技术栈。通过限制技术冒险,团队可以降低运维负担,提高系统稳定性,并最终为业务成功奠定坚实基础。当然,这并不意味着我们要拒绝所有新技术。相反,我们需要在创新与稳定之间找到平衡,在追求卓越与务实可行之间做出明智的选择。正如McKinley在文中所言:"技术为其本身而存在是伪科学。真正的自由来自于明智的技术选择。
" 。
