Inżynieria

Inżynieria

Jak budujemy i utrzymujemy Mythex – w tym co się zepsuło i jak to naprawiliśmy.

• Nieudana ponowna publikacja nigdy nie usuwa działającego backendu — Nieudana ponowna publikacja mogła usunąć żywe API aplikacji albo zostawić zepsutą wersję. Trzy poprawki w tym, jak Mythex cofa błędną publikację.
• Alerty, które wysyłają się raz, a nie raz na serwer — Alert wysyłany raz dziennie dotarł do nas pięć razy w jedno popołudnie. Dlaczego deduplikacja w pamięci zawodzi przy dwóch serwerach i jak wspólny stan to naprawił.
• Przechodzimy na większe przestrzenie robocze bez czekania — Ćwierć przestrzeni roboczych utknęła na 1 GB po przejściu na 2 GB. Pierwsza poprawka kazała jednej osobie czekać siedem minut. Co zmieniliśmy i dlaczego.
• Rozliczanie baz danych według tego, z czego faktycznie korzystają — Kiedyś szacowaliśmy koszt bazy każdej aplikacji i szacunek był błędny w obie strony. Teraz bazy są rozliczane według zmierzonego zużycia.
• Wykrywanie aplikacji, które padają tuż po publikacji — Trzy publikacje przeszły kontrolę stanu, choć ich API padało sekundy po każdym uruchomieniu. Przyczyną było liczenie awarii w liście ograniczonej do pięciu wpisów.
• Jak utrzymać tury agenta z dużą liczbą obrazów w granicach pamięci — Tura agenta, która przeglądała skany katalogów, wyczerpała pamięć przy 952 MB. Trzy osobne przyczyny, każda trzymała obrazy zbyt długo, i jak je naprawiliśmy.
• Jak utrzymać długie tury agenta w oknie kontekstu — Podagenci mogli rosnąć, aż model odrzuci żądanie, albo źle liczyć tokeny. Trzy poprawki, dzięki którym długa praca agenta się kończy.
• Jak utrzymać czat przy życiu, gdy telefon zasypia — Telefony zasypiają i tracą sieć w trakcie budowania. Dwa błędy psuły czat Mythex: zacinał się na „Łączenie…” albo pokazywał połowę odpowiedzi.
• Jak jeden ciężki czat mógł położyć nasze API — 28 września oba serwery API wyczerpały pamięć naraz. Prawdziwa przyczyna: historia czatu ładowana po liczbie wiadomości, nie po rozmiarze.
• Naciśnięcie Publikuj dwa razy publikuje tylko raz — Trzy żądania publikacji jednej aplikacji dotarły w odstępie 84 ms i każde uruchomiło pełne wdrożenie. Teraz tylko jedno się wykonuje.
• Lekcje SEO z naprawiania własnej strony — Zduplikowane znaczniki FAQ, zła miniatura w Google, strony szablonów, których nikt nie klikał, i ścieżka, którą nasz edge odrzucał: co znaleźliśmy na mythex.ai i naprawiliśmy.
• Strony statyczne działają, podczas gdy są publikowane ponownie — Ponowna publikacja strony statycznej kiedyś opróżniała ją przed wysłaniem builda. Teraz stara strona działa, aż nowa będzie na miejscu, a zmiany widać w kilka sekund.
• Crash z brakiem pamięci ukryty w etykiecie postępu — Nasz agent AI zabrakło pamięci podczas zapisu jednego dużego pliku. Przyczyną nie był model ani równoległe podagenty — była nią etykieta statusu, wysłana ponownie 41 000 razy.
• Brakujący plik wymiany, który zamroził nasze serwery — Serwer produkcyjny przestał odpowiadać, ale nie padł: bez zabicia przez brak pamięci, tylko z trashingiem pamięci podręcznej na maszynie bez wymiany. Co zmieniliśmy.
• Budzenie baz danych bez martwych połączeń — Opublikowana aplikacja budząca się ze snu trzymała pierwsze żądanie 10–12 sekund na połączeniach do bazy, które umarły podczas snu. Jak skróciliśmy to do 2,3 sekundy.
• Ograniczaliśmy sami nasze własne usługi — Limit żądań na adres w naszym API traktował nasze własne usługi jak jednego zajętego człowieka, aż na produkcji zaczęły dostawać 429. Jak to znaleźliśmy i naprawiliśmy.
• Dlaczego przenieśliśmy serwery Mythex na ARM — Gdy ciężka praca przeszła do sandboksów na projekt, nasze serwery zużywały jedną trzecią pamięci. Mniejsze instancje ARM obniżyły koszty o około 30%. Jak to zrobiliśmy.
• Jak doprowadziliśmy wdrożenia do zera błędów 502 — Watchdog ścigający się z wdrożeniami i load balancer, który zauważał za późno: jak znaleźliśmy oba problemy, naprawiliśmy je i zeszliśmy z 10 błędów 502 do zera.