- Authors
- Name
- Youngju Kim
- @fjvbn20031
无论什么背景，一半已经在手里
考虑转型 FDE 的工程师，大多从后端、DevOps/SRE、数据工程三者之一出发。先说好消息：拿第 2 篇的技能地图的八个领域来量，无论哪个背景，大约一半已经填上了。FDE 不是从零开始的职位，而是把既有的工程履历搬进「现场」这个坐标系的职位。
坏消息是，空着的那一半因背景而异。所以转型准备不该照抄别人的路线图，而要从自己背景的差距分析开始。下面依次讲三种背景。找到自己的那段来读，但其他背景的部分也值得扫一眼——因为入队之后，你会和那些背景的同事互相补位。
如果你来自后端
已经拥有的 — API 设计与集成、数据库、代码质量，以及读懂并修改产品代码的速度。既然 FDE 的交付物归根到底是跑在客户环境里的代码，快速且安全地写代码的能力就是转型最扎实的本钱。用八个领域来说，数据库大致在实战线，Linux 在底线附近。
需要补齐的 — 基础设施层。Kubernetes 和网络在后端的日常里多由平台团队代劳，所以容易是空的。还有运维经验：如果你从没在凌晨接过自己所建服务的故障电话，就得补——换到有值班轮换的团队，或者认真运营一个副业项目。最后是进入陌生代码库的速度，给开源项目提交贡献是无文档读懂他人系统的好练习场。
如果你来自 DevOps 或 SRE
已经拥有的 — 技术轴的大部分。Linux、网络、Kubernetes、可观测性、云，八个领域里五个很可能就是你的本职工作。故障响应的顺序感、运行手册文化、无责复盘这些运维纪律也早已长在身上。单看技术差距，这是三种背景里最占便宜的。
需要补齐的 — 方向相反的两件事。第一，写产品代码。基础设施自动化脚本和产品功能代码用的是不同的肌肉；如果没有过接到客户需求做出功能的经历，就做一个，再小也行。第二，掉转沟通的方向。过去你的对话对象多是内部开发者，而 FDE 的对面是外部的非工程师。要练习把本来写在内部 wiki 的文档，改写成发给客户的报告。
如果你来自数据工程
已经拥有的 — 数据库和 SQL 在实战线，搭管道攒下的数据地形感是一件大武器。客户环境里最先要干的事之一就是摸清客户数据的结构与质量——这正是你吃饭的手艺。数据边界与个人信息处理的分寸感也已经在。
需要补齐的 — 服务运维层。批处理管道的世界与实时服务的世界，故障的语法不一样。网络、认证，以及在用户正在经历故障的当下做实时诊断的经验，相对容易是空的。可观测性也需要从管道监控扩展到服务监控。
共同要补的 — 站到客户面前的技术
三种背景共同空得最厉害的格子不是技术，而是客户对面。具体是三件事。第一，口头演示。把做出来的东西在非工程师面前 15 分钟内演示完并接受提问，这种形式不经排练不可能成立——哪怕是内部分享也要创造机会，把次数堆起来。第二，传达坏消息。第 5 篇讲的期望管理，是「读到」和「做到」距离特别远的技能。第三，把模糊的需求变成范围文档：接住「要是能这样就好了」，产出一页带成功标准的纸——拿副业项目的虚拟客户也能练。
另外，若目标是全球化职位，英语就是技术栈的一部分。标准不是流利，而是故障当中能否准确汇报。
六个月转型路线图
以下是按两个月为一块构成的一般指南。前提是在职并行，时长会随个人起点伸缩。
- 第 1、2 个月 — 测差距、打地基。用 FDE 课程路线图定位自己，挑出最空的两个领域拉到底线。搭一个家庭实验室、亲手运营一个小型 Kubernetes 集群，是同时触碰多个短板的捷径。
- 第 3、4 个月 — 制造证据。选一个有公开 API 的产品，设定一个虚拟客户场景，做一个集成项目。交付物不只是代码：架构图、成功标准文档、故障手册都算。这些产出会成为证据作品集的核心。并行地用 FDE 工程师养成 RPG 这类诊断练习反复磨，把陌生环境的前 30 分钟练成肌肉记忆。
- 第 5、6 个月 — 改写成故事，投出去。从既有履历里挑出最有现场感的片段，打磨成情境-行动-结果的故事，连同作品集做成申请材料。面试的形式与准备方法在下一篇详细展开。
六个月之后你不会变成一个成品 FDE，而会变成一个 FDE 团队愿意招进来培养的人。这是这份路线图诚实的目标。
亲手练习
转型准备的两大支柱——差距测量与诊断练习——都可以用本博客的工具起步。
- FDE 课程路线图 — 用 10 个领域 65 项技能做差距分析并追踪进度。
- FDE 工程师养成 RPG — 把陌生环境诊断的决策当作任务反复演练。
FDE 完全指南系列