KnoAI 技术站

主题

22 — 软技能与架构设计深度教材 ​

技术决定下限，软技能决定上限。本章覆盖故障报告方法论、容量规划、技术方案设计、团队协作与 Mentoring。

1. 故障分析与根因定位 ​

1.1 故障报告方法论（5 Why + 时间线） ​

markdown
# 故障报告模板

## 摘要
- 影响时间：2026-08-24 10:00 ~ 10:45（45 分钟）
- 影响范围：生产环境 web-app 服务不可用
- 影响用户：约 5000 活跃用户

## 时间线
| 时间 | 事件 |
|------|------|
| 10:00 | 监控告警：web-app 5xx 错误率 >50% |
| 10:05 | On-Call 工程师响应 |
| 10:10 | 确认：所有 web-app Pod CrashLoopBackOff |
| 10:15 | 发现：MySQL 连接池耗尽 |
| 10:20 | 回滚到上一版本 |
| 10:30 | 服务恢复 |
| 10:45 | 确认稳定 |

## 5 Why 根因分析
1. Why: web-app 返回 5xx
   → 应用无法连接 MySQL
2. Why: MySQL 拒绝连接
   → 连接池耗尽（max_connections=100）
3. Why: 连接数突然增加
   → 新版本代码存在连接泄漏
4. Why: 连接泄漏未被发现
   → 测试环境连接池配置不同（max=1000）
5. Why: 环境配置不一致
   → 缺乏配置一致性管理（根本原因）

## 改进措施
| 措施 | 负责人 | 截止日期 |
|------|--------|----------|
| 添加连接池监控 | SRE | 1 周 |
| 统一环境配置管理 | DevOps | 2 周 |
| 添加连接泄漏检测 | Dev | 1 周 |
| 生产前压力测试 | QA | 持续 |

1.2 根因定位方法 ​

USE 方法（资源排查）：
  Utilization（使用率）→ 资源被使用了多少？
  Saturation（饱和度）→ 资源排队了多少？
  Errors（错误）→ 资源出错了多少？

RED 方法（服务排查）：
  Rate（请求率）→ 每秒多少请求？
 Errors（错误率）→ 每秒多少错误？
 Duration（延迟）→ 每个请求花了多久？

四个黄金信号（Google SRE）：
  Latency（延迟）→ 区分成功/失败请求的延迟
  Traffic（流量）→ 系统需求量
  Errors（错误）→ 请求失败率
  Saturation（饱和度）→ 资源使用率

2. 容量规划与成本优化 ​

2.1 容量规划方法 ​

bash
# 1. 资源基线收集（至少 30 天数据）
kubectl top nodes                  # 当前使用
kubectl top pods -A --sort-by=cpu  # 按 CPU 排序

# 2. Prometheus 查询历史数据
# 过去 30 天 CPU 峰值
max_over_time(sum(rate(container_cpu_usage_seconds_total{namespace="production"}[5m])) by (pod)[30d:])

# 3. 容量计算公式
# 目标容量 = 峰值需求 × 安全系数（1.3-1.5）× 冗余系数（N+1）
# 
# 示例：
# 峰值 CPU = 50 cores
# 安全系数 = 1.3
# N+1 冗余 = 需要容忍 1 节点故障
# 目标容量 = 50 × 1.3 = 65 cores
# 16 core 节点：ceil(65/16) + 1 = 6 节点

2.2 成本优化策略 ​

成本优化层次：

Level 1（快速见效）：
  - 清理未使用的 PV/PVC
  - 清理僵尸 Pod（非 Running 状态）
  - 降低过度分配的 requests/limits
  - 关闭非工作时间的开发/测试环境

Level 2（中期）：
  - VPA 建议合理的 requests
  - HPA 自动缩容非高峰期
  - Spot/竞价实例用于无状态工作负载
  - 节点池分层（按需 + Spot）

Level 3（长期）：
  - Karpenter 替代 Cluster Autoscaler（更智能的节点选择）
  - 资源利用率目标（SLO）：CPU > 60%，内存 > 70%
  - FinOps 文化：每个团队对自己的云成本负责
yaml
# Karpenter 配置（智能节点供给）
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: general-purpose
spec:
  template:
    spec:
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]    # 优先 Spot，不够用 On-Demand
      - key: kubernetes.io/arch
        operator: In
        values: ["amd64", "arm64"]       # 支持 ARM 降低成本
  limits:
    cpu: "1000"
    memory: 2000Gi
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h    # 节点 30 天后自动替换

3. 技术方案设计 ​

3.1 设计文档模板 ​

markdown
# 技术方案：K8s 集群高可用架构升级

## 背景与目标
当前集群单点架构，控制面可用性 99.5%，目标提升至 99.95%

## 方案设计
### 架构图
[控制面 HA 架构图]

### 关键决策
| 决策点 | 选项 A | 选项 B | 选择 | 理由 |
|--------|--------|--------|------|------|
| etcd 部署 | stacked | external | external | 独立扩展，故障隔离 |
| LB 方案 | keepalived | 云 LB | 云 LB | 托管服务，免运维 |
| 节点数量 | 3 | 5 | 5 | 容忍 2 节点故障 |

## 风险评估
| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|----------|
| etcd 迁移数据丢失 | 低 | 高 | 迁移前快照备份 |
| 切换期间服务中断 | 中 | 高 | 滚动升级，PDB 保护 |

## 实施计划
| 阶段 | 任务 | 负责人 | 时间 |
|------|------|--------|------|
| 1 | 搭建新控制面 | SRE | 第 1 周 |
| 2 | 数据迁移 | SRE | 第 2 周 |
| 3 | 流量切换 | SRE | 第 3 周 |
| 4 | 验证与清理 | SRE | 第 4 周 |

3.2 面试架构设计题 ​

Q: 设计一个支持 10000 Pod 的 K8s 集群

控制面：
  - 5 个 etcd 节点（NVMe SSD，16GB RAM）
  - 3 个 apiserver（负载均衡）
  - kube-proxy IPVS 模式

网络：
  - Calico BGP 模式（无封装，性能好）
  - CoreDNS + NodeLocal DNSCache
  - 每个节点 110 Pod，约 100 节点

存储：
  - Ceph 集群（3 MON + N OSD）
  - RBD CSI Driver
  - 本地 SSD 用于缓存类应用

调度：
  - topologySpreadConstraints 跨区分布
  - PDB 保护关键服务
  - Cluster Autoscaler 按需扩缩

监控：
  - Prometheus 分片 + Thanos 长期存储
  - Loki + Fluent Bit 日志
  - Grafana 看板三层

安全：
  - NetworkPolicy 零信任
  - Pod Security Standards Restricted
  - Falco 运行时检测
  - Trivy 镜像扫描

4. 团队协作与 Mentoring ​

高效运维团队的特征：

1. 知识共享
   - 文档化：所有操作流程写入 Runbook
   - 轮岗：定期轮换 On-Call 和项目负责人
   - Tech Talk：每周 30 分钟技术分享

2. On-Call 管理
   - 主 On-Call + 副 On-Call（备份）
   - 轮转周期：1 周（避免倦怠）
   - On-Call 交接：书面交接 + 15 分钟会议
   - 补偿：On-Call 津贴 + 次日调休

3. Mentoring
   - 新人 90 天计划：基础 → 独立 → 项目
   - 代码 Review：所有变更必须 Review
   - Pair Programming：复杂问题结对解决
   - 故障演练：定期 GameDay，新人主导

4. 沟通效率
   - 日常：Slack/钉钉群组，非紧急不打电话
   - 紧急：电话 + 战时群组
   - 决策：ADR（Architecture Decision Record）
   - 复盘：Blameless Postmortem（无责复盘）

5. 面试高频问题 ​

Q: 描述你处理过的最严重的故障

STAR 方法回答：
S（Situation）：描述背景（什么系统、什么时间、什么影响）
T（Task）：你的角色和责任
A（Action）：你具体做了什么（排查步骤、决策过程）
R（Result）：结果如何（恢复时间、改进措施、学到的经验）

关键点：
- 展示系统性思维（不是临时打补丁）
- 展示沟通能力（如何协调团队、如何向上汇报）
- 展示学习能力（事后复盘、长期改进）

Q: 如何推动一个技术改进项目？

1. 量化问题（数据说话：故障次数、恢复时间、成本）
2. 调研方案（至少 2 个方案对比）
3. 写设计文档（架构、风险、实施计划）
4. 小范围试点（一个团队/一个服务）
5. 展示成果（前后对比数据）
6. 全面推广（培训、文档、自动化）