INFOCHIEF ACADEMY · ITIL 4 KNOWLEDGE SERIES

Problem Management: Từ xử lý sự cố lặp lại đến quản lý nguyên nhân gốc.

Problem Management nối dấu hiệu, giả thuyết và bằng chứng với lựa chọn giảm nguy cơ. Workaround và known error cần điều kiện cùng người sở hữu, để hiểu nguyên nhân dẫn tới biện pháp được kiểm chứng trong dịch vụ.

Biên soạn: Infochief Academy · Chuyên đề: Quản lý dịch vụ theo ITIL 4

← Trở về thư viện bài viết

Minh họa biên tập: người phân tích problem cùng kỹ sư và chủ dịch vụ đối chiếu diễn biến, bằng chứng.

Dịch vụ được khôi phục sau mỗi lần khởi động lại, nhưng lỗi vẫn xuất hiện khi nhu cầu tăng. Nhóm hỗ trợ xử lý thành thạo, còn người dùng mất tin vì cùng một vấn đề tiếp tục làm gián đoạn công việc. Khả năng phục hồi nhanh đang che một nguy cơ chưa được quản lý.

Problem Management trong ITIL 4 hướng tới giảm khả năng và tác động của sự cố bằng việc xác định nguyên nhân thực tế hoặc tiềm ẩn, quản lý workaround và known error. Trọng tâm không chỉ là tìm một câu trả lời về nguyên nhân. Cần biến hiểu biết thành lựa chọn có trách nhiệm và kiểm tra biện pháp có tác dụng.

Mở problem từ bằng chứng và tác động

Một problem là nguyên nhân hoặc nguyên nhân tiềm ẩn của một hay nhiều incident. Không cần chờ lỗi lặp nhiều lần mới xem xét, vì một sự cố có tác động lớn hoặc một dấu hiệu nguy cơ có thể đáng ưu tiên. Ngược lại, không phải mọi ticket đều cần một cuộc điều tra sâu như nhau.

Nhóm cần nhìn tác động, khả năng tái diễn, điều đã biết và nguồn lực. Ưu tiên problem có thể khác ưu tiên phục hồi incident. Một lỗi đang được khôi phục tạm có thể vẫn cần xử lý cao vì workaround tạo công việc hoặc rủi ro đáng kể, trong khi một lỗi nhỏ đã có cách quản lý phù hợp có thể được thực hiện sau.

Dữ liệu incident giúp nhận diện mẫu, nhưng cùng triệu chứng không tự chứng minh cùng nguyên nhân. Cần xem thời điểm, điều kiện, thành phần và diễn biến. Gộp hồ sơ quá sớm có thể che nhiều cơ chế khác nhau; tách quá nhiều có thể làm mất mối liên hệ cần điều tra.

Nền tảng trong chương trình ITIL 4 Foundation là hướng tham khảo để thống nhất mục đích và thuật ngữ. Trong áp dụng, người sở hữu problem cần phạm vi cùng tiêu chí ưu tiên, để việc điều tra không chỉ dựa vào người nào có thời gian hoặc hứng thú với lỗi kỹ thuật.

Giữ mục tiêu phục hồi và điều tra khác nhau

Incident Management phục hồi khả năng sử dụng, còn Problem Management quản lý nguyên nhân và nguy cơ liên quan. Hai mục tiêu cần chia sẻ thông tin nhưng không trộn. Dịch vụ có thể được khôi phục trước khi nguyên nhân đủ rõ; kết luận nguyên nhân cũng chưa tự chứng minh biện pháp đã giải quyết tác động.

Trong lúc phục hồi, cần giữ diễn biến và hành động đủ để điều tra sau. Không nên để áp lực đóng incident làm mất thông tin về cấu hình, dữ liệu hoặc phương án tạm. Nhưng cũng không bắt mọi sự cố chờ phân tích đầy đủ nếu đã có lựa chọn phục hồi phù hợp và được kiểm soát.

Known error trong ITIL 4 là problem đã được phân tích nhưng chưa được giải quyết. Cần mô tả điều đã biết cùng giới hạn, không gọi một giả thuyết chưa kiểm chứng là kết luận chắc chắn. Workaround là cách giảm hoặc loại tác động trong điều kiện nhất định khi chưa có cách giải quyết đầy đủ.

Không phải known error nào cũng luôn có workaround dùng được. Khi có, cần phạm vi, điều kiện, quyền và cách kiểm tra. Một hướng dẫn khởi động lại có thể phục hồi triệu chứng nhưng làm mất dữ liệu hoặc tạo rủi ro nếu áp dụng ngoài điều kiện, nên tri thức phải được quản lý chứ không chỉ truyền miệng.

Điều tra bằng giả thuyết có thể kiểm chứng

Nhóm cần tách điều đã quan sát khỏi cách giải thích. “Lỗi xuất hiện khi tải tăng” là một nhận định cần dữ liệu về điều kiện; “thiếu năng lực xử lý” là giả thuyết cần kiểm chứng. Sự phân biệt giúp tránh chọn biện pháp chỉ vì nó quen thuộc hoặc xuất hiện gần thời điểm lỗi.

Một dòng thời gian có thể nối tác động, thay đổi, cảnh báo và hành động. Dữ liệu phải giữ nguồn và phạm vi để người đọc biết điều gì được xác nhận. Đối chiếu các lần lỗi với trường hợp không lỗi giúp kiểm tra điều kiện, thay vì chỉ tìm chi tiết có thể kể thành một câu chuyện hợp lý.

Nguyên nhân có thể gồm nhiều yếu tố. Một cấu hình không phù hợp, dữ liệu đặc thù và thiếu kiểm thử có thể cùng tạo lỗi; hành động của con người có thể là điểm xuất hiện chứ chưa phải cơ chế đầy đủ. Kết luận nên giúp tổ chức chọn biện pháp, không chỉ tìm một người để quy trách nhiệm.

Phần hồ sơ đề xuất	Nội dung cần giữ	Cách dùng khi quyết định
Quan sát	Triệu chứng, tác động và điều kiện	Xác định phạm vi problem
Giả thuyết	Cơ chế nghi ngờ và bằng chứng cần thêm	Chọn kiểm tra hoặc thử phù hợp
Workaround	Phạm vi, giới hạn và kết quả	Giảm tác động có kiểm soát
Kết luận phân tích	Căn cứ cùng điều còn chưa chắc	Chọn biện pháp và ưu tiên
Hành động	Chủ sở hữu, điều kiện và cách xác nhận	Kiểm tra tác dụng sau thực hiện

Bảng là công cụ tổ chức bằng chứng đề xuất, không phải biểu mẫu chính thức của ITIL. Mức chi tiết phải phù hợp tác động. Một hồ sơ dài chưa bảo đảm điều tra tốt nếu không giải thích được bằng chứng hỗ trợ hoặc bác bỏ giả thuyết nào.

Năng lực phân tích và sử dụng diễn biến có thể được phát triển qua chương trình Xử Lý Sự Cố và Phân Tích Nguyên Nhân. Trong thực hành, các kỹ thuật cần được dùng để kiểm chứng cơ chế, không trở thành cách điền một sơ đồ nguyên nhân rồi coi kết luận đã đủ.

Một lỗi lặp được nhìn lại sau workaround

Tình huống giả định: ứng dụng xử lý hồ sơ thường chậm ở một khoảng thời gian. Khởi động lại giúp phục hồi, nên nhóm vận hành coi đó là phương án quen thuộc. Nhưng người dùng phải làm lại một phần thao tác, còn các nhóm khác bị ngắt công việc để hỗ trợ.

Problem được mở theo tác động và mẫu điều kiện. Nhóm giữ dữ liệu về thời điểm, loại hồ sơ, tải và các thay đổi. Giả thuyết ban đầu về thiếu tài nguyên được đối chiếu với những khoảng thời gian không lỗi. Dữ liệu cho thấy cần xem một luồng xử lý đặc thù, thay vì chỉ tăng cấu hình.

Nhóm thực hiện kiểm tra trong môi trường và phạm vi phù hợp, phối hợp người hiểu dữ liệu và chủ ứng dụng. Workaround tiếp tục được quản lý để giảm tác động, với điều kiện và việc đối soát rõ. Người dùng nhận hướng dẫn nhất quán, không phải mỗi lần thử một thao tác khác nhau theo người hỗ trợ.

Kết luận phân tích tạo đầu vào cho thay đổi giải pháp và kiểm thử. Tuy nhiên, biện pháp phải được triển khai qua cơ chế phù hợp và xác nhận sau thực hiện. Việc xác định một lỗi trong mã hoặc cấu hình chưa đủ để đóng toàn bộ trách nhiệm nếu dịch vụ thực vẫn chưa được kiểm chứng.

Chọn biện pháp theo tác dụng và khả năng duy trì

Không phải mọi problem đều được loại bỏ ngay. Tổ chức có thể chọn sửa, thay phương án, tiếp tục quản lý workaround hoặc chấp nhận phần rủi ro theo đúng quyền. Lựa chọn phải phản ánh tác động, nguồn lực và chi phí duy trì, không để problem tồn vô hạn chỉ vì workaround đang dùng được.

Nếu chấp nhận tiếp tục, cần người sở hữu, thời điểm xem lại và dấu hiệu kích hoạt. Khi phạm vi sử dụng hoặc dữ liệu thay đổi, điều kiện cũ có thể không còn phù hợp. Một workaround từng an toàn không nên được mở rộng chỉ vì nhóm đã quen áp dụng.

Tri thức cần tới người xử lý incident và chủ dịch vụ. Cách tìm, cập nhật và kiểm tra nội dung quan trọng không kém việc phân tích. Nếu kết luận chỉ nằm trong báo cáo nhóm kỹ thuật, người hỗ trợ có thể tiếp tục thực hiện những cách đã được biết là không hiệu quả.

Năng lực tổ chức dịch vụ và tri thức có thể được phát triển qua chương trình Quản lý Dịch vụ IT – ITSM. Trong áp dụng, cần nối problem với incident, thay đổi và cải tiến, để đầu ra điều tra được dùng trong công việc tiếp theo.

Xác nhận giảm nguy cơ thay vì chỉ đóng hồ sơ

Sau biện pháp, nhóm cần xem các điều kiện trước đây tạo lỗi và kết quả dịch vụ. Không xuất hiện lỗi trong một thời gian chưa đủ nếu điều kiện chưa quay lại. Cần chọn cách kiểm tra phù hợp, giữ giới hạn và dữ liệu để kết luận có căn cứ.

Đo có thể gồm tác động của lỗi lặp, chi phí workaround, mức sử dụng tri thức và kết quả hành động. Số problem đóng phản ánh khối lượng, chưa cho biết nguy cơ đã giảm. Một hồ sơ được đóng khi chuyển việc sang dự án vẫn cần người tiếp nhận cùng cách theo dõi phần còn lại.

Người quản lý phải dành nguồn lực cho phòng ngừa, nếu không việc khẩn cấp sẽ liên tục đẩy điều tra ra sau. Chương trình Trưởng Phòng IT – IT Manager là hướng tham khảo để phát triển khả năng ưu tiên này. Trong doanh nghiệp, cần trình tác động và lựa chọn để nguồn lực không chỉ được cấp cho hoạt động phục hồi dễ thấy.

Công việc chủ động có thể bắt đầu từ xu hướng, kết quả kiểm thử hoặc một phụ thuộc đang thay đổi, trước khi tác động lớn xuất hiện. Nhóm cần giữ căn cứ và mức không chắc chắn để không biến mọi dấu hiệu thành problem ưu tiên cao. Phân tích phù hợp giúp chọn nguy cơ đáng xem, rồi phối hợp với chủ dịch vụ để quyết định bước kiểm chứng.

Một cuộc rà danh mục problem nên hỏi hồ sơ nào thiếu người nhận hành động, workaround nào vượt điều kiện ban đầu và kết luận nào chưa được thử. Các câu hỏi này dẫn tới việc cụ thể hơn lời yêu cầu chung giảm sự cố lặp. Nếu thiếu quyền hoặc nguồn lực, người quản lý cần trình lựa chọn thay vì chỉ tiếp tục nhắc nhóm điều tra.

Problem Management có chất lượng khi hiểu biết tạo ra hành động và tác dụng được kiểm tra. Dịch vụ được phục hồi nhanh vẫn cần, nhưng tổ chức còn phải giảm những điều kiện khiến cùng tác động trở lại. Khi workaround, known error và biện pháp đều có người sở hữu, việc điều tra trở thành khả năng bảo vệ dịch vụ lâu dài.