Cách SRE tạo ra văn hóa không đổ lỗi

Những người làm công nghệ thường ca ngợi thất bại là điều thiết yếu cho sự đổi mới. Nhưng ở rất nhiều tổ chức, khi thất bại xảy ra, điều đó lại bị trừng phạt. Khi một hệ thống CNTT gặp sự cố, một cá nhân hoặc một nhóm sẽ lập tức bị xác định, bị đổ lỗi và bêu rếu. Điều này phản tác dụng. Việc đổ lỗi gây tổn hại cho công ty bằng cách tạo ra một môi trường an toàn giả tạo và làm kìm hãm sự sáng tạo; tệ hơn nữa, khi sai sót xảy ra, chúng thường bị che giấu.

May mắn thay, ngày càng nhiều tổ chức nhận ra những tác hại mà văn hóa đổ lỗi mang lại và đang chuyển sang xây dựng văn hóa không đổ lỗi. Đây là một sự thay đổi lớn, đúng vậy, nhưng các công ty hoàn toàn có thể chuyển đổi thành công sang mô hình không đổ lỗi — nếu họ áp dụng các thực hành tốt nhất của kỹ thuật độ tin cậy hệ thống (SRE – Site Reliability Engineering) vào đội ngũ công nghệ của mình.

Tại sao việc đổ lỗi là tệ hại

Tôi đã từng làm việc tại nhiều công ty tăng trưởng nhanh chịu ảnh hưởng tiêu cực từ văn hóa đổ lỗi. Ở một nơi, công ty đang mở rộng rất nhanh. Những thay đổi liên tục được đưa vào hạ tầng, đồng nghĩa với việc hệ thống thường xuyên gặp trục trặc.

Vì khách hàng vận hành hoạt động kinh doanh cốt lõi trên hệ thống của chúng tôi, yêu cầu về độ tin cậy là cực kỳ cao — đến mức trong một thời gian, chúng tôi ngừng phát triển tính năng mới hoàn toàn, vì sợ rằng những tính năng đó sẽ khiến hệ thống sụp đổ.

Điều này đã đủ khó khăn, nhưng văn hóa đổ lỗi còn làm mọi thứ tồi tệ hơn. Không hề có "lưới an toàn tâm lý" và việc chỉ trích nhau diễn ra liên tục. Tâm lý “chúng tôi - họ” rất rõ rệt — kỹ sư so với người không phải kỹ sư, nhà phát triển với bộ phận vận hành, thậm chí là giữa các nhà phát triển với nhau. Các developer dành quá nhiều thời gian để bảo vệ bản thân và phạm vi công việc của mình.

Trong một môi trường đổ lỗi, các developer lẽ ra nên tập trung vào việc tạo ra kết quả lại phải dành nhiều thời gian trong các cuộc họp để biện minh cho công việc. Văn hóa trả đũa với những ai mắc lỗi sẽ khiến người ta không còn dám học hỏi hay trưởng thành từ sai lầm — vì khi mắc lỗi, họ có thể bị cấp trên quấy rối hoặc bị sa thải.

Những người giỏi nhất — những người có khả năng ra quyết định — cảm thấy trách nhiệm của mình bị phá hoại và rồi sẽ rời đi. Sự sáng tạo và đổi mới dần chậm lại. Trong khi đó, các đối thủ thì bứt phá.

Tại sao văn hóa không đổ lỗi tốt hơn

Trong một môi trường không đổ lỗi, mọi người cảm thấy an toàn và không sợ mắc sai lầm. Đó là một môi trường tâm lý an toàn, nơi DevOps thực sự có thể diễn ra. Các developer cảm thấy đủ tự tin để nêu ý tưởng và thử nghiệm. Nhóm phát triển và vận hành phối hợp tốt, và tất cả cùng đồng lòng giải quyết vấn đề.

Môi trường làm việc trở nên tích cực và mọi người được mặc định là đang cố gắng hết sức. Khi có lỗi xảy ra, không ai bị đổ lỗi. Thay vào đó, mọi sai sót được nhìn nhận là biểu hiện của một điểm yếu nào đó trong hệ thống. Mọi sự chú ý được dồn vào việc khắc phục điểm yếu đó — nhờ vậy mà hệ thống liên tục được cải thiện.

Làm thế nào để xây dựng văn hóa không đổ lỗi

Giả sử bạn vừa gặp sự cố: database bị sập. Đừng bắt đầu bằng việc đổ lỗi cho cá nhân hay đội nào. Thay vào đó, hãy thực hiện một buổi họp tổng kết sau sự cố (postmortem). Đặt ra các câu hỏi và tìm câu trả lời:

• Tại sao database bị sập?
• Vì Alex bấm nhầm nút.
• Vì sao Alex lại bấm nhầm nút?
• Vì chúng ta không có hệ thống tự kiểm tra hay quy trình xét duyệt.
• Tại sao không có?

Giờ đây bạn đã tiếp cận theo hướng không đổ lỗi và đang thu được lợi ích. Cuộc thảo luận trở nên mang tính xây dựng và bạn đang tập trung vào việc sửa hệ thống, không phải tìm người để đổ lỗi. Không phải vì Alex bấm nhầm nút, mà là vì tổ chức chưa có cơ chế để đảm bảo điều đó không xảy ra. Đây là cơ hội để học hỏi và cải thiện, không phải là lý do để sa thải Alex. Hãy đặt ra giải pháp để điều này không xảy ra lần nữa.

SRE có thể giúp gì?

Để đạt được một môi trường thực sự không đổ lỗi, bạn cần áp dụng các thực hành tốt nhất của SRE. Tại sao? Vì SRE tạo ra các hệ thống phần mềm cực kỳ mở rộng và đáng tin cậy, bằng cách tự động hóa và xây dựng các công cụ — loại bỏ yếu tố con người khỏi các quy trình nhạy cảm và tập trung vào hệ thống.

Một trong những nguyên tắc nền tảng của phong trào SRE chính là không đổ lỗi. Bằng cách thành lập đội ngũ SRE và áp dụng các thực hành SRE, tổ chức của bạn có thể chuyển từ mô hình vận hành truyền thống “hỏng – sửa” sang một môi trường tiếp cận vận hành theo hướng phát triển phần mềm — với mục tiêu nâng cao độ tin cậy thông qua tự động hóa, tích hợp liên tục và triển khai liên tục (CI/CD).

Để làm được điều đó, bạn cần một người dẫn dắt SRE (SRE Champion) và có được sự ủng hộ từ tổ chức. Văn hóa không đổ lỗi phải đến từ cấp lãnh đạo và được thực hành từ trên xuống dưới.

Công cụ cũng rất quan trọng. Hãy tìm những công cụ và dashboard có thể phân tích sau sự cố, xác định các hành động cần thiết, phát hiện các dịch vụ/sản phẩm/khách hàng bị ảnh hưởng nhiều nhất, và những yếu tố góp phần gây ra sự cố. Công cụ phù hợp sẽ giúp bạn xử lý nhanh hơn, bằng cách cung cấp cái nhìn tổng quan rõ ràng về chỉ số liên quan đến sự cố và hành động cần thực hiện.

Kết Luận

Bạn muốn di chuyển nhanh và đổi mới. Nhưng liệu bạn có thể làm điều đó một cách ổn định không? ✅ Với một văn hóa không đổ lỗi, bạn có thể. Bạn sẽ có một môi trường an toàn, thu hút và giữ chân được nhân tài. Bạn sẽ hành động nhanh hơn, vì bạn tập trung vào sửa hệ thống chứ không phải chơi trò đổ lỗi. Bằng việc nâng cao độ tin cậy, bạn sẽ xây dựng được niềm tin lớn hơn với khách hàng.

Người ta thường nói: “Thất bại không phải là một lựa chọn.” Nhưng trong một môi trường không đổ lỗi, thất bại luôn là một lựa chọn — vì điều đó đồng nghĩa với việc hệ thống luôn được cải thiện, và đổi mới luôn diễn ra.

Dịch từ: https://devops.com/how-sre-creates-a-blameless-culture/