按需求构建架构才是正确之举，过度工程只会“劳民伤财”

Rebecca：要说可进化架构，我觉得最重要的一点就是, 关注自己想通过架构实现怎样的结果。具体实现永远是为结果服务的。

作为一名企业架构师，我的工作就是确定到底需要把可扩展性、安全性或者弹性做到什么程度。我不会具体指定必须使用哪种负载均衡器，只会定下合理的负载强度目标。所以如果大家能把注意力从具体实现转向规范性目标时，最终成果反而会更好，因为这样系统构建团队既有灵活空间、又有明确方向，他们自己知道怎么做选择。弹性啦、可扩展性啦，这些都是客观的衡量标准。

有了这样的指引，系统团队就能权衡不同的架构选择会给结果造成怎样的影响。而且面对新技术，大家还是会以结果倒推方案 — 符合架构需求，那就用；如果不符合，那再新的技术也没有意义。所以这样我们的架构会更灵活，我们可以专注于需要实现的目标，不再纠结于特定时间、特定位置到底要用哪些特定方案。

这就是构建可进化架构时，必须完成的心态转变——以结果为导向。我不在乎你具体怎么做，但它必须能达成特定的正常运行时间或者可扩展性。要求明确之后，身处一线的团队更了解该怎么做取舍。他们可以自由选择技术，决定自己怎么把目标变成现实。

Rebecca：没错，但很遗憾，我经常见到过度工程、过度设计的系统。不是每套系统都需要 99.999% 的可靠性，也不是每套系统都需要应付谷歌那样的负载规模。我们构建的系统能满足自身需求和合理预期就够了，干嘛非要做得跟 Netflix 一样夸张？

Rebecca：在关于可进化架构的演讲中，我最爱举的例子，就是我们当初在英国开设办事处的故事。我们当时有家英国客户，他们运行着一套三明治外卖系统。每天早上，食客可以在系统上下单，再由他们负责送货，客户的信用卡信息也不会被存储到他们的系统里。

我们的办公室就在伦敦中心区，所以只要这套系统出了问题，我们下楼看看门口那些三明治店，就能马上发现端倪。这根本就不涉及保密的问题。我每天早上都会下单点个三明治加鸡蛋，订单里没有个人身份信息、也没有信用卡信息，所以完全不需要加密。即使系统停机维护，我也只需要下楼亲自去趟门店就行，根本没啥影响。对于这么简单的系统，用 rails 之类的开发就够了。客户创建的订单会留存一段时间，再到当周末集中删除。总之，这天然就是一套最最简单的系统，没必要硬塞一些复杂的功能进去。

我还经常提及另一个案例。当时我们为客户构建了一套交易系统——一听到交易系统，很多人首先就会想到“高频交易”，就是频率超高、延迟极低之类的。但大部分交易系统其实没那么复杂，每天只需要处理 100 次左右追踪交易。所以性能并不是大问题，反倒是交易成功率才是重点，毕竟每笔交易的金额都高达数十亿美元。

所以情况就跟第一印象完全不同了，这类交易系统跟高频交易系统根本不在一个次元。所以我们还是要回归眼前的现实问题，思考怎么解决、为系统引入哪些特性，这才是根本。

Rebecca：我经常引用 Martin Fowler 写过的一篇文章，谈的就是微服务架构的适用门槛。对，微服务架构相当复杂，是有适用门槛的。

我自己也在一篇文章中，解释过为什么我们永远不会在技术雷达上使用微服务。虽然微服务确实能解决某些特定问题，但架构本身的复杂性却大大增加了。就像你提到的分布式架构，它们真的非常复杂。如果采用结构更简单的其他高质量模式，很多故障压根就不会发生。

所以组织得先明确自己能从微服务架构中得到哪些好处。这些分布式架构或者说微服务架构当然很有价值，但你得证明由此带来的额外复杂性物有所值。各个微服务可以独立扩展、功能灵活，这些都是真实的优点，但同时也会给 IT 部门带来更大的运营负担。

我之前也提到过，持续交付才是真正的核心，所以如果保证不了这一点，微不微服务根本没有意义。所以如果 IT 部门已经非常成熟，那不妨放心大胆地去用微服务架构；但如果原本的模式就已经完全够用，何必还要自寻烦恼呢？万一 IT 部门根本搞不定微服务模式，那只会把本来好好的业务弄得一团糟。

所以还是认真想想微服务架构到底有什么好处，在组织里到底能不能发挥不可替代的价值。把收益和成本权衡一下，相信大家自有答案。

Rebecca：对我来说，技术的最大意义在于, 它能给人们的生活带来怎样的改变。我倒是没有被技术所累，最多也就是根据亚马逊上的推荐买东西，而且我还是挺喜欢那些推荐的。真的没什么大问题。但其他一些关键领域，比如医疗决策、刑事司法系统、信用评分、欺诈检测、人脸识别等等，与此相关的错误会造成严重后果，我们自然不能对相应的技术掉以轻心。

作为技术人员，我们需要考虑一旦自己犯了错，最终会造成怎样的影响。我们能承担后果吗？我们真的了解系统训练中所使用的各种数据吗？关于偏见，我经常会举这样一个例子。虽然偏见并不一定就有恶意，但影响仍然不容忽视。一家医院打算训练一套模型，指导医学生们如何设计患者的术后恢复方案，特别是需不需要将患者送入重症监护室（ICU）。结果，数据集中的素材对哮喘患者存在偏见，所以会自动将所有哮喘患者都送进 ICU。

事实证明，这套数据集里根本就没有关于哮喘患者的信息，这些患者是在不同的医疗系统下接受诊疗的。但院方在训练模型时并没有考虑到这一点，所以模型对哮喘症状一无所知。随着时间推移，如果有医院真的直接使用这种模型，那么肯定会引发很多“药不对症”的问题。这套模型对哮喘病人当然没有恶意偏见，只是院方没有认真筛查模型训练所使用的数据集。我们在实际工作中，接触过很多出现类似问题的系统，所以我才觉得负责任技术是个非常重要的议题。

好在现在的我们还拥有关于理性决策的集体记忆，及时纠正未为晚矣。

Rebecca：其实万事万物都有负面效应。我觉得最大的负面效应，其实来自因为对底层数据的不理解而做出的错误决策。不单是做出错误决策，甚至会强化这些错误、让下一次做出错误决策的可能性提高。毕竟强化学习的基本原理就在于此。

而从另一个方面出发，随着自动化水平越来越高，很多系统当中发生问题的速度也越来越快。如果整个循环中还有人的要素，那至少要等他们按下“确认”按钮、或者输入某些指令。但如果是机器对机器交互，这些延迟就将不复存在。这样我们得到的就是快速升级的反馈循环，错误会令交易业务的公司在几分钟内就宣告破产。这就是算法出错造成的危害，整个组合将会瞬间灰飞烟灭。而如果其中有人的参与，这些问题就不会发生。

所以我们必须要建立起这样一种更可靠的自动化循环，否则早晚会发生意想不到的情况、那种我们根本无法预测自动化系统会作何反应的情况。自动驾驶就是典型的例子。目标似乎很简单：让汽车沿着高速公路行驶，躲避其他汽车并保持在车道中央。这事很难吗？但行驶过程中往往会出现一些意外状况，比如一只鹿突然窜上马路，或者有人破坏了行驶标识、导致系统无法正常识别。对于这类全自动化系统，我们必须全面思考它们犯错的可能性，并在系统中设置断路器，确保能在意外后果发生前将其关停。

Rebecca：确实，所以我们才发布了《负责任技术手册》，大家可以在我们的网站上看到。其中包含一系列促进技术，能帮助开发团队有效打破自己的固有观点，从其他不同技术人员的视角看待问题。是的，在讨论负责任的技术时，我们会从问题出发。

我们会先搞清楚问题是什么，再看看问题会影响到哪些人，也就是我们需要帮助的对象。我们还会站在受影响者的立场上思考，比如他们可能需要什么？他们可能有哪些顾虑？这份手册中的方法并不全是我们自己想出来的，我们只是收集了这些思路并整合起来，同时注明相应来源。有了如此丰富的促进技术，我们就能更全面地审视自己的技术选择、考虑这些选择可能产生的影响。毕竟技术本身没有立场，所以无法预判实施之后会带来哪些意外后果。

这就是负责任技术理念的意义所在。作为技术人员，我们至少有责任想得远一些，预测技术实施可能引发哪些意外后果。也许没什么后果，也许能改善产品并扩大目标市场，这些都是比较好的结果。但某些意外后果也可能伤害到其他人，也许有办法可以提前预防或者缓解，这就是我们身为技术人的责任。

Rebecca：当时我在学代数，我们的高中数学老师正好在当地大学里学习编程。他买了本教科书，记得当时是 1974 年，我正好在读高中。他也送给我一本教材。那时候学校里有一台键盘穿孔机。不知道为什么，我们学校从来没开过这门课，但我可以用这台机器编写程序再录入到打孔卡里。之后，代数老师会把我的卡片带到大学，在上课的时候试着跑一跑，我就这么学会了编程。靠着代数老师学编程的这本教材，我第一次接触到了编程。

Rebecca：喜欢啊。我很少回忆过去，但我还清楚记得那种能用电脑解决问题的感觉。这是一种截然不同的问题思考方式，真的很令人着迷。顺着这种方式，我们就得到了程序，我特别喜欢这种感觉。

Rebecca：与其说是数据，不如说是技术可以改变世界，当时的我倒是相信编程和技术可以改变世界。

因为这些是实实在在的工作，能让事情变得更好。我们可以用程序处理账户、应收账款、工资单之类的工作。对于这些简单的结构化任务，当时的人们还没法直接编写公式统一解决。但程序可以，所以这是种革命性的飞跃、能够让这个世界变得更美好。听起来有点幼稚，但那时候我们确实是这么认为的。

Rebecca：主要是因为我身边总有一群同样热爱技术的伙伴。现在我还主持着一档播客节目，我特别喜欢录制播客的过程，因为大家可以坐在一起，共同讨论彼此关注的某些技术话题。

在这一个小时里，我会以主持人的身份交谈、感受他人对于某些技术细节的激动之情。所以我们才会每年举行两次技术雷达大会，在这里大家可以接触到更广泛的技术工具、平台和方法。这就是我保持技术热情的方式。

Rebecca：没错。

Rebecca：我刚开始从事技术工作时，CTO 的身份多少有点像记者，只需要在操作系统、编译器、数据库和应用程序当中做选择就行。但现在的技术领域太过广泛，所以记者型的 CTO 已经不成立了，任何特定类型的技术都会引发相应类型的问题。

比如说，当我们面对物联网系统，那有些问题就可以直接忽略；但在使用云端服务器时，同样的问题又变得至关重要。整个技术生态已经比当初复杂太多了。所以我会从思路、成效等多个角度审视这些技术，理解它的内涵。

Thoughtworks 公司体量不算太大，目前有 11000 名员工，但也已经不小了。那埃森哲呢？他们有 40 多万人。所以我们必须对自己的选择、对可能给客户带来重大影响的技术保持严谨且挑剔的态度。我一直在担心自己的某些技术判断会不会出错。我最怕自己做的决定搞得客户们怨声载道，绝对不能出现这样的事情。

总之，随着技术环境变得愈发复杂，客户使用技术的方式也越来越广泛。多年以来，大家已经习惯了在特定类型的应用场景中部署传感器网络，但以往这些系统只适用于某些特定问题，现在却需要朝着普遍适用的方向发展。身为 CTO，我觉得现在选择技术方案的难度确实越来越大了。

Rebecca：这个要分几点来看。首先，有些人比较像独行侠，我行我素、不爱跟团队打交道。但也有些人特别喜欢在团队中工作，却并不愿意承担管理事务。这些都很正常，但有时候却会限制一个人的发展空间。

这也是大家从事技术管理工作的最大障碍。身为开发人员的时候，我们面对的都是能够快速反馈的问题：代码编译成功了吗？测试通过了吗？一个个非常具体的指标可以清晰衡量工作成效，让我们感受到自己的进步。如果测试没能通过，我们就回头修复，也无所谓。但身为技术管理者，这种比较直接的成功开始逐渐消失，我们可能在很长一段时间里都无法确定自己做的事对不对。这对很多人来说最难适应，因为他们习惯了自己做对的事、而不是指导别人去做对的事。

我觉得这确实需要重大的心态转变，但回到之前你提到的保持技术热情的问题。我觉得大家就算走上了技术管理岗位，也仍然需要保持住技术水平，这样对工作更有帮助。也只有这样，技术管理者才能区分技术的好坏，理解团队成员有哪些不足、他们面临怎样的问题、又该如何提供帮助。

所以在我看来，不管是做纯技术还是涉足管理，对技术保持热情都是最重要的前提。

Rebecca：女性在科技行业的发展道路仍然很艰难。我是个铁杆极客，所以从没动过退出的念头，唯知一路奔驰。但对其他很多女性，这些阻碍确实会影响她们的感受、甚至迫使她们退出。要想坚持下来，最重要的还是对持续学习新事物的那种强烈期待吧。另外，培养起坚守自我价值、忽略噪音的能力也很有帮助。

真正让我坚持下来的，还是对技术的热爱。我喜欢学习技术，探索技术的使用方式。

我喜欢学习新技术、喜欢跟大家一起工作。对于自己热爱的事物，我们同样得做出权衡，弄清楚哪些最重要。让我感到遗憾的是，很多男性技术工作者可以出于丰厚的报酬和有趣的工作内容坚持下来，同时期待能有更大的上升空间；但对于女性，他们的评判标准又变了，似乎好工作突然就变得不那么好了。所以在技术场合下看到女性，很多人的第一反应会觉得对方是秘书，“给我来杯咖啡”这种。我就遇到过类似的情况，他们觉得出现在办公室里的中年女性，肯定不可能是搞技术。

所以如果大家对技术像我一样充满热情，那就请坚持下来，这一切都是值得的。但如果在你眼中，这单纯只是一份工作，那不如去找个项目经理之类薪酬差不多的岗位。确实，在技术行业里女性还是会多少受到一点歧视和冒犯，这个是有的。

总之，现在整个行业在多样性和包容性方面已经做得越来越好了。但如果各位女性朋友对技术没有热情、只是单纯想找份好工作，那可能还是不太适合。

Rebecca：谢谢。

嘉宾简介：

Rebecca Parsons，Thoughtworks 全球 CTO

往期推荐

• 一个思维习惯，让你成为架构师
  

• 阿里人，用语雀文档
  

• 很佩服的一个Google大佬，离职了。。
  

• 曾有5亿用户的应用下线，诞生比微信还早四年
  

• 阿里英布：程序员最重要的八种软技能