A czego nas powinna nauczyć ta katastrofa systemu sieci teleinformatycznej? Poniżej pięć nasuwających się wniosków.

Po pierwsze, procedura modernizacji i modyfikacji systemu, nawet łącznie z wpisywaniem pojedynczych linii skryptów powinna być najpierw wdrożona i dokładnie przetestowana na drugim, w mniejszej skali, ale identycznym funkcjonalnie i wykorzystującym tego samego typu elementy systemie z testowym obciążeniem. A tu chyba zastosowano zasadę „wdróż dzisiaj, napraw jutro”.

Po drugie, tworzenie mega, a nawet giga systemu konsolidującego w sobie wszystkie potrzebne funkcje znacząco utrudnia jego administrowanie i naraża go na „upadek” nawet z powodu drobnego lokalnego błędu w oprogramowaniu lub awarii urządzenia, ewentualnie wskutek cyberataku. Lepszym rozwiązaniem jest utworzenie rodziny (grona, klastra) systemów wyposażonych w potrzebne funkcjonalności, nawet wzajemnie redundantne i dobrze ze sobą skomunikowane.

Po trzecie, w przypadku istotnej operacji modernizacji systemu większość inżynierów powinna być fizycznie obecna w centrum komputerowym, dysponując bezpośrednim połączeniem z modyfikowanym systemem. Inżynierowie pracujący zdalnie, obserwując zewnętrzne, z punktu widzenia użytkownika, działanie systemu muszą mieć jednocześnie niezależny kontakt z centrum.

Po czwarte, specjaliści pracujący zdalnie oraz zwykli użytkownicy oraz firmy korzystające z systemu teleinformatycznego jednego operatora powinni zapewnić sobie też dostęp do takiego systemu u innego operatora, weryfikując często poprawność działania tej opcji (nawiasem mówiąc, jutro idę przenieść numer jednej z moich komórek do innego operatora, bo dotychczas wszystkie są u tego samego).

Po piąte, warto dla każdego takiego systemu opracować zasady jego zarządzania i odtwarzania w sytuacji całkowitego lub lokalnego braku zasilania (u mnie na przykład dostęp do internetu znika nawet po chwilowym zaniku zasilania i dopiero po zgłoszeniu awarii jest prawie natychmiast przywracany).

Zapewne dla grona czytelników pisma CRN są to stwierdzenia dobrze znane. Natomiast CTO Rogersa chyba tego nie wiedział i dlatego wyleciał z intratnej posady. Tym bardziej, że Rogers miał już podobną awarię rok wcześniej…

Dziękuję Markowi Nowickiemu z Kanady za dostarczenie informacji zawartych w tekście, a Zbyszkowi Bieleckiemu za cenne komentarze z miejsca zdarzenia.

Wacław Iszkowski  

Autor w latach 1993–2016 był prezesem Polskiej Izby Informatyki i Telekomunikacji. Pracował też w firmach: Oracle, DEC Polska, 2SI, EDS Poland, TP Internet. Obecnie jest senior konsultantem przemysłu teleinformatycznego.