Kỹ thuật

Kỹ thuật

Mythex được xây dựng và vận hành như thế nào, kể cả sự cố và cách chúng tôi khắc phục.

• Một lần republish thất bại không bao giờ xóa backend đang chạy — Một lần republish thất bại có thể xóa API đang sống của app, hoặc để lại phiên bản mới hỏng đang chạy. Ba cách sửa lại cách Mythex hoàn tác một lần publish bị lỗi.
• Cảnh báo chỉ kích hoạt một lần, không phải một lần mỗi server — Một cảnh báo mỗi ngày một lần đã đến năm lần trong một buổi chiều. Vì sao khử trùng lặp trong bộ nhớ thất bại với hai server và deploy, và cách trạng thái dùng chung đã sửa.
• Chuyển sang không gian làm việc lớn hơn mà không ai phải chờ — Một phần tư không gian làm việc vẫn ở mức 1 GB sau khi chuyển sang 2 GB. Bản sửa đầu tiên khiến một người chờ bảy phút. Chúng tôi đã thay đổi gì, và thay đổi lần nữa.
• Tính phí cơ sở dữ liệu theo mức thực sự sử dụng — Trước đây chúng tôi ước tính chi phí cơ sở dữ liệu của mỗi app, và ước tính đó sai cả hai chiều. Giờ mỗi cơ sở dữ liệu được tính phí theo mức sử dụng đo được, từng giờ.
• Bắt những app bị crash ngay sau khi publish — Ba lần publish qua được health check dù API bị crash vài giây sau mỗi lần khởi động. Nguyên nhân: đếm crash trong danh sách chỉ giữ năm mục. Giờ so sánh crash mới nhất.
• Giữ các lượt agent nhiều ảnh trong giới hạn bộ nhớ — Một lượt agent cứ xem các bản quét catalogue đã hết bộ nhớ ở mức 952 MB. Ba nguyên nhân riêng biệt, mỗi cái giữ ảnh quá lâu, và cách chúng tôi sửa.
• Giữ các lượt agent dài trong cửa sổ ngữ cảnh — Các sub-agent của chúng tôi có thể phình to đến mức model từ chối, tự dừng sớm để tiết kiệm chỗ, hoặc đếm sai token với tiếng Nga. Ba bản sửa giúp công việc AI dài hoàn thành.
• Giữ chat hoạt động khi điện thoại ngủ — Điện thoại ngủ, chuyển tab và mất mạng giữa lúc build. Hai lỗi khiến chat của Mythex bị treo hoặc chỉ hiện nửa câu trả lời sau đó. Cách chúng tôi tìm ra và sửa cả hai.
• Một chat nặng có thể làm sập API của chúng tôi như thế nào — Ngày 28/9, cả hai máy chủ API hết bộ nhớ cùng lúc. Cách sửa đầu tiên là thêm bộ nhớ; cách thực sự là tải lịch sử chat theo kích thước, không theo số lượng.
• Nhấn Publish hai lần giờ chỉ publish một lần — Ba yêu cầu publish cho cùng một app đến API cách nhau 84 mili giây và mỗi cái chạy một lần deploy đầy đủ. Cách chúng tôi để cơ sở dữ liệu quyết định ai được publish.
• Bài học SEO từ việc sửa chính trang web của chúng tôi — Mã FAQ bị trùng, ảnh đại diện sai trên Google, trang mẫu không ai nhấp và một đường dẫn bị chặn: những gì chúng tôi tìm thấy trên mythex.ai và đã sửa.
• Trang tĩnh vẫn hoạt động trong khi được xuất bản lại — Trước đây xuất bản lại trang tĩnh xóa trang đang chạy trước. Giờ trang cũ vẫn phục vụ cho đến khi bản mới lên, và thay đổi hiện trong vài giây.
• Lỗi hết bộ nhớ ẩn trong một nhãn tiến trình — Agent AI của chúng tôi hết bộ nhớ khi viết một file lớn. Nguyên nhân không phải mô hình hay các sub-agent chạy song song — mà là một nhãn trạng thái bị gửi lại 41.000 lần.
• File swap bị thiếu đã làm đứng các máy chủ của chúng tôi — Một máy chủ production ngừng phản hồi mà không crash, do thrashing bộ nhớ trên máy không có swap. Điều xảy ra và chúng tôi đã thay đổi những gì.
• Đánh thức cơ sở dữ liệu mà không gặp kết nối đã chết — Ứng dụng thức dậy từ trạng thái ngủ giữ yêu cầu đầu tiên 10–12 giây trên kết nối cơ sở dữ liệu đã chết. Cách chúng tôi đưa xuống còn 2,3 giây.
• Chúng tôi đang tự giới hạn tốc độ các dịch vụ của mình — Giới hạn yêu cầu theo địa chỉ của API chúng tôi coi các dịch vụ nội bộ như một người dùng bận rộn, và trên production chúng bắt đầu nhận lỗi 429. Cách chúng tôi tìm ra và sửa.
• Vì sao chúng tôi chuyển máy chủ của Mythex sang ARM — Khi công việc nặng chuyển vào sandbox riêng, máy chủ của chúng tôi chỉ dùng khoảng một phần ba bộ nhớ. Máy ARM nhỏ hơn giảm chi phí khoảng 30%. Đây là cách.
• Cách chúng tôi đưa triển khai về không có lỗi 502 — Watchdog tranh chấp với triển khai và load balancer nhận ra muộn. Cách chúng tôi tìm và sửa cả hai, và đưa số lỗi 502 mỗi lần triển khai về 0.