你好，我是郭东白。上节课我们讲了架构活动中需要重视对商业价值的考量。作为一个架构师，必须要创造足够的商业价值，才能保障自己职业的长期。
那么你作为架构师，该如何为你的公司、部门或团队提供可量化的增量价值呢？主要有扩大收入与减少成本两种路径。今天这节课，我们就结合几个真实的案例来具体分析一下。
有的架构师不关注软件之外的事情，比如很少关心公司或部门的收入。这种性格虽然可以让他专注于软件工作，但从长期来看，如果不去思考如何通过技术为公司创造商业价值，那就很难保持或扩大自己在团队的影响力，职业发展也可能受挫。
所以哪怕没有人向你施加为企业增加营收的压力，你也要主动思考，你或你的部门，该怎么为公司创造更多的营收。
那么我们该从哪里寻找扩大营收的机会呢？除了之前提到的深度理解用户心智和商业模式，以及我们经常遇到的不同的横向问题，比如稳定性、安全、可测试性、可维护性之外，还有其他方法吗？
你可能听说过“在小数据里看大机会，在大数据里看小机会”这句话，这其实适用于我们所有技术人。
前半句指的是从个性需求中抽象出共性的机会。也就是从解决一个具体问题的过程中得到启发，并从中找到一个可以规模化应用的机会。比如做用户调研时，你发现有一个用户总是截图之后再通过微信把商品发给另一个人。那么你就会意识到，可以开发一个分享工具，通过小程序和DeepLink来获得更多的社交裂变。
后半句指的是靠数据来打磨用户体验。也就是通过数据分析找到机会点，然后通过产品和技术的改进，不断提升转化减少损失。这是算法和数字化运营的常见办法。比如淘宝App的首页跳出率是2%，就是通过数据分析和打磨而不断提升的。
我特别强调一下前半句。事实上，很多著名的开源框架都是这么来的。离我们最近的一个例子就是Docker。
虽然现在的Docker已经没有它如日中天时那么辉煌了，但毫不夸张地说，今天整个云原生生态的存在，引爆点就是Docker。但谁能想到，Docker最初只是为了解决一个环境打包问题呢！回想一下，从你进入计算机领域以来，你见过几个程序员会把心思放在运行环境打包上呢？
这个案例给我的启发就是，很多非常成功的技术人，他们往往就是看到了别人忽略的小痛点，或者在别人不去排查的小异常上执着探索，才最终跨越了现实的障碍。
举一个我们团队的例子。我们曾在海外做社交裂变，玩法与拼多多的拉好友砍价类似。但刚开始时，业务逻辑出了一个Bug，用户没有达到提现条件（比如说拉到20个好友下载App）我们就让用户提了现。当然这个Bug造成了一定的资金损失。
我想既然钱已经损失了，那么分析一下用户行为也是好的。比如到底是哪些人比较喜欢薅羊毛呢？这些人薅了羊毛之后会对我们的产品产生情感连接，提高忠诚度吗？
于是我们通过用户标签做了简单的行为分析，然后惊奇地发现：小城市里的年轻女性非常特殊，她们发现了这个提现存在漏洞后，就做了大量的分享行为，主动拉新。在她们的分享推荐下，很多人都下载了App，而且这些人还没有加入裂变来薅羊毛。
更让我们兴奋的是，在我们修复了这个Bug之后，这些年轻女性的分享拉新行为依旧没有停止，而且她们拉来的用户的留存和购买率，竟然和大盘的拉新、留存差不多。也就是说，我们激活的这些年轻女性，是能够为平台带来大量用户增长的超级分享者。换句话说，对这个小Bug的执着，最终帮助我们找到了超级分享者。
后来我们就放大了这个玩法，故意放出“薅羊毛”的机会随机发给某些用户，尤其是年轻女性，并在其中寻找超级分享者。
接着，我们通过用户画像中召回与超级分享者最相似的人群，再用增强学习的方法放大这个人群的拉新效果。这样一来，这个小发现就能被大量复制了。
通过这个方法，我们发现前100万新增用户所用的拉新成本，连之前十分之一都不到，而且增长的空间也很大。这个方法玩了半年，让这个国家的互联网买家渗透率增加了7%。
所以你看，在别人容易忽视的痛点和异常点上，深度挖掘可能大规模复制的机会，不失为扩大收入的好方法。
能赚钱固然好，但省钱对于一个公司，尤其是成熟公司来说，也同样重要。
先分享一个故事。Robert Scott是一位伟大的探险家，他是人类第二支到达南极的队伍的队长。令人遗憾的是，他与他的四位队友都死在了从南极返回的途中。原因很复杂，但一个颇为重要的原因就是食物不足。他们只带了够4个人吃的食物，而队里却有5个人[1]。
这跟软件开发有什么关系呢？
一个公司在做商业模式探索的过程中，跟一个人要向前冲刺是一样的，都需要消耗能量。只不过对于一个公司而言，这个能量是钱。一旦钱耗尽，公司就饿死了。当然你可能会说，我家不缺钱。可以，难道你不缺时间吗？
所以作为一线的架构师，哪怕你不清楚公司的财务状况，但你的任何架构动作，都要考虑公司的研发成本，确保团队的规模在公司财务状况的允许限度之内。这也是经济学中所说的成本观念。
其实这种成本观念公司上下每个人都要有。对于一个公司而言，一切有限资源上的消耗都是公司在架构活动中要付出的成本，比如时间成本、人力成本、机会成本、计算成本等。
拿人力成本来说。很多做技术的人都有官本位思想，认为下属多多益善。似乎下属多了，他的管理水平就高了。相应地，工资和层级会更高。所以就会故意夸大和消耗更多的人力成本来换取自己的晋升。事实上，一个真正有经验的管理者很容易就能鉴别这种中饱私囊的蛀虫。面对这种情况，我的建议是，无论如何也不要参与到这种行为中去。
分享一个我的经历。08年美国发生次贷危机之前，我从耶鲁大学招了一个满分毕业的计算机系硕士生。他工作勤奋，产出也很好。但没过多久，公司就因为营收压力要强制裁员。由于他的入职时间最短，最终决定只能裁他。
他出生在印度一个普通家庭，从印度理工计算机系毕业后，又考到全球顶尖学府，这一路的艰辛可想而知。然而现实就是，在美国全职工作是拿绿卡留在美国的前提，我们一旦终止合同，那他只有几天时间去找工作。在经济危机发生的时候，这几乎是完全不可能的事情。
那两天公司上下都在裁员，当我叫他进办公室时，他已经预感到要发生什么，整个人都快虚脱了。他苦苦哀求，我都不知道该怎么回复他，只能沉默以对。这么多年了，我现在一闭上眼，还能想起他那一刻流露出的绝望眼神。
我分享这个故事，就是期望你知道，控制成本不是为了老板，而是为了我们自己。假设你总是以又大又笨重的系统去应对，那么在公司出现困境、经济出现低谷的时候，你的团队或企业可能就不复存在。相应地，架构师创造的软件也就不复存在，个人收入也会受影响。
从更理想化的角度来说，这么做也是为了自己的良心。我虽然无法预测未来，但在面对印度同事那一刻，内心还是非常自责。既然我不能给他一个稳定的任职机会，为什么还要让他加入？我的团队如果大幅盈利，那我不但不用裁员，说不定还可以收留其他员工。说到底还是我没做好。
我只是讲了人力成本的例子，其实时间成本、机会成本，包括技术的迁移成本，都是一样的。你作为一个架构师，要能省则省。
有些人会过分强调极客精神，事事追求完美。我觉得出发点是好的。但在一个企业中，追求完美必须以成本可控为前提。
关于第三条生存法则的内容我们就讲这么多，接下来分享一个我经历的性能优化的案例，来帮助你学以致用。
很多研发在做性能优化的时候，都会说“某个性能参数之前的TP95是多少秒，经过我优化之后，降低了多少秒”，以此来凸显自己的厉害。但这种玩法会让一个人逐渐忘记目标，只一心追逐性能上的极致。这就违反了我们今天讲的以商业价值为导向的架构原则。
我刚去AliExpress时，负责公司的全站架构。那时全站的性能非常差，但大家不知道这个差到底意味着什么，也不知道做性能优化到底要付出多大成本，又能带来多大回报。
当时我们已经有了全站的埋点。也就是说，我们有办法获取任意一个页面上跳出率和加载时长的关系，有办法获取任意一个页面上流量分布和加载时长之间的关系。我们也知道如果针对一个页面做优化，比如JavaScript优化、内容的静态化、图片压缩、动态加载等，都可以用来提升页面性能。
但问题就在于，如果针对每个页面的优化都要做投入。再加上维持这些优化效果，就要对页面的变更做限制和性能监控，那么付出的成本会非常高昂。
要知道，AliExpress是个跨境电商网站，当时有14个站点，每个站点的前端代码都有微小的差异。一到大促，就要根据国家和语言一次性发布数千个页面。如果按部就班一个一个页面去优化，哪怕配十几个全职研发，从头到尾做一年也跟不上发布的速度。
但结果呢？
我们只用了6个同学，兼职干了不到半年，就把全站的订单数提升了10.5%。这是怎么做到的呢？
我发明了一个方法，能够准确度量性能优化后每个页面的预期产出。而我们要做的，就是按预期产出除以预期投入成本，也就是预期回报的ROI来排序，再依次做优化。
具体的公式比较长，我就不在这里展开了。这个算法的核心原理展示在这张图里[2]：
如图所示，我们根据每个页面转化率分布的直方图，以及预期的性能优化后的结果，预测出如果不做性能优化而损失的该页面的转化率。我们把这个预测值叫做页面的性能损耗Lpage。
因为我们有全链路的转化漏斗和流量统计，所以如果优化某个页面，把性能损耗追回之后，那么这个优化对下游，以及对订单和GMV的预测，就可以通过大数据统计提前算出来。
所以我们就以优化订单数为目标做了架构规划，然后统筹我们可以做的一切优化动作。
如下图所示，本来完全不等价的优化动作，有的在网络层，有的前端，有的在后端。这下子就可以在一个指标上做比较了，因为我们的每一个优化动作最终都能被归因成了订单贡献。
之后我和团队把它做成了一个基于性能损耗的度量系统，共申请了13项专利。而这个理念也从最开始的指导架构规划，变成了性能归因、性能监控、转化分析和准实时的转化排查工具，并从AliExpress的一个部门逐步推广到阿里巴巴的其他部门。
这个架构项目成功的关键，也正是我一直在遵照我这两节课介绍的生存法则。现在让我们一起通过这个性能优化的案例来检验一下，看看我如何用生存法则来指导架构活动。
另外，我们通过案例检验的过程，会重新总结并强调我们这两节课传递的一些核心观点。
第一，你作为一个架构师，在架构设计中要追求商业价值。
我们做性能优化时，不是单纯做性能指标的优化，而是一上来就以提升商业价值为目标。因此我们的优化目标是订单数，而不是一个技术指标。
第二，想要创造商业价值，就必须不断度量你创造的增量价值，这样才能确保自己处在价值创造的前沿。并且能够在一个相对未知的环境下，不断寻找自己的增值空间。
从这个项目的开始，我们就没想过要做全站的性能优化，而是发现了回报最大的单点，做针对性的优化。
为了做到这一点，我发明了准确度量性能损耗的公式，找到了部门层面的单一优化目标（订单数）。并把我们所有可能的优化动作，全部归因到这个单一的优化目标上去。
有了这个可度量的价值，我们就不再做地毯式的性能优化，而是做具有针对性的、回报最高的性能优化动作。
此外，我们也没有越做越宽。当发现性能优化的回报不够大了，我们就不再做性能优化了。而是换个赛道去创造价值：做现有网络的性能监控。
最好的证明就是当时我们和全球研究实力最强、监控能力最完善的Akamai合作。而且我们发现，我们对CDN网络的监控能力，在很多国家要远远胜过Akamai。甚至到后来，我们干脆请Akamai的运维人员接了我们的部分报警。在此之后，我们又把应用方向再次扩大到业务转化问题排查等等。
第三，作为一个架构师，要最小化整个架构活动的成本。你要做的是：
我刚加入AliExpress时还没有很强的号召力，能调用的资源也极为有限。但当我发现性能优化是个突破口之后，就立即制定了一个可行的方案，而不是一个宏大的方案。
我当时仅仅把上面这个理念解释给了几个同学，然后我们就靠手算找到了回报率最大的几个页面，并且凭经验找到了投入产出比最大的优化点。这就确保了我们整个项目有非常强的可行性，同时也给了我们信心。
紧接着，我们迅速搭建了刚才提到的性能损耗的度量工具，验证了从工具中发现的优化点到订单回报的全流程。这样一来，不到一个月，整个项目的可行性就得到了验证。
但还是遵从同样的原则，为了确保投入最小化，我们仅仅升级了从优化点到订单的A/B能力。这样的话，我们的实施成本少，实施路径明确，所以项目可行性和合理性的风险就非常小。
最后，我还做了设计方案的结构性规划：先把相关理论和公式做了完整的推导，确保所有参与到项目的同学，都知道未来这个系统能给部门带来的核心技术价值，以及它对我们业务的支柱性作用。再把这些公式变成性能监控和性能损耗度量的工具。
这种结构化的思维方式使得我们在推广中的投入成本非常低，而且所有参与者都可以调用同样的工具来监控和度量性能的优化，以及实际产出。
可以看到，所有的核心能力，包括括数据链路、监控、A/B能力等等，在建设时都没有打折扣。虽然我们没有打算一上来就把整个系统构造完整，但我们还是为将来的扩展做了足够的考虑。这也是为什么我们的系统后来能够演变出新的能力的原因。
第四，做架构和做业务一样，都不能靠饱和攻击取胜，而要靠对阶段性精确目标的最大化投入来取得进步。
我们的系统虽然后来演变出了很多能力，包括保障业务稳定性、系统监控、业务问题和性能问题排查等等。但是在这个过程中，任何一个时期我们都只有一个目标。尤其是最开始，我的目标非常窄，就是通过性能优化带来订单量提升。我们甚至都不考虑优化带来的服务器成本降低。因为前者是放大收入，后者是节省成本，我们出手第一步只考虑放大收入，没有考虑节省成本这个附带目标。
第五，不断寻找通过技术手段扩大收入的机会。
这一点非常明显，整个案例都是通过纯技术手段带来订单增长的玩法。
第六，不断寻找通过技术手段缩减成本。
这一点要着重解释一下。这个案例并没有缩减成本，而是通过对性能的投入来获得商业回报的。
但我们案例执行中的每一步，都试图最小化我们在性能优化过程中的人力和时间成本，同时最大化商业回报。我们是怎么通过技术手段做到的呢？
在案例中，我们走的每一步都试图以最小成本去放大收入，技术上我们在不断计算性能损耗，在寻找最大的性能损耗和技术人日投入之间的比值来选择我们下一个优化点。
我们这个架构项目没有以节省成本为目标，是因为对于一个处在成长期的企业而言，挣钱永远比省钱更重要。我在AliExpress任职总架构师和CTO的前三年里，很少把注意力放在节省成本的手段上。
一个业务在高速增长的过程中，目标用户群体和用户心智，以及商业模式、供应链和运营手段，都在不断迭代。那么我们在快速奔跑的时候，最高优先级就是保障增长。哪怕增速慢下来，我们的优先级也依然是探索加速模式，重回高增长。而当一个业务到了成熟甚至是衰老期的时候，那就需要通过节省成本来扩大利润了。
你肯定想问我最后那个被裁的印度同事怎么样了。当他走出我的办公室后，我整个人都要崩溃了。我在我们整个楼跑上跑下，挨个敲每个研发管理者的门，告诉他们这个同事有多优秀，裁员对他来说打击会有多大。我跑了一下午，没有得到任何回复，原本都绝望了。
但是下班前有个主管来找我，说他团队里有个同事知道来龙去脉后，决定在那天下午提前退休，把自己的位置让给印度同事。这位印度同事后来在这个团队工作了很多年，我们也一直保持着友好的朋友关系。
这个世界还是有很多善良的人的，我期望你能记住这个故事，善待你周围的人。
这两节课我分享了一个新的架构师生存原则：你作为一个架构师，必须要创造足够的商业价值，这样才能保障你在企业长期存在的意义。
为整个企业创造商业价值，说得更直白一点，就是你要为企业赚到钱。
拉长时间来看，我们每个人，都会被我们所在的企业以商业价值的视角来审视。与其让别人审视你，还不如自己审视自己，在日常的每一天都去看自己的不足，从商业价值视角上看到自己可以提升的地方。这就是我们这两节课反复强调的事情。
因此，在日常的架构工作中，就要从创造商业价值出发，理解自己所在团队或企业的商业模式，理解自己为企业创造的增量价值。然后通过技术手段，最大化自己或团队的商业价值创造。
具体怎么做，其实我们不可能在两节课里穷尽所有的办法，但我们的确穷尽了所有的路径，那就是寻找扩大收入和减少成本的机会这两种。前者需要你不断探索、度量你的增量价值。而后者则需要你关注成本，平时能省则省，看准了机会之后再对精确目标做最大化投入，以取得最大的回报。而最终能做好这两点，还是要靠你日常养成的习惯。
能否分享一个你经历过的通过技术创造商业价值的案例呢？请注意，在分享这个案例的过程中，我建议你多强调这个技术突破点是怎么被发现的，具体的技术细节反倒可以讲得概括一些。
注释：
[1] Apsley Cherry-Garrard, The Worst Journey in the World – Antarctic 1910–13
[2] 郭东白、李彦超、桑植： “一种性能优化结果预测方法及装置。”申请/专利号：CN201610550297.8；申请日期： 2016-07-13
如果今天这节课对你有帮助，欢迎你点击课程右上角的分享并赚钱按钮，把课程转发给你的同事或朋友，大家一起交流、进步。我们下节课再见！