đọc một báo cáo sự cố

Lần này chúng ta thử cùng xem xét một ví dụ báo cáo sự cố/ vụ việc (incident), đi sâu vào phần Nguyên nhân một chút.

Lưu ý bài viết sẽ không đưa ra ví dụ hay đáp án sửa báo cáo thế nào, thay vào đó tập trung vào nhận xét nội dung báo cáo theo diễn tiến vụ việc.

Chúng ta cùng đến với tình huống luôn.

I. Khởi động

Một bạn PM báo cáo nhanh như sau (tên các bảng/ dữ liệu đã được thay đổi):

12h VN (14h JST) phía Nhật thông báo 2 bảng kalo_setting và kalo_settings_history chưa được cập nhật data cho tháng mới đúng spec Nguyên nhân sơ bộ : batch monthly sync data tới S3 cho 2 bảng kalo_setting và kalo_settings_history bị lỗi Ảnh hưởng : data các bảng kalo_setting và kalo_setting_history ở trên S3 và DWH phía sau là snowflake, TD chưa được cập nhật Action :

• Điều tra nguyên nhân sau khi hotfix
• Hotfix chạy lại batch để cập nhật data cho 2 bảng trên

Em sẽ cập nhật thêm khi có thông tin ạ

Nội dung trên có hứa “sẽ cập nhật thêm khi có thông tin” ở cuối có vẻ khá là uy tín. Vậy báo cáo trên cơ bản là ổn, đúng không? 🤔

💢 Chưa chắc, chỉ ít phút sau một Senior Manager (SM) dày dạn kinh nghiệm báo cáo incident cho bên Nhật đã hỏi lại PM :

.data gì chưa được cập nhật?

.hotfix chạy lại hay chỉ chạy lại batch? (Hotfix là sửa) 

Bạn PM trả lời:

>data gì chưa được cập nhật?

data tháng 3 của bảng kalo_setting_history chưa được cập nhật từ bảng kalo_setting

bảng kalo_setting đang thừa dữ liệu kalo tháng 3

>hotfix chạy lại hay chỉ chạy lại batch? (Hotfix là sửa)

hotfix có bao gồm sửa do phát hiện ra thông tin kalo của 1 account bị trùng lặp

— Nhận xét: —-

. Phần ảnh hưởng đã nêu tên bảng chưa được cập nhật data, tưởng rằng đủ nhưng thực ra chưa, vẫn cần mô tả cụ thể hơn. Trong trường hợp này “chưa được cập nhật data cho tháng mới” thì không cụ thể bằng “thừa dữ liệu kalo tháng 3“.

. Ngoài thông tin Where (bảng này bảng kia): data ở đâu có vấn đề thì khi được hỏi, PM đã trả lời bổ sung How: data bị thiếu ra sao.

. Viết “thừa” hoặc “thiếu” thì cụ thể hơn “chưa cập nhật”, và có time range rõ ràng “cho tháng 3” thì tốt hơn là “cho tháng mới”. Thông tin time range này giúp mô tả What: data nào bị thiếu.

. Ngoài ra sau khi được hỏi PM cũng bổ sung thêm chi tiết là bảng kalo_setting_history chưa được cập nhật từ bảng kalo_setting, đây là khía cạnh Which: Xử lý nào liên quan.

. Tương tự, “hot fix chạy lại batch” được thêm thông tin cụ thể hơn để thành “hotfix bao gồm sửa do phát hiện …. kalo của 1 account bị trùng lặp”. Tuy nhiên thông tin cụ thể hơn này chỉ dừng lại ở Lý do của việc “sửa” (=hotfix): do phát hiện …., tức là lại đi trả lời Why, chứ chưa trả lời ý hỏi “sửa cái gì?” (What)

——–

SM hỏi tiếp, tiếp tục làm rõ Why, What:

>bảng kalo_setting đang thừa dữ liệu kalo tháng 3

thừa dữ liệu kalo tháng 3 ở bảng này nên làm xử lý đồng bộ bị lỗi, việc thừa này là chưa rõ nguyên nhân đúng ko e?

>hotfix có bao gồm sửa do phát hiện ra thông tin kalo của 1 account bị trùng lặp

cụ thể là sửa cái gì hả e?

(đang thắc mắc là ghi nguyên nhân chưa rõ nhưng action là hotfix thì ko hiểu hotfix là sửa cái gì?) 

PM trả lời:

>thừa dữ liệu kalo tháng 3 ở bảng này nên làm xử lý động bộ bị lỗi, việc thừa này là chưa rõ nguyên nhân đúng ko e?

vâng, việc thừa này mới được xác định và chưa rõ nguyên nhân

>cụ thể là sửa cái gì hả e?

action là thống nhất với khách xóa đi record bị thừa và chạy lại các batch

💢 Ngay sau đó SM comment:

xóa đi record thừa thì chỉ là xóa data trong table chứ ko có sửa gì code nhỉ? như thế ko gọi là Hotfix em ạ. Hotfix là sửa code-> release production

— Nhận xét —

như vậy PM dùng từ hotfix trong tình huống này là không chuẩn, không đúng ngữ cảnh và bản chất hành động đối ứng, có thể gây hiểu nhầm

— tổng hợp để bạn đọc tiện theo dõi —

tổng hợp một chút các thông tin quan trọng đã có:

Ngay sau thời điểm PM. báo cáo nhanh:

Sau khi SM đặt câu hỏi để làm rõ thì có thêm (thông tin bổ sung được bôi đậm):

— bảng tổng hợp 1–

Quay trở lại với tình huống

II. Dev. bổ sung bối cảnh, hiện tượng ….

Tiếp theo, Dev. team cung cấp thêm thông tin bối cảnh và hiện tượng, action (biện pháp) đối ứng:

có 2 bảng kalo_setting và kalo_setting_history hàng tháng khi có kalo mới sẽ được lưu vào kalo_setting, khi đến cuối thang dữ liêu này sẽ được sao lưu vào kalo_setting_history và xóa toàn bộ dữ liệu cũ đi, dữ liêu trong bảng kalo_setting chỉ có tháng hiện tại cấu trúc dữ liêu kalo có các key là target_date và account_id , mỗi account id chỉ có 1 kalo trong 1 tháng tháng 3 vừa rồi xuất hiện 1 bản ghi dữ liệu bất thường account 59 có kalo mới nhưng target date lại là tháng 2 , nên khi cuối tháng thực hiện sao lưu thì hệ thống báo bản ghi có key account id 59 target tháng 2 đã tồn tại do là dữ liệu kalo tháng 3 mà target lại tháng 2 nên bọn em đã báo khách dữ liệu không đúng và thực hiện xoá đi, sau khi xoá bọn em đã chạy lại xong các batch liên quan

1. batch từ bảng kalo_setting sang bảng kalo_setting_history
2. batch từ bảng kalo_setting_history sang S3
3. batch từ bảng kalo_setting sang S3

— cập nhật tổng hợp để bạn đọc tiện theo dõi —

— bảng tổng hợp 2–

📍Sau đó PM cũng cập nhật báo cáo, từa tựa nội dung nói trên từ Dev. team

Ngày giờ phát sinh/phát hiện Incident: .. Incident type: … Overview: kalo_setting_history thiếu dữ liệu tháng 3/2025.

• .. bên JP thông báo cho team tình trạng 2 bảng kalo_setting và kalo_setting_history trên S3 được update không đúng
• … team phát hiện ra data lưu vào kalo_setting trong DB xuất hiện 1 record bất thường
• … team thực hiện xóa record bất thường và đồng bộ lại 2 bảng kalo_setting và kalo_setting_history lên S3
• … team đồng bộ thành công kalo_setting và kalo_setting_history từ S3 lên các bảng tương ứng ở Snowflake và TD

Ảnh hưởng :

• Trong khoảng .. ~ … bảng kalo_setting_history thiếu data của tháng 3 ; bảng kalo_setting lưu thừa data từ tháng 2 – 4

Nguyên nhân:

• Chưa xác định được lý do vì sao record có target_date = 2025-02-01 xuất hiện trong kalo_setting của DB.
• Batch xử lý hàng tháng lấy dữ liệu sai từ kalo_setting để ghi vào kalo_setting_history, dẫn đến lỗi trùng key

Next Actions:

1. [Done] Xoá record bất thường và đồng bộ lại dữ liệu lên .
2. [Doing] Monitor hệ thống để phát hiện lỗi tương tự.
3. [Doing] Điều tra nguyên nhân xuất hiện record bất thường trong DB.

— Nhận xét nhanh: —-

. Phần tóm tắt (câu đầu tiên) của Overview và phần Nguyên nhân không kết nối (connect) tốt, bởi vì trừ tên bảng “kalo_setting” và từ “record” ra thì không có keyword chung nào connect 2 phần này. Overview nói về “một record bất thường được phát hiện”, còn Nguyên nhân thì lại nói đến “record có target_date = 2025-02-01” và “lỗi trùng key” xảy ra ở “Batch xử lý hàng tháng”.

. Hai ý trong phần Nguyên nhân ở trên cũng không có keyword gì chung ngoài kalo_setting. Với diễn đạt này, không rõ 2 ý này là 2 nguyên nhân tách biệt (ngang hàng, xảy ra độc lập) hay có liên quan đến nhau

— cập nhật tổng hợp để bạn đọc tiện theo dõi —

— bảng tổng hợp 3–

III. Báo cáo sau cùng về Nguyên nhân

Sau cùng, Nguyên nhân sự cố cũng được làm rõ nên PM báo cáo lần cuối:

Kết luận : KINTONE update kalo thông qua API vào kalo_setting cùng thời điểm batch renew kalo chạy gây conflict về mặt data Chi tiết tiền đề : batch renew kalo chạy với 2 logic là 1.Copy toàn bộ kalo của tháng trước vào bảng kalo_setting_history 2. renew lại kalo

• Tính toán lại các trường liên quan như ….
• Reset target_date các record có target date là tháng trước thành date của ngày chạy batch

Phân tích log

• ở batch renew ngày 1/3

– batch renew start vào 0:30:00 – logic①chaỵ hoàn tất – logic ② update xong vào 0:31:06 – KINTONE update kalo cho account_id = 59  qua API  vào 0:32:11 kết quả sau cùng : -bảng kalo_setting_history : update đầy đủ data kalo của tháng 2 -bảng kalo_setting : 1 record sai lệch của account_id = 59 được update nhưng giá trị target_date sai từ 03-01 thành 02-01

• ở batch renew ngày 1/4/

-logic ①copy data vào kalo_setting_history không thành công do lỗi trùng key của account 59 -logic ② thực hiện renew kalo nhưng không update cho record kia vì target date là 02-01 chứ không phải tháng trước là 03-01 kết quả sau cùng: – bảng kalo_setting_history : không có data kalo của tháng 3 – tai bảng kalo_setting : 1 record sai lệch của account_id = 59 vẫn giữ nguyên giá trị target_date là 02-01 Biện pháp phòng tránh :

• Liệt kê thời gian chạy batch và liên lạc với admin Kintone yêu cầu không request vào các thời điểm batch chạy
• refactor để kiểm tra tính đúng đắn của dữ liệu sau khi renew kalo : khi phát hiện data bất thường sẽ thông báo lên slack cảnh báo

— cập nhật tổng hợp để bạn đọc tiện theo dõi —

— bảng tổng hợp cuối —

— Nhận xét —-

Kết luận : KINTONE update kalo thông qua API vào kalo_setting cùng thời điểm batch renew kalo chạy gây conflict về mặt data

✅ đặt Kết luận lên trước là một điều tốt

Phân tích log

• ở batch renew ngày 1/3

– batch renew start vào 0:30:00 – logic①chaỵ hoàn tất – logic ② update xong vào 0:31:06 …

✅ Có thêm các mốc thời gian khi mô tả Nguyên nhân cũng là một điều tốt.

Việc liệt kê lại các sự kiện theo trình tự thời gian là một việc không thể thiếu để đảm bảo đã tìm đúng nguyên nhân sự cố. Liệt kê này gọi là Incident timeline (Diễn biến vụ việc), nó là cứ liệu quan trọng để hỗ trợ điều tra phân tích sự cố. Chẳng thế mà trong các vụ trọng án người ta còn có cả bước “dựng lại hiện trường” vụ án, trong đó nghi phạm phải tái hiện lại hành vi gây án ….

Việc tái tạo trình tự thời gian và không gian của một chuỗi sự kiện là cách hiệu quả nhất để hiểu rõ bản chất của vấn đề, tìm ra nguyên nhân và rút ra bài học kinh nghiệm. Và để có được Diễn biến như trên, log hệ thống là nguồn thông tin không thể thiếu! (đây là điểm cần được lưu ý ngay từ những User story đầu tiên khi PM. đưa ra Yêu cầu cho team phát triển: là một maintainer, tôi muốn có log hệ thống để ….)

Tuy nhiên, có vài vấn đề diễn đạt trong báo cáo.

💢 Kintone?

KINTONE update kalo thông qua API vào kalo_setting cùng thời điểm batch renew kalo chạy gây conflict về mặt data

Kintone update … gây conflict! Viết thế này thì báo cáo hướng sự chú ý của người nhận đến Kintone.

Nhưng Kintone là một dịch vụ bên thứ 3 mà !(nếu chưa biết ta có thể hỏi nhanh AI về Kintone)

Diễn đạt này làm mờ đi sự thật là trong tình huống này User (người dùng) đã thao tác update kalo và điều này tạo nên một bản ghi (record) trong log hệ thống là có kalo bị update qua Kintone API vào thời điểm abcd. Chủ thể của việc “update kalo” vì thế là User chứ không phải Kintone.

Tất nhiên, ngoài đời ai đó có thể bảo rằng nói “cây cung bắn mũi tên vào ông N.” và nói “thổ dân bắn mũi tên vào ông N. bằng cung” thì cũng chả có gì khác nhau. Nhưng quan điểm của người viết, như từng chia sẻ, là: “giao tiếp trong công việc” thì rất khác so với “giao tiếp trong cuộc sống”. Những chi tiết trong báo cáo sự cố đều quan trọng và một dự án, một công ty có chuyển mình tiến bộ được hay không cũng là do có khả năng để ý/ xem xét đến những chi tiết tưởng chừng nho nhỏ ấy không.

Câu Kết luận về Nguyên nhân trong báo cáo thì quan trọng và việc đặt chủ ngữ chuẩn xác cho câu Kết luận ấy cũng quan trọng không kém.

. tiếp theo, xem Nguyên nhân được trình bày trong Diễn biến vụ việc thế nào:

Kết luận : KINTONE update kalo thông qua API vào kalo_setting cùng thời điểm batch renew kalo chạy gây conflict về mặt data

Phân tích log

• ở batch renew ngày 1/3

– batch renew start vào 0:30:00 – logic①chaỵ hoàn tất – logic ② update xong vào 0:31:06 – KINTONE update kalo cho account_id = 59  qua API  vào 0:32:11

Nhận xét:

💢 Diễn biến vụ việc như trên thì không phù hợp với Kết luận “cùng thời điểm”. Thời điểm logic ② của batch renew chạy xong là 0:31:06, hoàn toàn trước thời điểm update thông qua API: 0:32:11. Không biết PM có tự đọc lại mô tả của mình không mà không nhận thấy sự thiếu logic này. Thông tin thì có thừa, nhưng logic thì sai hoặc thiếu. Vì thiếu logic, nên giữa phần Kết luận và phần Diễn biến của báo cáo là một liên kết lỏng lẻo.

💢 Không chỉ 2 phần đó, liên kết của những phần chính trong báo cáo đều lỏng lẻo về mặt diễn đạt

Thử tách riêng chỉ một cột từ ” bảng tổng hợp cuối” ra xem:

💢 Cùng một thứ, nhưng mỗi lần PM lại báo cáo bằng những phiên bản từ ngữ khác nhau:

• .batch monthly sync data tới S3, sau đó là
• .batch từ bảng kalo_setting sang bảng kalo_setting_history , sau đó
• .Batch xử lý hàng tháng lấy dữ liệu từ kalo_setting để ghi vào kalo_setting_history, sau đó
• .batch renew

🤔 Có 2 cách vô cùng đơn giản để làm cho người đọc phải suy nghĩ gấp 10 lần, ấy là:

. Dùng những từ khác nhau để chỉ đến cùng một thứ

. Dùng cùng một từ để chỉ đến các thứ khác nhau

Bạn đọc đã từng có kinh nghiệm về điều trên chưa? Cá là chắc chắn có, đầy dẫy trong cuộc sống! Cùng một người được gọi là “bạn K, chồng M, bố B, con rể, member X …”. Cuộc sống phong phú nhưng cũng nhức đầu nhỉ! Và đó chính xác là điều xẩy ra khi ta cứ bê nguyên thói quen diễn đạt trong cuộc sống vào báo cáo sự cố. Mỗi Dev. nói về cùng một batch bằng một cách khác nhau và PM cứ thế copy i xì vào báo cáo thì phải!

Hai cột còn lại của bảng tổng hợp thì sao?

💢 Từ những chỗ bôi đậm trong cột Nguyên nhân ta cũng thấy ở đây cũng có cả một chuyến hành trình:

a) kalo bị trùng lặp > b) bản ghi dữ liệu bất thường (target date lại là tháng 2) > c) bản ghi có target tháng 2 đã tồn tại > d) conflict về mặt data

🧐 Trong công việc, tôi thấy một Comtor. dở thì chỉ biết ngôn từ, vì thế cứ khi nào có từ mới thì chị/anh ấy sẽ cho rằng đó là một thứ mới. Tuy nhiên, người đọc giỏi thì khác ở chỗ là chị/ anh ấy biết:

. lúc nào thực ra vẫn là nói đến cái cũ,

. lúc nào là đề cập đến cái mới, và quan trọng hơn

. cái mới liên hệ thế nào với cái cũ

Người đọc giỏi thì giống như là vừa đọc vừa đánh dấu được những điểm cũ mới trên một tấm bản đồ và không đi lạc mạch, còn người dở thì đơn giản giống như chơi một trò chơi ngẫu nhiên và bất định với tất cả các món đồ được vứt vương vãi tứ tung trên mặt sàn.

Giờ quay lại tình huống hiện tại

a) kalo bị trùng lặp > b) bản ghi dữ liệu bất thường (target date lại là tháng 2) > c) bản ghi có target tháng 2 đã tồn tại > d) conflict về mặt data

Vậy trong diễn đạt Nguyên nhân như trên, với a, b, c, d ở trên, thực chất có bao nhiêu thứ ở đó? Cần phải suy nghĩ rồi. ….

Ở đây b và c khá tương đồng với nhau về mặt ngôn từ, nên khả năng cao chúng là cùng một thứ. Còn a và d thì sao? Không phủ nhận a nhưng bản thân b và c có được giải thích trong bất kỳ mối quan hệ nào với a không?

Tôi đọc lại và phải mất công tìm hiểu một lúc mới ra được ý trả lời cho câu hỏi trên, ở đoạn ngay sau — bảng tổng hợp 1 –:

tháng 3 vừa rồi xuất hiện 1 bản ghi dữ liệu bất thường account 59 có kalo mới nhưng target date lại là tháng 2 , nên khi cuối tháng thực hiện sao lưu thì hệ thống báo bản ghi có key account id 59 target tháng 2 đã tồn tại do là dữ liệu kalo tháng 3 mà target lại tháng 2 nên bọn em đã báo khách dữ liệu không đúng và thực hiện xoá đi, sau khi xoá bọn em đã chạy lại xong các batch liên quan

và phải để ý thêm nữa đoạn hỏi đáp giữa PM với SM ban đầu:

hotfix có bao gồm sửa do phát hiện ra thông tin kalo của 1 account bị trùng lặp

vâng (thừa dữ liệu kalo tháng 3 ở bảng này nên làm xử lý đồng bộ bị lỗi ), việc thừa này mới được xác định và chưa rõ nguyên nhân

action là thống nhất với khách xóa đi record bị thừa và chạy lại các batch

💢 Phải để ý, để ý và phải tự xâu chuỗi thì người đọc mới đoán được:

a) kalo bị trùng lặp chính là e) record bị thừa (và do đó phải xử lý) trong mô tả sau đó của PM. Đến lượt Dev. thì vẫn cùng thứ đó nhưng Dev. lại mô tả bằng b) “dữ liệu bất thường” và rồi thì f) “dữ liệu không đúng”. Chúng đều là một vì ở đây có xử lý “xoá đi record bị thừa”. Hành động xoá đi này chỉ tác động đến một đối tượng duy nhất nhưng được dán rất nhiều nhãn: bất thường, đã tồn tại, không đúng, bị thừa, trùng lặp …

Phải suy nghĩ kha khá mới ra được à, a). b). c) đều chỉ là một và còn là cả e) cả f) luôn nữa. Không dừng lại ở đó, trong báo cáo cuối cùng nó cũng được gọi thêm là “sai lệch”:

Vẫn còn vấn đề d) conflict về mặt data.

“Conflict về mặt data” chỉ xuất hiện trong báo cáo cuối cùng, nó hẳn là một thông tin mới, tuy nhiên trong báo cáo này không giải thích cụ thể điều đó nghĩa là gì?

Mặc dù có vẻ báo cáo đã giải thích conflict data này xảy ra ở đâu (Where) khi nhìn vào thông tin Batch lỗi trong bảng dưới.

Tuy nhiên nó đã xảy ra lúc nào? WHEN?

💢 Tại thời điểm 1/3 thì đã có conflict data chưa? hay 1/4 mới phát sinh, hay cả 2 thời điểm đó đều có conflict data. Conflict ở đây là cái gì conflict với cái gì (WHICH)? Là data bảng kalo conflict với data bảng history hay xử lý batch X conflict với xử lý Kintone y? Conflict này được giải thích bằng những ý cũ a). b), c) …. hay là liên hệ đến những thông tin mới?

Như thế, mặc dù chắc 90% người viết báo cáo cho rằng họ đã giải thích đầy đủ những gì họ nói nhưng người đọc vẫn có thể cảm thấy bị đem bỏ giữa nhiều câu hỏi mở, nhiều khái niệm kỹ thuật được dán nhãn tuỳ tiện và phải mất công suy đoán.

💢 Một câu hỏi mở nữa:

bảng kalo_setting sau lúc batch renew ngày 1/3 chạy : 1 record sai lệch của account_id = 59 được update nhưng giá trị target_date sai từ 03-01 thành 02-01

Nếu câu trên viết đúng thì điều này nghĩa là “record sai lệch” được “update giá trị sai”, người đọc hoàn toàn có thể hiểu rằng à, vậy trước cả khi cái batch renew chạy ngày 1/3 thì record đó đã sai rồi, và sau khi batch chạy nó lại tiếp tục sai thêm. Nếu thế, tại sao lại có record sai ngay từ trước này? Lý do nó xuất hiện là gì ? …..

Như thế, khi không cẩn thận xem xét, không chuẩn hoá cách diễn đạt dù chỉ trong khuôn khổ một sự việc thôi, chúng ta hoàn toàn có thể tạo ra thêm nhiều vấn đề phức tạp hơn mức cần thiết cho người đọc báo cáo.

Đến đây, xin tóm tắt lại các điểm nhận xét đã được nêu ra:

• . Mô tả hiện tượng lỗi chung chung, vd. "chưa cập nhật data"
• (nên xem xét áp dụng 5W1H để mô tả vụ việc cụ thể, chuẩn xác hơn)
• . Dùng sai thuật ngữ dẫn đến hiểu nhầm, vd. hotfix
• . Cùng một xử lý hoặc cùng một data nhưng mỗi lần lại dùng từ ngữ (wording) khác nhau khi hành văn
• . Mô tả không đúng chủ thể trong kết luận cho Nguyên nhân
• . Mâu thuẫn khi mô tả Diễn biến: Ở trên nói "cùng thời điểm", ở dưới thấy một xử lý đã xong rồi xử lý kia mới xảy ra
• . Sự kết nối giữa Hiện tượng, Nguyên nhân, Diễn biến chưa tốt. Thiếu keyword chung liên kết những phần này

Haizz

IV. Tạm kết

Do tính chất của sự cố và yêu cầu công việc, khi làm báo cáo PM. sẽ phải tìm kiếm, tập hợp nhiều thông tin vào một cấu trúc đại loại: Hiện tượng, Nguyên nhân, Diễn biến, Khắc phục, Ngăn chặn….

Nhiều vụ việc, như đã nhận xét với ví dụ vừa rồi, việc liên kết giữa các phần trong cấu trúc báo cáo trên thực tế bị khiên cưỡng/ lỏng lẻo và gây khó khăn cho người đọc. Kết quả là khi đọc có cảm giác báo cáo viết tuỳ tiện, thiếu mạch lạc, thiếu logic và vì thế giảm kha khá tính thuyết phục.

🧩 Dạn này cá nhân tôi đọc báo cáo sự cố nhiều, stress nhiều vì phải lần mò, suy đoán, tự chuẩn hoá lại thông tin để có thể đọc hiểu. Stress đâm ra xem phim, thực ra là không có thời gian nên xem review phim Trấn Thành, Lý Hải, Marvel ….

Sau một thời gian, tôi vỡ lẽ từng có một công thức làm phim là tập hợp những tên tuổi nôi nổi và tập trung marketing tốt, còn kịch bản thì …xoay xở sau ….Và công thức đó sẽ là khởi đầu của thảm hoạ nếu kịch bản yếu, các tình tiết chẳng ăn nhập hoặc chộp giật kiểu chuyện gì đó đột nhiên xảy ra mà chẳng có bối cảnh phù hợp, hoặc ai đó bỗng dưng biến mất mà chẳng cần lý do… Các nhân vật ở tập sau bất chợt xử sự như một kẻ hoàn toàn khác, xem cứ tức anh ách như là …. đọc báo cáo sự cố.

Thế đấy, làm phim không phải là tập hợp một đống nhân vật, nhào nặn một đống tình tiết nhưng ít quan tâm đến việc kể một câu chuyện mạch lạc, cốt truyện rõ ràng. Tương tự vậy, báo cáo cũng cần kể một câu chuyện logic xuyên suốt các cấu phần của nó.

— Một đề xuất giả thuyết —

Về mặt lý thuyết, trộm nghĩ báo cáo sự cố cũng tương tự như viết một kịch bản điều tra tội phạm. Cho đến khi tìm được thủ phạm, những mảnh ghép có thể rời rạc nhưng một khi thủ phạm được xác định đúng thì các mảnh ghép đó cũng được xâu chuỗi một cách vô cùng hợp lý mà nghi phạm không thể chối cãi!

💡 Tương tự, để báo cáo sự cố trở nên tốt hơn, cuối cùng thì:

• .PM cần xác định được (lý tưởng nhất là chỉ) một thủ phạm, đó có thể là data bất thường X, logic sai Y, setting hạ tầng Z thiếu….
• .Sau khi xác định được thì chỉ sử dụng một wording duy nhất để dán nhãn cho “thủ phạm” ấy, ví dụ là “record bất thường có key account id 59” và cứ thế mà dùng trong toàn bộ báo cáo. Và để thuyết phục đây đúng là “thủ phạm”,
• .mọi phần như Hiện tượng, Nguyên nhân, Diễn biến, Khắc phục phải được kể/ mô tả xoay quanh “thủ phạm = record bất thường ….” ấy một cách hợp lý. Chẳng hạn
• .Diễn biến phải kể được lúc nào và làm thế nào mà “record bất thường …” xuất hiện, tiếp theo “record bất thường …” gây ra điều gì, điều đó dẫn tới điều gì, ở đâu… tiếp theo
• . Phần Khắc phục phải kể được cách cô lập/ sửa chữa “record bất thường ….” này ….

Mong rằng bài viết có thể giúp ích chút gì đó cho lần báo cáo sự cố tiếp