Wszystko, co musisz wiedzieć o rozpoczęciu pracy z Assets for Jira Service Management Data Center.
Jak zacząć korzystać z Assets for Jira Service Management Data Center
Ten przewodnik jest przeznaczony dla każdego, kto przystępuje do konfiguracji Assets for Jira Service Management Data Center. Narzędzie Assets umożliwia zespołom śledzenie ich zasobów, elementów konfiguracji i środków w celu uzyskania wglądu w krytyczne zależności między aplikacjami, usługami, podstawową infrastrukturą oraz innymi kluczowymi zasobami. Narzędzia Assets działają na bazie systemu Jira, pozwalając zespołom łatwo i szybko powiązać zasoby i elementy konfiguracji z wnioskami o usługi, incydentami, problemami, zmianami oraz innymi zgłoszeniami, aby uzyskać cenny kontekst.
Krok 2 — Zrozumienie struktury Zasobów
Ta część zawiera ogólny opis struktury bazy danych Zasobów.
Obiekty
Obiekty są rzeczywistymi zasobami / elementami konfiguracji. Można je połączyć ze zgłoszeniami w Jira, zatem za każdym razem, gdy pojawia się zgłoszenie, od razu zyskuje ono szerszy kontekst.
Można je również połączyć ze sobą przy użyciu odniesień do obiektów, odzwierciedlając w ten sposób zależności między obiektami.
Schematy obiektów
Schemat obiektów to rzeczywista baza danych zarządzania konfiguracjami (CMDB), która zawiera Twoje typy obiektów (więcej na ten temat w dalszej części) oraz obiekty. W Assets można utworzyć szereg schematów obiektów, co przydaje się z wielu powodów:
- Podział danych na mniejsze części ułatwia ich audyt i zapewnianie dokładności.
- Jeśli posiadasz dane wrażliwe, np. informacje o pracownikach, prościej będzie przechowywać wszystkie te dane razem w obrębie jednego schematu obiektów o ograniczonych uprawnieniach dostępu.
Wybierając sposób wprowadzania danych do Zasobów, należy wziąć pod uwagę sposób używania danych i osoby, które będą aktualizować dane, aby pogrupować je w logicznych schematach obiektów.
Assets (a w drodze rozszerzenia także Jira Service Management) nie zważa na to, do którego schematu obiektów zaliczone są poszczególne informacje. Widzi tylko jedną wielką pulę danych. Dzięki temu można w prosty sposób użyć wielu schematów obiektów w jednym przypadku użycia i tworzyć łącza między obiektami w różnych schematach obiektów.
Typy obiektów
Typy obiektów są częściami składowymi schematu i określają rodzaj obiektów, jakie zawiera dany schemat. Można je zdefiniować samodzielnie lub skorzystać z szablonu schematu obiektów zawierającego wstępnie wypełnione typy obiektów, które można dostosowywać. Typy obiektów pełnią funkcję kontenerów na rzeczywiste obiekty. Typy obiektów mogą być dowolne, ponieważ Assets jest narzędziem bardzo otwartym i elastycznym, jednak najczęściej spotykane typy obiektów to:
- Usługi biznesowe
- Hosty
- Laptopy
- Oprogramowanie
Nie muszą to być jednak zasoby IT. Wiele osób dodaje na przykład inne przydatne informacje, takie jak:
- Dostawcy
- Lokalizacje
- employees
- Priorytet biznesowy
Typy obiektów można porządkować w formie sensownego drzewa hierarchii. Takie drzewo służy głównie do nawigacji i poprawy czytelności. W tym samym celu można dodać również puste typy obiektów skonfigurowane tak, aby umożliwić dziedziczenie atrybutów, co ułatwi tworzenie typów obiektów.
Atrybuty typu obiektu
Atrybuty obiektów są typ, co definiuje konkretny typ obiektu. Każdy typ obiektu posiada własny zestaw atrybutów. Na przykład typ obiektu „laptopy” może posiadać takie atrybuty, jak model, numer seryjny, użytkownik, data wygaśnięcia gwarancji itp.
Wprowadzenie rzeczywistych wartości dla atrybutu pozwoli zdefiniować obiekt. Można to robić ręcznie lub automatycznie (patrz krok 4).
Wszystkie typy obiektów będą miały cztery obowiązkowe atrybuty:
- Imię i nazwisko
- Klucz
- Data utworzenia
- Data ostatniej aktualizacji
Ostatnie trzy z nich są ustawiane automatycznie. Każdy inny atrybut może zdefiniować administrator. Dzięki zastosowaniu atrybutu unikalnego klucza, nazwy poszczególnych obiektów nie muszą być unikalne.
Atrybuty mogą zawierać wiele różnych rodzajów danych, takich jak tekst, daty, liczby, adresy URL (doskonałe rozwiązanie do tworzenia połączeń z innymi magazynami danych lub umowami o świadczenie usług), użytkownicy Jira (świetnie sprawdzają się przy ustawianiu własności obiektów), statusy (na stanie, przypisany, wycofany itp.) oraz inne obiekty (więcej na ten temat w kolejnej części).
Odniesienia do obiektów
Konkretnie atrybutem obiektu do wywołania jest typ atrybutu „obiekt”. W ten sposób powstaje odniesienie do innych obiektów, co stanowi pierwszy etap tworzenia mapy zależności między obiektami.
Jeśli na przykład lokalizacja jest sama w sobie typem obiektu, wówczas każdy obiekt lokalizacji może odpowiadać lokalizacji jednego z biur firmy. Dzięki temu można szybko ustawić lokalizację każdego laptopa, na przykład wybierając opcję „Sztokholm”.
Odniesień do obiektów nie trzeba ustawiać ręcznie. Można je dodawać automatycznie za pomocą skanerów sieciowych, narzędzi importu, reguł automatyzacji itp. Więcej szczegółów na ten temat zawiera krok 4.
Tworzenie odniesień między obiektami ma dwie podstawowe zalety:
Podstawowa korzyść — zależności między obiektami można mapować. Można na przykład zmapować usługi biznesowe do różnych hostów, systemów operacyjnych oraz plików, od których są zależne. Taka mapa może być niezwykle przydatna, gdy chcemy zrozumieć wpływ zmian na inne procesy (na co może wpłynąć ewentualna zmiana tego systemu operacyjnego), a także poznać przyczyny incydentów i problemów. A dzięki możliwości połączenia poszczególnych obiektów ze zgłoszeniem Jira, z czasem powstaje wyczerpująca historia infrastruktury lub innych zasobów biznesowych, którą można wykorzystać podczas rozwiązywania zgłoszeń i problemów.
Dodatkowa korzyść — zarządzanie staje się łatwiejsze. Jeśli biuro zostanie przeniesione na przykład z Montrealu do Toronto, wystarczy jedynie zaktualizować obiekt Montreal. Nie trzeba zmieniać lokalizacji z Montrealu na Toronto dla każdego laptopa z osobna.
Dostępne są dwa rodzaje odniesień do obiektów:
- Odniesienia wychodzące to odniesienia bieżącego obiektu do innych obiektów.
- Odniesienia przychodzące to inne obiekty, które odnoszą się do bieżącego obiektu.
Odniesienia między obiektami można przeglądać za pomocą przeglądarki graficznej. Można w ten sposób sprawdzić rodzaje posiadanych odniesień (np. miejsce instalacji, właściciel, dostawca) oraz oznaczyć je kolorami w ustawieniach schematu obiektów.
Uprawnienia w narzędziu Zasoby
W narzędziu Assets są dostępne trzy rodzaje uprawnień:
- Uprawnienia globalne — w ustawieniach globalnych można wskazać osoby z uprawnieniami administracyjnymi w aplikacji Zasoby. Osoby przypisane do roli „Administrator Zasobów” mogą wykonywać wszystkie czynności w aplikacji Zasoby.
- Uprawnienia do schematu obiektów — w ustawieniach schematu obiektów można zdefiniować osoby posiadające uprawnienia administracyjne do konkretnego schematu obiektów, uprawnienia do aktualizacji danych schemat obiektów oraz uprawnienia wyłącznie do przeglądania danych.
- Uprawnienia do typu obiektu — czasami chcemy, aby klienci systemu Jira Service Management mogli wyświetlać tylko określone informacje należące do schematu obiektów, ale nie mieli dostępu do wyświetlania wszystkich danych w całym schemacie obiektów. W takim przypadku można użyć uprawnień do typu obiektu.
Krok 3 — Wybór danych do uwzględnienia
Każda instancja Zasobów będzie niepowtarzalna, ponieważ każda firma wymaga śledzenia innego rodzaju informacji. W Zasobach można zapisać dowolny wycinek informacji, którego poznanie i zrozumienie może przynieść korzyść Tobie i Twojej firmie.
Które konkretne zasoby i elementy konfiguracji należy uwzględnić, zależy od tego, co próbujesz zrobić. Instancja Assets do zarządzania zasobami magazynowymi będzie wyglądać zupełnie inaczej niż instancja używana do mapowania usług biznesowych i ich zależności, mająca na celu przyspieszenie wprowadzania zmian i rozwiązywania incydentów.
Zalecenia przy doborze danych do uwzględnienia:
Zdefiniuj problem
Większość narzędzi wdraża się w celu rozwiązania problemu, a Zasoby nie stanowią pod tym względem wyjątku. Być może incydenty nie są rozwiązywane wystarczająco szybko bądź zmiany w konkretnej usłudze często prowadzą do nieoczekiwanych rezultatów, ponieważ trudno dostrzec zależności między usługami.
Określ problem i na tej podstawie zdefiniuj wszystkie inne kwestie, od osób zaangażowanych po zasoby i informacje do uwzględnienia w bazie danych. Przyjrzyj się problemowi i postaraj się zrozumieć, jakich dodatkowych informacji będą potrzebowali pracownicy, aby go rozwiązać. Informacje te wyznaczą typy obiektów.
Dodanie zbyt dużej ilości informacji za jednym razem może utrudniać sprawdzanie dokładności. Spróbuj skoncentrować się tylko na jednym problemie naraz. Po rozwiązaniu pierwszego problemu można rozwijać narzędzie Assets, aby rozwiązać również inne problemy.
Zacznij od usług
W zastosowaniach związanych z zarządzaniem konfiguracjami zalecamy rozpoczęcie od usług powiązanych z problemem, który próbujesz rozwiązać. Usługi są dobrze zdefiniowane i stosunkowo łatwo przystąpić do dodawania różnych zasobów, od których zależy ich uruchomienie, a następnie kolejnych zasobów, od których zależne są te zasoby, i tak dalej. W końcu powstaje kompletny obraz każdej istotnej usługi wraz z jej zależnościami.
Musisz określić, jak głęboko chcesz sięgnąć. Pomyśl realistycznie, ilu szczegółów potrzebujesz, aby zrozumieć swoje usługi. Dla niektórych mapowanie konkretnych stojaków i przewodów będzie zbyt szczegółowe, a w przypadku innych może być konieczne.
Nie musisz uwzględniać wszystkich swoich usług naraz. Możesz rozpocząć od usług o znaczeniu krytycznym dla firmy lub tych, w przypadku których odnotowano przestoje.
Rozpoczęcie od usług pozwala uzyskać określony zestaw zasobów / elementów konfiguracji na początek. Następnie, w miarę pojawiania się nowych problemów, można dodawać inne zasoby. Najlepiej tworzyć swoją bazę CMDB kawałek po kawałku, ponieważ łatwiej sprawdzić dokładność niewielkich fragmentów danych niż całej infrastruktury i wszystkich zasobów za jednym razem.
Korzystaj z szablonów schematów obiektów
W Assets można znaleźć gotowe szablony schematów obiektów do zarządzania zasobami IT i konfiguracjami, zasobami ludzkimi oraz relacjami z klientem.
Szablony te można modyfikować, dostosowując je do własnych potrzeb, stanowią one też doskonały punkt wyjścia do wdrożenia typów obiektów, jakie użytkownicy często przechowują w Assets. Przejrzyj listę typów obiektów i usuń te, z których nie będziesz korzystać.
Porady i wskazówki
Zastanów się, bez czego możesz się obejść
Przemyśl dokładnie, co próbujesz osiągnąć i jakie informacje będą do tego potrzebne. Każdy obiekt oraz jego atrybuty powinny być przydatne.
Porozmawiaj z zespołem i osobami zainteresowanymi, aby upewnić się, że każdy atrybut jest wykorzystywany przez kogoś lub do czegoś. Jeśli nikt nie ma zastosowania dla jakiegoś atrybutu, odrzuć go. Zawsze można go dodać później!
Czy naprawdę musisz znać dokładną lokalizację swoich serwerów? Albo producenta systemów operacyjnych? Być może tak i to jak najbardziej ma sens. Jeśli jednak nie zamierzasz podejmować decyzji ani tworzyć zapytań w oparciu o te dane, po prostu odłóż je na bok.
Dodanie zbyt dużej ilości danych stwarza wyzwania:
- Im więcej obiektów i atrybutów, tym więcej pracy potrzeba, aby zapewnić ich dokładność.
- Duża ilość nieużywanych danych będzie przesłaniać cenne dane, a w skrajnych przypadkach może nawet obniżać wydajność.
- Łatwiej dodać dane później niż je usuwać. Lepiej dodać później brakujące dane niż zacząć od ogromnej ilości danych „na wszelki wypadek”. Nikt nie lubi usuwać danych.
Weź pod uwagę łatwość utrzymania w przyszłości
Przemyśl sposób utrzymywania danych wprowadzonych do Assets. Jak często będą się zmieniać atrybuty obiektu i na ile łatwo będzie zapewnić ich aktualność w Assets?
Jeśli konkretny wycinek danych dotyczących obiektu często ulega zmianie, ale rzadko się go wykorzystuje, prawdopodobnie lepiej będzie nie wprowadzać go do Assets, tylko po prostu wyszukać przy tych rzadkich okazjach, gdy faktycznie jest potrzebny. Jeśli czegoś używa się od czasu do czasu, ale jest to wysoce niezmienne, wprowadzenie tego w celu ułatwienia dostępu może być dobrym pomysłem.
Posłużmy się przykładem oprogramowania na laptopie. Jeśli zechcesz, możesz aktualizować Assets o każdy element oprogramowania zainstalowany na laptopie, wykorzystując w tym celu agenta skanowania, zgłoszenia dotyczące wniosków o oprogramowanie i reguły automatyzacji. Jeśli w Twojej firmie obowiązują otwarte zasady dotyczące instalacji, oprogramowanie będzie się zmieniało stosunkowo szybko i wzorce skanowania mogą nie wychwycić nowego oprogramowania, co może prowadzić do nieznacznego obniżenia dokładności. W takiej sytuacji lepiej przyjrzeć się kluczowemu zestawowi oprogramowania, którego wzorce użytkowania chcesz poznać w szczególności.
Jeśli w Twojej firmie obowiązują rygorystyczne zasady dotyczące instalacji, a oprogramowanie instalowane jest tylko przy konfiguracji laptopa i za pośrednictwem wniosków do działu obsługi, wówczas warto zapisać je w całości w Assets, ponieważ tempo zmian jest wolniejsze i łatwiej jest je śledzić.
Wyjdź poza elementy fizyczne
Narzędzie Assets umożliwia definiowanie potrzebnych obiektów, co oznacza, że nie musisz się ograniczać do zasobów tradycyjnych ani nawet fizycznych. Na przykład usługi biznesowe nie są zasobami fizycznymi, ale często ich szczegółowe zrozumienie ma dla ludzi krytyczne znaczenie. Z usługą można powiązać wszystkie jej zależności fizyczne i niefizyczne, dzięki czemu spojrzenie na obiekt usługi biznesowej pozwala w pełni zrozumieć sposób jej funkcjonowania.
Możesz przejść na dowolny poziom abstrakcji. Do przykładów obiektów ważnych dla firm, jakie tworzą użytkownicy Assets, należą typy środowisk, działy/zespoły, lokalizacje itp.
Innym zaczerpniętym z praktyki przykładem jest kategoryzowanie usług biznesowych. Załóżmy, że wszystkie Twoje usługi biznesowe są dodane do narzędzia Assets jako typ obiektu „Usługi biznesowe”. Możesz podzielić te usługi na kategorie, takie jak „Finanse”, „Logistyka”, „Sprzedaż”, „Infrastruktura” itp. W tym celu możesz użyć atrybutu w typie obiektu Usługa biznesowa lub stworzyć dla tych kategorii ich własny typ obiektu o nazwie „Kategoria usług”.
Zaletą tego rozwiązania jest możliwość dodawania szczegółów (atrybutów) właściwych dla danej kategorii usług biznesowych. Być może jest osoba odpowiedzialna za wszystkie usługi biznesowe związane z finansami. Nie chcesz dodawać tej osoby bezpośrednio do każdego obiektu „Usługa biznesowa” związanego z finansami, ponieważ takie rozwiązanie będzie trudne w utrzymaniu. Zamiast tego, wystarczy dodać tę osobę raz do obiektu „Finanse” w typie obiektu „Kategoria usług”. Wówczas taką informację aktualizuje się wyłącznie w jednym miejscu i nie trzeba wprowadzać jej powtórnie.
Można również stworzyć reguły, które będą odczytywać status roboczy każdej usługi biznesowej związanej z finansami z osobna, a następnie podsumowywać te statusy w celu uzyskania statusu ogólnego dla kategorii finansów. W ten sposób można szybko sprawdzić, czy występują jakiekolwiek problemy z usługami należącymi do poszczególnych kategorii usług, przeglądając obiekty kategorii.
Nie trzeba dodawać tych typów obiektów do Zasobów. Należy jednak pamiętać, że tradycyjne zasoby / elementy konfiguracji to nie jedyne możliwości. Wszystko zależy od tego, co chcesz zrobić, dlatego kluczowe znaczenie ma zrozumienie swoich celów i zidentyfikowanie informacji potrzebnych do ich osiągnięcia.
Spoglądaj w przyszłość i postaw na stopniowy rozwój
Miej na uwadze wszelkie rozszerzenia, które mogą się przydać w przyszłości. Od nich zależeć będzie nie tylko rodzaj uwzględnianych danych, ale także ich struktura.
Choć warto o tym pamiętać, zalecamy tworzenie bazy Assets stopniowo. Bardzo trudno utworzyć jedno ogromne wydanie zawierające w 100% dokładne dane dla tysięcy obiektów. Znacznie prościej będzie zacząć od drobnych elementów i dodawać nowe atrybuty, obiekty i schematy obiektów na bieżąco.
Zalecamy zidentyfikowanie problemu, utworzenie bazy Zasobów w celu jego usunięcia, a następnie przejście do kolejnego problemu poprzez rozwój tej bazy.
Wyznacz realistyczne oczekiwania względem dokładności
Docelowo dokładność powinna być 100% przez cały czas, jednak w rzeczywistości może się to okazać niemożliwe. Nie ma w tym nic złego. Dopóki dane są na tyle dokładne, że pod względem biznesowym przynoszą większą wartość niż ich brak, wciąż wychodzisz na swoje. Wiele projektów CMDB doświadcza opóźnień, a nawet nigdy nie zostaje ukończonych w oczekiwaniu na osiągnięcie „ideału” jeszcze przed wdrożeniem.
Krok 7 — Konfiguracja automatyzacji
W tej części opisano dwie opcje automatyzacji powtarzalnych zadań w Assets.
Automatyzacja narzędzia Assets
Automatyzacje Assets są właściwe dla poszczególnych schematów obiektów. Do ich częstych zastosowań należą:
- Wysyłanie powiadomień w oparciu o konkretne wyzwalacze lub zmiany w obiektach Assets należących do schematu — np. wysyłanie wiadomości e-mail, gdy zbliża się data wygaśnięcia licencji lub gwarancji, bądź tworzenie zgłoszenia w Jira, gdy usługa przestaje działać.
- Porządkowanie i normalizacja danych w Assets w celu ułatwienia tworzenia raportów i zapytań.
Reguły automatyzacji umożliwiają aktualizowanie informacji o obiektach, tworzenie zgłoszeń, wysyłanie wiadomości e-mail, tworzenie wniosków HTTP, wykonywanie skryptów Groovy i wiele innych.
Tutaj znajdziesz informacje na temat tworzenia reguł automatyzacji:
Funkcje następujące
W Assets wprowadzono również nowe funkcje następcze. Funkcje te, podobnie jak reguły automatyzacji, umożliwiają automatyzowanie wykonywania czynności.
Różnica polega na tym, że czynności są wykonywane, gdy status zgłoszenia w przepływie pracy Jira ulega zmianie (podczas przejścia zgłoszenia). Czynności te obejmują aktualizację zasobu, wysłanie powiadomienia i uruchomienie skryptu.
Można na przykład opracować zadania, które po utworzeniu zgłoszenia z wnioskiem o wdrożenie pracownika spowodują przypisanie do nowego użytkownika niezbędnych zasobów, takich jak laptop, telefon komórkowy i abonament telefoniczny, z których każdy będzie połączony z obiektami Assets.
Porady i wskazówki
Jeśli wprowadzasz lub aktualizujesz dane w Assets przy użyciu pól tekstowych zgłoszeń bądź od czasu do czasu wprowadzasz obiekty do Assets ręcznie, do danych może wkraść się bałagan. W takich przypadkach warto skorzystać z automatyzacji.
Dobrym tego przykładem są nazwy serwerów. Zazwyczaj są ono znormalizowane i łatwo się pomylić przy ich wpisywaniu. Można utworzyć reguły automatyzacji wyzwalane po utworzeniu lub zaktualizowaniu obiektu z uwzględnieniem serwera, aby się upewnić, czy nazwa zgadza się z konwencją nazewnictwa, a w razie potrzeby dodać oznaczenie sygnalizujące błąd.
Krok 9 — Konfiguracja raportowania
Raportowanie jest procesem bardzo specyficznym dla użytkownika, firmy oraz problemów, które próbujesz rozwiązać za pomocą aplikacji Assets. W Assets dostępny jest szereg wstępnie skonfigurowanych raportów, które pomogą Ci zrozumieć dane dotyczące zasobów i konfiguracji. Możesz tworzyć raporty na temat obiektów Assets, powiązanych z nimi zgłoszeń i projektów, a także poświęconego na nie czasu.
Może Cię na przykład interesować, ile zmian i incydentów wystąpiło w krytycznych usługach biznesowych. Możesz też sprawdzić, czy istnieje korelacja między czasem poświęcanym na wnioski o usługę a rodzajem zasobów, z którymi są powiązane. Z raportów można wywnioskować, z którymi krytycznymi usługami biznesowymi łączy się najwięcej incydentów, co pozwoli określić, które obszary doskonalenia należy potraktować priorytetowo.