第109章 数据方法论（2/2）

请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。

“上周三下午三点零七分，我接到运维组老周的电话。生产环境er表被删。从接到电话到数据全部恢复，两小时零八分。但今天不讲这两个小时零八分里做了什么——操作步骤运维组已经在整理操作手册了。今天讲的是接到电话之后的十几分钟里，脑子里的分析框架。”

他翻到第三页。这一页只有三个词组，从上到下排列：划定时间窗口、定位异常变量、追踪因果链路。

“这套框架不是我为了删库恢复临时想出来的。它最早是用在钓鱼上的。”

台下有人轻轻笑了一声。林泠没有笑，他翻到下一页，“划定时间窗口是什么意思？任何一个系统故障，不管是数据库被删还是鱼不开口，都有一个时间边界。你要做的第一件事不是跳进去找原因，是先把时间边界划出来。数据什么时候丢的？从哪个时间点到哪个时间点之间的数据需要恢复？这个窗口划得越精确，后面的恢复策略就越清晰。

他翻到异常变量定位这一页。

“时间窗口划好之后，第二步是定位异常变量。删库恢复案例里，异常变量有三个层级——DROP TABLE是直接异常，离职运维账号未注销是根本异常，blog完整是恢复条件异常。这三个异常变量的因果关系是一层一层往下的，不找到最底层的根本异常，只处理表层的直接异常，下次还会出事。

他翻到因果链路追踪这一页。

“第三步，因果链路追踪。把时间窗口内所有异常的变量串成一条完整的因果链。删库恢复的因果链是：未注销账号被外部登录→DROP TABLE执行→er表丢失→业务中断→全量备份加增量备份加blog三段式恢复→数据零丢失。这条链上的每一个节点都是一个决策点：备份策略决定了能不能恢复，blog完整性决定了能不能做到零丢失，响应速度决定了宕机时间有多短。

他翻到最后一页。这一页只有一行字，居中排列：“这套分析方法适用于任何具有周期性波动特征的复杂系统。”

台下安静了两秒，然后有人开始鼓掌。掌声从后排先响起来，然后是中间几排，然后是整个会议室。技术副总坐在第一排靠边的位置，也在鼓掌，右手不紧不慢地拍着左手掌心。

分享会结束后，林泠被好几个人围住了。开发组一个做推荐算法的同事挤过人群走到他面前，手里拿着手机，屏幕上开着备忘录显然刚才记了不少要点。他问这套框架能不能用在算法模型的性能优化上——推荐系统的响应延迟也有明显的周期性波动，晚高峰的时候延迟会飙高，是不是也可以用时间窗口加异常变量定位的方法来排查。林泠说当然能，算法的响应延迟也是一个窗口期问题——找到流量峰值窗口，定位延迟的瓶颈变量，再追踪从流量增加到延迟升高的因果链路，逻辑完全一样。

回到工位的时候已经快五点了。窗外的阳光从百叶窗的缝隙里漏进来，在办公桌上印出一排平行的金色光条。他把翻页笔放回抽屉里，拧开保温杯喝了一口凉了大半的茶，然后把笔记本翻到分享会那页备忘，在旁边空白处补了一行字：“分享会完成，反响超预期。通用分析方法在不同领域的可迁移性得到初步验证。”写完他把笔搁在笔记本上，靠进椅背里。桌上的手机屏幕亮了一下，是钓友群的消息——张磊在问周末雨水节气要不要一起去湿地。他拿起手机回了一句：“去。”