翻到 8 年前自己在 V2EX 的回复，发现当年我真低估了 Git

今天偶然翻到自己 8 年前在 V2EX 的一条回复。那时有人讨论“公司还在用 SVN，会不会显得技术落后”，我在下面回了一句：作为运维来说，真心没感觉 SVN 和 Git 在实际业务环境上有啥差别。

现在看这句话，脸上会有点发烫。但如果把时间拉回 2018 年左右，当时的逻辑并不是完全不可理解。那时很多团队的发布方式很简单：代码进 SVN，Jenkins 拉下来，打包，测试环境过一遍，再顺次推到生产。运维最关心的是服务能不能起来、发布别挂、数据别丢、出事能不能回滚。

在这种人肉或半自动化发布时代，SVN 确实够用。那时我看到的 Git，只是另一个“存代码的仓库”。我没有真正看到它背后会长出来什么。

这些年回头看，Git 赢的从来不只是版本管理。它真正改变的是团队协作方式：GitHub、GitLab、Pull Request、Code Review、CI/CD、Infrastructure as Code、GitOps，一层一层叠起来，最后变成了现代软件工程默认的工作流。

大多数团队今天也未必每天都在用 Git 最炫的“分布式本地提交”能力。但很少有团队愿意回到没有 Code Review、没有自动化 CI、没有基于代码变更触发部署的时代。

当我后来在生产里高频接触 GitHub Actions、Terraform、ArgoCD 时，才彻底意识到：Git 早就不是一个代码管理工具了，它已经变成研发协作的空气和水。

当年我还补了一句：“高可用方案还是怎么简单怎么来吧。”这句话我到今天依然认。

干运维越久，越会发现技术先进和业务价值经常不是一回事。很多系统最后不是死于性能瓶颈，而是死于架构复杂度过高，团队没有足够的人力、经验和心智带宽去长期维护。

Kubernetes 当然很好，但两三个人的小团队、业务规模有限时，ECS 也许更稳。ClickHouse 集群当然强，但如果未来一年数据量并不会爆，先把单机和备份做好可能更实际。最好的架构不是最先进的架构，而是贴合团队能力、半夜出事也能被稳定接住的架构。

十几年过去，手里的工具换了一轮又一轮。刚工作时是 SVN、Jenkins、MySQL、Nginx；后来变成 Git、AWS、Cloudflare、Terraform；这几年又多了 AI Workflow、Agent、LLM 和新一代自动化工具。

工具会变，但运维要解决的底层命题几乎没有变：稳定性、可维护性、成本控制、自动化。真正值得沉淀的，不只是某个命令或某个配置，而是这些工具背后的判断标准。

所以我现在更愿意把“当时为什么这么选”“后来哪里看错了”“哪些原则依然有效”写下来。技术债不只存在于代码里，也存在于人的判断里。

这些年踩过的坑、背过的锅，最后都散落成脚本、检查工具、排障文档和自动化流程。有的在服务器角落，有的在私有仓库里，有的只存在于脑子里的经验判断。

OpsKitPro 的初衷很简单：把这些“过去用过、后来证明有用”的东西整理出来，变成一个干净、轻量、可复用的运维工具箱。它不是为了做一个大而全的工具站，而是把排障时真正高频、真正节省时间的动作收进一个地方。

如果这些整理能让自己少翻几次旧脚本，也能让另一个深夜排障的同行省下几分钟，那这件事就值得继续做下去。

接下来 OpsKitPro 会更明确地围绕“对过去经验的整理”来设计。工具不只是入口，文章也不只是内容营销；它们应该共同回答一个问题：一个 SRE 在真实排障、选型、发布和复盘中，如何把经验变成可复用的判断。

网站信息架构可以分成三条线：诊断工具用于快速确认事实，运维复盘用于解释判断如何形成，工程工作流用于把这些判断固化成流程。首页也应该更直接地表达这个定位：把过去的排障脚本、检查清单和运维经验整理成可复用的 SRE 工作台。

这样 OpsKitPro 就不是“又一个工具合集”，而是一个不断被整理、验证、修订的公开运维笔记本。工具负责快，文章负责深，历史复盘负责让判断越来越准。