本文记录了将一台生产环境 GitLab 社区版 (CE) 从 v14.6.1 (2021 年) 跨越 4 个大版本，无损升级至最新稳定版 v18.5.0 极狐版 (JiHu) 的全流程。本次升级旨在解决旧版本安全漏洞、利用新版效能分析工具进行工作量量化，并实现架构现代化 (IaC)。
核心挑战：
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 告诉我们程序慢了，但它没告诉我们慢在哪里。
读到这里，你已经陪我走完了 rkyolo 从一个想法到一个功能完备的框架的全过程。但在这个故事开始之前，还有一段小插曲。它虽然只占了大概三个小时，却为后面所有的“顺利”铺平了道路，也算是一场有惊无险的“系统急救”演练。