Odwołując się do Formuły 1, można podać przykład - wymianę opon. Ekipa techniczna ma na to dosłownie kilka sekund, ale przedtem następuje mozolne dobieranie właściwych opon do nawierzchni, temperatury oraz stanu zużycia poprzednich; potem przygotowuje się do ich założenia. Gdy Robert Kubica zjeżdża do boksu, przez dosłownie kilka sekund należy odkręcić śruby, zdjąć stare koła, założyć nowe i ponownie dokręcić śruby. Czas i wysiłek poświęcony na przygotowanie zmiany jest stosunkowo długi w porównaniu z czasem jej "wdrażania", zaś kluczowe jest umiejętne skalkulowanie ryzyka.

Nie mniej złożona, choć pewnie mniej efektowna od wymiany kół, jest wymiana dysków. Pamiętajmy, że maszyny działającej w trybie wysokiej dostępności nie można tak po prostu wyłączyć. Jedna z możliwych opcji to przygotowanie serwera zapasowego, przeniesienie na niego wszystkich danych, błyskawiczna "podmiana" serwerów. Potem trzeba wykonać odpowiednie operacje na dyskach, szybko sprawdzić nowe dyski, z powrotem "podmienić" serwer i na koniec upewnić się, że żadne dane i transakcje nie zostały zagubione lub zmienione podczas tej skomplikowanej operacji.

Dość pełne i spójne definicje, czym jest zarządzanie operacyjne i taktyczne informatyką, daje standard ITIL. Jednak sam standard nie zawiera definicji procesów; nie da się ich też w żaden sposób "kupić" (choć na pewno znajdą się chętni, by je naszej organizacji "sprzedać" i "wdrożyć"). Trzeba je zbudować samemu, stosownie do rozmiaru organizacji, poziomu jej dojrzałości, specyfiki klienta oraz poziomu kosztów, które decydenci są skłonni ponieść.

W strefie śmierci

Powyżej 99% dostępności rozciąga się "strefa śmierci", w której najmniejszy błąd oznacza niespełnienie oczekiwań i umów SLA. 0,1% niedostępności systemu w przypadku reżimu 24x7 to ok. 40 min w ciągu miesiąca. Akurat tyle, żeby przeprowadzić czynności absolutnie niezbędne, jak np. instalacja krytycznych łatek do systemu operacyjnego. Zaś np. błąd krytyczny, powodujący konieczność ponownego uruchomienia aplikacji, oznacza wyczerpanie praktycznie całego "zapasu" dopuszczalnego czasu niedostępności.

W "strefie śmierci" z pomocą częściowo przychodzą rozwiązania techniczne: klastrowanie serwerów i baz danych, redundancja łączy, budowanie infrastruktury zapasowej oraz instalacja i regularne testowanie mechanizmów failover. Chronią one przed przerwami wynikającymi z przyczyn trudnych do przewidzenia: awarią dysków, przypadkowym rozłączeniem sieci lokalnej itd. Dają czas na przywrócenie normalnego działania uszkodzonego elementu.

Projektowanie systemów, tak by zapewniały pełną redundancję (tj. awaria występująca w jednym miejscu nie została zaobserwowana przez użytkownika), to cała dziedzina nauki, tzw. inżynieria bezpieczeństwa systemów. Informatykom można poradzić czerpanie pełną garścią z doświadczeń inżynierów innych specjalności: biomedyków (projektujących urządzenia podtrzymujące życie), inżynierów motoryzacji oraz specjalistów konstrukcji lotniczych i kosmicznych.

Ale żadna redundancja nie zabezpieczy przed błędami o charakterze ludzkim. Jeśli aplikacja nie poradzi sobie ze zmianą czasu z letniego na zimowy (kiedy to w logach po raz drugi pojawiają się te same stemple czasowe), jeśli przy przejściu pomiędzy platformą aplikacyjną a bazodanową "gubią się" znaki narodowe, jeśli przy kombinacji warunków program wpada w nieskończoną pętlę - to żadna redundancja i failover nie spełnią swojego zadania. To tak jak w wyścigach Formuły 1 - nowa para opon nie pomoże, jeśli do baku wlano niewłaściwe paliwo.

Redundancja nie może być traktowana jako antidotum na wszelkie bolączki, bo ma także bardzo istotne efekty uboczne - koszty. Systemy informatyczne w firmie zawsze stanowią jakiś kompromis między pożądaną funkcjonalnością i jakością a kosztami, które przedsiębiorstwo jest skłonne ponieść.

Błędy programistyczne i konstrukcyjne ukryte w aplikacji mogą stać się przyczyną niedostępności, ale nie tylko. W "strefie śmierci", powyżej 99%, najlepiej widać skutki długofalowego zarządzania. Na przykład tylko firma dbająca o bezpieczeństwo swoich systemów na każdym poziomie (tj. komponentu, systemu oraz procedur i regulacji) jest w stanie uniknąć przestojów spowodowanych włamaniem na konto administracyjne albo epidemią wirusową. Tylko przedsiębiorstwo, które dba o rozwój kwalifikacji pracowników, jest w stanie zapewnić, że nie popełnią oni banalnego błędu przy ryzykownej operacji typu wymiana sprzętu albo upgrade systemu do nowej wersji. Organizacja, która przestrzega godzin pracy i nie eksploatuje ponad miarę swoich pracowników, będzie w stanie uchronić swoją infrastrukturę przed skutkami usterki wprowadzonej przez kogoś pracującego dwunastą godzinę z rzędu.

Wysoka dostępność to także dobra komunikacja i zaufanie do ludzi. CIO, ani nawet menedżerowie średniego szczebla nie są w stanie kontrolować wszystkich czynników, które wpływają na dostępność. Ale jeśli ludzie w organizacji IT są świadomi celów biznesowych, jeśli wiedzą, że mają prawo do samodzielnego myślenia, działania oraz ewentualnego błędu, to taka organizacja jest w stanie działać w sposób efektywny. Zapewni wysoką dostępność swoim odbiorcom - i to nie dlatego że miliony włożono w drogie technologie. Dlatego że tym, co posiada, jest w stanie zarządzać w sposób optymalny.

Poza dostępnością

Wracamy więc do dobrego zarządzania. Bez niego infrastrukturalne "pudełka" mogą okazać się jedynie drogimi zabawkami, nie zaś sposobem na wysoką dostępność systemów. A dobrze zarządzana firma nie tylko umożliwia swoim klientom korzystanie z systemów, kiedy ich potrzebują, ale także stanowi miejsce, gdzie informatykom chce się pracować i rozwijać.