Phân tích nguyên nhân gốc rễ: 4 bí quyết để khắc phục lỗi nhanh hơn

Hãy hình dung thế này: bạn và đội ngũ của mình đang làm việc suốt ngày đêm để hoàn thành phiên bản quan trọng tiếp theo của sản phẩm phần mềm. Bạn đang tạo ra các tính năng mới với tốc độ ổn định. Đội ngũ sửa lỗi ngay khi có báo cáo QA. Các bài kiểm tra đơn vị đều đạt. Sau khi trải qua một loạt các kiểm tra toàn diện hơn, ứng dụng được phê duyệt và đã đến lúc cho ứng dụng ra mắt. Rồi sau đó—bùm! Ngay khi được đưa vào môi trường sản xuất, ứng dụng bị văng một cách ngoạn mục. Đã xảy ra sai sót ở đâu?

Hóa ra là do các môi trường thử nghiệm không hề sát với môi trường sản xuất như bạn từng nghĩ. Môi trường đã có những thay đổi về cơ sở hạ tầng mà không có bất kỳ ghi chép nào. Kết quả là các môi trường dần dần lệch nhau.

Là các chuyên gia trong ngành công nghệ, chúng tôi dành phần lớn thời gian để khắc phục lỗi. Và lẽ đương nhiên, chúng tôi cũng dành thời gian để sửa lỗi—nhưng bạn không thể sửa lỗi khi bản thân không biết trục trặc nằm ở đâu. Bất kỳ nhà phát triển phần mềm nào đã dành hàng giờ trước trình gỡ lỗi cũng sẽ cho bạn biết rằng thông thường, phần thực sự khó khăn là tìm ra lỗi. Ngay khi bạn biết vấn đề là gì, việc sửa lỗi có khi chỉ là chuyện nhỏ nhặt.

Vì vậy, tìm hiểu cách khắc phục sự cố nhanh hơn là một trong những khoản đầu tư tối ưu của bạn trong vai trò nhà phát triển phần mềm hoặc nhân viên CNTT nói chung.

Hãy nói về cách chúng ta có thể tìm ra vấn đề trong thời gian ngắn và sửa chúng nhanh hơn.

Phân tích nguyên nhân gốc rễ: Định nghĩa và lý do vì sao bạn nên quan tâm?

Phân tích nguyên nhân gốc rễ (RCA) là một kỹ thuật đặc thù bạn có thể sử dụng để khắc phục vấn đề. Với kỹ thuật này, bạn có thể phân tích sự cố mình gặp phải bằng cách sử dụng một tập hợp các bước cụ thể để xác định nguyên nhân chính gây ra vấn đề. RCA dựa trên nguyên tắc như sau: nếu chỉ chú trọng đến dấu hiệu của vấn đề mà bỏ qua gốc rễ thì sẽ không mang lại hiệu quả.

Bằng cách sử dụng RCA, bạn sẽ có thể hiểu chuyện gì đã xảy ra. Thông thường, bạn không thể hình dung toàn cảnh chỉ bằng cách quan sát các dấu hiệu. Tuy nhiên, xác định chuyện gì đã xảy ra chỉ là bước đầu tiên—sau đó, bạn cần phải tìm hiểu sâu hơn và khám phá lý do dẫn đến sự cố. Khi đã nắm được kiến thức đó, đã đến lúc áp dụng vào thực tiễn bằng cách xây dựng một kế hoạch hoặc chiến lược để làm giảm xác suất tái diễn.

Vậy là đã xong phần định nghĩa và lý do cần quan tâm. Sau đây là bốn bí quyết về việc sử dụng RCA để vấn đề xảy ra ít hơn.

Sử dụng phương pháp rubber duck (vịt cao su)
Vâng, tôi nghiêm túc đấy, đúng là có phương pháp vịt cao su. Tôi không bịa ra đâu. Người ta còn gọi đó là rubber-duck debugging (phương pháp gỡ lỗi vịt cao su) và có thể còn có nhiều tên hơn nữa. Phương pháp này bao gồm việc giải thích vấn đề của bạn cho một chú vịt cao su. Bạn không có một chú vịt cao su ư? Đừng lo lắng! Bạn có thể sử dụng bất kỳ đồ vật vô tri nào tình cờ nằm trong tầm tay của bạn. Hoặc thậm chí bạn có thể nói chuyện với một ai đó cũng được!

Vậy phương pháp vịt cao su thực sự là gì? Phương pháp này dựa trên hiệu ứng quan sát được rằng bằng cách giải thích điều gì đó với một ai đó, bạn buộc bản thân mình phải sắp xếp suy nghĩ. Quá trình suy nghĩ của chúng ta thường hỗn loạn hoặc lộn xộn. Khi đối mặt với viễn cảnh thực sự phải giải thích suy nghĩ của mình cho ai đó, chúng ta không còn sự lựa chọn nào khác ngoài việc sắp xếp suy nghĩ theo cách nào đấy. Jeff Atwood, người đồng sáng lập của trang web hỏi đáp nổi tiếng Stack Overflow, nói về số lần một nhà phát triển phần mềm đã kể ông nghe về việc viết một câu hỏi mới cho trang web, tự bản thân họ tìm ra câu trả lời trong quá trình viết câu hỏi và chưa bao giờ thực sự gửi câu hỏi lên trang web!

Phương pháp vịt cao su có đủ để khắc phục mọi sự cố không? Đương nhiên là không. Có thể là có, nhưng thông thường phương pháp này chỉ là bước đầu tiên trong một chiến lược lớn hơn.

Bạn có sợ mọi người nghĩ rằng bạn hơi kỳ quặc khi nói chuyện với những đồ vật vô tri không? Vấn đề là toàn bộ ý tưởng về chú vịt cao su có một chút là chuyện đùa. Đó là một nhân vật ngốc nghếch và dễ ghi nhớ, không cần phải được xem xét một cách nghiêm túc. Điều quan trọng là bạn buộc bản thân mình phải thể hiện suy nghĩ trong đầu một cách có trật tự, giải thích vấn đề bạn gặp phải một cách rõ ràng nhất có thể.

Bạn có thể sử dụng các phương pháp sau đây:
1. Viết một câu hỏi lên trang Stack Overflow. Hoặc bạn có thể giả vờ như đang viết một câu hỏi lên trang Stack Overflow nhưng thay vào đó hãy viết vào Notepad.
2. Gửi báo cáo lỗi chi tiết. Dù sao thì chắc ai đó đã báo cáo lỗi rồi, vậy thì, tại sao lại không bắn một mũi tên trúng hai đích nhỉ?
3. Đến chỗ làm việc/văn phòng của đồng nghiệp rồi nói chuyện với họ trong vài phút. Đương nhiên là nếu họ đồng ý nói chuyện. Đừng làm phiền đồng nghiệp của bạn khi không cần thiết.


Thu thập nhiều dữ liệu nhật ký (và tìm kiếm trong dữ liệu nhật ký một cách hiệu quả)

Nếu bạn đã giải thích thành công vấn đề một cách rõ ràng nhưng vẫn không thể tìm ra nguyên nhân gốc rễ, lúc đó, bạn phải tìm hiểu sâu hơn. Điều cần thiết lúc này là phải thu thập dữ liệu về vấn đề rồi trích xuất thông tin chi tiết từ dữ liệu đó.

Việc ghi nhật ký và giám sát có thể hữu ích trong trường hợp này—nhật ký tình trạng văng, nhật ký ứng dụng và máy chủ và những thứ tương tự như vậy. Bạn phải thu thập bằng chứng về việc vấn đề đã xảy ra đồng thời, nếu có thể, phải tìm hiểu xem vấn đề xảy ra trong bao lâu với tần suất ra sao.

Tuy nhiên, bạn không thể dừng ở đó. Việc thu thập nhiều dữ liệu có ý nghĩa quan trọng nhưng tất cả dữ liệu đó sẽ không có ích gì nếu bạn không tìm ra các bit dữ liệu cụ thể mà bạn cần đủ nhanh. Bị mắc kẹt trong tình huống “mò kim đáy bể” không vui vẻ cũng không hề hiệu quả chút nào.

Đó là lý do bạn phải sử dụng các công cụ hỗ trợ bạn tìm kiếm cũng như phân tích tất cả dữ liệu nhật ký bạn đã và đang thu thập theo thời gian thực, đồng thời biến dữ liệu thành thông tin chi tiết có giá trị mà bạn có thể sử dụng để chẩn đoán và giải quyết vấn đề nhanh hơn.


Sử dụng kỹ thuật “năm tại sao”
Sau khi bạn thu thập thông tin, đã đến lúc sử dụng thông tin đó bằng cách xác định các yếu tố nhân quả. “Yếu tố nhân quả” ở đây nghĩa là nguyên nhân trực tiếp dẫn đến vấn đề bạn gặp phải. Bạn không nên xác định một yếu tố nhân quả rồi sau đó dừng lại. Bạn phải tìm hiểu sâu hơn. Một trong những kỹ thuật nổi tiếng nhất cho việc đó là kỹ thuật “năm tại sao”.

Kỹ thuật đó bao gồm việc hỏi đi hỏi lại “Tại sao lại như vậy?” cho đến khi bạn tìm ra được gốc rễ của vấn đề. Hãy xem một ví dụ nhanh:

Vấn đề: Trang web hiển thị lỗi 500.
1. Tại sao lại như vậy? Bởi vì thành phần định tuyến của khung trang web gặp trục trặc.
2. Tại sao lại như vậy? Bởi vì trang web đòi hỏi một thành phần khác mà chính bản thân trang web gặp trục trặc.
3. Tại sao lại như vậy? Bởi vì thành phần này của khung trang web đòi hỏi tiện ích mở rộng intl mà tiện ích này không hoạt động.
4. Tại sao lại như vậy? Bởi vì trang web tình cờ bị vô hiệu hóa sau khi phần mềm máy chủ được cập nhật.

Như bạn có thể thấy, con số năm chỉ mang tính chất minh họa. Chúng ta có thể tìm ra vấn đề gốc rễ thông qua số bước ít hơn. Hoặc thậm chí bạn có thể cần nhiều bước hơn.

Kỹ thuật “năm tại sao” còn lâu mới đạt sự hoàn hảo. Kỹ thuật này đã chịu nhiều chỉ trích và chắc chắn có sự hạn chế. Tuy nhiên, nó có thể hữu ích trong việc khuyến khích các kỹ sư tiếp tục tìm kiếm nguyên nhân gốc rễ của vấn đề thay vì dừng lại ở dấu hiệu đầu tiên khi tiếp cận với một giải pháp.


Kiểm tra lại
Trong sự nghiệp làm nhà phát triển phần mềm của mình, có một phương pháp mà tôi đánh giá cao là xem lại mã. Một thực tế đơn giản là khi để một người khác, một ai đó trung lập xem mã của bạn, họ có thể khám phá ra rất nhiều vấn đề mà trước đó bạn không thể nhìn ra. Đây quả là điều đáng kinh ngạc. Cùng với thời gian, kỳ vọng lớn lao về việc để một người khác xem mã của bạn khiến bạn nhận thức vấn đề về mã rõ hơn. Bạn bắt đầu dành nhiều sự chú ý hơn so với trước.

Như vậy, với quan điểm này, tôi đang đề xuất việc xem lại mã, đúng không? Đúng vậy, nhưng đó không phải cách duy nhất bạn có thể kiểm tra lại sản phẩm của mình. Tôi khuyên bạn nên sử dụng các quy trình tương tự việc xem lại cho hầu hết mọi nhiệm vụ mà một kỹ sư thực hiện. Hoặc làm việc theo đôi là phương pháp còn tốt hơn thế. Lập trình đôi, cấu hình máy chủ đôi, gỡ lỗi đồng cấp và hỗ trợ trực tiếp đồng cấp cho khách hàng. Nói ngắn gọn: thực hiện khắc phục vấn đề theo đôi.

Khoa học hay kỹ xảo?

Khắc phục lỗi tại một giai đoạn khi mà lỗi đó vẫn mang tính kỹ xảo hơn là khoa học. Tuy nhiên, việc đó không ngăn được bạn sử dụng các kỹ thuật và công cụ để tăng hiệu suất thực hiện.

Vì vậy, hãy sử dụng những kỹ thuật này để thực hiện RCA:
1. Sử dụng phương pháp rubber duck (vịt cao su)
2. Thu thập nhiều dữ liệu nhật ký và sử dụng công cụ phù hợp để tìm kiếm rồi phân tích dữ liệu
3. Sử dụng kỹ thuật “năm tại sao”
4. Kiểm tra lại

Đã đến lúc tóm lấy chú vịt cao su của bạn và bắt đầu phân tích nguyên nhân gốc rễ của vấn đề rồi.

Tìm hiểu thêm về giá của Amazon OpenSearch Service

Truy cập vào trang giá
Bạn đã sẵn sàng xây dựng chưa?
Bắt đầu sử dụng Amazon OpenSearch Service
Bạn có thêm câu hỏi?
Liên hệ với chúng tôi