"Chi phí quan trọng hơn chất lượng, nhưng chất lượng là con đường tốt nhất để giảm chi phí" - Genichi Taguchi
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ễ [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.
Một bước không thể thiếu khi giải quyết vấn đề là xác định được nguyên nhân gốc của vấn đề đó. Tuy nhiên, trong nhiều trường hợp, một chuỗi nhiều sự kiện mang tính dây chuyền dẫn đến kết quả cuối cùng và do đó chúng ta thường chỉ xác định được nguyên nhân thứ cấp. Five Whys [5 câu hỏi tại sao] là một trong những phương pháp hiệu quả giúp xác định nguyên nhân gốc của mọi vấn đề.
Có ba yếu tố chính để sử dụng hiệu quả kỹ thuật Five Whys: [i] báo cáo chính xác và đầy đủ các vấn đề, [ii] trung thực hoàn toàn trong việc trả lời các câu hỏi, [iii] quyết tâm truy tìm tận gốc các vấn đề và giải quyết chúng. Công cụ này được phát triển bởi Sakichi Toyoda cho tập đoàn Toyota.
Đọc thêm:
Quy trình thực hiện Five Whys
Quy trình Five-Whys sẽ càng hiệu quả khi được áp dụng theo nhóm và bao gồm năm bước cơ bản:
1. Tập hợp một nhóm và phát triển một bản mô tả vấn đề. Từ đó quyết định xem nhóm có cần thêm cá nhân nào để giải quyết vấn đề hay không.
2. Đặt câu hỏi "tại sao" đầu tiên của nhóm: tại sao vấn đề này lại xảy ra? Có thể sẽ có ba hoặc bốn câu trả lời hợp lý: ghi lại tất cả trên một bảng flip chart hoặc bảng trắng.
3. Hỏi thêm lần lượt 4 câu hỏi “tại sao’’, lặp lại quy trình cho mọi vấn đề trên bảng. Đưa mỗi câu trả lời tới gần hơn "nguồn gốc" của nó. Theo dõi tất cả các câu trả lời hợp lý. Bạn sẽ xác định nguyên nhân gốc rễ khi câu hỏi "tại sao" không mang lại thêm thông tin hữu ích nào. [Nếu cần thiết, tiếp tục đặt câu hỏi ngoài năm câu hỏi đó tùy ý để tìm ra nguyên nhân gốc.]
Đọc thêm:
4. Tìm kiếm những nguyên nhân mang tính hệ thống của vấn đề trong số những câu trả lời cho câu hỏi "tại sao" cuối cùng. Thảo luận và chọn ra nguyên nhân hợp lý nhất. Trình bày kết quả tìm được với các nhóm khác để tìm sự đồng thuận.
5. Đề xuất các biện pháp khắc phục thích hợp để loại bỏ nguyên nhân gốc rễ khỏi hệ thống.
Ví dụ thực tế về cách Jeff Bezos ứng dụng Five Whys
Khi đến kiểm tra một Trung tâm xử lý đơn hàng của Amazon.com, tỷ phú Jeff Bezos được biết một nhân viên ở đây vừa gặp tai nạn lao động và gãy một ngón tay. Ông tìm một bảng trắng và bắt đầu sử dụng kỹ thuật Five Whys.
Tại sao ngón tay cái của người nhân viên bị thương?
- Bởi vì ngón cái của anh ta bị kẹt trong băng chuyền.
Tại sao ngón cái của anh bị kẹt trong băng chuyền?
- Bởi vì anh ta đang đuổi theo cái túi của mình, trên một băng chuyền đang chạy.
Tại sao anh ta đuổi theo chiếc túi của mình?
- Bởi vì anh ta đã đặt túi của mình lên băng chuyền, và sau đó bang chuyền bất ngờ hoạt động.
Tại sao túi của anh ấy lại trên băng chuyền?
- Bởi vì anh ta đang sử dụng băng tải như một cái bàn.
Và như vậy, nguyên nhân sâu xa của ngón tay cái bị thương của người nhân viên là anh ta chỉ cần một cái bàn. Vì xung quanh không có cái bàn nào và anh ta phải sử dụng băng chuyền như một cái bàn tạm. Để loại bỏ các trường hợp tương tự, Amazon.com cần cung cấp bàn tại các vị trí thích hợp và cập nhật đào tạo an toàn.