乔新亮CTO成长复盘总结（三） 对专业成长的复盘

（一）对个人认知的复盘
（二）对管理工作的复盘
（三）对专业成长的复盘

乔新亮CTO成长复盘总结（三）

对专业成长的复盘

17、架构决策：技术管理者最重要的能力

决策的重要性

• 技术债的根源: 架构决策失误是技术债的主要来源，错误的决策会导致企业需要花费数年时间来纠正。这不仅浪费资源，还可能影响企业的整体竞争力。
• 管理者的责任: 高层管理者尤其需要具备架构决策能力，因为他们的决定对企业的长远发展至关重要。正确的决策能够推动技术发展，提高业务效率和盈利能力。

架构决策能力的核心

• 全局视角: 技术管理者应从整体视角看待问题，关注技术架构的外部价值，如公司利润、人效、资源利用率和业务风险。全局视角能够帮助管理者在做出决策时考虑更多的因素，减少偏差。
• 技术深度和学习能力: 决策者需要具备深厚的技术知识、优秀的学习能力和逻辑思维，以快速理解和评估各种架构方案。技术深度确保管理者能在复杂的技术环境中做出合理的判断。

决策流程

• 发起申请: 当事人提出架构决策申请，并详细说明背景、需求和可选方案。
• 初步判断: 产品负责人判断申请的处理级别，决定是部门内解决还是上升至CTO办公室。
• 架构评审: 在产研中心或联合CTO办公室进行详细评审，评估各方案的优缺点。
• 结果反馈: 将评审结果反馈给当事人，征询意见并进行必要的调整。
• 架构仲裁: 若仍有分歧，则发起架构仲裁会议，快速解决问题，确保决策的及时性和有效性。

决策表单的设计

• 决策申请编号和归档: 为每个决策事件分配唯一编号，并归档以备日后参考，形成知识库。
• 假设条件: 明确标注可选方案的依赖条件，避免“空中楼阁”。
• 重要性标注: 提升决策效率，通过标注决策的重要性，使评审团队能够快速聚焦关键问题。
• 决策落地保障: 确保决策能够有效执行，并设立相应的监督机制，跟踪决策的落实情况。

决策过程的挑战

• 团队配合: 决策过程需要团队的充分准备和配合，以避免浪费时间和资源。
• 分歧处理: 将分歧落实到纸面上，防止沟通出现歧义，预防推诿扯皮。明确责任分工，确保每个环节都有专人负责。
• 培养能力: 通过决策流程培养团队的架构决策能力，推动人才梯队建设，提升团队整体水平。

架构决策的文化和工具

• 企业文化的重要性: 决策流程和工具不能脱离企业文化，需要企业文化的支持才能有效执行。良好的企业文化能够促进决策的透明性和公平性。
• 日历协同: 落实日历协同文化，提升团队决策效率。通过合理的时间管理，确保每个决策环节都能及时进行。

管理者的决策特质

• 全局视角和技术深度: 结合全局视角和技术深度，管理者可以做出高效且正确的架构决策。全局视角帮助管理者看到宏观趋势，技术深度确保其对细节有足够的把握。
• 学习能力和逻辑思维: 管理者通过学习能力和逻辑思维，快速理解业务和架构逻辑，进行明智的决策。持续学习和更新知识是保持决策能力的关键。

避免“不作为”的危害

• 及时决策: 及时做出决策，避免团队工作无限期阻塞，影响业务发展。决策拖延不仅会导致项目进度受阻，还可能带来额外的风险和成本。
• 有效沟通和准备: 通过有效沟通和充分准备，提升决策效率和正确性。确保所有相关方都能参与讨论，提供全面的信息支持。

总结

架构决策是技术管理者最重要的能力之一。决策过程需要结合全局视角和技术深度，通过完善的流程和工具，培养团队的架构决策能力，同时需要企业文化的支持。管理者应具备良好的学习能力和逻辑思维，以在复杂的架构决策中做出明智的选择，避免技术债和不作为带来的危害。通过有效的架构决策，企业能够在技术发展中保持领先，提高业务效率和市场竞争力。

18、架构决策：技术管理者最重要的能力

架构设计不仅是技术人员的常见工作，也是衡量他们能力的重要标准。对于初级程序员来说，设计原则和模式可能是入门的标配，但对于技术管理者和架构师而言，架构设计能力更是他们职业生涯中的关键能力。优秀的架构设计不仅体现在技术层面，更在于如何通过专业分工和协作精神，使系统高效且灵活地响应业务需求。

专业分工与协作精神

• 高内聚、松耦合: 优秀的架构设计强调模块间的低耦合和高内聚，使得系统各部分可以独立开发和维护。
• 单一职责原则: 每个模块只负责单一功能，避免功能混杂，提高系统的可维护性和扩展性。
• 接口隔离原则: 通过明确的接口进行交互，保证模块的独立性，减少修改的影响范围。

从程序员到架构师的能力提升

在职业发展过程中，架构师需要不断提升以下能力：

• 业务流程理解: 深入理解业务需求，能够将复杂业务拆分成简单的功能模块。
• 架构设计: 设计合理的系统架构，确保各模块的职责清晰、功能明确。
• 抽象与复用: 提炼可复用的组件，提高系统的灵活性和扩展性。
• 变化应对: 预见业务和技术变化，设计能够快速响应变化的系统架构。

业务驱动的架构设计

架构设计必须与业务紧密结合，以下是实际业务中的常见问题和解决思路：

• 功能混杂: 业务需求往往直接驱动代码实现，但忽略了架构设计，导致系统功能混杂，难以维护。
• 模块臃肿: 将不相关的功能混入同一模块，导致模块臃肿，影响系统性能和扩展性。
• 迭代缓慢: 由于架构设计不合理，业务需求的实现速度变慢，影响业务增长。

专业分工与充分协作的实现

架构设计实践中，通过“先拆分再合并”的方法实现专业分工与充分协作：

• 拆分: 将复杂功能按角色和职责拆分为单一模块，确保每个模块功能单一且简洁。
• 合并: 将相似职责的功能模块合并，抽象出可复用的组件，提高业务响应效率。

架构设计的核心原则

• 元素与关系: 架构由元素（功能模块）和关系（模块间交互）组成。稳定、可复用的功能应作为组件，对应架构中的“元素”；而面向不确定性的设计，则需要变成协作方式，为可能的扩展作准备，对应架构中的“关系”。
• 中庸思想: 架构设计应保持适度拆分，既不过度设计，也不过少设计，确保系统在业务复杂度增加时仍能高效运作。

微服务与中台架构

• 微服务架构: 微服务将功能和数据处理封装在一起，通过服务交互、服务治理、服务监控等机制，提升系统的灵活性和扩展性。其核心是让系统分工明确、责任清晰。
• 中台架构: 中台架构强调可重用部分的抽象，消除系统内的“烟囱式”结构，实现架构解耦和服务重用。中台的建设需要考虑业务需求和可复用性。

复杂架构设计的落地

复杂架构设计的落地需要以下步骤：

• 确定性与不确定性区分: 将功能按确定性和不确定性区分，稳定的功能模块化设计，不确定性的功能通过灵活的协作方式实现。
• 模块归类: 按职责和功能将元素归类为组件，组件对外暴露服务接口，确保模块职责清晰。
• 服务调用与事件驱动架构: 稳定的服务调用使用SOA架构，不确定性的服务交互使用EDA架构。
• 架构调整: 在业务需求变化时，架构师需要及时调整组件职责或拆分现有组件，确保系统响应业务变化。

总结

架构设计是技术管理者最重要的能力之一。通过专业分工和充分协作，架构师能够设计出高效、灵活的系统架构，使系统能够快速响应业务需求。无论是微服务还是中台架构，都只是实现这一核心原则的不同方式。理解并践行架构设计的核心原则，技术管理者才能在复杂的业务环境中游刃有余，推动企业技术和业务的发展。

19、产品思维，契约精神是基础，洞察人性才能成就卓越

引言

开始工作重心在架构设计和解决方案上，产品思维并不突出。然而，随着职位的提升和对公司业务发展的负责，逐渐认识到产品的重要性。产品思维不仅对高级管理者至关重要，对每个IT从业者也同样重要。

产品的企业价值和个人价值

企业价值

在“管理复盘”的第一讲中，讲到将职能型组织转变为产品型组织。对于企业而言，做需求重在“过程”，而做产品重在“结果”。产品是企业对外提供服务的载体，也是企业核心竞争力的具象化。许多大企业都有自己的“竞争壁垒”，如腾讯在社交和文娱领域，阿里巴巴在电商领域。所谓“竞争壁垒”，实际上就是指产品。

企业有对外和对内的产品，二者可以互相转换。随着产品能力的提升，内部产品有机会演变为外部产品。例如，阿里巴巴的技术平台成熟后成为了IT基础设施类产品；Netflix的API成为了内部和外部的服务产品；许多大企业的人才梯队建设方法论也可以形成产品。通过时间迭代和持续投入，这些产品逐渐形成企业的竞争壁垒。

个人价值

个人价值在很大程度上来自于企业价值的增量。如果你的工作对企业成长没有帮助，是不可能跨越成长台阶的。因此，每个团队成员都应努力创造企业价值的增量。长期来看，企业价值通过产品体现，所以每个希望成长的人都应具备产品思维。

培养产品思维的核心脉络

契约精神

培养产品思维的核心在于“契约精神”和“洞察人性”。契约精神指的是工作中的“一诺千金”意识，具体体现在四点：

1. 将每个工作成果当作产品，交付或售卖。
2. 尝试理解产品的用户是谁。
3. 在用户付出时间、精力或金钱后，明确交付了什么，并承诺交付。
4. 不惜代价信守承诺。

例如，京东物流的“当日或次日送达”承诺，需要系统的全面配合；唯品会的“用更便宜的价格买正版鞋服”承诺，需要整个企业的努力；彩食鲜的“提供可信赖的安全食品”承诺，需要各环节的严格把控。每个模块的责任人都需具备契约精神，否则企业信誉将受损。

洞察人性

洞察人性是指了解产品使用者的真正诉求，并通过产品让用户觉得自己更卓越。好的产品经理需具备极强的同理心，了解用户的痛点和目的。产品设计应以人为本，科技应向善，让人们的生活更美好。

在彩食鲜，销售对账系统的设计目标是帮助销售人员提高效率，让他们有更多时间专注于客户和签单。这样的产品设计让用户觉得工作效率更高，也让公司运转更加高效。

产品思维六步法

第一步：面对所有工作，习惯性自问“我到底要交付什么样的产品？”

你的工作和职业生涯都可以看作一个产品去打磨。关注工作的长线价值是产品思维成熟的第一步。

第二步：明确产品的用户是谁

对于内部产品，用户群体相对固定。认识和了解用户，时刻记住他们是谁，避免只考虑自己的需求。

第三步：明确服务契约

问自己，产品为用户提供了什么样的服务契约，用户通过产品实现什么价值？用纸笔写下来，尽量数字化和具体化。

第四步：将产品打磨至卓越

社会和企业奖励卓越，而非平庸。卓越产品的“三个一”思考法：一个位置、一个按键、一秒内达成目标。通过微观视角的卓越产品组合，最终创造产品的行业竞争力。

第五步：以人为本，成就用户

产品设计的第一驱动力应该来自用户价值，而非技术方案的优劣。产品建设要以人为本，成就用户。

第六步：关注数据，持续完善

产品迭代要有数据支撑，用数据衡量产品的卓越程度和价值增长，成就伟大的产品。

结语

培养卓越的产品思维并不复杂，关键在于行动、实践、思考和总结，固化成自己独有的方法，持续学习和成长。

契约精神与洞察人性

遵守“契约”可以打造90分的产品；以人为本和洞察人性则可打磨出卓越的产品。产品思维是一种长期的利他主义思维，设计产品的出发点是让用户的生活更美好。

长期主义与个人成长

作为IT从业者，应该追求长期主义。多年以后，留下属于自己的卓越产品，让别人的生活变得更美好。这种信念能激励我们克服困难，坚持成长。

人生是一场修行，职业中的磨难和领悟最终会让我们获得美好的融会贯通的感觉。希望你能持续打造一个又一个卓越的产品，实现个人和职业的成长。

20、高可用设计：为产品护航，无后顾之忧

提到高可用设计，许多人立刻联想到“冗余设计”和“故障转移”。确实，在大多数高可用设计的讨论中，这两个概念经常被强调。

“冗余设计”指的是通过集群替代单点服务，以做好冗余备份。单点架构是高可用的大敌，“把鸡蛋放在不同的篮子里”是最朴实且有效的设计思路之一。“故障转移”则旨在缩短故障时间，确保在故障发生时，业务能够迅速恢复。

如果深入了解高可用设计，可能还会想到“CAP理论”、“异地多活”、“双机热备”等概念。这些知识储备可以帮助应对复杂的面试场景。然而，在实际工作中，依然可能遇到许多高可用设计的难题。为何在面试中对答如流，而在实际操作中却难以主导企业整体架构的高可用设计？

这可能源于多种原因，如企业发展阶段的特殊性，缺乏实战经验，或者部门间的协作不顺，导致难以在实践中贯彻高可用设计。然而，更重要的原因是对高可用设计缺乏自顶向下的深入理解和认知，因而常常迷失在技术细节中，无法洞察架构的全貌。

解剖高可用设计

在架构设计中，通常会将一个IT系统从应用层到底层基础设施，拆解为一个个应用模块，也可称之为“元素”或“组件”。随后，确保各个模块间的协作，通过模块暴露的“服务”来承载，也称为“连接”。

因此，应用模块和服务，或称为元素和连接，共同构成了架构。要实现架构的高可用，就需要实现所有元素和连接的高可用。

这一点非常关键：真正的高可用是指所有元素和所有连接的高可用。只要一个元素或连接没有经过高可用设计，风险就依然存在。

举个例子，如果公司要求每天按时上班，迟到就会被罚款，如何保证自己的“出勤系统”是高可用的？一定是全链条的高可用设计。闹钟至少要有两个互为主备，衣物准备要妥当，还要有应对堵车的预案，甚至得保持身体健康，以防因为生病迟到。

在这个例子中，闹钟可能不响、堵车可能发生，这些都无所谓，只要在老板眼里，你按时打卡了，整个系统就是高可用的。更准确地说，高可用是指保证“业务的连续性”，即在用户眼中，业务始终能正常（或基本正常）提供服务。

实现高可用并不容易，实际工作中，很多企业的架构设计并没有做到高可用，原因通常有两个：

1. 相关负责人没有考虑高可用设计。
2. 实现全套高可用的代价太高，无论是资金还是时间都不充足。

高可用设计并不仅仅是技术问题，更是管理和资源配置的权衡。真正的高可用设计需要在企业的实际需求与可用资源之间找到最佳平衡点。

高可用，不只是设计问题

在实践中，高可用设计的最大敌人是“变化”。如果生产环境不发生变化，如不发布新版本、不修改配置文件或数据库脚本，系统大概率会保持正常运行。因此，研发管理水平直接影响版本发布的成功率和信心。

版本发布时需要关注以下几点：

1. 记录系统的每一次发布和变化，包括发布系统/组件、发布时间等，以便随时定位。
2. 确保发布过程不影响业务。
3. 保证任何发布都可以回滚，尤其是大版本发布时，能精准识别回滚单元并实现秒级回滚。

高可用设计不仅涉及技术层面的冗余、集群设计，还包括应对代码逻辑问题的降级服务和熔断服务。在资源不足的情况下，通过提供降级服务优先保证高可用，其次再考虑高可靠。

企业中某些核心服务无法降级，因此需要通过严格的研发流程管理，确保这些服务的高可用和高可靠。作为技术管理者，识别核心服务并引导团队重点关注是至关重要的。

结语

高可用设计意味着“Design for Failure”，目的是让产品在面对各种不确定性时，依然能够正常运作。如果研发团队总是应对突发问题而焦头烂额，就无法专注于将产品打磨至卓越。因此，做好高可用设计，某种程度上也是在实践“慢就是快”的理念。

通过以上内容，可以得出：虽然无法保证所有服务的高可靠，但可以通过设计，保证所有服务的高可用。关键在于对所有元素和连接进行设计，未经过设计的元素和连接，往往是不可靠的。

21、高性能设计，一切都围绕着契约精神

在产品设计中，契约精神和洞察人性是两个核心关键词。高性能设计同样与契约精神密切相关。高性能设计并不仅仅是指能够支撑大流量、高并发的架构设计，它还必须与业务紧密结合。例如，对于网络游戏服务器来说，能够支撑400名玩家同时在线就算是高性能；而对于流媒体服务器来说，则需要关注连接稳定性和延时等指标。

高性能设计的两大步骤

1. 清晰描述、定义性能目标。
2. 设计并实现这个目标。

高性能架构的设计目标

高性能架构的设计目标通常通过以下三类指标来具体定义：

1. 系统响应时间：包括服务/交易处理的时间和网络响应时间。
2. 系统吞吐量：系统的每秒交易量，通常需要结合并发量共同描述。
3. 系统容量：系统的可用资源数量，包括硬盘容量、网络带宽等。

需要注意的是，这些指标不能孤立地看待，必须结合业务场景进行综合考虑。例如，在定义系统响应时间目标时，需要考虑系统吞吐量，以避免在流量高峰时系统无法满足预期。

TP（Top Percentile）指标

系统响应时间可以通过TP（Top Percentile）指标来监控，例如：

• TP 90 = 2s，表示90%的请求响应时间在2秒以内。
• TP 99 = 2s，表示99%的请求响应时间在2秒以内。

平均响应时间（RT = 2s）虽然可以作为参考，但实际意义可能不大。通常，TP 90和TP 99的指标更有实际价值。

高性能设计的契约

当明确了TP 90或TP 99这一有关系统响应时间的指标时，一个交付给用户的契约就出现了。需要注意的是，这个契约应该明确且具体。一个模糊、不明确的契约往往是导致实际问题的根源。

例如，一个高性能设计的契约可能是：

“该架构在设计流量内，保证200万用户的TP 90 = 2s。”

如果超过200万用户，超出并发限制的用户则不在契约承诺的范围内。这样的契约有明确的上限和应对措施，才能真正交付高性能设计。

实现高性能架构的关键技术点

高性能架构的实现有三项关键工作：

1. 为架构做好“保护系统”。
2. 使架构具备扩容能力。
3. 提升系统各组件处理能力。

1. 保护系统

保护系统是为应对容量规划外的过载，通过流量控制来实现。流量控制有两种具体实践：

• 面向连接数做控制。
• 面向用户数做控制。

选择哪种方式取决于具体业务需求。

2. 扩容能力

扩容能力包括储备额外的计算资源和具备快速弹性扩容能力。在需要扩容时，能够快速响应和执行扩容操作是至关重要的。无论是利用公有云还是私有云，目标都是一致的，即在流量高峰时能够快速扩容，保证系统性能。

3. 提升系统各组件处理能力

高性能设计中，每个组件/服务都要确定目标，进行设计、评审和测试，确保满足性能需求。需要特别关注的是“对系统资源的争抢问题”，即并发压力增大时，响应时间是否变长。对于无状态服务，可以通过集群扩容来解决；而对于有状态的数据服务，需要考虑资源争抢问题，并进行隔离设计。

具体的隔离方法包括：

1. 缓存机制：解决数据库资源争抢问题。
2. EDA架构：区分同步处理和异步处理。
3. 预处理：以空间换时间，提高处理效率。

高性能设计的测试工作

在实际业务中，全链路生产压测是验证系统性能的重要手段。如果一个系统通过了全链路压测，那么可以基本确认其没有性能问题。

结语

高性能设计不仅仅是技术问题，更是业务契约问题。明确契约，按步骤落实，是高性能设计的关键。对于技术人来说，学会将复杂问题拆解为简单问题，是解决问题的核心能力。在设计高性能架构时，要牢记契约精神，并通过保护系统、扩容能力和提升组件处理能力等手段，实现高性能的设计和交付。

22、扩展性设计：看透业务的本质

扩展性设计不仅仅是业务拆分和集群扩容，还需要从业务和用户的角度进行思考。技术工作的最终目标是成就业务和提升用户体验，否则再多的技术工作也可能是无用功。

在职业发展的早期，工程师通常因技术上的进步而受到表扬。然而，若在职业发展三到五年后，仍然只关注技术细节，可能会陷入职业瓶颈。技术人需要变得专业，不仅在技术上，还在架构设计、团队管理和业务发展方面，才能做出好的产品，通过产品成就用户，进而帮助公司业务取得成功。

扩展性设计的核心

扩展性设计的核心是支持业务快速发展，确保在企业发展的不同阶段，业务上线所需的研发时间不会大幅增加。要做好扩展性设计，设计者需要具备企业发展的全局视角，从业务发展的角度出发，倒推出IT建设的整个链条，并针对链条中的某个节点进行设计工作。

四个层面的考虑

做好企业级扩展性设计需要在以下四个层面进行设计：

1. 公司的年度/季度业务发展目标：

   • 在公司战略和商业模式确定的情况下，充分考虑市场竞争情况，确定目标优先级，明确每个季度的工作目标。
   • 关注节奏问题，分析战略步骤的依赖关系、重要性和紧急程度，确定执行顺序。

2. 企业级产品建设：

   • 通过架构思维将产品拆解为功能模块。
   • 用穷举法思考每个模块的扩展可能。
   • 以ROI为出发点，对所有可能进行收敛，最终确定要落实的扩展性设计。
   • 产品能否具备高扩展性，与产品经理的业务思维和抽象能力密切相关。

3. 企业级应用架构设计：

   • 区分架构设计的确定性与不确定性。
   • 确定性部分（如交易体系）处理确定性问题，采用SOA架构。
   • 不确定性部分（如协同体系）处理不确定性问题，采用EDA架构，并与交易体系集成。
   • 监控指挥体系用于监控、分析、控制业务流程，生产体系用于保障产品高效迭代和优化。
   • 交易体系和协同体系的集成点称为CP（control point）。

4. 企业级技术架构设计：

   • 避免重复造轮子，通过自研或购买套装软件/云服务实现技术平台。
   • 非核心系统建议购买套装软件/云服务，核心系统建议自研。

扩展性设计的实施

真正的扩展性设计与单一维度的技术问题无关，是团队整体认知、博弈与决策的结果。需要掌握表达技巧，与领导、同事、下属保持充分沟通，并具备组织管理能力。

结语

优秀的扩展性设计建立在看透业务本质的基础上，面向不确定性，从中寻找确定性。研发速度快也是一种扩展性，但体系化的思维和解决方案才能从根本上解决问题。

23、产品交付的风险管理：如何避免陷阱

在实际工作中，工程师和项目经理常常面临交付困难的问题，可能会由于时间、资源或技术限制而无法按期交付项目。这种情况不仅对个人成长不利，还可能对公司的业务造成严重影响。

认识到限制的重要性

常见的情况包括，领导要求在极短时间内完成技术难度极高的项目，或是产品功能规划过于庞大，导致实际开发过程中的困难重重。上述情况虽然有所夸张，但确实反映了现实中的一些普遍问题。

成功交付的公式是“认知到位 + 彪悍执行 = 成功交付”，然而，这必须建立在对项目客观评估的基础上。若忽略了项目中的限制因素，即使再努力，也难以保质保量地完成任务。解决这些问题的关键在于理解和管理“限制”。

限制的分类

1. 输入限制

业务限制：

• 时间、资源和范围：产品的落地路径由这三要素构成。不合理的时间安排、资源配置或功能范围扩张会导致项目难产。
• 法律法规与政策限制：相关法规和政策可能限制产品设计和实施，应该及时了解并遵守。
• 组织文化限制：组织结构和文化也会影响产品的输入，管理者需要建立合适的企业文化。
• 地域因素限制：地理位置可能影响团队资源和能力。
• 风险承受能力：业务的风险承受能力影响其可持续发展。
• 市场因素限制：市场动态需保持敏感，避免闭门造车。

技术限制：

• 遗留系统限制：过多的遗留系统会影响系统升级和维护。
• 团队技能限制：团队成员的能力不足会制约项目进度。
• 现有基础设施限制：基础设施的强弱直接影响开发和实施效率。
• 标准规范限制：企业内的标准规范可能对产品建设形成限制。
• 实施限制：流程性规定可能对研发时间造成限制。

2. 输出限制

明确的服务契约：

• 必须提供清晰、可量化的承诺，以符合SMART原则。明确的限制能帮助更好地服务用户，避免承诺过度。

项目管理中的限制

项目管理是一门涉及“限制”的专业技能。项目经理需进行工作分解结构（WBS），确保任务分解合理、时间安排准确、资源配置恰当。专业的项目管理不仅要求细致的计划，还需合理考虑各类限制因素，避免因计划不周导致的项目延期或失败。

WBS（工作分解结构）原则

1. 逐步细化：将主体目标分解为最小的日常活动，并分派到个人。
2. 任务分解：每个任务需分解到无法再细分为止。
3. 活动对应：确保日常活动明确对应到人、时间和资金投入。

项目经理需与产品经理、架构师和技术专家合作，准确评估任务和时间要求，避免不切实际的时间预估。

向上管理的挑战

在项目管理中，常会遇到来自上层的压力。例如，领导可能要求在不合理的时间内完成项目。面对这种情况，项目经理需要利用专业知识和行业数据，合理解释项目需求和限制，争取实际可行的时间安排。同时，需考虑团队的实际能力和疲劳度，制定合适的工作计划。

结论

管理产品交付中的限制至关重要。通过对输入和输出限制的全面理解，以及专业的项目管理，能够有效避免陷入交付风险。尽全力完成用户承诺的契约，并在项目中不断调整和改进，是确保成功交付的关键。

24、监控设计：让一切都有迹可循，尽在掌控

为何要谈监控？

许多技术人员会在代码中根据公司的日志规范打印日志，以记录告警和报错。企业也会收集并分析这些日志，以形成对系统状态的监控。同时，一些团队使用免费的或付费的服务器监控报警服务。那么，为什么还要专门讨论监控设计呢？

事实上，这些仅仅构成了监控的一部分，并不是完整的监控体系。为了更好地理解监控的概念，我们需要从监控的目标出发：及时发现系统问题并迅速响应，使系统保持健康状态。

监控可以拆分为“监视”和“控制”两部分。举个例子，当生产环境出现问题时，我们需要通过“监视”来定位问题，通过“控制”来响应并解决问题。

技术团队的“怪现象”

某天晚上，团队发现一个程序在生产环境中出现异常：服务器的CPU负载突然飙升。尽管有十几位工程师参与分析，但问题仍未解决。产品负责人向我求助，并将我拉进问题调查组。

我询问团队最近是否有版本变动，是否都回退了。团队回答都回退了，但我认为不可能。经过追问，负责发布的同学承认并没有全部回退。最终发现问题在于一条数据库索引，在回退这条改动后，系统恢复正常。

这个案例暴露出的问题在于，技术团队没有及时声明所有变动，导致问题定位和解决延迟。反思后，我发现这是因为团队没有正确认识到监控的本质。

IT 团队监控体系的问题

监控的目的是让系统保持健康，具体手段包括“监视”和“控制”。当生产环境出现问题时，找到根因是最耗时的工作。如果没有控制手段，即使找到根因也无能为力。

典型的故障恢复流程如下：

1. 发现问题后，联系相关系统负责人排查问题。
2. 确认各系统或服务是否健康。
3. 进行根因分析，确认导致问题的系统或服务。
4. 完成系统恢复工作。

在实际操作中，步骤3和4依赖于分析人员的专业程度，并且随着业务复杂度和系统数量的增加，分析时间也会增加。为了降低对团队专业性的依赖，我总结了两个方法：流控和版本回退。

流控和版本回退

生产环境出现问题，通常是由于以下三类变化：

1. 外部用户请求量增大。
2. 产品发布，包括代码、配置和SQL脚本发布。
3. 依赖资源变化，如计算、存储、网络基础设施情况变差。

因此，我们不一定需要复杂的根因分析，只要控制住了服务的变化，就能控制住故障。新的故障恢复方法如下：

1. 发现问题后，联系相关系统负责人排查问题。
2. 确认各系统或服务是否健康。
3. 两批研发力量并行工作：一批继续定位问题，另一批回退有变化的模块，并启动流控。
4. 恢复系统。

这样的方法降低了对团队专业性的依赖。对于任何组件，我们需要具备流控和发布回退两种手段。

结语

本文讨论了监控的本质和方法。监控的目的是保持系统健康，手段包括监视和控制。为了控制系统变化，可以通过流控和版本回退来消除异常。

监控不仅适用于技术和业务系统，也适用于研发管理和团队管理。关注过程监控，能够更好地保障系统和团队的健康状态。

1. 监控的目标是及时发现系统问题并迅速响应，使系统保持健康状态。
2. 监控包括“监视”和“控制”两部分。
3. 流控和版本回退是生产环境故障恢复的重要手段。
4. 生产环境不允许调试问题，查问题要在测试环境进行。
5. 对企业业务的监控也很重要，通过数据化管理提升运营效率和质量。

25、异常设计，让错误无处遁形

异常设计的重要性

异常设计在高可用设计、监控体系建设中扮演重要角色，属于监控体系的一部分，但并不完全依赖于监控体系或高可用设计。即使在监控体系建设完成前，异常设计也可以独立发挥作用，实现快速见效。它能够提升 IT 团队快速定位问题的能力、降低生产系统异常的频次和数量，关键是让 IT 团队从面向技术转为面向产品、面向用户。

什么是异常？

异常不仅指导致系统不能正常工作的情况，还包括那些当前未必影响生产环境但未来可能会的问题。例如，低流量时没问题但高流量时可能出问题的情况。许多时候，Warning 和 Error 信息被忽略，但它们往往会导致严重故障。

被忽视的异常

早期电商平台出现的缺货、品质问题是因仓储系统、订单系统、质量监测系统不完善导致的概率性问题，并非“恶性故障”。但随着用户规模增大，这些低概率问题会被放大，影响企业声誉和用户信任。许多被忽视的异常最终会对用户体验产生恶性影响。

认知、方案和治理

异常设计的认知

1. 异常一定要消灭：有异常意味着系统存在风险，必须消灭。
2. 异常一定要管理：消灭异常是长期工程，短期要通过管理行为进行控制。
3. 对异常的处理水平会极大影响产品的用户体验：用户规模越大，异常影响越大。
4. 每个异常都要有具体负责人：没有具体负责人就意味着管理流于形式。
5. 与终端用户相关的异常，要以最高优先级处理：即便是 IT 研发，也要以用户为中心。

落实异常设计
管理异常需要从异常注册、异常事件触发、异常协作流程和异常统计四个方面进行。

1. 异常注册

   • 异常的 ID 和名字
   • 异常描述
   • 异常出现的代码位置
   • 负责此异常的研发、测试和产品人员
   • 异常发生时的代码版本
   • 使用的异常处理程序

2. 异常中心建设
   各个系统在异常中心注册异常，运行阶段出现异常就抛出异常事件，触发异常处理协同流程。可以通过收集日志中的异常进行归类处理，再通过异常治理完成注册。

3. 异常治理流程
   异常收集后交由相关负责人处理，保留下的异常提交管理层审批。要调查问题根源并解决，管理层关注异常处理情况，包括数量、频次、系统内异常增速或降速。异常治理纳入绩效考核，实现治理闭环。

异常设计的价值

做好异常设计既能防微杜渐，也能帮助研发和测试人员快速定位 Bug，推动企业用户体验驱动内部经营完善的逻辑。异常管理数据化、产品化、系统化，通过持续治理和数据分析，促进企业持续进化，建立竞争优势。

结语

异常设计的最终目的是让企业潜在的产品和研发问题暴露出来，达成最佳产品体验。在落实异常设计时，要有契约精神，快速迭代处理直接影响用户体验的问题；对于宏观异常治理，坚持长期主义，不断优化。企业要将任何问题纳入异常管理流程，通过持续治理和数据分析实现竞争优势。

26、上云设计，融合云计算的未来

为什么要在这个时刻聊云计算？

当前，IT产业的发展趋势促使我们必须关注云计算。随着云计算产业的成熟，它直接影响了许多问题的思考方式。

在之前的专栏中，多次提到对云上资源的规划。比如在“高性能设计”一节中，谈到了拥有云上秒级扩容能力会给运维工作带来的帮助；在“扩展性设计”一节中，建议对于非核心系统，在需求较为匹配的情况下，直接选择购买套装软件或云服务。类似的例子还有很多，最终可以归结为一个结论：企业要上云，并且未来一定会上云。

IT技术和云计算的发展趋势判断

IT产业的发展历程始于硬件的发明创造。1946年，英国剑桥大学成功研制出第一台冯·诺依曼机器：EDSAC。近十年后，相关的编译程序和编程语言才出现。但直到1964年IBM推出System/360以前，所有的计算机都是面向用户定制的，没有统一标准，设计上也没有连续性。IBM System/360的出现，标志着计算机开始走向通用化、系列化和标准化。

1981年，IBM推出了世界第一台个人PC，体型大幅缩小，这是计算机走进千家万户的开始。从历史角度看，IBM PC尤为重要。但如果让一个生活在2020年的程序员来看，IBM PC的性能差到令人发指。IT软件的发展也没有比硬件好多少。汇编语言非常难以理解，编码复杂，现在已经很少有软件公司用汇编来开发软件。那时，人们很难想象会有Java、Golang这样的语言应用在软件开发行业，极大降低研发成本，提升了研发效率。

从汇编语言到Java，从最早的IBM System/360到如今的计算设备，技术发展表现出一个明显的趋势：底层黑盒化、价格亲民化。也就是说，越来越不需要关注技术细节，同时技术的价格也越来越亲民。当这些技术或服务被整合成产品，连入互联网，使客户可以按需购买时，云计算就出现了。

云计算的特征

站在应用软件角度看，现在的IaaS软件已经非常成熟，PaaS和SaaS软件也在迅速发展中。Salesforce是最成功的SaaS软件。IT技术和云计算的发展呈现以下五个特征：

1. 形态产品化
2. 价格平民化
3. 自助服务
4. 按需付费
5. 网络访问

云计算可以理解为各类云服务的统称，而所有这些服务都是通过产品来体现的。云产品仍在快速发展，融合进旧有产品的生态里。这种发展的力量不是某家公司CEO的个人意志，而是“技术基座不断上移”的社会客观需求。科技不与人争利，只有人与人之间才会争利。技术进步推动了社会的进步，因此具有普世价值，也会越来越平民化。看清趋势，拥抱趋势，在技术演进早期选择恰当时间积极应用，拥抱技术红利，就可以为企业赢得阶段性的领先优势。

专业分工与社会效益最大化

在经济学概念里，实现社会效益最大化的答案是专业分工。在数字化世界里，这一逻辑同样成立。对于云产品来说，只要客观需求存在，就一定会有人去尝试解决，并包装成产品售卖。对于云计算厂商来说，所有“技术基座”都可以云化，让专业的人干专业的事，客户只需要付费购买就好。对于甲方企业来说，IT投入是价值成本，需要持续加大投入，但迫于经济规律，最终不得不寻求公共技术的社会化。

双方的深层需求是契合的，也符合社会效益最大化的经济学原理。因此，关于IT技术和云计算的发展趋势，有两大关键结论：

1. 数字化转型的结果是：云会吞噬一切；
2. 云不仅仅是技术，更是最好的商业模式。

正确看待这场“变革”

明确了上述两点，我们才能正确看待这场“变革”，并寻找个人或企业的发展机会。坚持拿来主义，不要与趋势为敌。以下五点认知需要关注并多加思考，既适合普通工程师，也适合CEO/CTO，区别在于站在何种角度思考及如何决策。

1. 从业务发展的角度出发，倒推上云规划

上云是为了帮助业务降本提效，做任何事都要从目标出发。过去，我曾主导企业的IT设施上云规划，明确了迁云后的资源节省目标。

2. 坚持“拿来主义”，不要在企业层面重复造轮子

对于非核心业务，坚持拿来主义，不要过于理想主义；对于核心业务，坚持长期投入，建立团队推进自研工作。

3. 别害怕上云，和乙方一起解决障碍

上云规划涉及内容广泛，包括上云方案、现有系统评估、云平台成本优化建议等。很多内容可以通过与云厂商沟通和商业谈判得到解决。

4. 开放心态看待数据隐私

对公有云的抗拒多因数据隐私泄露的担忧。我认为，云厂商不会在公司层级盗取数据，但可能因管理不善导致数据泄露。如果实在不放心，可以选择私有化部署。

5. 正确看待云计算的“负面影响”

云计算的成熟会导致部分初级开发者失去工作机会。如果企业文化不以业务和产品为核心，可能在上云问题上陷入多方扯皮。因此，上云仍是个一把手工程。

结语

曾经，很多研发同学向我展示他们的软件，但我常常打击他们：“有啥厉害的，你这做的就是个玩具。”真正厉害的技术要能包装成产品，对外售卖或提供服务。站在未来看当下，用十年后的眼光看现在，个人成长路径只有两条：

1. 成为技术管理者，进入商业公司，采用技术产品或云服务，洞察业务，帮助业务成功，实现业务价值；
2. 成为技术专家，进入纯技术公司或云计算公司，设计开发技术产品，提供技术服务。

无论哪一条，都与云计算的未来融合在一起。云计算会成为未来的水、电、燃气、交通工具。一定要尽早形成对此事的正确认知，大胆地拥抱新的技术趋势和机会。

很多企业没有认真规划过自己的技术平台，因此较难上云。但如果企业内部已有一个底层技术平台，这就接近企业级别“云平台”的概念。保持开放心态，外部平台只是一个候选方，与企业生态内的云平台无本质区别。

农业社会的核心生产力是农民，工业社会的核心生产力是工人，信息社会的核心生产力是码农。个人价值通过稀缺性体现。看清趋势、拥抱趋势，才能让自己变得稀缺，越走越顺。

在阅读专栏时，应以全局视角看待内容。管理和职业发展中往往存在复杂的“灰色部分”，需要理性分析和全局规划。同时，要认识到人生中的选择和放弃，明确自己的目标与愿望。

最后，时间是最好的朋友。读完专栏后，选择适合的方向和书籍，持之以恒地实践和学习，不怕过程中的困难，坚持下去。记住，成长是一场持久战，而身体健康同样重要。