Văn hóa đổ lỗi: Nhờ người giúp, hư gì cũng là lỗi họ

Văn hóa đổ lỗi là gì?

Văn hóa đổ lỗi là kiểu tư duy khi có sự cố thì việc quan trọng nhất không phải là hiểu chuyện gì đã xảy ra, mà là tìm một người cụ thể để chịu trách nhiệm. Thay vì hỏi “vì sao chuyện này xảy ra” hay “làm sao để tránh lặp lại”, câu hỏi phổ biến lại là “ai là người làm cái này”.

Trong môi trường như vậy, con người bị soi chi tiết, còn hệ thống, quy trình, giới hạn kỹ thuật và các yếu tố khách quan lại bị bỏ qua. Chỉ cần tìm được một cái tên để quy tội, mọi người cảm thấy “ổn rồi”, dù vấn đề gốc rễ vẫn nằm đó.

Từ điện thoại cá nhân đến server, cloud và dịch vụ

Quay lại ví dụ điện thoại:

• Nhờ đặt giúp hình nền, sau đó máy tự lỗi, mất danh bạ: kết luận vội vàng là “tại người đặt hình nền”.
• Nhờ cài giúp một ứng dụng, sau đó hệ điều hành xung đột, treo máy: thay vì xem lại máy cũ, hệ điều hành lỗi thời, lại đổ hết cho người vừa cài.

Trong thế giới server và cloud, câu chuyện y hệt, chỉ khác là bối cảnh phức tạp hơn:

• Trả hàng trăm đô cho server nhưng khi server bị quá tải, bị tấn công hay nhà cung cấp gặp sự cố, người bị blame đầu tiên vẫn là người cài đặt.
• Trả hàng chục đô cho license enterprise, nhưng khi hệ thống không chạy như kỳ vọng lại quy hết lỗi cho người cấu hình giúp.
• Mua gói Cloudflare Pro để chống DDoS, nhưng khi gặp một đợt tấn công vượt quá khả năng gói dịch vụ, phản xạ lại là đổ thừa cho người setup.

Giống như câu chuyện điện thoại: thuê dịch vụ, dùng hạ tầng người khác, chịu giới hạn của nhà cung cấp, nhưng cuối cùng toàn bộ trách nhiệm được đẩy xuống người đứng gần nhất với hệ thống.

Vì sao “trục trặc gì cũng là lỗi của người đụng vào” nghe có vẻ hợp lý?

Cách đổ lỗi này thường xuất phát từ một số thói quen và tâm lý:

• Đơn giản hóa vấn đề phức tạp: thay vì chấp nhận rằng hệ thống kỹ thuật có hàng chục lớp, nhiều thành phần và rủi ro, con người chọn cách “gom” tất cả lại thành lỗi của một cá nhân.
• Né tránh trách nhiệm ban đầu: quyết định chọn gói rẻ, cấu hình thấp, bỏ qua cảnh báo về rủi ro là lựa chọn của chủ hệ thống. Khi sự cố xảy ra, dễ hơn nhiều nếu quy hết cho người triển khai.
• Thiếu hiểu biết về giới hạn dịch vụ: nghĩ rằng “trả tiền là phải hoàn hảo”, trong khi mọi dịch vụ đều có giới hạn rõ ràng: băng thông, CPU, dung lượng, mức độ chống DDoS, phạm vi hỗ trợ.

Dev và admin server trong vai “người đặt hình nền”

Từ góc nhìn dev, không ít lần việc hỗ trợ kỹ thuật chỉ là “giúp cho xong”, nhưng khi có sự cố lại bị biến thành “chịu trách nhiệm chính”. Một số dạng tình huống điển hình:

• Cấu hình giúp website trên một server đã yếu sẵn, nhiều dịch vụ chạy chung. Khi traffic tăng đột biến, site chậm hoặc sập, lập tức bị quy là thiết kế hệ thống kém.
• Hỗ trợ bật một tính năng mới theo yêu cầu, nhưng phía sau là cả đống nợ kỹ thuật tích tụ từ nhiều năm. Khi lỗi ẩn trong đống nợ đó bùng lên, lại thành “dev chỉnh là hỏng”.
• Cảnh báo từ ban đầu về rủi ro, giới hạn, nhu cầu nâng cấp hạ tầng bị bỏ qua. Đến khi điều xấu nhất xảy ra, mọi người quên sạch cảnh báo đó và chỉ nhớ “ai là người đã đụng vào hệ thống”.

Đặt trong ví dụ điện thoại: nhờ người khác thao tác trên một thiết bị cũ, hệ điều hành lỗi thời, dung lượng đầy, pin chai, mạng chập chờn, nhưng nếu có bất cứ lỗi gì thì tất cả đều thành “lỗi của người đã cầm máy”.

Tác hại của văn hóa đổ lỗi với đội kỹ thuật

Khi mọi sai sót đều bị cá nhân hóa, môi trường kỹ thuật chịu nhiều hệ quả:

• Mất an toàn tâm lý: không ai dám thử nghiệm, dám cải tiến, vì chỉ cần một trục trặc là bị gọi tên.
• Chỉ chọn giải pháp an toàn cho bản thân: ưu tiên cách làm ít rủi ro với cá nhân, dù có thể kém hiệu quả cho hệ thống.
• Giảm chất lượng postmortem: báo cáo sự cố không còn là để học hỏi mà là để bảo vệ mình, né chi tiết, né chịu trách nhiệm.
• Khó giữ chân người giỏi: môi trường thiếu công bằng và thiếu tôn trọng khiến người có năng lực chọn rời đi.

Nền văn hóa học hỏi: nhìn vào hệ thống thay vì cá nhân

Đối lập với văn hóa đổ lỗi là văn hóa học hỏi, nơi sai sót được xem là dữ liệu để cải thiện hệ thống. Trong văn hóa đó:

• Sự cố được mổ xẻ theo timeline, dữ kiện, điều kiện vận hành, thay vì xoáy vào một người.
• Các quyết định về ngân sách, cấu hình, giới hạn dịch vụ được ghi lại rõ ràng, để khi có sự cố có thể hiểu được bức tranh đầy đủ.
• Postmortem được coi là tài liệu kỹ thuật giá trị, không phải là hồ sơ truy xét.

Cách tiếp cận này giống như khi điện thoại bị lỗi: thay vì trách người đặt hình nền, cùng nhau xem lại máy đã cũ chưa, hệ điều hành có lỗi không, app có xung đột không, dữ liệu đã backup hay chưa.

Thoát khỏi kiểu nghĩ “ai đụng vào là người có tội”

Để tránh rơi vào bẫy tư duy đổ lỗi, có thể bắt đầu từ những bước nhỏ:

• Luôn hỏi “chuyện gì đã xảy ra” trước “ai đã làm”.
• Nhìn lại các quyết định từ đầu: chọn gói nào, giới hạn ra sao, đã được cảnh báo gì, đã chấp nhận rủi ro gì.
• Chấp nhận rằng bất kỳ hệ thống nào cũng có lỗi và rủi ro, từ điện thoại, server đến con người.
• Ưu tiên giải pháp và phòng ngừa: backup, monitoring, tài liệu rõ ràng, quy trình minh bạch hơn là truy lùng một “thủ phạm”.

Kết luận: thuê giúp một việc, không có nghĩa mọi rủi ro đều thuộc về người giúp

Từ chuyện nhỏ như đặt hình nền điện thoại đến những thứ lớn như hệ thống cloud, server, license enterprise, logic căn bản vẫn giống nhau: khi nhờ người khác hỗ trợ, người đó không trở thành “lá chắn thần kỳ” cho mọi vấn đề kỹ thuật, càng không phải là người gánh toàn bộ hậu quả cho mọi quyết định trước đó.

Một môi trường trưởng thành là nơi mọi người hiểu rằng: rủi ro là thứ được chia sẻ, trách nhiệm là thứ được phân bổ rõ ràng, và sai sót là cơ hội để cải thiện hệ thống. Khi tư duy này rõ ràng, câu chuyện “nhờ cài hình nền, mất danh bạ là lỗi của bạn” sẽ dần trở thành điều vô lý mà không ai còn muốn lặp lại – cả trong đời sống lẫn trong thế giới server.