在 MongoDB 首席技术官 Mark Porter 看来，创新滞后并不是因为公司缺乏灵感或创造力，而是因为他们被迫将时间花费在维护传统框架上，导致数据相关工作举步维艰，这是大多数组织都存在的问题。那么，对于企业而言，在开源浪潮之下，如何突破数据的枷锁，构建自身独特的技术创新能力？在本文中，Mark Porter 给出了他的见解和 MongoDB 的创新之策。

受访嘉宾 | Mark Porter，MongoDB CTO

文 | 屠敏责编 | 梦依丹

出品 | 《新程序员》编辑部

创新，是我们时常提及的一个词语。企业、技术、产品倘若没有创新，宛如没有源泉的一潭死水，其结局就是干枯。不过，创新说着容易，行动却很艰难。在主流数据库 MongoDB 公司发布的《2022 MongoDB 数据与创新报告》中，有研究人员指出，每获得一次商业成功，需要尝试 3000 个原创想法。毋庸置疑，要想在百花齐放、百家争鸣的科技领域脱颖而出，对于不少技术团队而言，经常需要周旋于技术负债、不必要的复杂的数据结构，以及截然不同的框架、工具链和编程语言之间，导致创新面临多重挑战。

作为一款开源的 NoSQL 文档数据库， MongoDB 自 2009 年 2 月诞生以来，率先打破了关系型数据库一统天下的局面，随后几年间，它从一家名不见经传的创业公司，迅速成长为位居第一梯队的知名数据库厂商，且稳居在 DB-Engines 的 TOP 5 榜单中。开源是否是其创新的唯一驱动力？面对复杂的数据结构问题，MongoDB 成功的背后蕴藏着怎样的秘籍？

因此本期《新程序员：开源深度指南&新金融背后的科技力量》与 MongoDB 首席技术官 Mark Porter 围绕开源数据库的构建、开发者工作与创新的平衡，以及 MongoDB 的创新优势等方面进行了深入的探讨，也希望能够给对业务结果直接负责的 IT 决策者、想要提升效率的开发者带来借鉴与参考。

开源与云改变新时代下的数据库

《新程序员》：许多成功的数据库产品都是开源的，这是否意味着开源是创新软件成功的一条道路？

Mark Porter：开源对 MongoDB 的成功至关重要，也是全球软件行业的一个重要趋势。开源已成为建设社区和吸引开发者的默认标准。

在 MongoDB，我们的研发支出已接近 10 亿美元，其中半数以上资金用于免费开源产品研发。2021 年，MongoDB 免费开源产品下载量甚至超过了 MongoDB 成立以来前十年的下载量之和。

《新程序员》：许多企业都在构建云原生数据库或将数据库迁移上云，那么，在云数据库这一新的竞争领域内，企业如何利用云与开源的结合，在角逐中胜出？

Mark Porter：如今，开发者需要在各种不同类型系统中使用大量的技术、数据模型、应用程序编程接口(API)和编程语言，来满足用户对现代应用程序中事务、搜索和分析功能的需求。虽然云计算给科技行业带来了革命性的变化，提供了低廉的入门成本和无限的规模以及其他各种显而易见的优势，但大多数云迁移仅复制了传统数据中心的复杂性和弊端。

对于那些确实有必要迁移到云端的应用程序而言，“直接迁移上云(Lift and Shift) ”听起来是一个不错的选择。然而，这些迁移很大程度上只是将团队必须在本地完成的工作复制到了云端。以数据库为例，开发者仍需处理多种类型的数据系统，才能满足企业所需构建的事务、操作和分析需求。

“直接迁移上云”并不能解决团队结构或操作流程效率低下的问题。在面对各种请求时，开发和运营团队往往各自为营，束手无策。这导致应用程序交付时间很难得到改善。除非面临紧急事件，如数据中心租约即将到期，否则，“直接迁移上云”不仅耗资巨大，还会给公司带来诸多麻烦。即便完成了“直接迁移上云”这一步，既有的应用程序也并未发生改变，依然无法满足对敏捷性和速度的需求，区别只在于这些工作都被迁移到了云端。

但是，你将无法运用云原生的种种优势，如弹性；也不能像云厂商和 SaaS 公司那样，通过大量投入来提升韧性、安全性和合规性。“直接迁移上云”带来的成本和破坏对于企业的发展几乎没有任何助力—— 客户无法从中获得任何益处，企业也几乎没有获得任何优势。

显然，还有更好的方法，因为许多组织机构已经在上云方面取得成功。我们认为，企业在上云方法上要另辟蹊径。我们看到，一些最具创新性的企业对应用平台进行了战略投资，从根本上改善了四大关键领域：

提高开发者的工作效率；
优先考虑使用优质且可重复使用的架构；
轻松保护数据安全与隐私；
采用既兼顾灵活部署能力又侧重于多云模式的新方法。

《新程序员》：许多人在面对数据处理的挑战时，由于数据库的能力不足以解决问题而使用大数据技术，这是否意味着数据库领域需要一款足以比肩大数据能力的新型数据库？

Mark Porter：自 20 世纪 80 年代被提出以来，大数据概念已经发生了重大变化。结构化数据、非结构化数据和半结构化数据都属于大数据的范畴。如今多数大数据都是非结构化数据，包括视频、图片、网页和多媒体内容。每种类型的大数据都需要一套不同的大数据存储和处理工具。

大数据数据库可以快速摄取、准备和存储大量不同的数据。它们负责将结构化数据和半结构化数据转换为分析工具支持的格式。鉴于这些独特需求，MongoDB 等文档(或其他非关系型) 数据库成了存储大数据的理想选择。

《新程序员》：近两年中国涌现出了很多优秀的开源项目，也有不少走向海外。MongoDB 在全球范围内有许多用户，有什么样的经验可以分享？有人认为开源与商业毫无关系或互相矛盾，你怎么看？

Mark Porter：有这种想法的人还停留在过去的开源项目上。过去的开源项目旨在创造公平的竞争环境，为那些负担不起昂贵软件许可证的人提供支持和帮助。然而，随着开发人员的崛起和开源技术的战略性使用，市场上出现了许多令人印象深刻的开源软件公司，除了 MongoDB，还有 Conﬂuent、HashiCorp 和 DataBricks 等。

我们承认，每个公司利用、构建和扩展开源根文件的方式都不尽相同。对 MongoDB 而言，首先，我们会构建备受开发者青睐的优秀产品。在此过程中，我们始终奉行一个简单的理念，那就是打造一款有助于大幅简化数据处理流程的产品。

其次，我们会通过开源渠道使产品尽可能易于访问和使用，并创建尽可能多的优质培训文档和支持性文档。创建优质文档是一个关键因素。此外，我们还会提供免费的 MongoDB 大学课程，开发者可以轻松掌握 MongoDB。

截至目前，MongoDB 的下载量已经超过 2.65 亿次，在全球 100 多个国家和地区拥有数千名员工和 35000 多家客户。那么，MongoDB 是如何成功构建业务的？当然，成功不是单方面的因素造就的，也不是一蹴而就的。我们采取了多管齐下的市场战略，专注于为客户提供更大的价值。其中包括以下要素：

许可——这是一种传统的“开源销售”方式，指出售软件及额外支持服务的升级版许可。在这方面，我们有 MongoDB Enterprise Advanced 企业版，许多大型组织机构都喜欢在本地和云端运行此版本。
软件即服务——在这种模式下，MongoDB 将现有软件作为托管服务提供给客户，主要通过 MongoDB Atlas 来提供托管服务。在中国，开发者也可以通过阿里巴巴和腾讯获得 MongoDB 官方授权的托管服务。
服务——MongoDB 还为客户提供专业服务，满足他们对额外专业知识的需求，帮助他们更好地实施战略和转型，或从战术角度帮助他们在大型发布活动之前完善部署工作。
合作伙伴—— 当然，我们也与许多不同的合作伙伴建立了良好的关系，包括云厂商、大型集成软件厂商 (ISV) 、咨询公司和系统集成商(SI) 等。所有这些公司都专注于为开发者提供支持，推动业务向云端迁移，并优化自身的数据管理能力，而 MongoDB 可以为这些公司提供最佳的数据层解决方案。

“创新税”的根源在于数据

《新程序员》：据《2022 MongoDB 数据与创新报告》显示(见图1) ，55% 的受访者认为其组织机构的数据架构很复杂，60% 的受访者认为这种复杂性是制约创新的主要因素。你认为导致数据架构复杂的原因是什么？

图1 来源于《2022 MongoDB数据与创新报告》

Mark Porter：导致这种复杂性的因素有很多。其中最为明显的是许多组织机构仍在使用过时的传统技术，增加了开发的复杂性，但问题远不止于此。例如，大型企业可能拥有成百上千个应用程序，而每个应用程序都拥有各自的数据源和数据管道。

随着时间的推移，数据存储和管道成倍增加，组织机构的数据架构也变得愈发复杂，犹如一团乱麻。由于应用的技术各不相同，且每一种技术都有自己的框架、协议，甚至是语言，基础架构的扩展变得极其困难；同时每一种架构都是定制的，生产质量难以保证。团队不得不把本该用于深度技术研发的宝贵时间花在集成工作上，从而没有更多的时间构建企业需要且客户青睐的新应用程序和特性上—这就是所谓的创新成本。

在很多情况下，创新成本表现为没有能力去思考新技术的应用，因为底层架构太过复杂且难以维护，更不用说理解和转型。很显然，组织机构应当做好采用新方法的准备。

另一方面，通过观察一些走在创新前沿的企业，我发现这些企业并没有将创新工作外包给第三方。相反，这些组织机构的领导团队清楚构建软件的复杂性，并希望为开发团队提供有效的解决方案，帮助提升团队工作效率。

《新程序员》：应用需求千变万化，但系统设计没有唯一正解，如何设计一款简单、稳定且实用的系统架构？如何平衡数据复杂性与开发新产品/新功能之间的关系？

Mark Porter：在我的职业生涯中，曾有幸部署过许多不同类型的软件。从最早的光盘，到从网上为客户提供软件，再到迭代数据库实例和网络层。此外，我还负责过大型关键任务系统的在线升级工作。

我将这称之为“有幸”，是因为对于软件工程师而言，最开心的事情莫过于将软件交付到终端用户手中。然而，软件部署并非总是一帆风顺。虽然每项部署任务都有其特定的难点，但它们之间也有一个共同点，那就是焦虑。

我经常会谈到开发者在部署软件时产生的焦虑感，以及这种焦虑感对创新的负面影响。早期，我会使用“180法则”来帮助团队克服焦虑心理。也就是开发者应能够将软件部署到生产环境中。如果软件无法正常运行，应将软件快速剥离生产环境，并将系统恢复到之前的工作状态；如果开发者有信心检测和修复问题，那么对于软件部署的把握也会更大。

所有软件部署总体上都可以归纳为以下几个阶段：

部署—— 无论你是逐步把负载迁移到生产环境，或者一次性切换到生产环境，这个阶段需要将二进制文件或配置文件可靠地部署到生产环境中，然后让系统开始使用这些文件。
监控—— 系统在实时负载下的运行状况如何？我们是否会收到系统运行正常且性能良好的信号？监控阶段应更多地关注现有功能，而不是一味地追求实现新功能的“理想路径”。换句话说，首次发布是否会对系统造成损坏？
回滚—— 如果出现系统运行异常的迹象，则需立即进行回滚操作，将系统从生产环境恢复到之前的状态。从某种意义上说，回滚也是一种部署，因为开发者正在对实时系统进行另一项更改：将其返回到之前的状态。

“180法则”中的“180”有着双重含义。在这里，我们指的是回滚操作带来的“180度”大转弯。同时，它也意味着任何部署目标都是可以实现的。我相信，在任何环境中，我们都可以将软件部署到生产环境中，也可以当软件运行出现异常时，在3分钟(180秒) 内完成回滚操作。这意味着，在第一个 60 秒内，将二进制文件部署到生产环境中，并为客户指明路径；在第二个 60 秒内，观察事务负载是否存在问题；在最后的 60 秒内，根据需要回滚二进制或配置文件。当然，行业或产品不同，所需的时间可能更短。但底线是，故障软件在生产环境中停留的时间不能超过 3 分钟。

开发者应时刻遵循这三个步骤，并且这个过程通常需要手动完成。大家可能会想：“单纯依靠人力怎么可能在那么短的时间内完成软件的部署、监控和回滚？”

这正是“180法则”的神奇之处。要满足时间方面的要求，唯一的办法就是流程自动化。我们必须训练计算机，使其能够自动收集信息并制定决策，而不必等待人为制定决策。遗憾的是，对于许多公司来说，这意味着一种根本性的改变。但是，这种改变是必要的。如果不做出改变，企业就会陷入两难境地，一方面希望软件能够顺利部署，另一方面又担心失败。这也会导致开发者对软件部署产生抵触情绪。

MongoDB 的创新宝典

《新程序员》：许多企业中，员工大部分时间都花费在维护基础设施和解决业务问题上，且工作时间比较长，能真正用于创新的时间非常有限，很多创新也都是基于解决问题和需求的角度出发的。你怎么看待这种现象？其根本原因是什么？

Mark Porter：你对这个问题的认识一针见血。的确，创新滞后并不是因为公司缺乏灵感或创造力，而是因为他们被迫将时间花费在维护传统框架上，导致数据相关工作举步维艰，这是大多数组织机构都存在的问题。

尽管已经认识到创新和速度的重要性，也对此投入了持续关注，但不同规模的公司内部仍然存在团队不被人理解、管理不善、边缘化等问题。虽然不是有意为之，但组织却要为此付出高昂的代价。这些问题很快就会演变成为组织在创新数量和质量方面需要付出的成本。创新成本的一个表现就是组织未能正确认识开发者的工作内容和工作方式，或者无法为开发者提供高效的工作环境。在数字化经济时代，无法解决这一问题，将给组织带来极其严重的后果。如同要交税一样，创新成本也是真实存在的，它会严重打击员工士气，导致人员流失，还会从其他方面影响组织机构的利润。面临创新成本问题的组织机构将人力和资源都花费在维护工作上，在创新方面的投入则少之又少，导致创新速度异常缓慢。

还可以从DIRT的角度来考虑这个问题，DIRT (Data & Innovation Recurring Tax) 是指数据与创新经常性税(成本)。立足于根本，DIRT的根源在于数据(D)，因为企业往往试图使用传统数据库技术来支持现代应用程序，但现代应用程序却需要获取实时数据来创建丰富的用户体验，这无异于作茧自缚。在这种情况下，团队不得不将大部分时间用于支持复杂、棘手的架构，用于创新的时间则少之又少，因此影响了创新(I)。这种情况会经常性地(R) 出现，因为这不是一次性税收(T)。事实上，DIRT 适用于所有新项目，每个新项目都会添加新的组件、框架和协议，同时需要对它们进行管理和维护，也因此变得更加复杂。

对于技术领导者而言，DIRT 并不是一个新名词。他们早已意识到这种税收的存在，只是一直没有命名而已，如今我们的研究已经明确证实了这种税收的存在。

技术领导者还可以即刻了解自身的数据架构会在多大程度上导致或减轻这种税收。数据具有黏性、战略性、繁重性和复杂性等特点，但其仍然是现代数字化公司的核心。当前，应用程序变得越来越复杂，数据需求也愈加复杂；此外，数据量一直在不断增加，用户期望公司能够对数据蕴含的所有信号作出更快速、灵活的反应，这无疑将技术领导者们推到了十字路口—因为单一模型、僵化、低效且难以编程的关系型数据库等传统技术已经无法满足当前的需求。

《新程序员》：MongoDB 有哪些技术创新实践？如何平衡工作与创新？

Mark Porter：在成功构建和完善团队方面，我想分享以下三个理念：

康威定律—— 简单地说，组织风格及沟通方式取决于领导者。例如，如果两位领导者的关系不睦，在组织中各执己见，那么他们负责的两款产品也会相互格格不入。所以，确保组织、准则和领导者步调一致，才能呈现出受客户青睐的产品；
邓巴数字—— 邓巴数字定律指一个人每一次只能维持一定数量的社会关系。我认为，这一定律同样适用于团队构建和管理。在构建团队和进行互动交流时，确保团队人数在邓巴数字以内；不要盲目地构建一个千人大团队，你会发现团队成员之间缺乏信任或了解。特别是，如果你将开发者最私密的东西(例如，未受保护的地址空间) 分享给他们不信任的第三方，那么结果很可能事与愿违；
自治和问责—— 根据我的经验，大多数团队都想要并渴望拥有自治和问责权。无论是否是软件开发，当今的头部企业都会组建起一个个小型授权团队，这些团队知道自己的任务流程和进度，拥有自主决策权，并拥有着良好的客户关系网络。在这个过程中，领导力发挥着关键作用—— 引导并帮助创建一个自由、坦诚、赋权和自主的环境。你会发现，这样的团队更乐于主动承担责任，效果远比强迫他们承担责任要好。

此外，在 MongoDB 构建自治和问责能力时，我们格外看重以下四项特质，这些特质相互交织且结合起来产生的作用要远远大于各自相加的总和。

坦诚：要想打造坦诚文化，首先需要弱化利害关系。无论遇到什么问题，我们都希望员工能够敢于讲真话，以善意的角度表达想法和接受反馈。
背景：我们与员工分享大量企业信息和战略(甚至是疑虑和担忧) ，因为我们认为员工应该获得所需的所有信息，这样才便于他们更好地做出决策。
赋权：我们希望，在公司内部，员工不必事事请示。例如，作为首席技术官，我的职责之一是审批每一位员工的出差申请，但我并不愿意这样做，我希望员工将相关政策抄送给我，而我有权提出质疑或反对。我们应该授权员工，让他们自主做选择，而我们的职责是为员工创建起这些必要的机制。
心理安全感：每个人都需要在工作场所中获得心理安全感。没有人是奔着失败来的，但失败在所难免。作为领导者，在发现实验失败时，我们需要坦然接受，将失败视为通往美好未来的垫脚石。

深入钻研永远不会过时！

《新程序员》：中国有非常多的程序员，但据 CSDN 《2021-2022 中国开发者现状调查报告》数据显示，从事数据库内核研发的人只有 7%，对于数据库核心研发人才培养，你有什么建议？

Mark Porter：首先，我不确定 7% 这个数据是好是坏。如果我们是在讨论有多少开发者从事数据库技术研发这个问题，而答案是大多数开发者都在从事这项工作，那么我会感到不安。如同操作系统编程一样，数据库核心技术研发需要专业技能，我认为大多数开发者应该利用底层数据库技术来构建应用程序，而不是自己研发数据库。

对于所有应用程序来说，数据的使用、存储、保护和管理都是非常重要的环节，甚至可以说是最重要的环节，但也只是其中的一个环节。建立数据库是一项非常困难和复杂的任务。要想建立数据库，就需要非常关注这些问题。

我希望能够让大多数开发者都专注于为客户或组织机构创建新的价值/功能。我们的使命是打造一个理想的数据平台，让开发者不需要花费太多时间去研究，就可以快速实现迭代和创新。数据库研发不应该是开发者考虑的问题，应该交由我们来完成。对于想要从事数据库研发的开发者而言，则应该了解数据库的基本工作原理及数据库与应用程序的交互方式。

《新程序员》：在踏入工作至今，你的做事方式或工作方法是否发生了改变？有哪些感悟是受用至今的？

Mark Porter：我认为，工具进步是软件开发领域最为明显的变化。在现代开发环境中，我们可以轻松避开编码过程中的各种失误，甚至可以自动编写和运行大多数测试。如今，只需点击一下，即可部署数百台机器，还可以进行回滚操作。在我刚进入软件开发行业那会儿，这一切都是不敢想象的，那时的我们不得不将大量时间花费在简单的低价值任务上。

谈到人生感悟，我认为做事情应该求深求精，而不是浅尝辄止。深邃的知识会转换为卓越的成果。学会钻研本身就是一种技能，深入地了解有关软件组成或技术的几乎所有知识是一件令人振奋和自豪的事情。从我的人生经验来看，我发现懂得如何钻研技术的人比其他人更有价值。

《新程序员》：如果回到 30 年前，你会给年轻的自己提出什么建议？

Mark Porter：不用回到那么遥远的过去。我的妻子曾给我提过一个建议，我一直铭记于心，在我担任管理者和领导者期间也一直在坚定地贯彻这个理念。

我和妻子育有五个可爱的孩子。在孩子们还不到十岁的时候，某一天，妻子走过来对我说：“如果你总是以相同的方式对待所有孩子，你会慢慢失去他们的。你觉得‘做父亲有一个正确的模板’，但实际上，你必须要认识到，我们的五个孩子需要你给予他们不同的关爱。”

听从了妻子的话，我做出了改变，也取得了显著的效果。大概一两年后，我意识到，作为一名管理者或领导者，我也需要保持同样的心态。我们要学着成为一名多面性的领导者，成为一名每位员工都需要的领导者。在此过程中，没有诀窍可言，唯有不断投入和付出，才能得到回报。

《新程序员》：业界有不少程序员会有“35岁”危机，大家普遍认为此时的开发者在精力和体力比不上年轻人，编程质量可能也在管理团队的过程中因为脱离一线而下降，你怎么看待这种现象？有什么建议可以分享？

Mark Porter：首先，我完全不认可“35 岁是大龄程序员”这个说法。相反，我认为这是开发者的黄金时期。因为这时他们大多已经步入行业多年，拥有了丰富的经验，能够避开初级开发者可能会犯的一些错误。我觉得，35岁左右的优秀开发者可以转向架构和指导方面的工作，这样可以开辟更多学习和成长的途径。作为一名成功的开发者，关键在于终身学习，而我们在任何年龄段都可以做到这一点。

就职业发展而言，开发者应该慎重考虑是转做管理岗还是继续从事开发工作。同时，开发者还需要明确一点，无论作为个人贡献者，还是管理者，都必须要得到公司的切实支持。

在这里，我想给开发者的建议是，深入钻研永远不会过时。无论负责算法、调试还是工具链，只要你足够优秀，就会得到组织的器重。只有足够优秀的开发者，才能独具慧眼，才能抓准颠覆性迭代或重新设计的时机，也才有信心肩负起这份重任。

我不欣赏那些每两年就从一个技术转向另一个技术(或从一家公司跳槽到另一家公司) 的人。10~15 年后，他们会发现自己什么都会一点儿，又什么都不精通。在这个职业阶段，本应该考虑晋升到更高级别的职位；但不幸的是，自己一步步走下来，已经失去了最佳时机。我见过很多人在职业生涯中受挫于此。

受访者简介：Mark Porter