为什么技术探索与实践？一个996福报享受者的血泪总结
上周五晚上10点半，我还在公司盯着K8s Dashboard里Pod不断CrashLoopBackOff的红点发呆。产品那边催着明天上线新功能，测试说压测还没过，运维在群里@我说“兄弟你这资源配额又超了”。那一刻我真的想砸电脑——但转念一想，电脑是公司的，砸了还得赔。
这大概就是我在这家公司待了三年多的真实写照：白天改需求，晚上调YAML，凌晨三点还在查ImagePullBackOff是不是因为私有仓库token过期了。但即便如此，我还是坚持每周抽时间搞点“不务正业”的事——比如研究Service Mesh、折腾GitOps流水线，甚至在周末技术分享会上讲讲自己踩过的坑。
很多人问我：“你都996了，哪来的时间学新技术？”
我的回答是：不是有时间才去探索，而是因为问题逼得你不得不探索。
起因：一个差点让双11崩掉的项目
去年双11前两周，我们接了个“紧急优化”项目：把核心交易服务从传统VM架构迁移到K8s。听起来很酷，对吧？但实际上，团队里除了我（勉强算个“云原生老油条”），其他人连kubectl get pods都打得磕磕绊绊。
更糟的是，老板拍板说：“必须上，而且要快！隔壁组都上Service Mesh了，咱们不能落后！” ——结果呢？我们连基础监控都没搭全，日志还散落在十多个Pod里，ELK集群三天两头OOM。
迁移第一天就翻车了。
一个看似简单的HTTP服务，在K8s里启动后，外部调用直接502。查了两个小时，发现是Ingress配置漏了servicePort。当时我真的想对着空气喊一句：“产品经理，你确定这叫‘简单重构’？”
但骂归骂，活还得干。我知道，如果只是照搬旧架构、换个容器跑，那迟早会出大事。技术探索不是为了炫技，而是为了活下去。
实践：从“能跑就行”到“稳如老狗”
我决定趁这次迁移，把几个一直想试但没机会落地的技术点塞进去：
- 用Helm统一部署模板（告别手写YAML地狱）
- 引入Prometheus + Grafana做可观测性
- 用ArgoCD实现GitOps，让发布可追溯
踩坑实录：Helm不是万能胶水
一开始我以为Helm能一键解决所有部署问题。结果第一个Chart就给我上了一课——开发环境能跑，预发环境死活连不上数据库。
后来发现是ConfigMap里的database.host写死了localhost。在VM时代这没问题，但在K8s里，每个环境的Service Name都不一样。于是赶紧改成通过values.yaml注入：
# values-prod.yaml
database:
host: mysql-prod.default.svc.cluster.local
port: 3306
并在Deployment里引用：
env:
- name: DB_HOST
value: {{ .Values.database.host }}
教训：别信“一套Chart走天下”，环境差异必须参数化。
可观测性：没有监控的系统等于裸奔
上线前三天，测试反馈“接口偶尔超时”。我第一反应是代码问题，结果查了半天逻辑，最后在Grafana里发现：Pod CPU throttling高达40%！
原来是我给容器设的requests.cpu=100m，但实际峰值要500m。K8s限流导致应用卡顿。赶紧调整：
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"
加完之后，P99延迟从1.2s降到200ms。那一刻我才真正理解什么叫“可观测性驱动优化”。
附：我们最终定的资源配额参考表（单位：CPU为核，内存为MiB）
| 环境 | requests.cpu | limits.cpu | requests.memory | limits.memory |
|---|---|---|---|---|
| dev | 100m | 500m | 256 | 512 |
| staging | 300m | 800m | 512 | 1024 |
| prod | 500m | 1000m | 1024 | 2048 |
GitOps：让发布不再靠人肉 kubectl apply
以前上线全靠手敲命令，谁敲错了谁背锅。有一次同事误删了生产Namespace，整个支付链路挂了半小时。运维差点提刀来办公室。
这次我强推ArgoCD。虽然初期被吐槽“又加一层复杂度”，但第一次用它回滚故障版本时，所有人闭嘴了——点一下UI，自动同步到Git里的上一个commit，10秒内恢复服务。
# argocd-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: trade-service
spec:
destination:
namespace: prod
server: https://kubernetes.default.svc
source:
path: manifests/prod
repoURL: https://gitlab.example.com/platform/trade-deploy.git
targetRevision: HEAD
syncPolicy:
automated:
prune: true
selfHeal: true
效果：发布失误率从每月3次降到0，审计也有了依据——谁改了什么，Git里一目了然。
技术分享：不是表演，而是救命稻草
很多人觉得技术分享是“浪费时间”，尤其对我们这种996选手。但恰恰相反——分享是我保持技术敏感度的唯一方式。
去年我在公司内部搞了个“K8s避坑指南”分享会，讲完第二天就有同事跑来问：“你那个Sidecar日志收集方案能借我抄抄吗？” 结果他用这个方案解决了他们组的ELK性能瓶颈。
更意外的是，有猎头听完我在线上Meetup的演讲后联系我：“看你对云原生理解挺深，要不要聊聊新机会？” ——没错，我现在已经在认真考虑换环境了。三年了，是时候离开这个“福报工厂”了。
技术分享的本质，是把个人经验变成团队资产，再把团队资产变成个人资本。
为什么坚持探索？因为躺平代价太大
有人说：“公司用啥你就用啥，学那么多干嘛？”
但现实很残酷：
- 你不用Service Mesh，线上链路追踪就得靠grep日志
- 你不搞自动化，半夜报警就得爬起来手搓YAML
- 你不了解新工具，跳槽面试连K8s调度原理都说不清
我见过太多同事，三年只会在Spring Boot里CRUD，结果裁员名单第一个就是他。而那些哪怕每天只花30分钟看篇文档、试个小工具的人，往往能在危机中找到新出路。
技术探索不是选择题，是生存题。
写在最后：给同样996的你一点建议
我知道你现在可能刚开完需求评审会，脑子里全是“这个需求不合理但得做”。但请相信，每天挤出一点点时间做技术实践，长期来看会省下你无数加班的夜晚。
我的“偷时间”技巧：
- 午休前15分钟：看一篇CNCF博客
- 下班地铁上：刷K8s官方Slack频道的问答
- 周末上午：跑一个本地Minikube实验（就当陪电脑散步）
别追求“学完所有”，只要解决眼前的问题。比如这次迁移，我其实只深入研究了Helm和ArgoCD，其他像Istio、Knative都没碰——够用就行。
最后送大家一句话，也是我工位贴的便签：
“你现在的每一个技术决策，都是未来深夜救火时的氧气面罩。”
共勉。
（写完这篇，我得去改第37版需求文档了……）
评论 0