Những dữ liệu cần thu thập để chẩn đoán vấn đề

Một bộ dữ liệu tốt không nhất thiết phải rất lớn. Giá trị nằm ở khả năng xác định chính xác trạng thái bất thường, dựng lại diễn biến và so sánh trường hợp có vấn đề với trạng thái bình thường. Nếu chưa có các dữ liệu này, việc hỏi “nguyên nhân là gì?” thường diễn ra quá sớm.

Mô tả chính xác hiện trạng và trạng thái kỳ vọng

Dữ liệu đầu tiên cần thu thập là khoảng cách giữa những gì đang xảy ra và những gì lẽ ra phải xảy ra. Chỉ ghi “hệ thống lỗi”, “doanh số giảm” hay “máy hoạt động không ổn định” chưa đủ để chẩn đoán vì những mô tả này không xác định được bất thường cụ thể.

Cần ghi riêng hai trạng thái:

·         Hiện trạng: Kết quả, hành vi, thông số hoặc hiện tượng thực tế quan sát được

·         Trạng thái kỳ vọng: Kết quả hoặc điều kiện được xem là bình thường theo yêu cầu, thông số, quy trình, dữ liệu lịch sử hoặc mẫu đối chứng

·         Mức chênh lệch: Điểm nào khác, khác bao nhiêu nếu đo được và khác theo hướng nào

Ví dụ, thay vì ghi “thời gian xử lý đơn hàng chậm”, dữ liệu hữu ích hơn là thời gian xử lý thực tế của các đơn bị ảnh hưởng và thời gian tương ứng ở trạng thái bình thường. Nếu chưa có ngưỡng chính thức, vẫn có thể đối chiếu với dữ liệu trước khi vấn đề xuất hiện hoặc với các trường hợp không bị ảnh hưởng.

Điểm quan trọng là không đưa giả thuyết nguyên nhân vào phần mô tả hiện trạng. “Máy dừng do quá nhiệt” đã chứa một kết luận nhân quả; trong khi “máy dừng lúc 14:32, cảm biến nhiệt ghi nhận X tại thời điểm đó” giữ nguyên dữ kiện để nguyên nhân còn có thể được kiểm tra.

Ghi thời điểm bắt đầu và diễn biến của vấn đề

Thời gian giúp thu hẹp rất nhiều khả năng cần kiểm tra. Không chỉ cần biết “vấn đề xảy ra hôm nay”, mà cần xây dựng được một timeline đủ chi tiết để liên hệ hiện tượng với các sự kiện trước, trong và sau thời điểm phát sinh.

Nên thu thập:

·         Thời điểm gần nhất trạng thái vẫn bình thường

·         Thời điểm đầu tiên xác nhận có bất thường

·         Các lần vấn đề xuất hiện sau đó

·         Khoảng thời gian vấn đề kéo dài

·         Tần suất hoặc quy luật lặp lại nếu có

·         Thời điểm vấn đề tự biến mất hoặc trạng thái trở lại bình thường

·         Thời gian ghi nhận của từng bằng chứng liên quan

Khoảng giữa “lần cuối bình thường” và “lần đầu bất thường” đặc biệt có giá trị. Đây là cửa sổ thời gian để kiểm tra những thay đổi có khả năng liên quan mà không phải rà soát toàn bộ lịch sử.

Dữ liệu thời gian cũng phải được đọc trong đúng bối cảnh. Hai sự kiện xảy ra gần nhau không tự động chứng minh quan hệ nhân quả. Timeline chỉ giúp xác định điều gì đáng được kiểm tra, còn việc kết luận nguyên nhân cần thêm bằng chứng.

Xác định phạm vi ảnh hưởng và điều kiện vấn đề xuất hiện

Một vấn đề thường không ảnh hưởng mọi đối tượng theo cùng một cách. Vì vậy cần thu thập cả dữ liệu về nơi vấn đề xảy ra và nơi đáng lẽ có thể xảy ra nhưng thực tế không xảy ra.

Phạm vi nên được mô tả theo các chiều phù hợp với đối tượng đang chẩn đoán, chẳng hạn:

·         Bộ phận, khu vực, thiết bị, hệ thống hoặc công đoạn bị ảnh hưởng

·         Nhóm người dùng, giao dịch, sản phẩm hoặc dữ liệu bị ảnh hưởng

·         Phiên bản, cấu hình, môi trường hoặc chế độ vận hành liên quan

·         Điều kiện đầu vào khi vấn đề xuất hiện

·         Các trường hợp tương tự nhưng vẫn hoạt động bình thường

Các trường hợp không xảy ra vấn đề là dữ liệu đối chứng rất quan trọng. Nếu cùng một quy trình nhưng chỉ một nhóm đầu vào phát sinh lỗi, sự khác biệt giữa hai nhóm có thể giúp loại bỏ nhiều giả thuyết. Ngược lại, nếu hiện tượng xuất hiện trên mọi nhóm và mọi điều kiện, phạm vi tìm kiếm phải được đặt rộng hơn.

Cần tránh lấy một vài trường hợp nổi bật làm đại diện cho toàn bộ vấn đề. Phạm vi chỉ nên được xác lập từ những trường hợp đã kiểm tra hoặc từ dữ liệu cho phép xác nhận mức ảnh hưởng.

Kiểm tra những gì đã thay đổi trước khi vấn đề xuất hiện

Khi đã xác định được cửa sổ thời gian, cần lập danh sách những thay đổi xảy ra trong hoặc ngay trước khoảng đó. Đây thường là dữ liệu có Information Gain cao vì một trạng thái đang ổn định chuyển sang bất thường phải được xem xét trong mối quan hệ với những điều kiện đã thay đổi.

Dữ liệu thay đổi có thể gồm:

·         Cấu hình hoặc tham số

·         Phiên bản phần mềm, thiết bị hoặc thành phần

·         Quy trình hay cách thao tác

·         Nhân sự hoặc quyền truy cập

·         Nguồn nguyên liệu, đầu vào hoặc nhà cung cấp

·         Tải, lưu lượng hoặc khối lượng công việc

·         Điều kiện môi trường

·         Hoạt động bảo trì, triển khai, hiệu chỉnh hoặc thay thế

Cần ghi thay đổi gì, ai hoặc thành phần nào thực hiện, thời điểm nào, phạm vi nào và có bằng chứng xác nhận hay không.

Danh sách này không phải danh sách nguyên nhân. Một thay đổi xảy ra trước vấn đề chỉ tạo ra một ứng viên cần kiểm tra. Nếu gắn nhãn nguyên nhân ngay khi thấy sự trùng hợp về thời gian, quá trình chẩn đoán dễ bỏ qua các yếu tố khác cũng thay đổi trong cùng khoảng.

Thu bằng chứng gốc thay vì chỉ thu nhận định

Mô tả của người quan sát rất hữu ích để biết phải tìm ở đâu, nhưng chẩn đoán cần thêm những bằng chứng có thể kiểm tra lại. Vì vậy phải phân biệt rõ dữ kiện gốc với cách một người diễn giải dữ kiện đó.

Tùy vấn đề, bằng chứng có thể là:

·         Log hoặc lịch sử sự kiện

·         Số đo từ thiết bị, cảm biến hoặc hệ thống giám sát

·         Báo cáo, bản ghi giao dịch hoặc lịch sử xử lý

·         Ảnh chụp, video hoặc ảnh chụp màn hình

·         Thông báo lỗi và mã lỗi nguyên bản

·         Cấu hình tại thời điểm xảy ra sự cố

·         Lịch sử thay đổi

·         Mẫu vật, đầu ra lỗi hoặc kết quả kiểm tra

·         Lời thuật lại của người trực tiếp chứng kiến, kèm thời gian và bối cảnh

Bằng chứng nên giữ càng gần dữ liệu nguyên bản càng tốt. Chẳng hạn, ghi lại toàn bộ thông báo lỗi liên quan hữu ích hơn việc chỉ viết “có lỗi kết nối”, vì phần bị lược bỏ có thể chứa thời điểm, thành phần hoặc điều kiện cần cho việc phân biệt các giả thuyết.

Nguồn bằng chứng cũng cần được ghi lại. Một ảnh chụp không có thời điểm hoặc một con số không biết lấy từ hệ thống nào có giá trị chẩn đoán thấp hơn dữ liệu có nguồn, thời gian và bối cảnh rõ ràng.

Kiểm tra khả năng tái hiện và tạo dữ liệu đối chứng

Nếu vấn đề có thể được lặp lại một cách an toàn, cần ghi chính xác chuỗi điều kiện và hành động dẫn đến hiện tượng. Khả năng tái hiện biến một sự kiện khó quan sát thành một tình huống có thể kiểm tra nhiều lần.

Một bản ghi tái hiện nên cho biết:

1.    Trạng thái ban đầu

2.    Đầu vào hoặc điều kiện sử dụng

3.    Các bước đã thực hiện

4.    Điểm vấn đề xuất hiện

5.    Kết quả quan sát được

6.    Kết quả của cùng phép thử trong trường hợp bình thường

Không phải vấn đề nào cũng nên hoặc có thể tái hiện. Sự cố liên quan đến an toàn, dữ liệu quan trọng hoặc hệ thống đang vận hành có thể khiến việc cố tình tạo lại hiện tượng không phù hợp. Khi đó, dữ liệu lịch sử và bằng chứng tại thời điểm xảy ra vấn đề phải đóng vai trò lớn hơn.

Nếu có thể tạo đối chứng, chỉ nên thay đổi từng yếu tố có ý nghĩa trong khi giữ các điều kiện còn lại đủ ổn định. Khi nhiều yếu tố cùng thay đổi, việc hiện tượng biến mất hoặc xuất hiện trở lại vẫn chưa cho biết yếu tố nào thực sự liên quan.

Kiểm tra chất lượng dữ liệu trước khi bắt đầu chẩn đoán

Có đủ loại dữ liệu nhưng dữ liệu không đồng nhất cũng có thể dẫn đến kết luận sai. Trước khi phân tích nguyên nhân, cần kiểm tra xem các bằng chứng có đang mô tả cùng một sự kiện, cùng khoảng thời gian và cùng phạm vi hay không.

Đặc biệt cần rà soát:

·         Thời gian trên các nguồn dữ liệu có cùng mốc tham chiếu hay không

·         Bản ghi có bị thiếu một khoảng quan trọng hay không

·         Số liệu là dữ liệu gốc hay đã được tổng hợp

·         Đơn vị đo và cách đo có thống nhất không

·         Bằng chứng có thực sự thuộc đối tượng bị ảnh hưởng không

·         Dữ liệu được thu trước hay sau khi đã có một thay đổi can thiệp

·         Có trường hợp bình thường đủ tương đồng để đối chiếu hay không

Điều này ngăn việc xây dựng một câu chuyện nhân quả từ các dữ kiện vốn không cùng bối cảnh. Nếu hai nguồn mâu thuẫn, nên giữ lại mâu thuẫn đó như một vấn đề cần xác minh thay vì lựa chọn ngay nguồn phù hợp nhất với giả thuyết đang có.

Một bộ dữ liệu tối thiểu trước khi chẩn đoán nên có gì

Có thể bắt đầu chẩn đoán khi hồ sơ đã đủ để dựng lại vấn đề mà không phải dựa chủ yếu vào trí nhớ hoặc suy đoán. Bộ dữ liệu tối thiểu nên trả lời được:

·         Vấn đề là gì: Hiện trạng cụ thể và trạng thái kỳ vọng

·         Bắt đầu khi nào: Lần cuối bình thường, lần đầu bất thường và diễn biến sau đó

·         Ảnh hưởng ở đâu: Đối tượng, phạm vi và mức ảnh hưởng đã xác nhận

·         Xảy ra trong điều kiện nào: Đầu vào, môi trường, cấu hình hoặc hoàn cảnh đi kèm

·         Không xảy ra ở đâu: Các trường hợp đối chứng vẫn bình thường

·         Có gì thay đổi: Những thay đổi nằm trong cửa sổ thời gian liên quan

·         Bằng chứng nào xác nhận: Log, số đo, bản ghi, ảnh, lịch sử thay đổi hoặc vật chứng phù hợp

·         Có tái hiện được không: Điều kiện và chuỗi thao tác dẫn đến hiện tượng, nếu việc tái hiện phù hợp

·         Dữ liệu có đáng tin không: Nguồn, thời điểm, đơn vị và bối cảnh của bằng chứng đã được kiểm tra

Không nhất thiết phải biết nguyên nhân mới hoàn thành bước thu thập dữ liệu. Ngược lại, mục tiêu của giai đoạn này là tạo ra một tập dữ kiện đủ rõ để các giả thuyết nguyên nhân sau đó có thể được đối chiếu, bác bỏ hoặc củng cố bằng bằng chứng.

Dữ liệu chẩn đoán vấn đề nên bắt đầu từ sự khác biệt giữa thực tế và kỳ vọng, sau đó bổ sung timeline, phạm vi, điều kiện, thay đổi gần thời điểm phát sinh, bằng chứng gốc và dữ liệu đối chứng. Điều quan trọng nhất là giữ dữ kiện tách khỏi giả thuyết: những gì đã quan sát và kiểm chứng được tạo nền cho chẩn đoán; còn nguyên nhân chỉ nên được kết luận sau khi các giả thuyết đã được kiểm tra bằng chính tập dữ liệu đó.