凌晨两点半线上订单服务刚刚恢复会议室里还挂着那张被擦掉一半的鱼骨图。拍照、存档、第二天谁也说不清那张照片躺在谁的手机里——这是我待过的第三家公司也是第三次撞见一模一样的场景。后来我把团队的根因复盘流程整体搬进了一个叫 MiroFish 的板子里鱼骨图不再依赖会议室那块白板而是画在一块可以多人同时编辑、长期留存、能直接导出行动项的在线画布上。它的定位说起来很朴素就是把鱼骨图因果图这种结构化的分析方法和在线白板这种门槛极低的协作形态拼在一起盯住的是分析过程留不下来、结论落不了地这两件老问题。下面我按自己实际跑过的顺序讲MiroFish 这个名字背后的两层需求、它真正替掉的是哪条老链路、部署和画布骨架怎么搭、一次完整复盘怎么从现象追到根因、多人协作时最容易翻车的几个点、它和通用白板/思维导图/表格之间的横向差异以及我用了小半年之后沉淀下来的模板和至今没解决的遗留问题。不管你是带三五个人的研发负责人、做质量改进的工程师还是单纯想治一治复盘会开完就没下文的毛病里面能直接抄走的部分都不少。1. 拆名字MiroFish 把两套完全不同的东西缝在了一起1.1 Miro 代表交互范式Fish 代表分析方法Miro 这个词在协作工具圈里几乎是在线白板的代称它背后是一整套已经被验证过的交互范式无限画布、多光标、拖拽卡片、便签、连线、框选分组。Fish 指向的是鱼骨图也就是石川馨那套把原因摊开在人、机、料、法、环、测六个维度上的因果分析图。这两个词拼在一起逻辑其实非常直白——用一块白板的外壳去承载一张必须保持严格结构的因果图。这件事听起来像是把两个现成的东西拼起来但真正难的地方恰恰在结构这两个字。通用白板的问题是太自由了你可以把便签贴到任何位置可以随便连线可以在同一块板上同时画泳道图、时间线和鱼骨图最后谁也看不懂。而纯粹的鱼骨图工具又太死板主骨、分支、叶子节点的层级写死想临时补一条环境之外的维度都做不到。MiroFish 这类项目存在的意义就是在自由到混乱和死板到没法用之间找一个中间态。1.2 它替掉的是白板 拍照 群里传图那条链路会议室白板的物理限制非常具体面积有限字写小了后排看不见一次只能一个人写其他人要么围观要么干等擦掉就没了想保留只能拍照照片进了聊天群两周之后彻底沉底。我做过一次统计团队半年里开的复盘会事后能翻出完整分析过程的不到三成绝大多数只剩一张歪着拍的照片和一句口头结论。MiroFish 把这条链路的每一步都换掉了画布无限大写不下就往右拖多人可以同时往不同骨头上贴卡片会议时间从 90 分钟压到 40 分钟左右所有卡片天然带作者、时间戳和评论会议结束后链接直接发出去半年后还能点开看当时是谁提的那条原因以及后来是怎么排除的。更关键的一点是卡片的文本结构化了可以被检索、被统计、被导出成表格——这是照片永远做不到的事。提示判断一个复盘工具值不值得迁移先问一句三个月后我还能不能按关键词搜到当时的某一条原因。搜不到那就还停留在拍照阶段。1.3 什么人适合上手什么团队其实用不着适合的场景很明确线上故障复盘、需求评审里的事故预防、生产质量异常分析、跨部门项目延期归因。共同点是问题反复出现、参与方超过三个人、结论需要被追踪。只要满足其中两条结构化的鱼骨图板子带来的收益就能覆盖学习成本。不太适合的场景也要说清楚。两三个人的小团队问题定位基本靠口头沟通就能闭环硬上一套工具反而多一层负担纯粹的头脑风暴也不需要鱼骨图那是发散场景用便利贴墙或者最简单的白板就够了另外如果你的团队连复盘要出行动项这件事都没共识那换什么工具都没用工具只会把没共识这件事放大得更明显。我见过不止一个团队买了工具、建了板子开了两次会就荒废根因不在工具在流程本身没有责任人。2. 把 MiroFish 跑起来环境、数据模型和画布骨架2.1 部署之前必须先定的三件事第一件是数据放哪儿。涉及线上故障细节、客户信息、内部架构图的板子通常不能放在公开托管的环境里要么自建要么至少确认存储区域的合规性。这一点在动手部署之前就得跟安全那边对齐别等板子画满了再迁。第二件是账号体系怎么接。团队已经有统一登录的直接对接现有身份源最省事也避免了谁是谁的混乱——鱼骨图最怕的就是卡片全是某某同事三个月后根本对不上号。没有统一登录的小团队用邀请制邮箱注册也够用。第三件是板的生命周期策略。默认永久保留会让存储和检索成本慢慢堆起来我一般会设成结项后归档归档板只读、可检索、不可编辑。归档这个动作很重要它给了复盘一个明确的终点也避免了半年后有人悄悄改掉当初的结论。2.2 一次最小可用的启动流程下面这套是我在一台 4 核 8G 的机器上跑通的最小配置用的容器方式具体的镜像名和端口以你手上的版本为准这里主要给你一个可参照的骨架。# docker-compose.yaml version: 3.9 services: mirofish: image: mirofish/board:latest restart: unless-stopped ports: - 8080:8080 environment: DB_URL: postgres://mf:******db:5432/mirofish STORAGE_DIR: /data/attachments SESSION_SECRET: 换成你自己的随机串 ALLOW_ANONYMOUS: false volumes: - ./data:/data depends_on: - db db: image: postgres:15-alpine restart: unless-stopped environment: POSTGRES_USER: mf POSTGRES_PASSWORD: ****** POSTGRES_DB: mirofish volumes: - ./pgdata:/var/lib/postgresql/data启动命令就一行没什么玄机docker compose up -d docker compose logs -f mirofish看到健康检查通过的日志之后浏览器打开http://你的机器IP:8080用第一个注册的账号做管理员。这里有个容易被忽略的细节很多自建工具的第一个注册用户会自动拿到管理员权限如果端口暴露在可被外部访问的网络上一定要在启动后的五分钟内完成注册并把注册开关关掉否则等于把后台敞开放在那儿。2.3 板、骨、刺、卡四层结构决定了后面好不好用MiroFish 这类工具的数据模型基本都是四层理解这四层后面画图和做模板都会顺很多。最外层是板Board对应一次复盘活动有标题、时间、参与人、状态。往里一层是骨Bone对应鱼骨图的主分支常见的六个维度就在这里。再往里是刺Spine也就是二级分支用来承载一层原因。最里面是卡Card也就是具体的现象描述、原因假设、证据链接、行动项。这个层级关系直接决定了三件事一是卡片的父子关系天然表达了这条原因属于哪个维度、它又是由什么导致的二是统计口径可以按骨聚合一眼看出这次事故七成原因落在流程和监控上三是导出的时候结构是完整的不会像自由画布那样导出一堆没有归属关系的便签。{ board: 2024-06 订单超时复盘, bones: [ { id: people, title: 人, spines: [排班, 熟练度, 交接] }, { id: method, title: 法, spines: [发布流程, 回滚预案, 变更审批] }, { id: measure, title: 测, spines: [监控覆盖, 告警阈值, 演练频次] } ], card_schema: [现象, 证据, 假设, 验证方式, 结论, 责任人, 截止日期] }上面这份模板是我自己长期用的卡片字段不是固定的但现象、证据、结论、责任人、截止日期这五个字段我建议一个都别删——缺了证据讨论就会变成互相猜缺了责任人行动项就等于没写。3. 一次完整的根因复盘从订单超时追到一次提交3.1 第一刀把现象钉死在鱼头上别急着找原因绝大多数复盘会之所以开得低效是因为主持人一上来就问大家觉得是什么原因。这时候所有人都在给假设没人先把现象描述清楚讨论很快就会跑偏到某某上周改了什么这种互相甩锅的轨道上。正确的顺序是反过来的先把鱼头写死。鱼头上只写三样东西发生了什么、影响多大、什么时候。比如6 月 12 日 01:40 至 02:15订单创建接口 P99 从 230ms 升到 4.2s影响约 8600 笔订单创建其中 1200 笔用户重试成功。这句话里的每个数字后面都要能指向一个可查的来源——监控面板、日志、工单系统。凡是写不出数字的就换一个能写出数字的角度重新描述。这一步看着简单实际能砍掉后面一半的无效讨论。我遇到过好几次团队吵了四十分钟才发现两边说的根本不是同一个现象一方在说接口超时另一方在说消息积压实际上是同一件事的两个表现。鱼头写清楚之后这类误解基本不会再发生。3.2 用六个维度做发散先把量做够再谈质鱼头定死之后开始往骨头上贴卡片这一步的原则是先发散、不评判。六个维度里我会按照固定的顺序过一遍确保不遗漏人排班、熟练度、交接、机机器、容器、依赖服务、料数据、配置、上游输入、法发布流程、回滚预案、审批、环流量环境、依赖方状态、测监控覆盖、告警阈值、演练。实操里有个小技巧很管用限时静默填写。给每个人三到五分钟各自往板上贴卡片全程不讨论。这样做有两个好处一是避免第一个发言的人锚定所有人的思路二是让平时在会上不太说话的人也有机会把想法放上去。等卡片贴完再统一过一遍把重复的合并、把明显跑题的移到暂不讨论区。贴卡片的时候有两条纪律要守住。第一一张卡只说一个原因宁可多贴几张也不要把排班不合理导致夜班响应慢并且监控告警没配置塞进同一张卡——这种复合卡在后面追问的时候会彻底卡住。第二卡片上必须带证据或验证方式哪怕只是一句可以查 1:40 前后的容器重启记录也比一张空口猜测的卡片强得多。3.3 5Why 追问的停止条件和常见跑偏发散完之后是收敛用的是 5Why对每一条看起来最可疑的原因继续往下问为什么。这里有两个新手最容易踩的坑。第一个坑是把 5Why 当成必须问满五层。五只是一个经验值不是硬指标。追问的正确停止条件是再往下问一层得到的答案已经超出团队的控制范围或者答案是这是行业普遍现象。比如追到上游云服务商在该区域发生了短时抖动这就不是你能改的东西再往下问就是浪费时间。反过来如果追到第二层就出现了因为流程没写清楚那还得继续往下问清楚是哪个流程、谁负责写、为什么没写。第二个坑是把追问变成追责。一旦问题指向某个具体的人会上气氛立刻变味后面所有人都会开始自我保护卡片上的内容会明显变少。我的做法是在模板里加一条约定追问的对象永远是机制而不是个人如果某条原因确实涉及具体操作表述上要写成变更 checklist 中缺少 X 项校验而不是某某忘了校验。这不是和稀泥因为个人失误在复盘里几乎是必然出现的真正有价值的问题是为什么这个失误没有被拦住。3.4 从根因到行动项不写责任人和日期的都算没写收敛结束之后要把根因转成行动项这一步是决定复盘有没有价值的唯一环节。行动项的写法我有一条硬规定动词开头、有明确交付物、有责任人、有截止日期、有验收方式。四条缺一条这条行动项就会被判为无效当场退回重写。举个对比例的写法。加强监控是无效的在订单创建接口增加 P99 耗时告警阈值 800ms连续 3 分钟触发由某某在 6 月 20 日前完成并在测试环境验证误报率是有效的。区别不在于写得多长而在于前者无法验收后者可以。行动项在板子上要跟根因卡片建立父子关联这一点是结构化板子相比白板最大的优势。等到下次复盘同类问题时直接搜上一次的相关板子就能看到当时的根因和行动项以及它到底有没有被执行、有没有生效。我做过一次回看半年内同一个模块的三次故障有两条行动项是重复出现的——这本身就是比故障更值得关注的信号。4. 协作才是真考验并发、权限和匿名模式4.1 多人同时拖同一张卡片冲突怎么处理在线白板的多人并发是必答题。MiroFish 这类工具在这块的常见做法是卡片级锁加操作合并当 A 正在编辑某张卡片时B 看到的这张卡会带一个正在编辑的标识B 可以继续看但提交时会收到提示。实测下来这套机制在五到八个人同时操作时基本够用超过十五个人在同一块板上密集操作还是会出现卡片位置跳动的情况。我的经验是按维度分区认领。开会前把六根骨头分配给不同的人或者小组每个人只在自己负责的区域里贴卡片物理上减少了写冲突同时每个人对信息的掌握也更集中。会后统一收敛的时候再一个人操作、其他人只读这种发散阶段并行、收敛阶段串行的节奏比全程放开多人编辑要稳得多。另外一个细节是撤销的边界。多数白板的撤销是本地栈你自己按撤销只会撤掉你自己的操作这个设计是对的但如果你发现撤销之后别人的卡片也动了那大概率是服务端的操作合并出了问题值得单独排查一下版本。4.2 权限粒度能不能删别人的刺必须单独设权限这块一定要按操作类型而不是角色名字去想。复盘场景里至少需要区分四种操作看板默认所有人、加卡所有参与者、移动或改别人的卡受限、删卡或归档管理员。很多团队一上来只分管理员和成员两档结果要么人人能删要么人人不能动两种都难受。我在实际使用中把删除和归档拆成了两个权限。删除是真的移除归档是移到一个不可见的已排除区域但保留痕迹。复盘会上很多被否掉的原因其实是有价值的——它记录了我们当时考虑过这个方向并且排除了几个月后再看能省掉重复讨论的成本。所以默认给所有人归档权限、只给管理员删除权限是一个折中得很舒服的配置。4.3 匿名模式敢说话和乱说话之间那条线匿名是个双刃剑。做故障复盘的时候有些原因确实是某次变更没有走审批这类敏感信息实名环境下没人愿意写。开启匿名之后卡片上的内容一般会明显变多、变直接。但匿名带来的副作用也很实际一是无法追问细节你不知道该找谁补充二是极端情况下会出现情绪化的表达。我的处理方式是匿名投稿 实名认领匿名阶段只允许写卡片不允许评论和回复收敛阶段要求每条被保留的匿名卡片必须有人认领并补充证据无人认领的卡片自动进入待定区。这样既保护了发言意愿又保证了最后落地的结论是可追溯的。注意匿名模式一旦开启就不要在会中突然关闭。中途切换会让已经匿名发言的人产生被追溯的担忧后面的内容质量会断崖式下降。5. 选型对比什么情况下值得从通用白板迁过来5.1 四种做法在根因分析场景下的实测差异我把用过的四种做法放在一起横向比一下评分维度是围绕复盘这个具体场景来的不代表工具的通用能力。维度MiroFish 类结构化板通用在线白板思维导图表格 / 文档结构保持强骨与刺有固定父子关系弱全靠人工摆放中树形但无维度概念强但无图形直觉多维度发散强六骨天然分区中需要自己画框弱树形结构偏单向弱列多了很难看多人并发强按区认领后很稳强中中易覆盖冲突事后检索强卡片字段可搜弱只能搜到便签文本中强行动项追踪强卡片自带责任人字段无无强但没有看板视图学习成本中需要理解骨与刺低低极低会议中的参与感强强中弱看这张表能得出一个很直接的结论如果复盘只是偶尔做一次、参与人不超过三个通用白板甚至表格就够用只有当反复发生的问题 多人参与 结论要追踪这三条同时成立时结构化的板子才划算。5.2 迁移的临界点和迁移顺序我的建议是设一个很具体的触发条件同一个模块在三个月内因为不同原因出过两次以上同类问题就把这类复盘迁到结构化板子上。这个条件很好判断也不需要提前做任何工具评估。迁移顺序上不要一次全搬。先挑一次真实发生的故障用新工具完整跑一遍过程中把不顺手的地方记下来跑完两三次之后再固化模板模板稳定之后再把历史板子逐步导入。反过来一上来就把过去一年的复盘记录全导进去通常会得到一个没人愿意再打开的仓库——因为格式不统一看起来比原来还乱。5.3 成本账自建、托管和纯手工各自适合谁自建的成本主要不在机器上一台小规格的服务器一年花不了多少钱真正的时间成本在首次部署、升级维护和备份策略上。如果你的团队没有稳定的运维人力自建很容易变成部署完之后没人管版本越拖越旧。托管方案省心代价是数据要放在外部涉及敏感信息时需要额外评估。纯手工方案表格加会议纪要成本最低但它的隐性成本最高——我算过一次一场 90 分钟的复盘会六个人参与加上会后整理纪要和追踪行动项折算下来大约是一个工作日的人力其中至少三分之一浪费在信息不同步上。6. 用了小半年之后我留下来的模板和没解决的问题6.1 三套模板故障复盘、需求评审、项目延期跑顺之后我固化了三套模板。故障复盘模板用的是六骨结构卡片字段含现象、证据、假设、验证方式、结论需求评审模板把六骨换成了需求清晰度、依赖方、技术风险、排期冲突、验收标准、回滚方案项目延期模板换成范围变更、人力、外部依赖、估算偏差、沟通链路、验收阻塞。三套模板共用一个卡片结构只是骨的名字不同这样检索的时候口径是统一的。模板这件事的价值在于降低启动成本。没有模板的时候每次开会光讨论我们这次按哪几个维度看就要花掉十分钟而且每次都不一样导致历史数据没法横向对比。6.2 卡片粒度宁可多一根刺也不要一张大卡这是我踩得最深的一个坑。刚开始用的时候为了让板子看起来清爽我习惯把相关的原因合并成一张大卡比如发布流程不规范缺少灰度环节和回滚演练。结果是每次追问都卡壳——到底是灰度的问题还是回滚的问题负责人写谁验收方式怎么写后来我改成了一个粗暴但有效的规则一张卡上如果出现和以及并且这类连接词就拆开。拆完之后板子确实会变密但每张卡都能独立指派责任人和截止日期收敛阶段的效率反而高了。板子密不密是观众的感受行动项清不清楚才是复盘的目的。6.3 闭环行动项不同步出去板子就是座孤岛结构化板子最大的风险是变成另一个信息孤岛。板子画得很漂亮行动项写得很规范但没有人去工单系统里看到了截止日期也没人催一个月后板子归档、事情照旧。这个问题我在第二个季度遇到了根源在于板子和日常工作流之间没有接口。解决办法很土但很管用复盘会结束前由主持人当场把所有行动项复制到工单系统并把工单编号回填到对应卡片的字段里。只要这一步做了行动项就自动进入了原有的排期、提醒和验收流程不需要任何新的机制。回填这个动作看着像多余的手工活但它把复盘和执行这两件事真正焊在了一起。6.4 几个我到现在也没解决的问题第一个是收敛阶段的效率。六骨发散完之后通常会有三四十张卡片靠人工逐条追问和合并一场会至少要多花二十分钟。我试过按关键词做初步聚类效果一般因为同一件事在不同人嘴里用词差异太大最后还是得人来判断。第二个是匿名卡片的认领率。设置了匿名投稿之后大约有三成的卡片无人认领最后只能进待定区。这部分内容里确实有价值的但因为缺少证据链没法转成行动项最后也就不了了之。第三个是跨团队的板子。同一场故障往往涉及两三个团队的模块各自建板子的话信息是割裂的。把所有人拉到一块板上又会遇到权限和数据边界的问题。我目前的做法是每个团队建自己的板子然后在一块只读的聚合板上做汇总视图算是能用但离顺畅还有距离。最后一个体会可能比工具本身更重要鱼骨图和在线白板解决的是怎么把讨论记录下来解决不了愿不愿意说真话。我见过板子搭得极其规范的团队复盘质量依然很一般因为所有人都知道真正的原因说出来会得罪人。工具能做的是把真话记录下来、传播出去、追踪到底至于有没有人愿意开口那是团队氛围的事得靠主持人的控场能力和长期的信任积累。这一点上再好的画布也替不了你。
凌晨两点半线上订单服务刚刚恢复会议室里还挂着那张被擦掉一半的鱼骨图。拍照、存档、第二天谁也说不清那张照片躺在谁的手机里——这是我待过的第三家公司也是第三次撞见一模一样的场景。后来我把团队的根因复盘流程整体搬进了一个叫 MiroFish 的板子里鱼骨图不再依赖会议室那块白板而是画在一块可以多人同时编辑、长期留存、能直接导出行动项的在线画布上。它的定位说起来很朴素就是把鱼骨图因果图这种结构化的分析方法和在线白板这种门槛极低的协作形态拼在一起盯住的是分析过程留不下来、结论落不了地这两件老问题。下面我按自己实际跑过的顺序讲MiroFish 这个名字背后的两层需求、它真正替掉的是哪条老链路、部署和画布骨架怎么搭、一次完整复盘怎么从现象追到根因、多人协作时最容易翻车的几个点、它和通用白板/思维导图/表格之间的横向差异以及我用了小半年之后沉淀下来的模板和至今没解决的遗留问题。不管你是带三五个人的研发负责人、做质量改进的工程师还是单纯想治一治复盘会开完就没下文的毛病里面能直接抄走的部分都不少。1. 拆名字MiroFish 把两套完全不同的东西缝在了一起1.1 Miro 代表交互范式Fish 代表分析方法Miro 这个词在协作工具圈里几乎是在线白板的代称它背后是一整套已经被验证过的交互范式无限画布、多光标、拖拽卡片、便签、连线、框选分组。Fish 指向的是鱼骨图也就是石川馨那套把原因摊开在人、机、料、法、环、测六个维度上的因果分析图。这两个词拼在一起逻辑其实非常直白——用一块白板的外壳去承载一张必须保持严格结构的因果图。这件事听起来像是把两个现成的东西拼起来但真正难的地方恰恰在结构这两个字。通用白板的问题是太自由了你可以把便签贴到任何位置可以随便连线可以在同一块板上同时画泳道图、时间线和鱼骨图最后谁也看不懂。而纯粹的鱼骨图工具又太死板主骨、分支、叶子节点的层级写死想临时补一条环境之外的维度都做不到。MiroFish 这类项目存在的意义就是在自由到混乱和死板到没法用之间找一个中间态。1.2 它替掉的是白板 拍照 群里传图那条链路会议室白板的物理限制非常具体面积有限字写小了后排看不见一次只能一个人写其他人要么围观要么干等擦掉就没了想保留只能拍照照片进了聊天群两周之后彻底沉底。我做过一次统计团队半年里开的复盘会事后能翻出完整分析过程的不到三成绝大多数只剩一张歪着拍的照片和一句口头结论。MiroFish 把这条链路的每一步都换掉了画布无限大写不下就往右拖多人可以同时往不同骨头上贴卡片会议时间从 90 分钟压到 40 分钟左右所有卡片天然带作者、时间戳和评论会议结束后链接直接发出去半年后还能点开看当时是谁提的那条原因以及后来是怎么排除的。更关键的一点是卡片的文本结构化了可以被检索、被统计、被导出成表格——这是照片永远做不到的事。提示判断一个复盘工具值不值得迁移先问一句三个月后我还能不能按关键词搜到当时的某一条原因。搜不到那就还停留在拍照阶段。1.3 什么人适合上手什么团队其实用不着适合的场景很明确线上故障复盘、需求评审里的事故预防、生产质量异常分析、跨部门项目延期归因。共同点是问题反复出现、参与方超过三个人、结论需要被追踪。只要满足其中两条结构化的鱼骨图板子带来的收益就能覆盖学习成本。不太适合的场景也要说清楚。两三个人的小团队问题定位基本靠口头沟通就能闭环硬上一套工具反而多一层负担纯粹的头脑风暴也不需要鱼骨图那是发散场景用便利贴墙或者最简单的白板就够了另外如果你的团队连复盘要出行动项这件事都没共识那换什么工具都没用工具只会把没共识这件事放大得更明显。我见过不止一个团队买了工具、建了板子开了两次会就荒废根因不在工具在流程本身没有责任人。2. 把 MiroFish 跑起来环境、数据模型和画布骨架2.1 部署之前必须先定的三件事第一件是数据放哪儿。涉及线上故障细节、客户信息、内部架构图的板子通常不能放在公开托管的环境里要么自建要么至少确认存储区域的合规性。这一点在动手部署之前就得跟安全那边对齐别等板子画满了再迁。第二件是账号体系怎么接。团队已经有统一登录的直接对接现有身份源最省事也避免了谁是谁的混乱——鱼骨图最怕的就是卡片全是某某同事三个月后根本对不上号。没有统一登录的小团队用邀请制邮箱注册也够用。第三件是板的生命周期策略。默认永久保留会让存储和检索成本慢慢堆起来我一般会设成结项后归档归档板只读、可检索、不可编辑。归档这个动作很重要它给了复盘一个明确的终点也避免了半年后有人悄悄改掉当初的结论。2.2 一次最小可用的启动流程下面这套是我在一台 4 核 8G 的机器上跑通的最小配置用的容器方式具体的镜像名和端口以你手上的版本为准这里主要给你一个可参照的骨架。# docker-compose.yaml version: 3.9 services: mirofish: image: mirofish/board:latest restart: unless-stopped ports: - 8080:8080 environment: DB_URL: postgres://mf:******db:5432/mirofish STORAGE_DIR: /data/attachments SESSION_SECRET: 换成你自己的随机串 ALLOW_ANONYMOUS: false volumes: - ./data:/data depends_on: - db db: image: postgres:15-alpine restart: unless-stopped environment: POSTGRES_USER: mf POSTGRES_PASSWORD: ****** POSTGRES_DB: mirofish volumes: - ./pgdata:/var/lib/postgresql/data启动命令就一行没什么玄机docker compose up -d docker compose logs -f mirofish看到健康检查通过的日志之后浏览器打开http://你的机器IP:8080用第一个注册的账号做管理员。这里有个容易被忽略的细节很多自建工具的第一个注册用户会自动拿到管理员权限如果端口暴露在可被外部访问的网络上一定要在启动后的五分钟内完成注册并把注册开关关掉否则等于把后台敞开放在那儿。2.3 板、骨、刺、卡四层结构决定了后面好不好用MiroFish 这类工具的数据模型基本都是四层理解这四层后面画图和做模板都会顺很多。最外层是板Board对应一次复盘活动有标题、时间、参与人、状态。往里一层是骨Bone对应鱼骨图的主分支常见的六个维度就在这里。再往里是刺Spine也就是二级分支用来承载一层原因。最里面是卡Card也就是具体的现象描述、原因假设、证据链接、行动项。这个层级关系直接决定了三件事一是卡片的父子关系天然表达了这条原因属于哪个维度、它又是由什么导致的二是统计口径可以按骨聚合一眼看出这次事故七成原因落在流程和监控上三是导出的时候结构是完整的不会像自由画布那样导出一堆没有归属关系的便签。{ board: 2024-06 订单超时复盘, bones: [ { id: people, title: 人, spines: [排班, 熟练度, 交接] }, { id: method, title: 法, spines: [发布流程, 回滚预案, 变更审批] }, { id: measure, title: 测, spines: [监控覆盖, 告警阈值, 演练频次] } ], card_schema: [现象, 证据, 假设, 验证方式, 结论, 责任人, 截止日期] }上面这份模板是我自己长期用的卡片字段不是固定的但现象、证据、结论、责任人、截止日期这五个字段我建议一个都别删——缺了证据讨论就会变成互相猜缺了责任人行动项就等于没写。3. 一次完整的根因复盘从订单超时追到一次提交3.1 第一刀把现象钉死在鱼头上别急着找原因绝大多数复盘会之所以开得低效是因为主持人一上来就问大家觉得是什么原因。这时候所有人都在给假设没人先把现象描述清楚讨论很快就会跑偏到某某上周改了什么这种互相甩锅的轨道上。正确的顺序是反过来的先把鱼头写死。鱼头上只写三样东西发生了什么、影响多大、什么时候。比如6 月 12 日 01:40 至 02:15订单创建接口 P99 从 230ms 升到 4.2s影响约 8600 笔订单创建其中 1200 笔用户重试成功。这句话里的每个数字后面都要能指向一个可查的来源——监控面板、日志、工单系统。凡是写不出数字的就换一个能写出数字的角度重新描述。这一步看着简单实际能砍掉后面一半的无效讨论。我遇到过好几次团队吵了四十分钟才发现两边说的根本不是同一个现象一方在说接口超时另一方在说消息积压实际上是同一件事的两个表现。鱼头写清楚之后这类误解基本不会再发生。3.2 用六个维度做发散先把量做够再谈质鱼头定死之后开始往骨头上贴卡片这一步的原则是先发散、不评判。六个维度里我会按照固定的顺序过一遍确保不遗漏人排班、熟练度、交接、机机器、容器、依赖服务、料数据、配置、上游输入、法发布流程、回滚预案、审批、环流量环境、依赖方状态、测监控覆盖、告警阈值、演练。实操里有个小技巧很管用限时静默填写。给每个人三到五分钟各自往板上贴卡片全程不讨论。这样做有两个好处一是避免第一个发言的人锚定所有人的思路二是让平时在会上不太说话的人也有机会把想法放上去。等卡片贴完再统一过一遍把重复的合并、把明显跑题的移到暂不讨论区。贴卡片的时候有两条纪律要守住。第一一张卡只说一个原因宁可多贴几张也不要把排班不合理导致夜班响应慢并且监控告警没配置塞进同一张卡——这种复合卡在后面追问的时候会彻底卡住。第二卡片上必须带证据或验证方式哪怕只是一句可以查 1:40 前后的容器重启记录也比一张空口猜测的卡片强得多。3.3 5Why 追问的停止条件和常见跑偏发散完之后是收敛用的是 5Why对每一条看起来最可疑的原因继续往下问为什么。这里有两个新手最容易踩的坑。第一个坑是把 5Why 当成必须问满五层。五只是一个经验值不是硬指标。追问的正确停止条件是再往下问一层得到的答案已经超出团队的控制范围或者答案是这是行业普遍现象。比如追到上游云服务商在该区域发生了短时抖动这就不是你能改的东西再往下问就是浪费时间。反过来如果追到第二层就出现了因为流程没写清楚那还得继续往下问清楚是哪个流程、谁负责写、为什么没写。第二个坑是把追问变成追责。一旦问题指向某个具体的人会上气氛立刻变味后面所有人都会开始自我保护卡片上的内容会明显变少。我的做法是在模板里加一条约定追问的对象永远是机制而不是个人如果某条原因确实涉及具体操作表述上要写成变更 checklist 中缺少 X 项校验而不是某某忘了校验。这不是和稀泥因为个人失误在复盘里几乎是必然出现的真正有价值的问题是为什么这个失误没有被拦住。3.4 从根因到行动项不写责任人和日期的都算没写收敛结束之后要把根因转成行动项这一步是决定复盘有没有价值的唯一环节。行动项的写法我有一条硬规定动词开头、有明确交付物、有责任人、有截止日期、有验收方式。四条缺一条这条行动项就会被判为无效当场退回重写。举个对比例的写法。加强监控是无效的在订单创建接口增加 P99 耗时告警阈值 800ms连续 3 分钟触发由某某在 6 月 20 日前完成并在测试环境验证误报率是有效的。区别不在于写得多长而在于前者无法验收后者可以。行动项在板子上要跟根因卡片建立父子关联这一点是结构化板子相比白板最大的优势。等到下次复盘同类问题时直接搜上一次的相关板子就能看到当时的根因和行动项以及它到底有没有被执行、有没有生效。我做过一次回看半年内同一个模块的三次故障有两条行动项是重复出现的——这本身就是比故障更值得关注的信号。4. 协作才是真考验并发、权限和匿名模式4.1 多人同时拖同一张卡片冲突怎么处理在线白板的多人并发是必答题。MiroFish 这类工具在这块的常见做法是卡片级锁加操作合并当 A 正在编辑某张卡片时B 看到的这张卡会带一个正在编辑的标识B 可以继续看但提交时会收到提示。实测下来这套机制在五到八个人同时操作时基本够用超过十五个人在同一块板上密集操作还是会出现卡片位置跳动的情况。我的经验是按维度分区认领。开会前把六根骨头分配给不同的人或者小组每个人只在自己负责的区域里贴卡片物理上减少了写冲突同时每个人对信息的掌握也更集中。会后统一收敛的时候再一个人操作、其他人只读这种发散阶段并行、收敛阶段串行的节奏比全程放开多人编辑要稳得多。另外一个细节是撤销的边界。多数白板的撤销是本地栈你自己按撤销只会撤掉你自己的操作这个设计是对的但如果你发现撤销之后别人的卡片也动了那大概率是服务端的操作合并出了问题值得单独排查一下版本。4.2 权限粒度能不能删别人的刺必须单独设权限这块一定要按操作类型而不是角色名字去想。复盘场景里至少需要区分四种操作看板默认所有人、加卡所有参与者、移动或改别人的卡受限、删卡或归档管理员。很多团队一上来只分管理员和成员两档结果要么人人能删要么人人不能动两种都难受。我在实际使用中把删除和归档拆成了两个权限。删除是真的移除归档是移到一个不可见的已排除区域但保留痕迹。复盘会上很多被否掉的原因其实是有价值的——它记录了我们当时考虑过这个方向并且排除了几个月后再看能省掉重复讨论的成本。所以默认给所有人归档权限、只给管理员删除权限是一个折中得很舒服的配置。4.3 匿名模式敢说话和乱说话之间那条线匿名是个双刃剑。做故障复盘的时候有些原因确实是某次变更没有走审批这类敏感信息实名环境下没人愿意写。开启匿名之后卡片上的内容一般会明显变多、变直接。但匿名带来的副作用也很实际一是无法追问细节你不知道该找谁补充二是极端情况下会出现情绪化的表达。我的处理方式是匿名投稿 实名认领匿名阶段只允许写卡片不允许评论和回复收敛阶段要求每条被保留的匿名卡片必须有人认领并补充证据无人认领的卡片自动进入待定区。这样既保护了发言意愿又保证了最后落地的结论是可追溯的。注意匿名模式一旦开启就不要在会中突然关闭。中途切换会让已经匿名发言的人产生被追溯的担忧后面的内容质量会断崖式下降。5. 选型对比什么情况下值得从通用白板迁过来5.1 四种做法在根因分析场景下的实测差异我把用过的四种做法放在一起横向比一下评分维度是围绕复盘这个具体场景来的不代表工具的通用能力。维度MiroFish 类结构化板通用在线白板思维导图表格 / 文档结构保持强骨与刺有固定父子关系弱全靠人工摆放中树形但无维度概念强但无图形直觉多维度发散强六骨天然分区中需要自己画框弱树形结构偏单向弱列多了很难看多人并发强按区认领后很稳强中中易覆盖冲突事后检索强卡片字段可搜弱只能搜到便签文本中强行动项追踪强卡片自带责任人字段无无强但没有看板视图学习成本中需要理解骨与刺低低极低会议中的参与感强强中弱看这张表能得出一个很直接的结论如果复盘只是偶尔做一次、参与人不超过三个通用白板甚至表格就够用只有当反复发生的问题 多人参与 结论要追踪这三条同时成立时结构化的板子才划算。5.2 迁移的临界点和迁移顺序我的建议是设一个很具体的触发条件同一个模块在三个月内因为不同原因出过两次以上同类问题就把这类复盘迁到结构化板子上。这个条件很好判断也不需要提前做任何工具评估。迁移顺序上不要一次全搬。先挑一次真实发生的故障用新工具完整跑一遍过程中把不顺手的地方记下来跑完两三次之后再固化模板模板稳定之后再把历史板子逐步导入。反过来一上来就把过去一年的复盘记录全导进去通常会得到一个没人愿意再打开的仓库——因为格式不统一看起来比原来还乱。5.3 成本账自建、托管和纯手工各自适合谁自建的成本主要不在机器上一台小规格的服务器一年花不了多少钱真正的时间成本在首次部署、升级维护和备份策略上。如果你的团队没有稳定的运维人力自建很容易变成部署完之后没人管版本越拖越旧。托管方案省心代价是数据要放在外部涉及敏感信息时需要额外评估。纯手工方案表格加会议纪要成本最低但它的隐性成本最高——我算过一次一场 90 分钟的复盘会六个人参与加上会后整理纪要和追踪行动项折算下来大约是一个工作日的人力其中至少三分之一浪费在信息不同步上。6. 用了小半年之后我留下来的模板和没解决的问题6.1 三套模板故障复盘、需求评审、项目延期跑顺之后我固化了三套模板。故障复盘模板用的是六骨结构卡片字段含现象、证据、假设、验证方式、结论需求评审模板把六骨换成了需求清晰度、依赖方、技术风险、排期冲突、验收标准、回滚方案项目延期模板换成范围变更、人力、外部依赖、估算偏差、沟通链路、验收阻塞。三套模板共用一个卡片结构只是骨的名字不同这样检索的时候口径是统一的。模板这件事的价值在于降低启动成本。没有模板的时候每次开会光讨论我们这次按哪几个维度看就要花掉十分钟而且每次都不一样导致历史数据没法横向对比。6.2 卡片粒度宁可多一根刺也不要一张大卡这是我踩得最深的一个坑。刚开始用的时候为了让板子看起来清爽我习惯把相关的原因合并成一张大卡比如发布流程不规范缺少灰度环节和回滚演练。结果是每次追问都卡壳——到底是灰度的问题还是回滚的问题负责人写谁验收方式怎么写后来我改成了一个粗暴但有效的规则一张卡上如果出现和以及并且这类连接词就拆开。拆完之后板子确实会变密但每张卡都能独立指派责任人和截止日期收敛阶段的效率反而高了。板子密不密是观众的感受行动项清不清楚才是复盘的目的。6.3 闭环行动项不同步出去板子就是座孤岛结构化板子最大的风险是变成另一个信息孤岛。板子画得很漂亮行动项写得很规范但没有人去工单系统里看到了截止日期也没人催一个月后板子归档、事情照旧。这个问题我在第二个季度遇到了根源在于板子和日常工作流之间没有接口。解决办法很土但很管用复盘会结束前由主持人当场把所有行动项复制到工单系统并把工单编号回填到对应卡片的字段里。只要这一步做了行动项就自动进入了原有的排期、提醒和验收流程不需要任何新的机制。回填这个动作看着像多余的手工活但它把复盘和执行这两件事真正焊在了一起。6.4 几个我到现在也没解决的问题第一个是收敛阶段的效率。六骨发散完之后通常会有三四十张卡片靠人工逐条追问和合并一场会至少要多花二十分钟。我试过按关键词做初步聚类效果一般因为同一件事在不同人嘴里用词差异太大最后还是得人来判断。第二个是匿名卡片的认领率。设置了匿名投稿之后大约有三成的卡片无人认领最后只能进待定区。这部分内容里确实有价值的但因为缺少证据链没法转成行动项最后也就不了了之。第三个是跨团队的板子。同一场故障往往涉及两三个团队的模块各自建板子的话信息是割裂的。把所有人拉到一块板上又会遇到权限和数据边界的问题。我目前的做法是每个团队建自己的板子然后在一块只读的聚合板上做汇总视图算是能用但离顺畅还有距离。最后一个体会可能比工具本身更重要鱼骨图和在线白板解决的是怎么把讨论记录下来解决不了愿不愿意说真话。我见过板子搭得极其规范的团队复盘质量依然很一般因为所有人都知道真正的原因说出来会得罪人。工具能做的是把真话记录下来、传播出去、追踪到底至于有没有人愿意开口那是团队氛围的事得靠主持人的控场能力和长期的信任积累。这一点上再好的画布也替不了你。
` 完全指南：从右向左的函数组合与 Store Enhancer 应用)
