Nhà máy điện hạt nhân và Quy trình QA: Có mối liên hệ gì?

Chúng ta đều biết rằng kiểm thử và xác minh phần mềm trước khi đưa ra môi trường production là rất quan trọng. Nhưng bạn đã bao giờ dừng lại để suy nghĩ về mức độ nghiêm trọng thực sự của công việc này chưa?

Gần đây, khi xem lại bộ phim "Chernobyl", tôi đã nhận ra nhiều điều — đặc biệt là cách tôi nhìn nhận vai trò của mình với tư cách là một QA (Chuyên viên kiểm thử chất lượng) và trách nhiệm lớn lao mà nó mang lại. Tôi xin chia sẻ những suy ngẫm này với các bạn.

Với ai chưa biết, "Chernobyl" là bộ phim truyền hình ngắn tập ra mắt năm 2019 tái hiện thảm họa hạt nhân tại nhà máy cùng tên thuộc Liên Xô cũ vào ngày 26 tháng 4 năm 1986. Câu chuyện đi sâu vào những sự kiện ngay sau vụ nổ lò phản ứng số 4 — sự hỗn loạn, nỗ lực che giấu mức độ nghiêm trọng của chính phủ Liên Xô và những nỗ lực khổng lồ của các nhà khoa học, lính cứu hỏa, quân nhân và công nhân, những người đã chấp nhận rủi ro, và nhiều người đã hy sinh, để ngăn chặn một thảm họa còn lớn hơn. Phim cũng theo chân nhà khoa học Valery Legasov, người cố gắng tìm ra nguyên nhân thực sự của vụ tai nạn và vạch trần sự thật đằng sau bi kịch đó.

Tuy nhiên, điểm mấu chốt ở đây không nằm ở bộ phim.

Điều khiến tôi chú ý nhất là cách mà bi kịch đó lại đối chiếu trực tiếp với điều chúng ta đối mặt hàng ngày trong phát triển phần mềm: trách nhiệm trong việc ra quyết định.

Đã xảy ra gì tại Chernobyl?

Dù biết rằng phim có yếu tố kịch tính hóa, chúng ta vẫn có thể học được rất nhiều bài học từ thảm họa này. Tôi không phải là nhà vật lý hạt nhân, nhưng tôi sẽ cố gắng tóm tắt những gì đã diễn ra — bởi vì chính phần này đã khiến tôi suy nghĩ nhiều nhất về trách nhiệm và việc ra quyết định.

Vào rạng sáng ngày 26 tháng 4 năm 1986, các nhà điều hành nhà máy đang thực hiện một kiểm thử an toàn tại lò phản ứng số 4. Mục tiêu là xác minh xem trong trường hợp mất điện, các tuabin có thể tiếp tục phát điện trong vài giây hay không — thời gian đủ để các máy phát điện khẩn cấp khởi động. Trên lý thuyết, bài kiểm tra này có vẻ đơn giản.

Vấn đề là để thực hiện nó, nhiều hệ thống an toàn đã bị vô hiệu hóa và công suất của lò phản ứng được giảm xuống mức thấp hơn nhiều so với lý tưởng. Đó là lúc mọi thứ bắt đầu vượt khỏi tầm kiểm soát.

Lò phản ứng được sử dụng là loại RBMK, một mô hình có một lỗi thiết kế mang tính chí mạng: trong điều kiện nhất định, càng nhiều hơi nước được tạo ra trong hệ thống, công suất của lò phản ứng càng tăng. Thay vì ổn định, nó ngày càng trở nên mất ổn định. Để tệ hơn, bài kiểm tra được tiến hành dưới áp lực lớn từ cấp lãnh đạo, dù có những tín hiệu rõ ràng rằng việc tiếp tục là không an toàn.

Chernobyl

Trong suốt bộ phim, ta thấy chính các nhà điều hành nêu lên lo ngại — nhưng đều bị phớt lờ. Khi nhận ra tình hình đã trở nên nghiêm trọng, họ đã nhấn nút tắt khẩn cấp. Về lý thuyết, lệnh này sẽ kết thúc phản ứng. Tuy nhiên, do một lỗi trong thiết kế các thanh điều khiển, hiệu ứng ban đầu lại hoàn toàn ngược lại: công suất tăng vọt. Chỉ trong vài giây, nhiệt độ và áp suất đã tăng lên một cách mất kiểm soát.

Kết quả là hai vụ nổ đã phá hủy đỉnh của lò phản ứng, phơi bõi lõi ra atmosphere và giải phóng một lượng lớn vật liệu phóng xạ. Đám cháy sau đó đã lan truyền phóng xạ sang phần lớn châu Âu, biến Chernobyl thành thảm họa hạt nhân lớn nhất trong lịch sử.

Điều làm tôi ấn tượng nhất là nhận ra rằng thảm họa không xảy ra vì một lỗi đơn lẻ. Nó là hệ quả của một chuỗi các quyết định sai lầm: các lỗi kỹ thuật bị bỏ qua, rủi ro được đánh giá kém và những người không được lắng nghe.

Và điều đó liên quan gì đến phần mềm?

Sau khi xem xong phim, tôi bắt đầu thấy sự song song với lĩnh vực của chúng ta. Bởi vì, xét cho cùng, bao nhiêu vụ sự cố trên môi trường production cũng bắt đầu theo cách tương tự?

Không phải lúc nào vấn đề cũng xuất phát từ một bug duy nhất. Thường xuyên lắm, nó là kết quả của một chuỗi các quyết định được đưa ra mà thiếu sự thận trọng cần thiết: một yêu cầu (requirement) được định nghĩa tệ, một rủi ro không được mapping, một quy trình xác minh hời hợt, một sự ra mắt (release) vội vàng — hoặc một cảnh báo từ đội ngũ bị bỏ qua.

Đó là lúc bộ phim giúp tôi nhận ra một điều vượt xa bối cảnh của nó: khi sự vội vàng nói lớn hơn sự phân tích, cái giá phải trả thường xuất hiện sau đó.

Vấn đề lớn nhất: Rủi ro được xử lý một cách hời hợt

Một trong những thách thức lớn nhất mà tôi thấy hiện nay trong phát triển phần mềm chính là việc lập kế hoạch và đánh giá rủi ro được thực hiện một cách hời hợt.

Tôi chắc chắn bạn sẽ đồng ý: không có gì tồi tệ hơn là phải làm lại (refactor) hoặc phải "chữa cháy" những sự cố lẽ ra có thể đã được thảo luận từ trước.

Chúng ta sống trong một thế giới mà thời gian là tiền bạc. Và chính vì thế mà chất lượng cần phải hiện diện ngay từ đầu — không phải như một giai đoạn cuối cùng, mà là một phần của quy trình.

Cadeia de erros

Là một QA, tôi xin chia sẻ hai điều mà tôi cho là cốt lõi.

Lắng nghe đội ngũ của bạn

Bất kể vị trí của bạn trong đội nhóm là gì, hãy lắng nghe những người xung quanh.

Không ai hiểu sản phẩm tốt hơn những người đã xây dựng, kiểm thử và làm việc với nó hàng ngày. Trước khi một tính năng mới được đưa vào hoặc một bài kiểm tra được thực hiện, hãy trò chuyện với đội ngũ.

Hãy lắng nghe người phát triển (dev). Hãy lắng nghe nhân viên sản phẩm (product). Hãy lắng nghe bộ phận hỗ trợ (support). Hãy lắng nghe những người ở gần người dùng nhất.

Rất nhiều lần, rủi ro đã được nhận diện bởi ai đó. Nhưng họ đơn giản là không được lắng nghe.

Phân tích trước khi hành động

Hiểu được tác động của một thay đổi không chỉ là vấn đề kỹ thuật — mà còn là vấn đề kinh doanh.

Ví dụ: bạn định tối ưu hóa query của một API. Về lý thuyết, điều này có thể không thay đổi bất kỳ quy tắc kinh doanh nào. Nhưng nó ảnh hưởng đến người dùng cuối như thế nào? Hiệu suất (performance) thực sự được cải thiện chưa? Có bất kỳ tác động phụ nào không? Làm thế nào để chúng ta đo lường xem thay đổi này là tích cực hay tiêu cực?

Không phải mọi cải tiến kỹ thuật đều tạo ra sự cải thiện cho sản phẩm. Và cái nhìn phản biện này là một phần fundamental trong vai trò của QA.

Kết luận

Hãy tóm lại, "Chernobyl" đã khiến tôi suy ngẫm về điều gì đó vượt xa một bộ phim truyền hình: trách nhiệm đằng sau mỗi quyết định mà chúng ta đưa ra hàng ngày.

Chúng ta không đang xử lý một lò phản ứng hạt nhân. Tuy nhiên, chúng ta vẫn đang đối mặt với những tác động thực tế — lên người dùng, lên doanh nghiệp và lên chính đội ngũ. Một rủi ro bị bỏ qua, một bài kiểm tra được lập kế hoạch kém hay một quyết định được đưa ra mà không lắng nghe đội ngũ có thể không gây ra một thảm họa hạt nhân, nhưng chắc chắn sẽ gây ra những vấn đề lẽ ra có thể tránh được với sự chú ý, đối thoại và phân tích nhiều hơn.

Đối với tôi, làm QA vượt xa việc tìm kiếm bug.

Là đặt câu hỏi trước khi vấn đề xảy ra. Là phân tích các kịch bản với cái nhìn phản biện. Là tiên lượng rủi ro. Là khơi gợi những cuộc trò chuyện quan trọng trong đội ngũ. Là giúp xây dựng các quyết định an toàn và minh bạch hơn.

Cuối cùng, chất lượng không chỉ là về phần mềm hoạt động trơn tru.

Đó là về trách nhiệm, sự hợp tác và sự quan tâm đến mọi thứ mà chúng ta tạo ra.