谁的锅谁来背：团队边界 vs 平台边界，别再互相甩锅了
大家好，我是Echo_Wish。
我这几年做平台、带团队，踩过一个特别“经典”的坑——
系统出了问题，大家第一反应不是解决，而是找人背锅。
你一定见过这种场景：
运维：这不是我问题，是你代码有 bug
开发：环境不行，我本地跑得好好的
平台：我只提供基础能力，你们自己用错了
安全：你们压根没走规范流程
最后呢？
👉 问题没解决，群里吵了 200 条消息
说白了就一个原因：
👉 边界没划清楚
今天我们就把这事讲透：
团队边界 & 平台边界，到底谁该负责哪一层？
一、先说结论：没有边界，就没有责任
我先给你一句特别扎心但真实的话：
👉 没有边界的系统，一定是“责任稀释”的系统
你以为是“大家一起负责”，其实是：
👉 出事了 = 没人负责
二、经典错误：把平台当“全能保姆”
很多公司搞平台的时候，一开始的初心是好的：
👉 “我们做个平台，帮业务降本增效”
结果最后变成：
- 平台帮你部署
- 平台帮你排错
- 平台帮你改配置
- 平台甚至帮你写代码
👉 平台团队：人肉 Kubernetes + 人肉 DevOps
一个真实对话（你一定见过）
业务：帮我看看为什么 500 错误
平台：日志呢？
业务：没打日志
平台：？？？
三、正确认知：平台是“边界放大器”，不是“责任接盘侠”
平台的本质是什么？
👉 抽象能力 + 统一规范 + 限制自由度
不是替你干活。
四、我们来拆一套“清晰的边界模型”
我给你一个我自己总结的“三层责任模型”：
| 层级 | 谁负责 | 负责什么 |
|---|---|---|
| 基础设施层 | 平台团队 | 集群、网络、存储 |
| 平台能力层 | 平台团队 | CI/CD、调度、监控 |
| 应用层 | 业务团队 | 代码、配置、数据逻辑 |
一句话总结：
👉 平台负责“路”，业务负责“开车”
五、用 Kubernetes 举个最典型的例子
❌ 错误模式（边界混乱）
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
spec:
template:
spec:
containers:
- name: app
image: xxx
resources: {
}
问题在哪？
- 没有资源限制
- 没有健康检查
- 没有日志规范
然后业务说：
👉 “平台怎么不给我兜底？”
✅ 正确模式：平台定义“规则”，业务填“内容”
平台提供模板（或策略）：
# 平台侧约束（OPA / Kyverno）
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-resources
spec:
rules:
- name: check-resources
match:
resources:
kinds:
- Pod
validate:
message: "必须设置 resources"
pattern:
spec:
containers:
- resources:
limits:
memory: "?*"
业务写 Deployment：
resources:
limits:
memory: "512Mi"
cpu: "500m"
👉 这才是正确分工：
- 平台：制定规则
- 业务：遵守规则
六、CI/CD 是边界冲突的“重灾区”
很多公司 CI/CD 的现状：
👉 平台写 pipeline
👉 业务不会改
👉 出问题找平台
正确做法：平台给“脚手架”，业务负责“内容”
平台提供模板：
# .gitlab-ci.yml
stages:
- build
- deploy
deploy:
script:
- kubectl apply -f k8s.yaml
业务自己维护：
script:
- docker build -t my-app:v1 .
- docker push my-app:v1
👉 核心原则：
平台不替你发版，只提供“发版工具”
七、监控这块最容易“背锅”
经典场景：
业务报警了
运维第一时间被拉群
然后发现：
👉 业务代码死循环了
正确分层
平台负责：
- Prometheus / Grafana
- 指标采集
业务负责：
- 自定义指标
- 报警阈值
示例：业务必须暴露指标
from prometheus_client import Counter
request_count = Counter('request_count', 'Total Requests')
def handle_request():
request_count.inc()
👉 平台不会帮你写这个。
八、为什么很多团队边界划不清？
说点人话，其实就三个原因：
1️⃣ 怕“影响效率”
“算了，这次我帮你弄了吧”
结果：
👉 一次帮忙 → 永久依赖
2️⃣ KPI 错位
- 平台 KPI：稳定性
- 业务 KPI：交付速度
👉 天然冲突
3️⃣ 没有“拒绝机制”
平台团队不敢说：
👉 “这个不归我管”
九、我自己踩坑后的三条铁律
这些都是我用血换来的经验：
✅ 1. 所有能力必须“产品化”
不能是：
👉 “找某某同学帮你开权限”
必须是：
👉 自助化（Portal / API）
✅ 2. 默认拒绝，按需开放
就像安全设计一样：
👉 默认不允许，而不是默认放行
✅ 3. 文档就是边界
如果一件事没写清楚：
👉 那它一定会变成扯皮点
十、一个特别现实的建议
如果你现在团队很乱，我建议你做一件事：
👉 把所有“谁负责什么”写成一张表
比如：
| 事项 | 负责人 |
|---|---|
| 集群宕机 | 平台 |
| 应用报错 | 业务 |
| 数据错误 | 业务 |
| 网络策略 | 平台 |
然后：
👉 全员签字确认（很关键）
最后说点真心话
很多人以为：
👉 技术问题，用技术解决
但其实不是。
👉 90% 的问题，本质是“边界问题”
你可以技术很强，但如果：
- 权责不清
- 边界模糊
那你的系统一定会变成：
👉 谁都能改，谁都不负责
所以我现在越来越相信一句话：
👉 好的架构，不只是代码结构，更是“责任结构”
如果你现在团队已经开始出现：
- 扯皮
- 推责
- 平台过载
那不是人不行，而是：
👉 边界设计出问题了
