谁的锅谁来背：团队边界 vs 平台边界，别再互相甩锅了

大家好，我是Echo_Wish。

我这几年做平台、带团队，踩过一个特别“经典”的坑——
系统出了问题，大家第一反应不是解决，而是找人背锅。

你一定见过这种场景：

运维：这不是我问题，是你代码有 bug
开发：环境不行，我本地跑得好好的
平台：我只提供基础能力，你们自己用错了
安全：你们压根没走规范流程

最后呢？

👉 问题没解决，群里吵了 200 条消息

说白了就一个原因：

👉 边界没划清楚

今天我们就把这事讲透：
团队边界 & 平台边界，到底谁该负责哪一层？

一、先说结论：没有边界，就没有责任

我先给你一句特别扎心但真实的话：

👉 没有边界的系统，一定是“责任稀释”的系统

你以为是“大家一起负责”，其实是：

👉 出事了 = 没人负责

二、经典错误：把平台当“全能保姆”

很多公司搞平台的时候，一开始的初心是好的：

👉 “我们做个平台，帮业务降本增效”

结果最后变成：

• 平台帮你部署
• 平台帮你排错
• 平台帮你改配置
• 平台甚至帮你写代码

👉 平台团队：人肉 Kubernetes + 人肉 DevOps

一个真实对话（你一定见过）

业务：帮我看看为什么 500 错误
平台：日志呢？
业务：没打日志
平台：？？？

三、正确认知：平台是“边界放大器”，不是“责任接盘侠”

平台的本质是什么？

👉 抽象能力 + 统一规范 + 限制自由度

不是替你干活。

四、我们来拆一套“清晰的边界模型”

我给你一个我自己总结的“三层责任模型”：

一句话总结：

👉 平台负责“路”，业务负责“开车”

五、用 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% 的问题，本质是“边界问题”

你可以技术很强，但如果：

• 权责不清
• 边界模糊

那你的系统一定会变成：

👉 谁都能改，谁都不负责

所以我现在越来越相信一句话：

👉 好的架构，不只是代码结构，更是“责任结构”

如果你现在团队已经开始出现：

• 扯皮
• 推责
• 平台过载

那不是人不行，而是：

👉 边界设计出问题了