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