ServiceNow CMDB i CSDM temelji koji ne trunu

Kako da ServiceNow CMDB ostane tačan tokom vremena?

ServiceNow CMDB održavate tačnim tako što ga tretirate kao upravljani proizvod, a ne kao jednokratan uvoz: svaka konfiguraciona stavka (Configuration Item, CI) ima imenovanog vlasnika, svaku CI klasu napaja autoritativni izvor usaglašen kroz Identification and Reconciliation Engine (IRE), model podataka prati Common Service Data Model (CSDM), a zdravlje se kontinuirano meri po kompletnosti, ispravnosti i usaglašenosti. CMDB istrune u trenutku kada podaci sleću bez vlasništva, bez usaglašavanja ili bez modela na koji bi se zakačili. Rešenje je strukturno, a ne herojsko.

Prvo kratka definicija: CMDB (Configuration Management Database) je sistem zapisa za vaše IT komponente i njihove međusobne odnose. CI je bilo koja praćena stvar u njemu — server, aplikacija, servis. CSDM je ServiceNow-ova propisana šema koja određuje kako te CI-jeve i servise treba modelovati da bi podaci ostali upotrebljivi u ITSM, ITOM, SecOps i šire.

Zašto CMDB-ovi propadaju?

Većina CMDB-ova ne pada na go-live-u. Padaju u devetom mesecu. Ponavljajući uzroci:

• Bez vlasništva. CI bez odgovornog vlasnika je CI koji niko ne ažurira kada se promeni stvarnost koja stoji iza njega. Napušteni CI-jevi su pojedinačno najveći izvor zastarelosti.
• Neusaglašeni izvori. Dva alata pišu u isti CI sa različitim vrednostima i bez pravila koja odlučuju ko pobeđuje. Zapis treperi između istina i poverenje se urušava.
• Širenje obima. Timovi uvoze sve što mogu da otkriju umesto onoga što biznis zaista koristi. CMDB se naduvava, odnos signala i šuma opada, i niko ne može da pronađe CI-jeve koji su važni.
• Zastareli podaci. Rasporedi otkrivanja (Discovery) prestaju, integracije se tiho kvare, dekomisionirani hardver se zadržava. Bez signala o svežini, zastareli i tačni zapisi izgledaju identično.
• Bez discipline modela. CI-jevi sleću u pogrešne klase, odnosi su nedosledni, a mapiranje servisa se nikada ne materijalizuje — pa CMDB može da opiše kutije, ali ne i servise do kojih je ljudima stalo.

Svaki od ovih problema je rupa u upravljanju prerušena u tehnički kostim.

Šta je CSDM i kako ga treba usvojiti?

CSDM daje CMDB-u oblik vredan održavanja. Zamislite ga kao četiri ugnežđena domena koja usvajate redom — i odolite porivu da preskačete unapred:

1. Foundation. Bazni podaci koje sve ostalo referencira: kompanije, lokacije, korisnici, grupe i ključne strukture podrške. Ništa nizvodno nije pouzdano ako je Foundation pogrešan.
2. Design. Mesto gde se poslovni i tehnički servisi definišu kao Service Offerings i Application Services pre nego što se mapiraju — sloj namere.
3. Manage Technical Services. Tehnička stvarnost: application services, njihovi hosting CI-jevi i odnosi koje popunjavaju Discovery i mapiranje servisa.
4. Manage Business Services / Sell-Consume. Servisi okrenuti biznisu i način na koji se nude i koriste, povezujući tehnički pejzaž sa ishodima koje biznis prepoznaje.

Dokazani obrazac usvajanja je crawl, walk, run:

• Crawl — uredite Foundation i mali skup dobro modelovanih CI-jeva. Izaberite jedan ili dva stvarna servisa od početka do kraja. Odolite ispijanju okeana.
• Walk — proširite Design i Manage Technical Services na veći deo pejzaža, oslonite se na Discovery i Service Graph Connectors i postavite izveštavanje o zdravlju.
• Run — sazrite do mapiranja poslovnih servisa, ciklusa sertifikacije i automatizacije vođene CMDB-om (promene, incidenti, SecOps, upravljanje softverskim sredstvima).

Zrelost je ovde sekvencijalna. Mapa servisa nivoa „run“ izgrađena na Foundation-u kvaliteta „crawl“ nasleđuje svaku manu ispod sebe.

Kako da podaci ostanu dosledni preko više izvora?

To je posao IRE-a. Identification and Reconciliation Engine stoji između svakog dolaznog toka podataka i CMDB-a. Radi dve stvari:

• Identifikacija — uparuje dolazne sadržaje sa postojećim CI-jevima koristeći pravila identifikacije, kako ne biste pravili duplikate istog servera svaki put kada nešto piše u njega.
• Usaglašavanje (Reconciliation) — sprovodi koji izvor sme da ažurira koje atribute, tako da Data Source od zapisa uvek pobeđuje nad manje autoritativnim.

Disciplina koja čini da IRE radi jeste deklarisanje autoritativnih izvora po CI klasi i po atributu. Odlučite, eksplicitno, da (na primer) Discovery poseduje atribute operativnog sistema, dok integracija sa nabavkom poseduje polja vlasništva i troškova. Zapišite te odluke i kodirajte ih kao pravila usaglašavanja. Bez toga, svaka integracija se bori za ista polja i zapis se nikada ne smiri.

Discovery vs. integracije vs. Service Graph Connectors

Ove tri metode popunjavanja nisu zamenljive; birajte po domenu podataka:

| Metoda | Najbolja za | Kompromis | | --- | --- | --- | | Discovery | On-prem i cloud infrastrukturu koju možete direktno ispitivati (serveri, mreža, OS, pokrenuti procesi) | Zahteva MID Server-e, kredencijale i mrežni domet; skeniranje bez agenta ima slepe tačke | | Integracije | Autoritativne eksterne sisteme zapisa (HR, nabavka, sredstva, cloud naplata) | Kvalitet je dobar koliko i izvor; zahteva IRE pravila da bi se izbegle borbe za atribute | | Service Graph Connectors | Sertifikovan, podržan unos iz uobičajenih alata trećih strana, napravljen da se učita kroz IRE ispravno | Ograničen na dostupne konektore; i dalje zahteva odluke o izvoru istine |

Praktično pravilo: otkrijte ono što možete ispitati, integrišite ono što ne možete, i pretpostavite Service Graph Connector ručno pisanoj integraciji kad god postoji sertifikovan — dolazi sa već urađenim IRE povezivanjem.

Kako da izmerite da li je CMDB zdrav?

ServiceNow-ovi CMDB Health dashboard-ovi ocenjuju pejzaž po tri ose, i treba da ih pregledate po fiksnom ritmu:

• Kompletnost — da li su obavezni atributi i odnosi popunjeni? Nedostajuća obavezna polja i CI-jevi bez odnosa su crvene zastavice.
• Ispravnost — da li vrednosti izgledaju validno i da li postoje duplikati koje je IRE propustio?
• Usaglašenost — da li CI-jevi odgovaraju zahtevanim klasama, imenovanju i CSDM rasporedu?

Uparite dashboard-ove sa sertifikacijom podataka: zakazani zadaci koji traže od pravog vlasnika da potvrdi da je skup CI-jeva i dalje tačan, gde se izostanak odgovora tretira kao nalaz, a ne kao tišina. Sertifikacija je način na koji vlasništvo pretvarate iz oznake u ponavljajuću obavezu.

Kratka kontrolna lista zrelosti CMDB-a

Radite od vrha ka dnu — svaka stavka pretpostavlja da su one iznad nje tačne:

• [ ] Svaka CI klasa ima imenovanog, odgovornog vlasnika CI-ja (osobu ili grupu, ne „IT“).
• [ ] CSDM Foundation podaci (kompanije, lokacije, korisnici, grupe) su tačni i referencirani svuda.
• [ ] Svaka CI klasa i ključni atribut imaju deklarisan autoritativni izvor.
• [ ] IRE pravila identifikacije i usaglašavanja odgovaraju tim odlukama o izvorima — nema neusaglašenih upisivača.
• [ ] Popunjavanje koristi pravi alat po domenu: Discovery, integracija ili Service Graph Connector.
• [ ] Bar jedan poslovni servis je mapiran od početka do kraja kroz CSDM Design i Manage Technical Services.
• [ ] CMDB Health dashboard-ovi se pregledaju po fiksnom ritmu i nalazi se dodeljuju, a ne samo posmatraju.
• [ ] Kampanje sertifikacije podataka se odvijaju po rasporedu uz potvrdu vlasnika.
• [ ] Lagani odbor za upravljanje poseduje odluke o obimu i kaže ne CI-jevima iz taštine.

Ako možete iskreno da čekirate prvih pet, imate CMDB koji odoleva propadanju. Ostalo je način na koji ga dovodite do zrelosti.

FAQ

Koja je razlika između CMDB-a i CSDM-a? CMDB je baza podataka koja čuva vaše CI-jeve i odnose. CSDM je propisani model podataka — šema — koji određuje kako organizovati servise i CI-jeve unutar nje, tako da podaci ostanu dosledni i upotrebljivi preko ServiceNow proizvoda.

Da li mi je potreban Discovery da bih imao dobar CMDB? Ne. Discovery je odličan za infrastrukturu koju možete direktno ispitivati, ali snažan CMDB se takođe oslanja na integracije iz autoritativnih sistema zapisa i na sertifikovane Service Graph Connectors. Nepregovaračka stavka je usaglašavanje svih njih kroz IRE sa jasnim pravilima o izvoru istine.

Gde treba da počnemo sa CSDM-om? Počnite sa Foundation domenom i jednim, potpuno modelovanim servisom. Uredite vlasništvo, pravila identifikacije i Foundation podatke na malom obimu pre širenja. Sekvenca crawl-walk-run postoji upravo zato da ne biste gradili napredne mape servisa na slabim temeljima.

Koliko često treba da pregledamo zdravlje CMDB-a? Tretirajte ga kao operativnu metriku, a ne kao reviziju. Pregledajte dashboard-ove kompletnosti, ispravnosti i usaglašenosti po redovnom ritmu, dodelite svaki nalaz odgovornom vlasniku CI-ja i sprovodite kampanje sertifikacije podataka kako bi se tačnost potvrđivala, a ne pretpostavljala.

---

CMDB koji ne trune je proizvod nekoliko neglamuroznih navika održavanih tokom vremena: jasnog vlasništva, jednog modela usvojenog redom, usaglašenih izvora i zdravlja u koje zaista gledate. TechRevati donosi dve decenije enterprise i ServiceNow prakse — uključujući CMDB, CSDM i upravljanje servisima usklađeno sa ITIL-om — timovima koji žele konfiguracionu bazu na čije odluke izgrađene povrh nje mogu da se oslone.