Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng đội kỹ thuật của bạn đang tranh cãi suốt ba tuần về việc nên chọn REST hay GraphQL cho hệ thống API mới. Mỗi lần họp lại nhắc lại từ đầu, ai cũng có ý kiến, nhưng không ai chốt. Sáu tháng sau, một kỹ sư mới vào muốn hiểu "vì sao chúng ta chọn thế này" thì chẳng có tài liệu nào để tra — chỉ còn vài dòng chat Slack đã trôi mất.
Đây chính xác là loại vấn đề mà RFC (Request For Comments) sinh ra để giải quyết. RFC là một tài liệu đề xuất được viết ra, chia sẻ công khai để mọi người góp ý bất đồng bộ (async), trước khi một quyết định quan trọng về thiết kế, kiến trúc hay quy trình được thông qua.
Khi tổ chức của bạn còn nhỏ — dưới 15 người — bạn có thể quyết mọi thứ bằng cách quay ghế lại và nói chuyện. Nhưng khi vượt qua 30, 50, rồi 100 người, cách làm đó sụp đổ. Không phải ai cũng có mặt trong phòng họp. Không phải ai cũng nhớ vì sao quyết định được đưa ra. Kiến thức bị nhốt trong đầu vài người, và mỗi lần họ nghỉ việc, tổ chức mất trí nhớ.
RFC là công cụ giúp một tổ chức đang scale giữ được ba thứ cực kỳ quý: chất lượng quyết định, sự minh bạch, và trí nhớ tổ chức. Trong bài này, chúng ta sẽ đi sâu vào RFC là gì, khi nào dùng, template chuẩn ra sao, và cách vận hành nó mà không biến nó thành một lớp quan liêu làm chậm mọi người.
Khái niệm cốt lõi
RFC là gì và không phải là gì
RFC bắt nguồn từ cộng đồng phát triển Internet những năm 1969 — những tài liệu định nghĩa chuẩn TCP/IP, HTTP đều là các RFC được đánh số. Ngày nay các công ty công nghệ như Google (họ gọi là "design docs"), Uber, Stripe, Squarespace và rất nhiều startup đã mượn ý tưởng này cho quyết định nội bộ.
Bản chất RFC là một tài liệu đề xuất bằng văn bản cho một thay đổi có tác động đủ lớn, được chia sẻ để thu thập phản hồi trong một khoảng thời gian nhất định, rồi mới đi tới quyết định.
RFC không phải là:
- Một tài liệu để xin phê duyệt kiểu "sếp ký tên rồi làm". RFC là để thu thập góp ý và đạt đồng thuận, không phải cửa kiểm duyệt.
- Một bản đặc tả kỹ thuật chi tiết (spec) mô tả mọi dòng code. RFC tập trung vào quyết định và lý do, không phải hướng dẫn triển khai.
- Thứ dùng cho mọi quyết định nhỏ nhặt. Đổi màu nút bấm hay sửa một bug không cần RFC.
Vì sao RFC hiệu quả: bốn giá trị
Thứ nhất — Async decision-making. Thay vì kéo 8 người vào phòng họp một tiếng (tốn 8 giờ-người), tác giả bỏ 2 giờ viết tài liệu, mọi người đọc và bình luận vào lúc rảnh. Người ở múi giờ khác, người đang bận sprint, đều có thể tham gia. Đây là điểm cực kỳ giá trị cho các team remote hoặc phân tán như nhiều công ty tại Việt Nam có team ở TP.HCM, Hà Nội và Đà Nẵng.
Thứ hai — Tư duy sâu hơn. Viết ra buộc bạn suy nghĩ mạch lạc. Rất nhiều đề xuất nghe hay khi nói miệng nhưng sụp đổ khi phải viết thành câu chữ rõ ràng, liệt kê các phương án đã cân nhắc và giải thích vì sao loại bỏ chúng.
Thứ ba — Lưu trữ rationale (lý do). Sáu tháng, hai năm sau, khi ai đó hỏi "vì sao ngày xưa mình chọn thế này", câu trả lời nằm ngay trong RFC. Đây là "hộp đen" của tổ chức.
Thứ tư — Dân chủ hóa tri thức. Một kỹ sư junior đọc RFC của senior sẽ học được cách tư duy thiết kế. Người mới vào đọc kho RFC cũ sẽ hiểu lịch sử hệ thống nhanh hơn nhiều so với hỏi han từng người.
Khi nào cần viết RFC
Đây là câu hỏi quan trọng nhất, vì lạm dụng RFC cũng tệ như không có. Nguyên tắc chung: viết RFC khi quyết định vừa khó đảo ngược, vừa ảnh hưởng đến nhiều người/nhiều team.
Nên viết RFC khi:
- Thay đổi kiến trúc lớn (chọn database, đổi từ monolith sang microservices, chọn message queue).
- Thay đổi ảnh hưởng nhiều team (API contract dùng chung, quy ước code toàn công ty).
- Quyết định khó/đắt để đảo ngược (chọn ngôn ngữ lập trình, cloud provider).
- Thay đổi quy trình vận hành ảnh hưởng cả tổ chức (quy trình on-call, quy trình release).
- Quyết định nằm gọn trong một team và dễ đảo ngược.
- Sửa bug, refactor nhỏ, thay đổi thuần túy cục bộ.
Template RFC chuẩn
Một RFC tốt thường gồm các phần sau. Bạn nên chuẩn hóa thành một mẫu (template) trong Notion, Confluence hoặc Google Docs của công ty:
- Title & Metadata — Tiêu đề rõ ràng, tên tác giả, ngày tạo, trạng thái (Draft / In Review / Accepted / Rejected / Superseded), danh sách reviewer.
- Summary (Tóm tắt) — 3–5 câu để người bận rộn nắm được ý chính mà không cần đọc hết.
- Context & Problem (Bối cảnh & Vấn đề) — Chúng ta đang giải quyết vấn đề gì? Vì sao nó quan trọng bây giờ?
- Goals & Non-Goals (Mục tiêu & Ngoài phạm vi) — Nói rõ cái gì trong phạm vi và cái gì cố tình để ngoài, tránh tranh luận lạc đề.
- Proposal (Đề xuất) — Giải pháp đề xuất, đủ chi tiết để đánh giá.
- Alternatives Considered (Các phương án đã cân nhắc) — Phần quan trọng bậc nhất. Liệt kê các lựa chọn khác và vì sao không chọn. Đây là nơi thể hiện bạn đã suy nghĩ nghiêm túc.
- Trade-offs & Risks (Đánh đổi & Rủi ro) — Giải pháp này có nhược điểm gì, rủi ro gì.
- Open Questions (Câu hỏi mở) — Những điểm còn chưa chắc, muốn xin ý kiến.
- Timeline & Rollout — Kế hoạch triển khai sơ bộ.
Tình huống thực tế
Ví dụ 1: Startup fintech ở TP.HCM chọn hệ thống thanh toán
MoMoPay (tên giả định) là một startup fintech 45 người ở TP.HCM. Khi mở rộng sang mảng thanh toán quốc tế, đội kỹ thuật chia hai phe: một bên muốn tự xây payment gateway để chủ động, một bên muốn tích hợp Stripe/Adyen cho nhanh. Hai tuần liền, mỗi cuộc họp đứng lại ở chỗ tranh cãi, không ai chịu ai.
CTO quyết định dừng họp và yêu cầu một RFC. Một senior engineer viết tài liệu 4 trang: bối cảnh, ba phương án (tự xây, dùng Stripe, dùng hybrid), bảng so sánh chi phí (tự xây tốn ~6 tháng-người và ~2 tỷ đồng vận hành/năm; Stripe tốn phí giao dịch nhưng lên sản phẩm trong 3 tuần), rủi ro pháp lý với Ngân hàng Nhà nước, và một khuyến nghị.
RFC được mở review 5 ngày. 12 người bình luận, trong đó legal chỉ ra một rủi ro tuân thủ mà đội kỹ thuật đã bỏ sót. Cuối cùng team chọn phương án hybrid: dùng Stripe cho giai đoạn đầu, giữ kiến trúc mở để tự xây sau. Quyết định được chốt trong một tuần thay vì kéo dài vô tận.
Bài học: RFC biến một cuộc tranh cãi cảm tính, lặp đi lặp lại, thành một quyết định có cơ sở, có sự tham gia của cả những bên (legal) mà phòng họp kỹ thuật thường quên mời.
Ví dụ 2: Grab và văn hóa design doc phân tán
Ở một công ty quy mô Đông Nam Á như Grab, với hàng nghìn kỹ sư ở Singapore, Việt Nam, Indonesia, Ấn Độ, việc kéo mọi người vào một phòng họp là bất khả thi — múi giờ, ngôn ngữ, số lượng đều là rào cản. Các công ty như vậy dựa nặng vào design doc/RFC.
Giả sử một team ở Việt Nam muốn thay đổi cách định dạng dữ liệu địa lý dùng chung cho tính năng bản đồ. Thay đổi này ảnh hưởng ít nhất 5 team ở 3 quốc gia. Nếu không có RFC, họ sẽ phải tổ chức một loạt cuộc họp xuyên múi giờ, mỗi cuộc lại thiếu người. Với RFC, team viết đề xuất, tag các team liên quan, đặt deadline review 7 ngày. Mỗi team đọc và bình luận vào giờ làm việc của mình. Một team ở Ấn Độ phát hiện thay đổi này phá vỡ một tính năng của họ — họ nêu ngay trong comment, và tác giả điều chỉnh trước khi bất kỳ dòng code nào được viết.
Bài học: Với tổ chức phân tán, RFC không phải là "nên có" mà là phương tiện giao tiếp bắt buộc. Nó cho phép ra quyết định chất lượng cao mà không cần mọi người online cùng lúc.
Ví dụ 3: RFC thất bại vì biến thành thủ tục
Một công ty product 80 người ở Hà Nội áp dụng RFC nhưng làm sai. Họ bắt mọi thay đổi kỹ thuật đều phải có RFC, kể cả những việc nhỏ. Mỗi RFC phải được 3 cấp quản lý "approve". Kết quả: kỹ sư mất trung bình 2 tuần chỉ để một thay đổi nhỏ được thông qua, RFC chất đống, không ai đọc kỹ, và cuối cùng mọi người bắt đầu "lách" bằng cách làm trước rồi viết RFC lấy lệ sau.
Sau ba tháng, team lead nhận ra vấn đề và cải tổ: chỉ những quyết định có tác động cao mới cần RFC; RFC là để thu thập góp ý và đạt đồng thuận chứ không phải cửa phê duyệt hành chính; và mỗi RFC có deadline review cứng (thường 5–7 ngày làm việc), quá hạn mà không có phản đối nghiêm túc thì mặc định được thông qua.
Bài học: RFC là công cụ tạo đồng thuận và lưu trữ tri thức, không phải một tầng quan liêu. Khi nó trở thành thủ tục xin phép, nó giết chết tốc độ và mọi người sẽ tìm cách né.
Hướng dẫn từng bước
Đây là quy trình vận hành RFC bạn có thể áp dụng ngay:
Bước 1 — Xác định có thực sự cần RFC không. Áp dụng nguyên tắc "khó đảo ngược + ảnh hưởng nhiều người". Nếu không thỏa cả hai, cân nhắc một cuộc trao đổi nhanh thay vì RFC.
Bước 2 — Viết bản nháp (Draft). Dùng template chuẩn của công ty. Đừng cố hoàn hảo — mục tiêu là đủ rõ để người khác hiểu và góp ý. Đầu tư mạnh nhất vào phần Problem, Proposal và Alternatives Considered.
Bước 3 — Chọn reviewer và đặt deadline. Tag đúng người: những người bị ảnh hưởng, chuyên gia lĩnh vực, và người có quyền quyết định (decision owner). Đặt deadline review rõ ràng, ví dụ "xin góp ý trước hết ngày 5/7". Không có deadline thì RFC sẽ trôi mãi.
Bước 4 — Thu thập và phản hồi comment. Trả lời từng góp ý ngay trong tài liệu (Google Docs, Notion comment rất hợp cho việc này). Nếu một góp ý làm bạn đổi ý, hãy cập nhật tài liệu và ghi rõ. Sự minh bạch trong cách bạn phản hồi comment cũng quan trọng như nội dung.
Bước 5 — Đạt quyết định. Sau deadline, decision owner chốt: Accepted, Rejected, hoặc cần chỉnh sửa thêm. Ghi rõ lý do quyết định vào RFC. Nếu có bất đồng còn lại, ghi nhận nó (kiểu "disagree and commit").
Bước 6 — Lưu trữ và đánh dấu trạng thái. Chuyển trạng thái sang Accepted, đưa vào kho RFC có thể tìm kiếm được. Sau này nếu bị thay thế, đánh dấu "Superseded by RFC-XXX" thay vì xóa. Lịch sử là tài sản.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết RFC quá dài, quá chi tiết. Một RFC 20 trang sẽ không ai đọc. Mục tiêu là 2–5 trang. Nếu dài hơn, có lẽ bạn đang nhồi cả spec triển khai vào. Tách phần đó ra.
Lỗi 2 — Bỏ qua phần Alternatives Considered. Đây là dấu hiệu rõ nhất của một RFC lười. Nếu bạn chỉ trình bày một giải pháp mà không cho thấy đã cân nhắc phương án khác, reviewer sẽ nghi ngờ bạn "đã quyết trong đầu rồi, viết cho có".
Lỗi 3 — Không đặt deadline. RFC không deadline là RFC chết. Nó sẽ nằm mãi ở trạng thái Draft, mọi người "để đọc sau" và không bao giờ đọc.
Lỗi 4 — Biến RFC thành cửa phê duyệt hành chính. Như ví dụ ở Hà Nội, khi RFC cần quá nhiều chữ ký, nó giết tốc độ. Hãy nhớ: mục tiêu là đồng thuận và tri thức, không phải kiểm soát.
Lỗi 5 — Không phản hồi comment. Nếu tác giả im lặng trước góp ý, người ta sẽ ngừng góp ý. Văn hóa RFC sống nhờ vòng lặp phản hồi hai chiều.
Mẹo hay:
- Dùng "disagree and commit": khi không đạt đồng thuận tuyệt đối, decision owner chốt, và những người bất đồng cam kết thực thi. Ghi lại bất đồng để sau này còn tham chiếu.
- Đặt "office hours" cho RFC nóng: nếu comment qua lại quá nhiều vòng, một cuộc họp 30 phút để gỡ có thể nhanh hơn. RFC async là mặc định, không phải giáo điều cứng nhắc.
- Tạo một chỉ mục RFC (index) có thể tìm kiếm, đánh số RFC-001, RFC-002... để dễ tham chiếu.
- Khuyến khích cả người junior viết RFC — đó là cách rèn tư duy thiết kế tuyệt vời.
Bài tập thực hành
Bài 1 — Phân loại quyết định. Với mỗi tình huống sau, quyết định xem có cần RFC không và giải thích ngắn: (a) đổi màu nút "Đăng ký"; (b) chuyển toàn bộ hệ thống email từ SendGrid sang AWS SES; (c) đặt lại tên một biến trong một hàm; (d) thay đổi quy trình on-call của toàn phòng kỹ thuật.
Bài 2 — Viết một RFC thật. Chọn một quyết định kỹ thuật hoặc quy trình đang mở trong team bạn (hoặc giả định: "team nên dùng monorepo hay nhiều repo riêng?"). Viết một RFC 2 trang theo template chuẩn, đặc biệt đầu tư vào phần Problem và Alternatives Considered (ít nhất 2 phương án).
Bài 3 — Review chéo. Đưa RFC của bạn cho một đồng nghiệp và yêu cầu họ bình luận trong 48 giờ. Sau đó, tự đánh giá: phần nào của RFC gây hiểu nhầm nhiều nhất? Điều đó cho bạn biết gì về cách bạn cần viết rõ hơn?
Bài 4 — Kiểm tra kho tri thức. Nếu team bạn đã có RFC/design doc cũ, thử tìm một quyết định đã đưa ra hơn 6 tháng trước và xem bạn có tra lại được lý do không. Nếu không, đó là lỗ hổng trí nhớ tổ chức mà RFC giải quyết.
Tóm tắt
RFC (Request For Comments) là một tài liệu đề xuất được viết ra và chia sẻ để mọi người góp ý bất đồng bộ, trước khi một quyết định quan trọng về thiết kế, kiến trúc hay quy trình được thông qua. Nó giải quyết bốn vấn đề cốt lõi của một tổ chức đang scale: cho phép ra quyết định async (không cần mọi người cùng có mặt), buộc tư duy sâu hơn, lưu trữ rationale để tra cứu sau này, và dân chủ hóa tri thức.
Hãy dùng RFC khi quyết định vừa khó đảo ngược vừa ảnh hưởng nhiều người — không phải cho mọi việc nhỏ. Một RFC tốt gồm: tóm tắt, bối cảnh & vấn đề, mục tiêu & ngoài phạm vi, đề xuất, các phương án đã cân nhắc, đánh đổi & rủi ro, và câu hỏi mở. Phần "Alternatives Considered" là linh hồn của RFC.
Vận hành RFC đúng cách nghĩa là luôn có deadline review, phản hồi comment minh bạch, decision owner rõ ràng, và lưu trữ có thể tìm kiếm. Cạm bẫy lớn nhất là biến RFC thành một tầng phê duyệt quan liêu — khi đó nó giết tốc độ và mọi người sẽ tìm cách né. Nhớ rằng: RFC là công cụ tạo đồng thuận và giữ trí nhớ tổ chức, không phải cửa xin phép.