mod

极客时间专栏/乔新亮的CTO成长复盘/对专业成长的复盘/17 | 架构决策，是技术管理者最重要的能力.md

@@ -0,0 +1,183 @@
+<audio id="audio" title="17 | 架构决策，是技术管理者最重要的能力" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c7/4d/c76c90d07cc6ee8d1254140e0626944d.mp3"></audio>
+
+你好，欢迎来到我的专栏：「乔新亮的 CTO 成长复盘」第三章 —— 也是最后一章：「对专业成长的复盘」，我是乔新亮，很高兴能见到你。
+
+说起来真的有点感慨，自从 10 月 26 日专栏上线起，眨眼间，我们共同度过了一月有余的时光。
+
+在这段时间里，有超过 3500 人加入课程，与你我一起成长。专栏共发布了 17 篇文章，收到了超过 500 条留言，有好多同学是篇篇都留言，一路相随。基本上，每一条留言我都回复了，收获了许多感动与启发。
+
+感谢你！
+
+接下来，我们将以技术和架构思维为抓手，夯实管理者的成长基础，争取做一个底子打得扎实、向上生长快的优秀技术管理人才。最终，我们的目标是，成为一名优秀的 CTO。如果你觉得有收获，不妨把文章分享给其他人。不同的声音越多、交流的价值越大，成长的速度就越快。
+
+好，我们言归正传，聊一聊如何理解和提升架构决策能力。
+
+## 决策失误，是“技术债”的主要来源
+
+你可能会想，老乔是在吊人胃口吗？在「专业成长」部分，不赶紧讲架构设计，反而去讲所谓的架构决策能力。
+
+事实上，回顾这些年的管理经验和见闻，我认为架构决策能力不但非常关键，而且是技术管理者最重要的能力之一，而且职级越高就越重要。
+
+2012 年初，我身在 IBM，为苏宁提供顾问服务。
+
+当时，苏宁面临一个重大的架构决策问题：是继续沿用 ESB（企业服务总线）架构，还是转向分布式架构。
+
+在今天看来，这个问题或许不需要讨论 —— 很多企业都在拥抱分布式架构，放弃 ESB 架构。但在当时，苏宁是更倾向于继续沿用 ESB 架构的。
+
+因为在苏宁的技术架构内，是存在 SAP 服务和一些异构系统的，不能直接弃用 ESB，选择分布式等于同时维护两套系统。
+
+但我坚定地支持采用分布式架构，理由有很多：
+
+1. ESB 是一个集中点，风险非常大； 如果选择  ESB  架构并且让其承载大量的业务逻辑（系统间调用的处理逻辑），后续转型困难；
+1. 系统内虽然存在部分异构系统，但大部分是同构系统，分布式系统完全可以支撑；
+1. 在分布式架构中，不同服务可以直接访问，无需像 ESB 架构一样经过负载均衡系统和网络交换机，避免了资源的浪费；
+
+……
+
+虽然理由很多，但在工作性质上，我属于乙方，是企业外部人员；而持反对意见的是甲方，属于企业内部人员。大部分情况下，乙方不会在这种问题上和甲方争执到底 —— 如果甲方已经有非常明确的倾向和意见，那就顺从甲方，不是挺好的吗？
+
+但我知道，架构决策事关重大，所以坚持表达了意见。最终，苏宁的 IT 系统也顺利转型为分布式架构，没有走上歧路。
+
+最让我庆幸的是，2015 年我加入了苏宁。如果当初没有坚持转型分布式架构，三年之后，就会有一个庞大、臃肿、高风险的“烂摊子”架构在等着我收拾，那该有多么痛苦？
+
+说了这么多，并非是要突出自己聪明。恰恰相反，我相信人人都很聪明，也非常专业，但如果在一个重要的架构决策失误了，企业就可能需要花三年、五年甚至更久的时间来“还债”。
+
+你看，其实很多所谓的“技术债”，也就是由一次次的决策失误不断累加而成的。
+
+那么什么是架构决策能力呢？简单来说，就是当团队因架构方案的选择，出现争议、迟迟不能决定时，管理者需要具备的、一锤定音的能力和方法。
+
+新架构多久落地，说到底只是个效率问题。但如何拍板确定新架构的设计，则是重要的方向性问题。如果方向不对，那么无论团队里有多少精兵猛将，也只能跟着漫无目的地瞎忙，这就是所谓的“一将无能，累死三军”。
+
+## 选择“不作为”，往往更加可怕
+
+说句公道话，很多管理者虽然会出现决策失误，但至少做了决策，使业务在一定时间内可以维持增长。最不靠谱的是，管理者选择不做决策，导致团队工作无限期阻塞，严重影响业务发展。
+
+举个例子，有两个团队成员坐在会议室里，争论两个架构设计方案孰优孰劣。他们各执一词，谁也说服不了谁。这时，你作为技术管理者，应该怎么办？
+
+我大概见过三种处理方式：
+
+1. 给大家分析哪一种方案更好，现场拍板；
+1. 指出当前双方考虑不周到的地方，再给大家时间去准备，并在 Deadline 前决策拍板；
+1. 泛泛地对大家说：“不够具体”、“没有重点”，“再回去想想”……
+
+第一种、第二种其实都是正确的处理方式，建立在管理者内心已经有答案、有见解的基础上，前者追求决断效率，后者看重团队培养，都很棒。
+
+但第三种就有点值得玩味了。很多时候，这代表某种“职场生存技巧”。表面上，管理者希望团队多多思考，但实际上，他是自己没想明白。至于接下来，无非是一个字：拖。
+
+有些方案或项目甚至因此延期半年以上，这对于一家企业来讲是非常危险的。
+
+所以，在这一讲的开始，有一个关键认知，我一定要同步给你：
+
+**一把手是团队的天花板，并为团队的所有问题负责。**
+
+作为管理者，尤其是前几年，我经常用以上认知告诫自己。映射到架构决策层面，也就是一把手一定要有勇气在方案之间做取舍，并承担相应的后果。
+
+当然，架构决策也不能乱做，千万别说：乔老师说了，要敢于做决策，然后闭着眼睛挑了一个答案……
+
+关于架构决策，其实是有一套意见反馈和流程模板的。
+
+## 做好架构决策的流程和模板
+
+当管理者需要做架构决策时，就意味着至少有两个、三个甚至更多架构方案摆在面前，各有利弊，需要高层协助决策。在苏宁时，我还为此建立了一套架构决策流程，决策流程如下：
+
+1. 当事人发起架构决策申请；
+1. 由产品负责人判断：该申请是在产研中心部门内协调解决，还是上升至 CTO 办公室解决；
+1. 在产研中心部门内，或联合 CTO 办公室，完成架构评审；
+1. 将结果发还至当事人征询意见；
+1. 由当事人判断是否仍有疑虑，需要进行架构仲裁；
+1. 若需要则发起仲裁会，解决分歧；若不需要则结案归档，执行决策。
+
+过程中可能涉及的参与人包括：产品负责人、技术负责人、架构师团队、架构负责人、CTO 办公室负责人等。如果是部门内协调解决，则 CTO 办公室不参与评审；如果评审后仍有分歧，则 CTO 办公室连同其他负责人一起介入架构仲裁，快速解决问题。
+
+你可能会想，设计这么长的流程和表单，难道不是人为地加长决策周期吗？有点不太“敏捷”啊。
+
+没错，只要涉及到新增制度、新增流程，无论考虑得多完善，都会降低团队敏捷度 —— 初创团队几乎总是动作最快的，万人大厂相对来说就要迟缓一些。因此，在管理小团队时，我可能不会推行以上决策流程，因为我的精力足够覆盖团队每一次重要决策；但对于大型企业来说，上述制度就开始变得非常重要。
+
+同时，我们也要认识到，用体系化的解决方案解决组织问题，是正确的认知。但体系化的解决方案一旦在实际工作中开始落地，也非常容易“变形”。**在上述决策流程里，最困难的不是架构评审和架构仲裁，而是向下推进的动作和速度。**
+
+越是高级管理者，日程排得越满，越难约时间开会。决策流程一旦涉及到 CTO 级管理者，推进速度就可能变得非常慢，这在很多企业都是切实存在的现象。
+
+我的解决方法，是回到我们专栏的第二章第二节：《管理者最重要的三个任务（二）：加强组织协同效率》，坚决落地日历协同的文化和工具。当团队做好日历协同时，只要管理者某一时段的日历是空白的，就可以预定会议，对组织全体适用。若有特殊情况，单独沟通。
+
+所以你看，任何策略、体系化的解决方法，都很难脱离企业文化而独立存在。有一句话说得好：文化吞噬策略如早餐。
+
+管理者要优先配合下属做好架构决策，反过来，下属也要进行细致准备，节约时间、提升效率。在架构评审发起前，发起人最重要的工作之一，就是填写和提交一份意见反馈表单，表单内容大致如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/11/05/11f313a7698c1c4566d4ace1d7659a05.png" alt="">
+
+通常，当你看到这份表格，很可能会最先注意到「业务需求」、「可选方案」、「决策结果」和「决策理由」等关键字。毕竟，这几项直接构成了基本的决策流程，确实非常重要。
+
+但是请注意，当整个决策流程完成时，表格中每一项都应该被填满，没有例外。我们先来看看，表单其他部分的设计目的：
+
+- 从「待决策内容」到「决策申请编号」，这部分内容是为了更好地将决策事件归档，以备以后参考、调研、借鉴；
+- 「假设条件」是为了注明可选方案的依赖条件，以免出现建设“空中楼阁”的情况；
+- 「重要性」的标注是为了提升决策效率；
+- 「因决策而产生的需求」和「其他相关决策」，则是确保决策可以落地。
+
+不过具体到表单的某一项，模板中是没有字数限制的。填写意见反馈表的标准是：逻辑清晰、完整，能让他人能够准确理解。
+
+相比决策流程，这张表单的泛用性可能更高，作用也非常关键，我认为大概有四点：
+
+第一，这套流程和意见反馈模板，可以让当事人及各参与方，做好充分的思考和准备，避免浪费大家的时间；
+
+第二，所有分歧会落实到纸面上，能防止沟通出现歧义，也预防推诿、扯皮的现象发生；
+
+第三，可以培养所有人的大局观和架构决策能力，间接推动人才梯队建设；
+
+最后，用体系化方案解决团队问题，追求的是“一劳永逸”地解决问题。
+
+**更重要的是，无论是流程还是表格，都不仅是一样工具，更是一种思维模式**。越早养成这种思维模式，对个人成长的帮助越大。如果你能在思考、验证后，将其沉淀为文档，相信有一天，你也能起草适合自己公司和业务的架构决策模板。
+
+写到这里，我不得不承认：即便拥有了架构决策流程和模板，要高效率地进行正确的决策，对于管理者而言，依然是个巨大的挑战。各领域、各方向的架构设计往往有其独特的一面。尤其是业务架构的设计，可能还会掺杂一些“历史原因”。如果不是代码维护者，几乎很难讲清楚业务逻辑。
+
+这时，管理者怎么做架构决策呢？
+
+## 技术管理者如何做好架构决策
+
+我认为，要做好架构决策，管理者至少需要具备两项特质。
+
+**第一项特质：要学会站在全局视角看待问题，学会看到技术架构的“外部价值”**。这种“外部价值”包括：公司利润、人效、资源利用率、业务风险，等等。
+
+说到这里，请你暂停并回想一下：在这一讲的开头，我提到了 2012 年在苏宁完成的架构决策：在 ESB 和分布式架构之间，我选择了分布式架构。这个决策具备哪些“外部价值”呢？
+
+这是个有关企业技术平台的架构决策，所以和收入、利润的关联度都很小。但分布式架构确实大大降低了业务风险，也在系统交互层面提高了资源利用率。这些都是非常明显的优势。
+
+但如果只能看清“外部价值”，也不能让技术管理者做好架构决策，否则一个不懂技术的 CEO 才是最好的架构决策者。
+
+这就要求决策者具备**第二项特质：具备相当的技术深度，以及非常好的学习能力和逻辑思维。**
+
+时隔 8 年，今天再谈起在苏宁选择分布式架构的往事，总是有点云淡风轻。但在背后，是一箩筐的技术细节：你要知晓 ESB 和分布式架构支持同构、异构服务时，各自的优劣势；你要知晓两者通过 TCP/IP 和 IP 协议交互所带来的效率区别；你要知晓 ESB 架构中，负载均衡系统和交换机的存在，以及由此而来的资源浪费，等等。
+
+在前面的内容里，我们一直强调做 “T” 型人才，其中一个重要的原因就在此时得到了体现：有一条足够深入的技术栈，是你前进的巨大倚仗。
+
+那么，是不是分布式专家就只能参与分布式架构的决策呢？当然不是，CTO 几乎不可能成为真正意义上的全栈技术和架构专家 —— 在一个梯队建设较为成功的企业里，走技术路线的下属，几乎总是会在某一专业领域胜过你。
+
+这时，管理者的学习能力和逻辑思维就会派上用场。做架构决策时，我们要求写好意见反馈模板，其中一个重要意图是让当事人将架构背后的逻辑讲明白。
+
+而管理者要做的就是：通过下属的表述，快速理解业务和架构逻辑，短时间内成为这一细分问题的专家，然后进行决策。
+
+“只要你能讲清楚，我就一定能掌握”，如果通过坚持不懈的练习，养成了这一专业素质，管理者将在架构决策方面无往而不利。
+
+你可能会说，老乔啊，我们团队的成员，嘴都比较笨，真的是说不明白。没关系，管理者可以多加引导，一个很好用的小技巧是：引导对决策存在分歧的双方，就方案合理性互相“攻击”。
+
+你可以要求当事人 A 首先阐述方案，并进行提问，比如：你凭什么说这个方案就能节省资源？在当事人 A 回答完之后，询问当事人 B ：你对他刚才的阐述难道没有疑问吗？
+
+这样一来二去，方案背后的逻辑就会更加清晰，管理者也就更容易进行决策了。
+
+## 结语
+
+今天，我们聊了聊有关架构决策的认知、体系框架，以及高层管理者需要具备的基本素质。
+
+对于初级管理者来说，要尽早培养自己的架构决策能力，尤其重视思维模式的培养、个人技术栈的深度扩展以及逻辑思维能力的锻炼。
+
+对于高级管理者来说，则要做好认知层面的储备。很多 CTO 面对下属的架构决策求助，回复都是“我忙着呢，过两天吧”、“你自己再想想，晚点再说”。
+
+高级管理者不能总是瞎忙，如果你真的意识到，架构决策是技术管理者最重要的任务之一，就一定会为类似的决策会议腾出时间。
+
+拖延做决策的管理者，要么是不懂，要么是战略懒惰，很少有第三种情况。而所谓“战略懒惰”，常常表现为管理者自己冲到一线“拼杀”，却对团队的方向性问题反应迟钝。
+
+当然，做管理的时间一长，确实也会怀念“带队冲锋”的感觉，我觉得没什么问题。但要注意，“冲锋”这个动作，一定发生在战略决策之后。而善于做决策，又敢于冲锋的管理者，在现代商业环境中，一定大有可为。
+
+好了，关于架构决策，我们就聊这么多。
+
+让我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对专业成长的复盘/18 | 架构设计，专业分工和协作精神的体现.md

@@ -0,0 +1,146 @@
+<audio id="audio" title="18 | 架构设计，专业分工和协作精神的体现" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/43/21/43120070dyy6139e04b7858c4b8ffc21.mp3"></audio>
+
+你好，我是乔新亮。今天，我想和你聊聊，关于架构设计的一些认知和体会。
+
+作为技术人，最常接触的概念，恐怕就是架构设计了。即便是初出茅庐的新手程序员，可能也听说过 6 大设计原则与 23 种设计模式。因为，要成为管理者或技术专家，架构设计绝对是你绕不开的槛。
+
+因此，关于架构设计的书和课程非常多，多到简直学不完。如果用我们专栏文章的形式来讲，写出一百篇文章都不为过。
+
+但在今天，我们只聊一点认知，我认为，也是架构设计最核心的认知：**好的架构设计，就像优秀的组织协作一样，既能帮助 IT 系统做好各模块的专业分工，又能体现模块间的协作精神**。
+
+认知讲完了，是不是感觉有些熟悉？
+
+没错，其实在很多架构设计思想里，我们都能找到这句话的影子，比如“高内聚、松耦合”、“单一职责原则”、“接口隔离原则”，太多了。
+
+你可能会想，老乔坑人呢，作为一个 CTO ，在架构设计这一讲，就交付了一个这么基础的概念。
+
+没错，这个概念确实很基础，但我想告诉你，其实架构设计，尤其是业务/应用架构的设计，原本就没有那么复杂。
+
+工作了近 20 年后，我发现，如果一名架构师存在职业发展瓶颈，那么他的问题大概率是简单的设计方法没有执行好，而不是复杂的设计方法没学会。
+
+复杂的学会了，简单的却没做好，听起来很奇怪吧？下面，我们详细聊聊，这究竟是怎么一回事。
+
+## 从程序员到架构师，什么能力在提升？
+
+2020年，刚到彩食鲜的时候，我去审查团队技术需求的分配和实现，发现了一些不合常理的情况：对于部分业务流程改造工作，我认为很容易实现，团队却需要花费大量的时间才能落地。几天就能改好的代码，花掉一个月的时间都是有可能的。
+
+有时，团队甚至会觉得，单是为了实现需求，就已经很吃力了，从整体的逻辑上看就很不合理。
+
+仔细一查，我才发现问题的根源所在：表面上看，是逻辑不合理，实际上是架构设计不合理。
+
+生鲜/电商类业务的架构一般会包括 OMS（订单管理系统）、WMS（仓库管理系统）、TMS（运输管理系统）等系统。其中 OMS 处理用户订单，负责调度；WMS 负责仓储管理；TMS 负责安排物流运输。可以看到，其实功能的划分很明确。
+
+但很多业务在研发迭代时，并没有做过架构方面的考量，比如将与订单相关的逻辑直接放在 WMS 处理了：WMS 接到 1000 斤蔬菜的订单，检测仓库内只有 500 斤，于是发送请求到采购系统，要求再采购500 斤回来，然后将订单交付。
+
+这样的逻辑能保证功能实现吗？当然可以，但长远看来，就会出现架构层面的设计问题 —— WMS 越来越臃肿，最终导致新需求的处理速度严重下降，影响业务的增长，这就是很多企业正在为之头疼的现实。
+
+你可能会想，这个例子里的架构师真傻，连 OMS 都不知道。
+
+真的是这样吗？事实上，类似的错误，很多企业每天都在犯，尤其是 IT 服务于自身生态的甲方企业。大家习惯于基于业务需求写代码，而不是基于架构设计写代码，反正来了需求先实现了再说，尤其是在业务刚刚起步时。
+
+比如，在业界，你会发现一个很普遍的现象：许多企业投入大量的资金和人力进行 IT 建设，但每隔几年就要进行一次架构上的大调整，甚至直接推翻重写。
+
+大部分人甚至已经习惯了这种行为，觉得重建很正常，而且是一名架构师能力的证明。
+
+事实上，如果架构师严格按照“专业分工、充分协作”的思想去迭代需求，这样的重建根本就不应该出现。**一名优秀的架构师应该像个“隐形人”，似乎什么都没干，但其负责的架构就是能快速响应业务的需求。**
+
+什么叫做“快速响应业务的需求”？就是说，在同样的业务复杂度下，在系统建设的不同阶段，可以使用相近的工作量完成需求。
+
+那么，所谓的“专业分工、充分协作”，到底是做了什么呢？回到架构设计实践里，无非是一个先拆分再合并的 “V” 字型设计过程。
+
+拆分是指将一个负责的功能按角色、按职责拆分，核心特征是单一模块的功能既单纯又简单。比如，要从零实现一个淘宝网，是相当复杂的事。但我们可以将其拆分成订单中心、用户中心、商品中心、库存中心等许多模块；订单中心还可以再拆分，比如拆分成订单创建、订单查询、订单履约等功能；如果实现仍然复杂，我们还可以继续拆分，直到能够用简洁优雅的代码去实现。
+
+合并是指将类似的职责放在一个模块完成，抽象出可重用、复用的部分，提升业务响应效率。比如订单创建、订单查询都需要对数据库进行操作，那么与数据库的交互就应该统一封装。
+
+**抽象地看，架构是由元素（element）和关系（relationship）组成的。在架构设计中，那些稳定、可复用的部分应该变成组件或应用模块，对应着架构中的「元素」；而面向不确定性的设计，则需要变成协作方式，为可能的扩展作准备，对应着架构中的「关系」。**
+
+这就像一个足球队，有人司职前锋、有人司职中场、有人司职中后卫，分工明确才能组成一个有战斗力的队伍；中场可能回撤参与防守，后卫也可能前插参与进攻，这样才能对可能的变化作出响应。
+
+如果什么设计都没有，就只能变成一群追着球玩的小孩。
+
+那么「元素」是拆分得越细越好吗？当然也不是，5 个模块能搞定的功能，你非要写 100 个模块，只能是给自己徒增烦恼。
+
+所以，从初级架构师到高级架构师，什么能力是一直存在并持续提升的？其实就是对复杂业务的拆分能力、对可复用部分的抽象能力、对拆分过程的颗粒度把握，以及对未来变化的考量和设计。如何让架构有足够的“应变能力”，则与架构师对业务的理解程度息息相关。
+
+如果用一句话总结，那就是：**对架构层面的「专业分工」和「协作精神」的理解，是一名架构师的基础与核心能力。**
+
+## 认知延伸：如何看待微服务和中台架构
+
+你可能会想，老乔讲的对是对，可有什么用呢？
+
+别急，我们通过前面讲的架构设计思想，反过来看看近几年大火的微服务和中台架构。
+
+关于微服务，首先我们要知道，它的功能和数据处理是封装在一起的，这和  SOA  架构非常类似；其次，服务交互、服务治理、服务监控、服务隔离等很多基础性能力已经封装在框架中，可以让开发团队聚焦在功能实现上；再者，通过和 Kubernetes 集成，微服务的功能、数据、基础设施被再次封装，技术架构也再次进行了升级。
+
+看得出来，在微服务框架下，技术架构部分的很多职责已经被抽象出来，并对框架进行了处理，隐含着相关理念的最佳实践。
+
+同时，微服务也有一个很基本的原则：**让系统的分工更明确、责任更清晰**。所以你看，还是我们上面讲的那些内容。
+
+对于业务侧架构师来说，即便是使用了微服务架构，工作还是会集中在架构设计方面，比如：业务功能如何进行归类。具体到微服务改造的过程中，就会碰见一个典型问题：微服务拆分的颗粒度怎么把控？微服务，英文 MicroService，划分粒度一定要很细吧？
+
+其实这个问题压根没有统一答案，为什么？因为我们前面讲过了，即便没有微服务，架构师也要做功能的拆分，至于对颗粒度的把握，既受业务本身的特性影响，也受架构师的能力影响。
+
+换句话说，一名对架构的“分工”和“协作”理解得足够好的架构师，很少会困惑于微服务拆分的颗粒度问题。因为从本质上来讲，这些都是一码事。从单体应用到各功能独立服务，其实是处于功能拆分的两个极端，但**架构设计本质上是一种“中庸思想”，如果单纯考虑功能设计，我们的目标只有一个：让架构响应业务调整的速度更快。**
+
+那么架构如何才能实现更快的响应速度呢？就是在**保证各「元素」职责清晰的情况下，抽象出稳定的功能或组件，用业务流程去串联起来**。在一定时期内，一家企业的技术架构的功能或者组件基本是稳定的，而业务如何运转，却是动态变化的，甚至每周都在变。可以说，以不变应万变是架构设计的精髓。
+
+这个设计思想又和中台架构如出一辙。企业搭建中台，最重要的目标之一，就是实现企业营收层面的“开源”，承担企业架构快速响应市场需求的任务。其关键词包括：消除烟囱、架构解耦、统一中台、服务重用……
+
+没错，和我们前面谈的架构设计核心思想又是基本一致的。
+
+关于中台，业界很多技术人都踩了不少坑。刚开始听说中台概念的时候，大家一拥而上，做得多了才发现，中台到处都是坑。以至于在当下，许多人对中台是嗤之以鼻的。
+
+为什么呢？我认为很重要的一个原因，是大家忘了架构设计的“初心”，错认为中台是个全新的设计理念。
+
+其实从架构的视角看，中台这个概念并不新鲜，它只是突出了“可重用部分的抽象”这部分工作。那么， 如果你的 IT 系统可复用部分不多、业务量不高，建设中台的意义何在呢？如果你的中台对业务没有帮助，建设中台的价值如何体现呢？
+
+**你看，时刻牢记架构设计的核心原则，能帮助我们更清晰、更透彻地看待当下的许多“时髦理念”**。
+
+当然，这里可不是说，中台的兴起，就是一群不专业人士的狂欢，绝对不是这样的。苏宁在 2012 年就开始中台建设，2013 年上半年完成。后来在利用中台接入天猫业务时，团队仅花了七天七夜的时间就完成了融合，速度非常之快。
+
+关于企业数字化转型、中台建设，我在公众号里，曾经分享过一个系列，共 9  篇文章，用大概  4  万字左右的篇幅，描述了一个关于中台的“[指挥官体系](https://mp.weixin.qq.com/mp/homepage?__biz=Mzg2NjI1MDk0NQ==&amp;hid=8&amp;sn=5098693d64a4e0ebbffc79829e375ce9&amp;scene=1&amp;devicetype=Windows+10+x64&amp;version=6300002f&amp;lang=zh_CN&amp;nettype=WIFI&amp;ascene=1&amp;session_us=gh_29a69e00e273&amp;pass_ticket=%2FTbRTIlXcJMcB%2B3ejcKbOJV9JSakqAQOodTiZPotxt0lh0RHK1FjS7uTtMyRns2s&amp;wx_header=1&amp;uin=MjI1OTA5NDUwMQ%3D%3D&amp;key=07730a946a3186fb96024f450086917d0fb6060e575afb1a958a5395b9a2fdf7dd49ffb49246e3292e44f5c4d6df32c8404254b20c20916f1492a07d04383b033e00f7070c2accc32a69a32f86fddb41ef0731742508878a645f3cb54793b67182c0fc6a77a3ca2045cd5d28ff70e8a4bba24d2c636684a8dc17de141f895405)”，大家可以读一读，理解下中台和微服务设计的具体内容。
+
+**所以，无论是微服务还是中台，都有其巨大的实践价值，但二者只是架构设计核心原则的一种成熟的实践模式和承载方式，不是解决架构问题的“灵丹妙药”。**
+
+简单来说，如果你能按照架构设计的核心原则，做好模块拆分，那么微服务架构可以非常好地承载这种设计思想，为你提供服务治理、监控等一系列工具。但如果你在架构设计层面就做不好拆分，微服务也不能直接帮你解决颗粒度问题。
+
+如果你问我，老乔，我没有“专业分工”的设计意识，也做不好功能的拆分，是不是用了微服务就搞定了？我只能回答，怎么可能呢？天底下没有这样的美事。
+
+## 复杂架构设计如何落地执行
+
+下面我们再来聊聊，复杂的架构设计究竟是如何落地的。
+
+在  IBM 工作的那段时间，我曾经内部分享过一门专业架构师培训课程，包括为期 5  天的 Enterprise Architecture（企业架构）培训课程、为期 3  天的 Architecture Thinking （架构思维）培训课程、为期 3  天的 Component Modeling（组件建模）培训课程，以及为期 3  天的Operation Modeling （运营建模）培训课程。
+
+我尽量用最简单的方式，将功能性架构设计中，最简单直接的方法和步骤抽象总结出来，分享给你，其中也包含了少数我们上面提到的内容。
+
+1. 关键认知：在个人视角里，整个世界都可以按照确定性内容和不确定性内容做简单区分；
+1. 架构将其抽象为元素和关系，元素对应着确定性内容的处理，是看待这个世界的稳定视角；关系对应着不确定性内容的处理，是看待这个世界的响应视角；
+1. 人类的理解能力有限。包含内容过多的元素，会导致理解困难，需要将其拆分；
+1. 同理，将元素归类的时候，也不能贪多，不然会导致理解困难。优秀的架构师，会将合理数量的元素进行归类，归类后的整体一般被称作 component  或  module，也可以直译为“组件”。比如，我们永远以“元素数量为 10 ”作为一个衡量点，只要一个组件包含的元素/职责超过10个，就要进行拆分；
+1. 元素归类一般采用 “V” 字型分析法，即流程分解为功能，功能聚合为组件；
+1. 如果组件明确了，意味着职责就建设好了，架构的元素（element）建设问题就解决了。组件对外暴露的能力，我们统一称之为服务；
+1. 那么，架构的关系（relationship）建设问题该如何解决呢？稳定的关系，用来表达确定性的交互，使用  SOA  架构，做好服务调用就可以；不稳定的关系，用来表达不确定性的交互，使用  EDA  架构；
+1. 在每一个新需求到来时，尤其是大版本的更迭，架构师需要介入产品经理和程序员的沟通中，判断新需求是否大幅增加了某些组件的复杂度，并决定是否调整组件职责，或对现有组件进行拆分。所以，从实际的业务发展来看，组件的数量是逐步增长的，如果一开始就很多，基本属于过度设计；如果业务复杂度已经翻倍了，组件数量却没变，基本属于缺乏设计。
+
+那么以上就是落地复杂架构设计时的一些关键认知，要结合前文的阐述，多多体会。如果有疑惑，欢迎留言提问。
+
+## 结语
+
+今天我们聊了聊架构设计的核心理念：专业分工和协作精神，具体来讲，就是做好功能的拆分，抽象其中可复用的部分，并保留面向未来的扩展空间。
+
+这里我们聊的仅限于功能型架构的设计，关于高性能、高可用、高并发、风险控制等非功能型架构设计，我们将在后续内容里逐渐展开。
+
+我猜，即便看到这里 —— 这一讲的结尾，你可能仍然会想：这个理念是不是太简单了。
+
+其实很多知识恰恰是这样：说简单也简单 —— 容易理解，也容易操作；说难也难 —— 即便是首席架构师、技术总监，可能也还是会被类似的问题困扰，重复犯类似的设计错误。
+
+究其本质，在于我们要用发展的眼光，看待个人成长、架构设计这类相对宏伟的命题。就像我常常说的，要做时间的朋友。
+
+做架构设计的同学都知道，罗马不是一天建成的。同样，对架构设计核心原则的理解，也不可能在一年、两年内达到满分，这种理解往往会随着技术人的成长而持续加深。
+
+其实，人类在解决很多复杂问题时，都会采用类似的思维流程：**将复杂问题拆解为简单问题，逐一解决再合并，并将可复用的知识抽象，以实现举一反三**。我们今天所聊的架构设计，其实就是这种思想在软件设计层面的复现。
+
+希望你也能将这个看似简单、实则复杂的知识点吃透、嚼烂，最终做到返璞归真，成为一个优秀的架构师或技术管理者。
+
+我们下一讲再见。

极客时间专栏/乔新亮的CTO成长复盘/对专业成长的复盘/19 | 产品思维，契约精神是基础，洞察人性才能成就卓越.md

@@ -0,0 +1,152 @@
+<audio id="audio" title="19 | 产品思维，契约精神是基础，洞察人性才能成就卓越" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a5/44/a5350f72a4bafd07f62230yybb188e44.mp3"></audio>
+
+你好，我是乔新亮。今天，我想和你聊聊，如何培养产品思维，以及我个人与之相关的复盘和思考。
+
+多年以前，我其实也没什么所谓的产品思维，主要的工作还是做好架构设计、解决方案，做什么产品呢？
+
+后来，我的职位越来越高，也逐渐开始为公司的业务发展负责，我逐步意识到：产品太重要了，对于高级管理者很重要，对于 IT 组织的每一个人都很重要。
+
+为什么呢？要解释这个问题，我们首先要聊聊产品的企业价值和个人价值。
+
+## 产品，是企业及个人价值的最好载体
+
+你可能还记得，在「管理复盘」的第一讲，我们就提到：要将职能型组织转变成产品型组织。为什么要这样做呢？因为对于企业而言，做需求重在“过程”，做产品重在“结果”，**产品是企业对外提供服务的载体，也是企业核心竞争力具象化的载体**。
+
+许多投资人、企业家，都喜欢聊「竞争壁垒」这个概念，比如：腾讯在社交、文娱等行业有强大的竞争壁垒；阿里巴巴在电商领域有强大的竞争壁垒。几乎所有的大厂都有壁垒，导致新兴势力很难与之掰手腕。
+
+但这个神奇的「竞争壁垒」，具体是指什么呢？很多书中都有解读，「壁垒」可能包括品牌效应、规模效应、网络效应、要素垄断等，但因为涵盖的要素太多，反而让人难以理解。如果我们尝试从另一个维度看，问题可能瞬间就会变得清晰：对于企业而言，所谓「竞争壁垒」，主要指代的其实是产品。
+
+作为一个整体，企业有对外提供服务的产品，也有对内提供服务的产品。而且外部产品、内部产品可以互相转换。**一般来说，随着产品能力的提升，内部产品有机会演变为外部产品。我认为，这也是培育公司“第二曲线”业务非常切实可行的办法。**
+
+举个例子，阿里孵化了自己的技术平台，那么平台成熟后，就成为了属于阿里的 IT 基础设施类产品；Netflix API 做得好，那么就成为了 API 产品，不但可以服务内部，还可以对外售卖；再比如，许多大厂人才梯队建设的好，那么相应的选用育留方法论，也可以构成产品；一些公司擅长生产内容，就可以形成内容产品，比如 QCon 、ArchSummit 、GTLC 大会。
+
+以上所有产品，需要时间来迭代，需要持续耗费人力、物力进行打磨，就会逐步形成企业的竞争壁垒。因为在这一垂直领域，相较于同阶段的其他竞争对手，你已经占据了巨大的先发优势。
+
+说完了企业价值，其实产品的个人价值也就凸显了。
+
+在大部分时间里，个人价值来自于企业价值的增量部分。如果你所做的工作，对企业的成长没有任何的帮助，是不可能跨越成长台阶的。所以，团队中的每一个成员，都要为了创造企业价值的增量而努力。
+
+那么长期看来，企业价值如何体现呢？答案是做产品，所以企业里的每一个渴望成长的人，都要学着做产品，都要有产品思维。这是我一直提倡的一个简单逻辑。
+
+有些人会说，没有产品思维我不一样写代码、做架构？
+
+这话说得没错，如果只想老老实实的做个企业的“螺丝钉”，做个普通的程序员、测试人员、架构师，确实没必要培养产品思维；但如果你追求个人成长、追求卓越，就必须具备产品思维。
+
+## 培养产品思维的核心脉络
+
+大道理讲完了，那么究竟该如何培养自己的产品思维呢？
+
+大部分人的第一反应是去找一堆产品经理的书来看。可看着看着就有点懵：书里举的例子要么是 iPhone，要么是微信，让人忍不住感叹：天才的乔布斯，神奇的张小龙。可书里的故事很传奇，现实工作却很骨感，专业名词学了不少，就是用不太上。
+
+没错，对于大部分技术人来说，培养产品思维的目标在于重构自己的部分认知，并把它应用于自己的日常工作、生活中，不一定非要成为乔布斯，或是独立开发一个爆款 APP。
+
+那么，我们如何用简单、实用的认知，构建自己的产品思维呢？
+
+我个人认为，**有两个关键词最重要，一个叫做“契约精神”，一个叫做“洞察人性”，前者让你拥有入门级的产品思维，后者让你可以成为卓越的“产品经理”。**
+
+所谓“契约精神”，是指工作时，要有“**一诺千金**”的意识，具体可以分成四点来理解：
+
+1. 将自己的每个工作成果都当作产品，并将产品交付或售卖；
+1. 尝试理解这个产品的用户到底是谁；
+1. 在用户付出了时间、精力或金钱后，明确你的产品到底交付了什么？又承诺交付了什么？
+1. 不惜代价信守这个承诺。
+
+比如，京东物流作为一款物流时效性产品，给用户的“契约”是“当日或次日送达（偏远地区除外）”。那么京东物流的订单系统、调度系统、仓储系统、配货系统等，全部都要为这个契约的交付而努力。
+
+再举一个例子，唯品会作为一款产品，给用户的“契约”可能是“用更便宜的价格买正版的鞋服”。那么不光是 IT ，整个企业都要为了守住这个契约而努力。
+
+彩食鲜的“契约”是提供可信赖的安全食品，那么在基地管理、采购管理、工厂加工、仓储作业、配送服务等各个环节都要确保食品安全，例如对于蔬菜批批检，信息可查询、可追溯。
+
+所以你看，企业想做好产品，关键在于每一个模块的责任人，都有契约精神。任何一个环节出现问题，都会导致企业的信誉蒙受损失。
+
+你可能会想，嗨，我知道，契约就是按约定交付嘛。是的，“契约”这个概念，本来就非常容易理解。但要注意，理解起来很容易，执行起来可就难了。
+
+就像大部分人都知道欠债要还钱，老赖却还是很多。因为信守承诺不仅仅是态度问题，还涉及能力和方法问题，需要通过明确契约、开展设计、信守承诺三步法将契约落实到位。
+
+在日常的研发或管理过程中，当 Deadline 临近时、当工作量过饱和时，你还能不能守住契约精神，将“契约”规定内容，分毫不差地交付给用户？说实话，真的挺难的。但只要你能守住底线，**把简单的事情重复做到位，就可以超过绝大多数人和企业**。
+
+关于产品思维的另一个关键词，叫做“洞察人性”。
+
+即便在最具极客文化的互联网公司里，也可能存在很多反人性的产品。比如版本发布产品，大部分公司都会将发布时间设计在凌晨，甚至需要研发和测试一起值班，确保生产环境没问题后，才可以睡觉。
+
+可是这多难熬啊！那么我们在设计版本发布产品时，能否在保证业务不受影响的情况下，让发布时间更人性化？比如根据业务流量的特性，选择其他时间进行灰度发布；比如研发建设 7 x 24 小时无人值守的发布系统，附有秒级发布、秒级回滚功能，将团队从人工监测中解放出来……
+
+总之，方法有很多，只要肯去想，就一定能提升。
+
+这还是比较明显的“反人性”设计，很多情况下，研发同学未必能意识到产品的“反人性”设计。这时，就需要我们带着同理心，下到终端环境里，和真正的用户去交流。
+
+一个好的产品经理，通常有着极强的同理心，能够设身处地替用户着想：用户在这个场景下的诉求是什么？有什么痛点？目的是什么？
+
+在这一环节，**产品经理的个人价值观不同，就会塑造出有着所谓“不同世俗意义”的成功产品**。但我一直认为：科技是向善的，产品应该让人们的生活变得更美好。某些在商业上比较成功的产品，在我看来，就是有问题的、不成功的，因为它给用户的导向是不好的。
+
+**洞察人性是要树立“以人为本”的理念，了解产品使用者的真正诉求，用户通过使用产品，会觉得自己更棒了，让自己变得更卓越。先成就用户，然后成就产品**。
+
+在彩食鲜，销售人员每个月都需要对账，所以对账系统就会成为一个标准产品。如果该产品三分钟可以完成准确对账，销售人员的工作就可以更轻松，用更多的时间挖掘客户、努力签单，让每个销售人员都更加成功；
+
+如果该产品可以实现无人值守、自动准确对账，销售人员将被彻底解放。那么，销售人员一定会觉得自己工作效率更高了，自己的工作更棒了。从公司的角度看，这也让公司的运转更加高效。
+
+我们公司的 IT 人员就是在为了这样的目标努力，并且已经卓有成效。
+
+只要守住了“契约精神”和“洞察人性”这两大关键词，我相信你对于产品的初步认知就已经形成了，对于产品知识的学习就不会盲目。
+
+了解了“契约精神”和“洞察人性”这两大关键点后，我们如何在工作中实践应用呢？我认为，有六大步骤比较关键。
+
+## 产品思维六步法
+
+看到这里，你可能会想，怎么什么都是产品啊？物流是产品、API 是产品、代码发布还是产品，老乔是不是在偷换概念啊。
+
+当然不是，我可以确定地说，一切皆产品。**实践产品思维的第一步，就是面对所有的工作，都要习惯性自问：我到底要交付一个什么样的产品？**
+
+你在做的工作，甚至你的职业生涯，都可以看作一个产品去打磨。不是只有那些 APP 、手机才可以叫做产品。唯一的区别在于，你是否愿意关注这一切的长线价值，做时间的朋友。
+
+这一认知，是让产品思维逐步成熟的第一步。接下来，还有五个步骤，我们来逐一解读一下。
+
+**第二步，明确产品的用户到底是谁。**
+
+对于外部产品来讲，要做到精准识别用户，相对比较困难，这与公司的商业模式强相关。但对于公司的内部产品而言，用户群体可能是相当固定的。你的用户可能是其他工程师、同公司的销售、同公司的财务，也可能是身处一线的物流工人、司机，认识他们、了解他们，相对来说没有那么困难。
+
+困难的是，在设计流程、写代码、做测试的时候，时刻记住这样一群人，告诫自己：我的用户，并不是我自己。与真正的一线用户聊聊产品体验，看看自己是不是感到沮丧，感到有些受挫？下终端会让自己有不一样的感受，有助于提升自己的同理心。
+
+**第三步，明确服务契约。**
+
+要明确地问自己，自己的产品，到底为用户提供了什么样的服务契约，用户通过产品实现什么样的价值？拿出纸笔写下来，看能否数字化，是否够具体。在前文关于销售对账系统的例子里，我们的交付目标要么是 99%  的销售使用 3  分钟内完成、准确率在 98% 以上的对账产品，要么是  100%  的销售使用无人值守的、准确率为 100% 的对账产品。
+
+用数字来组成契约，用 “SMART  原则”来检查契约。
+
+**第四步，将产品打磨至卓越。**
+
+我们曾经多次强调过，社会、企业、组织会更多地奖励卓越的人或事，对「平庸」缺乏兴致。做产品也是一样：只有卓越的产品，才能对你的个人成长产生牵引作用。如果你总是想着：差不多就行了，不要跟自己较劲了，那还不如直接放弃。
+
+那么，怎么在微观视角打造出一个卓越的产品呢？我个人总结了关于**卓越产品的“三个一”思考法，即“一站一键一秒”**，意思是在场景和目标确定的情况下，让用户在一个位置，点击一个按键，在一秒内达成目标。试想一下，使用这样的产品，用户一定会觉得自己很棒，这就是产品的价值。
+
+当然，“一站一键一秒”是站在微观视角来谈的，要孵化一个完整的产品，往往需要不断地将产品的微观能力进行组合，不断重复上述步骤，最后和公司的商业模式、战略方向协同，以创造产品的行业竞争力。
+
+**第五步，要习惯于成就用户，时刻谨记：以人为本。**
+
+大多数时候，在 IT 的日常研发工作中，都存在更省时、更省力、更取巧的代码或设计方法，但这些方法却未必是对用户友好的。**技术人需要时刻提醒自己，产品设计的第一驱动力应该来自于用户价值，而不是技术方案的优劣**。
+
+产品建设要以人为本，不断去寻找价值，匹配价值，成就用户。
+
+**第六步，关注数据，持续完善。**
+
+产品迭代一定要有数据，要思考如何用数据来衡量产品的卓越程度，用数据衡量产品的价值增长，用数据成就伟大的产品。
+
+最后，还是那句话：大道至简。要培养卓越的产品思维其实并不复杂，以上六个步骤都很简单。我建议你学过之后就要行动起来，在工作中实践、思考、总结，固化成自己独有的产品思维方法，持续学习、学以致用、终身成长。
+
+## 结语
+
+今天，我们聊了聊培养产品思维的关键认知和方法。
+
+遵守“契约”，可以打造一个 90 分产品。以人为本、洞察人性、使用“一站一键一秒”等方法，则可以打磨出一个卓越的产品。
+
+没有产品导向的项目建设如同没有灵魂的肉体，会让工作流于平庸；而**产品思维，本质上是一种长期的利他主义思维**。设计任何产品的出发点，都应该是让用户的生活变得更美好。当然，利他就是利己，要明白：自己的努力对于社会是有价值的，这样的人生才会越来越充实、越来越有意义。
+
+作为 IT 行业从业者，十年、二十年之后，会为世界留下什么？我想，首先应该是属于自己的、卓越的产品。我就常常想：多年以后，我可以向自己的子孙吹牛：你看爸爸做了这么多产品，让别人的生活变得更美好了。
+
+而且人生还有这么长，你怎么就知道，自己无法打造出一个现象级的卓越产品呢？只要坚持长期主义，我认为还是非常有可能的。而且我一直觉得，这是让一个人坚持克服困难的最大动力。
+
+我常说，人生是一场修行，选择一个职业，在其中经历磨难，领悟人生的道理，最终殊途同归。我建议你如果有时间，也可以去慢慢琢磨、领会这个道理，因为那种融会贯通的感觉是非常美好的。
+
+最后，预祝你能持续打造一个又一个的卓越产品。
+
+我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对专业成长的复盘/20 | 高可用设计，让产品没有后顾之忧.md

@@ -0,0 +1,137 @@
+<audio id="audio" title="20 | 高可用设计，让产品没有后顾之忧" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1f/a9/1fd581c97f5be851cd9ac8dcb86336a9.mp3"></audio>
+
+你好，我是乔新亮。这一讲，我想和你聊聊，关于高可用设计的那些事儿。
+
+一提起高可用设计，很多同学立刻就会想到“冗余设计”、“故障转移”等关键词。确实，在大部分与高可用相关的分享里，这两个词往往会被重点强调。
+
+所谓“冗余设计”，是指要通过集群来替代单点服务，做好冗余备份。单点架构是高可用的大敌，“把鸡蛋放在不同的篮子里”是高可用最朴实、最有效的设计思路之一；“故障转移”则是为了缩短故障时间，保证故障发生时，业务可以快速恢复。
+
+如果你对高可用设计了解得更多，可能还会给出如 “CAP 理论”、“异地多活”、“双机架构”一样的更多概念，并且详细解释应用方法。
+
+像这样面对问题，能立刻在大脑知识地图中检索并给出应对举措或方案，是一个优秀的特质，能帮助你通过许多高难度面试。但不知你有没有想过，**为何自己在面试中对答如流，在实际工作中却仍然会遇见许多高可用难题呢？为什么还是无法主导一家大型企业整体架构的高可用设计呢？**
+
+问题或许是多方面的，比如企业现阶段的发展状况特殊，缺乏实战机会，导致个人资历不够；或者相关部门不太配合，组织人员能力差，代码 Bug 太多，让你一想就气不打一处来……
+
+以上原因都有可能，也都客观存在于很多公司。但我认为，最重要的原因是，缺乏对高可用设计自顶向下的、比较通透的理解和认知，因而在实践中常常迷失在技术细节里，难以窥见架构的全貌。
+
+那么这一讲，我们就来尝试一下，看能否通过一些简单的梳理，建立对高可用设计的完整认知。
+
+## 解剖高可用设计
+
+在架构设计部分，我们讲了：粗略地说，想做好架构设计，第一步是将一个 IT 系统从应用层级至底层基础设施，全部拆解为一个个应用模块，我们也可以称之为“元素”或“组件”；第二步是保证各个模块间不能孤立存在，还要做好充分的协作，协作通过应用模块对外暴露的“服务”来承载，我们也可以称之为“连接”。
+
+所以说，应用模块和服务，或者叫做元素和连接，共同组成了所谓的架构。那么，要实现架构的高可用，就意味着实现所有元素、连接的高可用。
+
+至此，其实我们已经得出了一点非常重要的认知，再重复一遍：**真正的高可用，是指实现所有元素、所有连接的高可用。只要一个元素或一个连接没有做高可用设计，都意味着风险的存在。**
+
+比如，公司要求每天必须按时上班，只要迟到就罚钱，那么你如何保证自己的“出勤系统”是高可用的呢？一定是全链条做高可用设计。闹钟至少有两个——互为主备、要保证衣物都在、要为堵车准备预案、要保证高峰期能挤上电梯……你甚至得保证身体健康，不然可能因为拉肚子而迟到。
+
+要注意，在这个例子里。闹钟可能不响、堵车可能会发生，没问题，只要在老板眼里，你永远按时打卡就行，只要整个系统是高可用的就好。**更准确地说，所谓高可用，是要保证“业务的连续性”，即在用户眼里，业务永远是正常（或基本正常）对外提供服务的。**
+
+怎么样，是不是有点难？是的，在实际工作中，大部分企业的架构设计没有做到高可用，原因可能只有两个：
+
+1. 相关负责人压根儿就没考虑高可用设计；
+1. 做全套高可用的代价太大了，钱不够用，时间不够用。
+
+先前有位同学在专栏下方留言说，乔老师传达的理念就是“**trade-off**”。我一看，禁不住为他鼓掌喝彩——说得太对了。在企业层面，很多难题不是“简答题”，而是“选择题”。所以在专业成长这一章，我们会先讲“架构决策”，再讲其他内容。
+
+其实人生也如此，职业生涯也如此，如果都有唯一的正确答案，那太简单了。很多教程回答的都是“唯一正确答案”，听着很有道理，实际做的时候，发现根本不是这么一回事。
+
+作为成年人，我们必须得清醒地认识到，人生这道选择题，根本没有标准答案，你能做的只有在不完美中寻找完美，不断trade-off。
+
+做好决策，在很多情况下，并不意味着风险就消失了 —— 风险始终存在。根据墨菲定律，如果事情有变坏的可能，无论概率有多小，它一定会发生。那么假设你我就是企业架构的总负责人，现在要保证企业整体业务的连续性，应该怎么办呢？
+
+有一个很通用的办法，叫做“**冗余设计**”（我们在文章开头提过了）。所谓“**集群**”、**“分布式”**，这些名词大体上都是在描绘“冗余设计”的概念。
+
+但冗余设计也不是万能的，它只能解决底层物理机器，也就是某一个实例的不可用问题。如果是代码逻辑出现了问题，冗余设计就失效了 —— 一个恶性 Bug 在生产环境爆发，后果是所有集群都会遭殃。
+
+没钱做 100% 的高可用设计，又想尽量提供系统的抗风险能力。作为架构负责人，应该怎么办呢？
+
+这里你可以停下一分钟，略微思考一下。
+
+**第一个解决方案是，在风险爆发、系统出现问题的情况下，对外提供“降级服务”**。也就是说，当团队没有时间去设计、测试并确保当前组件高可用时，如果因为未知原因，导致组件出现故障，我们需要提供一个逻辑相对简单，并且一定可用的服务替代原来的服务实现，实现服务对外的高可用。
+
+以电商系统的物流时效产品为例，正常情况下，该系统需要通知用户已购商品的到达日期。比如，邻近区域当日送达、跨省隔日送达、偏远地区三日送达，等等。具体的物流时效和用户和仓库的距离、仓库作业能力、车辆配送能力很多因素都有关。
+
+但如果因为一个 Bug 或一个配置文件修改错误，导致物流时效产品崩溃了，用户在四级页、购物车，订单确认页调用该服务时失败，怎么办呢？
+
+一个解决办法是：由服务器端技术人员写一段程序，保证任何用户查询物流情况，都显示 3 天送达。出问题的时候，使用此服务进行替换。然后，全体技术人员努力恢复服务，系统恢复后替换回正常的物流时效服务（如果有兴趣，这里你可以想想，为什么这段代码应该是服务端技术人员来写？答案藏在架构设计一节）。
+
+看到这里，你可能就笑了：老乔你这是欺骗用户呢，这还叫什么高可用？
+
+可这就是“降级服务”，实打实的高可用保障手段。在用户眼里，业务是连续的，只是可靠性降低了。其实对于架构师而言，高可用和高可靠应该是两个不同的概念，只是很多人将其混为一谈。
+
+**在最理想的情况下，我们既保证高可用，也保证高可靠；但出现问题时，我们优先保证高可用，其次保证高可靠**。这是另一点关键认知。
+
+其实在不同领域里，有很多类似的做法。比如在流媒体领域，当用户观看直播出现严重卡顿时，很多企业的第一反应不是查服务器 Log，而是为用户自动降码率。因为比起画质降低，卡的看不了显然会让用户更痛苦。
+
+如果“降级服务”还解决不了问题，应该怎么办？答案是提供“熔断服务”，让出现 Bug 的模块从系统中“熔断”，虽然用户会看到物流系统报错，但整个业务依然是正常响应的，不会被一个系统的 Bug 拖死。
+
+现在我们总结一下：**高可用意味着对系统全部元素、连接都进行高可用设计，在物理实例层面主要表现为冗余和集群设计，在代码逻辑层面，方法则多种多样。当你的资源和精力不足以实现全链路高可用时，提供“降级服务”和“熔断服务”，优先保证高可用，其次保证高可靠。**
+
+企业里面有些核心服务是不能降级的，对于这类服务，就一定要通过研发流程管理，确保服务的高可用、高可靠。一名合格的技术管理者，要能够识别核心服务，并引导团队重点关注。
+
+## 高可用，不只是个“设计问题”
+
+在我的职业生涯中，有两次生产事故让我印象最为深刻。
+
+一次是机房停电，一次是知名开源软件 ZooKeeper 出现严重 Bug（几年前的一个版本 Bug，连接数超过阈值就会停止服务，不知道现在是不是修复了）。这两次事故发生时，我基本都处于焦头烂额的状态，甚至几天几夜不能睡觉。它们一个属于底层物理实例出现了问题，一个属于代码逻辑出现了问题。
+
+对于你而言，我觉得代码逻辑导致的系统故障可能更为常见，机房停电、爆炸、地震毕竟发生几率比较小。
+
+如果将“放大镜”对准代码逻辑导致的系统“不可用”问题，我们就会发现**高可用设计真正的敌人是“变化”。**
+
+设想一下，如果生产环境不发生变化 —— 不发布新版本、不修改配置文件、不修改数据库脚本，系统大概率会一直保持正常（你可能会说，老乔，服务器压力激增也会导致问题。前面我们讲了，这属于架构设计中的“流控”设计，通过容量规划设计，流量控制问题很容易解决）。
+
+此时，生产环境发布新版本就会成为一个影响巨大的变量，极有可能对系统的可用性造成挑战。
+
+所以，**研发管理水平的高低，决定了你在版本发布方面的成功率和信心。**
+
+单就版本发布问题来说，你需要关注研发管理的三个关键点：
+
+1. 记录系统的任何一次发布和变化，包括发布系统/组件、发布时间等；确保自己可以随时定位任何一个时间段内的任何元素及任何发布动作，包括但不限于代码、配置文件、SQL  脚本、设备参数修改等；
+1. 发布时不影响业务；
+1. 保证任何发布都可以回滚。尤其当一个大版本的发布时，能否精确识别回滚单元，并做到秒级回滚。
+
+只要做到以上三点，哪怕你在上午十点发布新版本，又有什么关系？根本就不必等到半夜嘛。
+
+当然，总是回退也不是办法。作为一个研发组织，我们还可以从另外一个角度，提高系统的抗风险能力。这里，我要先问你两个问题，如果有时间的话，请你思考一下：
+
+1. 由代码逻辑导致的系统风险，是如何进入生产环境的？
+1. 生产环境出现严重故障，是不是毫无征兆地发生的？
+
+首先回答第一个问题，风险是经由开发环境、SIT  环境、压测环境、PRE  环境，进入生产环境的。所以我们要做的，是严格检查各个环境下的异常，**研发管理规范，应该为代码版本进入下一个环境设置准入标准，对于任何异常，都有负责人进行修正。如果异常通过了评估，审核者要对其负责**。
+
+第二个问题，答案当然是否定的。就像人在生病前，会在各项生理指标上有所表现。**系统 Bug 在导致生产故障前，也往往会有各类异常，我们要做好监控并正式的处理掉它**。
+
+这里我想说点题外话，在我们这个技术行业，每年都有猝死的情况发生，每次看到这种消息，我都觉得很遗憾。大家要关注自己的身体健康，关注身体给出的各种警告，爱自己、照顾好自己，才能爱家人。只要关注自己的健康、想办法，猝死大概率不会发生的。
+
+回归正题，在极少数情况下，一个严重 Bug 会藏在生产环境里，始终没有触发。但当它被触发时，可能就会导致生产环境“暴毙”。前面我讲的关于 ZooKeeper 的例子就是这样，到连接数超过阈值后，系统突然就挂了，所有人措手不及。
+
+对于这种情况，一旦碰到了，某种程度上就要认命。我一直讲，人生，运气也很重要，非常重要。如果已经尽全力了，还是出现了问题，要学会接受自己，承认自己的运气不好，将这当作是成功路上的经验、教训，这才是真正的成长性思维。拒绝不完美，渴望成长，当然很棒，但很多心理问题的源头也在这里，要学会接受自己。
+
+所以，开源软件其实是存在一定风险的。但开源软件依然代表了软件研发行业的一种主要潮流，毕竟你免费用了人家的软件那么久，有些许风险不是很正常吗？所以我依然允许团队向生产系统引入开源代码，只是从那次事故以后，我要求：引入开源代码的技术人员，必须通读并掌握其代码。
+
+还有许多研发管理方面的注意事项，包括代码 Review 文化、DevOps 等，我们就不再展开细说了。**关键在于要注意，真正的、为业务负责的高可用设计，不是画框图就能解决的，它是一个面向 IT 组织的整体设计。**
+
+## 结语
+
+到这里，我们这一讲的内容就接近尾声了。
+
+高可用设计，意味着“Design For Failure”，最重要的是让我们做产品没有后顾之忧。如果后院天天起火，研发团队每天胆战心惊，也就无从谈起“将产品打磨至卓越”了。所以，做好高可用，一定程度上就是在实践“慢就是快”的认知理念。
+
+如果你有仔细揣摩以上内容，或许会发现：虽然我们或许不能保证所有服务高可靠，但我们是可以保证所有服务高可用的。其关键点在于，面向所有的元素和连接，都要做设计。任何没有被设计过的元素和连接，往往都是不可靠的。
+
+任何一个要达到的目标，都要被量化；任何一个量化的目标，都是一个契约，要有契约精神；任何一个契约，都要进行设计。没有设计的内容，怎么可能如你所愿呢？何况，什么才是你的“所愿”呢？
+
+从这个角度来看，做一名卓越的架构师，真是个苦差事，但也充满了乐趣。
+
+你可能也会想，老乔，那我学的 CAP 理论、异地多活还有用吗？是不是都白学了？
+
+这些当然是有用的，但它们都有具体的使用场景限制。比如对于 CAP 理论来说，在分布式基础设施层的应用有些用，在应用层就受限了，许多人是学完了就忘了，设计架构时该怎么干还怎么干；至于异地多活，已经超过了国内大部分企业的现阶段的业务需要。而且我认为，异地多活最大的优势在于，对架构可扩展性和可维护性的提升，而不仅仅是高可用。
+
+学习，尤其是学习技术和管理知识，其实要有“功利心”。学完了一定要去实践，这样才能真正化为己用。我总是跟你讲：持续学习、学以致用、终身成长，有太多同学就是没做到学以致用，才导致“学了也白学”的结果出现。
+
+希望你在以后的学习生活中，能始终做到学以致用，保持高速的成长，终身成长。
+
+我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对专业成长的复盘/21 | 高性能设计，一切都围绕着契约精神.md

@@ -0,0 +1,173 @@
+<audio id="audio" title="21 | 高性能设计，一切都围绕着契约精神" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/yy/5d/yy882558928ef8a1f751401b854b065d.mp3"></audio>
+
+你好，我是乔新亮。这一讲，我们来聊聊如何实现架构的高性能设计。
+
+前面我们讲过，产品思维有两个核心关键词：“契约精神”和“洞察人性”。其实高性能设计，也和契约精神是密切相关的。我将其总结为：高性能设计，一切围绕着契约精神。
+
+你可能会想，高性能设计不就是可以支撑大流量、高并发的架构设计吗？和契约精神又有什么关系？
+
+其实关系很大。所谓的高性能，实际上，是与业务强相关的。比如，对于一台网络游戏服务器来说，可以支撑 400 名玩家同时在线，就算高性能；对于一台流媒体服务器来说，可以支撑 10,000 用户同时在线观看，就算高性能。
+
+当然，数据可能不准确，但逻辑大体如此。在实际的业务场景中，还会有许多其他技术指标被引入。比如游戏需要关注连接稳定性、视频需要关注延时，等等。
+
+明确了性能和业务的关系，下面我们就来聊聊，如何进行高性能设计，也借此加深对契约精神的认知和理解。
+
+## 契约精神是高性能架构设计的“拦路虎”
+
+首先，我们要清楚，高性能设计可以大体拆解为两大步骤：
+
+1. 清晰描述、定义性能目标；
+1. 设计并实现这个目标。
+
+而高性能架构的设计目标，是通过三类指标来具体定义的，分别是：
+
+1. 系统响应时间，一般指服务/交易处理的时间，也包括网络响应时间；
+1. 系统吞吐量，一般指系统的每秒交易量，通常需要结合并发量共同描述；
+1. 系统容量，通常代表系统的可用资源数量，包括硬盘容量、网络带宽等。
+
+但要注意：虽然我们有三类高性能指标，但彼此不能孤立地看待，否则就会出现问题。比如，在定义系统响应时间目标时，如果不与系统吞吐量关联起来，就会变得缺乏实践意义 —— 一旦流量的压力高峰到来，系统往往就不遂人愿了。
+
+这意味着，我们要学会识别架构设计中的组件（或服务），首先弄清哪些组件需要明确高性能指标，再针对性地用以上三个指标做清晰定义。
+
+除此之外，对于系统响应时间，我们还有一个更直观的监控指标，叫做 Top 百分数 （Top Percentile），简称 TP。比如， TP 90 = 2s，意思是，90% 的请求的响应时间都在 2s  内；那么  TP  99 = 2s 的意思就是 99%  的请求的响应时间都在  2s 内；我们一般说的  RT  =  2s，指的是平均响应时间，可以作为参考，但实际意义可能并不大。我个人一般会重点看  TP  90  和  TP  99 的数据。
+
+当我们明确了  TP  90  或者  TP  99 这一有关系统响应时间的指标时，一个交付给用户的“契约”就出现了。守好诸多类似的契约，也就是保证了高性能设计。但学习需要适当地进行延展思考，比如此时，我们应该多问自己一句：这个契约意味着什么？
+
+对于没有经验的程序员或架构师来说，这里其实存在一个隐含的假设，某种意义上，也算是一种侥幸心理：如果该系统在业务流量低峰场景下，满足了响应时间等性能指标，也就意味着，该系统在任何场景下，都能满足这些指标。
+
+你可能会觉得有点绕， 那我换个说法来描述刚刚签订的高性能“契约”：本系统、组件、服务承诺在任何情况、任何资源、任何压力高峰下，都保证  TP  90  =  2s 。
+
+是不是立刻就有了不一样的感觉？好像契约发生了变化，光是读出来，就让人心里一抖。
+
+其实到此时，还谈不上契约是否发生了变化，因为打从一开始，这个契约就是不明确、不清晰、不具体的。
+
+注意，这里还没有谈架构设计和研发能力，问题就已经出现了。很多时候，我们会被工作中出现的一些实际问题所困扰，其根源往往不在于相关责任人缺乏设计能力，而在于签订的“契约”并不明确。团队不可能实现和保卫一个“空中花园”。
+
+所以，我总说，高性能设计，一切围绕着契约精神。所以接下来，我们的内容都将围绕着“如何将契约描述清楚”这件事来展开。
+
+## 有上限的“契约”才能交付
+
+我曾经培养过许多架构师。一开始在做高性能设计时，他们常常会这样描述给用户的“契约”：
+
+“该架构最高支持 200 万并发流量，TP 90 = 2s 。”
+
+在不考虑业务需求的情况下，这个契约看似是没问题的。这意味着：对于第 1 名连接服务器的用户来说，TP 90 = 2s ；但对于第 300 万名连接服务器的用户来说，契约又是什么呢？答案是，没有，或者说比较模糊。
+
+**如果目标不清晰，隐患就埋下了。高性能设计非常看重系统响应时间的一致性，尤其是在不同的服务阶段，并发量和吞吐量发生变化的时候。**
+
+对于管理者或架构师而言，理想的契约应该是“保证设计流量内的用户 TP 90 = 2s，超出并发限制的用户，则暂时不在契约承诺的范围内。”。
+
+这就要求我们通过四大步骤去思考所谓高性能架构的设计问题：
+
+第一步，当服务器不超过 200 万并发用户时，TP 90 = 2s 。
+
+第二步，当连接服务器的并发用户数量超过 200 万，达到 250 万时，保证有 200 万用户的 TP 90 = 2s ，拒绝其他用户的连接请求。
+
+第三步，为设计容量外的用户提供服务器排队机制，并附带具体、明确的系统提示。
+
+第四步，3 分钟内完成扩容，保证并发用户数量小于等于 250 万时，任何在线用户的 TP 90 = 2s。
+
+其实，这样才构成了一个可以履行的契约：无论流量波动如何，该架构始终支持 200 万用户的 TP 90 = 2s；高峰时期，其他用户会被拒绝访问或进行排队，但系统能在三分钟内完成扩容，支持 250 万并发在线用户，并且保证其中任何一个用户的 TP 90 = 2s  。
+
+在某种程度上，这也是对业务诉求的精确表达，对于业务发展来说至关重要。很多同学设计的架构和契约，压根没有控制上限。他们想当然地认为，流量不可能出现太大的变化或波动。对于用户来说，这无异于一张“空头支票”。
+
+所以说，要做高性能设计，一定要明确目标，并交付给用户；没有清晰的目标，也就没有针对性的设计，怎么能实现高性能的架构呢？
+
+目标清晰后，我们再来看看，高性能架构如何设计并落地。
+
+## 实现高性能架构的关键技术点
+
+落地也不难，有三项工作最为关键，分别是：
+
+1. 为架构做好“保护系统”；
+1. 使架构具备扩容能力；
+1. 提升系统各组件处理能力。
+
+**保护系统，是为应对容量规划外的过载而设计的，通过流量控制来具体实现。**
+
+所谓流量控制，就是当实际并发压力，超过设计性能的时候，人为阻断服务器连接，告知用户需要排队或“稍后再试”。
+
+经常玩游戏的同学可能知道，对于网络游戏来说，流量控制是个基础设计，基本上所有的服务器都有“排队机制”。
+
+流量控制有两种具体的实践，一种是面向连接数做控制，一种是面向用户数做控制。前者让用户在不断尝试连接时，有一定成功的可能；后者则保证用户对系统的期望是一致的 —— 要么可以登录、要么不能登录。具体应该选择哪种方式，取决于业务的实际诉求。
+
+**而对于扩容能力来说，一般要包括储备额外的计算资源和具备快速弹性扩容能力。**
+
+你可能会说，既然已经有计算资源了，为什么不提前进行扩容呢？
+
+工作经验比较丰富的同学可能会知道其中的“隐情”：一般来说，该做的系统扩容，通常很早就完成了，架构设计真正缺乏的是应急手段。毕竟，你不能“不分青红皂白”，将每个系统的应急扩容都提前做好。一个经营稳健的企业，是不会允许这样的开销出现的。
+
+另一个关键要素在于扩容速度。扩容工作是需要一小时、一分钟，还是一秒钟完成，其差别非常之大。“天下武功，唯快不破”，就算架构设计做得不好，如果响应够快，很多情况下，也是能解决问题的。
+
+无论是利用公有云扩容，还是私有云扩容，目标都应该是一致的。想象一下这样的场景：
+
+双十一来了，你通过监控平台，看到在线用户数量快速增长，很快突破了 200 万，流量控制机制开始生效，新用户进入排队序列。你考虑了 3 秒钟，然后做了一个决定：系统需要扩容。于是，你轻轻地输入一个数字，按下回车。3 秒钟后，排队序列消失了。你对旁边的同学说，继续监控吧！然后悠闲地端起茶杯，离开了座位。
+
+这将是一种多么美妙的工作状态？更棒的是，以上场景完全有可能实现。
+
+至此，我们聊过了契约，也聊过了应急处理，也就意味着，我们把握住了高性能设计的“头”和“尾”。最后，我们再简单谈一下“中间”部分，也就是对系统各组件处理能力的提升。
+
+在高性能设计中，对于每个组件/服务都要确定目标，进行设计，然后进行评审和测试，确保满足性能需求。对于架构负责人来说，性能设计一定要尽早开始，具体工作内容包括：
+
+- 需求早期收集
+- 容量分析
+- 估算与建模
+- 技术研究
+- 设计、开发、跟踪
+- 测试计划执行
+- 风险与绩效管理
+- 实时监控与容量管理
+
+工作内容和流程可能有些多，但这更多属于标准化的研发管理流程，这里列出来仅供参考，实际执行的时候，需要参考具体的业务和企业情况做调整。
+
+**在这中间，有一点需要额外注意，我们称之为“对系统资源的争抢问题”。**
+
+对于一个组件或服务，并发压力增大，响应时间却没有变化，意味着在请求的处理过程中，没有发生对资源的争抢和排队。同理，当响应时间随着并发压力的增大而变长时，一般都意味着这些请求引起了对系统资源的争抢。
+
+**对于无状态的服务，理论上可以通过集群扩容，无限增加系统的并发处理能力，简单、直接地解决问题；**
+
+**但对于有状态的数据服务而言，比如缓存或数据访问，就要考虑资源争抢问题，并针对性地设计、处理**。
+
+所以，高性能架构在设计落地时，一个重要的任务，就是去发现那些可能出现资源争抢的模块，并一一进行隔离。
+
+谈到“隔离”，在架构维度有两种方案，一种是在应用层进行隔离，也就是说，在业务功能层面就开始隔离；一种是基础软件层面进行隔离，比如与数据库相关的“读写分离”概念，就是在基础软件层面进行隔离。
+
+对应到具体的实施方法上，有三种主要的“隔离”技巧，你可以多做了解：
+
+1. 缓存机制，适用于部分场景，可以解决数据库资源的争抢问题；
+1. EDA 架构，适用于处理时间较长的代码逻辑，需要提前区分哪些模块可以做同步处理，哪些模块可以做异步处理；
+1. 提前进行预处理，以空间换时间，这也是一种卓有成效的处理手段。
+
+当然了，方法还有很多，听完这节课后，你可以单独再做了解，并将了解到的方法，在评论区分享给大家。
+
+做好隔离后，我们也要注意提升架构的可扩展性，具体方法可以参考[《架构设计，专业分工和协作精神的体现》](https://time.geekbang.org/column/article/317135)，这里不再重复。
+
+至此，关于高性能设计的三个最重要的步骤就讲完了，我们总结一下，分别是：
+
+1. 为架构做好“保护系统”：做好系统的流量控制；
+1. 使架构具备扩容能力：储备额外的计算资源，提升弹性扩容的速度；
+1. 提升系统各组件处理能力：识别高并发情境中的资源争抢情况，同时注意保留架构的可扩展性。
+
+最后，我们也要对测试工作保持关注。可能你在 PRE  环境做过压测，但后来发现，实际的业务复杂度是远远超过想象的。
+
+针对这种问题，行业内的解决方案更偏向“全链路生产压测”，说白了，就是在生产环境准备数据、进行压测。如果一个系统通过了全链路压测，那就可以基本确认没有性能问题了。
+
+## 结语
+
+从我的角度来看，**技术行业发展到今天，基本不存在太多的技术挑战了。**
+
+如果你能将业务问题抽象为一个技术问题，那么不管是寻求同事的帮助，还是 Google、看书、到知识平台付费学习，都能解决你的疑惑。
+
+所以，在理清高性能架构设计的整体思路后，困惑、焦虑，应该从你的认知中消失。具体到数据库设计、缓存设计、队列使用等技术细节，我认为都不是问题。关键之处，是要守住契约，按照我们今天所讲的三大步骤尝试落地。
+
+过去的几年间，我曾在多个企业内建设高性能的 IT 系统架构，很好地服务了用户，使用的就是我们今天所讲的各个方法和思维框架。我个人感觉，过程也是相对轻松的。
+
+需要注意的是，如果时间充足且落实到位，系统确实不会出现高性能问题。可是实际情况是，团队没有时间做完整的高性能设计，没有预算做全链路压测，所以埋下了隐患。
+
+这时，我建议相关负责人要去识别最关键的服务，针对性地进行设计、测试，确保关键服务没有问题，并且，为非关键服务提供降级和熔断处理的开关。
+
+另外一个比较常见的情况，是企业决策层将高性能的设计问题和技术问题混为一谈：看似是技术能力太过欠缺，其实是契约和设计没有做好。**任何复杂问题都可以被拆解为简单问题，只要拆解得足够细致。一定要牢记这一点，这种思维能力是技术人的安身立命之本。**
+
+当然，如果你有问题或想交流的内容，也不要犹豫，立刻在评论区写出来，我会认真回复。
+
+我们下一讲再见。

极客时间专栏/乔新亮的CTO成长复盘/对专业成长的复盘/22 | 扩展性设计，看透业务的本质.md

@@ -0,0 +1,154 @@
+<audio id="audio" title="22 | 扩展性设计，看透业务的本质" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/23/af/23c7dd9e6e951ef2b6b5bac5521009af.mp3"></audio>
+
+你好，我是乔新亮。
+
+这一讲，我想和你聊聊，如何做好扩展性设计。
+
+说到扩展性设计，可能你的第一反应是业务拆分、集群扩容等等。说得没错，这些都能增强系统的扩展性，但仅仅局限于架构和技术层面。我的下属经常兴奋地向我描述，说他实现了一个非常厉害的、高性能、高可扩展性的系统。我的回答经常是，你说的都对，然后呢？
+
+这个问题背后隐含的意思是：对于一名追求成长的技术人来说，只从技术维度思考问题是不够的。这只能让你胜任目前的工作，但不能让你变得卓越。
+
+一名追求卓越的技术人，应该学会思考：我的工作是如何成就业务的，我的产品如何让用户变得更卓越？如果对业务、对用户没有帮助，做再多的技术工作都是无用功。
+
+在职业生涯的早期，每一个工程师都会因为一些技术上的进步被领导夸奖，这很正常。因为在那时，做好基础的代码编写工作，就是你的主要任务。
+
+但如果三年、五年后，你仍然将全部注意力放在技术细节上，就要小心了。比如，很多读者都在专栏下方向我提问，其中一些问题是非常相似的：乔老师，我是一名工作了 7/10/15 年的技术总监，现在感觉非常焦虑，应该怎么突破职业瓶颈，怎么继续成长呢？
+
+如果要将我的回答总结为一句话，我觉得应该是：**让自己变得专业，专业才能成就卓越。**
+
+这个专业不单是指技术越来越厉害了、写代码越来越快了。更重要的是，你在架构设计方面是专业的、在团队管理方面是专业的、在业务发展方面也是专业的。因为专业所以做出了好的产品，通过产品成就了用户，因此也帮助公司业务取得了成功。
+
+回归到今天的主题 ——「扩展性设计」上，我们同样要考虑：如何做扩展性设计才是专业的？一定不是只会扩展集群，提一些服务器采购需求。
+
+扩展性设计，是为了支撑业务快速发展而出现的概念，目的是保证在企业发展的不同时期，在业务复杂度相近的情况下，业务上线所需要的研发时间不会大幅增加，甚至是基本不变的。本质上，所谓扩展性设计，就是在面向业务的不确定性做设计。
+
+因此，要想做好扩展性设计，设计者要具备企业发展的全局视角，从业务发展的角度出发，倒推出 IT 建设的整个链条，再针对链条中的某个节点，针对性地推进设计工作。
+
+听起来是个很“宏大”的工程，有点让人望而却步。但别害怕，接下来，我们就一步步将其拆解，学习如何做好企业级的扩展性设计。
+
+## 一条重要的前置思考脉络
+
+要做好企业级的扩展性设计，意味着你要强迫自己像 CEO 一样思考，首先理顺一条重要的前置思考脉络。
+
+如同前文所讲，无论是高可用、高性能还是今天聊到的扩展性设计，出发点都应该是业务发展，所以我们首先可以明确，**这条脉络的第一个节点，是公司的年度或季度业务发展目标。**
+
+那么，企业用什么形式来支撑业务的发展和增长呢？如果你认真听了前面的课程，此刻心中应该会有答案。没错，答案是产品。所以**第二个节点，是企业的产品建设。**
+
+产品，本质上是一种顶层设计，底层要由众多应用/业务组件支撑。所以**第三个节点，是企业的应用架构设计。**
+
+而应用架构又由众多技术组件在底层提供基础能力支撑，所以**第四个节点，是企业级技术架构设计**。
+
+以上四个节点，最终都是由人来完成的。所以我们还要考虑组织的人才梯队建设，包括 A/B 岗配置、同赛道竞争机制等。一旦将团队纳入设计，就要考虑协同效率的问题，不能因为业务增长、团队增长而引入协同问题。这两点，则全部属于团队管理范畴的问题。
+
+其实没有那么复杂，对吧？我们来梳理一下，要提升扩展性，需要在以下四个层面进行设计，分别是：
+
+1. 公司的年度/季度业务发展目标；
+1. 企业级产品建设；
+1. 企业级应用架构设计；
+1. 企业级技术架构设计。
+
+同时，我们也要将团队管理内容纳入考量，分别是人才梯队建设和提升协同效率。
+
+如果用云计算领域的概念来比喻，那么「产品建设」就像 SaaS、「应用架构设计」就像 PaaS、「技术架构设计」就像 IaaS/PaaS，三者共同固化为企业的核心能力，在团队管理方法的辅助下，实现业务可持续的向前发展。
+
+这四点就像一张“寻宝地图”，下面我们来分析一下，如何通过这张“地图”，实践扩展性设计。
+
+## 保证企业级年度/季度业务发展目标实现聚焦
+
+制定「企业级年度/季度业务发展目标」，需要在公司战略确定、商业模式确定的情况下，充分考虑市场竞争情况，确定目标的优先级，明确每个季度的工作目标。
+
+此时，我们主要考虑节奏问题。这里的“节奏”是什么意思呢？从企业发展的角度讲，一切能力都需要提升，但顺序不一样，节奏就不一样，效果上的差别也非常大。所以，做好战略规划很重要，要分析各战略步骤的依赖关系、重要性、紧急程度，最后确定执行顺序。
+
+所谓“扩展性设计”，通常是当大环境或创始团队的认知出现变化时，公司需要重新调整业务目标，各团队也要配合调整。具体到每个季度的目标，则一定要清晰、聚焦、上下对齐。关于战略执行效率的问题，我们在“[管理三板斧](https://time.geekbang.org/column/article/307105)”部分进行过讲解，可以参考一下。
+
+此外，初/中级管理者很难像 CEO 一样透彻理解业务目标，但要尽力去理解、去沟通，每个季度要主动和公司目标进行对齐。认知越透彻，对自己的工作和成长越有帮助。
+
+## 用业务目标指导产品建设
+
+确定了业务目标后，在规划产品建设时，团队可以通过三步做好扩展性设计：
+
+1. 通过架构思维，将产品拆解为一个个功能模块；
+1. 针对每个模块，用穷举法思考其他扩展可能；
+1. 以 ROI 为出发点，对所有可能进行收敛，最终确定要落实的扩展性设计。
+
+对于步骤一，我们就不再展开详谈了，可以参考[《架构设计，专业分工和协作精神的体现》](https://time.geekbang.org/column/article/317135)这一讲的具体内容；对于步骤二，相关负责人既可以根据市场趋势来穷举，也可以根据相关竞品来穷举，其实更像一场头脑风暴。
+
+关键在于步骤三，如果收敛得不好，会让产品变得臃肿，变成过度设计；如果收敛得太过，又会使产品缺乏扩展性。如何准确计算 ROI，是一个大学问。而计算 ROI 的重任，一般都会落在产品经理的头上。
+
+ROI 的意思是投资回报率，也叫做投入产出比，常用的计算公式有五种以上。在技术管理领域，我们可以简单将 ROI 理解为“收益/投入”。
+
+业务侧人员一般重点关注工作收益，不关心工作投入；技术侧人员则非常重视工作投入，不关心工作受益；产品经理则要学会综合考虑。
+
+无论是业务侧、技术侧还是产品侧，这三方人员的业务思维越好，产品需求的收敛工作就完成得越快、越好。前面我们讲过，IT 团队的每个人都要懂业务，其意义就在于此；相应的，业务人员也需要培育产品思维，这样才能最终实现公司的业务  IT  一体化。
+
+当然，产品建设一方面从业务侧收集需求，完善产品；另一方面，优秀的产品经理也会帮助业务筛选客户，确定产品方向。二者循环往复，互为补充。
+
+举个例子，一个生鲜类 To B 产品的报价系统，通常需要和对标对象做价格比对，并做相应调整。通常，一个没有扩展性思维的团队，接了需求就会直接开始写代码，反正也没什么难度。
+
+但一个有扩展性思维的团队会思考：在北京需要与对标对象 A 比对价格，在福州可能就是与对象 B 比对价格了，不同的地区可能会对系统功能有不同的需求。
+
+进而，我们可以将一个价格比对产品的功能模块进行抽象，包含：对标对象设置、对标商品映射、价格设定规则（上浮或者下调）、对标周期等，这样就可以满足全国各个区域的任何价格比对需求，支持业务的快速发展。
+
+所以，产品能否具备高扩展性，是与产品经理的业务思维和抽象能力密切相关的。同时，如果产品设计做得好，应用架构的设计工作就会简单很多。
+
+讲完了业务目标和产品设计，也就来到了关于扩展性设计的第三个节点：做好企业的应用架构设计。这里，我们需要重点区分两个概念：架构设计的确定性与不确定性。
+
+## 扩展性设计，为“不确定性”而设计
+
+笼统地讲，任何业务架构都存在确定性和不确定性的部分，但二者并不是恒定不变的。所谓的确定性部分，可能无法适应业务的演进和发展，因此出现大量改动；而所谓的不确定性部分，也可能随着时间的推移，逐渐固化为产品能力，变成设计内的确定性内容。
+
+企业级应用架构设计可以包含：
+
+1. 交易体系；
+1. 协同体系；
+1. 监控指挥体系；
+1. 生产体系。
+
+这是做拆分的基本思想，无论在顶层还是底层，都非常适用，需要做的只是不断进行拆分。经过这些年的工作实践，我觉得，无论是组织管理、架构设计还是产品设计，很多时候就像“套娃”。刚开始做企业架构规划时，我觉得非常难以入手，彻底掌握后，我发现这和做系统架构设计简直一摸一样。
+
+对于生鲜行业的 To B 产品来说，查询、下单、发货、签收，是始终不变的业务流程，属于确定性部分。这部分的实现归属交易体系。**交易体系处理确定性问题，一般采用 SOA 架构。**
+
+但在实际的业务场景中，意外会经常出现。比如，客户下单购买了 500 斤白菜，但在发货时，仓储系统却显示备货不足，无法正常发货。
+
+此时，产品预设的服务流程就被打破了。企业一般会指派客服人员与客户联系，尝试着商量一下：“不好意思，我们的白菜只剩 300 斤了，剩下的 200 斤给您换成芹菜吧，芹菜多好吃呀！”
+
+这个时候，我们就需要让采购人员、销售支持、销售人员联系客户，进行充分沟通，确定最终的商品品类及数量。这个流程属于协同问题，充满不确定性，也就是说，相比交易体系，更有可能随着公司的管理优化而进行变化。**协同体系用于处理不确定性问题，一般采用 EDA 架构，且要和交易体系进行集成。**
+
+所谓「不确定性」部分，其实正是业务架构做扩展性设计的核心。交易体系和协同体系的分离，等同于分离了业务的确定性和不确定性部分，因此非常有利于业务功能的扩展。
+
+**分离不代表完全无关，交易体系和协同体系的集成点，我称之为 CP（control point）。一般来说，任何一个 CP 都要被监控、分析、控制，这就是企业的监控指挥体系。监控指挥体系和公司的管理密切相关，往往是公司数据化管理的重要抓手。**
+
+监控指挥体系可以分为监控、分析、洞察、控制等几大功能，大数据和  AI  部分的技术内容也在这个体系中。监控体系解决了公司的很多问题，但怎样保证产品高效地迭代和优化呢？这就是生产体系要解决的问题。
+
+**生产体系解决公司研发管理地速度问题**。我的观点是，技术管理者要学会引入“流水线”式设计思想，尝试极大简化开发人员、测试人员的工作复杂度。如果将研发的整体流程看作一条“流水线”，代码开发完成后，工作要自动流转，正常、异常都要自动流转至对应人员进行处理，这是有关 CI、CD、CO  的内容，我们不展开详解， 但它非常重要。
+
+做好了应用架构层面的扩展性设计，我们也就来到了第四个节点 —— 企业级技术架构设计。
+
+技术架构设计设计的关键在于：**不要重复造轮子，至少不要在公司层级造轮子**。 “局部最优，整体很差”的情况，很多时候都是因为重复造轮子导致的。
+
+所以，要实现技术架构体系中的各个技术平台，可以通过两步完成：
+
+1. 自研；
+1. 购买相应的套装软件或云服务。
+
+对于非核心系统，在需求较为匹配的情况下，建议选择购买套装软件或云服务；对于高度定制化的企业核心系统，也就是在核心价值链上提供服务的系统，则建议自研。
+
+是不是很简单？到这里，我们就将扩展性设计的四个关键节点全部分析完毕了。
+
+其实真正的扩展性设计，往往与单一维度的技术问题无关，也与某个人的架构设计能力关系不大 —— 扩展性设计，是团队整体认知、博弈与决策的结果。
+
+这意味着，如果你想在一家公司内，充分践行以上设计思想，需要锻炼并掌握一定的表达技巧，与领导、同事、下属保持充分的沟通，更与组织管理能力息息相关，要多治治“腼腆内向”、“不善沟通”等技术人“职业病”。
+
+## 结语
+
+这一讲，我们聊了聊如何进行扩展性设计。
+
+可以说，**真正优秀的扩展性设计，建立在看透业务本质的基础上，面向不确定性，但要从不确定性中寻找确定性。**
+
+这里需要注意，越是行之有效的方法，越不会太过复杂。比如说，研发速度快，对于产品或架构而言，也是一种扩展性 —— 我们没做过什么扩展性设计，但团队的研发速度很快：今天发现需求，明天就能上线。
+
+这样靠谱吗？当然靠谱，就像我们之前说的，“天下武功，唯快不破”。只是长期看来，唯有体系化的思维和解决方案，才能真正从根本上解决问题。
+
+如果你有问题，欢迎在评论区向我提问；如果你觉得有帮助，也欢迎分享文章到朋友圈，让更多人参与进来，共同学习。
+
+我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对专业成长的复盘/23 | 考虑限制，让自己的产品不入险地.md

@@ -0,0 +1,190 @@
+<audio id="audio" title="23 | 考虑限制，让自己的产品不入险地" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4a/e8/4a05697cde713b44c6b0yyaa3324d3e8.mp3"></audio>
+
+你好，我是乔新亮。
+
+在实际的工作中，可能你经常会承担许多难以按约、按时交付，甚至是无法交付的工作。对于个人成长来说，这无疑是个大问题。
+
+虽然我常常向团队强调一个公式：「**认知到位 + 彪悍执行 = 成功交付**」，但这是建立在对项目的客观评估基础上的，否则，对于某些工作任务或产品需求来说，无论你多么努力，也可能无法保质保量地交付。
+
+无法交付的原因可能有很多：或许，该需求远远超出了团队现阶段的技术能力；又或许，是该需求违背了项目执行的客观规律，等等。总之，因为你承诺了自己根本做不到，或风险极高的“契约”，因而导致自己无法按约交付，最终对自己的成长和信誉造成了损害。当然了，对于公司而言，这一结果也是最差的。
+
+举一个夸张点的例子，有一天，老板找到你说，小王啊，公司最近要自研一款分布式数据库，决定让你来负责项目实施，一个月能不能搞定上线？
+
+你可能会在心里想，天啊，一个月，时间太紧了，怎么可能？老板看出你有点犹豫，又补充道：小王啊，要抓住机会，好好表现啊！
+
+你一听，顿时觉得，不就是加班吗？拼一把吧，于是点头应承下来。结果，一个月后，项目因为种种意外延期了，你则因为长期加班累了个半死……
+
+我们不妨再举一个例子，公司的新产品要上线了，老板和产品经理们一同规划了一艘“航空母舰”：功能极其强大、性能业界领先、UI 非常漂亮，同时希望一个月就上线。结果呢，团队奋战了几个月，不但产品的设计和研发处处受阻，上线时间还遥遥无期……
+
+以上两个例子，相对来说都比较夸张，但夸大是为了便于理解。类似的情况，其实每天都在各大公司内上演，只是更加隐蔽，不易察觉。你可能认为这是一个有关“自知之明”的问题：没有金刚钻就别揽瓷器活，自己能干多少活还不清楚吗？
+
+但我要说，**无论是什么问题，只要存在，就一定有其合理性；进一步讲，无论是什么问题，只要合理，就一定有专业的解决办法，因为那些专业人士总是能确保自己不掉入陷阱。**
+
+在这里，我们同样有一套专业的思考和解决方案，适用于架构设计、个人成长等诸多方面，它的名字，叫作“考虑限制”。
+
+其实，在前面的几讲内容里，我们已经多少聊过一点“限制”思想。比如，对于高可用架构设计来说，要做好流量控制，否则，所谓的“高可用”只能是空谈；对于产品设计来说，要明确给用户的契约，不能做无边界的承诺。
+
+但关于“限制”，我们还需要更加系统化的理解和实践。接下来，我们就来详细聊聊，如何做好限制，让产品不入险地。
+
+## 限制产品的输入与输出
+
+首先，我们要知道，只有专业的人，“懂”的人才能做好限制，这个道理在高可用、高并发、高性能等各个领域都是通用的。
+
+那么，如何才能变得专业，让自己跨越从“不懂”到“懂”的鸿沟呢？这里就再次应用到了架构设计思维，对应的第一步，就是做好拆解。
+
+任何产品都存在“输入”和“输出”两部分。如果你是产品的负责人，“输入”就是其他人对你承诺的“契约”；“输出”一般理解为承诺给用户的“契约”，指的是产品的对外能力，通常受到输入的严重影响。
+
+比如，因为资金有限、服务器不够，所以我们无法承诺服务器在 300 万并发压力下保证 TP 90 = 2s，反之，只有当并发压力不高于 200 万时，我们才可以做出承诺。
+
+具体应该如何考虑输入限制呢？有两大维度我们要去重点评估和考量，一类叫做业务限制，一类叫做技术限制。
+
+**业务限制**主要包括以下六点：
+
+**第一，Time（时间）、Resource（资源）、Scope（范围）三要素。**
+
+这三类要素构成了产品最主要、最基本的“输入”，它们就像一个等边三角形，撑起了产品的落地路径。其中，时间和资源的含义都比较明确。范围一词略微有些模糊，我们将其理解为产品的功能规划或能力范围。范围出现变化，时间和资源也会相应出现变化。
+
+最可怕的事情，莫过于像我们文章开头所举的例子一样，一个月的工作量要求一周做完、十个人的工作量要求用一个人做完、产品的范围被扩充成“航空母舰”。只要三要素不合理、不匹配，产品基本都会“难产”。
+
+**第二，法律法规与政策限制。**
+
+这两年的 P2P、金融创新、社区团购等业务可以算是典型案例。但法律法规和相关政策的变更，大部分是为了在国家角度控制市场风险。对于相关行业从业者来说，不应该视为障碍。就像我们先前讲过的，**好的产品设计是向善的，这是始终不变的**。
+
+**第三，组织文化限制。**
+
+不同的组织结构、组织文化，都会对产品的输入造成限制。这也是管理者为什么要聚焦「管理三板斧」，建立好的企业文化 —— 没有合适的组织，一切设计都是空谈。
+
+**第四，地域因素限制。**
+
+不同地域也会对产品落地造成限制，但可能不会造成直接影响。比如具有高技术壁垒的底层基础设施产品，如果放在三线城市进行孵化，就会面临团队人才不足的情况；特定项目在上海临港新片区孵化可能会相对容易，在其他城市可能就会相对困难。这些都是客观存在的。
+
+**第五，风险承受能力。**
+
+举例来说，薄利多销且过于依赖场景的业务，风险承受能力可能就会有所欠缺。比如今年，疫情对许多线下业务几乎造成了毁灭性的打击。
+
+**第六，市场因素限制。**
+
+市场因素也是我们要重点考虑的，这就需要对市场动态保持一定的敏感度，不能闭门造车。
+
+除了业务限制，还要考虑**技术限制**，具体包括五类限制因素：
+
+**第一，遗留系统限制。**
+
+企业在系统建设的过程中，会引入一些商业套件软件或者自研系统。但同时，数字化资产管理可能没有做到位，导致很多设计文档缺失，相关负责人也不断变动。所以，后来人员很难再对系统进行升级。
+
+究其原因，主要是架构设计缺乏、研发管理缺失。遗留系统越多，对于后来迭代开发速度影响越大。
+
+新系统上线的时候，架构师的一个重要工作便是做系统的上下文架构设计、明确周边依赖，对于需要和周边遗留系统进行集成交互的组件或模块，要高度重视。这些都是关键的限制因素，可能因为一个小小的环节疏漏，就最终影响了工作的推进。
+
+**第二，团队技能限制**
+
+团队成员本身的能力，也是一大限制。一些团队刚刚经历了“大换血”，新成员需要成长。此时若要保证产品输出不变，势必需要在其他维度有所补充。
+
+**第三，现有基础设施限制。**
+
+前面我们讲过，企业的竞争壁垒来自于产品，IT 基础设施也是产品。基础设施强，团队能力就强，输入限制就少；反之，基础设施弱，团队能力就弱，输入限制就大。
+
+比如资源扩容的时间、访问数据服务的复杂程度、测试回归的能力等，都是非常重要的限制因素，对于研发速度、研发质量都有巨大的影响。
+
+**第四，标准规范限制。**
+
+一般来说，随着企业IT治理水平的提升，都会逐步建立企业范围内的标准规范。这些规范是企业最佳实践的总结、规划，但同时也对产品建设构成了限制。
+
+比如，一些企业会对研发语言有所限制。在某些情况下，精通 Java 语言的可用工程师比较少，但仍然要求用 Java 语言完成开发，这也会对输入产生限制。
+
+**第五，实施限制。**
+
+在实施方面，企业往往也会有所限制。比如，流程性的规定一般会对研发时间有所限制，做排期时需要纳入考虑。
+
+你看，一个产品从设计到落地，会受到如此多的输入限制。如果不考虑它们，一定会对“成功交付”造成很大的影响，最终影响工作目标的达成。
+
+讲完输入限制，我们再来理解一下所谓的输出限制。
+
+输出，是给用户的契约，我们在产品思维、高可用设计等章节都有所提及 —— 要给出清晰、可量化的、符合 “SMART 原则”的契约。可以说是“对契约做限制”，也可以理解成“要让契约更明确”。
+
+比如，在对系统进行容量规划后，架构师要对超出处理能力的流量进行流量控制。这就是一种明确的限制手段；再比如，如果机房只有一根光纤，就不要承诺系统 7 * 24 小时高可用；如果生鲜产品需要早上 7 点送达目标企业，那么原则上，晚上 10 点后就不再接单……
+
+这些都是限制，需要将其加入服务契约中，和用户形成共识，一诺千金。明确限制，是为了更好地服务用户，这是对用户负责的态度。
+
+## 产品迭代背后的项目管理
+
+在实际工作中，每个技术人员都会通过做项目的方式，参与产品的迭代。而做项目本身，就是一场关于“限制”的重头戏。
+
+你可能会想，做项目有什么可说的？我们的项目经理每天就会催、催、催，这活我也能干。
+
+其实，项目管理是一门专业度极高的学问。很多项目看似是因为一些意外情况延期、取消，实际恰恰是项目管理做得不够专业。
+
+在一个项目组里，有四类角色非常重要，分别是：
+
+- PM（Project Manager），项目经理；
+- PM（Product Manager），产品经理；
+- Architect，架构师；
+- Specialist，某一领域技术专家，比如 DBA ，分布式缓存专家，大数据专家等。
+
+在大型项目里，这四类角色可能分别对应着四个人，甚至更多；在中小型项目中，四类角色也可能只对应着一个人，这意味着，团队内有一个成员很强，可以同时承担这四类角色的职责。
+
+项目的成败，整体掌握于项目经理之手，因为项目经理要做好 WBS（工作分解结构）。项目在落地过程中，所有的节点监控、风险管理等工作，都依赖于 WBS 。
+
+WBS 有三大分解原则：
+
+1. 将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；
+1. 每个任务原则上要求分解到不能再细分为止；
+1. 日常活动要对应到人、时间和资金投入。
+
+前面我们讲了，业务因素和技术因素都会对输入产生限制，但具体如何对时间、人力、资源产生影响，影响程度怎么样，可不是拍脑门决定的。
+
+现在，很多项目经理做工作拆分的流程是：将所有相关人员叫到一起，分别询问各工作项的预估执行时间。可能各模块负责人自己也不太清楚，秉持着“ Timeline 要虚报”的原则，直接拍脑袋给了个上浮过的整数时间，比如：一个月、两个月……项目经理说，好！于是 Timeline 就这么确认了。
+
+这就是典型的非专业项目落地，最终不但造成项目时间的不可控、项目执行的低效，长期来看，也导致了业务各方、企业各层间的博弈，比如，老板会说，你们能不能更快点？你们是不是在“放羊”？
+
+有经验的项目经理在预估排期时，往往会问每个模块的负责人：“为什么这些工作需要 x 天的执行时间？有没有什么执行难点？”如果对方答不上来，或者该负责人也没有相关的项目经验，项目经理就需要找到有经验的人、有发言权的人，继续问：“这些工作需要多久做完，为什么？有没有什么执行难点？”
+
+看起来并不复杂，但实际上，是需要专业能力支撑的。项目经理凭什么做拆解，并确定任务间的依赖关系？答案是，要么组织产品经理、架构师、技术专家，一起分解任务；要么一人身兼四种角色，独立完成。
+
+WBS 制定完成后，产品经理以产品设计匹配业务需求，明确业务目标和业务流程；架构师负责整体的框架设计，明确对应组件的整体视图；技术专家负责扫清相关的技术难点。最后，Developer（开发人员）、Tester（测试人员） 进入项目，解决工作量问题。
+
+到头来，我们要明白，以上工作都是在输入、输出受限的情况下，保证产品不会因为执行问题而违背契约。反过来讲，执行团队本身也是输入的限制条件。也就是说，当缺乏优秀的项目经理、产品经理、架构师或技术专家时，就要相应地继续下调输出预期。
+
+而且，**项目同样受到 Time（时间）、Resource（资源）、Scope（范围）等多方因素限制，在执行时同样要考虑限制条件，其本质就是有“不完美”成分存在的。通过不断的迭代，产品最终变得完美，但项目不会一次就缔造一个完美的产品。对项目期望的合理管控，本身就是在考虑限制。**
+
+在做项目执行时，认识到这一点是非常重要的。
+
+## 延展思考：向上管理的“限制”问题
+
+把控好了输入、输出的“限制”，也做好了项目执行过程中的“限制”，基本上就覆盖了产品从 0 到 1 的整个流程。
+
+理论上讲，我们的产品应该不入险地，始终“高可靠”地完成契约交付。
+
+但实际情况未必如此。
+
+问题出在哪里呢？一个意外是，项目经理在做输出限制时，通常会遇到来自上层的阻力。
+
+比如，项目经理要立项研发企业 OMS 系统，但企业基础设施建设程度一般、团队技术实力较差，因此输出的契约是“三个月上线 OMS 系统”。老板看到了，可能就会问：“怎么这么久，一个半月行不行？”
+
+这时，一个很常见也很难解的命题就出现了：如何做好向上管理？
+
+在前面的文章里，我们其实分享过，要做好向上管理，第一要务是具备全局思维能力，和老板站在同一个维度思考。所谓的沟通技巧，只能锦上添花，不能雪中送炭。
+
+很多同学当时很有感触，但在沟通中，我发现，大家的认知可能还有偏差。全局思维，是为了对齐目标、统一话语体系，但在具体表达的时候，一定要体现自己的专业性。
+
+你的结论是：OMS 系统三个月上线；老板的想法是：OMS 系统一个半月上线。此时，你第一件要做的事，就是利用自己的专业知识和行业一般数据，将与 WBS 有关的思考和推断表达出来，尝试让项目按照正确的节奏落地。
+
+第二点同样重要：要从更快交付的目标出发，同时将多种限制因素考虑在内，比如团队疲劳度、凝聚力、激励措施等，和老板一起想办法，把自己想象成一个专业的 CEO —— 这公司就是自己的，进而思考应该如何安排工作、如何制定 WBS。
+
+你可能会说，老乔，那如果讲不清楚，应该怎么办啊？其实没啥办法，如果你不够专业，或者讲不清楚，那也只能认了。所以我对中层管理者的能力考察，包括：专业能力、汇报能力 —— 技术人不但要能干活，还要能专业地讲出来。
+
+最后，要千万注意：**具备全局思维、让自己变得更专业、提升自己的表达能力，这一切工作都不是为了和老板在项目目标上进行博弈。我们的目的是，通过更合理的实现路径，最终达成业务的增长目标。**否则，除非你非常优秀，是不可或缺的人才，不然一般都会在博弈中处于下风，对个人成长造成影响。
+
+## 结语
+
+今天，我们聊了聊面对产品，如何做好限制，尤其强调了对输入、输出以及项目执行的限制。在架构设计、高可用、高性能等内容里，我们无时无刻不在强调限制。
+
+很多同学，尤其是比较有上进心的同学都会想，强调这个干嘛呢？无论是什么工作，尽力去做不就好了吗？做成什么样算什么样，反正尽力了。
+
+其实，恰恰是因为有上进心，才应该尽全力交付为用户承诺的契约，所有组织最终都是结果导向的。产品有限制，说明当下仍有许多不足，知不足，才能知进步。
+
+限制，在企业层级，也意味着在企业发展的某个阶段，选择放弃某类用户。有放弃，才能聚焦，进而倒逼自己看到全局，和企业目标对齐。聚焦当下，学会取舍；放眼长期，持续进步、持续改进。
+
+到这里，关于如何做好限制，就基本讲完了。我们的专栏，也正式进入了完结倒计时。还是老样子，如果有问题，欢迎在评论区提问。
+
+我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对专业成长的复盘/24 | 监控设计，让一切都有迹可循，尽在掌控.md

@@ -0,0 +1,167 @@
+<audio id="audio" title="24 | 监控设计，让一切都有迹可循，尽在掌控" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/78/57/78fba3dd9b1e6d3e9c19f09da8505257.mp3"></audio>
+
+你好，我是乔新亮。
+
+这一讲，我想和你聊聊如何做好监控设计。
+
+你可能会想，为什么要聊监控呢？做监控不是很简单吗？
+
+所有做技术的同学，基本都会根据公司的日志规范，在代码中打印 Log ，以记录告警和报错。许多企业，也会将日志收集分析，以此形成对系统状态的监控。如果条件允许，团队还可以使用各类免费或付费的服务器监控报警服务，多方便啊，这有啥好讲的呢？
+
+其实在我眼里，这些都只是构成了监控的一部分，并非完整的监控体系。要想深刻理解监控的概念，我们首先要学会问自己：为什么要做监控系统？这就像许多工作方法论里强调的一样，做事先问目的 —— “start with why”。
+
+**监控的目标是及时发现系统的问题，并尽可能快地做出相应的动作，让系统一直处于健康的状态**。监控，可以拆分为“监”和“控”分别理解，其含义恰好对应着两种主要手段，也就是“**监视**”和“**控制**”（中文真是博大精深）。
+
+比如说，生产环境出现了个 bug，怎样定位问题？这需要做好“监视”；发现问题根源后如何正确响应？这需要做好“控制”。
+
+比较无奈的情况是，研发人员知道系统出了问题，但无法定位问题；更悲催的情况是，研发人员能够定位问题，但无法控制问题，只能眼睁睁地看着故障发生。但无论哪种情况发生了，从结果来看，其实区别都不大。唯一的区别可能是，前者至少让人心存希望，后者则让人感觉整颗心都“冰凉冰凉”的。
+
+说到这里，我不禁有点感慨：监控、监控，意味着既要监视也要控制，没有控制的监视达不到目标，没有监视的控制无法形成行动计划。
+
+从业至今，我曾处理过许多因认知不足，而导致的系统监控问题。下面，我们就选取其中一件比较典型的案例，尝试着一同复盘下。
+
+## 技术团队的“怪现象”
+
+这个案例发生于某日下班后 —— 大约是在傍晚 20:00 左右，团队发现了一个出现在生产环境的异常。该异常来自一个可以连接众多终端设备的程序，其具体表现为：所在服务器的 CPU 负载突然飙升。但发现异常后，团队既无法将其恢复，也无法定位问题。
+
+发现问题后，共有十几位工程师先后参与了问题分析。很快，两个小时就过去了，监控系统仍然显示 CPU 占用异常，问题还是没有解决。这下，产品负责人着急了，向我求助，并将我拉进了问题调查组的电话会议。
+
+进入会议后，我立刻问了大家一个问题：
+
+“最近线上有什么版本变动吗？都回退了吗？”
+
+团队回答道：“都回退了。”
+
+我几乎没有任何犹豫地说道，不可能，一定没有全部回退。
+
+要知道，计算机是非常可靠的。如果一套代码在一台机器上可以正常、稳定地运行，那么在外部环境没有发生任何变更的情况下，一周、一个月、一年后，它大概率能继续保持正常、稳定地运行。
+
+你可能会想，老乔又开始信口胡说了，难道就没有意外情况吗？
+
+有，我也确实遇见过，但在近 20 年职业生涯里，我只遇见过一次（ZooKeeper 因虚拟机连接数过多而崩溃事件，在“高可用设计”部分，我们曾简单提到）。所以，这种情况几乎是“可遇不可求”的，在大部分时间里都可以直接忽略。
+
+果然，在我的追问下，负责发布的同学说，系统没有回退到上一个版本，而是按研发同学的指挥选择性回退的。
+
+好呀，真相大白，我命令他迅速按公司研发制度回退。
+
+没成想，回退到上一版本后，系统依然不正常。于是，团队继续查看前端、服务端、数据库等各类监控数据，试图分析问题到底出在哪里。
+
+我再一次找到团队，问道，真的都回退了吗？
+
+团队可怜兮兮地回答，真的都回退了！
+
+我的回答是，不可能，鬼才信你们…… 于是，我开始继续不依不饶地追问。
+
+终于，在我的“威逼利诱”下，有位同学一拍脑门，犹豫地说道：“我在数据库里加了条索引，不过这肯定不会导致负载异常……”
+
+还没说完，我就哭笑不得地打断了他的话，谈这些做什么？赶紧回退去。
+
+当这个改动回退后，一切都恢复了正常。
+
+最终，一个本该三分钟内被搞定的生产问题，用了几个小时才解决。幸亏发布窗口是业务低峰期，否则已酿成重大损失。在许多公司里，相关人员几乎一定会受到处罚。
+
+事后复盘时，我问团队，当我询问版本有无全部回退时，为何不及时声明？
+
+那个同学委屈地说，我以为那条索引不可能惹出这么大的问题……
+
+请注意，在这个故事里，当事人员并不是毫无经验的新手；公司并非没有监控系统，相反还做到了可视化、图形化。
+
+既然如此，为何团队还会被一条小小的索引命令阻滞这么久呢？这是一个非常奇怪的现象。而且，在参加 GTLC 全球技术领导力峰会时，我在和一些同学的沟通中也发现：这种现象并非孤例，很多团队都曾出现过类似的情况。
+
+于是，我不得不去思考，IT 团队的系统监控体系，到底出了什么问题？
+
+## IT 团队的系统监控体系，到底出了什么问题？
+
+当陷入思考的泥潭时，我们往往需要将思维抽离，尝试站在更高维度探寻问题的本质。此时，我们不妨将这个案例暂且放一放，重新思考一下监控的本质含义。
+
+在文章开头，我们讲过了，**监控是为了让系统一直处于健康状态，具体的手段包括“监视”和“控制”两种**。简单来说，就是当生产环境出现问题时，我们要能知道哪里出了问题，并具备相应的控制手段。
+
+生产环境应急恢复的最大挑战在于根因分析，即找到问题的根本原因，这往往是耗时最久的工作。
+
+但如果没有控制手段，那么即使找到了根因，团队也是无能为力，只能干着急，或者静静地期盼奇迹出现，好像系统在下一分钟就能自动恢复健康。
+
+所以，当生产环境发生异常时，大部分团队会这样组织故障恢复工作：
+
+1. 发现问题后，立即联系各相关系统负责人，以便共同排查问题；
+1. 要求大家在一分钟之内回复：自己治下的系统或服务是否健康（这里要将“健康”的定义想清楚，如，响应时间是否增加超过 30% 等）；
+1. 进行根因分析，确认导致问题的系统、服务；
+1. 完成系统恢复工作。
+
+对于步骤  1、2 ，其实挑战都不大，真正的挑战在于步骤  3、4。步骤 3 依赖于相关分析人员的专业程度。一般情况下，随着企业业务的复杂度逐渐增加、系统和服务的数量逐渐增加，人员规模也会越来越大，在步骤 3 上花费的时间就会脱离控制。
+
+此外，对于步骤  3 中涉及的不健康组件，我们需要分析：这种不健康状态是原因，还是结果。关于分析方法，其实也比较简单：
+
+1. 首先，我们要确认异常是外因导致，还是内因导致。比如，服务响应慢，既可能是因为外部调用量变大，也可能是因为内部进程繁忙，导致 I/O 、内存、网络资源发生争抢。这步判断相对来说比较耗时间，只有当调查足够充分时，结果才可能浮出水面；
+1. 无论是内因还是外因，都要“顺藤摸瓜”，继续进行排查，最后进行恢复。
+
+说到这里，我们不难得出结论：生产应急保障体系的建设，并不像大家想象的那么简单。从系统复杂度到人员专业性，任何不足都会导致问题定位、根因分析花费更多的时间。因此，以上故障恢复流程也存在很大的隐患。
+
+那么，难道生产系统出了问题，我们就只能坐以待毙吗？有没有一个对团队专业度依赖较低的方法呢？答案是，有的。我把它总结为：**流控和版本回退，简单、粗暴、实用**。
+
+流控，就是做好程序的并发流量控制；版本回退，就是在生产环境的发布出现问题时，及时回退到上一个版本。
+
+**生产环境出现问题，原因通常只有两个字：变化**。常见的“变化”大致有三类：
+
+1. 外部用户请求量增大；
+1. 产品发布，一般包括代码发布、配置发布、SQL 脚本发布等；
+1. 依赖资源变化，一般是计算、存储、网络基础设施情况变差，比如磁盘存在坏道等。
+
+这样看来，当故障发生时，我们不一定要组织团队进行复杂的根因分析 —— 那是故障恢复后的事儿。相反，只要我们控制住了服务的近期变化，也就等于控制住了故障。思路一变，好像就豁然开朗了。所以， 我们不妨将生产应急恢复方法修改为以下 4 条：
+
+1. 发现问题后，立即联系各相关系统负责人，以便共同排查问题；
+1. 要求大家在一分钟之内回复：自己治下的系统或服务是否健康（这里要将“健康”的定义想清楚，如，响应时间是否增加超过 30% 等）；
+1. 此处组织两批研发力量，并行工作。第一批解决专业问题，继续跟进问题的定位和调试；第二批负责消灭变化，对有变化的模块进行回退，对于外部请求数量升高的模块启动流控；
+1. 恢复系统。
+
+你看，这样就降低了故障恢复对于团队专业性的要求。只要我们保证，对于任何组件，都有以下两种手段同时存在：
+
+1. 流控手段；
+1. 发布回退手段。
+
+是不是很简单？在 IT 行业，对于专业团队而言，一般没有太过复杂的工作；如果工作过于复杂，往往是因为负责人不够专业。还是那句话：大道至简。
+
+问题的关键在于，生产环境是不允许查找 bug 的。**在生产环境，研发人员应该寻找并消灭“变化”。从寻找 bug 到寻找变化，是一个非常大的认知转变。**
+
+此时，再回顾文章开头的案例，答案就比较清晰了。团队在执行生产环境故障恢复工作时，接连犯下了三个错误：
+
+错误一：负责发布的同学，没有按规定回退至稳定版本，而是询问开发同学的意见，并以其意见为准；
+
+错误二：相关负责人，因为假设“一条索引不会导致故障”而知情不报，导致系统无法完全回退；
+
+错误三：十几名团队成员没有将精力聚焦在线上业务恢复方面，而是试图在生产环境查找 bug。
+
+三个错误如出一辙，全部来自于技术同学的思维惯性。在大家的认知里，制度就是拿来参考的，对应模块的负责人才是专业的，出了事先找人再问制度规范，或者压根不问制度；在大家的认知里，bug 要用排除法解决，“确定”没问题的模块就要排除在外；在大家的认知里，能一眼发现错误的程序员，才是技术高手，如果动不动就回退，和“网管只会重启”有什么区别？
+
+但是我想说的是，当问题发生时，你的潜意识是要找到 bug ，还是找到变化，对应的结果可能是完全不同的。我们的目标是，**即使找不到 bug，依然可以做好故障恢复**。
+
+这样的思维惯性有多么普遍呢？我们举个例子：你是否曾在下班回家的路上，被老板电话叫回公司，查找线上 bug  ？
+
+也许你会觉得这样做很合理，但听完这节课以后，希望你能够意识到这种做法的局限性：线上有 bug ，为什么需要研发立刻回公司？先回退就好了嘛。否则，研发现场写程序，压力也是挺大的。
+
+更别提，一些团队还经常出现喜剧性的一幕：生产环境出现了问题，研发火急火燎地改了个版本，结果系统做不到秒级发布，单是发布就用了半个小时。好不容易上线了，还没来得及高兴，就发现了个新问题……
+
+我们必须不断强调并加深印象：**生产环境永远不允许调试问题，出现问题立刻回退，查问题要去测试环境**。
+
+你可能会想，老乔啊，你这就有点纸上谈兵了，很多大型发布涉及多个系统，怎么可能随便回退呢？
+
+其实这个问题，亚马逊在十几年前就给出解决方案了：**大版本立项，小版本上线** —— 梳理好各模块的依赖关系，将各个系统、各个服务独立发布。当然，这也需要依赖服务版本化和 CI  能力的支持。
+
+以上我们讲的是对企业系统的监控。除此之外，我们也要做好对企业业务的监控。
+
+也就是说，对于企业任何一个未处于理想状态的业务环节，都要进行监控：做好问题的可视化展现、明确管理执行动作，通过数据化管理，不断完善企业的运营效率和运营质量。道理其实还是相通的。
+
+如果能做到监视一切，分析一切，控制一切，“眼”能看见所有，“脑”能洞察一切，“手”能一手遮天，一切业务数字化，一切数据可视化，一切控制可触发，那么，这个企业的数字化水平一定已经很高了。
+
+## 结语
+
+今天，我们从一个实际案例出发，主要聊了聊关于企业生产环境系统监控的认知和方法：**监控的目的是让系统一直处于健康状态，具体手段则可分为“监视”和“控制”两种；要做好控制，一个重要的方法是做好流控和版本回退。因为在大部分情况下，消除变化就等于消除异常。**
+
+实际上，不单是技术、业务系统需要做好监控，研发管理、团队管理都要做好监控。
+
+关于研发管理，我们在“高可用设计”部分曾提到：风险是经由开发环境、SIT 环境、压测环境、PRE 环境，进入生产环境的。所以我们要做的是严格检查各个环境下的异常。所谓研发管理规范，应该为代码版本进入下一个环境设置准入标准。对于任何异常，都有负责人进行修正。
+
+对于团队管理，我们常常说，组织是结果导向的，但管理工作是过程导向的。关注过程自然就会得到好的结果，只盯着结果往往什么也得不到。对于一个项目、一个产品，乃至于团队的健康度，管理者有没有在关键节点设置监控？有没有针对异常做好控制？其差别是巨大的。
+
+如果你认真学习了前面的内容，可能也会发现，无论是管理还是专业技术，很多关键认知都是相通的。很多时候，是“一理通百理明”。在学习的同时，前后交叉思考，也有助于你在更高的维度上掌握这些知识。
+
+今天，我们就聊到这里，下一讲再见。

极客时间专栏/乔新亮的CTO成长复盘/对专业成长的复盘/25 | 异常设计，让错误无处遁形.md

@@ -0,0 +1,132 @@
+<audio id="audio" title="25 | 异常设计，让错误无处遁形" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/bd/7c/bd36aa257f192yy62604d87256aab27c.mp3"></audio>
+
+你好，我是乔新亮。
+
+今天，我想和你聊聊有关异常设计的话题。
+
+如果你认真听了前面的内容，那么对你来说，异常设计应该不是一个新鲜概念了。在高可用设计、监控体系建设部分，我们都聊到了对异常的管理。
+
+那么，为什么今天我们又要单独聊异常设计呢？因为异常管理虽然属于监控体系的一部分，但并不完全依赖于监控体系或高可用设计。**在企业的监控体系建设完成前，异常设计一般就可以独立发挥作用，达到快速见效的目的。**
+
+异常管理可以提升 IT 团队快速定位问题的能力、降低生产系统异常出现的频次和数量，更重要的是，它是让 IT 团队从面向技术，转为面向产品、面向用户的关键步骤，所以我们这里独立出来讲。
+
+那么，在开始之前，我们有必要明确一下，究竟何为异常？
+
+你可能会想，导致系统不能正常工作的问题就是异常呗。
+
+说得对，但不全对。有些异常，可能当下未必会对生产环境产生影响，但不代表未来也不会；有些异常，可能在流量压力小时未必会出问题，但不代表流量压力大时也不会。
+
+就像在平时，每位同学都会打印 Log，有 Warning，有 Error。大部分同学关注 Error，而不关注 Warning ，甚至有时 Error 也是选择性忽略的。反正打印这些，也不一定会导致线上服务受影响，看看就得了。
+
+但很可能恰恰就是这些被忽视掉的 Error 和 Warning，最终导致了严重故障的出现。
+
+所以，所谓**异常，指的就是那些让产品无法履行当初承诺用户的契约的问题。**
+
+下面，我们通过几个具体的例子来理解一下。
+
+## 那些被忽视掉的异常
+
+早些年，经常网购的同学，可能听说过电商界的两个绰号：“二手X”、“无货X”。
+
+商品缺货、出现品质或质量问题，一直以来就是电商界的两大“顽疾”。但严格地说，这些都是因仓储系统、订单系统、质量监测系统不够完善，而导致在业务运营层级发生的概率性问题，并非研发同学心目中的“恶性故障”。
+
+但随着用户规模的增大，原本“不值一提”的低概率问题就会被无限放大。举个例子，一家电商平台缺货的概率可能只有 2%，也就是说，配货成功率高达 98%，看起来没啥问题。但当平台用户数量达到一百万时，就会有多达两万人受到缺货问题的困扰。这两万人中，可能只有 30% 的用户有在社交平台发帖的习惯。可即便如此，也会有 6000 人出现在各大社交平台上，发帖吐槽该电商平台的缺货、质量问题。
+
+“好事不出门，坏事传千里”，于是，“无货 X”、“二手 X”的绰号就出现了，企业声誉严重受损，用户对企业的信任也极大降低，企业需要付出更大的努力来赢回用户。
+
+所以，许多你不太关注的异常，最终会在产品层面对用户体验产生恶性影响。一般情况下，产品经理对这类问题的感知更敏锐，但职能型研发组织中的产品经理往往不参与代码编写，一般也不会深度参与开发过程；对于程序员来说，通常也不会主动和产品经理沟通类似问题。
+
+于是，这类问题往往会顺利通过开发、测试，最终进入生产环境。在没有异常设计的情况下，让用户买单。**那些用户经历的坏体验，对于开发人员来说，可能只是一个简单的错误提示而已。**
+
+当然，这是业务和产品层面的异常。对于很多普通技术人来说，对于底层技术层面的异常，可能更为熟悉。
+
+我曾听一位做 C++ 服务器开发的同学，讲过他们企业发生的趣事。他们经常会处理许多到不同 CDN 节点的高频下载请求，但会有一部分下载超时或耗时增加的异常出现。
+
+他们当时的做法是，当下载耗时超过 200ms 时，在 Log 中打印 Warning ；当下载因超时而失败时，设置定时重试，并在 Log 中打印 Error 。
+
+我好奇地问，然后呢？
+
+他回答，然后就没什么啦，重试一般都能成功。
+
+我继续问，如果一直不成功呢？
+
+他挠挠头，那可能就会导致业务出问题了，研发就得起床查 Log 了。
+
+我又问，如果重试可以成功，但当并发压力增大时，来不及多次重试呢？
+
+他尴尬地笑了下，没说话。
+
+你看，往往我们在做所谓的“异常设计”时，并没有实现给用户的契约。对于电商平台而言，没有实现“成功下单 = 成功配送”的契约；对于那位做 C++ 服务器开发的同学来说，没有实现给其他系统模块的“准时下载”的契约。
+
+大家通常认为，当下的异常没有导致生产环境出现严重问题，所以以后也不会出问题，但实际情况往往不是这样。
+
+在我看来，没有兑现契约，即为异常，就应该控制起来。
+
+那么，到底怎么做好异常设计呢？我们大致可以分为三部分来理解，分别是认知、方案和治理。
+
+## 对于异常设计的认知、方案和治理
+
+首先，对于异常设计，有五点认知一定要明确，分别是：
+
+1. 异常一定要消灭：有异常，基本就意味着系统存在风险，一定要消灭异常；
+1. 异常一定要管理：消灭异常是个长期工程，短期要通过管理行为来进行控制；
+1. 对异常的处理水平，会极大影响产品的用户体验：用户规模越大，异常的影响往往越大；
+1. 每个异常都要有具体的负责人：没有和具体的负责人一一对应，往往就意味着管理流于形式；
+1. 与终端用户相关的异常，要以最高优先级处理：即便是 IT 研发，也要以用户为中心。
+
+有了对异常的正确认知后，我们就需要在体系上对异常进行管理。
+
+前面，在高可用设计部分，我曾经分享了“交易体系”和“协同体系”的设计差别。简单来说，交易体系负责处理相对稳定的业务流程，协同体系则是当异常出现时，需要接入的流程。比如客户要订 500 斤白菜，由交易体系来完成，库存满足、正常履行；库存不足时，则需要协同体系完成剩余流程。
+
+但很多同学只做交易体系，不做协同体系，只抛出异常，而不处理异常，因此常常会引领用户走上“断头路”。在某些情况下，用户无路可走，只能找客服投诉。
+
+认知到位后，下面我们一起来看如何落实异常设计。**异常设计一般包含异常注册、异常事件触发、异常协作流程以及异常统计。**
+
+要管理好异常，我们首先要完成对异常的注册，注册内容大概分为以下几项：
+
+1. 异常的 ID 和名字；
+1. 对异常的描述；
+1. 异常出现的代码位置；
+1. 负责此异常的研发、测试和产品人员；
+1. 异常发生时的代码版本；
+1. 当时使用的异常处理程序。
+
+同时，企业也要建设异常中心，各个系统都要在异常中心注册异常，一旦运行阶段出现异常，就要抛出异常事件，触发异常处理的协同流程。
+
+当然，很多企业在还没有很好地管理异常时，就已经建设了大量的系统，因此很难再做异常设计。但很多异常都被记录在了日志里，因此研发同学可以通过收集日志中的异常，继而进行归类处理，再通过异常治理完成异常的注册，这样就间接达到了目标。
+
+异常注册、收集后要做什么呢？当然是交由相关负责人进行处理了，这时我们就进入了异常的治理流程。不是所有的异常都要从 Log 中消失，但对于保留下的异常，一定提交管理层进行审批，说明保留原因；理由不够充分的，需要按排期规划并解决。
+
+比如到 CDN 节点的下载行为有一定概率会失败，我们就要调查究竟是服务商提供的节点有问题，还是系统程序在编写方面有问题，又或者是相关机房的网络情况不好。总之，问题一定要明确并解决掉。
+
+管理层也要关注异常的处理情况，包括：
+
+1. 异常的数量；
+1. 异常的发生频次；
+1. 系统内异常数量的增速或降速；
+
+……
+
+在季度末、年末，我们会对管理层进行绩效考核，并将异常管理情况纳入考核体系，以此实现异常治理的闭环。
+
+你可能会想，写个代码可真难啊，越来越麻烦了。不要怕麻烦，要关注投入产出比。做好异常设计，我们既可以做到高可用、高可靠问题的防微杜渐，还可以帮助研发和测试人员快速定位 Bug。最重要的是，在企业层面，我们可以**实现用户体验驱动内部经营完善的经营逻辑**。对于一个技术人来说，这无疑是能帮助你上台阶、再成长的。
+
+在苏宁的时候，我主导研发了“神鉴”系统，目标就是为了做好企业的异常管理。在彩食鲜，我们也在不断完善异常管理，虽然时间不长，但相关工作已经卓有成效。前几天，相关人员还汇报道，我们科技中心所有产品的异常码都已经被统一管理起来，相关异常编码、响应信息都会被实时收集、归类，保证可视化、可统计。
+
+你看，当我们能把繁杂的技术细节，纳入体系化的管理流程里时，还有什么样的困难我们克服不了呢？
+
+当你用这种思路去管理异常时，就可以对一家企业有更深入、更近距离的了解。**只要仔细观察一家企业是如何对待异常的，就可以判断这家企业的精细化运营和管理水平。**
+
+## 结语
+
+今天，我们聊了聊与异常设计相关的话题，最终的目的，是让企业的潜在产品和研发问题，全部暴露出来，达成最好的产品体验。
+
+但在落地异常设计时，也一定不要着急。要知道，异常，是会和我们长期共存的，对异常的处理和记录，也会逐渐成为企业数字资产的一部分。
+
+**对于直接影响用户体验的问题，要有契约精神，快速迭代；对于企业宏观角度的异常治理，要坚持长期主义，不断优化。**
+
+此外，企业的一个核心竞争力就是持续进化的能力。因此，在保持进化的过程中，企业发生的任何问题，都要纳入到异常管理流程中，将异常管理数据化、产品化、系统化，通过持续的治理和数据分析，让企业不断进化，最终建立竞争优势。
+
+相信你一定能将异常管理做得越来越好，让一切错误无所遁形。
+
+我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对专业成长的复盘/26 | 上云设计，融合云计算的未来.md

@@ -0,0 +1,159 @@
+<audio id="audio" title="26 | 上云设计，融合云计算的未来" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/99/2f/997c3513a3d944e10ac637f27fa2692f.mp3"></audio>
+
+你好，我是乔新亮。
+
+如果不考虑本周五将要更新的“结束语”，那么实际上，我们已经来到了整个专栏的最后一讲。在这一讲里，我打算和你聊聊有关“上云设计”的话题。
+
+为什么要在这样的时刻聊起云计算呢？
+
+这其实和当代 IT 产业的发展趋势有关，可以说，云计算产业的成熟，直接影响了很多问题的思考方式。
+
+前段时间，我找到团队内的一位核心架构师，请他去调研关于企业上云的可行性，培养他做架构决策的能力和思维。其实，对于我来说，调研的结果并不重要，因为我早就在心里打算好了：我们一定要上云，彻底拥抱云计算。让团队去调研可行性，更多是为了做好团队的能力培养。
+
+说到这里，你可能会觉得有些似曾相识。没错，在专栏里，我曾多次提起对云上资源的规划。
+
+比如，在“高性能设计”一节，我们谈到拥有云上秒级扩容能力，会给运维工作带来哪些帮助；在“扩展性设计”一节，我们提议，对于非核心系统，在需求较为匹配的情况下，直接选择购买套装软件或云服务。
+
+类似的例子还有很多，最终可以归结为一个结论：企业要上云，并且未来一定会上云。
+
+当然，我不是一拍脑门或是收了赞助费，所以跑来建议大家上云。而是整个 IT 产业的发展趋势，迫使我们顺应时代。如果不能形成正确认知，与趋势为敌，一定会影响企业或者自己的发展。
+
+所以接下来，我们要站在全局视角，尝试看透 IT 和云产业的价值与发展。
+
+## 对 IT 技术和云计算的发展趋势判断
+
+整个 IT 产业的发展历程，起始于硬件方面的发明创造。
+
+1946年，英国剑桥大学成功研制出第一台冯·诺依曼机器： EDSAC 。近十年后，相关的编译程序和编程语言才出现。
+
+但直到 1964 年 IBM 推出 System/360 以前，所有的计算机都是面向用户定制的，没有统一标准，设计上也没有连续性。IBM System/360 的出现，标志着计算机开始走向通用化、系列化和标准化。
+
+1981 年，IBM 推出了世界第一台个人 PC，体型大幅缩小，是计算机走进千家万户的开始。站在历史的角度看， IBM PC 尤其有重要意义。
+
+但如果让一个生活在 2020 年的程序员来看， IBM PC 无疑差到令人发指 —— 它的内存只有 16k，存储还要靠盒式录音磁带或 5.25 英寸软盘，售价却高达 1565 美元，真是又贵又难用，性能都不如现在一款价值几百元的老年手机。
+
+当然，IT 软件的发展也没比硬件好多少。如果你是计算机软件专业出身，很可能学习过汇编语言，也就是面向机器的程序设计语言。现在看来，汇编语言非常难以理解，编码也很复杂。到现在，已经很少有软件公司，会用汇编来开发软件。
+
+那时，人们很难想象，会有 Java、Golang 这样的语言应用在软件开发行业，极大降低研发成本，提升了研发效率。
+
+从汇编语言到 Java ，从最早的 IBM System/360 到如今的计算设备，技术发展表现出了一个明显的趋势：底层黑盒化、价格亲民化。也就是说，**我们越来越不需要关注技术细节，同时技术的价格也越来越亲民。**
+
+当这些技术或服务，被整合成产品，连入互联网，使客户可以按需购买时，云计算就出现了。
+
+站在应用软件角度看，现在的 IaaS 软件已经非常成熟，PaaS 和 SaaS 软件也在迅速发展中。到目前为止，Salesforce 可以说是最成功的 SaaS 软件。
+
+说了这么多，关于 IT 技术和云计算，二者的发展究竟呈现出什么样的特征呢？我将其总结为以下五点：
+
+1. 形态产品化；
+1. 价格平民化；
+1. 自助服务；
+1. 按需付费；
+1. 网络访问。
+
+在某种意义上，云计算可以理解为各类云服务的统称，而所有这些服务，都是通过产品来体现的。在今天，云产品仍然在向前快速发展，站在旧有产品的肩膀上，融合进旧有产品的生态里。
+
+推动这种发展向前的力量，不是某家公司 CEO 的个人意志，而是“**技术基座不断上移**”的社会客观需求。
+
+科技不与人争利，只有人与人之间才会争利。技术进步推动了社会的进步，因此自有其普世价值，也会越来越平民化。**看清趋势，拥抱趋势，在技术<strong><strong>演进早期，选择**</strong>恰当时间，积极应用，拥抱技术红利，**<strong>就**</strong>可以为企业赢得阶段性的领先优势</strong>。
+
+在经济学概念里，如何实现社会效益的最大化？答案是，专业分工。在数字化世界里，逻辑其实是同样成立的。最明显的特征是，对于云产品来说，只要客观需求存在，就一定会有人去尝试解决，并包装成产品售卖。
+
+比如，DevOps、微服务框架、多云管理、深度学习训练服务、边缘计算服务、量子计算服务……只要你需要，基本就能找得到。
+
+对于云计算厂商来说，只要不是企业核心的业务逻辑，所有“技术基座”都可以云化，让专业的人干专业的事，客户只需要付费购买就好。
+
+对于**甲方企业来说，IT 投入是价值成本，需要持续加大投入，但迫于经济规律，<strong><strong>最终**</strong>不得不寻求公共技术的社会化</strong>。
+
+双方的深层需求是契合的，也符合让社会效益最大化的经济学原理。所以，关于 IT 技术和云计算的发展趋势，我一直认为有两大结论是非常关键的，分别是：
+
+1. 数字化转型的结果是：云会吞噬一切；
+1. 云不仅仅是技术，更是最好的商业模式。
+
+明确了这两点，我们才能知道，该如何正确地看待这场“变革”，并寻找个人或企业的发展机会。
+
+## 坚持拿来主义，不要和趋势为敌
+
+我相信，至少有五点认知，你一定要关注，并多加思考。这些认知，既适合普通工程师，也适合 CEO/CTO ，区别是，站在何种角度去思考，以及如何做决策。
+
+**第一，从业务发展的角度出发，倒推上云规划。**
+
+你可能会想，老乔这个大忽悠，按你这么说，CTO 干脆啥也别想，直接上云就可以了。
+
+当然不是了，上云是为了帮助业务降本提效，做任何事都要从目标出发。从前，我曾主导企业的 IT 设施上云规划，就在同云计算厂商的合同里，明确写道：
+
+“完成迁云后，在同等资源下， IT 年度总支出费用相比 20xx 年降低 55%。20xx 年为迁云实施阶段，年度迁云总费用不得高于前一年 IT 相关基础设施、技术平台总费用。”
+
+当然，云产品带来的价值，不仅是资源节省，还有人力节省、加速研发等，这些都可以换算成财务价值。
+
+如果你上了云，IT 开销反而更大了，那说明整个规划和管理一定存在问题，先不要上云。
+
+**第二，坚持“拿来主义”，不要在企业层面重复造轮子。**
+
+其实在前面的内容里，我们有聊到过这一点，但很多做技术的同学，依然对此十分执着。
+
+经常有同学找到我说，老乔，XX 功能我们自己完成吧，我们自己做得更好！做得更好，到底是怎么个好法呢？用我们前面讲的知识来理解，也就是要明确给“用户”的契约：“你要消耗多少成本，在多长时间内，实现一个什么样的产品，性能表现怎么样？”
+
+大部分同学，可能并没有明确这个契约。有时，老板也会犯糊涂，仅仅是听研发负责人这么一说，就不假思索、大大方方地同意了。
+
+通常，在项目刚启动时，在开源项目的加持下，可能只需要两个人参与开发，人力成本并不高。可一个季度后，负责人就会找到老板，要求将项目组扩充至五人。又过了一个季度，可能项目组就变成了十个人。老板这才发现自己上了“贼船”，该项目仿佛一个“无底洞”，自研成本早已远远超过购买云服务的开销。
+
+当下，许多的 IT 研发工作都是重复造轮子，美其名曰为“沉淀企业 IT 基因”，实际就是浪费 IT 资源，对业务发展施加反作用。企业经营要务实，对于非核心业务，坚持“拿来主义”，不要过于理想主义；对于核心业务，坚持长期投入，建立团队推进自研工作。
+
+**第三，别害怕上云，<strong><strong>和**</strong>乙方**<strong>一起**</strong>搞定障碍。</strong>
+
+很多技术管理者一提上云就如临大敌：顶层规划怎么做呀？云上架构怎么设计呀？应用怎么迁移呢？怎么把云用好呀？怎么选择云厂商啊？
+
+还没正式见过服务商们，就先把自己吓了个半死 —— 这么多问题都不懂，我们团队可能支持不了上云改造，要不计划先搁置吧。
+
+依据我在企业上云方面的经验，上云规划涉及的内容会非常多，包括：上云方案、现有系统评估、云平台成本优化建议、迁移方案、云主机的功能和指标、网络带宽指标、跨国专线带宽指标，等等。
+
+在当时，团队也是第一次做上云迁移，很多内容都不懂。这份文档的内容，部分是我们根据自身需求提出的，部分来自于云厂商对自己亮点的介绍。最终，文档在不断地沟通和商业谈判中丰富起来了。
+
+**第四，开放心态看待数据隐私。**
+
+很多人对公有云比较抗拒，担心数据隐私泄露，担心竞争对手派系的企业盗用自己数据。其实我认为，大可不必担心。我个人的观点是，云厂商不会在公司层级盗取你的数据，但有可能因为管理不善而导致数据泄露。
+
+可我们也要多问问自己，自己管理的数据就安全吗？比头部云厂商的管理更加安全吗？
+
+我看未必。当然，如果实在不放心，大可以选择私有化部署，一样能解决问题。
+
+**第五，正确看待云计算的“负面影响”。**
+
+听到这里，你可能还是不太放心，老乔，云计算真的那么好，一点负面影响都没有吗？
+
+肯定还是有的，但客观地讲，这些更多属于组织和文化层面的问题。最近几年，在和许多管理者朋友的交流里，我愈发明确了一个事实：技术基座的上移，最终会导致部分初级开发者失去工作机会。
+
+听起来有点耸人听闻，但这是事实。以前，有许多人安于码代码，拒绝思考，同时也拒绝追求卓越，自嘲为“搬砖码农”。但“搬砖码农”的数量未来一定会减少，云计算的成熟会大大加速这一过程。
+
+如果企业奉行的不是以业务为中心，以产品为核心的组织文化，不具备我们前面所讲的、优秀的组织架构，就很可能在上云问题上陷入多方扯皮。因为，这触动了部分人的“蛋糕”，打扰了部分人的浑水摸鱼。
+
+所以上云，依然是个一把手工程。
+
+以上五点，是在上云过程中，许多人都可能存在的困惑与实际问题，如果要将其总结为一句话，我认为是：坚持“拿来主义”，不要和趋势为敌。
+
+我们要明确地意识到，未来，专业分工一定会越来越明确，技术基座一定会不断上移，每家企业都可以忘掉底层技术细节，聚焦自己的核心业务逻辑。因此，这条思考脉络最终也会回到出发点，形成闭环：对于大部分商业公司（非技术产品或云计算公司）而言，技术只有在成就业务时，才具备真正的价值。
+
+## 结语
+
+曾经，许多研发同学都喜欢找到我说，老乔，你看我做的这个软件，太厉害了，我技术厉害吧？
+
+我经常打击他：有啥厉害的，你这做的就是个玩具嘛。
+
+你可能会有点不解，怎么就是个玩具呢？答案很简单，真正厉害的技术，要能包装成产品，对外售卖或提供服务。用户愿意为之付费的，才是好东西。再多的夸奖，也不比金钱更有说服力。
+
+我常常说，要站在未来看当下，用十年后的眼光看现在。由此出发，可见对于很多研发同学来说，个人成长路径其实只有两条：
+
+1. 成为技术管理者，进入商业公司，采用技术产品或云服务，洞察业务，帮助业务成功，实现业务价值；
+1. 成为技术专家，进入纯技术公司或云计算公司，设计开发技术产品，提供技术服务。
+
+无论哪一条，其实都已经注定要和云计算的未来融合在一起，云计算会成为未来的水、电、燃气、交通工具。
+
+一定要尽早形成对此事的正确认知，大胆地拥抱新的技术趋势和机会。等到大家都看清云计算的发展情况，全部开上“汽车”时，无论是我们的个人发展，还是企业的发展，也就谈不上什么先发优势了。
+
+当然，很多企业没有认真规划过自己的技术平台，因此也比较难以上云。但如果在企业内部，就存在一个底层技术平台，那么，这就很接近企业级别“云平台”的概念了。与此同时，如果我们能保持开放的心态，那么外部平台就只是一个候选方，和企业生态内的云平台并无本质区别。
+
+农业社会的核心生产力是农民，工业社会的核心生产力是工人，信息社会的核心生产力是码农。经济学原理告诉我们：个人价值是通过稀缺性来体现的。看清趋势、拥抱趋势，才会让自己变得稀缺，才能让自己越走越顺！
+
+到此刻为止，我们专栏的正文内容，就全部结束了。感谢你一直以来的陪伴！
+
+还有一篇“结束语”，马上会和你见面，我们下一讲再见！