Staff Engineer 的技术领导力与影响力扩展策略

自我诊断问题
============================================

1. 我喜欢在一个团队里深耕
   -> Yes: Tech Lead 倾向

2. 我关心多个团队之间的技术一致性
   -> Yes: Architect 倾向

3. 解决"看似不可能"的技术问题让我兴奋
   -> Yes: Solver 倾向

4. 我想理解并影响整个组织的方向
   -> Yes: Right Hand 倾向

注意:原型不是固定不变的。它会随职业阶段和组织情况而变化。

# RFC:引入订单服务事件溯源

## 元数据

- 作者:Youngju Kim
- 状态:审阅中
- 创建日期:2026-03-01
- 审阅人:Seojun Park、Minha Lee、Dayun Jung
- 决策截止日期:2026-03-14

## 摘要

将订单服务的状态管理从当前的 CRUD 方式迁移到事件溯源(Event Sourcing),
以满足订单历史追踪与审计日志的要求。

## 动机

1. 金融监管合规:订单状态变更历史需保留 5 年
2. 客户支持:需要准确回答"订单为什么被取消?"这类问题
3. 分析:订单漏斗分析需要细粒度的事件数据

## 提议的设计

(具体的技术设计内容)

## 备选方案分析

### 备选方案 1:CDC(Change Data Capture)+ 独立历史表

- 优点:现有代码改动最小
- 缺点:历史与当前状态之间难以保证一致性

### 备选方案 2:引入审计日志库

- 优点:实现简单
- 缺点:无法重放事件,只能保留部分历史

### 备选方案 3:事件溯源(已选定)

- 优点:完整历史、事件重放、时间旅行查询
- 缺点:学习曲线陡峭,需要额外构建读模型

## 实施计划

- 阶段 1(2 周):搭建事件存储基础设施
- 阶段 2(3 周):将订单创建/修改迁移到事件溯源
- 阶段 3(2 周):构建读模型(CQRS)
- 阶段 4(1 周):迁移现有数据

## 风险

1. 团队学习曲线(缓解:开展 2 次事件溯源工作坊)
2. 读取性能可能下降(缓解:通过 CQRS 分离读模型)
3. 运维复杂度上升(缓解:搭建事件存储监控看板)

## 未决事项

- 事件存储选型:EventStoreDB 还是 PostgreSQL + Outbox 模式
- 事件模式演进策略(upcasting 还是 versioning)

# ADR-042:选择 JWT 作为 API 认证方式

## 状态

已批准(2026-03-10)

## 背景

需要统一微服务之间的 API 认证方式。
目前各服务混用 API Key、Session、JWT 等方式,
给安全审计和调试带来困难。

## 决策

采用 JWT(JSON Web Token)作为服务间通信的标准认证方式。

- 令牌签发:Auth 服务(基于 Keycloak)
- 令牌验证:各服务基于公钥在本地验证
- 令牌有效期:Access Token 15 分钟,Refresh Token 7 天

## 结果

- 正面:认证方式统一,消除了服务间调用对 Auth 服务的瓶颈
- 负面:令牌失效不会立即生效(需等到过期)
- 中性:每个服务都需要新增 JWT 验证中间件

## 备选方案

- API Key:简单,但密钥管理复杂,难以做细粒度权限控制
- mTLS:安全性强,但证书管理开销大
- OAuth2 Opaque Token:对 Auth 服务的依赖度高

普通资深工程师的代码评审:
  "把这个函数名从 getUser 改成 fetchUserById 吧。"

Staff Engineer 的代码评审:
  "这个函数做的是 DB 查询,所以用 fetch 前缀会更合适。
   我们团队的约定是:纯计算用 get/compute,涉及 I/O 就用
   fetch/load 前缀。要不要把这个约定写成 ADR 文档化一下?
   相关示例:payment-service 里的 fetchOrderHistory"

1:1 辅导结构(双周一次,30 分钟)
============================================

5 分钟  - 近况确认:"最近什么事最有挑战性?"
10 分钟 - 技术深度:讨论当前工作中的技术难题
10 分钟 - 职业成长:回顾长期目标与当前所处的位置
5 分钟  - 行动项:整理到下次见面前要做的事

导师应该做的事:
  - 用提问引导思考,而不是直接给答案
  - 坦诚分享自己失败的经历
  - 根据学员的成长阶段调整难度

导师不该做的事:
  - 替学员完成工作
  - 把自己的职业路径当作唯一正确答案来展示
  - 把辅导内容分享给学员的直属上级(破坏信任)

不好的说法:
  "测试覆盖率太低了,需要重构。"

好的说法:
  "目前支付模块的测试覆盖率是 30%。
   上个季度 3 起支付相关事故中,有 2 起发生在没有测试
   覆盖的代码路径上。每起事故的业务影响平均是
   2 小时服务中断,以及约 500 万韩元的营收损失。
   花 2 周时间补齐测试,预计可以把事故率降低 60%。"

                  业务影响高
                        |
    Q2: 计划性偿还      |     Q1: 立即偿还
    (纳入下季度路线图)  |     (纳入当前 Sprint)
                        |
  ──────────────────────┼──────────────────────
                        |
    Q4: 接受            |     Q3: 渐进式改进
    (维持现状)          |     (童子军规则)
                        |
                  业务影响低

  左侧:变更频率低    右侧:变更频率高

学习文化的实践方法
============================================

每周:
  - Tech Talk(30 分钟):团队成员轮流分享感兴趣的技术
  - 代码评审 Power Hour:全体团队一起评审重要的 PR

每月:
  - 技术书籍读书会
  - 事故复盘会(分享 postmortem)
  - 黑客松或 Innovation Day

每季度:
  - 技术雷达更新(Adopt/Trial/Assess/Hold)
  - 职业成长 1:1(经理 + Staff Engineer)
  - 参加外部会议并在内部分享

资深 -> Staff 转型所需的能力变化
============================================

需要做得更多:
  + 超越团队边界的技术影响力
  + 文档化的技术决策(RFC/ADR)
  + 组织层面的技术问题解决
  + 支持初级/中级工程师的成长
  + 理解业务背景并与技术战略相连接

可以少做一些:
  - 亲自编写所有代码
  - 掌握所有技术细节
  - 参与每一次代码评审

绝对不能丢掉的:
  ! 保持编码能力(hands-on 比例 30~50%)
  ! 学习技术趋势
  ! 谦逊与好奇心

# Impact Log - 2026 Q1

## 组织影响

- [RFC-018] 提出并推动支付服务引入事件溯源方案获批(3/1)
  - 影响范围:支付团队、订单团队、结算团队
  - 预期效果:100% 满足审计日志要求

## 技术债务偿还

- 主导认证中间件统一项目(1/15 - 2/28)
  - 将 5 个服务的认证方式统一为 JWT
  - 解决 3 项安全审计问题

## 辅导/成长支持

- 定期辅导 2 名初级工程师(双周一次)
  - 支持其中 1 人晋升资深工程师(晋升成功)
- 主持"分布式系统基础"内部工作坊(2/10, 25 人参加)

## 事故响应

- 主导支付网关超时事故的响应(1/22)
  - 30 分钟内定位原因并部署热修复
  - 撰写事后复盘,提出 3 项防止复发的对策