技术治理与变革管理练习册
通过练习掌握技术标准、技术债管理和组织变革推动方法。
难度分级
- 🟢 基础：理解概念。
- 🟡 进阶：能制定标准和推动变革。
- 🔴 深入：能设计完整治理体系。
一、选择题
第 1 题（🟢）
技术治理的核心目标是？
A. 限制创新
B. 在创新和规范间平衡，提升协作效率
C. 增加审批流程
D. 减少技术人员
第 2 题（🟢）
技术债登记册的主要作用是？
A. 记录bug
B. 可视化和管理技术债
C. 替代代码注释
D. 统计代码行数
第 3 题（🟢）
以下哪项不属于技术债的类型？
A. 代码债务（Code Debt）
B. 架构债务（Architecture Debt）
C. 人力债务（Headcount Debt）
D. 测试债务（Test Debt）
第 4 题（🟢）
ADR（Architecture Decision Record）的主要用途是？
A. 记录每日站会内容
B. 记录架构决策的背景、方案和理由
C. 替代技术文档
D. 记录代码行数变更
第 5 题（🟡）
以下哪项不是技术治理的常见领域？
A. 架构治理
B. 代码治理
C. 员工考勤
D. 安全治理
第 6 题（🟡）
推动技术变革时，第一步应该？
A. 强制所有人执行
B. 找到痛点并建立共识
C. 购买新工具
D. 立即全面推广
第 7 题（🟡）
在制定技术标准时，以下哪种做法最有效？
A. 由架构师独立制定后直接发布
B. 跨团队协作起草，经 RFC 评审后试行
C. 全盘采用业界最新标准
D. 由管理层直接指定
第 8 题（🟡）
变更管理流程中，变更咨询委员会（CAB）的主要职责是？
A. 审批所有代码变更
B. 评估和审批高风险的变更请求
C. 代替开发团队编写代码
D. 拒绝所有变更以维持稳定
第 9 题（🟡）
技术治理中的"三项防线"模型指的是？
A. 开发、测试、运维
B. 管理层、业务层、技术层
C. 业务部门、风险管理部门、内部审计部门
D. 前端、后端、数据
第 10 题（🔴）
技术标准的生命周期通常是？
A. 提案 → 评审 → 试行 → 正式发布 → 监督 → 复审
B. 领导决定 → 发布 → 结束
C. 写文档 → 发邮件 → 完成
D. 不需要生命周期
第 11 题（🔴）
在衡量技术治理有效性时，以下哪项指标最不适合？
A. 技术债比率（Tech Debt Ratio）
B. 架构合规率
C. 工程师离职率
D. 变更失败率
第 12 题（🔴）
成本优化中，"FinOps"文化的核心原则是？
A. 所有成本由财务部门控制
B. 团队自主管理云成本，实时反馈和持续优化
C. 无限预算
D. 完全禁止使用云服务
二、场景分析题
第 13 题（🟢）
团队代码风格混乱，导致 Code Review 效率低。如何推动统一代码规范？
第 14 题（🟡）
一个遗留系统技术债严重，业务又需要持续迭代。如何制定偿还计划？
第 15 题（🟡）
项目中有多项技术债积累，需求排期紧张，如何确定技术债的优先级？
第 16 题（🟡）
公司要从 Vue 2 迁移到 Vue 3，涉及 10 个团队。请设计变革管理方案。
第 17 题（🔴）
两个团队在同一个产品中使用了不同的状态管理方案（Redux vs. MobX），导致维护成本上升。如何处理架构分歧？
第 18 题（🔴）
云服务成本在过去三个月内翻倍，管理层要求紧急优化。请制定成本危机应对方案。
第 19 题（🔴）
公司正筹备 SOC 2 合规审计，工程团队需要体系化整改。请设计合规准备方案。
三、设计/开放题
第 20 题（🟡）
为一个前端团队设计代码规范治理方案，包括制定、推广、监督、迭代。
第 21 题（🟡）
设计一个技术债登记册模板，并说明如何使用它做决策。
第 22 题（🟢）
为一个中型团队设计技术债分阶段偿还计划，列出每个阶段的目标和关键动作。
第 23 题（🔴）
设计一个跨团队的技术标准制定流程，确保标准既合理又能被接受。
第 24 题（🔴）
设计一个完整的架构评审流程，涵盖评审触发条件、参与者、评审内容和决策机制。
第 25 题（🔴）
为企业设计一个技术治理框架，包含组织架构、标准体系、评审机制、度量指标和持续改进机制。
参考答案
第 1 题
查看答案与解析
答案：B
技术治理在创新和规范之间找到平衡，提升协作效率。
第 2 题
查看答案与解析
答案：B
技术债登记册用于可视化和管理技术债。
第 3 题
查看答案与解析
答案：C
技术债常见类型包括代码债务、架构债务、测试债务、文档债务等，人力债务不属于技术债范畴。
第 4 题
查看答案与解析
答案：B
ADR（Architecture Decision Record）记录架构决策的背景、方案、理由和后果，是架构治理的重要工具。
第 5 题
查看答案与解析
答案：C
员工考勤不属于技术治理领域。
第 6 题
查看答案与解析
答案：B
推动变革应先找到痛点并建立共识。
第 7 题
查看答案与解析
答案：B
最有效的标准制定方式是跨团队协作起草，经过 RFC 评审和试行，确保标准既有技术合理性又能被团队接受。
第 8 题
查看答案与解析
答案：B
变更咨询委员会（CAB）负责评估和审批高风险变更，确保变更经过充分评审，降低对生产环境的影响。
第 9 题
查看答案与解析
答案：C
"三道防线"模型源自风险管理领域，第一道防线是业务部门（承担日常风险），第二道是风险管理部门（监控和指导），第三道是内部审计（独立评估）。
第 10 题
查看答案与解析
答案：A
技术标准应经过提案、评审、试行、发布、监督、复审。
第 11 题
查看答案与解析
答案：C
工程师离职率受多种因素影响，不适合作为技术治理有效性的直接指标。更合适的指标包括技术债比率、架构合规率、变更失败率等。
第 12 题
查看答案与解析
答案：B
FinOps 是一种云财务管理文化，核心原则是让工程团队自主管理云成本，通过实时数据和反馈实现持续优化，而不是由财务部门集中控制。
第 13 题
查看答案与解析
参考思路：
- 成立规范小组，调研现状和团队意见。
- 制定规范并配套 ESLint/Prettier 配置。
- 提供 IDE 插件和自动化修复脚本。
- 纳入 CI 检查，逐步推广。
- 定期收集反馈并迭代。
第 14 题
查看答案与解析
参考思路：
- 梳理技术债清单，评估影响和成本。
- 与业务方协商，在每个迭代中分配固定比例时间偿还。
- 优先偿还阻塞新功能的高影响债务。
- 建立监控，防止新增债务。
第 15 题
查看答案与解析
参考思路： 优先级评估矩阵：
- 影响范围：该技术债影响了多少团队或用户？
- 业务风险：是否可能导致故障、安全漏洞或合规问题？
- 偿还成本：修复需要多少工作量？收益是否大于成本？
- 债务利息：不偿还的长期成本（维护复杂度、开发速度下降）。
分类策略：
- P0（立即处理）：导致生产故障或安全漏洞。
- P1（本季度处理）：显著降低开发效率或增加维护成本。
- P2（本年度处理）：影响较小但长期积累有风险。
- P3（持续关注）：低优先级，定期重估。
第 16 题
查看答案与解析
参考方案：
- 成立迁移委员会，制定总体计划和里程碑。
- 先试点 1-2 个团队，积累经验。
- 提供迁移工具、文档和培训。
- 设立答疑渠道和内部分享。
- 分阶段推进，允许并行运行。
- 庆祝早期胜利，激励其他团队。
第 17 题
查看答案与解析
参考方案：
- 架构分析：评估两种方案的优缺点、团队技术能力、迁移成本。
- 建立共识：组织架构评审会，邀请双方团队陈述方案优劣。
- 决策方案：
- 方案 A：统一为一种方案，制定迁移计划。
- 方案 B：在新模块中统一技术选型，已有模块按计划迁移。
- 方案 C：允许共存，但明确边界和通信规范（如使用微前端隔离）。
- 制定标准：将决策记录为 ADR，明确选择理由和适用范围。
- 执行和监督：纳入架构合规检查，避免再次出现类似分歧。
第 18 题
查看答案与解析
参考方案：
- 成本分析（第 1 周）：
- 按服务、团队、环境（开发/生产）维度拆分账单。
- 识别成本异常增长的服务和资源。
- 紧急止血（第 2-3 周）：
- 清理未使用的资源（闲置实例、未挂载的存储卷）。
- 对非生产环境设置预算上限和自动关停策略。
- 启用成本监控告警。
- 中短期优化（第 1-3 个月）：
- 引入预留实例/节省计划，降低按需实例成本。
- 应用自动扩缩容策略。
- 优化存储层级（冷数据迁移到低成本存储）。
- 长期机制：
- 建立 FinOps 文化：给每个团队成本预算，实时可见。
- 将成本纳入架构评审指标。
- 每季度成本复盘会议。
第 19 题
查看答案与解析
参考方案：
- 差距分析：
- 对照 SOC 2 信任原则（安全、可用性、处理完整性、保密性、隐私），识别差距。
- 体系建设：
- 制定安全策略和流程文档。
- 建立变更管理、访问控制、监控告警、事件响应流程。
- 技术整改：
- 实施日志审计和集中监控（SIEM）。
- 启用加密（传输中、静态）。
- 加固 CI/CD 流水线安全。
- 证据收集：
- 自动化收集合规证据（日志、审批记录、监控数据）。
- 保留至少 6 个月的审计历史。
- 预审整改：
- 内部模拟审计，发现漏洞并修复。
- 正式审计：
- 配合审计师，提供证据和说明。
第 20 题
查看答案与解析
参考方案：
- 制定：小组起草，团队评审。
- 推广：培训、文档、工具链集成。
- 监督：CI 检查、定期审计。
- 迭代：收集反馈，每季度复审。
第 21 题
查看答案与解析
参考模板：
| 债务项 | 类型 | 影响 | 估算成本 | 优先级 | Owner | 计划偿还时间 | 状态 |
|---|---|---|---|---|---|---|---|
| 组件 X 无单元测试 | 测试债 | 高风险 | 3 人天 | P0 | 张三 | 2026-Q3 | 进行中 |
使用方式：
- 每季度 Review，根据业务节奏排期。
- 决策依据：优先级 = 影响 × 业务紧迫度 / 偿还成本。
- 跟踪偿还进展，防止新增债务。
第 22 题
查看答案与解析
参考方案： 第一阶段（0-3 个月）：紧急止血
- 盘点全部技术债，建立登记册。
- 优先修复 P0/P1 级别的债务（生产安全、阻塞开发流程）。
- 在迭代中固定分配 20% 的容量用于还债。
第二阶段（3-6 个月）：系统还债
- 按模块分批偿还中优先级债务。
- 建立自动化工具（Lint、SonarQube）防止新增。
- 培养团队还债意识，建立技术债文化。
第三阶段（6-12 个月）：长效机制
- 定期技术债 Review（每季度）。
- 将技术债管理纳入开发流程（Definition of Done）。
- 度量技术债比率趋势，设定健康目标值（如 < 5%）。
第 23 题
查看答案与解析
参考流程：
- 识别问题，收集各团队痛点。
- 起草标准草案，明确目的、范围、内容。
- RFC 评审，邀请相关团队参与。
- 试行 1-2 个月，收集反馈。
- 正式发布，纳入 CI/CD。
- 每季度复审，持续优化。
第 24 题
查看答案与解析
参考方案：
评审触发条件：
- 新项目或新模块启动。
- 引入新的技术栈或框架。
- 重大架构变更（模块拆分、数据迁移、微服务化）。
- 出现严重架构问题或技术债积累到阈值。
评审参与者：
- 架构评审委员会（Architecture Review Board, ARB）：由资深架构师和技术 Lead 组成。
- 提案团队：提出变更的团队。
- 关联团队（可选）：受影响的上下游团队。
评审内容：
- 业务需求和技术背景。
- 方案设计（含 ADR）：备选方案对比和选择理由。
- 影响分析：对现有系统、团队、安全、性能的影响。
- 风险和缓解措施。
- 实施计划和回退方案。
决策机制：
- 投票制（每人一票），简单多数通过。
- 关键决策（如架构范式变更）需要 2/3 多数。
- 决策结果记录为 ADR，存档可追溯。
- 设有申诉机制：被否决的提案可在补充材料后重新提交。
第 25 题
查看答案与解析
参考方案：
1. 组织架构：
- 技术委员会：制定战略方向，审批顶层标准。
- 架构评审委员会（ARB）：评审重大架构决策。
- 领域 SIG（Special Interest Group）：各技术领域（前端、后端、数据、安全）的专题小组。
- 技术 Owner（TLO）：在各团队内推动治理落地。
2. 标准体系：
- 架构标准：技术选型原则、模块划分规范、API 设计规范。
- 代码标准：编码规范、Lint 规则、模板项目。
- 安全标准：认证授权、数据加密、漏洞处理。
- 运维标准：部署流程、监控告警、灾备方案。
- 数据标准：数据模型设计、数据分类分级。
3. 评审机制：
- 架构评审（重大变更必须经过 ARB）。
- 代码评审（Code Review 是强制门禁）。
- 安全评审（定期的安全审计和渗透测试）。
- 成本评审（新服务上线前评估成本影响）。
4. 度量指标：
- 治理覆盖度：多少领域有明确标准。
- 合规率：代码/架构与标准的偏差率。
- 技术债比率：修复技术债的估算工时 vs. 总代码量。
- 变更成功率：发布后无事故的比例。
- 治理满意度：团队对治理体系的满意度调研。
5. 持续改进机制：
- 每季度治理复盘会议，收集改进建议。
- 标准定期复审（至少每年一次）。
- 团队满意度调查（年度）。
- 外部对标（参考行业最佳实践）。
标签：#tech-governance #change-management #technical-debt #architecutre-review #compliance
最后更新：2026-07-06