Czy wysoki uptime to powód do dumy? Niekoniecznie...

Wśród wielu administratorów wciąż popularny jest pogląd, że długi czas uruchomienia serwera (uptime) jest źródłem chwały. Brak konieczności restartu systemu ma świadczyć o tym, że wybrane oprogramowanie jest stabilne i poprawnie skonfigurowane, sprzęt porządny i niepodatny na zawieszenia, a infrastruktura (sieciowa i elektryczna) – godna zaufania. Taki splot cech ma zapewniać wysoką dostępność (high availability) rozwiązania pod opieką administratora i generalnie oznaczać, że porządnie wykonuje on swoje obowiązki.

Takie postawienie sprawy często wywołuje wolę wyścigu i nakręca przechwałki dotyczące tego, jak długo czyjś serwer działa bez restartu. Swoją chwilę sławy mają tutaj administratorzy systemów uniksowych, bowiem ich systemy znacznie rzadziej wymuszają restarty podczas aktualizacji, niż Windows (choć nie oznacza to od razu, że owe aktualizacje bez restartu cokolwiek dają...). Ale czy naprawdę miarą "dobrej roboty" jest wysoki uptime serwera? Zdecydowanie nie. W dodatku coraz częstsze są scenariusze, w których wysoki uptime oznacza nieświadomą beztroskę lub wręcz zaniedbanie.

Długo uruchomiony system to system bez nałożonych aktualizacji. Częste wymówki, że przecież system jest "dobrze zabezpieczony" albo znajduje się w scenariuszu wdrożenia pozbawionym możliwości ataku są chybione. Niektórych rzeczy nie da się zabezpieczyć bez aktualizacji, a żadna infrastruktura nie może być uznawana za w pełni bezpieczną. Nie wolno również projektować systemów komputerowych na bazie założenia "no ale przecież nikt tam nie wejdzie i nie podłączy tego klastra do internetu!". Wielu już tak myślało i nierzadko wyrządzili sobie w ten sposób niemałą krzywdę.

Należy powiedzieć jasno: wysoka dostępność świadczonej usługi nie jest bezpośrednim efektem wysokiej dostępności sesji systemu operacyjnego. Serwery instaluje się po coś, nie tylko po to, żeby sobie pracowały. To usługa, aplikacja, funkcjonalność ma być dostępna, a nie jakiś system operacyjny pod spodem. Wysokodostępne rozwiązanie przewiduje możliwość przezroczystego failoveru, bezinwazyjnej procedury przełączenia obciążenia na inny system, gdy ten pierwszy podlega konserwacji. Zakłada też wygodne skalowanie, co oznacza że łatwo dodać do systemu kolejne węzły tak, aby konserwacja była jak najmniej zauważalna.

W takich sytuacjach wysoki uptime jest nie tylko bezwartościowy, ale i groźnie mylący. Nowoczesne sposoby wdrażania aplikacji już się nim nie przejmują: gdy trzeba cokolwiek podmienić albo zaktualizować w kontenerze, po prostu bez sentymentów się go wywala i podmienia nowym. A jeżeli jakaś maszyna zaczyna mieć problemy z pamięcią, to się ją zatrzymuje, a obok odmraża kopię ze snapshota. Potem można ewentualnie znaleźć źródło problemu, ale na pewno nie warto trzymać uptime'u, bo przestaje on być wyznacznikiem odpowiedzialności.

Nie znaczy to jednak, że kiedyś nim nie był. Wielkie mainframe'owe maszyny postawione w czasach sprzed zautomatyzowanych ataków cyfrowych, świadczące usługi pod wynajem istotnie szczyciły się wysokim uptimem, bo tutaj trudno było o nadmiarowość albo jakieś nowoczesne pomysły. Niektóre systemy postawione lata temu, na których zaktualizowanie nie ma pieniędzy, również mogą być oparte o filozofię "tego serwera nie wyłączamy" i trudno cokolwiek z tym zrobić. Niemniej, zdecydowanie szkodliwym wzorcem jest opieranie się dziś na takim założeniu podczas projektowania nowych systemów. Nie popełniajmy błędów architektonicznych i nie wdrażajmy Świętych Serwerów w których trudno o failover. Nie ma żadnego powodu do chwalenia się tym, że jakiś RHEL 7.3 z niepołatanym jądrem "działa już trzy lata!". Bo to niedobrze. I wskazuje na więcej szczęścia niż rozumu.

Czy jesteście dumni ze swoich uptime'ów? A może znacie kogoś, kto ciągle chwaili się swoimi? Dajcie nam znać w komentarzach!