CoreTeam 三年：内部系统这条路怎么走下来的
写在三年这个节点
2021 年春，我把 CoreTeam 内部运维平台这条线的 ownership 正式交接给下一任。从 2018 年 5 月接手，到 2021 年 4 月交出去，差一个月整三年。
三年这个长度不长不短，但够把一个”烂摊子”变成”能跑的系统”。前面七篇写了具体做了什么：资源盘点、CI/CD、ELK、权限审计、Terraform、ECS 编排。这一篇不写技术，写我自己走过的路、踩过的坑。
三年做完回头看，真正决定结果的，是当时怎么做选择的。
一、做对的事
1. 先盘点，再重构
接手时第一冲动是”上 K8s，全容器化”。我们没这么干，先花两周盘点资源、清理僵尸、打标签。
事后看这是最正确的决定之一。如果当时直接重构，会把一堆没人理解的资源一起搬掉，事故必然发生。重构的前提是看懂现状，否则就是赌博。
这条经验我后来反复跟新人讲：到一个新环境，前三个月不要想着”我要改什么”，先想”我能不能看懂现状”。看懂是改的前提。
2. 业务自助，运维退后
2018 年那一套 Jenkins + ECS 流水线最大的价值，不在于我们终于能发版了，而在于业务方能自己发版。
这一点决定了整个平台的边界。运维一直当”发布执行者”，团队规模永远是瓶颈：业务越多，运维越累，越容易出错。让业务自服务，运维才能从”打杂”变成”修路”。
后来 GitLab CI、GitHub Actions 接入都是延续这个思路：修路的人不管谁在路上开车，但要保证路平。
3. 把工具当”宪法”来执行
Terraform 那篇最后我说了一句：”工具有，执行力才是分水岭。”这一点三年走下来体会越来越深。
任何工具的”威力”都来自组织对其作为唯一真理来源的承认。Terraform 之所以在我们这里管用，不是因为 .tf 写得多漂亮，是因为所有人达成了共识：
- 任何 AWS 变更必须走 Terraform PR。
- Console 改的东西视为非法，drift 检测会查到。
- 生产环境禁止
terraform apply -auto-approve。
这种共识靠流程和文化建立，不靠技术。一旦形成，工具的力量才能释放出来。
4. 三套 CI 并存而不强行统一
前面写过，2020 年我们有 Jenkins + GitLab CI + GitHub Actions 三套。当时承受了不少”为什么不统一”的质疑。
回头看，不强行统一是对的。强推迁移的隐性成本（事故风险 + 培训成本）远超维持多套的开销。重要的是让它们协作：共享制品库、共享部署脚本、共享通知渠道。
多样性本身不是问题，协作不到位才是。
5. 日志先于 metrics
这个顺序很多人质疑——“为什么不一起做？”
答案很现实：资源有限，必须排优先级。日志能解答 80% 的业务问题（”为什么这个请求挂了”），metrics 只能告诉你”系统慢了”。先把日志做扎实，业务方立刻能用上，价值立竿见影。metrics 后面慢慢补，不耽误。
资源永远不够，所以”先做什么”比”做什么”更重要。选 ROI 最高的先做。
二、做错或者后悔的事
不能只讲好的，否则就是软文。
1. 早期文档投入严重不足
前半年我们一边踩坑一边搭系统，但没把决策过程记录下来。一年之后新人入职，问”为什么 ECS 用 awsvpc 而不是 bridge”，没人答得上来。
后来补这一课花了很多力气：每个关键决策都要写 ADR（Architecture Decision Record），哪怕只有几行：
1 | # ADR-007: ECS 网络模式选用 awsvpc |
ADR 这种东西写起来五分钟，省下来的”为什么当初这么定”的会议可能是五个小时。早该做。
2. 过度依赖”英雄员工”
某个核心系统一直是某个同事一个人维护，他离职时我们慌了一阵。单点知识等于单点故障，这个道理在运维里特别重要。
后来强制每个核心系统至少两人 familiar，code review 必须有外部人员参与。但这个教训是付出了代价才学到的。
3. 监控告警早期太粗
ELK 上线后我们一度觉得”日志够了”。但日志是被动查询，告警是主动通知。某次凌晨数据库连接数飙满，第二天早上才发现：日志里全是错误，但没人盯着看。
后来补了 CloudWatch alarm + Slack 集成，关键指标（5xx 率、数据库连接数、ECS task 重启次数）触发阈值立即告警。这件事应该在 ELK 上线的同时就做，而不是事后补。
4. 容器化早期没考虑成本
Docker 化一开始我们用了比较大的基础镜像（Ubuntu + 一堆工具），结果 ECR 存储费用和镜像拉取时间都不好看。后来切到 alpine 基础镜像，存储降了 80%，拉取速度快了一倍。
容器化的成本优化是后期才意识到的。早做这一步能省不少钱和不少发布时间。
三、关于”内部系统”这条路
写到这里，我想聊聊更宏观的话题：”内部系统”这件事到底算什么。
很多人对”内部系统”有误解，觉得是”给公司内部用的工具”，技术含量不高。这个看法是错的。
内部系统本质是个放大器：一个好的内部工具，能让十个人的团队发挥出五十个人的效率；一个差的内部工具（或者根本没有），会让五十个人的团队表现得像十个人。
CoreTeam 三年做的所有事情——资源管理、CI/CD、日志、权限、IaC、ECS 编排——都是在搭这个放大器。每一步看似解决的是技术问题，实际解决的是组织效率问题：
- 资源盘点 → 让账单透明，决策有依据。
- 自助发布 → 让业务自治，运维不卡脖子。
- ELK → 让排障从小时级到分钟级。
- 权限审计 → 让事故有迹可循。
- Terraform → 让变更可控可复现。
- ECS 编排 → 让扩缩容不需要人盯着。
内部系统的价值，从来不在于技术做得多牛，而在于让多少人因此而工作得更好。
四、给后来者的几句话
如果让我给做内部系统的后来者一句话的建议，我会说：
不要追新技术，要追”业务方的真实痛点”。
K8s 牛吗？牛。但如果你的业务规模没到那一步，ECS 完全够用。Service Mesh 高级吗？高级。但如果你只有十几个服务，它的复杂度反而是负担。
工具的价值是相对的，取决于它解决的问题。脱离业务谈工具，就是技术自嗨。
第二句话：重视文档和培训，不要做”隐形英雄”。
内部系统的成功标志不是”系统能跑”，是”大家会用”。一个没人用的内部工具，再牛也是失败。文档、培训、内部分享，这些”非技术”的事，往往比代码本身更重要。
第三句话：承认自己不会永远在，让系统能离开你跑下去。
三年交接的时候，最让我欣慰的不是”系统多牛”，而是”我走了它还能跑”。这才是内部系统该有的样子：不依赖任何一个人。
五、写在最后
CoreTeam 这三年，是我职业生涯里很重要的一段。
技术上学到了 Terraform、ECS、ELK、IAM、Cloud Map 这些具体的东西。但更重要的是学到了怎么在一个真实组织里，把一件事从无到有做出来：怎么权衡、怎么协作、怎么妥协、怎么坚持。
内部系统这条路没有终点。每一个阶段的”完成”，都是下一个阶段的”起点”。
我交接出去的不是一套完美的系统，而是一套有人接得住、改得动、跑得稳的系统。这就够了。
接下来我会把这些经验带到新的场景里去。下一段路，希望也能走得稳。
谢谢 CoreTeam。这三年值得。
