Lỗi kỳ lạ nhất tôi từng thấy cho đến nay
(engineering.gusto.com)Quá trình phát hiện và khắc phục một lỗi kỳ lạ
- Trong ca trực on-call của nhóm công cụ nội bộ, những người dùng sử dụng phần mềm nội bộ của Gusto đã gặp sự cố trình duyệt Chrome bị crash.
- Sự cố này gây ra nhiều gián đoạn cho bộ phận dịch vụ khách hàng.
- Để xử lý vấn đề, tác giả đã nhờ đến sự hỗ trợ của các đồng nghiệp giàu kinh nghiệm, nhóm hạ tầng sản phẩm và nhóm IT.
Manh mối đầu tiên
- Tác giả cố gắng tìm ra điểm chung giữa những người dùng bị ảnh hưởng.
- Không phải toàn bộ nhân viên Gusto đều bị ảnh hưởng, và phần mềm phục vụ khách hàng bên ngoài thì không gặp vấn đề.
- Các trang web phần mềm nội bộ khác vẫn hoạt động bình thường.
- Việc crash xảy ra không nhất quán, và không xuất hiện trên Safari hay Firefox.
Manh mối thứ hai
- Tác giả đưa ra giả thuyết rằng phiên bản Chrome có thể là nguyên nhân.
- Với một số người dùng, vấn đề có vẻ được giải quyết sau khi cập nhật Chrome, nhưng không được khắc phục hoàn toàn.
- Tác giả cũng nghi ngờ tiện ích mở rộng Chrome là nguyên nhân, nhưng lỗi vẫn tái hiện ngay cả khi không có extension.
Khó khăn trong việc tái hiện lỗi
- Nhóm hạ tầng đã yêu cầu toàn bộ kỹ sư thử tái hiện vấn đề.
- Ngoài hai kỹ sư ở Thổ Nhĩ Kỳ, phía đội ngũ kỹ sư không có thêm báo cáo nào về việc Chrome bị crash.
- Tính năng báo cáo crash của Chrome bị vô hiệu hóa vì lý do bảo mật, khiến việc xử lý vấn đề trở nên khó khăn hơn.
Bước ngoặt may mắn
- Một kỹ sư ở Denver báo rằng vấn đề bắt đầu xảy ra sau khi tải ứng dụng desktop Grammarly.
- Họ phát hiện rằng xóa ứng dụng Grammarly và khởi động lại máy tính thì vấn đề được giải quyết.
Tiến triển
- Khi đã có thể debug, tác giả thử nhiều cách để tìm ra nguyên nhân của vấn đề.
- Ứng dụng nội bộ chính được xây trên nền ActiveAdmin, nhưng các phần mới dùng React lại không bị crash.
- Trong lúc điều tra phần mã dùng chung, tác giả phát hiện menu thả xuống
My Historylà nguyên nhân gây ra vấn đề.
Giải quyết vấn đề
- Tệp ảnh
loader-spinner.gifđược xác định là thứ gây ra lỗi. - Khi thay GIF đó bằng một ảnh khác, trang không còn bị crash nữa.
- Không rõ là Grammarly hay Chrome đã sửa vấn đề, vì hiện tại GIF gốc cũng không còn làm Chrome bị crash nữa.
Kết luận
- Một ảnh GIF động ngoài dự đoán lại chính là lời giải cho quá trình debug.
- Vấn đề được giải quyết nhờ sự tò mò và hợp tác.
- Gusto mang đến cơ hội làm việc cùng những con người hợp tác tốt và giàu tính tò mò.
Ý kiến của GN⁺
Điểm quan trọng nhất của bài viết này là mô tả chi tiết quá trình phát hiện và xử lý một lỗi có nguyên nhân hoàn toàn bất ngờ. Bài viết cho thấy sự phức tạp và khó lường của kỹ thuật phần mềm, đồng thời nhấn mạnh tầm quan trọng của tinh thần đồng đội và khả năng giải quyết vấn đề một cách bền bỉ. Đây là một ví dụ thú vị về cách các nhóm kỹ thuật phối hợp để xử lý một vấn đề hóc búa, và sẽ là câu chuyện rất hấp dẫn với những ai quan tâm đến lĩnh vực kỹ thuật.
1 bình luận
Ý kiến trên Hacker News
Khi đọc tôi đã nghĩ có lẽ là vấn đề liên quan đến Grammarly, vì trước đây tôi từng gặp một lỗi có biểu hiện tương tự: không tái hiện ổn định được nhưng lại ảnh hưởng đến nhiều người trong cùng một bộ phận
Cuối cùng điểm chung là đều cài tiện ích mở rộng Grammarly, và lỗi chỉ xảy ra ở URL preview staging chứ không phải trên site production
Nguyên nhân là một biểu thức chính quy bị viết sai trong tiện ích Grammarly, và nếu tên miền vượt khoảng 100 ký tự thì trang sẽ bị treo
Nếu vụ này thật sự là do ứng dụng desktop gây ra thì còn đáng sợ hơn
Nhiều vấn đề có thể được thu hẹp đến một tổ hợp cụ thể, nhưng nếu vẫn không biết vì sao lại như vậy thì không thấy thỏa mãn
Nên giờ tôi đang đọc về regex engine: https://swtch.com/%7Ersc/regexp/regexp1.html
Trong quá trình nâng cấp toàn công ty lên Windows 10, chúng tôi thay chiếc laptop cũ của một quản lý, và quy trình như kiểm tra yêu cầu phần mềm/mạng, sao lưu hồ sơ người dùng và tài liệu đều được chuẩn bị đầy đủ
Trong phiếu đánh giá thiết bị có ghi đó là một chiếc ThinkPad 10 năm tuổi, RAM 4GB, và nếu rút dây nguồn thì máy sẽ tắt; nhìn vào đó mới thấy người ấy kiên nhẫn thế nào khi vẫn dùng được nó
Sau khi cấp laptop mới thì gần như mọi thứ đều ổn, chỉ còn việc chuyển giấy phép Grammarly chưa xong nên chúng tôi gửi yêu cầu, và một tuần sau khóa giấy phép được áp dụng nên xác nhận Grammarly cũng hoạt động bình thường
Nhưng đến cuối ngày hôm đó lại có thông báo rằng trang web camera an ninh bị crash, và bộ phận helpdesk đã thử khởi động lại, xóa cache, cài lại trình duyệt, tạo lại profile mà vẫn không giải quyết được nên chuyển sang cho tôi
Tôi kiểm tra mạng, log tường lửa, các PC khác, truy cập tại chỗ/lẫn từ bên ngoài, nhưng bên tôi mọi thứ đều bình thường và người khác cũng không gặp vấn đề gì
Khi tôi hỏi “gần đây có gì thay đổi ở PC hay trong văn phòng không”, người đó đùa rằng “hôm nay tôi cài Grammarly, chẳng lẽ là nó à?”, và vì tôi đã hết ý tưởng nên thử gỡ thật, thế là chạy được
Bật lại Grammarly rồi bấm vào liên kết thì đúng là lại lỗi ngay
Phần mềm camera đó cực kỳ cũ, các liên kết trên trang chủ tùy biến có dạng URL do PHP sinh ra rất dài, và tại địa điểm đó chỉ có mỗi người này dùng Grammarly nên đây là vấn đề chỉ xuất hiện đúng một lần
Các lập trình viên thường quên mất khả năng nguyên nhân đến từ extension, nhưng extension có thể làm đủ thứ kỳ quặc với trang web
Có lần một giáo sư đại học đang viết bài báo và nói rằng gạch chân không được giữ nguyên, tôi tưởng chỉ là lỗi thao tác người dùng đơn giản và sẽ giúp xong trong 5 phút
Nhưng phải hơn 3 tiếng sau tôi mới phát hiện ra rằng chính tổ hợp giữa một phiên bản driver card đồ họa nhất định và một phiên bản driver máy in nhất định đã ngăn việc in phần gạch chân
https://www.zdnet.com/article/xerox-scanners-alter-numbers-i...
Dù đã tắt crash reporting, vẫn có khả năng một tệp .dmp được tạo ở đâu đó trong thư mục profile người dùng
Bạn có thể tải thủ công tệp đó lên bug tại https://crbug.com/new để các lập trình viên Chrome debug
Nếu vì những lý do tương tự như khi tắt crash reporting mà bạn không thể chia sẻ dump, thì có thể build
minidump_stackwalktừ Chromium để tạo stack trace không có symbol rồi đính kèm vào bugKhi đó các lập trình viên Chrome có thể gắn symbol vào
Chi tiết xem tại https://www.chromium.org/developers/decoding-crash-dumps/
Tổ hợp công nghệ tạo ra lỗi này thật thú vị. Web năm 2023 đúng là trông như thế này
Tôi cũng muốn biết liệu bug của Chromium đã được sửa hay chưa, nhưng không dễ lần theo danh sách này: https://bugs.chromium.org/p/chromium/issues/list?can=1&q=gif...
Tôi cũng thích cảm giác Gusto đăng bài này để cho thấy “đó không phải lỗi của chúng tôi”, đồng thời đá xoáy nhẹ Grammarly
Đã từng có vấn đề thỉnh thoảng không có tiếng sau khi khởi động vào Linux, và hóa ra là liên quan đến thiết lập dual boot Windows
Khi khởi động lại từ Windows, Realtek audio device không bị tắt hẳn mà chỉ được để ở trạng thái ngủ, nên Linux không thể khởi tạo thiết bị đó
Cách khắc phục duy nhất là luôn tắt máy từ Windows rồi nhấn nút nguồn để bật lại, và vấn đề vẫn còn đó: https://askubuntu.com/questions/1032543/no-sound-in-ubuntu-1...
Có người dual boot Windows và Linux, và Wi‑Fi chỉ hoạt động nếu họ khởi động vào Windows rồi khởi động lại sang Linux
Lý do là bản cài Linux không có gói firmware cho card Wi‑Fi, nên khi reboot từ Windows thì thiết bị đã ở trạng thái sẵn sàng, còn nếu cold boot thẳng vào Linux thì không được
Tôi đồng ý là cái kết khá là hụt hẫng
Kiểu như chẳng thể truy cập source code của Chrome hay Grammarly nên chỉ còn biết đoán, và tôi tự hỏi liệu đây có phải là hệ quả mà phong trào “open source” tạo ra hay không
Không có source code thì có vẻ đã xuất hiện những lập trình viên hoàn toàn lạc lối và từ chối đào sâu hơn, và với các công ty không muốn sự thật bị phơi bày thì thái độ đó hẳn rất đáng mừng
Trước đây có rất nhiều người disassemble, tìm hiểu và patch chương trình dù không có source, và khá nhiều trong số họ thậm chí còn không phải developer chuyên nghiệp
Họ chỉ đơn giản có động lực muốn phần mềm hoạt động theo ý mình, rồi từ đó tự học những gì cần thiết
Bài này cũng chạm tới việc độ phức tạp của toàn bộ stack đã trở nên điên rồ. Nhìn framework chồng framework, tôi có cảm giác phần lớn là tự chuốc lấy
Họ bảo rằng chỉ cần bỏ
loader-spinner.gif, tức placeholder hiển thị trong lúc các tùy chọn menu đang được tải, thì trang không còn crash nữa, và điều đó cũng khiến tôi tự hỏi vì sao việc tải tùy chọn menu lại mất lâu đến mức cần animationThế giới software engineering quá rộng lớn, và chuyện hiểu mọi phần của stack từ lâu đã gần như bất khả thi
Hơn nữa, software engineering là một hành trình học hỏi, và mỗi người đang đứng ở một điểm khác nhau trên hành trình đó
Chưa nói đến chuyện mở disassembler hay gắn debugger, có vẻ những kỹ năng đó giờ cũng không còn được dạy nhiều nữa
Thường thì nó gần như xong ngay lập tức, nhưng việc có loading spinner để đề phòng trường hợp lâu hơn vẫn là hợp lý
Trường hợp kỳ lạ nhất tôi từng gặp là có người dùng bảo rằng một cụm từ họ nhập vào một form cụ thể sẽ bị đổi đi sau khi lưu
Ban đầu tôi tưởng là có người khác đang chỉnh cùng form đó cùng lúc, nhưng log không cho thấy điều đó, và trên máy tôi thì cụm từ vẫn hiển thị đúng
Rồi tôi phát hiện trong screenshot một số nhãn menu cũng bị lạ, và nguyên nhân là tùy chọn “Dịch trang này” của Chrome đang được bật
Sau khi hướng dẫn họ cách đổi ngôn ngữ đúng cách trong ứng dụng thì vấn đề biến mất
Có vẻ đây là trật tự mới có thể áp vào app hoặc phần tử. Có lẽ nó không phải CSS vì họ không muốn hỗ trợ thay đổi động, và nhìn cũng xấu: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
Thỉnh thoảng tôi xem các meta tag trong những single-page app lớn, rồi trong lúc tìm hiểu vì sao cái tag đó lại cần thiết thì lại phát hiện ra một nỗi kinh hoàng mới
Khi đọc website tiếng Nhật, tôi thường phải dựa vào Google Translate, nhưng mọi website dùng React đều bị vỡ
Vì React và Google Translate đều cố cập nhật DOM node mà không biết tới nhau
Tôi thậm chí đã từng nghiêm túc xem xét implementation của Google Translate để sau này thử làm lại một web widget không gặp vấn đề này
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=872770
Đây là một vấn đề quá quen thuộc
Trước đây tôi từng thấy công cụ trợ năng của Chrome gây ra kiểu lỗi này với menu thả xuống, và nó còn dễ tái hiện đến mức chỉ cần một đoạn HTML rất nhỏ
Bug cụ thể mà tôi dính phải hai năm trước nằm ở Chromium-Edge, nhưng triệu chứng và nguyên nhân rất giống nhau
Grammarly gần như chắc chắn đang dựa vào một phần nào đó của công cụ trợ năng của Chrome
Những công cụ này hơi khác nhau giữa các trình duyệt họ Chromium như Edge, Brave và Chrome
Lần sau nếu gặp chuyện như vậy, tôi khuyên cứ chuyển sang dùng trình duyệt khác
Đặc biệt là Firefox giờ đã cải thiện rất nhiều khả năng nhập bookmark, mật khẩu và các thứ khác từ Chrome
Vũ trụ đang gửi tín hiệu rằng đây là lúc nên chuyển, và chúng ta không thể từ chối tín hiệu đó
Nhân tiện, tôi là kỹ sư Firefox, nhưng điều đó hoàn toàn không liên quan gì đến lời khuyên này cả
Nhưng từ góc độ PM thì chẳng lẽ vừa mất 4 tháng để làm onboarding dễ hơn, giờ lại đi bảo người ta cài trình duyệt mới sao
Một sản phẩm chạy trên trình duyệt mà không hoạt động tử tế trên trình duyệt được dùng nhiều nhất thế giới thì rõ ràng không phải tín hiệu tốt
Vì lý do bảo mật mà chặn báo cáo sự cố Chrome, nhưng lại cho phép nhân viên cài Grammarly — đúng là một chính sách bảo mật doanh nghiệp rất đáng nể