Bạn tôi, Priya, quản lý lịch trực cho một khoa y tế 34 giường và đã dành hai năm xử lý các yêu cầu đổi ca qua một nhóm tin nhắn mà chẳng ai đọc theo đúng thứ tự. Cô ấy muốn có thứ gì đó mà y tá có thể mở trên điện thoại trong giờ nghỉ, đăng một ca cần người thay, và có người nhận trước khi điều dưỡng trưởng phải tự tay sắp xếp lại bảng phân công. Tôi đã xây dựng nó trong ba tuần vào buổi tối. Đây là nhật ký của ngày nó thực sự lên sóng — xuất bản, domain riêng, y tá thật, ca trực thật — vì khoảng cách giữa "nó chạy tốt khi kiểm thử" và "nó chạy tốt lúc 7 giờ sáng khi khoa thiếu hai người" hóa ra lại là một bài học riêng.
6:58 sáng — xuất bản
Tôi đã đặt đích triển khai là domain riêng của Priya từ tối hôm trước, nên phần này khá bình lặng: nhấn xuất bản, xem bản ghi xác minh của build chạy qua các bước kiểm tra:
- Các route hoạt động đúng
- Endpoint nhận ca trực trả về phản hồi thực thay vì dữ liệu giả
- Hook thông báo SMS đã được cấu hình thực sự thay vì chạy thử
Tất cả đều xanh. Tôi nhắn link cho Priya lúc 6:58 sáng vì biết cô ấy sắp vào ca đúng lúc đó, và tôi muốn cô ấy thấy nó hoạt động trước khi ngày bắt đầu, chứ không phải sau.
7:15 sáng — người dùng thật đầu tiên làm điều tôi chưa từng kiểm thử
Priya đăng một ca trống cho buổi tối hôm đó trong vòng hai mươi phút, nhanh hơn tôi tưởng và có nghĩa là tôi chưa kịp uống xong cà phê thì đã có dữ liệu thực đầu tiên. Sau đó một y tá tên Denise nhận ca, hủy nhận bốn phút sau, rồi nhận lại. Tôi không rõ vì sao — có lẽ cô ấy kiểm tra lịch của mình giữa chừng và nhận ra có hẹn nha sĩ. Ứng dụng xử lý ổn. Điều tôi chưa kiểm thử là ba người cùng cố nhận một ca trong cùng khung mười giây, vì trong ba tuần kiểm thử một mình, kịch bản đó chưa từng xuất hiện trong đầu tôi. Nó cũng không xuất hiện trong đầu tôi lúc này. Nó xuất hiện với thực tế khoảng năm giờ sau.
9:40 sáng — yên ắng, và tôi bắt đầu lo lắng vì sự yên ắng đó
Không có gì xảy ra trong hai tiếng rưỡi. Không có ca nhận, không có ca đăng, không có lỗi trong log. Tôi vẫn kiểm tra dashboard bốn lần, một thói quen mà có lẽ tôi nên bỏ — một build không được sử dụng không có nghĩa là nó hỏng, chỉ là chưa được dùng đến, và đó là hai vấn đề khác nhau với cách xử lý khác nhau. Tôi ép mình đóng tab lại và đi làm việc khác.
11:52 sáng — con bug
Endpoint nhận ca chấp nhận cả ba lượt, vì tôi đã viết logic "đánh dấu đã nhận" theo kiểu kiểm tra-cập-nhật đơn giản mà không có khóa (lock), và trong điều kiện kiểm thử một người dùng bình thường, tình huống race condition này đơn giản là không bao giờ có cơ hội xảy ra. Nhưng với ba lần chạm đồng thời từ ba điện thoại khác nhau, nó có đầy đủ cơ hội. Cả ba y tá đều nhận được tin nhắn xác nhận rằng họ đã nhận ca. Denise là một trong số đó, lần thứ hai trong ngày, và lần này cô ấy khó chịu thật sự.
Tôi muốn thành thật về cách tôi phát hiện ra chuyện này — tôi không phát hiện qua giám sát hệ thống. Priya nhắn tin cho tôi thế này, kèm emoji cười, dù tôi không nghĩ cô ấy thực sự thấy vui, vì đó thực sự là một vấn đề với buổi chiều của cô ấy:
ứng dụng báo 3 người nhận cùng một ca lol
12:10 chiều — vào build chat
Tôi mô tả lỗi bằng ngôn ngữ đơn giản: nhiều người có thể nhận cùng một ca nếu họ chạm gần như cùng lúc, trong khi chỉ nên có một lượt nhận được ghi nhận. Tôi không tự viết fix trước, một phần vì tôi đang ngồi trong xe ở bãi đỗ và một phần vì mô tả chính xác sự cố thường nhanh hơn tự chẩn đoán chính xác. Agent truy ra nguyên nhân là thiếu khóa hàng (row lock) trên bảng nhận ca, và đề xuất chuyển sang cập nhật có điều kiện nguyên tử — việc nhận chỉ thành công nếu trạng thái ca vẫn là "mở", và chính thao tác đó quyết định ai thắng thay vì kiểu kiểm tra-rồi-ghi khiến cả ba request đều thấy "mở" cùng lúc. Đó là bản chất của lỗi gói gọn trong một câu, và là kiểu vấn đề hiển nhiên khi đã nói ra nhưng vô hình cho đến khi có gì đó buộc nó lộ diện.
12:34 chiều — bản vá được đưa ra, và tôi bắt Priya chờ
Bản vá khá nhỏ. Nhưng tôi vẫn không đẩy thẳng lên domain thật trong lúc đang có ca trực — tôi chạy nó trên một bản preview trước và nhờ đồng nghiệp điều dưỡng trưởng của Priya, người không trong ca lúc đó, thử đúng kiểu ba lần chạm cùng lúc từ ba tab trình duyệt. Nó đứng vững. Một lượt nhận thành công, hai lượt còn lại nhận được thông báo "ca này vừa được người khác nhận" thay vì một xác nhận giả. Tôi đẩy lên trực tiếp lúc 12:34 chiều, khoảng bốn mươi hai phút sau khi lỗi xảy ra, cảm giác chậm vào lúc đó nhưng nhìn lại thì khá nhanh.
2 giờ chiều đến 6 giờ chiều — phần nhàm chán nhưng tốt đẹp
- 11 ca trực được đăng thêm
- 9 được nhận suôn sẻ
- 2 hết hạn mà không ai nhận và được chuyển vào bảng mà Priya vẫn tự quản lý thủ công — điều này ổn thôi, công cụ không cần giải quyết mọi thứ ngay ngày đầu, nó chỉ cần giải quyết đúng vấn đề đã bị hỏng
- 0 trường hợp nhận trùng thêm
Tôi theo dõi các con số thay vì tưởng tượng kết quả, một hoạt động khác hẳn và bình tĩnh hơn nhiều.
Điều tôi sẽ làm khác đi
Hai điều.
- Tôi sẽ mô tả kịch bản nhận ca đồng thời ngay trong prompt build ban đầu thay vì phát hiện nó khi đang chạy thật — "nhiều người dùng, cùng hành động, cùng thời điểm" chỉ là một câu, không phải một yêu cầu khó, và tôi đơn giản là không nghĩ đến việc đưa nó vào vì bản thân việc kiểm thử của tôi vốn mang tính tuần tự; tôi chỉ từng nhấn từng nút một.
- Tôi đã đầu tư quá nhiều thời gian vào tuần thứ hai cho câu chữ thông báo SMS — ba lần viết lại riêng biệt cho một tin xác nhận mà chẳng ai phàn nàn — trong khi đầu tư quá ít cho đúng loại tình huống đồng thời (concurrency) mà một khoa đầy y tá nghỉ giải lao, tất cả cùng nhìn điện thoại cùng lúc, chắc chắn sẽ gặp phải ngay ngày đầu tiên.
Lần ra mắt tiếp theo, tôi sẽ dành ít thời gian hơn để chỉnh sửa câu chữ mà không ai để ý, và nhiều thời gian hơn để hỏi "điều gì xảy ra nếu năm người cùng làm việc này một lúc," vì với bất cứ thứ gì có nhiều hơn một người dùng thực, sớm muộn cũng sẽ có người thử.
