Có lẽ ai trong chúng ta cũng từng trải qua cảm giác này – một buổi sáng đầu tuần, khi vừa mở laptop đã thấy chuông báo lỗi, ticket chất chồng, khách hàng gửi mail hỏi “Tại sao hệ thống lại dừng?” và team mình lại phải chạy đua với thời gian để khôi phục hệ thống.
Rồi sau khi mọi thứ yên ổn trở lại, ta thở phào nhẹ nhõm nhưng cũng tự hỏi trong lòng: “Bao giờ thì vòng lặp này kết thúc? Khi nào chúng ta có thể làm chủ hệ thống, chứ không chỉ chạy theo nó?”
Làm BRSE trong dự án maintain, ta luôn ở giữa hai áp lực: một bên là deadline và yêu cầu khách hàng, một bên là chất lượng và sự ổn định của hệ thống.
Ta không có quyền dừng hệ thống, không thể thay đổi quy trình khách hàng,
nhưng vẫn phải giữ cho mọi thứ vận hành trơn tru – ngày này qua ngày khác.
Thế nên hôm nay, ta sẽ nói về nghệ thuật giữ thăng bằng -giữa tốc độ và ổn định, giữa yêu cầu ngắn hạn và cải tiến dài hạn. Không phải để làm ít lỗi hơn, mà để sống sót và phát triển trong một hệ thống có lỗi.
1️. Từ “chữa cháy” sang “cân bằng rủi ro”
Trong Site Reliability Engineering của Google, khái niệm Error Budget được sinh ra để kết thúc cuộc chiến giữa “release nhanh” và “giữ ổn định”
Thay vì tranh luận, họ định lượng rủi ro: chúng ta chấp nhận bao nhiêu lỗi là “ổn” để đổi lấy tốc độ phát triển.
Với BRSE, bạn có thể không đặt ra SLO chính thức, nhưng vẫn có thể tư duy theo hướng “error budget nhỏ”:
- Ví dụ: “Nếu hệ thống có hơn 5 ticket lỗi giống nhau trong tháng, cần dành 1 tuần refactor hoặc review process.”
- Hoặc: “Nếu downtime vượt 99.9% mục tiêu, tạm dừng thêm feature mới.”
Đây là cách bạn chuyển phản ứng “chữa cháy” thành điều phối rủi ro có chủ đích.
2. “Toil” – công việc lặp lại giết chết cải tiến
Google định nghĩa toil là những công việc vận hành thủ công, lặp lại, không tạo giá trị dài hạn
Với BRSE, toil thường là:
- Cập nhật cùng một lỗi 5 lần trong 1 tuần.
- Copy/paste log để gửi qua email khách hàng.
- Hoặc chạy cùng một script kiểm tra release mỗi ngày.
Những việc này dần hút cạn thời gian cho cải tiến. Vì vậy, hãy chủ động “Kaizen nhỏ”:
- Viết một template trả lời lỗi phổ biến.
- Tạo macro kiểm tra log.
- Hoặc gợi ý khách hàng thêm rule alert tự động.
Khi toil giảm, bạn có thêm “error budget” cho chính mình — thời gian để học, cải tiến, hoặc hỗ trợ nhóm tốt hơn.
3. Tư duy “SRE nhỏ trong dự án lớn”
David Blank-Edelman trong Becoming SRE nói rằng: “SRE không phải là chức danh, mà là cách bạn nhìn hệ thống.”
Là BRSE, bạn có thể không điều khiển hạ tầng, nhưng bạn vẫn có thể:
- Đưa ra đề xuất cải thiện log/error message để debug dễ hơn.
- Giúp khách hàng đo lường uptime hoặc phản hồi trung bình.
- Viết postmortem nhẹ sau sự cố (“vì sao lỗi này tái diễn, giải pháp tạm và dài hạn là gì?”).
Những hành động nhỏ đó giúp bạn tạo ảnh hưởng ngược lên tổ chức khách hàng không bằng quyền lực, mà bằng dữ liệu và niềm tin.
Lời khuyên thực tế cho BRSE
- Đừng chỉ báo lỗi – hãy kể câu chuyện của lỗi.
Khi report sự cố cho khách hàng, thay vì chỉ nói “lỗi đã được fix”, hãy thêm: “Nguyên nhân là A, tác động là B, để tránh tái diễn chúng tôi đề xuất C.”
Điều này giúp khách hàng thấy bạn là người vận hành có trách nhiệm, không phải người xử lý sự cố. - Đặt câu hỏi “chúng ta chấp nhận lỗi đến mức nào?”
Câu hỏi này giúp định nghĩa SLO ngầm cho dự án, đôi khi chỉ cần một bảng Excel theo dõi lỗi định kỳ là đủ để thay đổi cách mọi người nhìn về chất lượng. - Biến số liệu thành ngôn ngữ giao tiếp.
Người Nhật thường tin vào số liệu hơn cảm xúc. Nếu bạn muốn đề xuất cải tiến, hãy bắt đầu bằng dữ liệu: “Tuần này có 12 lỗi, trong đó 8 lỗi lặp lại từ tháng trước.”
Khi có con số, bạn có thể nói về cải tiến mà không bị coi là “ý kiến cá nhân”. - Tạo “mini-dashboard” cho nhóm.
Dù chỉ dùng Google Sheet, bạn có thể tự quản lý bảng SLO nhỏ: uptime, lỗi lặp lại, thời gian phản hồi.
Chính dashboard này là “Error Budget Board” của bạn. - Nhỏ nhưng đều – Kaizen theo chu kỳ.
Đừng đợi cải tiến lớn. Mỗi tuần chỉ cần chọn 1 việc lặp lại để tự động hóa, hoặc 1 lỗi để root cause sâu hơn.
Vui lòng đăng nhập để bình luận.