Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là một kỹ sư vận hành tại một công ty fintech ở TP.HCM. Sáng nào bạn cũng phải làm đúng một chuỗi thao tác: đăng nhập vào máy chủ, kiểm tra dung lượng ổ đĩa của mười node, xóa log cũ nếu đầy, khởi động lại một service hay bị treo, rồi copy-paste kết quả vào một kênh Slack. Mỗi buổi sáng mất khoảng 40 phút. Nghe có vẻ nhỏ, nhưng nhân với 20 ngày làm việc mỗi tháng, bạn đang đốt gần 14 giờ — gần hai ngày công — chỉ để làm những việc mà một script có thể làm trong 30 giây.
Đó chính là toil. Và nếu không nhận diện, đo lường, rồi chủ động cắt giảm nó, đội vận hành của bạn sẽ dần bị chôn vùi dưới những công việc lặp lại, mất động lực, và không còn thời gian cho những việc thực sự tạo giá trị — như cải thiện độ tin cậy hệ thống hay xây dựng nền tảng mới.
Trong khóa học này, chúng ta đã nói về SRE (Bài 7), về error budget (Bài 9), về runbook (Bài 10) và tự động hóa hạ tầng (Bài 36). Bài 53 tập trung vào một khái niệm nền tảng của văn hóa SRE mà Google đưa ra trong cuốn Site Reliability Engineering: toil và việc giảm toil. Đây không chỉ là chuyện "viết vài cái script cho tiện". Nó là một triết lý về cách bạn phân bổ sức lao động của con người sao cho bền vững và có đòn bẩy. Nắm vững nó, bạn sẽ biết cách bảo vệ thời gian của đội, thuyết phục cấp trên đầu tư vào automation, và xây dựng một hệ thống vận hành trưởng thành.
Khái niệm cốt lõi
Toil là gì — định nghĩa chính xác
Theo Google SRE Book, toil không đơn giản là "công việc mình ghét". Toil là loại công việc vận hành gắn với việc chạy một dịch vụ production, và mang những đặc tính sau:
- Manual (thủ công): Cần con người trực tiếp thực hiện bằng tay, ví dụ tự gõ lệnh, tự click, tự copy-paste.
- Repetitive (lặp lại): Bạn làm đi làm lại cùng một thứ, không phải một lần rồi thôi.
- Automatable (có thể tự động hóa): Nếu máy móc có thể làm được thay bạn, thì việc con người làm chính là toil. Nếu công việc bắt buộc cần phán đoán của con người, nó không phải toil.
- Tactical (mang tính đối phó): Nó phản ứng lại tình huống, kiểu "chữa cháy", chứ không mang tính chiến lược, chủ động.
- No enduring value (không tạo giá trị lâu dài): Sau khi làm xong, trạng thái dịch vụ không tốt hơn về mặt lâu dài. Bạn chỉ đưa nó về đúng chỗ cũ.
- Scale linearly with growth (tăng tuyến tính theo quy mô): Dịch vụ lớn gấp đôi thì công việc này cũng tăng gấp đôi. Đây là dấu hiệu nguy hiểm nhất, vì nó nghĩa là bạn không có đòn bẩy.
Toil khác với overhead
Đây là điểm nhiều người nhầm. Overhead là công việc hành chính không liên quan trực tiếp đến việc chạy dịch vụ: họp hành, làm OKR, tự đánh giá cuối kỳ, khai báo chi phí, email. Overhead cũng phiền, nhưng nó không phải toil. Toil gắn chặt với việc vận hành production và có tính lặp lại kỹ thuật. Phân biệt được hai thứ này giúp bạn nhắm đúng mục tiêu khi muốn cắt giảm.
Vì sao toil nguy hiểm
Google chỉ ra rằng toil quá nhiều dẫn tới nhiều hệ quả xấu: kiệt sức (burnout), giảm động lực, đình trệ sự nghiệp (làm toil cả ngày thì không có gì để thăng tiến), tạo tiền lệ xấu (người khác thấy bạn chịu đựng được thì họ cũng đẩy thêm việc), gây lỗi do con người mệt mỏi, và làm chậm tiến độ vì không còn thời gian cho dự án kỹ thuật.
Điều quan trọng: toil không thể bằng không, và cũng không nên bằng không. Một lượng toil nhỏ đôi khi chấp nhận được vì nó dễ dự đoán, giúp người mới học hệ thống. Vấn đề là khi nó vượt ngưỡng.
Ngưỡng 50%
Google đặt ra một cột mốc rất cụ thể và dễ nhớ: một SRE nên dành dưới 50% thời gian cho toil. Nửa còn lại phải dành cho công việc kỹ thuật mang tính engineering — thứ tạo ra giá trị lâu dài và giảm toil trong tương lai (viết automation, cải thiện kiến trúc, xây công cụ). Nếu vượt 50%, đó là tín hiệu cảnh báo cần hành động: tái phân bổ công việc, đẩy bớt toil về đội phát triển, hoặc dừng nhận thêm dịch vụ mới cho tới khi giải quyết xong.
Đo lường toil
Không đo thì không quản được. Cách thực tế: yêu cầu đội ghi nhật ký thời gian trong 2-4 tuần, phân loại từng đầu việc thành toil / engineering / overhead. Hoặc dùng dữ liệu từ hệ thống ticket, on-call: đếm số ticket lặp lại, thời gian xử lý mỗi loại. Kết quả cho bạn một con số phần trăm toil để theo dõi theo thời gian và ưu tiên cắt giảm cái tốn nhiều nhất.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử và cơn ác mộng "restart service"
Một sàn thương mại điện tử tầm trung ở Việt Nam (gọi là ShopViet) có một service thanh toán hay bị treo do rò rỉ bộ nhớ. Đội SRE 4 người xử lý bằng cách: mỗi khi có alert "payment latency cao", một người vào SSH và khởi động lại service. Việc này xảy ra trung bình 6 lần mỗi ngày, mỗi lần khoảng 10 phút gồm cả xác nhận, restart và theo dõi. Tính ra 60 phút/ngày, tương đương một người mất gần 20 giờ mỗi tháng chỉ để bấm nút restart.
Diễn giải: đây là toil kinh điển — thủ công, lặp lại, tự động hóa được, không tạo giá trị lâu dài (service vẫn sẽ treo lại). Đội quyết định làm hai việc. Ngắn hạn: viết một cơ chế health-check tự động restart khi phát hiện service không phản hồi, kèm giới hạn số lần restart để tránh vòng lặp che giấu lỗi. Dài hạn: mở một dự án engineering để tìm và vá chỗ rò rỉ bộ nhớ. Sau hai tuần, toil restart giảm về gần như 0, và ba tuần sau, lỗi gốc được vá.
Bài học: tự động hóa toil trước để giải phóng thời gian, rồi dùng chính thời gian đó để diệt nguyên nhân gốc. Nếu chỉ tự động restart mà không vá lỗi gốc, bạn đã che giấu vấn đề — đó là cái bẫy ta sẽ nói ở phần lỗi thường gặp.
Ví dụ 2 — Startup logistics và việc cấp quyền thủ công
Một startup logistics ở Đông Nam Á tăng trưởng nhanh, tuyển mới 15-20 người mỗi tháng. Mỗi nhân viên mới cần được cấp quyền vào khoảng 8 hệ thống nội bộ: dashboard vận hành, cơ sở dữ liệu chỉ đọc, công cụ CRM, VPN... Trước đây, một kỹ sư vận hành làm việc này bằng tay cho từng người, mất khoảng 45 phút/người và thỉnh thoảng cấp nhầm quyền. Với 20 người/tháng, đó là 15 giờ toil mỗi tháng cộng thêm rủi ro bảo mật.
Diễn giải: công việc này lặp lại, thủ công, tăng tuyến tính theo tốc độ tuyển dụng — dấu hiệu điển hình của toil nguy hiểm. Đội xây một quy trình tự động: một biểu mẫu duyệt đơn giản kích hoạt một pipeline cấp quyền dựa trên vai trò (role-based). HR chọn "vai trò: nhân viên kho", hệ thống tự cấp đúng bộ quyền chuẩn. Thời gian giảm còn 5 phút thao tác duyệt, lỗi cấp nhầm về 0, và quan trọng hơn: khi công ty tuyển gấp đôi, công việc này gần như không tăng.
Bài học: hãy để ý những công việc tăng tuyến tính theo tăng trưởng — đó là ưu tiên số một để tự động hóa, vì chúng sẽ giết đội của bạn khi công ty scale.
Ví dụ 3 — Ngân hàng số và bẫy "báo cáo thủ công"
Một ngân hàng số ghi nhận đội SRE dành 50% thời gian on-call để tổng hợp báo cáo tình trạng hệ thống mỗi sáng: gom số liệu từ 5 dashboard, dán vào slide, gửi lãnh đạo. Nghe có vẻ "quan trọng" nên không ai nghĩ đó là toil. Nhưng khi họ đo lường, con số gây sốc: hơn 22 giờ mỗi tháng cho một việc hoàn toàn tự động hóa được.
Diễn giải: cái bẫy ở đây là toil được ngụy trang thành "công việc giá trị cao" vì nó phục vụ sếp. Sau khi đo lường và trình bày con số, đội được duyệt xây một báo cáo tự động gửi hàng ngày. Kết quả không chỉ tiết kiệm thời gian mà báo cáo còn chính xác và đúng giờ hơn.
Bài học: đo lường biến cảm giác thành con số, và con số là thứ thuyết phục được lãnh đạo đầu tư vào automation.
Hướng dẫn từng bước
Đây là quy trình thực tế để bắt đầu một chương trình giảm toil trong đội của bạn:
- Định nghĩa toil cho đội bạn. Ngồi lại cùng nhau và thống nhất: cái gì tính là toil, cái gì là engineering, cái gì là overhead. Viết ra vài ví dụ cụ thể trong bối cảnh hệ thống của bạn để mọi người phân loại nhất quán.
- Đo lường. Trong 2-4 tuần, mỗi thành viên ghi lại thời gian dành cho từng loại. Có thể dùng bảng tính đơn giản, hoặc trích xuất từ hệ thống ticket và lịch on-call. Mục tiêu là ra được con số phần trăm toil.
- Lập danh sách và ưu tiên. Liệt kê các đầu việc toil, ước lượng thời gian tốn cho mỗi loại mỗi tháng, và độ khó tự động hóa. Ưu tiên theo công thức đơn giản: tác động cao (tốn nhiều giờ) và chi phí tự động hóa thấp làm trước. Đặc biệt ưu tiên những việc tăng tuyến tính theo quy mô.
- Chọn cách xử lý phù hợp cho từng việc. Không phải toil nào cũng cần tự động hóa hoàn toàn. Các lựa chọn: loại bỏ hẳn (việc này còn cần không?), đơn giản hóa quy trình, viết runbook để giảm sai sót và thời gian, tự động hóa một phần (self-service), hoặc tự động hóa hoàn toàn.
- Phân bổ ngân sách thời gian. Dành một tỷ lệ thời gian cố định của đội (ví dụ 20-30% mỗi sprint) cho công việc giảm toil. Nếu không "chặn lịch" như vậy, toil hằng ngày sẽ luôn nuốt hết thời gian và bạn không bao giờ thoát ra được.
- Áp dụng nguyên tắc "đau ba lần thì tự động hóa". Một quy tắc thực dụng: nếu bạn phải làm thủ công một việc lần thứ ba, đó là lúc dừng lại và tự động hóa nó. Lần đầu cứ làm tay, lần hai để ý, lần ba thì viết script.
- Theo dõi và lặp lại. Đặt con số phần trăm toil thành một chỉ số theo dõi định kỳ (hàng quý). Ăn mừng khi giảm được, và điều tra khi nó tăng — vì toil tăng thường báo hiệu hệ thống đang xuống cấp hoặc đội đang nhận quá nhiều việc.
Lỗi thường gặp & mẹo
Lỗi 1 — Tự động hóa mà che giấu vấn đề gốc. Như ví dụ ShopViet, nếu bạn chỉ auto-restart service treo mà không vá lỗi rò rỉ bộ nhớ, bạn đã biến một triệu chứng nhìn thấy được thành một vấn đề vô hình. Mẹo: khi auto-remediate, luôn ghi log và đếm số lần kích hoạt; nếu con số cao, đó là tín hiệu phải xử lý nguyên nhân gốc, không phải để ăn mừng.
Lỗi 2 — Tự động hóa quá sớm, quá phức tạp. Đừng bỏ ba tuần xây một hệ thống tự động hoàn hảo cho một việc chỉ tốn 10 phút mỗi tháng. Toil-to-automate cũng có chi phí. Mẹo: tính điểm hòa vốn — thời gian bỏ ra xây automation phải nhỏ hơn thời gian nó tiết kiệm trong khoảng thời gian hợp lý (thường là dưới một năm).
Lỗi 3 — Không đo lường, chỉ dựa vào cảm giác. "Tôi thấy mệt lắm rồi" không thuyết phục được ai cấp ngân sách. Con số "22 giờ/tháng" thì có. Luôn đo trước khi đề xuất.
Lỗi 4 — Coi giảm toil là việc phụ, làm khi rảnh. Sẽ không bao giờ rảnh. Nếu không chặn lịch chính thức cho công việc giảm toil, nó sẽ vĩnh viễn bị đẩy xuống dưới.
Lỗi 5 — Automation không có người bảo trì. Script tự động hóa cũng là phần mềm: nó hỏng, cần cập nhật, cần giám sát. Một automation mục nát và chạy sai còn nguy hiểm hơn làm tay. Mẹo: coi automation quan trọng như code production — có test, có monitoring, có người chịu trách nhiệm.
Mẹo vàng: Bắt đầu nhỏ và chọn một chiến thắng nhanh (quick win) — một đầu việc toil tốn nhiều giờ nhưng dễ tự động hóa. Thành công đầu tiên tạo động lực và niềm tin để đội đầu tư tiếp.
Bài tập thực hành
- Ghi nhật ký toil của chính bạn. Trong một tuần làm việc tới, mỗi cuối ngày dành 5 phút ghi lại những việc bạn đã làm, phân loại thành toil / engineering / overhead cùng số phút ước lượng. Cuối tuần, tính tỷ lệ phần trăm thời gian dành cho toil. Bạn có vượt ngưỡng 50% không?
- Xác định top 3 nguồn toil. Từ nhật ký trên, chọn ra 3 đầu việc toil tốn nhiều thời gian nhất mỗi tháng. Với mỗi việc, trả lời: nó có tăng tuyến tính theo quy mô hệ thống không? Chi phí tự động hóa ước tính bao lâu? Điểm hòa vốn là khi nào?
- Viết một đề xuất một trang. Chọn đầu việc toil ưu tiên cao nhất và viết đề xuất ngắn gửi (giả định) cho quản lý: hiện trạng tốn bao nhiêu giờ/tháng, đề xuất giải pháp (loại bỏ / đơn giản hóa / tự động hóa), ước tính công sức bỏ ra và thời gian tiết kiệm được. Đây chính là kỹ năng thực tế bạn sẽ dùng để bảo vệ ngân sách automation.
- Áp dụng quy tắc "đau ba lần". Trong tuần tới, để ý việc thủ công nào bạn làm tới lần thứ ba. Dừng lại và phác thảo (dù chỉ trên giấy) cách tự động hóa nó.
Tóm tắt
Toil là công việc vận hành mang tính thủ công, lặp lại, tự động hóa được, đối phó, không tạo giá trị lâu dài, và tăng tuyến tính theo quy mô. Nó khác với overhead (việc hành chính) và khác với công việc engineering tạo giá trị bền vững. Toil quá nhiều dẫn tới kiệt sức, đình trệ sự nghiệp và làm hệ thống không thể scale — nên Google đặt ngưỡng SRE dành dưới 50% thời gian cho toil.
Cách hành động thực tế: định nghĩa → đo lường → ưu tiên → chọn cách xử lý → chặn ngân sách thời gian → theo dõi. Ưu tiên những việc tốn nhiều giờ, dễ tự động hóa, và đặc biệt là những việc tăng theo tăng trưởng. Nhớ ba cạm bẫy: đừng che giấu lỗi gốc, đừng tự động hóa quá sớm/quá phức tạp, và đừng để automation không ai bảo trì. Trên hết, hãy dùng con số — không phải cảm giác — để thuyết phục tổ chức đầu tư. Giảm toil không phải là làm cho công việc dễ chịu hơn một chút, mà là giành lại thời gian của con người cho những việc thực sự có đòn bẩy.