技术判断力养成：从事故中提炼可复用的“大道”原则

凌晨两点半的发布失败让我第一次意识到问题的根子不在我看了多少文档、更新过多少工具版本而在于我从来没有把自己的判断体系整理成一条条能复用的原则。那以后我开始维护一类专门的笔记标题就叫【大道】。大道不是什么玄学也不是所谓的人生哲理它是我在真实项目和事故里提炼出来的底层规则跨场景、可迁移、经得起反复推翻。这篇内容会展示我的三条核心大道和提炼过程也会把维护这类笔记的方法讲透。适合所有靠判断力吃饭的人参考技术研发、产品经理、团队管理者都能从中找到自己值得记录的那几行。1. 什么内容配得上大道两个字信息、方法、原则三层结构1.1 多数人记笔记只记到第二层开始维护大道笔记之前我也和大部分人一样把笔记当成信息仓库。项目里用到的接口文档、某个工具的最新版本号、一次故障的处理步骤、开会的模板全都往笔记里堆。当时感觉记了就有安全感后来才发现这是一场自我欺骗信息层面的笔记寿命极其短暂版本号一过期就废接口一变就再也想不起来方法层面的情况稍好一点至少能把一个流程沉淀下来但换一个团队、换一套流程原来的方法马上就变形。真正能穿越具体业务和具体工具存活下来的是原则层。我把日常接触的知识分成三层。信息层回答是什么。比如系统端口是8080某个环境的账号归属哪个组某款中间件的版本支持什么特性。信息必须准确、快速、低成本地获取所以它最应该放到工具里而不是脑子里。方法层回答怎么做。比如一次标准的上线流程、一套故障排查步骤、一个商务谈判的推进模板。方法具有场景性换一个流程就要微调。原则层回答为什么这么做是对的。它不依赖具体工具、不依赖具体部门、不依赖当时那台机器它描述的是某种长期成立的因果规律。比如做自动化的同时必须定义一个哨兵任务来验证自动化本身还活着这句话在数据库运维、测试平台、流水线调度里成立在内容生产的自动化审核里同样成立。普通笔记的致命问题是大量时间花在第一层和第二层而把第三层忽略了。信息和方法用完就忘看似努力实则是在做知识的搬运工而不是在做判断的建设者。我的大道笔记从体系上把所有第三层知识单独收容并且用一套机制持续打磨。1.2 筛选大道的四条标准既然笔记的名称是大道就不能什么原则都收。我给自己定过四条硬性标准拿不准的时候就用这四条来卡。第一条跨场景。一条大道必须在至少两个不同领域里都验证过。如果一条原则只在数据库领域成立在接口设计里不成立那它可能是一条方法不是大道。比如复杂的东西一定会在最意外的组合点出问题这个判断我在数据库双主同步、前端构建缓存、跨团队流程协作里都反复应验它才能进笔记。第二条反直觉。大道最好能让人看完先愣了一下然后拍大腿。完全理所当然的内容不值得占笔记的位置。比如改动越小的发布越需要谨慎测试这已经是常识不用记。但在新代码里增加一个模块之前先想清楚怎么删除它这一条明显反直觉一旦想通受益很久。第三条可证伪。每一条大道都必须能写明什么情况下它不成立不然它就会变成正确的废话。能画出边界的原则才是真正消化过的原则没有边界的大道要么是信仰要么是口号。第四条能转化为动作。大道不是放在收藏夹里自我感动用的读完必须能让人在下一个周一作出不同的选择。如果一条原则写完之后你都不知道明天该改变什么说明它还不够具体需要继续压缩。这四条标准设置以后我的笔记数量骤然下降从一个月记几十条变成一年只新增三五条。数量变少质量反而上来每次复盘能调取的弹药都是真正有效的。1.3 工作笔记和大道笔记的边界我用一个对比来帮助团队理解这两类笔记的关系普通笔记记录的是事件本身大道笔记记录的是事件的决策模型普通笔记生命周期以项目为界大道笔记生命周期是长期演进普通笔记使用方式是查一下当时怎么做的大道笔记使用方式是现在这个场景该遵循什么普通笔记增长方式是越记越多大道笔记增长方式是定期淘汰、合并、重写。边界清楚了才不会把大道笔记写成另外一个收藏夹。大道笔记的目标不是积累资料而是训练出一套判断系统。2. 从两起事故里提炼出第一条大道的完整过程讲方法论容易抽象我拿自己真正从事故里提炼第一条大道的过程来讲。这条大道后来取代了当时团队里一整套复杂流程也是我整个笔记体系的起点。2.1 第一次事故我为了解决故障反而制造了更大的故障当时负责一个内部系统业务量起来之后内存曲线一路缓慢上涨。按理说第一步应该是做线程和堆栈分析但当时现场压力很大大家为了快速止血先上了缓存清理脚本。缓存脚本跑了一晚上内存确实降了一点可是某些热点数据被清掉后触发大量回源数据库压力反而翻倍。于是团队又加了数据库扩容扩容要改连接配置改配置要发布新版本发布后在验证环节发现一个权限组的配置格式不符合预期又修了一轮。到第二天早上系统彻底不能用了登录都进不去。复盘的时候团队成员提了一堆改进项加内存监控、加缓存命中率看板、加压缩归档、扩连接池、做发布预检。每一条单独看都没问题但我越听越难受这等于在原来的故障上叠加了一个更复杂的机器。后来我把整个时间线拉出来发现真正致命的不是最初的内存上涨而是我们为处理它而引入的第二个、第三个、第四个变数。每个变数看似都在解决问题其实都在增加系统的连接面。2.2 把事故转化成原则的三步法从那次事故里我没急着更新监控配置而是把整个过程拆成了固定步骤之后每一次复盘都用这套步骤来沉淀原则。第一步还原因果链。把所有事件按时间写到白板上标出每个节点到底是我们主动做的变更还是系统自发行为。这一步的关键是要区分故障本身和我们改出来的故障。我当时只用一个简单维度来分系统自身有没有主动产生这个动作没有就说明这个节点是我们自己塞进去的变数。第二步做一次什么都不做的推演。问自己如果保持原状系统最坏会怎样很多时候答案不是立刻全挂而是性能变差、响应变慢甚至下个迭代还能正常发布。而我们已经采取的行动不但没有消灭风险还引入了新的不可预测性。这个推演很反常识因为人在故障现场会条件反射地认为必须做点什么可绝大多数时候少动比多动更能保住系统存量。第三步压缩成一句话。原则不允许写超过一句话不允许出现具体技术名不允许出现部门、人名和系统代号。我们当时压缩出来的是为故障而引入的修复其复杂度不得高于故障本身。写完之后我发现这句话放在当时那座系统的场景里亮了缓存清理脚本的复杂度确实低于内存问题的复杂度但后来扩容、配置改动、发布验证这一连串动作的复杂度已经远超原故障。把一个看似合理的经验压成这句话才算真正变成了可迁移的大道。2.3 用反例检验给大道收边原则写出来只是初稿。写完这句话后我立刻开始找反例确认它到底在什么情况下不成立。很快我就找到了边界如果故障本身极简单比如就是一个配置字段写错那么修复动作天然也很简单复杂度低于故障这条等式会退化成琐碎的判断价值不大。更关键的反例是当原故障会引发数据永久损坏时宁可采取复杂度更高的动作也要立刻止损此时修复复杂度要低于故障复杂度根本不适用。这个反例帮我给大道加了边界备注——它适用于性能退化、瞬时抖动、慢跌异常这类可容忍场景不适用于数据损坏和资损场景。这一步极其重要不做反例检验的大道只能叫感悟。有了边界它在下一个项目里才敢被真正用来做决策。3. 大道一简化优先法则复杂系统一定会在最意外的地方失效3.1 为什么复杂度会定向找上你这条大道现在写在我的笔记第一行所有系统都会在最意外的地方失效所以面对任何修复和优化先想如何减少连接面。我对复杂的判断标准不是代码行数不是模块数量而是连接面的数量。一个系统内部A调用BB依赖CC又回写A这叫连成网。网越大故障的传播路径越多但更要命的是这些路径不可能全被测试覆盖。每个连接点都是一个潜在失效点就像一栋楼的消防通道平时谁都不会多看一眼火灾发生时它才暴露所有问题。复杂度平时看起来只是不够优雅但在故障场景下它直接决定你定位根因要花二十分钟还是四个小时。3.2 简化不是砍功能是砍连接面很多人听简化就以为是要砍需求、砍功能结果砍完发现业务不开心系统也没有更稳定于是觉得这条大道是空话。问题在于他们简化错了对象。功能是一个明确的产品交付砍掉它损失的是业务价值连接面是技术架构和流程里的隐性耦合砍掉它损失的是冗余收益的是稳定性。举个例子。我们当时要做一个策略配置的A/B开关产品和研发开了三次会定出来六个配置字段。实施之前我用这条大道重新过了一遍发现这六个字段里四个字段都是为了满足以后可能的灵活扩展不是给用户解决当下问题的。于是我们把配置砍到两个字段那四个需求一律不做改为在现有策略上直接切换版本。结果交付周期从两个迭代缩到半个迭代上线一个月没有任何回退。这个例子里的简化砍的正是各模块之间的链接和条件判断而不是砍用户可见的核心功能。我自己给团队立了一个规矩每次要新增依赖或者连接时必须连续回答三个问题。这个依赖直接服务于用户可感知的价值吗能不能用现有能力组合出来如果一个月后要删掉能否干净利落地删掉三个问题任一答不上来就推迟。单次推迟会显得保守长期坚持下来系统复杂度膨胀的速度明显被压住了。3.3 这条大道的边界条件说明也说说它的边界。这条大道主要针对偶然复杂度就是那些因为偷懒、过度设计、历史包袱撒到系统里的复杂度它不针对结构性复杂度。正在快速发展的业务天然需要更多连接那是为了成事必须留的存在不能一刀切地砍。另外如果你面对的是一次性任务比如写一次性迁移脚本这条大道就让位给越简单越快交付越好因为一次性任务没有长期连接面不值得为它做大量设计。好原则不是普适真理而是有明确射程的决策工具。4. 大道二约束产生自由度限制才是高质量产出的前提4.1 没有限制的团队反而交不出东西第二条大道来自一次让我印象深刻的对比。当时两个小组同时做内部工具一个组资源充足时间也宽裕另一个组被明确规定了交付时间、功能范围和必须遵守的技术边界。结果是资源充足的组花了三个月交出来一个带了许多以后可能用得上功能的大平台没人愿意用维护成本巨大被限制的小组在六周内交付了一个简单趁手的工具上线即被采用。我后来回看这次对比发现关键差别恰好是最开始看起来吃亏的限制二字。没有限制的组面临极高的选择成本每个功能要不要做、边界在哪里、技术路线怎么选都要反复评审讨论越多内耗越大。有了限制之后团队的选择空间被压缩到一条清晰的走廊所有人在走廊里可以全速跑而不用在草原上决定往哪儿走。4.2 有效约束的四个特征从那次观察开始我开始刻意收集哪些约束是有效的。最后总结出四个特征第一明确说出不要做什么而不是只列要做什么第二必须有一个可量化的上限比如最多三个接口而不是越少越好第三约束内仍然保留实现自由团队在规则之内可以任意发挥第四约束本身可以被修改但修改必须走明确的流程不能悄悄松动。这四条每一条都能对应到一个反面教材。只列要做什么的约束等于没有约束因为人总会倾向于多做一些没有可量化上限的约束会被解释得越来越宽然后失效约束内没有自由会让团队失去主人翁意识变成应付而允许悄悄松动的约束是最危险的一种它会训练所有人习惯打破边界。4.3 工程里最能落地的三个约束实践我长期在团队里推三条约束实践效果都很稳定。第一每个模块设置接口数量上限。超过上限不允许再加接口必须回头重新设计模块边界。接口是系统最贵的连接面限制接口数量就是限制失控扩展。第二新功能进入计划之前先写退出条件和回滚条件。很多需求讨论停不下来是因为没有人定义过失败的边界一旦写下上线两周后某指标没有提升就回滚并关闭功能争论很快收敛。第三代码评审时把删除代码量纳入评审视野。如果一次评审只看到新增几百行代码却没人提删了什么说明这次改动很可能只是在叠加复杂度。我见过最好的评审记录是加了几十行删了三百行那个模块后来的故障率一直很低。4.4 写方案文档前先写绝不做什么这个习惯是我个人认为性价比最高的一个。每次写方案第一页先写非目标列三到五条本版本绝不做的事。别小看这一页它能逼着团队在一开始就把真正的目标想清楚。很多项目做歪不是能力问题而是所有人各说各话最后把周边功能做了个遍核心问题反而搁置。非目标写明白之后后续的讨论只要偏离方向一句话就能拉回来这件事在我们非目标清单里吗后来我把这个习惯带到了个人时间管理里。每一季度的目标下面会专门写一两条这季度不主动启动的事效率提升非常明显。这也验证了这条大道可迁移出了工作场景。5. 大道三一切系统最终依赖人的判断力自动化解决不了责任真空5.1 自动化链上最脆弱的环节往往不是机器第三条大道的来源不是一次大事而是一次特别不起眼的漏检。当时的发布流程已经完全自动化流水线跑了大半年没出过事团队都对它充满信任。直到有一次线上权限配置被改错自动化测试却全部绿灯因为测试账号用的权限很大把配置错误完全掩盖了。真正发现问题的是凌晨一个值班同学习惯性地看了一眼日志。这次漏检让我第一次承认一个事实自动化能消除重复劳动但消除不了验证逻辑是否合理这个动作。当验证条件本身被写错或者没有覆盖到实际场景时自动化非但不会发现故障还会把故障快速扩散到整张网。我当时的体会是自动化工具链里最脆弱的环节不是机器而是那个默认它已经检查过了的人。5.2 责任真空每个人都默认别人会想后来我开始用一个词来称呼这类问题责任真空。责任真空发生在一个没人自己主动认领长期责任的环节所有人都默认这块应该有人在看。权限例外、数据边界、接口归属、文档一致性这些都是责任真空的重灾区。流程设计得越完善越容易制造一种流程会搞定一切的错觉目标压得越细越容易让每个人都只盯着自己那一小块没人抬头看全局。责任真空非常狡猾它平时看不到因为它是负责人的但它没有对应当前版本的告警规则。它只在两种时刻爆发一是自动化检查恰好有盲区时二是在线所有人都无法凭记忆回答这是谁负责的时。5.3 给系统留出人工裁决点要能强制输出判断我现在的做法不是反对自动化而是在自动化链条上专门留出人工裁决点。所谓裁决点不是让人在界面点一个确认按钮那只是形式上的确认点的人可能根本没看。真正有效的人工裁决点必须强制输出判断比如发布单上的本次发布与上次发布的差异摘要必须由操作人手动填写。系统可以自动生成差异列表但人工要在上面批注这几处差异我检查过风险点是……。这样做的原因很简单打字的过程一定会逼着大脑进入思考状态。按钮可以盲点摘要没法瞎编一旦人要写出一句话他就必须真的去看差异。我见过很多团队为了安全加了四个审批环节结果每个审批人都出于信任秒过这就是人工裁决点设置失败的典型。人工裁决不是流程越长越好而是要在最关键的那一步设置一个必须输出判断的障碍物。5.4 事故复盘里固定不变的三个人为问题为了让这条大道真正落地我把复盘模板里的固定问题调整为三个。第一个系统在哪个环节默认了某个人会做检查这个问题用来定位责任真空找出来的那个环节要么补上所有者要么把检查逻辑自动化并持续验证。第二个我们如何证明自动化工具的检查本身是有效的针对自动测试、监控规则、发布校验都要有对应的哨兵比如故意制造一个异常看检查逻辑能不能发现。第三个如果核心负责人突然不在场系统能不能被完整接管这看似是值班问题其实也是责任真空问题它检验的是知识集中度。这三个问题每次复盘都问一遍比堆砌几十个告警规则有用得多。每次都能问出一些平时完全想不到的东西这也是我把这条大道长期放在前三名的原因。6. 大道笔记的维护机制定期复盘、证伪、重写6.1 每季度给大道做一次反例大清查讲完内容再说维护。我见过很多人一开始也兴致勃勃建了体系类似的笔记没过几个月就废弃了原因是笔记刚写完很激动一放两三个月就忘了回头再看还心虚。我的应对是每季度进行一次反例大清查把所有大道列表逐条拿出来专心找反例。找反例不是为了证明自己错了而是用反例来修剪原则的边界。一条大道如果连续好几个季度都找不到反例我不会更相信它反而会怀疑自己是不是在自我重复。真正活跃的大道应该不断被新场景挑战每挑战一次备注区就多一行边界说明使用起来会更安全。还在我笔记里的那条简化优先法则我有一次在评估一个大数据平台改造时找到了很强的反例后来把备注改成了该条不适用于需要数据最终一致的强一致性场景这句话让后来借阅笔记的同事避免了一次误判。6.2 合并与拆分控制在十条以内大道笔记和其他笔记不一样数量必须克制我给自己定的上限是十条。一旦超过十条说明其中一些不是道只是普通经验混进来了。超过上限时我会做一次合并和拆分两条大道应用场景高度重叠就合并成一条更抽象的表达一条大道备注越来越长、解释越来越复杂说明它被塞了太多东西反而应该拆成两条边界清晰的小道。我用第一条和第三条做过一次完整的合并再拆分循环。最开始分开写任何自动化都会引入维护负担和人必须保留最终判断权用了一段时间发现这两个判断总是一起被引用就合并成了自动化要有人工裁决点。合并后又跑了半年发现这句话对不同背景的人解释成本太高研发同事会误解成自动化要留手工按钮质量同事又误解成所有检查都得靠人我就重新拆成了两条一条专门讲验证自动化本身一条专门讲人工判断的位置。合并拆分都不是终点关键是保持每条都足够锋利。6.3 把大道笔记从收藏夹变成日常决策工具最后一步也是最重要的一步是让大道参与日常决策。只写不看和没写没有区别。我给自己设了一个轻量级的动作每做完一次重要决策用三行字快速记录——这一局我应用了哪条大道这一局我违反哪条大道有没有出现新的模式。不追求每件事都记只记真正重要的决策每周花十分钟把最近记录扫一遍。这个动作坚持半年以后我发现违反大道的情况越来越少不是因为我在压抑自己而是因为每条大道已经被反复练习成了一种本能反应。大道笔记不是用来向别人证明学习态度的它就是一个长期的、可迭代的个人决策操作系统。系统里存的不应该是别人的口号和书摘而是自己经历过、提炼过、被反例修剪过的判断规则。所有想建立这类笔记的人都不必追求一开始就完美可以先积累三到五条再用一次事故或一次成功去验证它。最后分享一个让我一直坚持的小技巧在大道笔记最上方留一块修订历史区每次因为真实事件修改了一条大道就在那里写一行记录比如这个反例让某条大道缩窄了适用范围日期和事件都写上。每次打开笔记先看这一块你能直观看见自己的判断系统在长骨头。大道不是背出来的是撞出来的。多记录那些让你别扭的冲突当场修订保持克制这本笔记会在几年后变成你最值钱的资产。