Dlaczego restartujemy serwery

Pytanie, które pojawia się dość regularnie, dotyczy tego, czy serwery powinny być rutynowo restartowane, np. raz w tygodniu, czy też powinny działać jak najdłużej, by osiągnąć maksymalny "uptime". Dla mnie odpowiedź jest prosta — z rzadkimi wyjątkami, regularne restarty są najbardziej odpowiednim wyborem dla serwerów.

Jak w przypadku każdej zasady, istnieją przypadki, w których nie ma ona zastosowania. Na przykład niektóre firmy obsługujące krytyczne systemy nie mają żadnego okna na przestój i muszą być dostępne 24/7. Oczywiście takich systemów nie można po prostu rutynowo restartować. Jednak jeśli system jest tak krytyczny, że nigdy nie może przestać działać, sytuacja ta powinna wzbudzić alarm, że system ten jest punktem awarii i być może należy rozważyć sposób postępowania z przestojem, zarówno planowanym, jak i nieplanowanym.

Kolejnym wyjątkiem są niektóre systemy AIX, które potrzebują znacznego czasu pracy, powyżej kilku tygodni, by osiągnąć maksymalną wydajność, ponieważ system jest samostrojący i potrzebuje czasu na uzyskanie informacji o użytkowaniu i odpowiednie dostosowanie się. Dotyczy to zazwyczaj dużych, rzadko zmieniających się serwerów bazodanowych i podobnych scenariuszy użycia, które są mniej powszechne niż na innych platformach.

W IT często wielbimy pojęcie "uptime" — jak długo system może działać bez konieczności restartu. Ale "uptime" nie jest pojęciem przynoszącym wartość firmie, a IT musi przez cały czas mieć na uwadze potrzeby biznesowe, zamiast skupiać się na sztucznych metrykach. Firma nie jest zainteresowana tym, jak długo serwer utrzymał się online bez restartu — zależy jej jedynie na tym, że serwer jest dostępny i gotowy do działania, gdy jest potrzebny do procesów biznesowych. To są bardzo różne pojęcia.

Dla większości normalnych serwerów biznesowych istnieje okno, w którym serwer musi być dostępny do celów biznesowych, i okno, w którym nie jest potrzebny. Okna te mogą być dzienne, tygodniowe lub miesięczne, ale rzadko zdarza się serwer, który jest faktycznie używany przez całą dobę bez wyjątku.

Często słyszę, jak ludzie twierdzą, że ponieważ używają systemu operacyjnego X zamiast Y, nie muszą już restartować, ale to po prostu nieprawda. Istnieją dwa główne powody regularnego restartowania: weryfikacja zdolności serwera do pomyślnego zresetowania oraz stosowanie łatek, których nie można zastosować bez restartu.

Stosowanie łatek jest powodem, dla którego większość firm restartuje serwery. Niemal wszystkie systemy operacyjne otrzymują regularne aktualizacje wymagające restartu, by weszły w życie. Ponieważ większość łatek jest wydawana ze względów bezpieczeństwa i stabilności, szczególnie te wymagające restartu, ich stosowanie jest dość ważne. Pozostawianie serwera niepotrzebnie narażonego tylko po to, by utrzymać uptime, nie jest mądrym rozwiązaniem.

Testowanie zdolności serwera do pomyślnego restartu jest tym, co często jest pomijane. Większość serwerów ma regularnie wprowadzane zmiany. Zmiany mogą obejmować łatki, nowe aplikacje, zmiany konfiguracji, aktualizacje lub podobne. Każda zmiana wprowadza ryzyko. To, że serwer jest sprawny natychmiast po zastosowaniu zmiany, nie oznacza, że serwer ani aplikacje na nim działające uruchomią się zgodnie z oczekiwaniami po restarcie.

Jeśli serwer nigdy nie jest restartowany, nigdy nie wiemy, czy może pomyślnie się zrestartować. Z czasem liczba zmian wprowadzonych od ostatniego restartu będzie rosła. Jest to bardzo niebezpieczne. To, czego się obawiamy, to duża liczba wprowadzonych zmian, z których wiele może być nieudokumentowanych, a restart kończy się niepowodzeniem. W tym momencie zidentyfikowanie, która zmiana powoduje awarię systemu, może być procesem nie do pokonania. Brak pojedynczej zmiany do cofnięcia, brak znanej ścieżki do odtworzenia. To jest moment, gdy wpada panika. Oczywiście serwer, który nigdy nie jest celowo restartowany, jest bardziej prawdopodobny do niecelowego restartu — co oznacza, że ryzyko nieudanego restartu jest zarówno większe, jak i bardziej prawdopodobne, że wystąpi w trakcie aktywnego użytkowania.

Chociaż regularne restarty nie mają na celu zmniejszenia częstotliwości nieudanych restartów — w rzeczywistości zwiększają liczbę wystąpień awarii — ich celem jest uczynienie tych awarii łatwo zarządzalnymi z punktu widzenia "znanych zmian" i, co ważniejsze, kontrolowanie momentu tych restartów, by upewnić się, że następują w czasie, gdy serwer jest przeznaczony do konserwacji i jest zaprojektowany do testowania pod obciążeniem, tak by problemy były wykrywane w momencie, gdy można je ograniczyć bez wpływu na biznes.

Słyszałem wielu administratorów systemów twierdzących, że unikają weekendowych restartów, bo nie chcą pracować w niedziele z powodu serwerów, które nie wracają do życia po restarcie. Sam byłem wzywany wiele niedzielnych poranków z powodu nieudanego restartu, ale za każdym razem, gdy odbierałem ten telefon, czułem ulgę. Wiedziałem, że właśnie wykryliśmy problem w momencie, gdy firma nie jest narażona na straty finansowe. Gdyby ten serwer nie był zrestartowany poza godzinami pracy, mogło się okazać, że jego "niemożliwość uruchomienia" zostałaby odkryta dopiero po awarii w aktywnych godzinach biznesowych, powodując utratę przychodów.

Dzięki regularnym weekendowym restartom możemy wykrywać nadchodzące katastrofy w bezpieczny sposób, a dzięki wiedzy, że mamy do zbadania tylko jeden tydzień zmian, jesteśmy zazwyczaj w stanie naprawić problemy przy stosunkowo niewielkim wysiłku i z dużą pewnością, że rozumiemy, jakie zmiany zostały wprowadzone przed awarią.

Regularne restarty mają na celu ochronę firmy przed przestojami i awariami, którym można zapobiec poprzez bardzo proste i niezawodne procesy.