Lista kontrolna gotowości przed wejściem na produkcję z aplikacją pisaną przez AI

Aplikacja, która dobrze wygląda na demie, i aplikacja, która przeżyje wejście na produkcję, to dwie różne rzeczy, a w przerwie między nimi zatrzymuje się większość projektów pisanych z AI. Kod działa na twojej maszynie, na czystych danych, dla jednego użytkownika: ciebie. Produkcja to nic z tych trzech. To jest lista, którą przechodzimy, ułożona według tego, co zwykle zawodzi najpierw. Nie jest to nic wymyślnego. Rzecz w tym, że szybkie buildy z AI zwykle pomijają to wszystko.

Sekrety i konfiguracja

• Żadnych sekretów w repozytorium ani jego historii. Klucz zacommitowany raz i „usunięty” w kolejnym commicie nadal jest w historii i nadal wyciekł. Wygeneruj nowy i przenieś go do menedżera sekretów albo zmiennych środowiskowych.
• Konfiguracja jest per środowisko, nie wpisana na sztywno. Ten sam build działa na staging i na produkcji przez zmianę konfiguracji, nie kodu.

Obsługa błędów i logowanie

• Aplikacja jest odporna na błędne lub złośliwe dane wejściowe. Każda składowa, która może zawieźć (sieć, baza, usługa zewnętrzna), jest obsłużona, a użytkownik widzi sensowny komunikat zamiast wewnętrznych szczegółów błędów. Złośliwe i błędne dane wejściowe są odrzucane.
• Logi są ustrukturyzowane i przeszukiwalne, z kontekstem wystarczającym, żeby później odnaleźć błądzące żądanie. Log, którego nie da się odpytać, to log, którego nie masz.

Uwierzytelnianie i autoryzacja

• Dostęp jest wymuszany na API, nie tylko schowany w interfejsie użytkownika. Przycisk, którego nie widać, to nie uprawnienie; endpoint, który sprawdza z kim rozmawia, owszem.
• Sesje i tokeny wygasają i da się je unieważnić.

Testy i CI

• Pipeline CI działa przy każdym pushu i blokuje merge, gdy któryś z mechanizmów ochronnych dostrzeże niepożądane zmiany.
• Testy end-to-end pokrywają te kluczowe ścieżki, których nie mogą Cię zawieść (rejestracja, płatność, najważniejsze procesy realizowane przez twoją aplikację). Nie potrzebujesz pełnego pokrycia, żeby spać spokojnie. Potrzebujesz automatycznie przetestowanych ścieżek krytycznych.

Dane

• Kopie zapasowe robią się automatycznie, a odtworzenie jest zweryfikowane. Kopia, której nigdy nie odtworzyłeś, to nie kopia, tylko nadzieja.
• Zmiany schematu to migracje, wersjonowane i odwracalne, a nie ręczne edycje na żywej bazie.

Obserwowalność

• Błędy są zbierane tam, gdzie naprawdę zaglądasz, z alertami na te, które mają znaczenie.
• Dostępność i kilka kluczowych metryk są monitorowane, żebyś o awarii dowiadywał się z dashboardu, a nie od klienta.

Wdrożenie

• Aplikacja stoi pod realnym adresem, a proces sam się restartuje, kiedy padnie. localhost:3000 i terminal, który musisz trzymać otwarty, to nie wdrożenie.
• Wdrożenie to jeden powtarzalny krok, i da się je cofnąć. Ręczne, wieloetapowe wydanie to ręczny, wieloetapowy sposób na wywrócenie produkcji.

Skalowalność, kiedy faktycznie jej potrzebujesz

• Ścieżka krytyczna musi być przetestowana pod względem wydajności na wielokrotności dzisiejszego ruchu, żebyś wiedział, gdzie się ugina, zanim odkryją to użytkownicy.
• Stan żyje w bazie albo cache, nie w procesie, żebyś mógł uruchomić więcej niż jedną instancję za load balancerem.

Jak z tego korzystać

Nie próbuj zrobić wszystkiego naraz i nie rób tego w losowej kolejności. Najpierw napraw punkty o bezpieczeństwie i danych, bo to one zamieniają zły dzień w utraconą firmę. Potem wdrożenie i testy, żebyś mógł zmieniać rzeczy bez strachu. Obserwowalność i skala przychodzą, gdy reszta już stoi pewnie.

Jeśli wolisz nie sprawdzać własnej pracy, od tego jest Przegląd: spojrzenie z zewnątrz na to, jak twoja aplikacja wypada wobec tej listy, co solidne, co kruche i co ruszyć najpierw, z wyceną pracy, jeśli chcesz ją zlecić.