技能介绍

解决什么问题

团队在规模化过程中常撞上几类反复出现的难题：OKR 写完就搁置，目标与日常执行脱节；代码散落在多个仓库，跨团队的原子性变更难以落地；发布决策依赖资历判断而非数据；线上故障复盘滑向互相追责。这套技能针对的正是这些失效场景——它把 Google 在 20 亿行代码、单日 86,000+ 次提交的规模下沉淀的工程实践，整理成一套可对照执行的工作框架。

核心能力与工作方式

技能围绕五个方向展开：

OKR 驱动开发：用 Objectives and Key Results 对齐目标，每个任务都能追溯到具体指标
Monorepo 管理：基于 trunk-based development，配合 OWNERS 文件明确代码归属，提交保持原子性
SRE 实践：以错误预算（error budget）替代对绝对稳定的追求，故障复盘坚持 blameless
规模优先架构：按 10x 增长场景做设计推演，而非只覆盖当前流量
数据驱动决策：功能上线需经 A/B 测试与量化验证

执行按四个阶段推进：需求梳理 → 方案规划 → 落地实施 → 结果校验，每阶段都有明确的完成标准，未达标则回退到上一步。关键决策采用加权评分模型，质量权重 30、效率 25、准确性 25、安全性 20，综合分低于 70 直接停止。

适用边界

这套框架诞生于超大规模单体仓库环境，并非所有团队都适配。每日数万次提交与单体仓的前提是成熟的自动化测试和严格 review 文化，缺少这两项而照搬 trunk-based 开发，只会让主干变得脆弱。内部工具 Piper、Blaze、Critique 需替换为开源或云端等效方案（Git、Bazel、Gerrit 等），抽象层会引入迁移成本。70-20-10 这类规则源自特定公司的历史背景，不宜当作普适公式。风险矩阵的分级和 SLO 目标值同样需要结合业务实际重新校准。