- Apple tự động đóng các lỗi được báo qua Feedback Assistant nếu người dùng không trực tiếp xác nhận (verify) rằng lỗi vẫn chưa được sửa
- Với lỗi rò rỉ quyền riêng tư liên quan đến tiện ích mở rộng bộ lọc mạng (FB12088655) đã không có phản hồi suốt 3 năm, Apple đột ngột yêu cầu xác nhận và coi như đã được sửa nếu không có phản hồi trong vòng 2 tuần
- Tuy nhiên, các nhà phát triển Little Snitch xác nhận cùng một vấn đề vẫn còn tồn tại trên macOS mới nhất, nhưng Apple vẫn đóng báo cáo
- Quy trình này vận hành như một cơ chế làm giảm số lượng báo cáo lỗi một cách nhân tạo, tạo ra hiệu ứng che khuất các vấn đề chất lượng thực tế
- Kết quả là, cách quản lý lỗi của Apple làm suy yếu niềm tin của nhà phát triển và cản trở văn hóa phản hồi mang tính hợp tác
Vấn đề Apple tự động đóng báo cáo lỗi
- Một nhà phát triển đã báo lỗi qua Apple Feedback Assistant chỉ trích thông lệ Apple tự ý đóng báo cáo mà không có xác nhận từ người dùng
- Apple tự động đóng báo cáo nếu người dùng không trực tiếp xác nhận rằng “lỗi vẫn chưa được sửa”
- Sau nhiều năm không phản hồi, Apple bất ngờ gửi yêu cầu xác nhận và coi là “đã sửa xong” nếu không có phản hồi trong vòng 2 tuần
- Trong trường hợp FB12088655 “Privacy: Network filter extension TCP connection and IP address leak” được gửi vào tháng 3/2023, Apple đã im lặng suốt 3 năm rồi đến tháng 3/2026 mới yêu cầu xác nhận trên macOS 26.4 beta 4
- Do không cài beta OS thường xuyên nên việc xác minh gặp khó khăn, và dù đã hỏi Apple liệu lỗi có thực sự được sửa hay chưa thì vẫn không nhận được câu trả lời rõ ràng
- Apple thông báo rằng “nếu không xác nhận trong vòng 2 tuần, chúng tôi sẽ coi là đã được sửa và đóng báo cáo”
- Các nhà phát triển Little Snitch báo cáo rằng cùng vấn đề vẫn tái hiện được trên macOS 26.4 beta 4
- Trên thực tế, cùng lỗi đó vẫn còn tồn tại ở bản phát hành chính thức macOS 26.4
- Việc Apple yêu cầu người dùng trực tiếp xác nhận với một lỗi chưa được sửa bị chỉ ra là quy trình kém hiệu quả và thiếu hợp lý
- Có ý kiến cho rằng nội bộ đang tồn tại cơ chế khuyến khích nhằm giảm số lượng báo cáo lỗi
- Vì vậy, số “lỗi còn mở” giảm xuống, khiến các chỉ số nội bộ trông như chất lượng đã được cải thiện
Các trường hợp báo lỗi khác
- Một trường hợp khác là lỗi FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tab”
- Dù là vấn đề có thể tái hiện 100%, Apple vẫn đánh dấu là “Đã hoàn tất điều tra - Không thể chẩn đoán với thông tin hiện tại (Investigation complete - Unable to diagnose with current information)”
- Ngày 9/3 đã có yêu cầu bổ sung thông tin nhưng Apple không phản hồi
- Trên bản beta iPadOS 26.4, một lỗi Safari bị crash mới phát sinh, nhưng Apple không sửa trước khi phát hành bản công khai
- Tác giả chỉ trích rằng “mục đích của beta có vẻ không phải để sửa lỗi, mà là để làm phiền những người đi báo lỗi”
Thay đổi sau Hacker News và phản ứng của Apple
- Ngay sau khi bài viết này lên trang đầu Hacker News, Apple đã cập nhật báo cáo FB22057274
- Apple yêu cầu gửi log sysdiagnose cho vấn đề giao diện người dùng
- Tác giả chỉ ra rằng đã cung cấp các bước tái hiện và video quay màn hình, còn sysdiagnose là dữ liệu không cần thiết và có nguy cơ xâm phạm quyền riêng tư
- Tác giả đã phản hồi yêu cầu của Apple như sau
- “Lỗi UI không cần sysdiagnose và nó cũng không hữu ích”
- Tác giả cho biết có thể tái hiện vấn đề ngay cả khi không có Little Snitch bằng cách dùng Network Link Conditioner trong Xcode Additional Tools để đặt cấu hình độ trễ uplink 3000ms
Giới thiệu Xcode Additional Tools
- Xcode Additional Tools bao gồm nhiều tiện ích hữu ích,
có thể tải từ trang Apple Developer Downloads (cần đăng nhập)
Đánh giá tổng thể
- Cách Apple quản lý báo cáo lỗi tạo gánh nặng không cần thiết cho nhà phát triển,
và vận hành theo hướng giảm số lượng báo cáo hơn là giải quyết vấn đề thực tế
- Các báo cáo bị bỏ mặc trong thời gian dài, yêu cầu xác nhận vô lý và các yêu cầu thông tin kém hiệu quả đang làm
suy yếu niềm tin và thiện chí hợp tác của nhà phát triển
1 bình luận
Ý kiến trên Hacker News
Có vẻ tác giả chưa từng trải qua phần mềm doanh nghiệp
Khi nhà phát triển nhận được báo cáo lỗi, chiêu điển hình là kéo dài thời gian bằng câu kiểu “không tái hiện được, bạn đã kiểm tra trên phiên bản mới nhất chưa?” trong khi thực ra chẳng làm gì cả
Nếu vẫn không xác minh được thì họ sẽ đóng với lý do “lỗi người dùng” hoặc “không thể tái hiện”
Cách đối phó duy nhất là nói “vâng, tôi đã kiểm tra” trong khi thực tế là chưa kiểm tra
Nếu trong log thấy phần mềm diệt virus thì họ sẽ đóng ngay với câu “hãy liên hệ bên đó”
Vì có quá nhiều ưu tiên kinh doanh quan trọng hơn một lỗi do một người dùng đơn lẻ báo lên
Dù vậy, ở góc nhìn người dùng thì điều này vẫn rất đáng tiếc
Phần lớn nhà phát triển либо không biết kiểm thử sản phẩm của chính họ, либо thấy phiền nên không làm
Thời làm hỗ trợ kỹ thuật doanh nghiệp, mỗi ngày tôi phải nhận ít nhất hai case mới và quản lý đồng thời hơn 20 case
Cảm giác giải thoát khi đóng những case không có tiến triển dưới dạng “đóng do không hoạt động” là rất lớn
Về sau còn có quy định phải liên hệ ba lần trước khi đóng, đúng là ác mộng
Cuối cùng thì chính quan liêu ở tập đoàn lớn phá hỏng mọi thứ
Apple thể hiện thái độ như thể đang cầu mong lỗi tự biến mất
Giờ tôi cũng không gửi bug report nữa
Bị phớt lờ thì còn chấp nhận được, nhưng vấn đề là họ coi tôi như nhân lực QA không lương
Họ đòi hỏi một lượng công sức khổng lồ chỉ để chứng minh lỗi là có thật
Kiểu suy nghĩ là “đây là phần mềm của anh, anh tự debug đi”
Các dự án mã nguồn mở cũng hay tự động đóng issue stale theo cách tương tự
Việc mặc định coi là đã được giải quyết chỉ vì đã qua một khoảng thời gian là vô lý
Điểm hay của mã nguồn mở là bạn có thể tự sửa, gửi PR, hoặc fork ra để tự giải quyết
Lọc các ticket cũ như vậy hợp lý hơn nhiều
Từ phía người dùng thì rất bực, nhưng không phải lỗi nào cũng dễ tái hiện
Đôi khi sau khi có thay đổi ở đoạn mã liên quan, việc yêu cầu người dùng kiểm tra lại là cách hiệu quả hơn
Dù vậy, khi đóng những lỗi cũ nhưng không thể thực thi được thì vẫn thấy không thoải mái
Điều đó chỉ có nghĩa là họ không tái hiện được trong mạng nội bộ của Apple
Đóng lại chỉ là cách che giấu vấn đề, và việc để mở không tốn chi phí
Việc phải cài bản beta rõ ràng kém hiệu quả hơn rất nhiều với người dùng
Tôi đã cung cấp cả dự án mẫu Xcode lẫn các bước tái hiện
Tôi tin chắc Apple đã chẳng làm gì cả
Có lẽ họ đang làm màn dọn dẹp bug để chuẩn bị cho macOS 27 trước WWDC
Khi làm ở Facebook và Google, tôi đã thấy rất nhiều mánh quản lý bug
Sau khi áp dụng SLA, họ hạ ưu tiên bug một cách giả tạo hoặc đẩy trách nhiệm về phía người dùng bằng câu “vấn đề này vẫn còn chứ?”
Rồi theo thời gian họ sẽ đóng lại với lý do “phiên bản đó đã bị loại bỏ”
Thậm chí còn cố tình gộp vào bug khác để né trách nhiệm
Cuối cùng, tất cả chuyện này đều do chỉ số hiệu suất của tổ chức (SLA)
Vì vậy giờ tôi hầu như không gửi bug report nữa
Nhưng ban lãnh đạo lại chỉ đạo rằng “lúc này hãy tập trung vào dự án AI”
Trong khi đó họ vẫn quở trách rằng “có quá nhiều bug”
Tôi thấy việc cứ lờ đi còn thành thật hơn là đóng nó lại
Lãnh đạo đã thúc đẩy kiểu triage cưỡng ép như vậy
Chặn thông báo tự động là một vấn đề
ví dụ trang web có thể đã chết hoàn toàn nhưng nếu đang mùa thấp điểm thì chưa chắc đã là P0
Nhưng trên thực tế, chất lượng dữ liệu thấp đến mức không thể dùng cho báo cáo
Vì thế một giá trị ưu tiên duy nhất lại thực tế hơn
stalebot chỉ đang đóng thay những issue bị phớt lờ kiểu đó mà thôi
Họ quản lý riêng severity cho khách hàng và priority nội bộ
Salesforce “Lightning Experience” trái với cái tên của nó thì rất chậm
Công cụ nội bộ nhanh và hiệu quả hơn nhiều
Ở ElevenLabs cũng xảy ra điều tương tự
Khi gửi bug report, AI sẽ tự động trả lời và sau 48 giờ thì bị đánh dấu stale
Có lẽ sắp tới LLM agent sẽ giải quyết được kiểu vấn đề này
Chúng có thể tự động bình luận “vẫn chưa được sửa” và định kỳ bump tự động bằng câu như “điều này ảnh hưởng tới một workflow quan trọng”
Trước đây tôi từng gửi bug cho Microsoft, vài tháng sau họ báo “không thể tái hiện”
Thực ra trong khoảng thời gian đó, một bản sửa khác đã gián tiếp giải quyết vấn đề
Tôi nhận ra mình chỉ là người mù sờ một phần con voi
Tôi là cựu nhân viên Apple
Trình theo dõi bug nội bộ của Apple được gọi là Radar, và mọi issue đều phải qua bước “Verify” thì mới có thể đóng
Bề ngoài thì giống một quy trình đảm bảo chất lượng, nhưng trên thực tế vô số Radar bị mắc kẹt vĩnh viễn ở trạng thái Verify
Các đội bị đánh giá bằng “số Radar chưa được xác minh”, nên sau một thời gian họ sẽ cưỡng ép đóng chúng lại
Ảo tưởng “0 bug” tạo ra chỉ số thành tích méo mó
Không thể xem đó là bằng chứng rằng kỹ sư Apple đã thực sự cố sửa lỗi
Ở công ty, tôi từng cùng đồng nghiệp họp dọn dẹp backlog
và xử lý những lỗi cũ chỉ xuất hiện một lần
Kiểu quy trình này là cực kỳ phổ biến