W życiu każdego serwisu internetowego przychodzi taki moment, że trzeba go zaktualizować lub wykonać inne zadania związane z utrzymaniem lub - jak nakazuje obyczaj nazywania wszystkiego po angielsku, aby brzmieć bardziej profesjonalnie - maintenance. W przypadku systemów IT tego typu operacje warto przeprowadzać w momencie, kiedy nie będą działy się niespodziewane operacje na danych, a więc mówiąc inaczej - użytkownicy nie będą mogli niczego zmieniać. W przypadku małych systemów można to zagwarantować bezpośrednią komunikacją, ale w przypadku dużych platform staje się to niemożliwe. Wówczas wprowadza się tzw. przerwę techniczną (ang. maintenance break), o której porozmawiamy sobie dzisiaj trochę więcej.

Nie ukrywam, że do napisania tekstu zainspirowała nas sytuacja, która miała miejsce w marcu 2024 r., a która wiązała się z czasową i lokalną niedostępnością Internetu u jednego operatora. Nie jest to nic nadzwyczajnego, gdyż takie przerwy w dostawie zdarzają się co jakiś czas w różnych firmach - ot, złośliwość rzeczy martwych, powodująca konieczność naprawienia awarii. Zawsze też warto sprawdzić połączenie w mieszkaniu lub firmie, aby upewnić się, że problem nie leży po stronie routera, który czasem wystarczy uruchomić ponownie. Jednak w tym przypadku moją uwagę zwróciło coś innego - o tym, iż awaria jest z winy operatora, dowiedziałem się z jego fanpage'a na Facebooku i to nie z postu, ale odpowiedzi na komentarz innego użytkownika. Przy okazji, tutaj trzeba przyznać, że zarządzający profilami takich firm na mediach społecznościowych mają trudne życie, gdyż wiele postów to wiadomości negatywne, pomstujące na niedziałające usługi. Ale, wracając do odpowiedzi, wynikało z niej, że... operator zaplanował prace modernizacyjne, o których wcześniej nie zakomunikował i podczas tej modernizacji wystąpiła "nieplanowana awaria". Wszystko napisane z uśmiechem i bez konkretów, co akurat łatwo zrozumieć, gdyż zwykle nie wiadomo, ile potrwa stawianie usługi na nogi. A tutaj zajęło to kilkanaście godzin, podczas których odbiorcy nie wiedzieli, jaki jest aktualny status, a oficjalnego komunikatu nie było lub był tak ukryty, że nie wszyscy do niego dotarli. Głównym źródłem informacji była strona Downdetector oraz artykuły w niektórych serwisach internetowych.

(Co ciekawe, podobna sytuacja miała miejsce kilka tygodni później, ale tym razem operator stanął na wysokości zadania i oficjalnie przyznał się na fanpage'u. Zresztą, awaria trwała trochę krócej.)

Wówczas zrozumiałem, że wśród twórców różnych usług związanych z Internetem (niezależnie od ich charakteru), informacja o zaplanowanej przerwie technicznej to nie tylko życzliwość w stosunku do użytkowników czy klientów, ale czasami wręcz obowiązek, który w dodatku może ukazać firmę jako podmiot odpowiedzialny i dbający o konsumenta. Być może nawet coś, co powinno być odgórnie regulowane w konkretnych przypadkach.

Czym jest przerwa techniczna?

Każda usługa działająca potencjalnie w trybie ciągłym (słynne 24/7), ale także w ściśle ustalonych ramach czasowych, potrzebuje przerw technicznych. Czasem wynika to z aktualizacji oprogramowania lub sprzętu, a niekiedy z zaplanowanych przeglądów konserwacyjnych w celu upewnienia się, że wszystko działa jak należy i wykrycia ewentualnych usterek, zanim spowodują realny problem. W tym przypadku mówimy o zaplanowanych momentach, w których wiadomo, iż przez jakiś czas usługa (lub jej określony zakres) nie będzie dostępna - nie dotyczy to awarii, które z oczywistych względów trudno przewidzieć.

Taka "oficjalna" przerwa techniczna powinna wiązać się z:

• zaplanowaniem jej w sposób najmniej dokuczliwy dla odbiorców,
• wcześniejszym poinformowaniem odbiorców o zakresie, dacie i godzinach (*),
• wyświetleniem odpowiedniego komunikatu na stronie,
• poinformowaniem, pod jakimi danymi kontaktowymi można zasięgnąć więcej informacji,
• ograniczeniem dostępu do odpowiedniego zakresu systemu dla konkretnych użytkowników lub adresów IP (*),
• podaniu informacji, gdy przerwa techniczna się przedłuża i jakie są tego powody.

Niektóre z tych punktów sa oczywiste, natomiast warto rozwinąć kilka z nich, szczególnie, te które zostały oznaczone gwiazdką, co ma oznaczać, iż są zależne od sytuacji.

O formie przeprowadzenia formy technicznej decydują przede wszystkim trzy aspekty:

• czas potrzebny na przeprowadzenie przerwy - im dłuższy, tym bardziej przerwa powinna być "sformalizowana",
• popularność i zasięg usługi - im większe, tym informacja powinna być lepiej widoczna oraz podana z wyprzedzeniem,
• zapisy w umowach - są usługi, które w kontraktach ze swoimi klientami mają zagwarantowane procedury w takich przypadkach.

Nie zawsze możliwe jest zapewnienie, iż przez cały czas trwania przerwy technicznej będzie dostępna plansza z informacją - w zależności od usługi oraz sytuacji, może pojawić się moment, w którym wgrywana jest właśnie nowa wersja, a nie ma już dostępnej starej. Oczywiście, nie powinno tak być - w idealnym świecie zaistniałby nieprzerwany ciąg: stara wersja -> plansza z przerwą techniczną -> nowa wersja. Jednak nie każdy serwis musi działać 24/7, a są też takie, gdzie operacyjność nie musi wynosić 100%.

Druga sprawa, to fakt, że podczas takiej przerwy do systemu (lub wydzielonego zakresu) dostęp mają tylko wyselekcjonowani użytkownicy. Zazwyczaj są to osoby o roli administratora lub maszyny posługujące się wyznaczonymi adresami IP. Z tym drugim jest czasami problem wynikający z faktu, że mało kto ma publiczny adres IP i te ustawienia trzeba edytować za każdym razem, ale lepsze to niż zablokowanie sobie dostępu całkowicie. Istnieją też praktyki, w wyniku których obok siebie znajdują się dwie wersje systemu i w odpowiednim momencie następuje podmiana plików lub domeny. To jednak wymaga dodatkowego ograniczenia widoczności danej domeny (także dla Google'a) lub wiary w to, że nikt tej testowej domeny "nie odgadnie" (co nie brzmi profesjonalnie). Lub po prostu bogatszej infrastruktury.

Co się dzieje podczas przerwy technicznej?

Odpowiedź na to pytanie jest prosta - zazwyczaj następuje wdrożenie nowej wersji systemu lub przynajmniej zaktualizowanie pewnego modułu. Jest to czas, w którym na serwerze pojawiają się nowe pliki, ale też testowane są modyfikacje, aby upewnić się, iż wszystko działa jak należy. Dotyczy to też parametrów konfiguracyjnych, których brak nierzadko stanowi zaskoczenie po wdrożeniu, gdyż w lokalnych środowiskach nie było potrzeby ich ustawiania lub modyfikowania. Dlatego tym bardziej warto posiadać jeden lub więcej serwerów testowych, zbliżonych pod kątem ekosystemu do serwera produkcyjnego, aby wykryć taką potrzebę dostosowania konfiguracji wcześniej.

Pojawia się również czasem konieczność przeprowadzenia na systemie operacji, które mogą potrwać dłużej i są na tyle obciążające, że może to dotknąć użytkowników normalnie korzystających z oprogramowania. Przykładem są jakieś gigantyczne raporty (ale rzadko; jeśli raport blokuje system, to nie jest to dobry sygnał) lub operacje czyszczące przeprowadzane na dużych tabelach. Pomijając kwestię architektonicznego podziału oprogramowania, warto wówczas zagrać w otwarte karty i poinformować o przerwie technicznej, aby nikt nie czuł się zaniepokojony potencjalną większą awarią i nie zaczął alarmować innych osób, burząc tym samym spokój i reputację twórców. Oczywiście, jeśli jesteśmy pewni, że wszystko będzie działać należycie, można zrezygnować z oficjalnej przerwy technicznej, ale w takiej sytuacji (jak i w każdej innej) i tak warto zrobić kopię zapasową bazy danych oraz odpowiednich plików.

Przerwa techniczna może też wynikać z przeprowadzenia konkretnych testów, które obciążają system lub weryfikują jego bezpieczeństwo, choć to się również rzadko zdarza - zazwyczaj są one przeprowadzane przed oficjalnym startem serwisu lub w trakcie, ale nigdy nie słyszałem o tym, aby wymogiem ich przeprowadzenia było zatrzymanie działającego oprogramowania. Jednak domyślam się, że życie pisze różne scenariusze.

Wreszcie, w przypadku niektórych firm może zajść potrzeba przeglądu i/lub modernizacji sprzętu. I tutaj wracamy między innymi do wspomnianych operatorów internetowych, którzy co jakiś czas muszą wymienić konkretny fragment infrastruktury lub przekonfigurować ją. W tym przypadku zazwyczaj odbywa się to na danym obszarze, który potencjalnie dotknąłby określoną grupę użytkowników. Przerwy techniczne związane z hardwarem mogą też dotyczyć oprogramowania - poza przypadkami aplikacji używanych w specyficznych środowiskach na określonych maszynach (desktopowych, wbudowanych itd.), zwyczajnie czasem przenosi się aplikacje między serwerami i transferuje domeny, co również trwa i w pewnych przypadkach może wymagać ogłoszenia oficjalnej pauzy.

Jak i kiedy informować?

Tak, jak wcześniej sobie podaliśmy, to zależy od rozmiaru i warunków, w jakich działa serwis. Najprostsza, ale zaraz też czasem równie kłopotliwa sytuacja jest w momencie, kiedy aplikacja jest wewnętrzna, tj. kierowana do pracowników konkretnej firmy lub organizacji. Z jednej strony łatwiej wówczas o umówienie takiej przerwy, gdyż komunikacja następuje pomiędzy dwoma podmiotami. Z drugiej strony, bywa tak, że użytkownicy korzystają z oprogramowania w konkretnych godzinach (np. 8:00-16:00) i w tym czasie system musi być w pełni dostępny, pomijając incydenty. Wówczas aktualizacje i inne prace muszą zachodzić poza tym zakresem czasowym lub w taki sposób, aby nie zaburzyć doświadczenia odbiorcy.

Inaczej bywa z systemami, które są kierowane do szerszego grona odbiorców - wówczas, jeśli istnieje choćby cień szansy, że system nie będzie w pełni "operowalny" w zauważalnym czasie, należy to publicznie ogłosić. Zazwyczaj robi się to poprzez media społecznościowe, jednak warto przyjąć zasadę, aby tego typu zdarzenia doczekały się komunikatu także na stronie firmowej lub w innych kontrolowanych miejscach. Dotyczy to zresztą nie tylko usług internetowych, ale też innych, jak choćby wodociągi, elektrownie, instytucje publiczne czy operatorzy innego rodzaju mediów. Owszem, nie zawsze można to zrobić na stronie projektu, zwłaszcza, jeśli to właśnie ona jest modernizowana, ale należy jasno wyznaczyć miejsce, w których odbiorcy będą wiedzieli, że tam mogą przeczytać o ewentualnych przerwach lub zorientować się, że chwilowa "awaria" to właśnie wynik zaplanowanych działań i się nie denerwować. W przypadku ważniejszych dostawców, zdecydowanie warto pomyśleć też o systemie powiadomień, mailowym lub SMS-owym, aby użytkownicy z odpowiednim wyprzedzeniem wiedzieli, kiedy nie skorzystają z usługi. Oczywiście, z zachowaniem RODO, prawa odbiorców do nieotrzymywania takich wiadomości itd. Szczególnie takiego ostrzeżenia kierowanego bezpośrednio do konsumentów zabrakło mi w przypadku omawianej sytuacji z operatorem usług sieciowych.

Jeśli chodzi o czas takiej przerwy technicznej, to w miarę możliwości warto zadbać o to, aby odbyła się ona w godzinach, w których użytkownicy najrzadziej korzystają z usługi - tak to robią np. banki. Natomiast tutaj trzeba powiedzieć wprost - nie zawsze jest to możliwe, gdyż w niektórych przypadkach firma nie dysponuje odpowiednią infrastrukturą lub zasobami, aby prowadzić takie prace o niestandardowych godzinach. Dlatego tym bardziej potrzebna jest wcześniejsza informacja, która pozwoli odbiorcom odpowiednio się przygotować i nie planować korzystania z usługi w czasie przerwy.

Jak to robią duże serwisy?

Ktoś może w tym momencie słusznie zapytać o to, w jaki sposób przerwy techniczne są przeprowadzane przez duże serwisy, oblegane przez tysiące lub nawet miliony użytkowników, a u których w sumie nie widać, aby cokolwiek się zatrzymywało. Nie dotyczy to banków, które - tak, jak już wspomnieliśmy - zgłaszają wcześniej przerwy i u których ten proces jest dużo bardziej sformalizowany. Ale np. platformy aukcyjne czy sklepy internetowe wypracowały pod tym względem swoje metody, które zazwyczaj idą w parze ze skalowaniem poziomym i posiadaniem wielu serwerów, na których istnieje kopia serwisu. To, oczywiście, wiąże się z dużymi nakładami na infrastrukturę, kadrę i procedury, jednak w przypadku dużych serwisów odpłaca się:

• większą odpornością na awarię - aktualizacja następuje krokowo, serwer po serwerze (tzw. rolling update), a więc problem zostanie zauważony wcześnie i nie u wszystkich od razu, więc będzie można łatwiej się z tego wycofać i sprawdzić dokładniej,
• większą dostępnością usługi,
• możliwością aktualizacji tylko konkretnej części systemu (choć to zależy również od jego architektury),
• łatwiejszą możliwością przeprowadzenia testów A/B,
• możliwością wprowadzania modyfikacji bez potrzeby zatrzymywania dostarczania usługi.

Dwa skrajne punkty interesują nas najbardziej - prace techniczne lub konserwacyjne nie zachodzą na wszystkich serwerach naraz, tylko na jednym lub kilku. One są faktycznie objęte przerwą, jednak reszta serwerów działa normalnie i w dalszym ciągu przyjmuje żądania. Dopiero po zakończeniu prac na pierwszych serwerach i włączeniu ich, zatrzymuje się kolejne i tam przeprowadza zmiany. Jest to, oczywiście, długotrwałe, wymaga oskryptowania i nie wszyscy użytkownicy od razu odczują pozytywne skutki, ale to również chroni całość przed negatywnymi konsekwencjami. Przynajmniej w przypadku serwisów internetowych, gdzie odbiorcy są przekierowywani między serwerami i niekoniecznie zawsze korzystają z tego samego - gorzej jest w przypadku dostarczania mediów, w tym połączenia internetowego, gdzie nieudane prace w jednym węźle "wyłączają" określoną grupę użytkowników.

Uwagi końcowe

A co w przypadku, kiedy przerwa techniczna się przedłuża lub pojawia się awaria? Pomijając procedurę diagnozy i naprawy, warto pamiętać, że w przypadku dostawców popularnych usług, należy zwyczajnie... przeprosić i poinformować. Nie powinno być tak, że odbiorcy o globalnej lub lokalnej niedyspozycji systemów dowiadują się okrężną drogą, czytając komentarze mieszczące się pod postami na Facebooku. Zabrzmi to dziwnie, gdyż wszystko zależy od kontekstu, ale awarie się zdarzają i czasem nie da się ich przewidzieć oraz uniknąć. Natomiast należy zadbać o odpowiednią informację, aby odbiorcy jeszcze bardziej się nie denerwowali, tylko poczuli, że ratunek przychodzi ze strony profesjonalistów. Taki system funkcjonuje np. u spółek wodociągowych, które na swojej stronie internetowej posiadają dział z planowanymi pracami oraz awariami, gdzie aktualizowany jest status.

Być może niektóre z przedstawionych informacji okazały się dla większości oczywiste. Czasem jednak trzeba napisać coś oczywistego, aby zasygnalizować, iż dane wytyczne nadal obowiązują i warto o nie zadbać.

Pozdrawiam i dziękuję - Jakub Rojek.