本文转录自：领有 10 余年架构师教训的高驰涛，在云智慧 AIOps 社区第 4 期 Meetup 上进行的《一般程序员向架构师进阶之路 》分享。

PPT 及回放地址：戳此获取材料

架构师都在干什么？

两个实例看架构师们的日常

实例一

困扰整个团队⼀个⽉的诡异事件

• 数据库中偶然会呈现反复的两次 / 多次重复数据
• 经营 / 运维在发飙，客户经理间断赔罪了 N 次
• 研发查看代码，没有发现异常
• 研发排查 log，⽣产零碎没有打 INFO，遂开启并察看
• ⼀周后的某天下午果然⼜呈现了⼏条不同客户的反复数据
• 研发排查该工夫前后 log，发现了反复数据写⼊的 log

• 架构师拿出零碎架构图进⾏标记

  • 反复 log 总是呈现在负载均衡器后的不同实例中

• 批改 Nginx 对反代超时的断定与实例超时断定雷同

  • 诡异事件不再发⽣

实例二

零碎稳固运⾏⼀段 工夫 后总要重启⼀次

• 为了应答该状况，运维复制了另外两套集群，三班倒的保障
• 研发排查 log 和源代码，有⼀堆显著异样，但不晓得哪个是起因
• 纠集上百位系统管理员进⾏会诊，⼀周未果，“不是我啊”

• 三名架构师

  • 通过 APM 探针，精确地失去了⽣产运⾏时的应⽤拓扑
  • 配合 CMDB，将运⾏时拓扑与零碎拓扑合并，发现内部 API
  • 配合根底监控数据，将运⾏时状态、log 与上述拓扑合并，失去指标体系

• 数据分析失去故障流传图

  • 打卡应⽤ -\> ⼈脸辨认 API -> MQ -> 接驳该 MQ 主题的其余零碎
• 将打卡应⽤使⽤的 MQ 独自部署，减少⼈脸辨认 API 的容错工夫及本地验证后缓存

实例一波及到的 研发工程师 有 40+ 位，实例二波及到的系统管理人员有上百位，而真正起到的关键作用的只有其中几名架构师和架构师的系统管理办法。

架构师的类别

业务架构、技术架构、零碎架构

解决方案架构、基础架构、软件架构

大数据架构、分布式架构、微服务架构、云原生架构

架构师的角色定位

从大的层面讲，架构师的角色是：

• 需要剖析和业务建模的 负责⼈
• 零碎技术演进策略的 制定者
• 关键问题攻关的 组织者 和贡献者
• 组织内核⼼技术的 引路⼈ 和布道者
• 零碎品质和效率的 捍卫者
• ⾼潜技术⼈才的 伯乐 和导师

粗疏的拆分一下：

• 负责软件系统的零碎需要剖析及业务建模

  • 负责零碎需要剖析，辨认核⼼业务需要与⾮性能需要，并实现技术⽅案转换
  • 形象零碎需要剖析论断，形象失去业务建模
  • 制订匹配短期与中⻓期的软件系统架构演进策略

• 负责技术⽅案中的架构设计、组件选型及预研、关键问题攻关

  • 依据产品及项⽬中⻓期策略，制订具备前瞻性的零碎架构设计
  • 依据技术演进⽅向，制订正当的组件选型打算并对其进⾏充沛的技术预研
  • 负责解决架构中要害组件、关键技术问题的攻关问题

• 负责软件系统的公共组件、核⼼模块研发⼯作

  • 负责公共组件的架构和开发设计正当与⾼品质的编码实现
  • 负责核⼼模块的架构和开发设计正当与⾼品质的编码实现
  • 制订中⻓期的公共组件与核⼼模块的技术布局，并推动执⾏落地

• 主导开发过程中技术评审、难点攻关，主导 Code Review，管制研发品质

  • 主导开发过程中各阶段成绩的技术评审
  • 监控并主导开发过程中技术难点、技术⻛险点的发现与解决
  • 组织并主导 Code Review，一直晋升代码品质

• 负责团队中⾼潜技术⼈才的辨认和造就

  • 负责输入产品及项⽬的技术成绩、相干常识和教训
  • 负责组织团队中技术⼈才的常识分享
  • 负责辨认团队中⾼潜技术⼈才，制订成⻓打算、跟踪和改良

• 组织促成技术提高与翻新、晋升开发执⾏效率

  • 发现并改良有利于产品与团队技术倒退的翻新点
  • 引⼊或发明新型⼯具或⽅法，一直晋升开发过程执⾏效率

架构师的保持

最值的保持和鼓吹的品质：高效

高效的辨认、高效的产出、疾速的试错

除此意外，还须要具备以下 重要的品质：

架构师是如何成熟的？

这部分不解说技术上特地粗疏的内容，技术上的内容网上都能够检索的到，这部分讲一些网上没有的、且架构师必须要具备的软、硬实力。

成长路上的那些硬通货

技术的广与深

• 计算机、软工等方面的内容（这里能够自行检索）

业务建模

• 形象、分层、分治、演进
• 资源、零碎、子系统、关联、规定、能力

遵守 工程思维

工程思维：指永远以 资源无限 、条件有余为前提，进行 零碎的 、 极限的 、 全面的 思考，去实现“事实世界 ”的指标。

• 资源无限：人力资源、工夫资源、技术资源、服务资源等。
• 事实世界：生存中的、工作中的，具体的、要达成的指标。
• 零碎的思考：在没有构造的状况下“预感”构造的能力。
• 极限的思考：熟练地在有束缚的条件下进行设计思考。
• 全面的思考：三思而行后对解决方案和备选计划的决断能力、对技术和业务的衡量能力。

工程思维不是利用迷信进行发现、利用艺术进行传感，而是利用 构造、束缚和取舍 进行实现。

刻意训练的实力

• 英文浏览、形象形象
• 表白演讲、合作 协商
• 自驱 冲破
• 业务品质、麻利 精益、前怕狼; 后怕虎
• 零碎衡量、主观 批评、可控翻新

一般工程师该如何进阶架构师？

避坑指南

“受害者思维”

不能有“因为 … 所以 …”的受害者思维

例：因为 明天的数据量是昨天的 3 倍，所以 没有稳固的运行。

因为 … 所以 …→即时 … 也要 … 通过 …

例：即便 明天的数据量是昨天的 3 倍，也要 xx 的 通过xxx 计划保持稳定的运行。

幸存者偏差

• 不要置信本人的眼睛
• 零碎、辩证的思考
• 怯懦犯错 拥抱变动

怎么开始更好

确定业务指标

弄清楚你的业务指标，这比所有都要更重要。

箭头右边是在做的事件，左边是对应的业务指标。

• 我在改 Bug -> 我在让⽤户登录时更稳固
• 我在写⽤户治理 API -> 我在为第三⽅提供服务能⼒
• 我在优化数据处理性能达到以后的 3 倍 -> 我正在让零碎在施展更⾼的数据吞吐能⼒的同时降低成本
• 我的⼩组正在全⼒保障 v1.2.0 的版本按期交付 -> 有 5 个⼤客户，和 300 个在线客户正在苦楚中煎熬的期待
• 我和我的⼩组要在这个迭代中解决数据导出的需要 -\> ⽤户想要的是不是数据某个纬度下的历史快照？

正确认识团队

全面理解团队中每个人的能力状况，面对不一样的团队成员，应用不一样的合作形式，高效协同。

理清事实

凡事都有坐标系

• 轻重 / 缓急
• 老本 / 价值
• 能力 / 志愿
• 指标 / 现状

举例：

对于处于不同地位的事件分清轻重缓急，对不同地位的事件正当分配资源和人力等等。

5W1H思考法：

正确思考、先放筐再放苹果

5W1H ：

-What：是什么

-Why：

• 为什么会产生
• 为什么要解决
• 为什么是以后的计划

-Where：

产生点、影响点

-When：产生工夫、预期工夫、打算工夫

-Who：影响了谁、谁来解决、谁来执行

-How：具体步骤

确定门路并践行变动

• 放弃精力充沛
• 不断更新你手中的工具
• 多做、多说
• 在游泳中学会游泳
• 利他

书籍举荐

《高效能人士的七个习惯》

《稀缺》

《12 堂思维课》

《Getting Real》

最新 Meetup 预报

写在最初

近年来，在 AIOps 畛域疾速倒退的背景下，IT 工具、平台能力、解决方案、AI 场景及可用数据集的迫切需要在各行业爆发。基于此，云智慧在 2021 年 8 月公布了 AIOps 社区，旨在树起一面开源旗号，为各行业客户、用户、研究者和开发者们构建沉闷的用户及开发者社区，独特奉献及解决行业难题、促成该畛域技术倒退。

社区先后 开源 了数据可视化编排平台 -FlyFish、运维治理平台 OMP 、云服务治理平台 - 摩尔平台、 Hours 算法等产品。

可视化编排平台 -FlyFish：

我的项目介绍：https://www.cloudwise.ai/flyFish.html

Github 地址：https://github.com/CloudWise-OpenSource/FlyFish

Gitee 地址：https://gitee.com/CloudWise/fly-fish

行业案例：https://www.bilibili.com/video/BV1z44y1n77Y/

局部大屏案例：

您能够增加小助手（xiaoyuerwie）备注：飞鱼。退出开发者交换群，可与业内大咖进行 1V1 交换！

也可通过小助手获取云智慧 AIOps 资讯，理解 FlyFish 最新进展！