架构的起始——黄金链路

2023年底，公司有一个部门的对客系统出现了十分严重的故障，损失严重。当日一系列只听过名字，没见过真人的大佬都出现在机房跟进问题排查的进度。事后，具体的原因仍未完全定位。也因这场故障，开始公司级别的重视架构的重要性。

2024年，架构提升就摆到了第一位。“黄金链路”应运而生，其指的是一系列涉及客户的重要交易链路的梳理。对于一个几百套系统在生产运行多年的公司来说，想要端到端的完成梳理，是一份巨大的工程。有幸参与到这份工作内容中，也是艰辛伴随着一些成就感。

在正式将组织架构调整到架构运维组后，第一份差事就是负责梳理一个未接触过的系统的黄金链路，编写汇报材料。用时1个多月，120多页的PPT，才算完成一份较为完善的材料进行汇报。在此记录一下这份材料编写过程的一些收获。

第一是如何进行工作的安排，由中心架构师牵头组织会议，架构运维组全体参加，由系统原负责人进行黄金链路的描述。描述的顺序是业务进行的顺序，讲述使用到的微服务、中间件、外部系统，系统的风险点、监控点，会议中形成泳道图。并在泳道图的每个节点中注释其涉及的数据库表、redis使用的key、es的索引、外部调用的接口等等。

第二是汇报的视角，主要分为系统视角与用户视角。系统视角针对泳道图中每一个节点、远程调用进行分析其可能的故障点、应急方案、可优化的方案。从用户的视角，又从对用户的影响分为3种类型，分别是系统报错、内容差错、体验差。并站在用户视角的反馈，梳理第一时间的应急预案是什么，主打三板斧，第一时间停止继续损失，再考虑精确排查问题的节点可能性。

第三是汇报的思路，这是一块软技能，对于一张涉及16个微服务，70+节点，30+系统间调用的泳道图，如何向上汇报，让领导能够清晰了解该链路的重要性、当前业务主要的经过、存在的风险点、后续优化的方案、系统应急的方案完善性。首先对该黄金链路的主要业务进行介绍，通过哪些系统对哪些客户进行了服务，服务的量有多大，体现出该黄金链路的价值。其次展示该链路涉及的0层图、1层图（不严格），以及生产部署的物理视图。接着从概要进入详细的泳道图全览，并介绍泳道图中节点的编码方式。然后按照节点重要性进行分类排序、索引，之后再一个个节点进行详细分析，描述其功能，系统视角分类、用户视角分类，故障场景以及对应的应急方案、是否可添加监控、优化方案等等。接着切换为用户视角再总结不同的用户反馈的处理应急预案。最后再附上链路中涉及的表、接口、关键代码的附件。

写这样的材料对我来说，真的挺折磨，因为这是公司第一次做这样的事情，汇报材料的模板，格式，都是做了不知道多少次的反复修改，领导每天都能给出一些指导，好在的确是收获不少。之后，我也直接参与了该系统几次生产问题的排查，例如CPU使用率高等问题。发现经过黄金链路的“折磨”后，对链路上的业务已经大致了解了，在排查过程中，真的可以指着泳道图，问对应的同事，这里的表现好像不大对，是不是出现了什么对应的问题。

接下来有时间的话，我还想总结一下最近在做的应急演练。思考一下应急演练在测试环境的模拟，系统间问题的编排。不过也不是什么高大上的东西，可能连灰度都不涉及。后一阶段还要在生产上演练~