Comiesięczna checklista utrzymania IT.
Co sprawdzać, nawet gdy wszystko działa?

Serwery działają. Backup ma zielony status. Użytkownicy nie zgłaszają problemów. Internet działa, ERP odpowiada, Microsoft 365 nie zgłasza incydentów, a monitoring nie świeci się na czerwono.

Czyli można niczego nie ruszać? Właśnie wtedy warto przyjrzeć się infrastrukturze najdokładniej. Wiele problemów IT nie zaczyna się od nagłej awarii. Narastają przez tygodnie albo miesiące.

Żaden z tych problemów nie musi dzisiaj powodować awarii. Ale każdy może stać się jej przyczyną później. Dlatego dobra administracja IT nie polega tylko na reagowaniu na alerty. Potrzebny jest również regularny przegląd środowiska.

Nie zamiast monitoringu. Obok monitoringu.

Ten artykuł to praktyczna checklista na co miesiąc. Jeśli szukasz szerszego opisu tego, jak zorganizować cały proces i raport dla zarządu, zajrzyj do przewodnika jak wygląda profesjonalny miesięczny przegląd infrastruktury IT.

Comiesięczny przegląd nie zastępuje monitoringu

To najważniejsze zastrzeżenie na początku. Niektórych rzeczy nie powinno się sprawdzać raz w miesiącu. Awaria backupu nie może czekać 29 dni na odkrycie. Podobnie:

Takie zdarzenia powinny być monitorowane automatycznie i zgłaszane możliwie szybko. Jak to zorganizować, opisujemy w artykule monitoring infrastruktury IT.

Po co więc comiesięczny przegląd? Żeby sprawdzić rzeczy, których pojedynczy alert często nie pokaże:

Dlaczego "wszystko działa" nie oznacza, że infrastruktura jest zdrowa?

Brak awarii jest dobrą wiadomością. Nie jest jednak dowodem, że wszystkie elementy środowiska są poprawnie utrzymywane.

Backup może działać, ale nie być użyteczny

Job kończy się statusem success. To nadal nie mówi nam:

• › czy obejmuje wszystkie potrzebne dane,
• › czy retencja jest poprawna,
• › czy kopia off-site rzeczywiście powstaje,
• › czy znamy hasło lub klucz potrzebny do odzyskania danych,
• › czy da się wykonać restore,
• › ile czasu zajmie przywrócenie usługi.

Dlatego backup trzeba monitorować na bieżąco, a jego odtwarzalność testować okresowo.

Zasoby mogą się kończyć powoli

Sam aktualny wynik storage wygląda dobrze. Trend już niekoniecznie. Podobnie można analizować RAM, IOPS, przestrzeń backupową, liczbę połączeń do bazy, obciążenie WAN, wielkość logów, czas wykonywania backupu i rozmiar baz danych.

Uprawnienia z czasem się rozrastają

Nowy użytkownik potrzebował dostępu. Później zmienił dział. Dostał kolejne uprawnienia. Poprzednich nikt nie odebrał. Po kilku latach powstaje środowisko, w którym część użytkowników ma dostęp do znacznie większej liczby systemów, niż rzeczywiście potrzebuje. To samo dotyczy:

Dokumentacja starzeje się szybciej niż infrastruktura

Dodaliśmy VLAN. Przenieśliśmy VM. Zmieniliśmy operatora. Serwer SQL ma inny adres. Backup trafia już na nowe repozytorium. Tyle że diagram sieci nadal pokazuje stan sprzed roku.

Problem pojawia się dopiero podczas awarii, gdy dokumentacja nagle zaczyna być naprawdę potrzebna.

Jak powinien wyglądać comiesięczny przegląd IT?

Nie powinien być 80-punktowym Excelem, którego administratorzy zaczynają nienawidzić po drugim miesiącu. Lepiej przygotować krótszą listę obejmującą najważniejsze obszary:

Nie każdy punkt musi być wykonywany ręcznie. Wręcz przeciwnie. System powinien automatycznie zbierać dane. Administrator powinien przede wszystkim analizować wyjątki i podejmować decyzje.

1. Przejrzyj monitoring, ale patrz na trendy

Nie chodzi o otwarcie Grafany i stwierdzenie "wszystko zielone". W miesięcznym przeglądzie interesuje nas szerszy okres: ostatnie 30, 60 albo 90 dni. W zależności od środowiska warto sprawdzić:

Szukamy nie tylko przekroczeń progów. Szukamy trendów. Jeżeli przez trzy miesiące wykorzystanie storage rośnie o kilka punktów procentowych miesięcznie, możemy zaplanować rozbudowę, zanim pojawi się alert 95%.

Sprawdź również sam monitoring

Raz na jakiś czas warto zapytać:

2. Sprawdź backup i ostatnie testy restore

Backup powinien być kontrolowany codziennie lub automatycznie. Miesięczny przegląd ma odpowiedzieć na szersze pytania.

Czy kopiujemy właściwe rzeczy?

Sprawdź, czy backup obejmuje:

Szczególnie interesujące są nowe systemy. Nowa maszyna może działać od trzech tygodni, ale nikt nie dodał jej do polityki backupowej.

Czy retencja nadal jest właściwa?

Sprawdź liczbę punktów przywracania, retencję, wykorzystanie repozytorium, kopię off-site, niezmienność kopii (jeżeli jest stosowana) i szyfrowanie. Gdzie i jak trzymać drugą kopię, opisujemy w artykule backup off-site.

Kiedy ostatnio wykonaliśmy restore?

Nie każdy system musi być odtwarzany co miesiąc. Częstotliwość testów powinna wynikać z krytyczności danych i wymaganego RTO/RPO. Można przykładowo stosować:

Najważniejsze, żeby istniał harmonogram. Nie odpowiedź "chyba kiedyś sprawdzaliśmy". Jak przeprowadzić taki test krok po kroku, opisujemy w artykule test odtwarzania backupu.

RTO i RPO

3. Zrób capacity planning

Nie czekaj, aż będzie 98%. Przynajmniej raz w miesiącu warto ocenić, co może skończyć się w najbliższych miesiącach.

W klastrze wirtualizacyjnym dochodzi jeszcze jedno pytanie:

4. Przejrzyj aktualizacje i podatności

Patch management nie powinien sprowadzać się do żadnej z nich. Warto regularnie sprawdzić:

Nie każda podatność oznacza identyczne ryzyko. Liczą się między innymi ekspozycja systemu, możliwość wykorzystania podatności, krytyczność usługi, dostępność poprawki i ryzyko samej aktualizacji. Więcej o tym piszemy w artykule bezpieczne aktualizacje systemów.

5. Przejrzyj konta i uprawnienia

To jeden z najważniejszych punktów. Sprawdź między innymi:

Szczególną uwagę zwróć na administratorów

Lista użytkowników mających pełne uprawnienia powinna być krótka i zrozumiała. Dla każdego konta powinniśmy wiedzieć:

• › do kogo należy,
• › dlaczego istnieje i do czego służy,
• › czy nadal jest potrzebne,
• › czy posiada MFA, jeżeli system je obsługuje.

Osobne konto administracyjne jest zwykle lepszym rozwiązaniem niż wykonywanie codziennej pracy na koncie posiadającym pełne uprawnienia.

Sprawdź również konta techniczne

Service account utworzony pięć lat temu może nadal posiadać:

Tego rodzaju konta łatwo przegapić przy zwykłym offboardingu pracownika.

6. Certyfikaty, domeny, licencje i inne daty ważności

Niektóre awarie są całkowicie przewidywalne. Certyfikat ma konkretną datę wygaśnięcia. Domena również. Licencja również. Mimo to nadal zdarzają się awarie spowodowane przez rzeczy, o których od miesięcy wiadomo było, kiedy przestaną działać.

Monitoruj automatycznie

Jeżeli certyfikat jest krytyczny, jego daty nie powinno się kontrolować wyłącznie raz w miesiącu. Monitoring powinien ostrzegać z wyprzedzeniem (więcej w artykule monitoring certyfikatów SSL). Miesięczny przegląd służy sprawdzeniu:

• › co wygasa w kolejnych 30-90 dniach,
• › czy alerty działają,
• › kto odpowiada za odnowienie,
• › czy proces odnowienia jest automatyczny.

Przejrzyj:

7. Sprawdź sieć i sprzęt

Comiesięczna administracja nie kończy się na serwerach. Warto sprawdzić również routery, firewalle, switche, access pointy, UPS, storage i pozostały sprzęt fizyczny. Szczegółowo opisujemy to w artykule monitoring sieci w firmie.

UPS

Jeżeli monitoring pozwala odczytać status baterii, czas pracy, wynik self-testu i temperaturę, warto uwzględnić te dane w stałym nadzorze.

8. Sprawdź backup konfiguracji urządzeń

To punkt często pomijany. Firma posiada backup serwerów. Ale co z:

Po awarii urządzenia można kupić nowe. Znacznie trudniej odtworzyć konfigurację, jeżeli jej aktualna wersja istniała wyłącznie na uszkodzonym sprzęcie. W miesięcznym przeglądzie warto więc upewnić się, że:

9. Przejrzyj incydenty z ostatniego miesiąca

Każda awaria powinna czegoś nauczyć. Jeżeli w poprzednim miesiącu zabrakło miejsca, backup się nie wykonał, wygasł certyfikat, VPN przestał działać albo uszkodził się dysk, to pytanie nie powinno brzmieć tylko:

Może trzeba dodać alert, poprawić próg, rozszerzyć monitoring, zmienić retencję, dopisać runbook albo zautomatyzować procedurę.

Domykaj działania po incydentach

Jeżeli po awarii ustalono "trzeba dodać monitoring certyfikatów", to podczas kolejnego miesięcznego review warto sprawdzić, czy rzeczywiście został dodany.

10. Przejrzyj zmiany w infrastrukturze

Co zmieniło się przez ostatni miesiąc?

Każda taka zmiana może wpływać na monitoring, backup, dokumentację, bezpieczeństwo, pojemność i procedury awaryjne. Dobry miesięczny przegląd pozwala wyłapać sytuację:

11. Szukaj zmian wykonanych poza normalną procedurą

Podczas awarii administrator czasem musi zrobić hotfix. To normalne. Problem zaczyna się wtedy, gdy hotfix staje się konfiguracją na kolejne trzy lata.

Jeżeli firma korzysta z Ansible, Terraform, GitOps albo konfiguracji przechowywanej w Git, warto sprawdzić, czy stan rzeczywisty nadal odpowiada temu, co zapisano w kodzie. Ręczna zmiana powinna zostać cofnięta albo przeniesiona do właściwej konfiguracji.

12. Zaktualizuj najważniejszą dokumentację

Nie chodzi o przepisywanie całej dokumentacji co miesiąc. Wystarczy odpowiedzieć na pytanie: czy wydarzyło się coś, przez co obecna dokumentacja jest już nieprawdziwa? Najważniejsze są informacje potrzebne podczas awarii:

Dobry test dokumentacji jest prosty. Administrator, który nie wykonywał danej czynności, powinien być w stanie przeprowadzić ją na podstawie instrukcji. Jeżeli musi zadzwonić do autora z pytaniem "co autor miał tutaj na myśli?", runbook wymaga poprawy. Aktualna dokumentacja to też pierwsza rzecz, którą sprawdzamy podczas audytu IT przed przejęciem obsługi.

13. Sprawdź procedury dostępu awaryjnego

Co się stanie, jeżeli główny administrator będzie na urlopie, zachoruje albo zakończy współpracę? Czy druga osoba posiada:

Nie chodzi o rozdawanie wszystkim pełnych uprawnień. Chodzi o to, żeby firma nie była uzależniona od jednego człowieka.

14. Przejrzyj koszty i nieużywane zasoby

To szczególnie ważne w chmurze, ale nie tylko. Szukamy rzeczy, które istnieją, choć nikt już ich nie potrzebuje:

W środowisku lokalnym pytanie może być inne: "czy naprawdę potrzebujemy utrzymywać pięć starych VM, o których nikt nie wie, do czego służą?" Nie kasujemy ich od razu. Najpierw ustalamy właściciela i przeznaczenie.

15. Sprawdź samą checklistę

Proces utrzymania również może się zestarzeć. Raz na kilka miesięcy warto sprawdzić:

• › które punkty nigdy niczego nie wykrywają,
• › czego zabrakło podczas ostatniej awarii,
• › co udało się zautomatyzować,
• › jakie nowe systemy pojawiły się w firmie.

Jeżeli podczas incydentu odkryliśmy problem, którego checklista nie obejmowała, warto go do niej dodać. Jeżeli jakiś punkt od roku jest wykonywany ręcznie i zawsze ma identyczny rezultat, może należy go zautomatyzować.

Przykładowa comiesięczna checklista administratora

Co warto zautomatyzować?

Celem nie jest comiesięczne klikanie po dwudziestu panelach. Dobrze zaprojektowane środowisko samo powinno zebrać większość informacji. Administrator analizuje rezultat. Można automatyzować między innymi:

Dobry schemat wygląda tak:

Przykład: certyfikaty TLS

Nie potrzebujemy pracownika, który raz w miesiącu otworzy kalendarz i sprawdzi datę ważności certyfikatu. Można ją pobrać automatycznie:

echo | openssl s_client \
  -servername example.com \
  -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

Jeszcze lepiej monitorować datę ważności w systemie monitoringu i generować alert odpowiednio wcześniej. Miesięczny review powinien wtedy sprawdzić przede wszystkim, czy wszystkie ważne endpointy są monitorowane, czy pojawiły się certyfikaty wymagające działania i czy mechanizm automatycznego odnowienia nadal działa.

Jak udokumentować wykonanie przeglądu?

Nie potrzebujemy 20-stronicowego raportu. W wielu firmach wystarczy jeden cykliczny ticket. Na przykład:

Monthly Infrastructure Review - wrzesień 2026

[OK] Monitoring i trendy
[OK] Backup
[OK] Capacity
[OK] Aktualizacje
[!]  Konta i uprawnienia
[OK] Certyfikaty
[OK] Sieć
[!]  Dokumentacja
[OK] Koszty

Do wykonania:

IT-1842 - usunąć konto byłego kontraktora
IT-1843 - zwiększyć storage PBS przed listopadem
IT-1844 - zaktualizować diagram VLAN

I to wystarczy. Celem checklisty nie jest produkowanie dokumentacji. Celem jest znajdowanie rzeczy wymagających działania.

Dlaczego takie checklisty przestają działać?

Najgorszy wariant wygląda tak:

Jak wygląda taki przegląd w PRO-Admin?

W ramach stałej administracji nie ograniczamy się do reagowania na zgłoszenia użytkowników. W zależności od zakresu współpracy analizujemy również stan i trendy infrastruktury. Może to obejmować:

Celem nie jest generowanie kolejnego raportu, którego nikt nie przeczyta. Jeżeli wykrywamy problem, powinien powstać konkretny wynik, na przykład:

To są informacje, na podstawie których można działać.

FAQ - comiesięczna checklista utrzymania IT

Podsumowanie

Dobra administracja IT nie polega na ciągłym naprawianiu awarii. Polega również na tym, żeby część z nich nigdy nie zdążyła się wydarzyć. Dlatego nawet wtedy, gdy infrastruktura działa poprawnie, warto regularnie sprawdzać:

Nie wszystko raz w miesiącu. Część tych elementów powinna być monitorowana 24/7. Miesięczny przegląd jest warstwą wyżej. Pozwala zatrzymać się na chwilę i odpowiedzieć na pytanie:

Zielony dashboard odpowiada tylko na pierwszą część tego pytania. Dobry administrator powinien znać odpowiedź również na drugą.