架构师的职责、核心能力、能力修炼手册
孔庆龙，一线架构师，多年金融架构经验，具备 SOA 服务化、服务治理、系统优化、 分布式系统项目经验。目前关注于互联网金融技术架构设计、分布式架构、微服务架构、 DevOps 实践、大数据等领域。
在多年的架构工作中，我经常反问自己什么才是自己应该做的事，如何才能做好架构工作。本章意在从职责、核心能力、能力修炼等方面总结自己的经验和对架构工作的看法。做架构师要仰望星空、匍匐前行。仰望的是远景和方向，匍匐是要对业务和具体的研发有掌控，避免成为空中楼阁一般的“PPT 架构师”。
1
架构师承担的职责
在记录片《黑猩猩的守护者》中珍妮·古道尔博士说过:“唯有了解，才会开心，唯有开心，才会采取行动，唯有行动，生命才有希望。”将这句话套用到架构师身上同样适用:
“唯有了解，才会关心，唯有关心，才会采取行动，唯有行动，才会有结果。”
技术管理多为结果导向的，作为架构师首先要知道自己承担什么样的角色和职责，之后才能构建自己的知识体系用于辅助决策和指导实施。不同的企业对架构师工作的要求不同，有些企业没有设置架构师岗位，相关工作由需求或开发人员承担。按照架构师工作内容的侧重点不同， 架构师可以分为业务架构师(进行系统分析、建模以及业务架构设计)、技术专项领域架构 师(业务领域专家、业务顾问，可以洞察行业发展)、技术架构师(技术专家，从事技术架 构设计)、企业总体架构师(从事企业总体架构的规划和设计)、项目层面的技术架构师(Java 架构师、.NET 架构师)、方案架构师等。
2
架构师的核心能力
2.1
经验
架构师的经验很重要，若没有丰富的实战经验，在架构设计或指导开发时就很难预见哪些地方可能出问题。因为只有经历过才能更深入地理解痛点以及繁华表面的背后所需要 填的“坑”。但是，比经验更重要的是要具备深入思考的能力，只有时常对从事的专题领域进行经验总结，才能跳出本位看全局，不断提升自己的判断和分析能力。
在做分析或经验总结时，一般采用结构化思维方法:
首先梳理目标，理清目标与现在或将来发展的关系。
其次做现状分析，知道有什么、缺什么、现状与目标的差距，以及眼下首要的任务是什么。
接下来是路线与措施分析，并制定可以保证有效执行的方案。
最后是下定决心以较高的执行力来实践。下面以传统企业几年前的服务整理为例，分析企业机构服务治理的过程。
目标:改善目前无序的现状，建立服务及交易标准，构建符合企业发展需要的 SOA 服务平台，为灵活多变的业务提供支撑。
现状:企业创立多年，已经积累了大大小小几百个系统，因为建设之初上线时间要求得比较紧，所以大部分套件是采购的成熟的、基于垂直架构体系的商业套件，长期下来，系统如烟囱一样一个一个建立。为了解决信息孤岛，采用了系统集成方案， 但是由于在执行过程中接口缺少统一的管理，所以导致系统边界、模块边界模糊不 清。解决生产问题的过程中，需要相关或无关的人员一起参与进来才能定位问题， 问题排查慢，且需要耗费大量人力。因此当前最重要的是，先建立服务及交易标准， 规范新建系统对接，再制定计划指导历史系统改造。
路线:如何执行是需要好好规划的，具体的规划步骤可以是“找出差距——差距图， 明确整改措施——整改图，制定时间表——行动路线图”。
一般来说，传统企业在开始考虑做服务治理时，已经积累了大量接口。接口改造和测试的耗费巨大而且周期长，其中部分系统可能是外包出去的，难以控制。综合企业环境和 团队人员等因素，服务治理分阶段执行是比较合适的。
第一阶段，通过统一的服务总线和 监控平台实现交易的监控，这就需要选择比较成熟的产品和经验丰富的实施商(根据以往 经验，有时候有经验的实施商比产品重要)，制定交易线服务接入接出规范，并进行服务接入;
第二阶段，深入服务治理，将一些基础服务下沉为平台，将流程服务放入 BPM(Business Process Management)，提高可管理性，为服务自治和预警提供有效手段。图 5.1 简要描述 了服务治理需要考虑的各个方面。
2.2
沟通
架构师的沟通能力也很重要。在执行决策前，先听取相关干系人的诉求并进行分析， 对相关问题进行沟通协调，获得其支持并能够一起合作，这要比单纯的编程能力更为重要。架构师还要具备一定的商业头脑，只有这样，才能很好地理解企业战略目标，制定能够帮助企业赢得市场的技术路线，使技术路线与企业战略相匹配。
2.3
快速学习
架构师的知识面很广，需要快速地学习知识、快速地掌握并运用，经常将知识沉淀为经验并分享给伙伴，并督导团队执行和创新。关于如何构建自己的知识体系，有如下几点建议。
保持好奇心和阅读习惯，坚持做笔记。
深入思考问题背后的根源，学习并掌握方法论。
经常与人交流，查看牛人博客。
经常总结并分类管理与分享。
表 5.1 是几年前在没有使用 APM 类监控工具时，人工排查问题的排查列表(该表是一个 Web 应用对客户反馈生产问题的分析过程，当不知道问题出在哪里时，可以利用这个表对交易线上的每一个点进行确认，不能确认没问题的点就是下一步需要重点分析的地方， 经过多轮筛选后一般可以定位到真正的问题)。表中的第五步“知识积累”部分用来对常见问题进行分类总结并保存到知识库，如果团队中有新人加入可以根据知识库中的材料了解 前人的经验。
2.4
解决问题的能力
架构师的好奇心比较强，喜欢研究问题(很多时候这也是架构师的职责)。然而做技术容易先入为主，会觉得技术的重要程度排在第一位。比如，你所在的项目组接到一个新的接口开发需求，作为架构师你如何处理?建议以如下的思维方式来考虑问题。
要不要做(是否与长期 IT 规划相匹配)。
应该由谁来做(涉及系统边界问题)。
如何做(涉及技术栈选择、方案设计等)。
什么时候做合适(变更的关联分析)。
如果做了，那么对将来有什么影响(跳出当前局限，站在未来的角度考虑)。
作为技术管理者，架构师应该在不同的场景内跳入、逃出，着眼大格局，从细节入手，并时时总结，尽量规避先入为主的执行思维(比如，首先考虑使用什么协议及接口规范、 如何执行、要多久才能完成、如何规避风险等。并不是说这些不重要，而是不仅限于这些)。
3
架构能力的修炼
架构能力的修炼，最好做到七多:
多想(“学而不思则罔”，运用计算机思维，深入思考问题背后的根源和关联问题的渊源)。
多看(空杯心态，“他山之石，可以攻玉”，避免重复造轮子)。
多读(“思而不学则殆”，读书而有益，多读而博知)。
多写(“学而时习之”，构建知识体系)。
多练(“绝知此事要躬行”，不自欺、不欺人、不被欺)。
多问(不耻下问，不怕傻问题，对问题及时反思，成竹于胸，多视角看待事物)。
多实践(实践出真知，要有工匠精神，“如切如磋，如琢如磨”)。
架构师，特别是一线架构师，经常会作为技术专家来参与问题的解决，下面是以往解决问题时的经验总结。
问题描述。准确了解问题是什么，基于具体事实进行陈述，尽量详细不笼统，并以分析问题为重点进行问题信息收集(而非一些过往经验的论断)。
分析问题(根据问题树排查)。分析问题时要简单有效、逻辑清晰，如果暂时无法
确认问题，最好能给出确认问题的截止时间。
问题跟踪分析，去掉非关键问题(通过使用漏斗法去掉非关键问题)。使用 80/20 的思考方式，推敲问题现象与假设间的逻辑关系，尽量做到全面考虑、避免遗漏。制订详细的工作计划，发挥团队协作的作用，让交易线相关人员尽可能参与其中(这 样可能会加快问题确认的速度)。如果问题复杂，需要团队协同，则组织者要做好 工作规划。
进行关键分析。以数据为基础(避免以经验先入为主);争取得到专家的支持(充 分利用他人经验);使用 80/20 的思考方式;经常回顾问题的目标以及论证的逻辑关 系(奥卡姆剃刀定律:如无必要，勿增实体);不拘泥于现状，寻求突破性观点。
综合调查结果，并构建论证。整合各种分析内容，串联成合乎逻辑又具有说服力的故事；关心汇报对象的关注点，做到重点突出，条理清晰；描述问题时要为关键决策者提供必要依据；根据汇报对象的不同，采用不同的方式描述问题。
问题处理。注意紧急解决问题和完美解决问题的权衡，分析问题解决过程可能带来的影响并制定对策。
问题解决确认。与问题提出者确认，与问题周边影响者确认，根据监控系统数据进 行确认。
知识积累。将问题故事记录成文件或放入知识库，并分享解决问题的过程和经验。
4
总结
本章就架构师的核心能力提出了一些看法，希望能抛砖引玉，引导读者对自身工作的范围、能力边界以及精进技艺进行思考，在以后的实践中不断摸索和总结，形成自己的思考和做事方法。
最后，也请读者一起思考以下问题：如何才能拥有架构师思维和计算机工程思维，在工作中如何锻炼自己的术并坚守自己认为正确的道，做到道与术的平衡?
本文节选自中生代技术社区系列图书之《架构宝典》
5
推荐阅读
资深架构专家聊架构之道：灵活、稳定、高可用15点精要
2021-08-05
山哥新作：架构师必备技能之业务分析
2021-07-26
资深架构师十几年的架构干货经验总结分享！
2021-07-19
什么是业务，什么是业务架构？
2021-07-15
资深架构专家聊架构之道：规划、简化和演化（续）
2021-07-12
从架构演进谈 DDD 兴起的原因以及与微服务的关系
2021-06-30
