CMDB konfiguracja
od zera — kompletny przewodnik

Jeśli dziś ktoś Cię pytałby „Ile licencji SQL Server macie? Czy serwer APP-01 komunikuje się z bazą PROD-DB? Gdzie jest switch sieciowy do datacenter?", odpowiadałbyś szukając w emailach, Excelu i na kartach rozłożonych biurach? Wtedy CMDB (Configuration Management Database) to dla Ciebie. CMDB to baza danych wszystkich zasobów IT w organizacji — serwerów, laptopów, oprogramowania, licencji i relacji między nimi. W tym artykule nauczę Ciebie jak zbudować CMDB od zera: planowanie struktury, import danych, konfiguracja relacji i integracja z helpdeskiem.

Czym jest CMDB i dlaczego 78% firm nie ma go skonfigurowanego?

CMDB to źródło prawdy (single source of truth) dla całej infrastruktury IT. Zawiera wszystko co masz:

• Hardware: serwery, laptopy, switche, routery, drukarki, storage
• Software: systemy operacyjne, aplikacje, middleware, bazy danych
• Licencje: kto ma uprawnienia, liczba dostępnych licencji, data wygaśnięcia
• Umowy: serwis, gwarancja, SLA sprzętu
• Relacje: serwer A obsługuje aplikację B, która korzysta z bazy C, która stoi na sprzęcie D

Pytanie: dlaczego 78% firm nie ma CMDB?

• Myśl, że to za trudne: „Zbudować CMDB to projekt na 6 miesięcy". Prawda: projekt na 2–4 tygodnie przy odpowiednim podejściu.
• Brak danych do importu: „Nie mamy, skąd wziąć dane". Excel rozpiętego na biurka — są, trzeba tylko zebrać.
• Strachy przed zmianą: „Zmiana w CMDB = zmiana w helpdesku = chaos". Bez zmiany = chaos jest już teraz.
• Inertia: IT pracuje ad-hoc, bez procesu. CMDB wymusza proces — a to oznacza zmianę nawyków.

Typy CI (Configuration Items) — co inwentaryzować?

Każdy element w CMDB to CI (Configuration Item). Muszysz zdecydować które CI są dla Ciebie ważne.

CI obowiązkowe (Tier 1) — zacznij od tego

• Serwery (Physical & Virtual)

  Każdy serwer Windows, Linux, fizyczny czy VM. Atrybuty: hostname, IP, OS, RAM, CPU, data zlecenia, właściciel biznesowy, SLA sprzętu.

• Aplikacje biznesowe

  ERP, CRM, HR, email, accounting systems. Atrybuty: nazwa, wersja, producent, numer licencji, data wsparcia, właściciel procesu, SLA aplikacji.

• Bazy danych

  SQL Server, PostgreSQL, Oracle, MongoDB. Atrybuty: DBMS typ, wersja, baza danych (jakie bazy?), backup SLA, recovery time, właściciel danych.

• Urządzenia sieciowe

  Switche, routery, firewall, load balancers. Atrybuty: model, IP, lokalizacja, SLA dostępności, właściciel.

CI drugie priority (Tier 2) — dodaj po Tier 1

• Laptopy i workstations
• Licencje (oprogramowanie)
• Umowy serwisowe
• Storage (SAN, NAS)
• Backup systems

CI trzecie priority (Tier 3) — jeśli jest czas

• Drukarki
• Monitory
• Klawiatury, myszki
• Zespoły (teams/departments — dla relacji biznesowych)

Relacje między CI — jak mapować zależności?

CI bez relacji to liczby w bazie. CI z relacjami = mapa infrastruktury. Relacja to związek między dwiema jednostkami: A wspiera B, A zależy od B, A komunikuje się z B.

Przykładowe relacje (dla typowego stacku IT)

Aplikacja ERP (CI)
  ↓ runs on
Serwer APP-01 (CI)
  ↓ connects to
SQL Server 2019 (DBMS) na SRV-DB-01 (CI)
  ↓ backup to
NAS Storage (CI)

Użytkownik (CI)
  ↓ uses
Laptop Dell XPS (CI)
  ↓ needs
WiFi 5GHz (Infrastructure CI)
  ↓ on
Switch SW-01 (CI)
  ↓ powered by
UPS Unit-A (CI)
    

Mapa pokazuje: jeśli SRV-DB-01 pada → pada ERP → pada kilkadziesiąt użytkowników. Dlatego trzeba monitoring i szybki SLA naprawy na DB.

Import automatyczny — discovery z sieci

Zamiast ręcznie wprowadzać każdy serwer — system automatycznie skanuje sieć i znajduje urządzenia. To discovery.

Metody discovery

• Network Scan (SNMP, WMI): System pinga sieć 192.168.0.0/24, zbiera urządzenia aktywne (serwery, switche, drukarki) — ok. 60–70% CI.
• Agent-based Discovery: Zainstalować agenta na każdym serwerze Windows/Linux — daje dokładne dane OS, aplikacji, licencji — ok. 80–90% CI.
• API Integration: Połączyć ManageEngine z vSphere (VMware), Hyper-V, AWS — automatycznie ściągać dane VM i instancji — ok. 95% CI dla VM.

Krok po kroku: Discovery w Endpoint Central (lub ManageEngine SDP Enterprise)

1. Admin → Discovery → New Discovery Task
2. Wybierz metodę: Network Scan vs Agent-based
3. Podaj zakres: sieć 192.168.0.0/24 lub wszystkie serwery z Active Directory
4. Uruchom discovery — system skanuje, zbiera dane, importuje do CMDB
5. Validate: przejrzyj zaproponowane CI, usuń duplikaty, uzupełnij brakujące atrybuty ręcznie

CMDB w ManageEngine SDP — konfiguracja krok po kroku

ServiceDesk Plus Professional i wyżej zawierają CMDB. Tutaj konfiguracja bazy.

Krok 1: Definiowanie typów CI (CI Class)

1. Admin → CMDB → CI Class → New CI Class
2. Podaj nazwę (np. „Server", „Database", „Application")
3. Dodaj atrybuty dla każdego typu:
   • Server: hostname, IP, OS, RAM, CPU, location, owner, SLA
   • Database: DBMS type, version, databases (lista), backup time, RTO/RPO
   • Application: name, version, vendor, license key, support date, owner
4. Zapisz — typ CI gotowy do użytku

Krok 2: Dodawanie CI (konfiguracja elementów)

1. CMDB → Create → New CI
2. Wybierz CI Class (np. Server)
3. Wypełnij dane:
   • Name: PROD-SQL-01
   • IP: 192.168.1.50
   • OS: Windows Server 2019
   • RAM: 32 GB
   • CPU: 16 cores
   • Location: Datacenter-1, Rack-5
   • Owner: Database Team
4. Zapisz — CI w bazie

Krok 3: Definiowanie relacji między CI

1. CMDB → Relationships → New Relationship
2. Relacja 1: App ERP → runs on → Server PROD-APP-01
3. Relacja 2: Server PROD-APP-01 → connects to → Database PROD-SQL-01
4. Relacja 3: Database PROD-SQL-01 → backed up to → NAS Storage

Integracja CMDB z helpdeskiem — praktyczne zastosowanie

CMDB bez helpdesku = archiwum. CMDB powiązana z helpdeskiem = narzędzie które oszczędza czas.

Scenariusz 1: Technik otwiera zgłoszenie

Technik: „Serwer PROD-SQL-01 nie odpowiada". W formularzu zgłoszenia:

1. Automated lookup: system wyszukuje CI „PROD-SQL-01" w CMDB
2. Zobacza dane: Owner = Database Team, SLA = 4h, Database = PROD-ERP.db (ważna baza!), zależy od niej: 500 użytkowników
3. Priorytetu automatycznie ustawiony na KRYTYCZNY — bo zależy od tego 500 osób
4. Technik od razu wie kim zadzwonić (Database Team) i jakie są oczekiwania (4 godziny do naprawy)

Scenariusz 2: Raportowanie wpływu awarii

Manager pyta: „Jak długa była awaria ERP wczoraj?" System automatycznie pokazuje:

• ERP był down 45 minut (12:00–12:45)
• Przyczyną: brak dysku na PROD-APP-01
• Zależy od ERP: 500 użytkowników (50 godzin × 500 użytkowników = 25 000 godzin pracy stracone)
• Koszt: ~5 PLN × 25 000 = 125 000 PLN strat biznesowych

Raport umotywowuje inwestycję w lepszą infrastrukturę — bo teraz IT pokazuje biznesowy impact awarii.