3 年前我一个人管一个小站，没有值班表，没有备机，出错只有我自己知道。最怕的不是被攻破，是凌晨 2 点屏幕亮起来的那一刻：又一份要求尽快更新的通告。真正难的不是修，是在 10 分钟里决定现在动手，还是等天亮，而这个决定没有人能替我做。
我的总看法是：漏洞被公布的那一天，并不是最危险的开始。真正危险的是我已经知道了、但还没补完的那段真空。真空有多长，取决于我提前准备到什么程度：准备过的，这段真空是几个小时；没准备过的，是几周。补丁不是终点，它更像发令枪，枪响之后我和对面同时起跑，而我常常还没穿好鞋。
那台机器只有我一个人看着
一个人管一台机器，最难的从来不是技术，是判断。通告半夜来，字不多，语气克制，末尾一句通常是建议尽快更新。尽快是多久？2 个小时，还是 7 天？技术有对错，判断只有代价大小，所以我那时候没有标准，全看当天困不困。现在回头看，短板在这里，不在手艺上。
这几天我看到一份安全通报，讲的是同一类事，只是规模比我那个站大得多。一门用了 20 多年的网站脚本语言，被人找出了 2 个严重漏洞。找它的不是人手：研究者把手上最强的模型调过来，主动去问这里有没有问题，而不是等漏洞自己浮出来。等和搜，是两种活。
通报里有一句话我看了好几遍。他们找到的不是一个点，是一串有严格先后的步骤，顺序换一下整条路就断；这串步骤的长度，已经超出人手能做到的边界。细节我不打算知道，也不该知道。对我来说，有一串步骤、顺序不能换，这句的信息量已经够了：因为防线大致是按人的耐心设计的，一个熟手熬 2 个通宵能撞出来的路，防守方靠 1 次例行更新就能挡住；长度一旦越过这条线，门槛就从手艺挪到了算力。
七成这个数，压在我头上是几层
那门语言撑着多少站点？通报给的说法是七成。我第一眼看到这个比例，下意识把自己摘出去了，觉得我那个小站不算什么。后来想明白，比例是别人的统计，落到我头上是一个很具体的问题：我这台机器底下，到底压着几层东西。比例越高，越说明它不是某一家的私事，而是一层公共地基；地基挪一下，上面所有东西都得跟着重算。
我数过：语言本身一层，建站程序一层，主题模板一层，插件一层，托管方一层。5 层里，只有最上面那一层是我能直接动的。往下每一层都有各自的维护者，也都有各自的排期。有一次我等一个底层更新，从看到通告到真正装上，中间隔了 11 天。我一开始记成 7 天，翻了记录才发现是 11 天。那 11 天我什么也做不了，只能每天登进去看一眼版本号，末尾那一位数字没变，我就知道还要等。
这就是依赖深度的代价。它不是我技术不行，是我要等的人太多。一门语言用得越广，等的人越多；等的人越多，末尾那一环装上补丁的时间就越晚。对面不需要比我强，只需要比那一环快。
我一直觉得这类事里最容易被忽略的一点是：漏洞的数量和危险程度不是一回事。2 个漏洞，听着不多。可只要其中一条链路能从头走到尾，1 个就够用了。数量是给统计看的，能不能走通才是给维护者看的。另一头，复杂度在两边的意义正好相反：对守的一方，链路越长、顺序越死，被撞上的概率越低，我就多一点时间；对攻的一方，复杂度曾经是门槛，现在更像一道要算力的题。门槛还在，抬脚的高度变了。真正的差别在这里：一条走不通的路，写进通报也只是个数字；一条走得通的路，哪怕只有 1 条，也够对面用很久。
所以我不愿意把这件事讲成模型变强了。变强是事实，但真正挪动的是门槛的位置。过去门槛在会不会，现在门槛在敢不敢和快不快。这个变化对守的一方不算友好，因为守的人要守一大片，攻的人只要找一个口子；也因为我这边每一片都有自己的主人，谁点头都不算数，要所有人都点头。
补丁公开的那一刻，倒计时才开始
按常理，补丁发出来就该松口气。我一开始也这么想，甚至觉得这是整件事里唯一的好消息：机器替人把问题找出来了，人把补丁写出来了，剩下就是装。
我忽略了补丁本身的性质。补丁是公开的，公开的东西可以被读。它修好了什么、在哪儿修的、原来那处为什么不对，都写在差异里。对会看的人，补丁不只是药，也是一张标了位置的地图。知道这里有洞，和知道怎么走进去，中间隔着一段路，而这段路这几年一直在变短。
通报里还提到一件事，我看到时心里咯噔一下：对面也知道有漏洞了，他们在用自己那套工具反推方法，专门盯着还没更新的站点。这句话翻成我的处境就是：从补丁公开那一刻起，我面对的不再是一个已知的问题，而是一个已知有人在往这边赶的问题。前者能排期，后者只能抢时间，紧迫程度差了一个量级。
对面也在用同一把工具
这里有个不对称，值得说清楚。守的一方用模型找漏洞，是为了知道哪里要修；攻的一方用模型反推，是为了知道从哪里进。同一把工具，两种用法，成本却不一样。前者要从零开始找，后者手里已经有一个结论：这条路走得通。
结论本身就是资源，它省掉的不是力气，是试错。一条被证实存在的链路，剩下的事是把它复现出来；复现比发明容易，这在哪个行当里都一样。本质上，一边在扩大搜索范围，一边在缩小搜索范围，缩小的那一头永远更快。所以守的一方先找到这个好消息，同时也是一次公开的确认：这里确实有一扇门。
我不觉得这是研究者的错。发现、通报、推动修补，这套流程本身是对的。没有它，我连要不要现在动手这个问题都不会知道。问题在于这套流程默认了一个前提：知道的人会比赛跑的人慢。这个前提过去大致成立，现在不太成立，因为反推这一步已经被工具接过去了，而工具不会因为下班时间到了就停手。
我给自己划的三道关
说回我自己。这几年我给自己立的规矩就 3 道关，都很土，但每次都用得上。之所以是 3 道不是 5 道，是因为我记不住，记不住的规矩等于没有。
我一般先看这一条：24 小时之内，我能不能把这一轮更新从头走完，并且验证一遍。是走完加验证，不是点一下更新。很多次我以为装完了，点开一看只是下完了包。这一条答不上来，我就不该等通告来了才想。
第二道，我有没有一份能退回去的备份，而且我自己动手恢复过 2 次。我给自己定过一条：没亲手恢复过的备份，只算一个文件夹。我吃过亏：文件都在，恢复的时候才发现少了东西，进度条卡在一半不动，那时候已经没时间补。
第三道，我有没有先降到最小可用的预案。站可以暂时只剩几页静态内容，可以先关掉不必要的外露入口，可以让一部分功能停着。这个决定难下，因为它等于我主动承认现在守不住全部。真到了那一天，能下这个决定的人，比硬扛的人损失小。
这 3 道关没有一条是技术活。它们更像出门前摸一下口袋：钥匙在不在，手机有没有电。平时觉得多余，急的时候救命。我拿这个衡量自己，比拿漏洞等级衡量可靠得多。
补完之后，我把停机写进了预案
后来我看到几个公共机构的网站先后下线，连发出警告的那家机构自己也把站撤了。第一眼觉得荒唐：怎么连提醒别人的人都守不住。再看就明白了，撤站不是认输，是把可能被利用换成暂时不可用，用一段确定的时间换掉一段不确定的风险。
这个动作在我看来是专业的。站点停掉的代价看得见：有人办不了事，有人白跑一趟，有人会投诉。被利用的代价看不见：数据去了哪儿、留了多久、会不会被转手，没人说得清。两害相权，我宁可要那段看得见的停机。我以前总觉得下线等于失败，那天之后我改了看法。
也是从那之后，我把停机写进了自己的预案。写的时候才发现，停机比修东西难。修东西是我一个人的事，停机要通知、要解释、要有人接住那些本来要办事的人，这部分我以前完全没想过。难的地方不在技术，在你要替别人的时间负责。
落在我身上，其实就三条
讲了这么多，落在我身上，就 3 条。
一条是盘点。我要知道自己脚下压着几层，每一层谁在管，更新从哪儿来。这份清单我原来整整 1 年才更新 1 次，太懒，现在改成每季度对一遍。之所以按季度，是因为依赖链的变化比漏洞慢，按周查是浪费，按年查是赌博。
一条是节奏。不等通告来了才动，平时就把更新走一遍，把流程走顺。通告来了，我只是把平时做的事加快，不是第一次学怎么做。
一条是接受。接受我永远会比补丁慢一点，接受暂时不可用是一个正当选项，接受我不知道的事情比我以为的多。3 条里，第三条最难，因为它跟本能反着来。我这样判断一件事值不值得慌：先看我今晚能不能闭环，再看我退不退得回去，还看我肯不肯主动关掉一半。
普通人也被这件事连着。站点一撤，挂号、缴费、查成绩、看公告，全卡在那个打不开的页面上。我那次在窗口前站了 30 分钟，前面的人都在问同一句话：什么时候能好。没人答得上来。那一刻我特别理解补丁这两个字的分量，它不是给技术人看的，它是让这些页面重新打开的开关。
有句话说得好，亡羊补牢。这五个字常被当成一句安慰，我不这么看。牢补得慢，羊就是白丢的；真正值钱的不是补得多彻底，是从发现到补完这段能被压到多短。最划算的一圈篱笆，是羊还在的时候修的那一圈。
七成这个比例，2 个漏洞，一串换了顺序就断的步骤，再加上连发警告的机构自己都撤了站。这几件事摆在一起，不是一条热闹，是一道算术题：我准备的时间，够不够跑赢别人反推的时间。这道题没有标准答案，但每个人心里都该有一个自己的数。
这种题我会一直跟。原创不易，尤其是一个人查、一个人核对口径的写法，慢，也容易出错，但我不想拿没把握的东西来充数。下次再有类似的通告，我还是会把能写的部分写实。
|来源：互联网|编辑排版：小四|说明：本文由智慧数码体验整理创作，转载请注明来源
免责声明：本文仅供学习交流参考，不构成医疗、投资、法律等专业建议，亦不代表本公众号立场。部分文字、图片、音视频来源于网络，版权归原作者所有，如涉侵权请及时联系，我们将第一时间删除。读者据此操作风险自担，本公众号不承担相关责任；留言评论仅代表发布者个人观点。特此声明。
双击屏幕，交个朋友。
热门跟贴