Close

Poznaj Jira Service Management i inne zaawansowane narzędzia podczas wydarzenia Atlassian przedstawia: ITSM o wysokiej dynamice.

Zarejestruj się bezpłatnie

Chcesz wdrożyć proces ITSM o wysokiej dynamice?

Przewodnik po bazach danych zarządzania konfiguracją (CMDB)

Według ITIL 4 baza danych zarządzania konfiguracją (CMDB) „służy do przechowywania rekordów konfiguracji przez cały ich cykl życia i… utrzymywania relacji między (nimi).”

Innymi słowy, CMDB przechowuje informacje o konfiguracji elementów w organizacji, w tym sprzętu, oprogramowania, systemów, obiektów, a niekiedy personelu. Zdaniem organizacji IT jest określenie, które elementy powinny być śledzone i jak to zrobić. Te dane konfiguracyjne mogą obejmować relacje i współzależności między elementami, historię zmian w każdym elemencie oraz klasę i atrybuty — takie jak typ, właściciel i znaczenie — dla każdego elementu.

W obrębie CMDB te śledzone elementy są znane jako elementy konfiguracji (CI). Zgodnie z definicją ITIL 4, CI są „dowolnymi elementami, którymi należy zarządzać w celu świadczenia usługi IT”.

Celem CMDB jest dostarczenie organizacji informacji potrzebnych do podejmowania lepszych decyzji biznesowych i prowadzenia wydajnych procesów ITSM. Centralizując wszystkie informacje o konfiguracji, liderzy mogą lepiej zrozumieć krytyczne CI i ich relacje. CMDB są ważne w analizie wpływu, analizie przyczyn źródłowych, zgodności z prawem, zarządzaniu incydentami i zarządzaniuzmianami.

Zarządzanie zasobami IT (ITAM) a zarządzanie konfiguracją

Teraz, kiedy mówimy o zasobach i CI, zarządzanie zasobami IT (ITAM) i zarządzaniu konfiguracją, łatwo pomylić te pojęcia. Na pierwszy rzut oka wydaje się, że terminy są wymienne, ale prawda jest taka, że mogą zajmować się niektórymi z tych samych elementów firmy, jednak dotyczą różnych aspektów tych elementów.

Jaka jest zatem różnica między tymi praktykami? Użyjmy samochodu jako przykładu, ponieważ może to być zarówno składnik aktywów (coś o wartości finansowej dla firmy), jak i CI (dynamiczny element ważny dla usług organizacji).

Istnieją różne rozważania dotyczące tego samochodu w ramach różnych praktyk:

Rozważania ITAM

Zagadnienia dotyczące zarządzania konfiguracją

  • Kiedy kupiono samochód?
  • Od którego dilera?
  • Jaka była cena?
  • Jaka jest marka, model, i wykończenie?
  • Jaka jest amortyzacja?
  • Co obejmuje gwarancja?
  • Jaki rodzaj oleju jest używany?
  • Jak często sprawdzany jest olej?
  • Ile pozostało kilometrów do następnej wymiany oleju?
  • Jaka jest konfiguracja silnika?
    • Czy został zmodyfikowany?

Teraz przeanalizujmy to, że nie każdy zasób jest również CI. W przypadku niektórych firm sensowne może być śledzenie zasobów, które nie mają konfiguracji i zależności, które czynią je cennymi do śledzenia jako CIS. Na przykład firma energetyczna może śledzić poszczególne słupy energetyczne jako aktywa. Mają wartość finansową dla organizacji, a wiedza, kiedy są uszkodzone, zastąpione itp., może być warta śledzenia w ramach zarządzanie zasobami.

Jednak jako CI słup energetyczny może nie mieć sensu. Nie ma sieci współzależności do śledzenia. Nie ma konfiguracji, kiedy mówimy o kawałku drewna. Próba wprowadzenia słupów energetycznych jako CI w CMDB może nie wprowadzić do systemu wystarczającej wartości, aby uzasadnić czas i wysiłek.

Charakterystyka CMDB

Rozumiemy więc, jak działa CMDB, jej rolę w zarządzaniu konfiguracją oraz jak odnosi się do zarządzanie zasobami i różni się od niego. Ale jak wygląda funkcjonalność CMDB na bardziej praktycznym poziomie?

Podstawowe cechy funkcjonalne CMDB to:

Płynnie działające pulpity nawigacyjne ze wkaźnikami CI i analizami ułatwiające śledzenie stanu CI, ich relacji, wpływu zmian, wzorców prowadzących do incydentów lub problemów oraz kosztów — wyrażonych jako pieniądze i zasoby — budowania i utrzymania każdej usługi w organizacji.

Funkcje zgodności zapewniające szczegółową dokumentację i wgląd audytorom nie tylko w aktualny stan CI, ale także ich historyczne zmiany, kontrole i bilanse, incydenty, itp.

Tworzenie CI i terminowe wypełnianie ich danych, obsługiwane przez trzy różne metody: ręczne wprowadzanie, integracje (oparte na interfejsie API, SCCM) i narzędzia wykrywania, które przeprowadzają automatyczne skanowanie wszystkich adresów IP w sieci organizacji w celu skutecznego zbierania informacji o oprogramowaniu i sprzęcie gromadzenie inwentaryzacji każdego fizycznego i wirtualnego urządzenia w firmie.

Obsługa połączonych zbiorów danych, w tym normalizacji i uzgadniania CI i ich danych.

Mapowanie usług IT (zazwyczaj graficzna ilustracja relacji i zależności).

Kontrole dostępu umożliwiające przekazywanie różnych poziomów dostępu różnym osobom lub zespołom w razie potrzeby oraz śledzenie zmian z powrotem do ich źródła w przypadku pytań lub incydentów.

Korzyści z CMDB

Podstawowymi problemami rozwiązywanymi przez CMDB są odizolowane dane i nieaktualne informacje. Przed wdrożeniem CMDB, większość organizacji ma dane rozproszone po różnych systemach z różnymi właścicielami, co utrudnia zobaczenie z lotu ptaka wszystkich CI i ich współzależności, jeszcze bardziej utrudniając zrozumienie, które informacje są, a które nie są aktualne.

Uniemożliwia to zespołom zrozumienie ważnego kontekstu przy podejmowaniu decyzji, które mogą mieć wpływ na ocenę ryzyka i raportowanie, utrudniać podejmowanie decyzji, spowodować powolne rozwiązywanie problemów, i ostatecznie kosztować firmę zarówno pod względem finansowym, jak i reputacji.

Na przykład powiedzmy, że dane CI A są przechowywane w jednym dziale, a CI B w innym. Prawidłowe funkcjonowanie CI B zależy od CI A. Ale kiedy dział CI A decyduje się przenieść go do trybu offline w związku z przerwą techniczną, nie ma wglądu we wpływ, jaki wywiera na CI B.

W najlepszym wypadku może to spowodować zamieszanie między zespołami. W najgorszym, może przekształcić się w poważny incydent. A wszystkim, co jest potrzebne, aby uniknąć tego scenariusza, jest dobra CMDB.

Forrester identyfikuje trzy przypadki użycia, w których CMDB jest dziś niezwykle ważna:

Planowanie

Menedżerowie technologii potrzebują danych CMDB do planowania, zarówno na wysokim poziomie z architekturą firmy i zarządzaniem ofertą, jak i na bardziej szczegółowym poziomie z zarządzaniem zasobami i wydajnością.

Księgowość

Dział finansowy IT wymaga ewidencji aplikacji lub kodów usług w celu alokacji wyciągów rozliczeniowych i właściwego zarządzania finansami biznesowymi.

Operacje

CMDB usprawnia szereg podstawowych praktyk ITSM, w tym zarządzanie zmianami, zarządzanie incydentami, i zarządzanie problemami.

W zarządzaniu zmianami CMDB może poprawić ocenę ryzyka, przewidując, którzy użytkownicy, systemy, i inne CIS mogą mieć wpływ. W branżach regulowanych może również pomóc w przestrzeganiu przepisów, pomagając zespołom zarządzać kontrolami i zapewniać przejrzystą ścieżkę audytu.

W zarządzaniu incydentami, CMDB może pomóc zidentyfikować zmiany, które doprowadziły do incydentu i uzyskać szybsze rozwiązanie. Zapisy incydentów mogą być powiązane z ich odpowiednimi CI, pomagając zespołom śledzić incydenty w czasie wraz z zasobami, na które mają wpływ.

W zarządzaniu problemami CMDB może pomóc w analizie przyczyn źródłowych, szybciej doprowadzając zespoły do sedna problemu. Może również wspierać aktywne zarządzanie problemami, pomagając zespołom zidentyfikować zasoby wymagające aktualizacji w celu zmniejszenia kosztów usług i nieplanowanych przestojów.

Ostatecznie CMDB powinna zmniejszyć złożoność, zapobiegać błędom, zwiększyć bezpieczeństwo, i wspierać płynne działanie praktyk ITSM, takich jak zarządzanie zmianami i incydentami.

Wyzwania związane z CMDB

Statystyki branżowe mówią nam, że tylko 25% organizacji uzyskuje znaczącą wartość z inwestycji w CMDB. Tak wysoki wskaźnik niepowodzeń owiał technologię dość problematyczną reputacją.

Dobrą wiadomością jest to, że przyczyny niepowodzenia można zapobiec i dzielą się na sześć przewidywalnych kategorii:

Kultura

Jak wszystko w organizacji, kultura i zaangażowanie zespołu są jednym z najważniejszych czynników wpływających na sukces nowych technologii i procesów. W niedawnym badaniu przeprowadzonym przez Harvard Business Review93% kadry kierowniczej stwierdziło, że największym wyzwaniem w transformacji cyfrowej opartej na danych są ludzie i proces. Dotyczy to projektów CMDB.

Trafność

CMDB są często nazywane „jedynym źródłem prawdy”, co czasami może prowadzić do tego, że organizacje próbują zbić wszystkie swoje dane w jedno, nie zastanawiając się nad przypadkami użycia odpowiednimi dla ich potrzeb.

Podobnie jak w przypadku każdego repozytorium danych, CMDB powinna zawierać skoncentrowane, przydatne dane obsługujące wewnętrzne procesy, takie jak zarządzanie zmianami. Używana CMDB musi mieć jasno określony cel wartości, właściciela i sposób aktualizacji danych odzwierciedlający wszystkie zmiany.

Centralizacja

Kiedy mówimy, że CMDB jest scentralizowanym miejscem do przeglądania danych aktywów, nie oznacza to, że wszystkie dane aktywów musi pozostawać wyłącznie w CMDB. To powszechne błędne przekonanie może spowodować wiele pracy dla zespołów, które próbują przenieść wszystkie swoje dane do tego „jedynego źródła prawdy”. Najlepszą praktyką jest tutaj łączenie danych z innych narzędzi, tak aby najbardziej odpowiednie narzędzie było używane do obsługi każdego przypadku użycia.

Na przykład często bardziej sensowne jest przechowywanie danych finansowych w narzędziu IT do zarządzania finansami (ITFM) i informacji o licencji oprogramowania za pomocą narzędzia do zarządzanie zasobami oprogramowania (SAM). Dane mogą być importowane i dublowane w CMDB, nawet jeśli nie stanowi ich podstawowej pamięci masowej.

Dokładność

Wiele organizacji ma trudności z opracowaniem i utrzymaniem prawidłowej CMDB. Najczęstszymi problemami są narzędzia wykrywania działające zbyt rzadko, brak reguł automatyzacji, lub poleganie na ręcznych wpisach. Typową odpowiedzią na te wyzwania jest wykrywanie oparte na wydarzeniach, wzmacniające tradycyjne oddolne wykrywanie.

Dla nieznających tych terminów, oddolne wykrywanie ma miejsce, gdy aktywa są mapowane, zaczynając od infrastruktury i rozgałęziając się w CIS zorientowane na klienta. Wykrywanie oparte na zdarzeniach ma miejsce, gdy się dzieje coś — zdarzenie w systemie, problem itp. — powodującego komunikację między systemami. Następnie, na podstawie tego zdarzenia, system mapuje powiązane CI i ich połączenia.

Teraz nie wszystkie CI są możliwe do wykrycia. Na przykład zespół może chcieć mapować monitory w CMDB. Ponieważ monitory nie są możliwe do wykrycia przez zautomatyzowany system, należy je ręcznie wprowadzić za pomocą arkusza kalkulacyjnego (lub podobnej metody).

Kluczem do dokładności jest wykorzystanie mocy zarówno oddolnego wykrywania, jak i wykrywania opartego na zdarzeniach, aby uzyskać jak najwyraźniejszy obraz zasobów i ich połączeń.

Proces

W niektórych organizacjach panuje przekonanie, że CMDB służą do modelowania starszej infrastruktury i oprogramowania, zamiast nowego stosu chmury i infrastruktury zdefiniowanej programowo oraz hostowanych na nich nowoczesnych przepływów pracy.

Prawda jest taka, że nie powinniśmy pozwolić, aby debata na temat semantyki powstrzymywała nas od zbadania prawdziwej wartości śledzenia naszych CI — starszych i nowszych — w narzędziu dającym nam kompleksowy obraz naszych ekosystemów technicznych.

narzędzia

Wybór odpowiedniego narzędzia jest najważniejszy, aby uniknąć wspomnianych powyżej niefortunnych statystyk niepowodzeń. Niektóre narzędzia CMDB to niewiele więcej niż repozytoria zasobów — struktury danych naprawione w starszej infrastrukturze fizycznej i narzędziach do wykrywania, które powoli reagują na wszelkie zmiany. Aby odnieść sukces dzięki CMDB, potrzebne jest takie, który uwzględnia nowe typy aktywów i jest zdolne do szybkiej zmiany.

Wybór, czym zarządzać w CMDB

Nie ma jednej właściwej dla wszystkich odpowiedzi, którymi CI należy zarządzać w swojej CMDB. Przypadki użycia i cele każdej organizacji powinny określać poziom szerokości i głębokości, który ma sens dla ich konfiguracji CMDB. Ogólnie rzecz biorąc, sensowne jest rozpoczęcie wysokiego poziomu i prawidłowe korzystanie z usług, a następnie zastosowanie podejścia szerszego lub głębszego tylko tam, gdzie jest to potrzebne, aby osiągnąć swoje cele organizacyjne.

Uwzględniając to, CI mogą być szeroko pogrupowane jako obiekty techniczne lub nietechniczne.

Obiekty techniczne obejmują usługi biznesowe, usługi techniczne, aplikacje, oprogramowanie, bazy danych, kontenery, maszyny wirtualne, systemy operacyjne, sprzęt, sieci, porty itp.

Obiekty nietechniczne mogą być również modelowane w CMDB, jeśli mają być reprezentowane jako zależne lub znajdujące się pod wpływem innych zasobów w mapowaniu usług IT. Obiekty nietechniczne mogą obejmować użytkowników, klientów, organizacje, lokalizacje, umowy serwisowe, dokumenty itp.

Ponadto przy projektowaniu modelu CMDB powinny być brane pod uwagę usługi w chmurze. Obie oferty SaaS (np. aplikacje Google, Dropbox, Salesforce itp.) i oferty IaaS (np. DigitalOcean, Linode, Rackspace, Amazon Web Services itp.) mogą być w razie potrzeby reprezentowane jako CI.

W przeciwieństwie do starszych CMDB, Insight for Jira Service Management oferuje elastyczną i otwartą strukturę danych umożliwiającą zarządzanie wszystkimi zasobami.