北京
每个团队都有这么一个人。评审要等他，他一说"下周休假"，三个人心里同时一紧。有人做了个工具，专门在Kubernetes里找出这类人——它叫Understudy，是Graph Hacks（WeMakeDevs x FalkorDB）的参赛作品。
先看一组数字：pkg/kubelet/apis/config这块代码，九个人懂，六个人有权限批准改动。听起来挺安全。可这两个群体之间的每一条路径，都要经过同一个人。
于是作者换了个数法。Understudy不数人，数"路线"：一个懂代码的人，连到一个能批准改动的人，且路线之间不共享任何中间人。这个数字叫"替补数"（understudy number），在这里等于1。计数由FalkorDB内置的max-flow算法完成，是实打实的测量，不是拍脑袋。
这个人被代号为contributor-25b5f。所有人都以化名出现，作者也不知道他是谁，只知道他不该去休假。
接着做了一次"离职演练"：Understudy复制整张图，在副本上把这个人拿掉，看哪里会断。结果是Kubernetes的79个部分里有41个会变弱。真实数据全程不动。工具还会给出最省事的补法——在这里，让一个懂代码的人配一个审批人，就足以补上备份。
它还带了个AI代理，态度很谦卑。你可以用大白话提问，它只能从图里找答案，图里没有就按下第二个按钮。每个回答都会附上它跑过的查询语句。所有答案在给你看之前都会对着图做一次事实核查——有一次代理答对了，核查也对，作者最后靠让工具用大白话说人话、方便代理引用，才把问题修掉。
FalkorDB和作者之间还有过一次小分歧。他把每个数字都拿去和networkx对了一遍：在混合容量下，150张测试图里有8张的max-flow算出来偏低；把所有容量都设成1之后，两边每次都一致。于是现在全部设成1，问题靠"不制造问题"解决了。
那它到底准不准？作者拿真正离开Kubernetes的人做了对照：39个案例里只有7个数据够用，而且没有一个命中1。所以他很坦白——目前还证明不了。包括没跑通的部分在内，全部结果都放在应用里。
应用跑在一台免费服务器上，只有十分之一颗CPU。把启动时间从两分钟压到三十秒，本身就是一段冒险。项目已在GitHub开源（BalajiReddy1 / understudy），思路是把Kubernetes建模成FalkorDB里的一家公司，再检查真有人离开时谁能顶上。
最后留个问题：你团队里有contributor-25b5f吗？他知道自己是吗？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
