二〇二四年整理档案室，我翻出一张 A1 图纸，卷起来用橡皮筋捆着。展开是二〇一四年画的车间系统架构图，手绘，用直尺和圆规画的框，线条有粗有细，左上角写着一行字："现行系统，二〇一四年三月"。
这张图画的是七个方块、十一条连线，还有六个手写的小注。当年它贴在机房门口，谁要动系统先看它。现在它什么也指导不了，但我还是把它裱了，挂在办公室。因为它记录了一件比技术更重要的事：我们当年怎么理解"系统"这个词。
这一篇用四个画面讲这张图。每个画面分画面、旁白、当时的判断三段。
一、画面一：图纸摊在会议室桌上
1.1 画面
图纸摊在会议室长桌上，四角用茶杯压住。七个方块，从右往左排：数据库服务器、报工客户端、条码打印机、仓库扫码枪、财务电脑、共享文件盘、磁带备份。连线是实线，箭头单向，从客户端指向服务器。
方块大小不一样。数据库那个框画得特别大，占了图纸四分之一，里面还写了三行小字：SQL 版本、实例名、磁盘阵列容量。其余六个框都是一样大小。
1.2 旁白
这张图有一个明显的特点：它以服务器为中心，所有东西围着它转。客户端是"连上去的"，打印机是"挂在服务器上的"，备份是"从服务器拷出来的"。
这在二〇一四年是对的。那时候车间只有二十几台电脑，一个机房，一台服务器，一套系统。架构图的作用是告诉维修的人：出问题先看哪里。
1.3 当时的判断
画图的人当时的判断是"系统就是这套软硬件"。所以图上没有业务流程，没有数据流向，没有岗位。七个框全是设备。
这个判断在当时很实用，因为它解决的是"坏了找谁"的问题。但它也决定了这张图的天花板：它没法回答"这个数从哪来"，因为数不在它的语言里。
二、画面二：图上的七个方块
2.1 画面
我把七个方块上的手写小注抄了下来：数据库旁边写着"每日二十三时全备"，扫码枪旁边写着"三号库两台，二号库一台"，共享盘旁边写着"图纸、工艺卡、检验标准"，财务电脑旁边写着"独立，不联外网"。
十一年过去，这几行小注里有三行已经失效。全备改成了增量加周备，扫码枪从三台变成十一台，财务那台早就联了内网。
2.2 旁白
图上没有一样东西叫"接口"。所有连线都表示"能连上"，不表示"传什么"。这是老架构图常见的省略，因为当年确实不需要说清：一套系统，一个库，客户端只是界面。
等到后面要加 MES、加看板、加移动端，问题就出来了。新来的人看着这张图，以为连线就是数据流，接上去才发现每个客户端的取数逻辑都不一样，有的直连库，有的走中间表，有的干脆是人工导。
2.3 当时的判断
当时判断"图是给运维看的，不是给开发看的"。这个判断省了事，也埋了坑。运维看图能修，开发看图不能建。
后来我们补了一张数据流图，画了十九个箭头，标明每个箭头的表名和频率。这张图没有裱起来，但它是这十年里被翻得很多的一张。
画这张图时踩过一个坑：十九个箭头里有三个指向同一张中间表，我按客户端分，画成了三条独立的线，结果口径对不上。后来改成按表归并，一张中间表只留一个入口，箭头减到十六个，反而把上游谁在写说清了。图不是越细越好，同一张表被画成几个入口，看的人会以为是几份数据。
三、画面三：十年里改过的四条线
3.1 画面
同一张图上，后来有人用红笔加过线。红笔的痕迹有四条：一条从扫码枪连到一个新增的中间表，一条从数据库连到一台新加的报表服务器，一条从共享盘连到一台文档服务器，还有一条从财务电脑连到税务端的报税客户端。
四条线的笔迹不一样，粗细也不一样，其中一条画歪了，穿过了"磁带备份"那个框。
3.2 旁白
四条线对应四次需求：扫码数据要单独汇总、报表不能压在业务库上、图纸要能被车间查到、报税要导数据。每次都是小改动，每次都是加一条线。
十年下来，这张图从"一套系统"变成了"七个方块加四条补丁"。补丁本身没错，错在没有一次改动之后重画整张图。图不更新，它就慢慢从工具变成了装饰。
3.3 当时的判断
每次加线的判断都是"先跑起来，回头再整理"。回头一直没来。这不是懒，是这类整理工作没有直接产出，永远排在需求后面。
我后来定了一条规矩：任何一次加线，必须同时改图，改完图才能上线。规矩定下来之后，图更新了，也顺带逼着人想清楚这条线到底连到哪。
四、画面四：今天重画这张图
4.1 画面
二〇二四年的新图是在电脑上画的，横向五层：接入层（扫码枪、工位机、手机）、应用层（报工、检验、设备、看板）、集成层（四个接口和两个定时任务）、数据层（业务库、报表库、文件存储）、保障层（备份、监控、账号）。
每一层里的框都标了责任人和更新日期。连线一律双向箭头，旁边标了频率和数据量。
4.2 旁白
新旧两张图放在一起，差别不在画得好不好，在"图回答什么问题"。旧图回答"坏了修哪里"，新图回答"这个数从哪来、经过谁、多久一次、谁负责"。
新图还多了保障层。旧图里备份只是一个框，挂在角落；新图里它是一层，和业务并列。这个变化是被一次事故逼出来的：二〇二一年有一次备份失败连续三周没人发现，等发现时已经无法回滚到出问题之前。
4.3 当时的判断
这次画图时的判断是"图要能被不熟悉系统的人读懂"。所以每个框都写了责任人，每条线都写了频率。
这个判断带来的副作用是图变得很啰嗦，A1 装不下，只能放在共享文档里。但它确实好用了：新来的运维靠它三天能接手日常，以前要三个月。
五、从图里读出的三件事
5.1 图会过期，接口不会
十年里，图上的方块换了三轮，服务器换了两台，客户端从台式机变成工位机又加了手机。但有几样东西一直没变：报工数据的字段、库存扣减的时点、工单和工序的对应关系。
这些不变的东西，才是架构的骨架。画图的时候如果只画设备，图会随着设备迭代很快过期；如果画清数据和规则，图能撑很久。
5.2 每加一条线，就多一个要维护的口径
四条红线，对应四个新口径。扫码汇总的口径和库存扣减的口径不一样，报表库的口径和业务库的口径不一样。每多一个口径，就多一处对不上的可能。
这也是我后来主张"接口要少而稳"的原因。不是不能加，是每加一个都要有人负责解释它和别人的差别。没人负责的接口，半年后一定变成争议源头。
5.3 边界：图上不画的东西
有些东西我们故意不画。具体的人名不画，画岗位；具体的服务器型号不画，画容量和用途；临时的取数脚本不画，那属于个人工具，不属于架构。
这条边界是为了让图稳定，也让看图的人知道哪些东西该去问人。图上一旦出现会频繁变的东西，它就会被迫频繁更新，更新跟不上就没人信，到后来整张图作废。
我见过反面的例子。有家企业把架构图画成了设备清单，主机型号、机柜位置、IP 段全标上，看着很专业。半年后换了两台服务器，图没人改，从此再没人打开过。不是图不好，是它记的东西太容易变。
常见问题
问：小厂只有一套系统，需要画架构图吗？
答：需要，但可以很简。一张纸上画清三件事就够：数据存在哪、谁往里写、谁从里读。这三件事说不清，后面加任何东西都会打架。我们那张旧图虽然只有七个方块，但它至少说清了数据存在哪。
问：架构图应该谁来画、谁维护？
答：画的人要同时懂业务和系统，通常是既做过实施又管过运维的那个人。维护不能靠自觉，得挂在变更流程上：改动上线前必须更新图，更新人签字。我们试过"每季度集中整理一次"，两次之后就没再执行。
问：老图还有没有必要留着？
答：留。它的价值不在指导现在，在解释过去。有一次查一个历史数据口径，谁也说不清二〇一五年的库存是怎么算的，翻出旧图和当年的表结构说明才弄明白。旧图是档案，不是工具。
问：图上标的频率和数据量，写不准怎么办？
答：写量级，不写精确值。一天几十条、一天几万条、一小时一次、一天一次，这种粒度就够判断风险。写"每分钟三千二百条"反而容易过期，过期之后整张图的可信度都受影响。