Player Unknown’s Bug: Ghi lại những vấn đề không rõ nguyên nhân có giúp chúng ta trưởng thành hơn không?
(engineering.ab180.co)Xin chia sẻ câu chuyện về việc tạo ra một trang tổng hợp issue một cách tình cờ, qua đó nâng cao cảm giác an toàn tâm lý trong nhóm, tăng cường chia sẻ thông tin và xây dựng một tổ chức cùng dịch vụ vững chắc hơn.
Khi phát triển phần mềm, đôi khi ta sẽ gặp những vấn đề không rõ nguyên nhân.
Đặc biệt, web frontend chịu ảnh hưởng của vô số yếu tố bên ngoài như trạng thái của server, loại và phiên bản trình duyệt, Chrome Extension, v.v.
Nếu không biết nguyên nhân của vấn đề, hoặc nguyên nhân không nằm ở phía chúng ta, tôi chợt tự hỏi liệu chỉ với postmortem thôi có đủ để xây dựng một cấu trúc vững chắc hay không (có phải là vẫn còn thiếu gì đó không?).
Động lực
Đã có lần tôi mất tới 9 tiếng từ lúc nhận báo cáo về một issue không rõ nguyên nhân cho đến khi đóng nó lại.
Chỉ sau khi dành 4 tiếng để debug issue, tôi mới biết nguyên nhân không nằm ở code nội bộ hay hạ tầng, mà phát sinh do bug của Chrome Extension của người dùng.
Việc xác định nguyên nhân của vấn đề nằm ở đâu vốn đã khó, nhưng điều khiến tôi tự giận mình là phải mất tới 4~5 tiếng mới nhận ra nguyên nhân nằm ở bên ngoài.
Tôi tạo một trang trên Notion tên là ‘Player Unknown’s Bug(PUB)’ và, trong lúc đầy bực bội, ghi lại những điều đã thử khi xử lý issue, những điểm còn tiếc nuối và những gì nên bổ sung.
Bám rễ thành văn hóa, rồi tiếp tục phát triển
Khi nhìn lại, tôi đã nói về nguyên nhân của issue, những điều học thêm được trong quá trình tìm hiểu, cũng như những chỗ mình đã phán đoán sai. Các thành viên trong nhóm chỉ ra những điểm họ còn thắc mắc và những chỗ có thể cải thiện, rồi từ đó chúng tôi tập hợp lại để thiết lập quy trình ứng phó sự cố.
Điều hay ở quá trình này là các đồng đội đã đồng cảm với những khó khăn tôi cảm thấy trong lúc xử lý issue, và việc chia sẻ những điều mới biết được cũng rất thú vị. Ngoài ra, chúng tôi tạo checklist để nếu gặp tình huống tương tự thì có thể xác định vấn đề nhanh hơn. Sau khi trao đổi với cả nhóm, nó đã được chấp nhận như một văn hóa chính thức.
Tổ chức phát triển của AB180 về cơ bản luôn thực hiện ‘postmortem’. Nếu postmortem nội bộ trong công ty tập trung vào Resolution và Action Items, thì PUB hướng đến Lesson Learn, xây dựng cảm giác an toàn tâm lý quanh việc xử lý issue, và sắp xếp các yếu tố cần kiểm tra trước khi gặp một vấn đề chưa rõ nguyên nhân.
Văn hóa tự nguyện chia sẻ thông tin
Khi đã bám rễ trong nhóm, các issue do những thành viên khác xử lý cũng bắt đầu tích lũy dần từng cái một.
Trong các buổi nhìn lại, việc nói về những điều trước đây chưa biết và dành thời gian đào sâu hơn đã dần vận hành như một ‘phiên chia sẻ kiến thức’ nhỏ nhưng tự nguyện.
Để phát triển văn hóa này thêm một chút, chúng tôi đang vận hành một kênh Slack để thường xuyên chia sẻ những gì đã học và những gì mới biết. Cho đến nay, nó vẫn đang hoạt động khá tốt.
Lesson Learn
- Cần nâng cao cảm giác an toàn tâm lý của cả nhóm khi ứng phó sự cố, và để làm được điều đó thì phải trò chuyện nhiều hơn.
- Nếu không như vậy, vấn đề sẽ lặp lại, và trong tổ chức sẽ hình thành suy nghĩ rằng ‘vấn đề = điều không nên nói ra’.
- Thông qua việc chia sẻ thông tin, có thể tạo ra, thậm chí còn nâng cao, cảm giác an toàn tâm lý trong tổ chức.
- Và văn hóa chia sẻ thông tin như thế này có khi lại có thể bắt đầu từ những điều nhỏ hơn ta tưởng.
5 bình luận
Ngược lại, hôm nay tôi tan làm sau khi vật lộn suốt cả ngày với một sự cố mà tôi nghĩ nguyên nhân rất rõ ràng là do một yếu tố bên ngoài, nhưng vì tình hình nội bộ nên không thể dễ dàng xử lý, hóa ra chỉ cần thay đổi đúng một dòng trong tệp cấu hình là giải quyết được. Đọc bài này mới thấy nó thực sự hữu ích.
Hôm nay bạn cũng đã vất vả rồi. Dù vậy, thật may là bạn đã giải quyết được vấn đề. Thỉnh thoảng tôi vẫn nhớ đến những vấn đề đã viết ở bài trên. Khi đó thì rất vất vả, nhưng giờ có lẽ tôi đã có thể đón nhận chúng một cách vui vẻ.
Có lẽ những chuyện khó khăn mà kunggom đã trải qua hôm nay, sau khi thời gian trôi qua, cũng sẽ có thể được nhớ lại một cách vui vẻ chăng? haha
Cảm ơn bạn đã đọc bài viết còn nhiều thiếu sót của tôi.
Thật ra thì trước đây cũng như bây giờ, tôi chưa từng nghĩ việc xử lý sự cố là một điều thú vị.
Ví dụ như sự cố tôi xử lý hôm nay cũng lại xảy ra ở một sản phẩm mà đội chúng tôi bị chặn truy cập trực tiếp vào máy chủ vận hành, nên ngoài giai đoạn đầu khi phát hiện sự cố và tìm hiểu hiện tượng, cùng giai đoạn sau khi cuối cùng cũng khó nhọc giành được quyền truy cập máy chủ, thì phần lớn thời gian chúng tôi buộc phải ở trong trạng thái khá bất lực. Khi đội chúng tôi nhờ đội vận hành máy chủ thực hiện những biện pháp này nọ, họ đã từ chối vì những lý do phía họ. Không thể nào vui vẻ đón nhận cảm giác bất lực như thế được.
Vì vậy, điều tôi cảm nhận khi viết tài liệu postmortem cho đến trước giờ tan làm có lẽ gần với kiểu: 'Bực mình đến mức, từ lần sau dù thế nào cũng không lặp lại sai lầm này nữa!' hơn.
Nghe những gì bạn chia sẻ, tôi nghĩ hẳn bạn đã rất vất vả. Như bạn nói, chỉ cần dần dần không lặp lại những sai lầm giống nhau thì chắc chắn sẽ từng chút một trở nên tốt hơn... hu hu
Thực ra, sản phẩm này là một sản phẩm legacy đã khá cũ, tôi cũng chỉ mới tiếp nhận bàn giao chưa lâu, và ngay sau khi nhận đã có yêu cầu thay đổi tính năng nên gần đây tôi có chỉnh sửa mã, nhưng đó là phần hoàn toàn không liên quan gì đến sự cố xảy ra hôm nay. Vì vậy, phần thực sự gây ra vấn đề không phải là nội dung do chính tôi viết, nhưng nếu tôi hiểu sản phẩm đó tường tận hơn thì có lẽ đã có thể giải quyết vấn đề nhanh hơn. Điều đó thật đáng tiếc.
Và ngay từ đầu, sau khi xác nhận tình trạng sự cố trên diện rộng, suy đoán về nguyên nhân mà tôi đã tin chắc lúc đầu thực ra chỉ đúng một nửa mà thôi. Tôi nghĩ chính sự chắc chắn vào suy đoán đó mới là sai lầm thực sự của ngày hôm nay.