Po wdrożeniu: monitoring, poprawki i utrzymanie strony lub aplikacji

Strona, która przeszła wszystkie testy na środowisku testowym, w pierwszym tygodniu na produkcji i tak pokaże rzeczy, których nikt wcześniej nie widział. Nie dlatego, że testy były złe, tylko dlatego, że żaden test nie zastąpi prawdziwych użytkowników, prawdziwych skrzynek pocztowych i prawdziwego ruchu z wyszukiwarki. Pytanie nie brzmi, czy coś wyjdzie po starcie, tylko kto to zauważy pierwszy: Ty, Twój klient czy system monitoringu.

Ten tekst opisuje okres po wdrożeniu od strony praktycznej: co obserwować, jak ustawić alerty, żeby ktoś je czytał, jak zgłaszać błędy, żeby poprawka nie zajęła trzech dni, kiedy wdrażać zmiany i jak zabezpieczyć dane. Na końcu porównujemy opcje na czas po zakończeniu bezpłatnego monitoringu, w tym te, w których nasz plan utrzymaniowy nie jest dobrym wyborem.

Co wychodzi dopiero na produkcji

Pierwsza grupa to prawdziwe dane. Na środowisku testowym formularz wypełnia się danymi typu "Jan Kowalski, ul. Testowa 1". Prawdziwi użytkownicy mają nazwiska z apostrofem, adresy dłuższe niż przewidziane pole, numery telefonów z prefiksem kraju i spacjami, a w polu wiadomości wklejają tekst z edytora z niewidocznymi znakami formatowania. Walidacja, która na testach przepuszczała wszystko, co trzeba, zaczyna odrzucać poprawne dane albo przepuszczać takie, które psują eksport do systemu księgowego.

Druga grupa to poczta. Powiadomienia z formularza kontaktowego wysyłane z serwera bez poprawnie ustawionych rekordów SPF, DKIM i DMARC dla domeny trafiają do spamu albo są odrzucane przez serwery odbiorcy. Na testach wiadomości przychodziły, bo testowy adres był na tej samej domenie albo w skrzynce, która nie filtruje. Po starcie klient przez tydzień myśli, że nikt nie pisze, a wiadomości leżą w folderze spamu handlowca.

Trzecia grupa to ustawienia, które zostały ze środowiska testowego. Znacznik noindex albo Disallow: / w pliku robots.txt, dodane po to, żeby wyszukiwarka nie zaindeksowała stagingu, przeniesione na produkcję blokują indeksowanie nowej strony. Klucze testowe bramki płatności przyjmują zamówienia, za które nikt nie płaci. Adres API wskazujący na testowy backend działa, dopóki ktoś nie wyczyści testowej bazy.

Czwarta grupa pojawia się przy wymianie starej strony na nową. Stare adresy podstron są zaindeksowane w wyszukiwarce, podlinkowane z innych stron i zapisane w zakładkach. Jeśli nowa strona ma inną strukturę adresów, a nikt nie przygotował przekierowań 301 ze starych adresów na nowe, ruch z wyszukiwarki trafia na stronę błędu 404. Raport stron w Google Search Console pokazuje takie adresy jako błędy 404, gdy robot na nie trafi, i to jedno z pierwszych miejsc, które warto sprawdzać po starcie.

Co obejmuje monitoring w pierwszych 90 dniach

Bezpłatny monitoring po wdrożeniu trwa u nas najczęściej 90 dni. Jego podstawą jest dostępność i czas odpowiedzi. Oba sygnały najlepiej sprawdzać z zewnątrz, bo taki test ma przewagę nad monitoringiem na samym serwerze: serwer, który stracił połączenie z siecią, nie wyśle informacji o tym, że stracił połączenie. Test z innej lokalizacji widzi to samo, co widzi użytkownik.

Dostępność i czas odpowiedzi to jednak nie wszystko, co może się zepsuć bez żadnej zmiany w kodzie. Poniższa tabela zbiera sygnały, które warto obserwować w typowej stronie lub aplikacji, z tym, jak je sprawdzać, i progiem, przy którym powinien odezwać się alert. Które z nich mają sens w konkretnym projekcie, zależy od tego, co projekt robi, więc zakres najlepiej mieć spisany, a nie domyślny.

Dwa wiersze tej tabeli są szczególnie podstępne. Zadanie cykliczne, które przestało się uruchamiać, nie generuje żadnego błędu: po prostu nic się nie dzieje. Nie wysyłają się przypomnienia, nie generują się faktury, nie czyszczą się stare pliki tymczasowe. Dlatego monitoruje się je odwrotnie niż resztę, czyli alarmem na brak sygnału, a nie na błąd.

Drugi podstępny wiersz to kopie zapasowe. Zadanie kopii potrafi kończyć się sukcesem i tworzyć pusty plik, bo na przykład zmieniło się hasło do bazy, a skrypt nie sprawdza kodu wyjścia narzędzia do zrzutu. Rozmiar pliku, który nagle spada z kilkuset megabajtów do kilku kilobajtów, jest prostym i skutecznym sygnałem, że coś jest nie tak.

Alert, który ktoś przeczyta

Monitoring potrafi przestać działać bez żadnej awarii technicznej. Alerty przychodzą tak często i tak często okazują się fałszywe, że ludzie przestają je czytać, a wtedy prawdziwy alert ginie wśród pozostałych. Dobrze ustawiony monitoring odzywa się rzadko i za każdym razem z powodem, który wymaga reakcji.

Pierwsze narzędzie przeciw fałszywym alarmom to warunek czasu trwania. Pojedyncze nieudane zapytanie może wynikać z chwilowego problemu w sieci między punktem testowym a serwerem. Alert powinien odpalić się dopiero wtedy, gdy problem utrzymuje się przez kilka minut, a przy dostępności najlepiej gdy potwierdzają go testy z różnych lokalizacji. Poniżej przykład reguł w Prometheusie z eksporterem blackbox, który wykonuje zapytania HTTP i odczytuje certyfikaty:

Pole for to właśnie warunek czasu trwania: reguła musi być spełniona nieprzerwanie przez podany czas, zanim alert przejdzie ze stanu oczekującego do aktywnego. Etykieta severity pozwala kierować alerty różnymi drogami: krytyczne do kanału z powiadomieniem na telefon, ostrzeżenia do kanału, który ktoś przegląda raz dziennie. Adnotacja action nie jest wymagana przez Prometheusa, ale jest najważniejszą linijką w regule, bo mówi osobie obudzonej powiadomieniem, od czego zacząć.

Drugie narzędzie to zasada, że każdy alert ma odbiorcę i akcję. Jeśli po odpaleniu reguły nikt nie wie, co zrobić, albo jedyną reakcją jest "sprawdzę później", reguła jest do usunięcia albo do zmiany na zwykły wykres. Metryki, które warto oglądać, ale które nie wymagają natychmiastowej reakcji, lepiej trzymać na dashboardzie, na przykład w Grafanie, niż w kanale alertów.

Trzecie to przegląd po każdym fałszywym alarmie. Alert, który odpalił się bez powodu, to informacja, że próg jest źle ustawiony. Poprawienie go od razu kosztuje kilka minut, a niepoprawianie kosztuje zaufanie do całego systemu.

Zapas 15% czasu projektu na poprawki

W cenę każdego naszego projektu wliczony jest zapas na poprawki równy 15% czasu projektu. Przy projekcie zaplanowanym na 100 godzin pracy to 15 godzin, przy projekcie na 400 godzin to 60 godzin. Zapas liczony od czasu projektu, a nie jako stała liczba dni, rośnie razem z projektem: panel z kilkunastoma widokami ma więcej miejsc, w których prawdziwe użycie pokaże potrzebę poprawki, niż jednostronicowy landing.

Granica między poprawką a nową funkcją to miejsce, w którym po wdrożeniu najłatwiej o nieporozumienie, więc warto ją postawić jasno, zanim pojawi się pierwsze zgłoszenie. Poprawka to zmiana, która doprowadza projekt do stanu opisanego w ustaleniach albo usuwa problem, który wyszedł przy prawdziwym użyciu. Nowa funkcja to coś, czego w ustaleniach nie było.

Druga kolumna nie oznacza, że takie zmiany są źle widziane. Po kilku tygodniach używania nowej strony albo panelu naturalnie pojawiają się pomysły na rzeczy, których nikt nie przewidział na etapie planowania. Takie zmiany wycenia się osobno, tak jak każdy inny zakres, żeby zapas na poprawki został na to, do czego jest przeznaczony.

Zmiany z trzeciego wiersza pierwszej kolumny dobrze pokazują, po co ten zapas jest. Formularz, który wyglądał logicznie na makiecie, w codziennym użyciu okazuje się mieć pola w niewygodnej kolejności, a komunikat błędu zrozumiały dla programisty nic nie mówi pracownikowi recepcji. Takich rzeczy nie da się wyłapać na testach, bo wychodzą dopiero po setnym wypełnieniu formularza przez kogoś, kto robi to zawodowo.

Jak zgłosić błąd, żeby poprawka zajęła minuty, a nie dni

Zgłoszenie "formularz nie działa" uruchamia serię pytań: który formularz, na jakim urządzeniu, co dokładnie się stało, kiedy. Każde pytanie i odpowiedź to kolejna wymiana wiadomości, a każda wymiana to godziny zwłoki. Zgłoszenie, które od razu zawiera odpowiedzi, pozwala zacząć od szukania przyczyny, a nie od ustalania, czego szukać.

Najcenniejsze pole to godzina. Serwer zapisuje w logach każde zapytanie z dokładnym czasem, więc "około 14:20" pozwala w kilka minut znaleźć konkretny błąd w logach zamiast przeglądać cały dzień. Pole "czy się powtarza" rozdziela błędy, które da się odtworzyć i poprawić od razu, od jednorazowych problemów, na przykład z połączeniem użytkownika.

W przykładzie powyżej jeden szczegół prawie wskazuje przyczynę: bez załącznika formularz działa, z plikiem 4 MB nie. To może być limit rozmiaru zapytania na serwerze, limit czasu przesyłania albo walidacja typu pliku. Bez tej informacji szukanie zaczęłoby się od sprawdzania wysyłki poczty, która w ogóle nie jest problemem.

Zrzut ekranu jest dobry, a krótkie nagranie ekranu jest lepsze, bo pokazuje kolejność kroków, której użytkownik często nie pamięta. Oba systemy telefonów mają wbudowane nagrywanie ekranu, więc nie trzeba niczego instalować.

Wdrożenie poprawki: w środku dnia i małymi krokami

Wdrażamy regularnie i raczej w środku dnia. Powód jest prosty: jeśli po wdrożeniu coś pójdzie nie tak, w środku dnia wszyscy są przy komputerach, łącznie z osobami po stronie klienta, które mogą sprawdzić zmianę na żywo. Wdrożenie w piątek wieczorem oznacza, że problem odkryty w sobotę rano czeka na osobę, która akurat odbierze telefon.

Poprawka najpierw trafia na środowisko testowe, do którego klient ma dostęp. Tam można ją sprawdzić na tych samych danych, na których wystąpił błąd, zanim zmiana dotknie produkcji. Przy poprawkach zgłoszonych przez klienta to on najlepiej wie, czy problem zniknął, więc jego potwierdzenie na stagingu jest lepszym testem niż jakikolwiek automat.

Małe wdrożenia są bezpieczniejsze od dużych z prostego powodu: gdy po wdrożeniu jednej zmiany coś się psuje, wiadomo, która zmiana to zrobiła. Gdy wdraża się dwadzieścia zmian zebranych przez miesiąc, szukanie przyczyny zaczyna się od ustalenia, która z dwudziestu. Małe wdrożenie łatwiej też wycofać, bo przywrócenie poprzedniej wersji nie cofa przy okazji dziewiętnastu innych poprawek.

Osobnej uwagi wymagają zmiany w bazie danych. Wycofanie kodu jest szybkie, wycofanie migracji, która usunęła kolumnę, bywa niemożliwe bez kopii zapasowej. Dlatego zmiany w strukturze bazy robi się w dwóch krokach: najpierw dodaje się nową kolumnę i kod, który obsługuje obie wersje, a starą usuwa się dopiero w kolejnym wdrożeniu, gdy nowa wersja działa stabilnie. Taki układ pozwala wycofać kod bez dotykania danych.

Aktualizacje zależności i poprawki bezpieczeństwa

Strona albo aplikacja, w której nikt nie zmienia kodu, i tak się starzeje, bo starzeją się jej zależności. Biblioteki dostają poprawki bezpieczeństwa, wersje środowisk uruchomieniowych tracą wsparcie, a system operacyjny serwera wymaga aktualizacji. Projekt pozostawiony bez aktualizacji przez dwa lata wymaga potem skoku o kilka wersji naraz, a to jest znacznie droższe niż regularne małe aktualizacje, bo zmiany z kilku wersji trzeba przejrzeć i przetestować jednocześnie.

Aktualizacje mają różną wagę, zgodnie z numeracją wersji. Wersja poprawkowa, trzecia liczba w numerze, powinna tylko naprawiać błędy. Wersja pomniejsza, druga liczba, dodaje funkcje bez łamania zgodności. Wersja główna, pierwsza liczba, może zmieniać zachowanie i wymaga przejrzenia listy zmian. Nie każda biblioteka trzyma się tych zasad, dlatego nawet aktualizacja poprawkowa powinna przejść przez testy przed wdrożeniem.

npm audit --omit=dev pomija zależności używane tylko przy budowaniu i testach, które nie trafiają na produkcję, co oddziela realne zagrożenia od szumu. composer outdated --direct pokazuje tylko biblioteki dodane bezpośrednio do projektu, a nie całe drzewo zależności. Narzędzia takie jak Dependabot albo Renovate otwierają pull requesty z aktualizacjami automatycznie, a automatyczne testy sprawdzają je, zanim ktoś kliknie scalenie.

Środowisko uruchomieniowe ma własny kalendarz. Node.js publikuje harmonogram wsparcia dla każdej wersji LTS, a PHP dla każdej wersji głównej i pomniejszej. Warto znać datę końca wsparcia wersji, na której działa projekt, i zaplanować przejście z wyprzedzeniem, bo po tej dacie luki bezpieczeństwa przestają być łatane.

Kopie zapasowe, które da się odtworzyć

Kopia zapasowa ma sens tylko wtedy, gdy da się z niej odtworzyć działający system. Brzmi to oczywiście, ale kopia, której nikt nigdy nie próbował odtworzyć, może być niekompletna, uszkodzona albo zapisana w formacie, do którego brakuje narzędzia w odpowiedniej wersji. Wychodzi to w najgorszym możliwym momencie: podczas awarii.

Pełna kopia strony albo aplikacji to trzy rzeczy, a nie jedna. Baza danych, pliki wgrywane przez użytkowników, takie jak zdjęcia produktów i załączniki, oraz konfiguracja pozwalająca uruchomić system od nowa. Sam kod jest w repozytorium, więc nie wymaga osobnej kopii, ale sekrety i zmienne środowiskowe w repozytorium być nie powinny, więc muszą mieć własne, bezpieczne miejsce.

Zasada 3-2-1 mówi: trzy kopie danych, na dwóch różnych nośnikach, w tym jedna w innej lokalizacji. Migawka serwera wykonywana przez dostawcę hostingu jest wygodna, ale leży w tej samej infrastrukturze co serwer. Jeśli problemem jest konto u dostawcy albo awaria centrum danych, migawka jest niedostępna razem z serwerem.

Test odtworzenia nie musi być skomplikowany. Dla bazy PostgreSQL wystarczy odtworzyć zrzut do tymczasowej bazy i sprawdzić, czy zawiera dane:

Przy kopiach warto ustalić dwie liczby. Pierwsza to maksymalna ilość danych, jaką firma może stracić: jeśli kopia robi się raz na dobę, awaria tuż przed kolejną kopią oznacza utratę prawie całego dnia zamówień. Druga to czas, w jakim system musi wrócić do działania. Dla sklepu, który sprzedaje głównie wieczorem, obie liczby wyglądają inaczej niż dla wewnętrznego panelu używanego w godzinach pracy biura.

Po 90 dniach: plan utrzymaniowy, własny zespół albo zlecenia doraźne

Po zakończeniu bezpłatnego monitoringu są trzy sensowne drogi i żadna nie jest najlepsza dla każdego. Wybór zależy od tego, jak często projekt się zmienia, czy firma ma własnych programistów i jak kosztowna jest dla niej godzina niedostępności.

Nasze plany utrzymaniowe wyceniamy indywidualnie, bo utrzymanie landingu i utrzymanie sklepu z integracją z magazynem to zupełnie inne zakresy pracy. Jeśli masz w firmie programistę, który zna technologię projektu, plan utrzymaniowy u nas najpewniej nie jest potrzebny: lepiej zainwestować w porządne przekazanie projektu i dokumentację, a nas zostawić na większe zmiany.

Zlecenia doraźne mają sens dla prostej strony firmowej bez sklepu i bez logowania, pod warunkiem, że podstawowe rzeczy dzieją się same. Certyfikat odnawia się automatycznie, domena ma włączone automatyczne odnowienie, a darmowe narzędzie do monitoringu dostępności wysyła powiadomienie na adres osoby w firmie. To minimum, które kosztuje godzinę konfiguracji i chroni przed najgłupszymi awariami.

Dla projektów, które zarabiają albo obsługują klientów, brak kogokolwiek, kto obserwuje system, jest ryzykiem, które łatwo policzyć: wystarczy oszacować, ile kosztuje dzień, w którym sklep nie przyjmuje zamówień albo panel nie pozwala klientom się zalogować.

Przejęcie projektu przez inny zespół: co musi być w dokumentacji

Klient dostaje od nas pełne prawa do kodu, dostęp do repozytorium i dokumentację pozwalającą przejąć projekt. Prawa do kodu nic nie znaczą, jeśli nowy zespół potrzebuje tygodnia, żeby uruchomić projekt na swoim komputerze. Test dokumentacji jest prosty: czy programista, który nigdy nie widział projektu, jest w stanie uruchomić go lokalnie i wdrożyć zmianę, nie zadając autorom ani jednego pytania.

Dokumentacja do przejęcia powinna zawierać co najmniej:

• Uruchomienie lokalne. Wymagane wersje narzędzi, polecenia instalacji, sposób wypełnienia bazy danymi testowymi.
• Zmienne środowiskowe. Lista nazw z opisem, do czego służy każda, bez wartości. Wartości produkcyjne przekazuje się osobnym, bezpiecznym kanałem.
• Procedura wdrożenia. Krok po kroku, łącznie z tym, jak wycofać wersję, gdy coś pójdzie nie tak.
• Architektura w skrócie. Z jakich części składa się system, jak się ze sobą komunikują i gdzie działają.
• Usługi zewnętrzne. Bramka płatności, wysyłka poczty, mapy, API partnerów, z informacją, na czyje konto są zarejestrowane.
• Domena i DNS. Gdzie jest zarejestrowana domena, gdzie są zarządzane rekordy DNS, które rekordy są potrzebne do poczty.
• Kopie zapasowe. Gdzie są, jak często się robią i jak je odtworzyć.
• Znane problemy. Rzeczy, które działają, ale wymagają uwagi, i decyzje techniczne, które warto znać przed zmianą kodu.

Punkt o usługach zewnętrznych jest ważniejszy, niż wygląda. Konto bramki płatności, domena albo konto w usłudze wysyłki poczty zarejestrowane na wykonawcę oznaczają, że przejęcie projektu wymaga jego współpracy, niezależnie od tego, co mówi umowa o prawach do kodu. Serwer, domena i usługi zewnętrzne powinny być zarejestrowane na klienta od początku, a wykonawca powinien mieć do nich dostęp, a nie odwrotnie.

Ostatni element to rozmowa. Nawet najlepsza dokumentacja nie przekaże wszystkiego, na przykład tego, dlaczego jedna z integracji jest napisana w nietypowy sposób. Godzina rozmowy, na której autorzy przechodzą przez projekt z nowym zespołem, oszczędza nowemu zespołowi dni zgadywania.

Koszty, które zostają po wdrożeniu niezależnie od wykonawcy

Część kosztów utrzymania nie ma nic wspólnego z tym, kto zbudował projekt, i istnieje nawet wtedy, gdy nikt nie zmienia w nim ani linijki. Warto mieć je spisane przed startem, żeby żaden nie zaskoczył w trakcie roku.

• Domena. Odnowienie co rok albo na kilka lat z góry. Wygaśnięcie domeny wyłącza jednocześnie stronę i pocztę.
• Serwer lub hosting. Opłata miesięczna albo roczna, zależna od potrzebnych zasobów.
• Poczta firmowa. Jeśli skrzynki nie są częścią hostingu, osobna opłata za każdego użytkownika.
• Płatne API. Mapy, wysyłka SMS, wysyłka poczty transakcyjnej, rozpoznawanie adresów. Wiele z nich ma darmowy limit, który przy rosnącym ruchu przestaje wystarczać.
• Prowizje operatorów płatności. Naliczane od każdej transakcji, a nie jako stała opłata.
• Licencje. Płatne wtyczki, fonty i zdjęcia ze stocków mają często licencję roczną albo ograniczoną do określonego zastosowania.

Przy każdej z tych pozycji warto zapisać trzy rzeczy: na czyje konto jest zarejestrowana, jaką kartą albo z jakiego rachunku jest opłacana i kiedy przypada kolejne odnowienie. Łatwo przeoczyć awarię, której przyczyną nie jest błąd w kodzie, tylko karta firmowa, która wygasła, przez co odnowienie domeny albo serwera nie przeszło, a powiadomienia trafiały na skrzynkę osoby, która już nie pracuje w firmie. Jeden wspólny kalendarz odnowień, widoczny dla więcej niż jednej osoby, zamyka tę lukę.

Certyfikat TLS nie musi być kosztem. Let's Encrypt wydaje darmowe, krótko ważne certyfikaty, które trzeba odnawiać co kilka tygodni, a serwery takie jak Caddy albo narzędzie certbot odnawiają je automatycznie. Właśnie dlatego data wygaśnięcia certyfikatu jest w tabeli monitoringu: automatyczne odnowienie działa, dopóki nie przestanie, na przykład po zmianie konfiguracji DNS albo zapory.

Jeśli planujesz stronę albo aplikację i chcesz od początku wiedzieć, jak będzie wyglądał okres po wdrożeniu, cały przebieg projektu opisaliśmy na stronie jak pracujemy. Zakres i cenę startową stron firmowych, od 1 199 zł, znajdziesz w ofercie stron internetowych. Jeśli masz już projekt po wdrożeniu i szukasz kogoś do jego utrzymania albo przejęcia, napisz do nas. Odpowiadamy w godzinę.