Từ SRE sang FDE: nửa mô tả công việc bạn đã làm, nửa còn lại quyết định bạn có được tuyển

Một kỹ sư SRE đọc tin tuyển Principal Forward Deployed Engineer của Pragmatike trên Built In Boston sẽ thấy rất quen. Tin yêu cầu xử lý các sự cố kỹ thuật phức tạp xuyên qua tầng ứng dụng và hạ tầng, đồng thời cải thiện quy trình deployment, tài liệu, observability và độ tin cậy.

Đến dòng tiếp theo thì nhiều người khựng lại: làm cố vấn kỹ thuật và là đối tác kỹ thuật đáng tin cậy của khách hàng. Ranh giới thật giữa hai nghề nằm ở dòng này, và việc ai được tuyển cũng thường được quyết định ở đây.

Thời điểm cũng thuận lợi: The Pragmatic Engineer ghi nhận nhu cầu tuyển FDE rất lớn tại Google, OpenAI và Anthropic. Với người làm DevOps/SRE, đường sang FDE ngắn hơn bạn nghĩ, với điều kiện bạn biết rõ phần nào mang theo được và phần nào phải xây lại.

Nửa đầu mô tả công việc là việc thường ngày của SRE

Hãy bắt đầu bằng một bài kiểm kê. Paraform xếp FDE vào vai trò lai giữa kỹ thuật phần mềm và triển khai trực tiếp cho khách hàng, với năm nhóm kỹ năng cốt lõi: một ngôn ngữ backend, hạ tầng cloud, data engineering, AI ứng dụng và giao tiếp với khách hàng. Hãy đánh dấu những ô bạn dùng hằng tuần.

Với nhiều người làm SRE, ô cloud được đánh dấu ngay, ô dữ liệu được đánh một nửa. Lặp lại bài kiểm tra với lớp nền mà AITraining2U mô tả cho FDE năm 2026: Python, API, cấu trúc dữ liệu, Git, cloud và DevOps cơ bản, cộng đủ ML để lý luận về mô hình.

Chữ “cơ bản” đứng cạnh DevOps là chỗ bạn đã vượt chuẩn. Những ô dễ còn trống là API, cấu trúc dữ liệu và phần ML, và đó chính là danh sách việc cần làm của bạn.

Có một thứ không nằm trong bảng kiểm kê nhưng đáng giá hơn: thói quen on-call. Paraform nhận thấy kỹ sư xuất thân từ hackathon, startup giai đoạn đầu hoặc từng trực on-call thường thích nghi nhanh nhất, và vai trò này không đòi kinh nghiệm tư vấn từ trước.

Lý do khá dễ hiểu: on-call buộc bạn chẩn đoán một hệ thống chưa quen, khi thông tin còn thiếu và luôn có người đang chờ bạn.

Vì sao kỹ năng hạ tầng chỉ đưa bạn qua cửa

Bài kiểm kê trên có một giới hạn. Paraform nói thẳng rằng trong các đợt giới thiệu ứng viên của họ, kỹ năng kỹ thuật là mức sàn chứ không phải tiêu chí xếp hạng. Thế mạnh SRE giúp bạn vào phòng phỏng vấn, nhưng các ứng viên ngồi cạnh bạn cũng đã qua mức sàn ấy.

Vậy thứ gì tách bạn ra khỏi họ? Lớp kỹ năng thứ hai trong mô tả của AITraining2U gợi ý câu trả lời: xác định đúng bài toán, tư duy sản phẩm, giao tiếp và cộng tác.

Đây cũng là phần mà công việc SRE ít khi buộc bạn phải luyện, vì khách hàng của bạn thường là đồng nghiệp nội bộ và sự cố đã được định nghĩa sẵn bằng alert.

Script chưa phải là code production

Khoảng trống đầu tiên nằm ngay ở phần kỹ thuật. Cloud Authority định nghĩa FDE trước hết là kỹ sư phần mềm làm việc ngay bên cạnh khách hàng, viết code production trong môi trường của khách. Họ coi nền tảng kỹ sư phần mềm vững là điều kiện bắt buộc, và nhiều tin tuyển dụng đòi từ 3–5 năm kinh nghiệm code trở lên.

Nếu phần lớn code bạn viết là Terraform, YAML cho pipeline và script vận hành, hãy tự hỏi: bạn đã bao giờ viết một service mà người khác gọi qua API, cùng sửa và cùng chịu trách nhiệm chưa?

Nếu câu trả lời là chưa, hãy chuẩn bị sẵn cho các câu hỏi về API, cấu trúc dữ liệu và Git trong lớp nền, cùng cách bạn test và bảo trì một service khi người khác cũng sửa nó.

Cách lấp nhanh nhất là chọn một công cụ nội bộ bạn đang vận hành và viết lại nó thành service Python thật sự: có API rõ ràng, có test, có review.

Sau đó gắn thêm một thành phần AI ứng dụng nhỏ, ví dụ một bước tóm tắt log bằng mô hình ngôn ngữ, để luyện đúng mức “đủ ML để lý luận về mô hình” mà lớp nền đòi hỏi.

Trước khi sửa sự cố, hỏi xem bài toán thật là gì

Thử hình dung một khách hàng than rằng job tạo báo cáo hằng đêm của họ liên tục thất bại. Phản xạ của SRE là thêm alert, thêm retry, dựng dashboard rồi viết postmortem. Cả bốn việc đều đúng, nhưng chưa việc nào trả lời được câu hỏi khách thực sự cần.

Một FDE sẽ hỏi trước: ai đọc báo cáo này, đọc lúc mấy giờ, và họ ra quyết định gì dựa trên nó.

Có thể trưởng bộ phận chỉ cần ba con số lúc tám giờ sáng, và một truy vấn chạy theo yêu cầu sẽ thay được cả job dễ hỏng kia.

Phần sửa kỹ thuật lúc ấy trở nên nhỏ hơn, còn niềm tin của khách thì lớn hơn.

Tin tốt là thói quen postmortem chuyển sang được. Việc lần ngược nguyên nhân gốc trong postmortem và việc hỏi “vì sao khách cần thứ này” dựa trên cùng một kỷ luật tư duy. Khác biệt là bạn phải hỏi những câu đó trực tiếp với khách hàng, bằng ngôn ngữ của họ, trước khi đụng vào hệ thống.

Vá cho một khách hay xây cho mọi khách?

Khoảng trống thứ ba nằm ở tầm nhìn. Trong bài nói tại AI Engineer, Kepler đặt kỳ vọng rằng FDE phải khái quát các giải pháp làm cho từng khách thành năng lực của sản phẩm.

Thử hình dung điều ngược lại: mười khách hàng là mười bản vá riêng, và mỗi bản cần một người nhớ nó chạy thế nào. Người làm SRE nhận ra ngay kịch bản đó, vì nó chính là toil.

Ở điểm này SRE có sẵn một lợi thế: bản năng giảm toil. Khi cùng một thao tác thủ công lặp lại lần thứ ba, người làm SRE sẽ muốn tự động hóa nó. Áp vào FDE, khi khách thứ ba cần cùng một connector dữ liệu, bạn nên tách nó thành module dùng chung và viết tài liệu để đội sản phẩm tiếp nhận.

Bảng dưới đây đặt từng dòng trong mô tả FDE cạnh thứ SRE đã có, khoảng trống còn lại và bằng chứng nên đưa vào CV.

Yêu cầu trong mô tả FDE	SRE đã có gì	Khoảng trống cần lấp	Bằng chứng nên có trong CV
Xử lý sự cố xuyên tầng ứng dụng và hạ tầng	Chẩn đoán dưới áp lực khi on-call	Giải thích nguyên nhân cho người không làm kỹ thuật	Một sự cố kể theo tác động tới người dùng
Deployment, observability, độ tin cậy	Đã làm hằng ngày	Hầu như không có	Số liệu cải thiện độ tin cậy bạn trực tiếp tạo ra
Nền tảng kỹ sư phần mềm vững	Script, IaC, tự động hóa	Service có API, test, review	Repo service Python công khai
Đủ ML để lý luận về mô hình	Vận hành hệ thống chạy mô hình, nếu từng làm	Hiểu hành vi và giới hạn của mô hình	Một tính năng AI nhỏ đã deploy
Cố vấn kỹ thuật cho khách hàng	Hỗ trợ đội nội bộ	Xác định đúng bài toán, tư duy sản phẩm	Một lần bạn đổi hướng giải pháp nhờ hỏi đúng câu
Khái quát giải pháp thành sản phẩm	Bản năng giảm toil	Thiết kế để nhiều khách dùng chung	Một công cụ nội bộ được nhiều đội dùng

CV của bạn nên nói ngôn ngữ của FDE

Khi lọc tin tuyển dụng, hãy tìm những dòng như “troubleshoot across application and infrastructure layers” hay “improve observability and reliability”. Những dòng đó trùng với việc bạn đã làm hằng tuần, nên đó là những tin đáng nộp đơn trước tiên.

Sau đó viết lại CV theo hướng ngược với thói quen SRE. Thay vì “giảm MTTR”, hãy kể ai bị ảnh hưởng, bạn đã chẩn đoán xuyên tầng ra sao và người dùng nhận được gì. Mỗi gạch đầu dòng nên cho thấy cả mức sàn kỹ thuật lẫn phần tạo khác biệt.

Người làm SRE đã quen chịu trách nhiệm cho hệ thống của người khác lúc ba giờ sáng. Để trở thành FDE, bạn giữ nguyên tinh thần trách nhiệm đó, chỉ khác là nó hướng tới vấn đề của khách hàng chứ không còn dừng ở uptime của hệ thống.