Chiếc ô tô bị dị ứng với kem vani (2000)
(cs.cmu.edu)- Một chủ xe Pontiac mới đã khiếu nại với General Motors Pontiac Division rằng mỗi tối sau khi mua kem, xe chỉ không nổ máy khi anh chọn vani
- Chủ tịch Pontiac nghi ngờ bức thư, nhưng vẫn cử một kỹ sư đến kiểm tra, và tại hiện trường đã tái hiện được việc mua vani xong thì không nổ máy
- Vào những ngày mua sô-cô-la và dâu, xe vẫn khởi động được, nhưng vào ngày mua vani thì lại thất bại, cho thấy điều kiện tưởng như vô lý này lặp lại một cách nhất quán
- Kỹ sư ghi lại thời gian, loại nhiên liệu, thời gian đi-về và thời gian mua hàng, rồi phát hiện khác biệt về lộ trình di chuyển: chỉ có vani là có thể mua rất nhanh từ một tủ lạnh riêng ngay phía trước cửa hàng
- Nguyên nhân không phải là vị kem mà là do thời gian mua quá ngắn khiến động cơ không kịp nguội hẳn, gây ra vapor lock; ngay cả những báo cáo kỳ lạ cũng cần được kiểm chứng bằng quan sát và tái hiện
Vấn đề khởi động kỳ lạ của Pontiac
- Một chủ xe Pontiac đã gửi bức thư thứ hai tới Pontiac Division của General Motors
- Gia đình anh mỗi tối sau bữa ăn đều bỏ phiếu chọn vị kem để ăn tráng miệng, và anh sẽ lái xe đến cửa hàng mua kem về
- Sau khi mua chiếc Pontiac mới, một vấn đề chỉ lặp lại trong một điều kiện cụ thể
- Nếu mua kem vani, anh không thể khởi động xe để rời cửa hàng
- Nếu mua vị khác, xe lại khởi động bình thường
- Anh thừa nhận câu hỏi này nghe có vẻ ngớ ngẩn, nhưng vẫn hỏi vì sao chiếc Pontiac lại chỉ không nổ máy khi anh mua vani
Kiểm tra tại chỗ và tái hiện lặp lại
- Chủ tịch Pontiac nhìn bức thư với sự hoài nghi, nhưng vẫn cử kỹ sư đi xác minh trực tiếp
- Kỹ sư gặp chủ xe ngay sau bữa tối và cùng anh đến cửa hàng kem
- Hôm đó là ngày mua vani, và khi hai người quay lại xe, quả thực xe không nổ máy
- Trong ba ngày tiếp theo, họ thay đổi điều kiện để kiểm tra, và kết quả rất rõ ràng
- Ngày đầu mua sô-cô-la thì xe khởi động được
- Ngày thứ hai mua dâu thì xe cũng khởi động được
- Ngày thứ ba mua vani thì lại không khởi động được
Manh mối từ việc ghi chép quan sát
- Kỹ sư không chấp nhận cách giải thích rằng chiếc xe bị dị ứng với kem vani
- Ông quyết định tiếp tục đến hiện trường cho đến khi tìm ra lời giải và ghi lại nhiều dữ liệu
- Khung giờ
- Loại nhiên liệu sử dụng
- Thời gian đi-về tới cửa hàng
- Thời gian cần để mua hàng
- Manh mối quyết định là thời gian mua vani ngắn hơn các vị khác
- Cách bố trí trong cửa hàng đã tạo ra chênh lệch thời gian đó
- Vani là vị bán chạy nhất nên được đặt trong một tủ lạnh riêng ở phía trước cửa hàng để khách có thể lấy nhanh
- Các vị khác nằm ở quầy phía sau, nên mất nhiều thời gian hơn để tìm vị và thanh toán
Nguyên nhân thực sự: vapor lock
- Trọng tâm của vấn đề không phải là vị kem mà là thời gian chờ ngắn
- Sau khi xác định thời gian là nguyên nhân, kỹ sư tìm ra thủ phạm là vapor lock
- vapor lock thực ra xảy ra mỗi ngày, nhưng khi mua các vị khác thì thời gian mua lâu hơn, động cơ đã kịp nguội và xe có thể khởi động
- Khi mua vani, thời gian mua quá ngắn nên động cơ vẫn còn nóng, vapor lock chưa biến mất nên xe không thể khởi động
Bài học
- Ngay cả những vấn đề thoạt nhìn có vẻ phi lý, các sự kiện được quan sát vẫn có thể là thật
- Dù triệu chứng trông rất khó tin, nếu lặp lại việc kiểm tra điều kiện và thu thập dữ liệu thì vẫn có thể tìm ra nguyên nhân thực sự
1 bình luận
Ý kiến trên Hacker News
Cuối thập niên 90, ở chỗ làm tôi cũng gặp một chuyện tương tự. Chuột của một nhân viên chỉ bị đơ vào một số khung giờ nhất định trong ngày: buổi sáng thì ổn, đến gần trưa thì không dùng được, rồi sau đó lại hoạt động trở lại.
Manh mối quyết định là vào những ngày nhiều mây thì nó chạy ổn cả ngày, nhưng ngày nắng thì cùng một hiện tượng lỗi lại lặp lại. Hóa ra vỏ nhựa của con chuột bi rẻ tiền quá mỏng, nên vào ngày nắng, ánh mặt trời lấn át các cảm biến trục X/Y hơn cả đèn LED; chỉ đến khi mặt trời di chuyển và tạo bóng râm thì nó mới hoạt động bình thường lại. Ban đầu nghe rất vô lý, nhưng nguyên nhân thì hoàn toàn logic.
Có vẻ một số phiên bản jailbreak Pangu cho iOS 7.1.x bị crash trong lúc khởi động nếu giá trị cảm biến ánh sáng môi trường thấp hơn một ngưỡng nhất định. Nguyên nhân chính xác thì vẫn chưa rõ, nhưng có vẻ Pangu đã đưa vào đoạn mã không cần thiết đụng tới cảm biến ánh sáng [1]
[1] https://www.reddit.com/r/jailbreak/comments/294wob/jailbreak...
[2] https://www.reddit.com/294wob/
Sau khi kiểm tra đủ thứ, tôi nhận ra vấn đề không xảy ra khi trời mưa, mà khi có sương mù dày hoặc mưa phùn. Kỹ thuật viên của công ty cáp kiểm tra thì bên trong nhà không có vấn đề gì; hóa ra sợi cáp từ đường chính vào nhà có một vết xước rất nhỏ, khiến hơi ẩm xung quanh thấm vào và làm hỏng kết nối.
Khi khay đá đầy, tia hồng ngoại phải bị chặn để máy ngừng làm đá, nhưng vào ngày nắng, ánh sáng mạnh trong bếp đánh lừa cảm biến khiến máy tiếp tục làm đá. Vì vậy tôi đặt đại một cuốn tạp chí lên trên để nó hoạt động đúng.
Một ngày nọ, các bài test liên quan đến ứng dụng client đồ họa X đột nhiên bắt đầu fail chập chờn, nhưng không thể tái hiện trong các điều kiện khác. Hóa ra các job CI đang chạy trên những máy desktop đặt đâu đó trong công ty, và ai đó đã cắm chuột vào một máy rồi bỏ mặc nó trên kệ. Khi tải máy tăng cao, quạt quay nhanh hơn và độ rung lớn hơn, làm con chuột dịch chuyển rất nhẹ; vì lý do không rõ, việc đó gây tác dụng phụ lên bài test. Tôi khá tự hào vì đã chẩn đoán ra qua SSH một cái máy thậm chí không có mặt tại hiện trường.
Hóa ra tấm pin mặt trời, hoặc bộ optimizer, inverter nào đó đang phát ra tần số vô tuyến gây nhiễu với remote cửa garage. Khi có nắng và hệ thống đang sản xuất điện, nhiễu mạnh hơn cả bộ mở cửa garage Homelink. Vài năm trước, bộ mở cửa garage đột nhiên bắt đầu hoạt động tốt, và vài ngày sau tôi mới biết là do inverter đã hỏng. Theo quy định của FCC, có lẽ bên lắp đặt phải sửa, nhưng quan hệ đã xấu đi từ lúc lắp đặt nên tôi thấy bỏ remote còn hơn phải làm việc với họ để bảo hành sửa chữa.
Một giai thoại buồn cười nghe kể lại từ thời còn có phòng máy chủ. Máy chủ ở công ty của một người bạn cứ khoảng 5 giờ chiều hằng ngày lại khởi động lại, và dù kiểm tra mọi thứ có thể ở phía hệ điều hành vẫn không tìm ra nguyên nhân.
Cuối cùng họ quyết định đứng trước máy chủ vào đúng giờ đó, và thấy nhân viên vệ sinh bước vào phòng, rút nguồn của rack máy chủ, cắm máy hút bụi vào để dọn dẹp, rồi cắm lại rack máy chủ.
Có một camera cứ khởi động lại gần như vào cùng một thời điểm mỗi ngày; không chính xác đến cùng một giây, mà có một quy luật rõ ràng như hôm thì 19:12:10, hôm sau muộn hơn 2 giây, hôm tiếp theo cũng muộn hơn 2 giây. Hóa ra lúc mặt trời lặn, một công trình trên đường đổ bóng trước camera, và phần mềm nhầm đó là xe nên bắt đầu thu thập thông tin phân loại. Vì cái bóng di chuyển chậm hơn xe thật rất nhiều, bộ nhớ bị cạn trước khi nó ra khỏi khung hình, hệ thống treo rồi watchdog khởi động lại. Quy luật thời gian là do góc mặt trời thay đổi mỗi ngày, khiến cái bóng đánh lừa thuật toán muộn hơn một chút.
[0] https://old.reddit.com/r/talesfromtechsupport/comments/5yrs1...
[1] https://www.goodreads.com/book/show/3227607-the-devouring-fu...
Tôi ngồi canh vào khung giờ đó suốt một tuần, rồi thấy đèn tối đi và máy chủ khởi động lại. Luật sư ở văn phòng bên cạnh đi làm, đồng thời bật PC, máy in và ấm cà phê trên cùng một ổ cắm kéo dài, và dòng khởi động làm sụt điện áp trên mạch mà máy chủ đang dùng. Có UPS, nhưng UPS tiêu dùng thời đó chỉ xử lý mất điện; chúng tôi đo được điện áp rơi xuống tận 85V, và thực tế cứ dưới 95V là máy thường khởi động lại.
Đó là đầu giờ chiều thứ Sáu, trời nóng ẩm và sắp có giông, khoảng 16 giờ thì người phụ trách đến bảo tôi làm nhanh lên vì 17 giờ họ sẽ cắt điện toàn bộ tòa nhà. Họ đang tắt điện vào mỗi thứ Sáu để tiết kiệm năng lượng, và trớ trêu là việc dọn dẹp DB lại được lên lịch vào 16:30 hằng thứ Sáu. Vì vậy, trong một giờ còn lại, tôi sửa sự cố, hủy lịch chạy của tuần đó rồi tắt DB server thủ công. Việc cưỡng bức cắt điện hằng tuần đã gây sự cố vận hành cho server Netware và DB server của phần mềm thu tiền, và theo hợp đồng bảo trì thì lần nào chúng tôi cũng phải sửa. Cuối cùng khoảng một tháng sau họ mới dời việc cắt điện cưỡng bức sang sáng thứ Bảy, để sau khi tác vụ sao lưu hoàn tất thì server có thể được tắt đúng cách.
Chuyện này làm tôi nhớ đến chiếc minivan GM mà anh rể tôi lái hồi thập niên 80. Đó là xe do bố vợ tôi, một kỹ sư ô tô của GM, đưa cho; thỉnh thoảng nó ngẫu nhiên không nổ máy và trông như toàn bộ hệ thống điện đã chết.
Vì anh rể tôi bị xem là người không rành xe cộ, bố vợ tôi không xem lời phàn nàn đó là nghiêm túc. Cuối cùng họ đổi xe cho nhau trong một tháng; sự cố tái hiện ngay tại bãi đỗ của GM Technical Center, và cả các kỹ sư GM tụ lại xung quanh cũng không tìm ra vì sao nó trông như hệ thống điện đã chết, nên anh rể tôi được minh oan.
Vài giờ sau xe lại nổ máy như chưa từng có chuyện gì, nên trung tâm dịch vụ cũng không chẩn đoán được. Về sau nó bắt đầu ảnh hưởng đến cuộc sống khi không nổ máy cả trong lúc đi cắm trại off-road, và cuối cùng một lần nó không nổ ngay trên lối vào nhà, tôi kéo đến một garage độc lập khi xe vẫn đang ở trạng thái lỗi, và ở đó sự cố cũng tái hiện. Thợ đề xuất thay mô-đun ECU hoặc thay cả hộp cầu chì; ECU tốn vài nghìn đô, còn thay hộp cầu chì thì dưới 200 đô đã gồm công, nên tôi chọn phương án sau. Đến nay đã 6–7 năm, chiếc xe đó vẫn là chiếc xe chính duy nhất, và kể từ đó chưa từng có vấn đề cơ khí nào.
Việc xe GM trong giai đoạn khét tiếng đó gặp các sự cố điện bí ẩn khiến người ta phát điên là điều hoàn toàn có vẻ hợp lý.
Có lẽ ở đâu đó một relay bị quá nhiệt và kẹt ở trạng thái đóng, nhưng tôi không tự debug được, và người anh họ làm thợ sửa ô tô của tôi cũng không tìm ra. Chúng tôi không cố quá nhiều; khi chuyện đó xảy ra thì rút cầu chì ra, sáng hôm sau cắm lại.
Starter nhiều khi vẫn quay tốt, nhưng thiết bị điện tử bị kẹt trong trạng thái lạ và chỉ hết sau khi ngắt ắc quy để hard reset.
Từng gặp một hiện tượng lặp lại kỳ lạ liên quan đến thiết bị điện tử ở nhà cũ. Vào nửa đêm một ngày cố định trong tuần, từ các thiết bị điện tử cố định vang lên rất khẽ một âm thanh nghe như bản ghi diễn văn chính trị thời Thế chiến II.
Âm thanh quá nhỏ nên khó xác định phát ra từ đâu, lời nói thì không nghe rõ, nên có cảm giác như một bản ghi cũ đang vang lên đồng thời từ khắp nơi. Dù rút điện, thậm chí nhà bị mất điện, nó vẫn tiếp tục. Tôi đã nghĩ mình sắp phát điên, hoặc nhà bị ma Hitler ám, nhưng sau đó nghe thấy thứ tương tự trên radio ô tô và hiểu ra. Một đài phát thanh AM Công giáo bắt đầu phát sóng vào đúng ngày đó, đúng giờ đó, bằng thánh ca Gregorian và bài giảng; hệ thống dây điện trong nhà bằng cách nào đó đã hoạt động như một bộ thu radio AM, khiến một số linh kiện rung lên thành âm thanh được chở trên tín hiệu vô tuyến.
Mỗi khi con trai tôi chơi American Truck Simulator, màn hình laptop lại tắt, và trong lúc màn hình đen, chiếc xe tải lao ra khỏi đường.
Khi tôi chơi trên cùng chiếc laptop thì không xảy ra, nên con trai tôi tin chắc mình bị nguyền rủa. Sau vài ngày lặp lại, tôi ngồi cạnh quan sát cháu chơi và nhận ra dây đồng hồ của cháu là dây kim loại có khóa nam châm. Vị trí cổ tay đã kích hoạt cảm biến Hall của laptop, khiến máy tưởng rằng nắp đã đóng. Cả con trai tôi, tôi và vợ đều nhẹ nhõm khi biết cháu không bị nguyền rủa.
https://www.ifixit.com/News/33952/apple-put-a-hinge-sensor-i...
Những câu chuyện như thế khiến Car Talk thú vị đến vậy. Không chỉ là chuyện thợ sửa xe sửa xe, mà vì tình huống quá kỳ quặc và đặc biệt nên rất hấp dẫn.
Cũng rất vui khi nghe những thợ máy lâu năm đã thấy quá nhiều tình huống lạ lùng kiểu này đến mức coi chúng như chuyện bình thường; hơn nữa họ còn là những người kể chuyện tuyệt vời.
Bài học với tôi không hẳn là “những vấn đề trông có vẻ vô lý đôi khi là thật”, mà là vấn đề của người dùng thường thực sự tồn tại, nhưng đừng tin khả năng chẩn đoán nguyên nhân của họ.
Bức thư không khẳng định kem là nguyên nhân gốc, và nói rất rõ rằng đó là nguyên nhân gần. Chủ tịch Pontiac và người viết “bài học” đó có thể đã nhầm lẫn hai điều này, nhưng kỹ sư điều tra thì không.
Từ kinh nghiệm từng làm cả helpdesk trong công việc phát triển, người dùng rất dễ chỉ định một sự thật tùy ý làm nguyên nhân của vấn đề. Các heuristic như “tương quan là nhân quả” hay post hoc ergo propter hoc có thể hữu ích, nhưng sẽ tệ nếu chúng thay thế cho suy luận. Vì người dùng không biết nguyên lý hoạt động của thứ họ dùng nên khó chẩn đoán đúng, và những người dùng nghĩ rằng mình “biết chút ít về chuyện đó” thường lại là nhóm khó xử lý nhất.
Xe của vợ tôi hiện thiếu nước rửa kính, nhưng cảnh báo chỉ hiện lên tại một điểm nhất định khi đang lái. Không phải một khoảng cách nhất định tính từ nhà, mà là đúng một vị trí.
Ban đầu tôi nghĩ có thể do thời gian đi rồi quay về đâu đó, nhưng dù trước đó đã lái 5 phút, 5 dặm, 1 giờ hay 60 dặm, màn hình và âm cảnh báo luôn bật lên tại vị trí đó. Manh mối bổ sung duy nhất là điểm đó là vùng sóng yếu với hầu hết điện thoại và nhà mạng. Tôi đã châm thêm nước rửa kính nên bí ẩn tạm thời ngủ yên, nhưng tôi tò mò liệu mọi cảnh báo có xuất hiện vào lúc đó không. Cảm giác như telemetry của xe bị chạm vào ở điểm đó, thức dậy và nói gì đó.
Nó có thể gây ra nhiễu kỳ lạ vừa đủ để đẩy cảm biến từ “đủ chất lỏng” sang “thiếu”.
Chỉ là vấn đề chất lỏng chuyển động trong bình chứa thôi. Hôm nay tôi đã xịt rửa kính chắn gió một chút để xe bật hẳn đèn báo mức thấp.
Vào một đêm khi đang làm bài tập Java trong phòng thực hành khoa học máy tính, giáo sư phụ trách đi ngang qua và nói: “À, với cái máy đó thì chắc phải chúc may mắn thôi.”
Cái máy đó từng không chạy được bất kỳ chương trình Java nào và chết một cách hoành tráng, nhưng C++ hay Python thì vẫn ổn. Chương trình của vị giáo sư ban đầu không tin chuyện đó cũng làm máy bị crash. Sau khoảng 2 tuần kiểm tra của một kỹ thuật viên và vị giáo sư, họ phát hiện rằng mỗi khi JVM khởi động, nó đều gán số nguyên 12 vào cùng một địa chỉ RAM, và chip RAM chứa địa chỉ phần cứng đó bị lỗi. Mỗi lần cố gán vào địa chỉ đó thì máy lại crash, và ngay khi thay thanh RAM hỏng, vấn đề được giải quyết lập tức.
https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
Tôi sẽ không spoil kết luận. Đây là một hành trình debug dài và quanh co, rất đáng đọc. Thảo luận trên HN:
https://news.ycombinator.com/item?id=15845118
Câu chuyện này là một ví dụ thú vị về biến gây nhiễu
Trong suy luận nhân quả, biến gây nhiễu là biến tác động đến cả biến phụ thuộc lẫn biến độc lập, tạo ra một mối liên hệ giả. Đây là một khái niệm nhân quả không thể giải thích chỉ bằng tương quan, và là một trong những lý do định lượng quan trọng đằng sau câu “tương quan không có nghĩa là quan hệ nhân quả”
https://en.wikipedia.org/wiki/Confounding
Nếu viết dưới dạng mô hình thống kê, có thể xem là
S = f(H, I, T).Slà việc xe có khởi động được hay không,Hlà nhiệt độ động cơ,Ilà loại kem đã chọn, cònTlà thời gian mất để mua kem. KhiTngắn, động cơ còn nóng hơn nên dễ bị vapor lock, từ đó ảnh hưởng đếnS; đồng thời vị trí của kem vani khiến nó có thể được mua nhanh hơn, nên cũng liên quan đếnI. Vì vậy, một mối quan hệ giả xuất hiện giữaIvàS.Tảnh hưởng đếnI, mà làIảnh hưởng đếnTsao? Vì loại kem quyết định thời gian đi lại trong cửa hàng mà.