架构师，到底是干什么的？

---

前言

  很多公司对于架构师的职责没有明确的定义，这就导致很多人顶着架构师的头衔，却一直在做一些基层主管的工作。那么，架构师到底是干什么的？今天，我们就结合当前互联网环境，来分析下架构师的核心职责。

---

一、架构师所面临的技术挑战

（一）、反射式研发行为

  不论是初创公司还是大企业里的初创团队，往往持续面临着巨大的交付压力，导致一种“反射式研发”的行为：写代码就像膝跳反射一样。 研发人员的日常工作都是在接需求、写代码、上线、修故障之间循环，很少有时间去思考和追求长远的设计。这种短期行为虽然不影响业务迭代，但如果在大型架构活动中频繁出现，造成的后果将是灾难性的。

（二）、分布式研发团队

  互联网企业往往有多个分布在全国甚至全球各地的研发团队。在这种跨地域、跨语言的研发模式下，每个研发团队内部可能有非常多的交流，但是各个研发团队之间的沟通，相比之下就是互相隔离的。

（三）、普遍存在认知差异

  每个团队，甚至每个研发，平时都在自己的隔离环境下高强度地开发代码，所以大家一般没有统一的语言和全局的认知。这种情况在业务和产品团队中同样存在。因此，达成一个宏观的、完整的、可行的、被普遍认可的规划就变得非常困难。

（四）、大型架构活动本身的挑战

  在高风险和高回报预期的场景下，大型架构活动需同时应对目标漂移和执行复杂度的双重挑战。一方面，业务目标可能随市场变化而调整，导致架构方案需要频繁迭代；另一方面，活动涉及大量资源协调、跨团队协作和技术难点攻坚，任何环节出现疏漏都可能影响整体结果。

二、架构师的核心职责

（一）、建设共识

  架构师需要克服分散的研发团队、普遍存在的认知差异、习惯于独立决策的研发团队所带来的认知局限，引导参与者在对架构活动的认知上达成共识。所谓共识，在架构活动里，就是尽可能让更多的人在限定时间里达成一致。很多人误以为共识就是投票，让少数服从多数。其实不然。投票是一种表面公平但其实非常暴力的决策方式，它是在参与者无法达成共识的情况下，依然要获得一个决策的办法。而共识的目标并不是达成一个决策，而是让尽可能多的参与方认可一个决策。

  达成一致的关键在于找到架构活动参与方的认知差异点，然后再想办法消除。认知差异点的来源主要有三个方面：

1. 利益不同：这很好理解，不同团队的绩效目标、资源分配、优先级排序都会有差异。
2. 视角不同：架构师往往是从整个架构活动的视角出发，但其他参与者只会从各自团队的视角出发。
3. 内在差异：比如因为职能、工作背景和语言文化的不同，也会带来认知上的差异。

  那么，应该怎么抹平这些认知差异？

1. 通过多轮的沟通与对齐，让各方充分表达诉求，同时借助可视化的方案、原型或演示来降低理解门槛。
2. 在关键分歧点上，引入第三方仲裁或数据验证，帮助团队基于事实而非情绪做判断。
3. 明确统一的成功标准和验收口径，以减少后续的争执。

（二）、控制风险

  架构师需要在架构活动的全生命周期中持续收集、发现、评估、控制和传递风险。同时不断提升对风险的理解，逐步完善预案。并能在成本可控的情况下选择合理冒险，同时随时跟踪风险变化，及时传递重大风险，最终把风险控制在可接受的范围内。

  所谓风险，在架构活动里，指的是有可能带来损失的不确定事件。具体怎么做呢？有三个关键动作：

1、逐渐形成量化认知

  发现和评估风险是个极其耗时间的过程。在互联网企业，不仅每天都有新风险，而且现有的风险还在不断变化。要是把风险评估作为一次性的前置环节，不仅会占用大量宝贵时间，也不能有效控制风险。 所以成本更低的做法是“搭车制”：架构师要在架构活动中持续预留一部分精力，任何时候都先关注已知的最大风险，然后随着时间推移，不断对这些风险形成更深刻的认知。而这些认知最终将转化成能够准确量化的风险控制成本和企业的预期损失。

2、可以冒险

  在架构活动中，如果我们发现了一个风险，也对损失有了一定的预估，并准备好了预案以响应不确定性事件，这个时候，就可以“冒一次有准备之险”。 为什么要这么做呢？如果企业能接受预估的损失，且风险预案的成本与预估损失差别不大，那么忽视这个不确定性事件，既可以省下宝贵的研发资源，投入到更紧急的需求中去，还能让我们获得宝贵的时间资源，以更快的速度去做业务迭代。

  纵观早期的互联网公司，都是在速度上抢先于监管和竞争对手，所以才积累下了海量的用户、行为数据和财富，进而获得了更高的增速。可以说，冒险是互联网公司的重要共同特征。

3、不能不说

  架构师的权责，还没有大到可以代替公司去决定风险政策的地步，所以必须向上及时传递重大风险和冒险行为，而不是直接采取冒险行为。大多数时候风险是连续的，但是很多突发事件都会让风险产生大幅变化。一旦风险升级，你需要寻找有效的控制手段和响应预案，并且能对效果做一定程度的验证，以此来提升团队对风险变化的响应能力。如果没有找到有效的控制手段，而风险又很大，那么最好的办法就是及时向决策者传递风险预警。

（三）、保障交付

  保障交付意味着架构师能够降低大型架构活动的不确定性和复杂度，最小化架构方案，最终保障高质量的交付。其中关键动作有三个：降低不确定性、控制复杂度和最小化架构方案。

1、 降低不确定性

  不确定性的来源有多个方面：

1. 目标的不确定性：主要是决策层对目标的不确定导致的。
2. 资源的不确定性：企业往往会同时有多项研发活动，而整体研发资源不足以完成所有任务。架构师必须在有限的研发资源池里争抢份额，以保障架构活动的交付。
3. 用户需求的不确定性：用户需求与我们的期望不一致，或者需求随时间发生较大变化。

  那么，我们应该如何应对这些不确定因素呢：

1. 通过阶段性的目标冻结与评审机制，减少目标反复变更带来的冲击。
2. 在资源分配上，提前与管理层和相关团队协商锁定关键人力。
3. 在需求层面，采用快速原型验证、用户访谈和小范围灰度发布等方式，尽早暴露偏差并调整方案。

2、复杂度控制

1. 从问题域层面分解架构规划和交付方案：将整个架构活动按问题域拆分成不同领域的子问题，再从粗到细分解成细粒度的执行方案。这样可以最大程度利用已有的沟通协作机制，降低交付风险。
2. 增加架构设计方案本身的结构性：即不同领域、不同模块的设计是同构的。例如，不同业务域使用相同的编程语言、微服务框架、测试框架和发布流程。
3. 按照多种方式分割交付模块：如按部门、领域、架构分层或最小价值单元交付。每一层的交付都保持向后兼容，从而最小化对上层业务的侵入。

3、最小化架构方案

  不论是分期交付，还是通过单一目标约束范围，都是最小化架构活动的例子。这个最小且必要原则，是提升交付成功率的最重要方法。 然而在实际项目中，我们常看到的是“好大喜功”，尤其在大厂中。有些负责人恨不得把项目铺开到整个企业，甚至为了扩大影响力故意放大工作半径，这是交付的大忌。

（四）、沉淀知识

  任何大型架构活动背后，都有巨大的时间成本、机会成本、商业资源和人力资源投入。从这个视角看，架构师必须具备区别于其他参与者的宏观视角。在架构活动中，架构师有必要通过有效的知识沉淀来保障思考与决策质量，也为企业未来的架构活动提供经验和方法论。

1. 沉淀完整和真实的过程记录，包括关键决策依据、风险评估过程、方案演进历程等。
2. 为企业注入逻辑思考，引导团队在面对类似问题时能做出更科学的决策。这不仅包括文档化的产出，还可以通过技术分享、代码注释、架构评审记录等形式，让经验在团队内流动。
3. 建立问题与解决方案的映射库，形成可复用的设计模式和最佳实践，从而提升整个组织的架构能力。