17.架构师提升

作为一个架构师仅仅掌握这些“硬”知识、“硬”技能还不够，“业务驱动技术”，但是业务领域更多是很多“软”性的、抽象的技能。一旦一个东西呈“软”性的，大家虽然知道这类东西存在，但又难于表述。

业务架构

业务意识

互联网时代有个岗位——产品经理。而在互联网大规模发展起来之前，软件行业通常称为“需求分析师”。技术不是无源之水，一旦离开业务纯粹地谈技术，就失去了驱动技术发展的根本要素。另一方面，研发部门的人力资源和时间资源是有限的，而业务需求是无限的，要用有限的资源应对无限的需求，必然存在需求的取舍问题，而这种取舍往往也会影响系统的架构设计。对于一个技术人员，不需要像产品经理或需求分析师一样对需求了如指掌，但具有良好的业务意识却是做业务架构的基本条件。

1. 需求来自何处？
2. 真需求还是伪需求
   1. 技术人员经常会听到要开发一个某某功能、一个某某系统，但“功能”和“系统”并不是需求。需求是要解决的“问题”，而问题一定是系统所要面对的用户问题或客户问题，功能或系统只是解决问题的一种答案而已。
   2. 一个需求被用户或客户提出来，可能经过总监、组长、产品经理层层传导，等传到了技术人员，可能已经不是最初的需求，最后做出来的东西往往不是对方真正想要的。
   3. 所以，作为一个技术人员，当从产品经理接到需求的时候，一定要回溯，明确需求是在什么背景下提出的，究竟要解决用户的什么问题。
3. 产品手段vs技术手段: 通过产品的设计解决技术问题
4. 需求的优先级: 系统的架构是被需求驱动着一步步迭代、升级

什么是业务

个内容是否算作一个“业务”往往与公司的长期战略、盈利模式、发展阶段、组织架构密切相关，并没有一个标准的划分方式。但抛开这些差异性，一个内容能称为一个“业务”，往往具有一个特点，就是“闭环”。

• 团队闭环：有自己的产品、技术、运营和销售，联合作战。
• 产品闭环：从内容的生成到消费，整条链路把控。
• 商业闭环：具备了自负盈亏的能力（即使短期没有，长期也是向这个发展方向）
• 纵向闭环：某个垂直领域涵盖从前到后。
• 横向闭环：平台模式，横向覆盖某个横切面。

同时闭环可大可小。

• 小闭环:：一个部门内部的某项内容有独立的产品、技术、运营团队，独立运作。
• 大闭环：事业群、事业部级别，公司高层战略来决定的。
• 更大的闭环：产业上下游，构建完整的生态体系。

“业务架构”的双重含义

前面的案例讨论的“业务”，其实对应的是“业务架构”一词的字面意思，也就是“业务的架构”。这通常关乎大的战略，主要是从商业角度去看，公司高层领导决定的。但对于技术人员来说，讨论业务架构的时候则是另外一个意思:“支撑业务的技术架构”。注意，这里的落脚点在技术上，是从技术的视角看业务应该如何划分。业务架构既关乎组织架构，也关乎技术架构，业务架构、组织架构和技术架构三者之间的关系是怎么样的呢？

1. 先说业务架构的第一重意思。从理论上讲，合理的团队的组织架构应该是根据业务的发展来决定的。不同的公司在不同的发展阶段会根据业务的发展情况，将壮大的业务拆分，萎缩的业务合并。拆分到一定的时候又合并，组织架构相应地跟着调整，相应的技术团队跟着整合，技术架构自然也会跟着变化。这种变化规律在半个世纪前就已经被提出，也就是 “康威定律”：一个组织产生的系统设计等同于组织之内、组织之间的沟通结构。这也意味着：如果组织架构不合理，则会约束业务架构，也约束技术架构的发展。而组织架构的调整涉及部门利益的重新分配，所以往往也只能由高层来推动。
2. 业务架构的第二重意思。“支持业务的技术架构”,业务架构和技术架构会相互作用、相互影响。举个例子，对于广告业务，如果认为CPC（效果广告）、CPM（展示广告）、CPT（按时间段计费）是三个业务，可能会各自设计三套技术架构方案，并让三个团队去做；但如果认为是一个业务，会思考这三者之间哪些是共用的，哪些又是个性化的，尽可能把三者通过一个技术架构支撑，让一个团队去做。这种技术的思考会反过来影响业务，重新思考团队的组织方式，团队的组织方式又会变,接下来又会影响业务的发展方式。

“业务架构”与“技术架构”的区分

之所以要谈“分”，是因为经常遇到的情况是：明明是业务问题，却想用技术手段解决；明明是技术问题，由于技术无法实现，反过来将就业务；可能既不是业务问题，也不是技术问题,而是组织架构问题，是部门利益问题，是公司的盈利模式问题。

一般技术架构要关注的一系列问题:

1. 你的系统是在线系统还是离线系统？
2. 如果是在线系统，需要拆分成多少个服务？每个服务的QPS 是多少，需要部署多少台机器?
3. 运行方式是多线程，多进程？还是线程同步机制，进程同步机制？
4. 如果是离线系统？有多少个后台任务？任务是单机，还是集群调度？
5. 对应的数据库的表设计？是否有分库分表？
6. 数据库的高可用？
7. 服务接口的API 设计？
8. 是否用了缓存？缓存数据结构是怎样的？缓存数据更新机制？缓存的高可用？
9. 是否用了消息中间件？消息的消费策略？
10. 是否有限流、降级、熔断措施？
11. 监控、报警机制？
12. 服务之间的数据一致性如何保证？比如分布式事务。

通过上面一系列问题可以看到，技术架构涉及的都是“系统"“服务”“接口”“表”“机器”“缓存”这样技术性很强的词语。这些是开发人员直接可以通过写代码实现的，很务实，没有虚的内容在里面。把上面这些内容梳理一下，归类后就变成了我们经常挂在嘴边的各种架构词汇：

1. 物理架构（物理部署图）;
2. 运行架构（多线程、多进程）；
3. 数据架构（存储系统的选择、数据库表的schema）；
4. 应用架构（系统的微服务划分）；

从具体技术到抽象技术，再到业务，所用的词汇会越来越抽象，越来越偏向各自的领域，则在沟通和表达过程中，产生歧义的概率就越大。实践中只有时刻意识到我们面对的是业务问题，还是技术问题，或是其他的更高层次的问题，才可能在一个正确的层面上去解决。通过分析，我们知道了“技术架构”究竟代表什么，这也为我们提供了一个参照系。“业务架构”不是“技术架构”，是“技术架构”外面的东西。

业务架构思维

警惕“伪”分层

分层其实不光是一个技术词汇，而是一个通用的思维方式，比如架构图分层，实际的代码、系统是否能按分层架构严格执行呢？如果把所有系统之间的调用关系都梳理出来把依赖关系图画出来，不一定会是这样一个分层结构，很可能是一个网状结构了。产生了伪”分层。

1. 底层调用上层。比如某个基础服务调用上层的业务服务，怎么解决呢？
   1. 要思考业务逻辑是否放错了地方? 或者业务逻辑是否需要一分为二，一部分放在业务服务，一部分放在基础服务。也就避免了底层调用上层。
   2. DIP（依赖反转）。底层定义接口，上层实现，而不是底层直接调用上层。
2. 同层之间，服务之间各种双向调用。比如业务服务1、业务服务2、业务服务3 之间都是双向调用。这时就要思考，业务服务1、业务服务2、业务服务3 之间的职责分配是否有问题，出现了服务之间的紧耦合？是否应该有一个公共的服务，让公共服务和业务服务1、业务服务2、业务服务3 交互，而三个业务服务之间相互独立?
3. 层之间没有隔离，参数层层透传，一直穿透到最底层，导致底层系统经常变动。例如，App 一直发版本，为了实现兼容，服务器端会根据不同的版本调用不同的函数。比如客户端要支撑各式各样的业务，因此肯定有类似 businessType 用于区分不同业务，或者说区分同一个业务的不同业务场景。businessType 字段一旦透传到最底层的基础服务，在基础服务里面都能看到if busessType = XXX 这样的代码，就是典型的上层业务多样性透传到了最底层。这种情况下，虽然是严格分了层，层层调用，但“底层服务”已经不是底层服务，因为每一次业务变动都会导致从上到下跟着一起改。
4. 聚合层特别多，为了满足客户端需求，各种拼装。遇到这种情况，往往意味着业务服务层太薄，纯粹从技术角度拆分了业务。而不是从业务角度让服务成为一个完整的闭环，或者说一个领域。

一个优秀的分层架构应该具有的典型特征如下。

1. 越底层的系统越单一、越简单、越固化；越上层的系统花样越多、越容易变化。要做到这一点，需要层与层之间有很好的隔离和抽象。
2. 做到了上面一点，则要做到层与层之间严格地遵守上层调用下层的准则。

边界思维

在所有的架构思维模式中，如果说最终只能留下一种思维模式，那就是边界思维。腾讯公司前CTO 张志东曾说过“优雅的接口，龌龊的实现”，可以说是边界思维最好的昵释。在技术领域,“封装”“面向接口的编程”等技术，也都是边界思维的体现。只要一个系统对外的接口是简洁、优雅的，即使系统内部混乱，也不会影响到外界其他系统。相当于把混乱的逻辑约束在一个小范围内，而不会扩散到所有系统。边界思维是一种通用的思维方式，从小到大来，边界思维在不同层面的均有体现。

1. 对象层面（SOLID 原则）：在面向对象的五大原则中，第一个原则S 就是单一职责原则（The Single ResponsibilityPrinciple）。通俗地讲，就是一个函数、一个类、一个模块只做一件事。不要把不同的职责杂糅在一起,这就是边界思维的一种体现。
2. 接口层面：对于开发人员来说，做一个系统往往先想到的是如何实现。而利用边界思维，首先想到的不是如何实现，而是把系统当作一个黑盒，看系统对外提供的接口是什么。接口也就是系统的边界。接口定义了系统可以支持什么、不支持什么。所以，接口的设计往往比接口的实现更重要！站在使用者的角度来看，并不在意接口如何实现，而更在意接口的定义是否清晰，使用是否方便。具体来说，就是：接口的输入、输出参数分别是什么？哪些参数可选，哪些必选？如果输入参数很多，为什么不是分成多个接口？设计策略是什么？接口是否幂等？各种异常场景接口的返回结果都是什么?
3. 产品层面：除了技术，产品同样需要有边界思维。对于产品，常说的一句话是:内部实现很复杂，用户界面很简单。把复杂留给自己，把简单留给用户！尤其现在的AI 产品，更是把这句话发挥到了极致。AI 算法本身很复杂，但对用户来说，使用却越来越“傻瓜化”，以前还有图形界面，现在直接对着系统说句话，它就明白了。
4. 组织架构层面：组织的各个部门之间如果没有非常清晰的边界，就会导致该自己做的事情不做，互相推诿、踢皮球；不该自己做的事情抢着做，你争我夺。最后整个体系权责不分，做事效率低下，还容易产生各种问题。

回到系统，不管用哪种分析方法和设计方法，最终必须保证每个系统有清晰的边界，各自分工清晰。无论谁要了解这个系统，他不用看这个系统是怎么实现的，只要看系统的接口，就能知道系统支持什么，不支持什么。边界思维的重点在于“约束”，是一个“负方法”的思维方式。什么意思呢? 比如要看一个开源软件的功能，要看的不是它能做什么，而是它不能做什么！“不能做什么”决定了系统的边界，或者说它的“极限”。做架构尤其如此，架构强调的不是系统能支持什么，而是系统的“约束”是什么，不管是业务约束，还是技术约束。没有“约束”，就没有架构。一个设计或系统，如果“无所不能”，则意味着“一无所能”。

系统化思维

与边界思维相对应的是系统化思维。哲学中有一句话:事物之间的普遍联系。通俗的说法就是:不能头痛医头，脚痛医脚。头痛的时候，可能原因不在头上，而是身体其他部位出了问题引发的头痛。

1. 比如现在有一个系统A 和系统B，应用边界思维，在两个系统之间定义了接口。但随着业务的发展，发现每次来新的需求，两个系统都要跟着一起改，之间的接口也不够用，要么增加新接口，要么为之前的接口增加新参数。原因可能是在最初设计的时候，接口定义得不合理；也可能是这两个系统的逻辑本身就耦合得很紧。应该把系统A 和系统B 重新放在一起整体考虑，然后一致对外提供统一的接口，对内，系统A 和系统B 就是一个系统的两个联系紧密的部分。这就是系统化思维的一种体现，把不同的“东西”串在一起考虑，而不是割裂后分开来看。
2. 系统化思维的另外一个体现，就是遇到事情要刨根问底。如果遇到了问题A，经过分析，是原因1 导致的;原因1 又是如何产生的，是原因2 导致的;原因2 又是如何产生的，是原因3 导致的……如此追到最后，直至事物的本质。这点在物理学中叫作“第一性原理”，在哲学上叫作“道”。无论是遇到技术问题，还是产品问题、业务问题，都可以利用这种思维方式。这个倒追的过程会让你探究到事物与事物之间的普遍联系。
   • 比如一个电商系统中商品库存。站在C 端来看：用户下单，要减库存；用户发生客退，要加库存；站在B 端供应商角度来看：采购，要加库存；退供，要减库存；站在内部商务和物流人员角度来看：调拨，一个仓库减库存，另一个仓库加库存。无论C 端的下单、客退，还是B 端的采购、退供，还是内部的调拨，都是很复杂的业务流程，对应的是不同的团队开发的不同系统。单独去看每一个业务的每一个系统，都没有问题，但要系统性地把这五大类业务串在一起来看，可能库存的账目是对不齐的。
   • 这就是为什么电商系统里库存往往是单独的微服务，库存不仅仅是一个数字<SKU,数量>，然后对这个数字进行加加减减，逻辑很简单。但实际问题在于库存不是一个简单的数字，而是一个复杂的数据模型，有自己单独的领域。

利益相关者分析

做一个系统与做一个产品一样，首先要了解用户是谁。在架构里面称为利益相关者。为什么谈业务架构，要先谈“利益相关者”呢?

1. 利益相关者其实是从“外部”来看系统。把系统当作一个黑盒子，看为哪几类人服务。这其实也就定义了整个系统的边界，定义了整个系统做什么和不做什么。
2. 前面说到一个词“业务”，业务具有“闭环”的特点。而利益相关者就是一个最好的看待业务的视角。
3. 每个利益相关者代表了一个视角。站在C 端用户的视角和B 端商家的视角上，对系统有不同的看法。系统很复杂，无法从一个角度全面认识，每个视角都是盲人摸象，只看到系统的一部分。
4. 利益相关者往往也对应了一种业务划分、系统划分。根据不同的利益相关者,可以划分成不同的系统和业务。

所以，当谈到系统的时候，首先要确定的是系统为哪几类人服务，同哪几个外部系统交互，也就确定了系统的边界。

非功能性需求

软件有功能性需求和非功能性需求之分。其实软件的非功能性需求有很多，不同类型的软件的侧重点也有差别。互联网比较关注的有：

1. 并发性。对于C 端的系统，大家首先关注的是系统能抵抗多大的流量。说通俗点，是可以承受多少人同时访问。常用的衡量指标是TPS 和QPS，平均响应时间/最大响应时间，并发数。
2. 可用性。从服务角度来说，一个服务不可用有两层意思:
   • 机器宕机，不能对外提供服务，直接抛错;
   • 机器虽然没有宕机,但是超时。这涉及“性能”问题。
3. 一致性。比如数据库的参照完整性、事务、缓存与数据库数据同步、多备份数据一致性问题。
4. 稳定性和可靠性。“稳定性”指系统没有任何未定义的行为，体现在如下几方面:
   • 所有的if-else 语句里面,没有不处理的分支;
   • 所有的 API 调用，每种异常返回值都有处理;
   • 考虑内存、磁盘的上限;
   • 系统不会时不时冒出一个问题出来;
   • 出了问题,有很好的日志监控,能快速修复;
   • 系统的QPS 不会有抖动（除非业务有变化，比如大促），是一条平滑的
   • 发布新版本,有回滚方案;
   • 新系统上线,灰度平滑切换;·
   • 通过压力测试;
5. 可维护性。与可维护性密切相关的是“可理解性”,或者说“代码可读性”。体现在如下几个方面:
   • 系统架构设计简单，接口简洁，表数据关系清晰;
   • 老人离职,新人接手，无须很长时间就能厘清代码逻辑;
   • 系统功能不耦合,改一个地方不会牵动全身;
   • 系统某些模块即使时间久远,也有人能厘清内部逻辑;
6. 可扩展性。体现在如下几方面:
   • 来了一个新需求，伴随一些新功能，可以在现有系统上灵活扩展
   • 没有地方写死，可以灵活配置;
   • 容易变化的逻辑没有散落在各个系统里面，不需要多个地方跟着一起改。
7. 可重用性: 开发新的需求，旧的功能模块拿过来可以直接用。

通常来讲，对于C端应用，会更关注高并发和高可用，然后有的业务（比如支付）对一致性要求非常高；对于B端业务，会更关注系统的可维护性、可扩展性性，系统才能不拖业务的后腿，可以快速地支撑各种各样的复杂业务需求的开发。

抽象

抽象是人类思维认知的一个基本能力，在现实生活和各种学科中都会遇到。具体到计算机的软件架构里，就是分析和分解各种概念、实体、系统，然后又造出一些新的概念、框架的过程。

• 计算机中的抽象
  • 存储的抽象: 关系型数据库,表格。现实世界中的数据各式各样，但到了计算机中，有一种东西叫关系型数据库。通俗地讲，就是一张张的表格，然后表格之间通过主外键关联起来。这其实就是一种抽象，把现实世界中花样繁多的数据形式进行规整,最终变成了一张张的表格。
  • 计算的抽象是顺序、选择、循环。再复杂的算法，逻辑计算到了计算机里面，最终都会变成顺序、选择、循环三种语句。现实的逻辑很复杂，但计算机里面的逻辑只有三种。
  • 面向对象的方法学: 父类与子类、继承。在面向对象的方法学里面，提取共性形成父类，提高代码复用性，这是抽象。
  • 面向接口的方法学。把面向对象的方法再往前推进一步，就是所谓的“面向接口的方法学”。接口是交互双方的一种协议，也是对交互细节的一种抽象。
• 怎么做抽象
  • 分解：找出差异和共性。要做抽象，首先要做的是分解。只有分解，才知道两个事物间的差异和共性。
  • 归纳：造词。找到了共性和差异，把共性的部分总结成一个新的东西，造一个新词来表达“共性”，就是归纳，也是抽象。所以抽象的过程往往也是一个“造词”的过程。
• 抽象带来的问题: 抽象的好处就是找出共性、简化事物，但抽象也会造成问题
  • 抽象造成意义模糊。越抽象的东西往往越“虚”，最后就变成“空洞的大话”，华而不实。不同人对“虚”的东西理解都不一样，大家在沟通时往往不在同一个频道中，牛头不对马嘴。
  • 抽象错误：地基不稳。没有做分解就分析，会把一个非原子性、容易变化的东西抽象出来，作为整个系统的基础。
  • 抽象造成关键特征丢失。把事物的某个重要的关键特征抽象掉了，会导致对事物的认知偏差。
  • 抽象过度。抽象是为了提供灵活性和扩展性。但如果业务在某一方面变化的可能性很小，则可能压根不需要抽象。

技术管理

能力模型

• 格局
  • 系统的定位是什么？它能创造哪些核心价值？
  • 开发这个系统的背景是什么？为什么以前不做，现在要做？是因为业务发展到了一定规模？还是开发资源现在有多余，没事可干?
  • 系统在整个组织架构中处于什么位置？与这个系统关联的其他系统目前处于什么状况？
  • 产品经理如何看待这个系统？技术负责人/CTO 如何看得这个系统？
  • 这个系统的需求处于比较确定清晰的状态，还是有很大的模棱两可的空间，核心点大家有没有想清楚?
  • 这个系统所用的技术体系是比较老，还是最新的?
  • 对于业界类似的系统，别的公司是如何做的?
  • 在做一件事情之前，会对所做的事情有一个“全局把握”，风险如何？挑战在哪？提前都有心理准备
  • 不同层次的人聚焦的范围不一样。如果能把自己的“范围”往外扩大一圈，这对自己做“本职工作”会很有益处。而这，就是“格局”
• 技术历史
  • “格局”是从空间的角度看待问题，那么“历史观”就是从时间的角度看待问题。
  • 任何一种技术，都不是凭空想象出来的，它一定是要解决某个特定问题而产生的。
  • 这个特定问题一定有它的历史背景：因为之前的技术在解决这个特定问题时不够好或有其他副作用，所以才发明了这个新技术。所以，看待一个技术或方法论，需要把它放到“历史长河”中去，看它在历史中处于什么位置。
• 抽象能力
  • “抽象能力”已经有所说明，这个词听起来很“虚”。可作为架构师，就是需要这种“务虚思维”。
  • 抽象也是一个“层次”结构，从最底层到最上层，在不同工作阶段需要在不同的抽象层级中思考。
  • 很多写代码的人都习惯“自底向上”的思维方式。当讨论需求的时候，他首先想到的是这个需求如何实现，而不是这个需求本身是否合理？这个需求与其他需求有何关联关系。
  • 这种过早考虑“实现细节”的思考方式会让我们“只见树木，不见森林”，最终淹没在错综复杂的各种细节之中，因层次混乱，往往把握不住重点。
  • 假如做一个新的系统，从“抽象”到“细节”，应该考虑:
    • 每个需求的合理性?
    • 这个系统的领域模型是什么样的?
    • 这个系统应该在旧的上面改造?还是应该另起炉灶?
    • 这个系统可以分成几期，分期实施?
    • 这个系统要拆分成几个子系统?·每个子系统又要拆分出多少个模块?
    • 系统的表设计?API 接口设计?系统之间的消息传输如何实现?
  • 从上到下，是一个逐级细化的过程，并目进入到下一级之后，上一级可能又会退回去修改。
• 深入思考的能力
  • 深入思考能力主要指“技术”的深度。关于“广度”，在“格局”层面已经包含。
  • “深度”并不是要在所有领域都很深。人一生的精力是有限的，我们不可能深入掌握所有技术领域，但至少需要对于一个领域非常精通。
  • 拥有这种深度并不代表要胜任当前的工作必须达到这种要求，而是要养成这种“深入思考的习惯”，当我们在思考其他问题时也会带着这种“习惯”。
  • 由于技术一直在更新换代，当面对一个新技术的时候，如果具有深入思考的能力和习惯,对新技术的理解往往也会更透彻。
  • 同时，“深度”会让你对“技术风险”有更加清醒的认知。在做一个项目的时候，可能会前发现里面潜在的“坑”，而不是等到实施了才发现问题，被动解决。
• 落地能力
  • 落地能力就是通常所说的“执行力”,取决于很多因素。首先,架构方案必须是能够落地的而不是只能停留在PPT 上面。对于一个技术管理者，需要跟踪从架构设计到架构落地的完整过程，在落地过程中发现问题，实时修正，才可能真正做到“理论”与“实际”的统一。
  • 然后是项目管理的问题，需要对项目中任何可能存在的不确定因素、阻碍项目进度的因素进行把控。在这些不确定因素里面，很多是“人”的因素，而不是“技术”的因素。再复杂的系统,都是由“人”开发出来的。而人多了之后，与“人”相关的问题会自然产生:沟通不充分、组织混乱、职责不清。作为一个技术管理者，需要意识到这些问题的存在，然后在各种障碍之下找到一条路线,去达成业务和团队目标。

影响力的塑造

• 关键时候能顶上
  • 某个问题困扰了团队一个星期，也没有人能搞定;
  • 某个成员离职，他负责的模块没有人接手;
  • 某位用户反映的问题像牛皮癣一样，总是时不时发生,无法根治;
  • 某个需求发生工期延误，到了快上线的时候却上不了;
• 打工思维和老板思维
  • 这个产品的价值究竟在哪?
  • 这个产品有什么问题，如何改进?
  • 团队的协作流程有什么问题，如何改进?
  • 技术架构有什么问题，如何改进?
  • 某些用户投诉一直没解决，如何处理?
• 空杯心态：术业有专攻。水平再高的人，也只是在某一个领域很强换一个其他的领域，可能什么都不懂。
  • 任何时候，我们需要意识到自己的“无知”。只有意识到自己是有“局限的”，才可能不断去听取别人的意见，不断改进自己的工作方法,提升自己的专业能力和视野。否则就会一直待在自己的舒适区里,刚愎自用。
• 持续改进：世界上从来没有能做到100 分的事情，只要想“鸡蛋挑骨头”，总可以找出要改进的地方
  • 所以要有“批判性思考”的习惯。不能觉得“差不多”就可以，要追求极致，其实有很多事情要做。
• 建言献策
  • 接上面的问题，如果有“批判性思考”的能力，能看到一个组织存在的各种问题，并想出应对的解放办法。然后多和同事、领导沟通这些事情，无论对于个人成长还是组织，都是一个正向作用。

最后换位思考一下:如果我们看到公司某个同事在关键时候能顶上，做事追求极致，思考总是很全面，对业务的了解总是比其他技术人员要多，总是很虚心地接受意见，时不时地给公司提出自己的建议。是不是觉得这个人很靠谱，觉得这个人适合带团队。

团队能力提升

• 不确定性与风险把控：技术管理的首要任务是项目管理。从人的认知来讲，做任何事情，思路都是从一个“朦胧”到逐步“清晰”的过程，项目的进展也是一个从思路、到方案、到落地的细化过程。在这个过程中，不可避免地存在各种“灰度”，或者说“不确定性”。而项目管理就是要提前防范各种“不确定性”，并采取相应措施，让整个团队、项目克服重重干扰，成功到达终点。
  • 需求的不确定性：很可能项目在一个想法没有完全想清楚的情况下就开始了实施。遇到这种情况，作为技术负责人，需要和产品经理、相关业务方、上级领导等进行广泛的沟通，最终在这个事情上达成“共识”：到底哪些是东西清晰的，我们可以开始做,哪些还需要进一步思考和细化
  • 技术的不确定性：必须在项目早期做尽可能多的调研和测试。对于引入的技术框架，哪些特性可以支持、哪些不能支持;对于技术选型，不同方案的优缺点都是什么。尤其是一些关键的技术细节，如果在前期不调研，等到中后期才发现某个框架无法支持或有问题,可能对整个的技术架构和项目进度造成严重影响。
  • 人员的不确定性：不要把项目最核心的部分让一个人开发维护，导致别人无法插手。要分摊风险，在技术的架构设计层面，保证整个系统耦合性不能太高，根据团队成员的水平，每个人都可以承担一块东西。这样即便某个人离职，也有相应的人可以补上。
  • 组织的不确定性：公司越大，业务越复杂，部门越多。随便做一个项目，都可能与好几个业务部门打交道。这些部门可能还在异地，平时只能即时通信，或者远程电话沟通。对于这种情况，在项目前期必须要做尽可能多的沟通，调研对方提供的业务能力，哪些目前有,哪些还在开发中，哪些还没有开发。在充分沟通的基础上，和对方敲定排期表，不定期地同步进度，保证对方的进度和自己在一个节奏上。
  • 历史遗留问题：有些老项目的技术架构很清晰，文档清楚，业务清楚，还有对项目熟悉的其他同事;也有些遗留项目欠了很多技术债，之前的开发人员也走了，业务人员很多都熟悉。对于这种情况，需要对项目进行完整的梳理:从产品到技术，找各个接口人沟通，可能经过了两三个月，才对整个系统有了一个全局的把控。总之，要有“风险把控”的意识，在项目早期努力地想出各种各样的“不确定性”，未雨绸缪。
• 以价值为中心的管理
  • 如何衡量这些项目的价值大小：有多少人使用了这个开源项目
  • 第一个层次：系统有多少个业务模块，功能多么强大，采用了多少新技术,采用了某个先进的算法
  • 第二个层次：在所做的所有工作中，最核心的是采取了哪种措施?最终可能会抽象出一到两个。再追问一下,这一到两个大的技术改进有什么价值，通常都会追问到软件的各个非功能性需求：
    • 可重用性。做了某个Jar 包、组件、服务，别人不再需要重复造轮子。
    • 可扩展性。来了一个新的需求，只需要配置一下或做很简单的代码开发即可实现，不需要改动很多系统。
    • 可维护性。整个系统解耦做得很好，代码也很整洁。叠加功能或找人接手都比较容易。
    • 高性能。用户体验很好，所有请求都在100ms 内返回。
    • 高并发。能支持千万到亿级的用户并发访问。
    • 稳定性。系统时不时出问题、宕机，已经把这些问题都解决了，还增加了监控，出问题会立即报警。
    • 高可靠。做了灾备方案，即使某个机器宕机，系统也不受影响。
    • 一致性。做到了强一致性,极大地提高了业务体验。
  • 第三个层次：所做的系统为公司带来了什么业务价值
    • 极大提升了用户体验?因此促进了用户增长?提高了用户的活跃度?
    • 为公司增加了收入?
    • 降低了公司的研发成本?
    • 提升了公司的运维效率?
    • 为公司开辟了一个新的市场?
  • 第四个层次：站在公司的角度来看，公司是一个在市场经济中追求利润最大化的组织。从这个角度来看，技术也好，产品也好，运营销售也好，最终目的都是要增加公司的利润，即使短期不盈利，长期也是要盈利的。而增加利润，要么“开源”，要么“节流”。所以做的任何东西的价值，基本都会被归结到从这个层次去评判。当然，还有一类是“战略性投入”的项目，虽然它本身不直接挣钱或挣钱很少，但是为了支撑其他盈利的核心业务而能发挥重要作用。
  • 在这四个层次之外，当然还可能会涉及研究性质的技术、技术的普惠性、技术对整个社会的促进作用等,这已经超出了某个业务的技术范畴。目前国内的互联网公司这个方面比较少，国外的Google 等做的比较好。
  • 以“价值”为中心的管理，会让人避免陷入“无效忙碌”的状态: 整个团队天天忙得不亦乐乎，做各种功能，解决各种问题，但回过头来想想，到底有多少东西是有“价值”的?
• 团队培养：有些技术团队的负责人水平很高，解决问题迅速，但团队成员技术平平，遇到问题都需要负责人亲自上阵解决、累个半死，团队整体非常低效，成员得不到成长，这是典型的缺乏团队培养的思维和意识的案例。
  • 技术能力：要培养人，首先得“识人”。只有清楚地知道团队成员的技术能力层次，才能针对不同层次的人设置不同的培训内容。
    • 初级：全部是“面条式”代码，超长类、超长函数，各种晦涩难懂的if-else。写出来的代码时常出问题，且长时间定位不到问题,对写的功能无法完全掌控
      • 需要时常做代码评审，需要读《数据结构与算法》《代码整洁之道》之类的书籍，培养代码思维
    • 中级：能熟练地完成各种功能开发，问题少，出现问题能快速解决，代码模块化程度比较高，系统稳定，有业务运维的意识功底深厚，能解决各种开发中的“疑难杂症”
      • 要培养系统设计能力
    • 高级：熟悉业务,能根据业务设计出合理的技术方案
      • 虽然有系统设计能力，但不够深入,缺乏完善的方法论
    • 资深：对技术和业务都有深刻的思考，能对大规模、跨团队的复杂系统进行很好的架构设计。
      • 就解决问题来讲，技术已不是问题，需要发展的是业务能力，成为某个领域的技术领军人物
    • 对于一个技术团队来说，绝大多数都处于前三个层次，在技术上还有很多的上升空间。在这种情况下，需要在完成业务需求的同时，让团队成员的技术水平不断提高。可以不定期地举行技术培训、技术分享，在整个团队中形成一个较好的技术的文化氛围,形成一个人带人、人帮人的协作氛围。
  • 独立意识：独立非常的关键，无论对于任何级别的人，都需要独立。所谓独立，就是能掌控事情。交给一个功能开发，能独自把功能做得很好;交给一个模块，能把模块快速开发完，运行稳定;交给一个系统，能把系统从设计，到编码、上线，完整地接住;交给一个项目，能带领一个小团队从需求开始一直到上线完成整个项目，不需要上级操心,按时按质地交付。做到这一步，意味着团队的每个人在自己所处的层次都是可“托付”的，否则就会频繁出现“补位”。组长干组员的活，经理干组长的活，总监干经理的活，副总裁干总监的活……层层错位,最后整个组织缺乏“顶层设计”。
  • 思维能力：当团队成员遇到问题时，很多人的解决办法是，告诉他问题的解决办法，然后让他把这个问题解决好。如果只做到这一步，则没有起到培养的作用。对于一个团队来说，解决项目中遇到的问题只达到了及格分数。更需要在解决项目问题之上升华一层,也就是培养思维能力。
    • 思维能力的培养只能靠平时，在面对一个个的问题时，通过一次次的讨论来言传身教。面对问题要刨根问底，深挖问题的背景，掌握解决问题的办法背后的技术原理，研究是否有更好的解决办法……如此一来，思维能力慢慢就会提高。
    • 每个人在职场上工作，都是要养家糊口的。站在团队成员的角度去想下:如果跟着你干，能力没什么提升，薪资待遇也没什么增长，公司业务前景也看不到，为什么会跟着干呢?
    • 所以，作为一个管理者，要多去赋能他人、成就他人，做项目只是一个过程，最终是要打造一个极具战斗力的团队。有了这样的团队，可以在公司发展的不同阶段自如地切换到不同的业务。

总结梳理

**业务驱动技术：**需求来自何处？真需求还是伪需求？产品手段vs技术手段？需求的优先级？什么是业务：闭环

明明是业务问题，却想用技术手段解决；明明是技术问题，由于技术无法实现，反过来将就业务；可能既不是业务问题，也不是技术问题,而是组织架构问题，是部门利益问题，是公司的盈利模式问题，实践中只有时刻意识到我们面对的是业务问题，还是技术问题，或是其他的更高层次的问题，才可能在一个正确的层面上去解决，“业务架构”不是“技术架构”，是“技术架构”外面的东西

业务架构

• 业务架构既关乎组织架构，也关乎技术架构

  • **“康威定律”：一个组织产生的系统设计等同于组织之内、组织之间的沟通结构。**这也意味着：如果组织架构不合理，则会约束业务架构，也约束技术架构的发展。而组织架构的调整涉及部门利益的重新分配，所以往往也只能由高层来推动

  • 技术的思考会反过来影响业务，重新思考团队的组织方式，团队的组织方式又会变,接下来又会影响业务的发展方式

• 警惕“伪”分层：底层调用上层；同层之间，服务之间各种双向调用；层之间没有隔离，参数层层透传，一直穿透到最底层，导致底层系统经常变动；聚合层特别多，为了满足客户端需求，各种拼装（业务服务层太薄，纯粹从技术角度拆分了业务。而不是从业务角度让服务成为一个完整的闭环，或者说一个领域）

  • 越底层的系统越单一、越简单、越固化；越上层的系统花样越多、越容易变化。要做到这一点，需要层与层之间有很好的隔离和抽象。

  • 层与层之间严格地遵守上层调用下层的准则

• 边界思维：优雅的接口，龌龊的实现；把混乱的逻辑约束在一个小范围内，而不会扩散到所有系统

  • **单一职责原则；接口的设计往往比接口的实现更重要；把复杂留给自己，把简单留给用户；**组织的各个部门之间边界清晰

  • 边界思维的重点在于“约束”，是一个“负方法”的思维方式：要看的不是它能做什么，而是它不能做什么

    • 架构强调的不是系统能支持什么，而是系统的“约束”是什么

    • 没有“约束”，就没有架构；如果“无所不能”，则意味着“一无所能”

• 系统化思维

  • 把不同的“东西”串在一起考虑，而不是割裂后分开来看

  • **刨根问底：**单独去看每一个业务的每一个系统，都没有问题，但要系统性地把这五大类业务串在一起来看，可能库存的账目是对不齐的。所以库存往往是单独的微服务，实际问题在于库存不是一个简单的数字，而是一个复杂的数据模型，有自己单独的领域

• **利益相关者分析：**首先要确定的是系统为哪几类人服务，同哪几个外部系统交互，也就确定了系统的边界

  • 把系统当作一个黑盒子，看为哪几类人服务。也就定义了整个系统的边界，定义了整个系统做什么和不做什么。

  • 业务具有“闭环”的特点。利益相关者就是一个最好的看待业务的视角。

  • 每个利益相关者代表了一个视角

  • 根据不同的利益相关者, 可以划分成不同的系统和业务。

• 非功能性需求：并发性；可用性；一致性；稳定性和可靠性；可维护性；可扩展性；可重用性；

  • 对于C端应用，会更关注高并发和高可用，然后有的业务（比如支付）对一致性要求非常高；

  • 对于B端业务，会更关注系统的可维护性、可扩展性性

• **抽象：**分析和分解各种概念、实体、系统，然后又造出一些新的概念、框架的过程

  • 计算机中的抽象：存储的抽象；计算的抽象是顺序、选择、循环；面向对象的方法学；面向接口的方法学；

  • 怎么做抽象：分解（找出差异和共性）；归纳（造词）；

  • 抽象带来的问题：抽象的好处就是找出共性、简化事物

    • 抽象造成意义模糊；抽象错误；抽象造成关键特征丢失；抽象过度

技术管理

• **能力模型：**格局；技术历史 ；抽象能力（从上到下）；深入思考能力；落地能力（执行力&项目管理）；

• **影响力的塑造：**关键时候能顶上；老板思维；空杯心态；持续改进；建言献策；

• 团队能力提升

  • 不确定性与风险把控：需求；技术；人员；组织；历史遗留问题；

  • 以价值为中心的管理：技术；非功能性需求；业务价值；公司角度；“战略性投入”项目；研究性普惠性技术；避免陷入“无效忙碌”的状态

  • 团队培养

    • 技术能力（识人与培养）：初级、中级、高级、资深

    • 独立意识：每个人在自己所处的层次都是可“托付”的

    • 思维能力

      • 通过一次次的讨论来言传身教

      • 每个人在职场上工作，都是要养家糊口的，多去赋能他人、成就他人