同样的服务，不同的要求
「快速搭建」系列教的是：你一个人 5 分钟能搞定一台机器。 进了团队，规则变了——不是技术更难，而是**"只你能搞"反而成了问题**。
三件事划开了边界
1. 可观测（Observability）
个人项目：服务挂了你重启就行；偶尔看看 tail -f。
团队场景：服务挂了几个客户在抱怨、CEO 在群里问、你在地铁上。这时候要的是：
- 任何人打开监控大盘 → 能看出现状
- 告警自动到 on-call 手里 → 不用挨个找人
- 历史数据 → 复盘能查到当时发生了什么
没有可观测 ≈ 服务在黑盒里跑，故障时间会被放大几倍。
2. 可审计（Auditability）
谁、何时、做了什么改动？为什么改？
- "我昨天 ssh 上去 vi 了一下 nginx.conf 改了 worker 数" — 个人 OK，团队是定时炸弹
- 团队要的是：改动走 git → PR Review → CI → 自动部署 → 留痕
- 这条链让 6 个月后的同事能回答"为什么这里这样配？"
合规要求（SOC2 / 等保等）的本质就是逼你做到这点。
3. 可交班（Bus-factor）
"如果今天你被车撞了，明天系统能继续跑吗？"（Bus factor = 1 是危险信号）
- 知识不能只在脑子里——写到 Runbook
- 操作不能只你会——脚本化、自动化
- 凭据不能只你有——密钥管理（密钥见 ops-corp/29-secrets）
心智转换
| 个人模式 | 团队模式 |
|---|---|
| 我能跑就行 | 任何人能上手 |
| 出问题我修 | 出问题任何 on-call 能修 |
| 改完就部署 | 改动有审计、有 review |
| 知识在我脑子 | 知识在 Runbook |
| 工具我熟就行 | 工具团队达成共识 |
不是某个工具突然变重要——而是协作的成本让"工具 + 流程"成为必需。
这一系列要回答什么
- 怎么把基础设施变成代码（IaC）
- 怎么让发布变成日常而不是惊魂
- 怎么把"你知道的事"变成"系统知道的事"
- 怎么和合规 / 安全 / 成本三件事共存
不假设你已经在大公司，假设你团队从 3 人长到 30 人这段路。
推荐阅读
- Google SRE Book — 整本免费在线，是 SRE 思想的圣经
- The DevOps Handbook — 把"DevOps 是什么"讲透
- Team Topologies — 团队结构如何影响系统结构
- Accelerate (DORA report) — 用数据回答"高效团队长什么样"
下一篇：SRE / DevOps / Platform Engineering 三个常被混用的概念到底什么关系。