引子：告别“纯手工”时代

如果你也是一名 Android 玩机爱好者，你一定经历过这样的痛苦：

1. 机场订阅更新了，得手动去复制链接、更新配置、重启服务。
2. 想要微调一个分流规则，得在手机那个局促的编辑器里改几十行 JSON。
3. 换了台手机，所有的分流逻辑又要重写一遍。

在 Mice-Tailor-Infra 的世界里，这种低效的操作是不被允许的。既然我们已经有了准时的调度（MiceTimer）和高质量的数据（FCM-Hosts-Next），那么最后一步就是：将 Sing-box 运行环境彻底基础设施化。

今天我们要聊的是：如何用 Infrastructure as Code (IaC) 的思想，重构 Android 端的网络治理。

引子：域名再美，数据不活也是徒劳

在上一篇《MiceTimer 诞生记》中，我们解决了 Android 端的“执行确定性”问题。但很快，另一个更底层的问题浮出水面：如果你的 Hosts 数据本身就是腐烂的，那么再准时的唤醒也只是在搬运垃圾。

市面上大多数 FCM 优化方案都死在了“数据源”上：要么是几个月更新一次的静态文件，要么是简单粗暴的全局 Ping 扫描。

在 Mice-Tailor-Infra 的哲学里，数据不应该是“捡”来的，而应该是“炼”出来的。今天我们拆解这套全自动化的数据工厂：FCM-Hosts-Next。

序言：索然无味的“稳定”

最近我的 FCM 连接时间稳定得让人有些想打呵欠。Time connected 长期维持在 1.5 小时以上，重连几乎是秒级完成。在玩机圈摸爬滚打这么久，我深知这种“索然无味”背后的含义：基础设施的边界情况被彻底堵死了。

但在几天前，情况完全不是这样。

那时候，我还在依赖最原始的 Shell 脚本配合 while true; sleep 1h 来更新 FCM Hosts。我本以为这很稳，直到我发现：每当我晚上睡觉放下手机，早起一看，Hosts 的同步记录竟然断了五六个小时。

这时候我才意识到，我掉进了 Android 系统那个深不可测的“休眠黑洞”。

背景

在 Root 或使用各类后台管理工具（如墓碑、NoActive 等）后，验证 FCM 推送是否正常工作是一个常见痛点。传统方法依赖他人发送消息，效率低下且不确定。本文提供一种利用 Telegram Bot API 实现的、完全自主的 FCM 推送测试方案。

该方案旨在模拟 App 进程被杀或进入后台限制后，依赖 FCM 唤醒并接收消息的场景。

实战：GitLab 从 v14 到 v18 的跨版本无损升级与 CI/CD 终极排障

1. 背景：偿还四年技术债

本文记录了将一台生产环境 GitLab 社区版 (CE) 从 v14.6.1 (2021 年) 跨越 4 个大版本，无损升级至最新稳定版 v18.5.0 极狐版 (JiHu) 的全流程。本次升级旨在解决旧版本安全漏洞、利用新版效能分析工具进行工作量量化，并实现架构现代化 (IaC)。

核心挑战：

1. 数据库复杂迁移：需执行两次数据库引擎大版本升级（PostgreSQL 12 -> 13 -> 16）。
2. 网络协议冲突：解决 Docker Compose 内部网络与外部 Nginx 反向代理之间的 HTTPS/HTTP 协议冲突。
3. Runner 兼容性：修复 GitLab 18 对旧 Runner 注册信息及 session_server 的底层 Bug。

我是一个有“洁癖”的工程师。我无法忍受我的源代码目录里，混杂着 __pycache__、.pytest_cache，以及各种虚拟环境工具（如 .venv, .pixi）生成的、动辄几百 MB 的“垃圾”。.gitignore 是一个伟大的发明，但它只是“眼不见为净”——这些文件依然物理地躺在我的项目文件夹里。

这在平时没什么，但当某些场景出现时，这种“同居”状态就变得无法忍受。比如，我最近在用一个自研的 snapshot 工具，它是一个 Web 应用，是通过文件上传弹窗来选择项目目录用来生产 AI 可以消费的snapshot.md文件用于通过 ai 迅速了解一个项目的大概情况并让 ai 获悉项目的结构和细节等信息的工具，并且可以递归解析.gitignore 文件并为每个文件夹独立解析。问题来了：浏览器和 Node.js 的文件 API，根本不鸟 .gitignore！

每次为了生成一个干净的代码快照，我都必须手动地、临时地将 .pixi 文件夹移出去，完事后再移回来。这太蠢了，不仅麻烦，而且极易出错。我忍不了了。我必须找到一个一劳永逸的解决方案。

在上一篇，我们用 crossterm 绘制出了一个专业的 TUI 界面。现在，是时候挑战 PIPA-rs 的真正核心了：实现 pipa-rs stat -- <command>，一个 perf stat 的原生替代品。

这意味着，我们要直面 perf_event_open 这个系统调用，去精确测量一个外部命令从生到死的完整生命周期。

前期的探索，虽然没有产生一行可用的代码，但却留下了一份极其宝贵的财富：一份详尽的“此路不通”的地图。 它用 ptrace 和信号的失败告诉我们，任何试图在用户态通过复杂技巧来模拟内核级同步的方案，都是在与操作系统的底层调度作对，这是一场注定会失败的战争。

所以，这次我们不是在收拾烂摊子。我们怀揣着“排除法得来的宝贵知识”，进行了一次目标明确的、从零开始的正确构建。我们的任务，从“发明创造”，转变成了“探索发现”。

在上一篇手记中，我们为 PIPA-rs 搭建了一副坚固的“骨架”——一个自律的、自动化的工程框架。现在，是时候为这副骨架注入第一股“生命力”了。我们的目标是：深入 pipa_collector，从零开始实现对系统核心指标的采集，并构建一个基础的 TUI 监控工具，作为 sar 和 top 的一个微型替代品。

有人可能会问，Linux 上有那么多现成的工具和 crate，为什么非要选择一条最“难”的路——直接去解析 /proc 文件系统？

答案很简单，它源于 PIPA-rs 的核心理念：“零外部二进制依赖”和“超可靠”。我们不希望 PIPA-rs 的可靠性建立在对 sar 命令输出格式的脆弱假设上。我们希望直接与内核提供的数据源对话，并用自己的代码来保证每一次解析的健壮性。这不仅仅是重新造轮子，更是一次关于构建“可信度”的修行。

开新坑了。这次，我想从零开始，用 Rust 认真地做一个原生的 Linux 性能分析工具链——PIPA-rs。这不仅是对经典 PIPA 项目的一次重塑，也是我个人在系统编程领域的一次深度探索。

但今天这第一篇，我们不聊 perf_event_open 的底层魔法，也不谈 /proc 文件系统的精妙。在写下第一行真正的业务逻辑之前，我想先聊聊那些“看不见”的东西：项目的工程化基础。

很多人（包括曾经的我）在开始一个新项目时，总是迫不及待地 cargo new 然后一头扎进 main.rs。但这次，我决定反其道而行之。我要为 PIPA-rs 搭建一个“世界级”的工程基础。这听起来有点空，甚至有点“过度工程”的嫌疑，但一个可靠的工具，必须诞生于一个可靠的摇篮。这个摇篮，关乎开发纪律、自动化，以及在未来漫长的迭代中，我们是否还能保持从容。

所以，这篇手记，就从我们的第一块基石开始：如何搭建一个“自律”的 Rust 项目框架，以及我们在 CI/CD 自动化之路上，踩过的那些坑和最终找到的光。

本次环境为Arch Linux，内核版本6.12.46-3-cachyos-lts，perf版本6.16-3

前言：从“健康报告”到“外科手术”

在上一篇文章《我的程序为什么慢？—— Perf CPU 性能剖析》中，我们学会了使用 perf stat。它就像一份体检报告，能告诉我们程序的整体健康状况——IPC 高不高、分支预测准不准。

但这还不够。如果报告说“指标异常”，我们并不知道问题出在哪个“器官”。perf stat 告诉我们程序慢了，但它没告诉我们慢在哪里。