OpsKitPro
16 posts

OpsKitPro
@OpsKitPro
10+ 年资深运维架构师。不盲从技术潮流,只解决核心四件事:稳定性、可维护性、成本与自动化。 https://t.co/xgumj9Jyt9 🛠 个人运维工具箱:https://t.co/qCSntOK4pg
ap-northeast-1 (Tokyo, Japan) Katılım Şubat 2026
101 Takip Edilen26 Takipçiler

翻到 8 年前自己在 V2EX 的回复,发现当年我真低估了 Git
今天偶然翻到了自己 8 年前在 V2EX 的一条回复。
当时社区里有人发帖讨论:“现在公司还在用 SVN,会不会显得技术很落后?”
而我当时在下面接了一句:
“作为运维来说,真心没感觉 SVN 和 Git 在实际业务环境上有啥差别。”
甚至嫌不够,还嘴硬地补充了一句:
“高可用方案还是怎么简单怎么来吧。”
看到这段话的时候,我的第一反应是脸上有点发烫——当年的自己,确实保守了。但靠在椅子上仔细想想,又觉得当年的逻辑其实也有时代的局限。
那时候,为什么我会这么想?
2018 年左右,我手里的活儿基本上是标准的三板斧:代码进了 SVN,Jenkins 滋溜一下拉下来,打个包,顺次往测试环境和生产环境一扔。
作为运维,那时候我们睁眼闭眼关心的就四件事:
服务能不能拉起来?
发布别挂了就行。
数据千万别丢。
万一出事,能不能一键回滚?
说实话,在这种纯粹的“人肉/半自动化”发布时代,SVN 确实够用了。开发老老实实提交,Jenkins 稳定构筑,代码往服务器一推,收工上线。
那时候在我眼里,Git 和 SVN 不就是个存代码的仓库吗?至于天天为了“分布式”吵得不可开交吗?
后来我才发现,我看错了行业,也看扁了 Git
这些年技术浪潮的大浪淘沙,狠狠抽了当年的我一个耳光。
我发现自己低估的根本不是 Git 这个工具本身,而是由它掀起的一场关于“研发效能”的革命。
当年我以为的对比,只是单纯的工具输赢(SVN VS Git)。但后来,行业直接把这两个字玩成了万物的起点:从 Git 衍生出 GitHub/GitLab,带来了 Pull Request 和 Code Review,紧接着焊死了 CI/CD 流水线,再往后,连基础设施都变成了 Infrastructure as Code,甚至演进成了今天的 GitOps。
Git 赢的从来不是版本管理,它赢的是整个软件工程的生态。
坦白讲,直到今天,大部分团队也未必真的需要 Git 那引以为傲的“分布式本地提交”能力。但现在的团队,有谁离得开 Code Review、自动化 CI、和基于代码变更触发的自动化部署?
当我后来在生产中高频接触 GitHub Actions、Terraform、ArgoCD 的时候,我才彻底醒悟:Git 早就不是一个代码管理工具了,它变成了一种研发的“空气和水”,一种现代协作的标准范式。
但有些当年的“保守”,今天看依然是真理
虽然在 Git 上我交了学费,但回头看当年说的那句——“高可用方案还是怎么简单怎么来吧”,我至今依然想给当年的自己点个赞。
这些年当运维,看过了太多潮起潮落:OpenStack、Mesos、Docker Swarm、Service Mesh……哪个当年不是风头无两?多少公司投入了海量的人力和架构成本去追逐。结果呢?大浪退去,最后真正留下来当家做主的,反而是 Linux、Nginx、MySQL、Git 这些看起来没那么炫、却扎实得像磐石一样的底层技术。
技术先进和业务价值,往往是两码事。
干运维越久,胆子越小。现在做技术选型,我脑子里跳出来的第一个问题不再是“它炫不炫”,而是“这玩意儿扔给团队,他们能不能稳稳当当维护五年?”
Kubernetes 还是 ECS? 先看团队有几个人。如果就两三只小猫,业务规模也有限,老老实实用 ECS 挺好。不是 K8s 不好,而是人肉维护它的复杂度本身就是一场灾难。
ClickHouse 要不要上集群? 先问问自己,未来一年我们的数据量真的会爆吗?
很多系统,最后都不是死于性能瓶颈,而是死于架构复杂度过高,最后自己把自己给玩塌了。最好的架构永远不是最先进的,而是最贴合团队能力的、能在深夜让你睡个安稳觉的架构。
从 SVN 到 AWS,再到如今的 AI
一晃十几年过去了,手里的家伙什儿变了一轮又一轮。
刚工作那会儿,技术栈简单干净:SVN + Jenkins + MySQL + Nginx。 后来,变成了 Git + AWS + Cloudflare + Terraform。 这几年,桌子上又堆满了 AI Workflow、Agent、LLM 和各种新一代自动化工具。
工具的花样层出不穷,但运维要解的底层命题,其实从十年前到现在一个都没变过:稳定性、可维护性、成本控制、自动化。
关于 OpsKitPro 的一点碎碎念
这些年在这条路上摸爬滚打,踩过的坑、背过的锅,最后都变成了我硬盘里散落的排查脚本、检查工具、运维文档和自动化流程。它们有的躺在某个角落的服务器里,有的塞在私有仓库里吃灰。
最近,我抽空把这些年攒下来的“老伙计们”慢慢整理了出来,做成了一个干净的小站,叫 OpsKitPro。
初衷挺自私的,就是想把自己平时排查故障、调优时高频用到的工具聚合在一起,省得自己到处找。但如果这些工具恰好也能帮某个正在深夜排障的同行省下几分钟,那这事儿就更值了。
小站地址在这,感兴趣的朋友可以去踩踩: 👉 opskitpro.com
写在最后
翻到当年那条 V2EX 的回复,我心里其实没有一丝尴尬,反而有一种莫名的庆幸。
我庆幸自己这 8 年来没有在一个自以为是的舒适圈里躺平,也庆幸自己至今还拥有“不断推翻过去判断”的勇气。
对于一个工程师来说,走弯路不可怕,看走眼也不可怕。最危险的是当年的预言错了,而你却活成了那个永远觉得自己没错的古董。
中文

翻到 8 年前自己在 V2EX 的回复,发现当年真低估了 Git。
当年我以为 SVN 和 Git 只是代码仓库的区别,后来才明白:Git 真正改变的是 PR、Code Review、CI/CD、IaC、GitOps 这一整套工程协作方式。
opskitpro.com/blog/underesti…

中文

OpsKitPro の UI は、あえて控えめにしています。
運用中や調査中に使うツールは、派手さよりも、状態が読みやすいことのほうが大事だと考えています。
opskitpro.com/blog/design-pr…
#UI設計 #Web開発 #個人開発
日本語

排障時に面倒なのは、確認ツールが足りないことよりも、ツールが分散していることでした。
DNS、IP、SSL、HTTP、CDN を行き来せず、必要な確認をひとつの場所で見られるように OpsKitPro を作っています。
opskitpro.com/blog/why-opski…
#運用 #Web開発 #個人開発
日本語

OpsKitPro を作りました。
DNS / IP / サイト診断 / JSON / WebSocket など、運用や開発中によく使う確認ツールをひとつにまとめています。
必要なときにすぐ使える軽いツール集です。
opskitpro.com
#個人開発 #Web開発 #運用
日本語

Annoyed by slow diagnostic tools, so I built OpsKitPro.
Zero logins. No bloat. Just instant DNS, IP, and site forensics built on Cloudflare edge.
Been using it for my own SRE work, now it's public. Break it & let me know: opskitpro.com
#buildinpublic #devops

English








