乔新亮CTO成长复盘 （下）
2021-12-18 11:28:08 3 举报AI智能生成
现彩食鲜CTO，前苏宁电器技术中心副总裁的个人成长复盘。第二部，共3部
作者其他创作
大纲/内容
新架构多久落地，说到底只是个效率问题。
如果方向不对，那么无论团队里有多少精兵猛将，也只能跟着漫无目的地瞎忙，这就是所谓的“一将无能，累死三军”。
但如何拍板确定新架构的设计，则是重要的方向性问题。
决策失误，是“技术债”的主要来源
给大家分析哪一种方案更好，现场拍板；
指出当前双方考虑不周到的地方，再给大家时间去准备，并在 Deadline 前决策拍板；
泛泛地对大家说：“不够具体”、“没有重点”，“再回去想想”……
有两个团队成员坐在会议室里，争论两个架构设计方案孰优孰劣，你该怎么办？
选择“不作为”，往往更加可怕
一把手是团队的天花板，并为团队的所有问题负责。
当事人发起架构决策申请；
由产品负责人判断：
该申请是在产研中心部门内协调解决，还是上升至 CTO 办公室解决；
在产研中心部门内，或联合 CTO 办公室，完成架构评审；
将结果发还至当事人征询意见；
由当事人判断是否仍有疑虑，需要进行架构仲裁；
若需要则发起仲裁会，解决分歧；
若不需要则结案归档，执行决策。
步骤
第一，这套流程和意见反馈模板，可以让当事人及各参与方，做好充分的思考和准备，避免浪费大家的时间；
第二，所有分歧会落实到纸面上，能防止沟通出现歧义，也预防推诿、扯皮的现象发生；
第三，可以培养所有人的大局观和架构决策能力，间接推动人才梯队建设；
最后，用体系化方案解决团队问题，追求的是“一劳永逸”地解决问题。
优点
做好架构决策的流程和模板
管理者要优先配合下属做好架构决策，反过来，下属也要进行细致准备，节约时间、提升效率。
只要涉及到新增制度、新增流程，无论考虑得多完善，都会降低团队敏捷度
这种“外部价值”包括：公司利润、人效、资源利用率、业务风险，等等。
第一项特质：要学会站在全局视角看待问题，学会看到技术架构的“外部价值”。
做 “T” 型人才，其中一个重要的原因就在此时得到了体现：有一条足够深入的技术栈，是你前进的巨大倚仗。
第二项特质：具备相当的技术深度，以及非常好的学习能力和逻辑思维。
在一个梯队建设较为成功的企业里，走技术路线的下属，几乎总是会在某一专业领域胜过你。
CTO 几乎不可能成为真正意义上的全栈技术和架构专家
通过下属的表述，快速理解业务和架构逻辑，短时间内成为这一细分问题的专家，然后进行决策。
管理者的学习能力和逻辑思维就会派上用场。做架构决策时，我们要求写好意见反馈模板，其中一个重要意图是让当事人将架构背后的逻辑讲明白。
引导对决策存在分歧的双方，就方案合理性互相“攻击”。
团队的成员，嘴都比较笨，真的是说不明白。
技术管理者如何做好架构决策
对于初级管理者来说，要尽早培养自己的架构决策能力，尤其重视思维模式的培养、个人技术栈的深度扩展以及逻辑思维能力的锻炼。
架构决策是技术管理者最重要的任务之一
对于高级管理者来说，则要做好认知层面的储备。
总结
架构决策，是技术管理者最重要的能力
好的架构设计，就像优秀的组织协作一样，既能帮助 IT 系统做好各模块的专业分工，又能体现模块间的协作精神。
架构设计最核心的认知
大家习惯于基于业务需求写代码，而不是基于架构设计写代码
保证各「元素」职责清晰的情况下，抽象出稳定的功能或组件，用业务流程去串联起来。
一名优秀的架构师负责的架构就是能快速响应业务的需求。
从程序员到架构师，什么能力在提升？
拆分是指将一个负责的功能按角色、按职责拆分，核心特征是单一模块的功能既单纯又简单。
合并是指将类似的职责放在一个模块完成，抽象出可重用、复用的部分，提升业务响应效率。
先拆分再合并的 “V” 字型设计过程
专业分工、充分协作是什么呢？
在架构设计中，那些稳定、可复用的部分应该变成组件或应用模块，对应着架构中的「元素」；
而面向不确定性的设计，则需要变成协作方式，为可能的扩展作准备，对应着架构中的「关系」。
抽象地看，架构是由元素（element）和关系（relationship）组成的。
其实就是对复杂业务的拆分能力
对可复用部分的抽象能力
对拆分过程的颗粒度把握
对未来变化的考量和设计。
从初级架构师到高级架构师，什么能力是一直存在并持续提升的？
如何让架构有足够的“应变能力”，则与架构师对业务的理解程度息息相关。
首先，它的功能和数据处理是封装在一起的，这和 SOA 架构非常类似；
其次，服务交互、服务治理、服务监控、服务隔离等很多基础性能力已经封装在框架中，可以让开发团队聚焦在功能实现上；
再者，通过和 Kubernetes 集成，微服务的功能、数据、基础设施被再次封装，技术架构也再次进行了升级。
微服务
技术架构部分的很多职责已经被抽象出来，并对框架进行了处理，隐含着相关理念的最佳实践。
同时，微服务也有一个很基本的原则：让系统的分工更明确、责任更清晰。
在微服务框架下
一名对架构的“分工”和“协作”理解得足够好的架构师，很少会困惑于微服务拆分的颗粒度问题。因为从本质上来讲，这些都是一码事。
认知延伸：如何看待微服务
企业搭建中台，最重要的目标之一，就是实现企业营收层面的“开源”，承担企业架构快速响应市场需求的任务。
从架构的视角看，中台这个概念并不新鲜，它只是突出了“可重用部分的抽象”这部分工作。
如果你的 IT 系统可复用部分不多、业务量不高，建设中台的意义何在呢？
如果你的中台对业务没有帮助，建设中台的价值如何体现呢？
认知延伸：如何看待中台架构
无论是微服务还是中台，都有其巨大的实践价值，但二者只是架构设计核心原则的一种成熟的实践模式和承载方式，不是解决架构问题的“灵丹妙药”。
关键认知：在个人视角里，整个世界都可以按照确定性内容和不确定性内容做简单区分；
架构将其抽象为元素和关系，元素对应着确定性内容的处理，是看待这个世界的稳定视角；关系对应着不确定性内容的处理，是看待这个世界的响应视角；
人类的理解能力有限。包含内容过多的元素，会导致理解困难，需要将其拆分；
同理，将元素归类的时候，也不能贪多，不然会导致理解困难。优秀的架构师，会将合理数量的元素进行归类，归类后的整体一般被称作 component 或 module，也可以直译为“组件”。比如，我们永远以“元素数量为 10 ”作为一个衡量点，只要一个组件包含的元素 / 职责超过 10 个，就要进行拆分；
元素归类一般采用 “V” 字型分析法，即流程分解为功能，功能聚合为组件；
如果组件明确了，意味着职责就建设好了，架构的元素（element）建设问题就解决了。组件对外暴露的能力，我们统一称之为服务；
那么，架构的关系（relationship）建设问题该如何解决呢？稳定的关系，用来表达确定性的交互，使用 SOA 架构，做好服务调用就可以；不稳定的关系，用来表达不确定性的交互，使用 EDA 架构；
在每一个新需求到来时，尤其是大版本的更迭，架构师需要介入产品经理和程序员的沟通中，判断新需求是否大幅增加了某些组件的复杂度，并决定是否调整组件职责，或对现有组件进行拆分。
所以，从实际的业务发展来看，组件的数量是逐步增长的，如果一开始就很多，基本属于过度设计；如果业务复杂度已经翻倍了，组件数量却没变，基本属于缺乏设计。
将功能性架构设计中，最简单直接的方法和步骤抽象总结出来
复杂架构设计如何落地执行
架构设计，专业分工和协作精神的体现
产品是企业对外提供服务的载体，也是企业核心竞争力具象化的载体。
做需求重在“过程”，做产品重在“结果”
对于企业而言，所谓「竞争壁垒」，主要指代的其实是产品。
一般来说，随着产品能力的提升，内部产品有机会演变为外部产品。我认为，这也是培育公司“第二曲线”业务非常切实可行的办法。
对企业的成长没有任何的帮助，是不可能跨越成长台阶的。
没有产品思维的人只能做个企业的“螺丝钉”
个人价值来自于企业价值的增量部分
产品，是企业及个人价值的最好载体
让你拥有入门级的产品思维
将自己的每个工作成果都当作产品，并将产品交付或售卖；
尝试理解这个产品的用户到底是谁；
在用户付出了时间、精力或金钱后，明确你的产品到底交付了什么？
又承诺交付了什么？不惜代价信守这个承诺。
一诺千金
信守承诺不仅仅是态度问题，还涉及能力和方法问题，需要通过明确契约、开展设计、信守承诺三步法将契约落实到位
契约精神
让你可以成为卓越的“产品经理”
科技是向善的，产品应该让人们的生活变得更美好。
淘宝的双11绝对是个失败的产品
产品经理的个人价值观不同，就会塑造出有着所谓“不同世俗意义”的成功产品。
洞察人性是要树立“以人为本”的理念，了解产品使用者的真正诉求，用户通过使用产品，让自己变得更卓越。先成就用户，然后成就产品。
洞察人性
培养产品思维的核心脉络
你在做的工作，甚至你的职业生涯，都可以看作一个产品去打磨。不是只有那些 APP 、手机才可以叫做产品。
你是否愿意关注这一切的长线价值，做时间的朋友。
第一步，我到底要交付一个什么样的产品？
下终端会让自己有不一样的感受，有助于提升自己的同理心。
第二步，明确产品的用户到底是谁。
交付目标要么是 99% 的销售使用 3 分钟内完成、准确率在 98% 以上的对账产品，要么是 100% 的销售使用无人值守的、准确率为 100% 的对账产品。
用数字来组成契约，用 “SMART 原则”来检查契约。
第三步，明确服务契约。
只有卓越的产品，才能对你的个人成长产生牵引作用。
在场景和目标确定的情况下，让用户在一个位置，点击一个按键，在一秒内达成目标。
卓越产品的“三个一”思考法，即“一站一键一秒”，
第四步，将产品打磨至卓越。
技术人需要时刻提醒自己，产品设计的第一驱动力应该来自于用户价值，而不是技术方案的优劣。
在 IT 的日常研发工作中，都存在更省时、更省力、更取巧的代码或设计方法，但这些方法却未必是对用户友好的。
第五步，要习惯于成就用户，时刻谨记：以人为本。
产品迭代一定要有数据，要思考如何用数据来衡量产品的卓越程度，用数据衡量产品的价值增长，用数据成就伟大的产品。
第六步，关注数据，持续完善。
产品思维六步法
设计任何产品的出发点，都应该是让用户的生活变得更美好。
产品思维，本质上是一种长期的利他主义思维。
产品思维，契约精神是基础，洞察人性才能成就卓越
是指要通过集群来替代单点服务，做好冗余备份。单点架构是高可用的大敌，“把鸡蛋放在不同的篮子里”是高可用最朴实、最有效的设计思路之一；
“冗余设计”
是为了缩短故障时间，保证故障发生时，业务可以快速恢复。
“故障转移”
两个高频词
真正的高可用，是指实现所有元素、所有连接的高可用。只要一个元素或一个连接没有做高可用设计，都意味着风险的存在。
是要保证“业务的连续性”，即在用户眼里，业务永远是正常（或基本正常）对外提供服务的。
相关负责人压根儿就没考虑高可用设计；
做全套高可用的代价太大了，钱不够用，时间不够用。
很多企业没有做到高可用，原因可能是
根据墨菲定律，如果事情有变坏的可能，无论概率有多小，它一定会发生。
解剖高可用设计
在最理想的情况下，我们既保证高可用，也保证高可靠；但出现问题时，我们优先保证高可用，其次保证高可靠
如果“降级服务”还解决不了问题，应该怎么办？答案是提供“熔断服务”，让出现 Bug 的模块从系统中“熔断”
第一个解决方案是，在风险爆发、系统出现问题的情况下，对外提供“降级服务”。
没钱做 100% 的高可用设计，又想尽量提供系统的抗风险能力。作为架构负责人，应该怎么办呢？
高可用设计真正的敌人是“变化”。
生产环境发布新版本就会成为一个影响巨大的变量，极有可能对系统的可用性造成挑战。
记录系统的任何一次发布和变化，包括发布系统 / 组件、发布时间等；确保自己可以随时定位任何一个时间段内的任何元素及任何发布动作，包括但不限于代码、配置文件、SQL 脚本、设备参数修改等；
发布时不影响业务；
保证任何发布都可以回滚。尤其当一个大版本的发布时，能否精确识别回滚单元，并做到秒级回滚。
版本发布问题，关注研发管理的三个关键点：
风险是经由开发环境、SIT 环境、压测环境、PRE 环境，进入生产环境的。严格检查各个环境下的异常，研发管理规范，应该为代码版本进入下一个环境设置准入标准，对于任何异常，都有负责人进行修正。如果异常通过了评估，审核者要对其负责。
由代码逻辑导致的系统风险，是如何进入生产环境的？
系统 Bug 在导致生产故障前，也往往会有各类异常，我们要做好监控并正式的处理掉它。
生产环境出现严重故障，是不是毫无征兆地发生的？
高可用，不只是个“设计问题”
高可用设计，意味着“Design For Failure”，最重要的是让我们做产品没有后顾之忧。
虽然我们或许不能保证所有服务高可靠，但我们是可以保证所有服务高可用的。
结语
高可用设计，让产品没有后顾之忧
清晰描述、定义性能目标；
设计并实现这个目标。
高性能设计步骤
系统响应时间，一般指服务 / 交易处理的时间，也包括网络响应时间；
系统吞吐量，一般指系统的每秒交易量，通常需要结合并发量共同描述；
系统容量，通常代表系统的可用资源数量，包括硬盘容量、网络带宽等。
高性能架构的设计目标
契约精神是高性能架构设计的“拦路虎”
高性能设计非常看重系统响应时间的一致性，尤其是在不同的服务阶段，并发量和吞吐量发生变化的时候。
有上限的“契约”才能交付
第一步，当服务器不超过 200 万并发用户时，TP 90 = 2s 。
第二步，当连接服务器的并发用户数量超过 200 万，达到 250 万时，保证有 200 万用户的 TP 90 = 2s ，拒绝其他用户的连接请求。
第三步，为设计容量外的用户提供服务器排队机制，并附带具体、明确的系统提示。
第四步，3 分钟内完成扩容，保证并发用户数量小于等于 250 万时，任何在线用户的 TP 90 = 2s。
高性能架构的设计问题
保护系统，是为应对容量规划外的过载而设计的，通过流量控制来具体实现。
为架构做好“保护系统”；
而对于扩容能力来说，一般要包括储备额外的计算资源和具备快速弹性扩容能力。
使架构具备扩容能力；
需求早期收集
容量分析
估算与建模
技术研究
设计、开发、跟踪
测试计划执行
风险与绩效管理
实时监控与容量管理
性能设计一定要尽早开始，具体工作内容包括
提升系统各组件处理能力。
实现高性能架构的关键技术点
于无状态的服务，理论上可以通过集群扩容，无限增加系统的并发处理能力，简单、直接地解决问题；
但对于有状态的数据服务而言，比如缓存或数据访问，就要考虑资源争抢问题，并针对性地设计、处理。
对于一个组件或服务，并发压力增大，响应时间却没有变化，意味着在请求的处理过程中，没有发生对资源的争抢和排队。
一种是在应用层进行隔离，也就是说，在业务功能层面就开始隔离；
一种是基础软件层面进行隔离，比如与数据库相关的“读写分离”概念，就是在基础软件层面进行隔离。
在架构维度有两种方案
缓存机制，适用于部分场景，可以解决数据库资源的争抢问题；
EDA 架构，适用于处理时间较长的代码逻辑，需要提前区分哪些模块可以做同步处理，哪些模块可以做异步处理；
提前进行预处理，以空间换时间，这也是一种卓有成效的处理手段。
三种主要的“隔离”技巧
发现那些可能出现资源争抢的模块，并一一进行隔离。
对系统资源的争抢问题
技术行业发展到今天，基本不存在太多的技术挑战了。
看似是技术能力太过欠缺，其实是契约和设计没有做好。
任何复杂问题都可以被拆解为简单问题，只要拆解得足够细致。
企业决策层将高性能的设计问题和技术问题混为一谈
高性能设计，一切都围绕着契约精神
追求卓越的技术人：我的工作是如何成就业务的，我的产品如何让用户变得更卓越？
要想做好扩展性设计，设计者要具备企业发展的全局视角，从业务发展的角度出发，倒推出 IT 建设的整个链条，再针对链条中的节点针对性地设计。
让自己变得专业，专业才能成就卓越。
第一个是公司的年度或季度业务发展目标
通过架构思维，将产品拆解为一个个功能模块；
针对每个模块，用穷举法思考其他扩展可能；
如果收敛得不好，会让产品变得臃肿，变成过度设计；如果收敛得太过，又会使产品缺乏扩展性。
以 ROI 为出发点，对所有可能进行收敛，最终确定要落实的扩展性设计。
用业务目标指导产品建设
所谓的确定性部分，可能无法适应业务的演进和发展，因此出现大量改动；
而所谓的不确定性部分，也可能随着时间的推移，逐渐固化为产品能力，变成设计内的确定性内容。
扩展性设计，为“不确定性”而设计
架构设计的确定性与不确定性。
第二个节点，是企业的产品建设。
交易体系处理确定性问题，一般采用 SOA 架构。
交易体系；
协同体系用于处理不确定性问题，一般采用 EDA 架构，且要和交易体系进行集成。
交易体系和协同体系的分离，等同于分离了业务的确定性和不确定性部分，因此非常有利于业务功能的扩展。
任何一个 CP 都要被监控、分析、控制，这就是企业的监控指挥体系。
监控指挥体系和公司的管理密切相关，往往是公司数据化管理的重要抓手。
分离不代表完全无关，交易体系和协同体系的集成点，我称之为 CP（control point）。
协同体系；
监控指挥体系可以分为监控、分析、洞察、控制、大数据和 AI 部分。
监控指挥体系；
技术管理者要学会引入“流水线”式设计思想，尝试极大简化开发人员、测试人员的工作复杂度。
生产体系解决公司研发管理地速度问题。
生产体系。
企业级应用架构设计可以包含：
第三个节点，是企业的应用架构设计。
对于非核心系统，在需求较为匹配的情况下，建议选择购买套装软件或云服务；
对于高度定制化的企业核心系统，也就是在核心价值链上提供服务的系统，则建议自研。
不要重复造轮子，至少不要在公司层级造轮子。
第四个节点，是企业级技术架构设计。
还要考虑组织的人才梯队建设，包括 A/B 岗配置、同赛道竞争机制等。
也要考虑协同效率的问题，不能因为业务增长、团队增长而引入协同问题。
保证企业级年度 / 季度业务发展目标实现聚焦
其它
前置思考脉络
所谓“扩展性设计”，通常是当大环境或创始团队的认知出现变化时，公司需要重新调整业务目标，各团队也要配合调整。
扩展性设计，看透业务的本质
“输入”就是其他人对你承诺的“契约”；
“输出”一般理解为承诺给用户的“契约”，指的是产品的对外能力，通常受到输入的严重影响。
限制产品的输入与输出
只要三要素不合理、不匹配，产品基本都会“难产”。
时间和资源的含义都比较明确。
范围是产品的功能规划或能力范围
第一，Time（时间）、Resource（资源）、Scope（范围）三要素。
法律法规和相关政策的变更，大部分是为了在国家角度控制市场风险。
第二，法律法规与政策限制。
没有合适的组织，一切设计都是空谈。
第三，组织文化限制。
第四，地域因素限制。
第五，风险承受能力。
第六，市场因素限制。
输入业务限制主要包括以下六点：
新系统上线的时候，架构师的一个重要工作便是做系统的上下文架构设计、明确周边依赖，对于需要和周边遗留系统进行集成交互的组件或模块
第一，遗留系统限制。
第二，团队技能限制
基础设施强，团队能力就强，输入限制就少；反之，基础设施弱，团队能力就弱，输入限制就大。
第三，现有基础设施限制。
随着企业 IT 治理水平的提升，都会逐步建立企业范围内的标准规范
第四，标准规范限制。
流程性的规定一般会对研发时间有所限制，做排期时需要纳入考虑。
第五，实施限制。
输入技术限制主要包括五类限制因素：
输出，是给用户的契约
很多项目看似是因为一些意外情况延期、取消，实际恰恰是项目管理做得不够专业。
项目的成败，整体掌握于项目经理之手，因为项目经理要做好 WBS（工作分解结构）。
项目在落地过程中，所有的节点监控、风险管理等工作，都依赖于 WBS 。
产品迭代背后的项目管理
具备全局思维、让自己变得更专业、提升自己的表达能力，这一切工作都不是为了和老板在项目目标上进行博弈。
第一要务是具备全局思维能力，和老板站在同一个维度思考。
第二点要从更快交付的目标出发，同时将多种限制因素考虑在内，比如团队疲劳度、凝聚力、激励措施等，和老板一起想办法，把自己想象成 CEO
延展思考：向上管理的“限制”问题
考虑限制，让自己的产品不入险地
监控的目标是及时发现系统的问题，并尽可能快地做出相应的动作，让系统一直处于健康的状态。
IT 团队的系统监控体系，到底出了什么问题？
发现问题后，立即联系各相关系统负责人，以便共同排查问题；
要求大家在一分钟之内回复：自己治下的系统或服务是否健康（这里要将“健康”的定义想清楚，如，响应时间是否增加超过 30% 等）；
进行根因分析，确认导致问题的系统、服务；
完成系统恢复工作。
当生产环境发生异常时，大部分团队会这样组织故障恢复工作：
流控，就是做好程序的并发流量控制；版本回退，就是在生产环境的发布出现问题时，及时回退到上一个版本。
生产系统出了问题一般可以采取：流控和版本回退。
外部用户请求量增大；
产品发布，一般包括代码发布、配置发布、SQL 脚本发布等；
依赖资源变化，一般是计算、存储、网络基础设施情况变差，比如磁盘存在坏道等。
生产环境出现问题，原因通常只有两个字：变化。
第一批解决专业问题，继续跟进问题的定位和调试；
第二批负责消灭变化，对有变化的模块进行回退，对于外部请求数量升高的模块启动流控；
此处组织两批研发力量，并行工作。
恢复系统。
只要我们控制住了服务的近期变化，也就等于控制住了故障
在生产环境，研发人员应该寻找并消灭“变化”。从寻找 bug 到寻找变化，是一个非常大的认知转变。
错误一：负责发布的同学，没有按规定回退至稳定版本，而是询问开发同学的意见，并以其意见为准；
错误二：相关负责人，因为假设“一条索引不会导致故障”而知情不报，导致系统无法完全回退；
错误三：十几名团队成员没有将精力聚焦在线上业务恢复方面，而是试图在生产环境查找 bug。
团队在执行生产环境故障恢复工作时，接连犯下了三个错误：
生产环境永远不允许调试问题，出现问题立刻回退，查问题要去测试环境。
监控设计，让一切都有迹可循，尽在掌控
在企业的监控体系建设完成前，异常设计一般就可以独立发挥作用，达到快速见效的目的。
你可能会想，导致系统不能正常工作的问题就是异常呗。
有些异常，可能当下未必会对生产环境产生影响，但不代表未来也不会；
有些异常，可能在流量压力小时未必会出问题，但不代表流量压力大时也不会。
究竟何为异常？
所谓异常，指的就是那些让产品无法履行当初承诺用户的契约的问题。
那些用户经历的坏体验，对于开发人员来说，可能只是一个简单的错误提示而已。
那些被忽视掉的异常
异常一定要消灭：有异常，基本就意味着系统存在风险，一定要消灭异常；
异常一定要管理：消灭异常是个长期工程，短期要通过管理行为来进行控制；
对异常的处理水平，会极大影响产品的用户体验：用户规模越大，异常的影响往往越大；
每个异常都要有具体的负责人：没有和具体的负责人一一对应，往往就意味着管理流于形式；
与终端用户相关的异常，要以最高优先级处理：即便是 IT 研发，也要以用户为中心。
五点认知
异常设计一般包含异常注册、异常事件触发、异常协作流程以及异常统计。
异常的 ID 和名字；
对异常的描述；
异常出现的代码位置；
负责此异常的研发、测试和产品人员；
异常发生时的代码版本；
当时使用的异常处理程序。
异常的注册
不是所有的异常都要从 Log 中消失，但对于保留下的异常，一定提交管理层进行审批，说明保留原因；
企业也要建设异常中心，各个系统都要在异常中心注册异常，一旦运行阶段出现异常，就要抛出异常事件，触发异常处理的协同流程。
异常设计。
对于异常设计的认知、方案和治理
只要仔细观察一家企业是如何对待异常的，就可以判断这家企业的精细化运营和管理水平。
实现用户体验驱动内部经营完善的经营逻辑。
对于直接影响用户体验的问题，要有契约精神，快速迭代；对于企业宏观角度的异常治理，要坚持长期主义，不断优化。
异常设计，让错误无处遁形
我们越来越不需要关注技术细节，同时技术的价格也越来越亲民。
对 IT 技术和云计算的发展趋势判断
形态产品化；
价格平民化；
自助服务；
按需付费；
网络访问。
IT 技术和云计算，二者的发展究竟呈现出什么样的特征
看清趋势，拥抱趋势，在技术演进早期，选择恰当时间，积极应用，拥抱技术红利，就可以为企业赢得阶段性的领先优势。
数字化转型的结果是：云会吞噬一切；
云不仅仅是技术，更是最好的商业模式。
甲方企业来说，IT 投入是价值成本，需要持续加大投入，但迫于经济规律，最终不得不寻求公共技术的社会化。
云产品带来的价值，不仅是资源节省，还有人力节省、加速研发等，这些都可以换算成财务价值。
第一，从业务发展的角度出发，倒推上云规划。
许多的 IT 研发工作都是重复造轮子，实际就是浪费 IT 资源，对业务发展施加反作用。
第二，坚持“拿来主义”，不要在企业层面重复造轮子。
第三，别害怕上云，和乙方一起搞定障碍。
云厂商不会在公司层级盗取你的数据，但有可能因为管理不善而导致数据泄露。
第四，开放心态看待数据隐私。
第五，正确看待云计算的“负面影响”。
坚持拿来主义，不要和趋势为敌
如果企业奉行的不是以业务为中心，以产品为核心的组织文化，不具备我们前面所讲的、优秀的组织架构，就很可能在上云问题上陷入多方扯皮。
上云设计，融合云计算的未来
对专业成长的复盘
“有用之书”就像各类专业课程，读完了就要在当下立刻实践，光看不用，基本就算是白学了；
“无用之书”并不是真的无用，它们一般很难即时生效，但长期看来，会对你的人生造成巨大影响
立刻付诸行动，在管理和专业技术领域开展实践，优先关注“有用之处”。
坚持长期主义：三个月后，重读一遍专栏；半年或一年后，再重读一遍专栏，持续关注“无用之处”
学以致用，终身成长
寻常人看待一件事，往往是非黑即白的。但我们要看的，是全局视角下，因黑白交织而形成的“灰色部分”，也往往是理性生长的部分。
其实，一个人感到纠结，常常是因为想要的太多了。因为没有全局视角，所以容易陷入各类细节，左右为难。
全局视角，看到“灰色部分”
读完专栏，找好方向，选择“有用之书”，立刻去做；
选择“无用之书”，长期去做。一个月、一年不见效，怎么办？坚持去做。念念不忘，必有回响。
做时间的朋友
在精神上，我需要重新回忆起，许多已经忘记的故事或知识点，并对个人的知识体系进行查缺补漏，形成严密的逻辑闭环。
随着专栏的不断更新，我个人的知识体系也在不断地被重新梳理。每当一章更新完，我都会觉得这部分认知变得浑然一体。
复盘自己，真是一件痛苦的事
利他就是最好的利己；
沟通创造价值，分享带来快乐。
感受
结束语 | 做时间的朋友
自己的成长处于哪个阶段，是慢了还是快了？
初级 leader 为何这么忙，如何“闲”下来？
要成为卓越的技术管理者，有哪些工作要重点完成、优先完成？
如何成为一个卓越的架构师？
“被洗脑”的第一类快乐：解答困惑、提升认知
认为工作的核心在于成长，薪资只是附属价值；
因核心目标聚焦于成长，那么相关决策和心态就会变好，所以成长得更快、更好；
因成长得又快又好，所以很可能得到上台阶的机会，为公司业务贡献更大价值；
因为为公司业务贡献了更大价值，所以可在行业内获得更优越的薪资；
因为获得了更优越的薪资，所以不再忧心生活，将目光进一步聚焦于成长；
因为进一步聚焦，所以成长得更快、更好；
“被洗脑”的第二类快乐：逻辑闭环，触摸边界
编辑手记 | 我被老乔洗脑了
乔新亮CTO复盘
0 条评论
回复 删除
下一页
