Automatyzacja zarządzania serwerami: od czego zacząć

Automatyzacja zarządzania serwerami kojarzy się z dużymi środowiskami, a najbardziej opłaca się tam, gdzie ludzi jest mało. Przy trzech maszynach i jednym administratorze problemem nie jest skala, tylko to, że konfiguracja istnieje wyłącznie na serwerze i w cudzej pamięci.

Powtarzalność, nie oszczędność czasu

Argument o oszczędzaniu czasu bywa mylący, bo napisanie automatyzacji zajmuje więcej niż jednorazowe wykonanie zadania ręcznie. Zwrot pojawia się gdzie indziej.

Po pierwsze, konfiguracja przestaje być wiedzą ukrytą i staje się zapisem, który da się przeczytać. Po drugie, odtworzenie maszyny po awarii przestaje być rekonstrukcją z pamięci. Po trzecie, zmiana wykonana na trzech serwerach jest wykonana tak samo na każdym z nich, a nie trzy razy podobnie.

Ta trzecia rzecz jest źródłem większości dziwnych awarii. Serwery, które miały być identyczne, rozjeżdżają się przez lata drobnych ręcznych poprawek, aż zaczynają zachowywać się inaczej przy tej samej aktualizacji.

Warstwy, które da się automatyzować osobno

Nie trzeba brać wszystkiego naraz. Warstwy są trzy i każda ma inny próg wejścia.

Instalacja systemu. Najniższy poziom. Powtarzalna instalacja z tym samym zestawem pakietów i ustawień początkowych. Przy serwerze dzierżawionym wiele z tego załatwia panel dostawcy. W serwerach dedykowanych SDC system instaluje się przez zdalne zarządzanie IPMI, a usługa jest deklarowana jako gotowa w 5 minut (źródło: sprintdatacenter.pl/najtansze-serwery-dedykowane). Opisywaliśmy szerzej, co dzieje się po zamówieniu serwera.

Konfiguracja systemu i usług. Tu leży największa wartość dla małego zespołu. Użytkownicy, klucze, pakiety, reguły zapory, ustawienia usług. To warstwa, którą najczęściej odtwarza się po awarii i najtrudniej odtworzyć z pamięci.

Wdrożenia aplikacji. Najbardziej zależna od tego, co robicie. Warto brać ją na końcu, gdy dwie poprzednie są opanowane.

Zacznij od jednej rzeczy, którą robisz najczęściej

Najskuteczniejszy start to nie wybór narzędzia, tylko wybór zadania. Weź czynność, którą wykonujesz regularnie i która ma jasny wynik: konfigurację nowego użytkownika z kluczami, ustawienie reguł zapory, instalację i konfigurację serwera WWW.

Zapisz ją tak, żeby dała się uruchomić ponownie bez zmian i z tym samym skutkiem. To jedyny warunek, który naprawdę odróżnia automatyzację od skryptu. Narzędzia do zarządzania konfiguracją opierają się właśnie na tej zasadzie: opisujesz stan docelowy, a nie kroki do wykonania, dzięki czemu drugie uruchomienie niczego nie psuje.

Sprawdzian jest prosty. Uruchom to samo dwa razy pod rząd. Jeśli za drugim razem coś się zdubluje albo wysypie, nie masz jeszcze automatyzacji.

Czego nie automatyzować na początku

Trzy rzeczy lepiej zostawić na później, bo koszt błędu jest w nich nieproporcjonalnie wysoki:

• Operacje na danych produkcyjnych. Migracje baz i czyszczenie danych rób ręcznie, dopóki nie masz zaufania do narzędzia i do testów.
• Zmiany w sieci, przez którą się łączysz. Automat, który zmienia reguły zapory, potrafi odciąć sam siebie. Przy takich zmianach dostęp przez konsolę sprzętową jest zabezpieczeniem, a nie luksusem.
• Wszystko, czego nie umiesz cofnąć ręcznie. Jeśli nie wiesz, jak naprawić skutek automatyzacji po awarii, automatyzacja tego zadania zwiększa ryzyko, zamiast je zmniejszać.

Hasła i klucze nie należą do repozytorium

Automatyzacja zaczyna przechowywać poświadczenia niemal od razu i to jest moment, w którym najczęściej powstaje problem. Hasło zapisane w pliku konfiguracyjnym, który trafia do repozytorium, zostaje w jego historii nawet po usunięciu.

Rozdziel dwie rzeczy: opis konfiguracji trzymaj w repozytorium, a sekrety w menedżerze haseł albo dedykowanym magazynie, z którego automatyzacja pobiera je w trakcie działania. Przy prostych konfiguracjach wystarczy szyfrowany plik z sekretami, trzymany osobno i z osobną kontrolą dostępu.

Kiedy taniej jest kupić obsługę

Automatyzacja ma sens, gdy ktoś będzie ją utrzymywał. W zespole, w którym administracja jest zajęciem pobocznym, opisy konfiguracji potrafią zestarzeć się szybciej niż dokumentacja, a to gorsze niż ich brak.

W takiej sytuacji warto policzyć alternatywę. W pakietach administracyjnych SDC obsługa serwera jest rozliczana miesięcznie, z określoną liczbą godzin i zadeklarowanym czasem reakcji w wariantach Small Business oraz Full Business (źródło: sprintdatacenter.pl/pakiety-administracyjne). Przy jednym lub dwóch serwerach bywa to rozsądniejsze niż budowanie i utrzymywanie własnej automatyzacji.

Podsumowanie

Wybierz jedno powtarzalne zadanie, zapisz je tak, by dało się uruchomić dwa razy bez skutków ubocznych, i trzymaj sekrety poza repozytorium. Wartością nie jest zaoszczędzony czas, tylko to, że konfiguracja przestaje zależeć od pamięci jednej osoby.

Planujesz środowisko, które ma być powtarzalne od początku? Zobacz ofertę serwerów dedykowanych albo napisz do nas.

FAQ – najczęściej zadawane pytania o automatyzację zarządzania serwerami

Czy automatyzacja ma sens przy dwóch serwerach?

Tak, choć z innego powodu niż przy dwudziestu. Przy dwóch maszynach zyskiem nie jest skala, tylko zapisana konfiguracja, z której da się odtworzyć środowisko po awarii i którą może przeczytać ktoś inny niż autor.

Od jakiego narzędzia zacząć?

Od takiego, które Twój zespół zrozumie i utrzyma, a nie od najbardziej rozbudowanego. Przy małej infrastrukturze wystarczają narzędzia działające bez instalowania agenta na serwerach, sterowane opisem stanu docelowego. Wybór narzędzia jest mniej istotny niż konsekwencja w jego stosowaniu.

Co zrobić z serwerami, które już działają i są konfigurowane ręcznie?

Nie przepisywać ich naraz. Przy najbliższej zmianie opisz automatycznie tylko ten fragment, którego dotykasz, i stopniowo powiększaj zakres. Pełne odtworzenie istniejącej maszyny warto zrobić dopiero wtedy, gdy i tak planujesz jej wymianę.

Czy automatyzacja zastępuje dokumentację?

Częściowo. Opis konfiguracji jest dokumentacją stanu i zawsze aktualną, bo wykonywalną. Nie zastępuje jednak wyjaśnienia, dlaczego coś zostało zrobione w dany sposób, ani procedury odtworzenia usługi po awarii. Te dwie rzeczy nadal trzeba zapisać osobno.

Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.