Od ręcznej kontroli do własnego centrum operacyjnego. Jak zbudowałem DIGIKROM Hub dla ponad 50 stron

Przy kilku stronach internetowych wiele rzeczy można jeszcze kontrolować ręcznie. Wchodzę do WordPressa, sprawdzam aktualizacje, zaglądam do WooCommerce, patrzę na SSL, cron, kolejki i ewentualne błędy. Jeżeli coś się dzieje, reaguję.

Problem zaczyna się wtedy, kiedy nie mówimy już o kilku stronach.

Przy kilkudziesięciu aktywnie obsługiwanych serwisach taki model przestaje się skalować. Nie dlatego, że samo kliknięcie w kokpit WordPressa jest trudne. Problemem jest liczba miejsc, które trzeba odwiedzić, liczba informacji, które trzeba zapamiętać i przede wszystkim fakt, że potencjalny problem może pojawić się na stronie, do której akurat danego dnia nie zajrzę.

W pewnym momencie stało się dla mnie oczywiste, że jeżeli DIGIKROM ma rozwijać opiekę techniczną nad coraz większą liczbą stron WordPress i WooCommerce, potrzebuję własnego centrum operacyjnego.

Nie kolejnej tabelki. Nie systemu, który tylko mówi, czy domena odpowiada kodem 200. Potrzebowałem miejsca, które pokaże mi w jednym widoku, co dzieje się z całym technicznym zapleczem obsługiwanych serwisów.

Tak powstała kolejna warstwa DIGIKROM Hub.

Problem nie polegał na tym, czy strony działają

Samo sprawdzenie dostępności strony jest stosunkowo proste. Serwer odpowiada albo nie odpowiada. Certyfikat SSL jest ważny albo nie. Kod odpowiedzi HTTP jest prawidłowy albo wskazuje problem. Tylko że działający frontend nie oznacza jeszcze, że wszystko jest w porządku. Strona może odpowiadać kodem 200, a jednocześnie:

• mieć kilkanaście zaległych aktualizacji,
• pracować na starej wersji PHP,
• mieć problemy z WP-Cron,
• mieć zakleszczone zadania Action Scheduler,
• generować serię błędów w tle,
• mieć wygasający certyfikat,
• nie wykonywać części procesów WooCommerce,
• albo po prostu od dawna nie raportować swojego stanu.

Dlatego od początku rozdzieliłem dwa różne rodzaje kontroli. Pierwszy to monitoring zewnętrzny. Drugi to monitoring wewnętrzny.

Warstwa pierwsza: monitoring zewnętrzny

DIGIKROM Hub samodzielnie sprawdza strony z zewnątrz. Dzięki temu wiem, czy serwis odpowiada, jaki zwraca kod HTTP, ile trwa odpowiedź i jak wygląda stan certyfikatu SSL. To ważne, ponieważ taki monitoring działa niezależnie od samego WordPressa. Jeżeli WordPress całkowicie przestanie odpowiadać, wewnętrzna wtyczka również nie będzie miała możliwości wysłania raportu. Monitoring zewnętrzny nadal może wtedy wykryć awarię. Nie chciałem jednak reagować na każdy pojedynczy przypadkowy błąd jak na krytyczne zdarzenie. Internet nie jest idealny. Zdarzają się chwilowe timeouty, problemy DNS, restart PHP-FPM czy pojedyncze odpowiedzi serwera, które po kilkunastu sekundach wracają do normy. Dlatego system dostał mechanizm anti-flapping. Pojedynczy nieudany test nie musi jeszcze oznaczać awarii. Dopiero powtarzające się problemy zmieniają stan monitorowanej witryny na krytyczny. Analogicznie powrót do stanu OK również wymaga potwierdzenia. Dzięki temu monitoring ma informować, a nie generować hałas.

Warstwa druga: DIGIKROM Monitor Agent

Monitoring zewnętrzny wie, czy strona odpowiada. Nie wie natomiast, co dzieje się w środku WordPressa. Do tego powstał DIGIKROM Monitor Agent — lekka wtyczka instalowana na monitorowanych serwisach. Agent nie przesyła treści stron, danych klientów, treści zamówień ani haseł użytkowników. Jego zadaniem jest raportowanie informacji technicznych. Do DIGIKROM Hub trafiają między innymi dane o wersji WordPressa, PHP, WooCommerce, dostępnych aktualizacjach wtyczek i motywów, WP-Cron, Action Scheduler oraz podstawowej kondycji środowiska. Dzięki temu zamiast logować się kolejno do kilkudziesięciu WordPressów, mogę otworzyć jeden ekran.

Jeden ekran zamiast ponad 50 kokpitów WordPressa

To właśnie główny ekran Monitoringu jest dla mnie najważniejszą częścią całego systemu. Każda domena ma własny wiersz. Widzę stan HTTP, czas odpowiedzi, SSL, połączenie Agenta, środowisko, aktualizacje oraz podstawowe informacje o kolejce i procesach utrzymaniowych. Jeżeli wszystko jest dobrze — widzę zielony status. Jeżeli coś wymaga uwagi — system to zaznacza. Jeżeli strona faktycznie przestaje działać — problem jest widoczny od razu. Przy kilkudziesięciu stronach okazało się też, że nawet drobiazgi interfejsu zaczynają mieć znaczenie. Pierwsza wersja listy mogła zmieniać kolejność domen na podstawie bieżących danych. Przy kilku stronach nie ma to większego znaczenia. Przy ponad 50 oznacza, że za każdym razem trzeba szukać interesującej domeny. Dlatego lista została ustawiona na stałe alfabetycznie, a do panelu trafiła wyszukiwarka działająca w czasie rzeczywistym. To jedna z tych zmian, które technicznie są niewielkie, ale operacyjnie oszczędzają czas każdego dnia.

Agent nie jest monitorem dostępności

To była jedna z ważniejszych decyzji podczas projektowania systemu. Na początku łatwo byłoby założyć: brak kontaktu z Agentem = awaria strony. Tylko że to nie byłoby prawdą. Agent działa wewnątrz WordPressa i jego raportowanie jest zależne między innymi od WP-Cron oraz aktywności samego środowiska. Strona może działać całkowicie prawidłowo, ale Agent może przez pewien czas nie wysłać nowego raportu. Dlatego brak kontaktu Agenta nie jest traktowany jako rzeczywista awaria witryny. Źródłem prawdy dla dostępności pozostaje monitoring zewnętrzny HTTP/HTTPS. Agent mówi natomiast: „od pewnego czasu nie mam świeżych danych technicznych z tej instalacji”. To subtelna różnica, ale bardzo ważna. Monitoring powinien opisywać rzeczywistość, a nie tworzyć alarmy na podstawie zbyt prostych założeń.

Action Scheduler: liczba błędów bez kontekstu niewiele mówi

Podczas rozwijania systemu szczególnie ciekawym elementem okazał się Action Scheduler. WooCommerce i wiele innych wtyczek wykorzystuje go do wykonywania zadań w tle. W bazie mogą znajdować się tysiące zakończonych akcji, zadania oczekujące oraz błędy historyczne. Samo pokazanie: „failed: 1116” wygląda dramatycznie. Ale po analizie może się okazać, że ponad tysiąc nieudanych działań pochodziło z dawno odłączonej integracji, a bieżąca kolejka działa prawidłowo. Dlatego sam licznik błędów nie może być traktowany bez kontekstu. System zaczął rozróżniać bieżącą kondycję kolejki od historycznych wpisów. Podobnie z oczekującymi zadaniami. Kilka czy kilkadziesiąt pending może być całkowicie normalne, jeżeli są zaplanowane na przyszłość. Problemem jest dopiero zadanie, które powinno zostać wykonane dawno temu i nadal pozostaje w kolejce. To właśnie takich informacji chcę od monitoringu. Nie czerwonej liczby. Odpowiedzi na pytanie, czy trzeba reagować.

Aktualizacje bez odwiedzania każdej strony

Kolejnym problemem przy większej liczbie WordPressów jest mechanizm aktualizacji. WordPress przechowuje informacje o dostępnych aktualizacjach w transientach i wykonuje własne kontrole okresowo. W praktyce oznacza to, że jedna strona zobaczy nową wersję wtyczki od razu, druga po wejściu do ekranu aktualizacji, a jeszcze inna dopiero po kolejnym cyklu. Przy ponad 50 stronach ręczne otwieranie każdego WordPressa tylko po to, żeby wymusić ponowne sprawdzenie, nie ma sensu. Dlatego Hub dostał możliwość zdalnego wywołania sprawdzenia aktualizacji DIGIKROM Monitor Agent. Jedno kliknięcie w centralnym panelu powoduje, że konkretna instalacja sprawdza dostępność aktualnej wersji Agenta. Bez logowania do WordPressa. Bez przechodzenia przez kilkadziesiąt kokpitów.

One-Click Login bez magazynu haseł

Kiedy liczba stron rośnie, pojawia się jeszcze jeden banalny problem. Logowanie. Różne domeny, różne adresy logowania, różni użytkownicy. Mógłbym zbudować w Hubie magazyn loginów i haseł. Nie chciałem tego robić. Centralna baza ponad 50 haseł administracyjnych byłaby wygodna, ale tworzyłaby też bardzo atrakcyjny pojedynczy punkt ataku. Dlatego DIGIKROM Hub nie przechowuje haseł WordPress. Powstał One-Click Login. Po kliknięciu przycisku Hub generuje krótkotrwały, jednorazowy token dla konkretnej domeny i konkretnego Agenta. Token jest podpisany kryptograficznie i przekazywany przez HTTPS. Agent sprawdza jego podpis, czas ważności, identyfikator instalacji oraz to, czy nie został już wykorzystany. Dopiero wtedy tworzy lokalną sesję WordPress. W praktyce klikam: „Zaloguj” i kilka sekund później jestem w kokpicie konkretnej strony. Nie interesuje mnie nawet, czy standardowy adres logowania to /wp-admin/, /wp-login.php/ czy niestandardowy endpoint. Co równie ważne — strona otwiera się w nowej karcie. Hub pozostaje otwarty. To detal, który przy obsłudze jednej strony nie ma znaczenia. Przy pracy na kilkudziesięciu robi ogromną różnicę.

Monitoring stał się częścią opieki technicznej

W pewnym momencie pojawiło się kolejne pytanie. Skoro Agent działa u klienta, dlaczego jego ekran ma wyglądać jak zwykła techniczna tabela wtyczki WordPress? Dla mnie najważniejszy pozostaje centralny Hub. Ale klient również może wejść do ustawień Agenta. Dlatego ekran został całkowicie przebudowany. Powstał DIGIKROM Technical Care. Zamiast surowych identyfikatorów klient widzi profesjonalny ekran pokazujący stan połączenia, kondycję techniczną, poziom opieki, środowisko, monitoring zewnętrzny, ostatnią aktywność oraz zakres przesyłanych danych. Informacje stricte techniczne, takie jak Installation ID czy Agent ID, zostały schowane w sekcji zaawansowanej. Na górnym pasku administracyjnym WordPressa pojawił się również skrót: DIGIKROM Technical Care. Klient cały czas widzi więc subtelną informację, że strona znajduje się pod techniczną kontrolą. Dla mnie jest to szybki skrót do panelu. Dla klienta — sygnał, że opieka techniczna nie polega wyłącznie na reagowaniu wtedy, kiedy ktoś zgłosi problem.

Poziom opieki jako informacja, nie blokada funkcji

Do systemu trafiły również cztery poziomy: Brak aktywnej opieki. Opieka Podstawowa. Opieka Rozszerzona. Opieka PRO. To pole ustawiam ręcznie w centralnym Hubie. Celowo nie wpływa ono na działanie monitoringu. Nie chciałem tworzyć logiki w rodzaju: „PRO widzi SSL, Podstawowa już nie”. Monitoring techniczny może pozostawać aktywny niezależnie od przypisanego pakietu. Poziom opieki jest informacją organizacyjną. Dzięki temu w jednym miejscu wiem nie tylko, jaki jest stan strony, ale również jaki model obsługi jest do niej przypisany.

Bezpieczeństwo było częścią projektu od początku

Centralny system, który komunikuje się z kilkudziesięcioma WordPressami, musi być projektowany inaczej niż zwykła wtyczka. Komunikacja Agent–Hub odbywa się przez HTTPS. Żądania są podpisywane HMAC. One-Click Login wykorzystuje tokeny jednorazowe. Hasła administratorów WordPress nie są przechowywane w Hubie. Agent nie wysyła treści wpisów, stron, zamówień ani danych klientów. Raportuje informacje techniczne i zagregowane metryki potrzebne do utrzymania serwisu. Równie ważne było dla mnie to, żeby sam Agent był możliwie kompatybilny ze starszymi środowiskami. Jeżeli narzędzie ma informować, że dana strona używa starego PHP, nie może przestać działać tylko dlatego, że PHP jest stare. To dokładnie ten rodzaj paradoksu, którego chciałem uniknąć.

System powstawał podczas realnej pracy

DIGIKROM Hub nie został zaprojektowany jednego dnia na podstawie kompletnej specyfikacji. Rozwijał się podczas rzeczywistego używania. Agent zbyt szybko był oznaczany jako offline? Zmieniłem sposób interpretacji obecności. Lista stron zmieniała kolejność i utrudniała pracę? Dostała stałe sortowanie A–Z. Aktualizacje nie pojawiały się jednocześnie? Powstało zdalne sprawdzanie. Logowanie wymagało zbyt wielu kliknięć? Powstał One-Click Login. Panel Agenta wyglądał jak narzędzie developerskie? Powstał Technical Care. Właśnie taki sposób rozwoju najbardziej lubię. Nie dokładam funkcji dlatego, że dobrze wyglądają na liście możliwości. Dodaję je wtedy, kiedy podczas normalnej pracy pojawia się konkretny problem do rozwiązania.

Co zmieniło się w codziennej pracy?

Najważniejsza zmiana jest bardzo prosta. Nie zaczynam dnia od otwierania kilkudziesięciu kokpitów WordPress. Otwieram jeden panel. W kilka sekund widzę, które strony są OK, gdzie są aktualizacje, gdzie Agent nie raportuje, jak wygląda SSL, czy HTTP odpowiada prawidłowo i czy coś wymaga mojej uwagi. Jeżeli muszę wejść na konkretną stronę, klikam Zaloguj. Jeżeli chcę znaleźć domenę, wpisuję kilka znaków w wyszukiwarkę. Jeżeli chcę wymusić ponowne sprawdzenie aktualizacji Agenta, robię to z tego samego miejsca. To nie eliminuje pracy technicznej. Eliminuje natomiast ogromną część pracy organizacyjnej wokół niej.

Czy DIGIKROM Hub zastępuje administratora?

Nie. I nie taki jest jego cel. Monitoring nie naprawi źle napisanego kodu. Nie podejmie za mnie decyzji, czy dana aktualizacja jest bezpieczna. Nie przeanalizuje konfliktu dwóch nietypowych rozszerzeń tak jak człowiek, który zna projekt. Ale pozwala znacznie szybciej zauważyć, że coś wymaga uwagi. Daje kontekst. Porządkuje informacje. Zmniejsza liczbę miejsc, które trzeba sprawdzić. I przede wszystkim pozwala przejść z modelu: „klient zgłosił, że coś nie działa” do modelu: „wiem, co dzieje się z systemem, zanim zacznę szukać problemu”.

Od Huba do własnego centrum operacyjnego

DIGIKROM Hub powstał wcześniej jako system kontroli autorskich wdrożeń, ich wersji, aktualizacji i instalacji. Monitoring był naturalnym kolejnym etapem. Dziś Hub zaczyna pełnić funkcję znacznie szerszą. Jest miejscem, w którym spotykają się: monitoring zewnętrzny, dane techniczne z WordPressa, utrzymanie, aktualizacje, logowanie, poziomy opieki, incydenty i narzędzia serwisowe. Nie budowałem go dlatego, że potrzebowałem kolejnego panelu. Zbudowałem go dlatego, że przy ponad 50 stronach ręczna kontrola przestała być właściwym modelem pracy. Jeżeli mam odpowiadać za techniczną kondycję serwisów klientów, chcę mieć własne narzędzie, które pokazuje mi ich rzeczywisty stan. Nie wtedy, kiedy ktoś napisze wiadomość. Teraz.

Opieka techniczna to nie tylko aktualizacje

Aktualizowanie WordPressa jest tylko jednym z elementów utrzymania strony. Znacznie ważniejsze jest posiadanie informacji. Czy serwis działa? Czy SSL jest prawidłowy? Czy kolejki wykonują zadania? Czy środowisko jest aktualne? Czy występują błędy? Czy Agent nadal raportuje? Czy wymagana jest moja reakcja? Właśnie dlatego rozwijam własny system monitoringu razem z usługą opieki technicznej. Bo im więcej systemów trafia pod opiekę DIGIKROM, tym mniej chcę polegać na pamięci, przypadkowych kontrolach i zgłoszeniach klientów. Chcę mieć centrum operacyjne. I dokładnie tym staje się DIGIKROM Hub.

Zobacz, jak wygląda opieka techniczna WordPress i WooCommerce w DIGIKROM →