云智慧 10 年资深架构师带你了解:普通程序员向架构师成长必经之路
本文转录自:拥有 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》
写在最后
近年来,在 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/
部分大屏案例:
评论