Close
Przewodniki i samouczki dotyczące produktów

Wszystko, co musisz wiedzieć o rozpoczęciu pracy z Assets for Jira Service Management Data Center.

Ilustracja ludzi wchodzących do monitora, na którym wyświetlana jest platforma Jira

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 1 — Instalacja

W przypadku Jira Service Management Data Center w wersji 4.15 lub nowszej pobierany plik obejmuje funkcję Assets.

Użytkownicy Jira Service Management Data Center w wersji 4.14 lub starszej muszą zainstalować darmową aplikację Assets:

  1. Zaloguj się do Jira Service Management jako użytkownik z globalnymi uprawnieniami administratora Jira.
  2. Kliknij listę rozwijaną administratora i wybierz opcję „Zarządzaj aplikacjami”.
  3. Na stronie po lewej kliknij opcję „Znajdź nowe aplikacje” i wyszukaj opcję „Assets”.
  4. W wynikach pojawi się odpowiednia wersja aplikacji.
  5. Postępuj według instrukcji, aby zainstalować aplikację.
  6. Pojawi się monit o zalogowanie do serwisu MyAtlassian i rozpocznie się pobieranie aplikacji Assets.

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.

Okienko nawigacji CMDB przedstawiające hierarchię obiektów, na przykład od zasobów IT do sprzętu do obsługi serweró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.

Strona atrybutów Insight przedstawiająca różne atrybuty obiektu bazy danych, w tym typ, stan, hosta bazy danych oraz inne informacje.

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”.

Ekran tworzenia obiektu Insight dla obiektu Komputer. Użytkownik wprowadza atrybuty komputera, takie jak lokalizacja, model, producent i system operacyjny.

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:

  1. Odniesienia wychodzące to odniesienia bieżącego obiektu do innych obiektów.
  2. 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.

Okno przeglądarki graficznej Insight przedstawiające obiekt „Jira Service Management”. Wyświetlane są zależności, takie jak hosty, na których oprogramowanie jest uruchomione, system operacyjny, różne wymagane wersje Jira oraz licencja.

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ć.

Formularz tworzenia schematu obiektów zawierający opcje pustego schematu, schematu zasobów IT, schematu HR oraz schematu CRM.

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”.

Widok obiektu aplikacji biznesowej SAM z wyróżnionymi otagowanymi typami obiektów „Kategorie usług” dla obiektów „Finanse” i „Administracja” będących samodzielnymi typami obiektów.

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 4 — Przeniesienie danych do Zasobów

W dużej organizacji ręczne wprowadzanie wszystkich danych trwałoby niemiłosiernie długo. Dlatego dostępnych jest kilka narzędzi, które mogą pomóc.

Skaner sieciowy Assets Discovery

Assets Discovery to darmowe narzędzie dostępne w sklepie Marketplace.

Aplikacja Assets Discovery to bezagentowy skaner (choć dostępny jest agent pozwalający uzyskać bardziej szczegółowe informacje), który wychwytuje zasoby sieciowe. Pozwala ona wybrać zasoby i atrybuty, które mają zostać ściągnięte do schematów obiektów Zasobów, a także tworzyć własne wzorce skanowania w celu wykrycia bardziej niszowych zasobów. Regularne uruchamianie tego narzędzia umożliwia wychwytywanie zmian i zapewnienie aktualności danych. Za pomocą reguł automatyzacji można nawet wyzwalać zgłoszenia Jira, powiadomienia e-mail oraz inne operacje w oparciu o wykrywane zmiany.

Narzędzia importu

Za pomocą narzędzi importu Assets można pobierać dane z innych źródeł. Te reguły importu można regularnie synchronizować, aby w razie potrzeby móc aktualizować dane. Dla każdego typu importu należy zdefiniować miejsce zapisu danych oraz ich lokalizację docelową w Assets.

Import plików CSV

Jeśli korzystasz z programu opartego na arkuszach kalkulacyjnych, takiego jak Excel lub Arkusze Google, do przechowywania swoich zasobów, możesz wprowadzić te dane do Zasobów za pomocą funkcji importu plików CSV. Dzięki temu uzyskasz zintegrowany i przejrzysty system z możliwością łączenia zasobów ze zgłoszeniami i analizowania wpływu.

Importowanie bazy danych

Korzystając z funkcji importu bazy danych, można zaimportować dane z systemu wewnętrznego lub zewnętrznego. Obsługiwane są bazy danych Oracle, MySQL, Microsoft SQL Server i PostgreSQL.

Importowanie użytkowników Jira

Często użytkownicy Assets łączą użytkowników Jira z posiadanymi przez nich zasobami. W tym celu konieczne jest zaimportowanie poszczególnych użytkowników lub konkretnych grup użytkowników Jira do Assets, co można zrobić za pomocą funkcji importowania użytkowników Jira.

Importowanie katalogów LDAP

Korzystasz z katalogu korporacyjnego zawierającego dane na temat zasobów lub relacji pracowników z kierownictwem używanych w procesach zatwierdzania? Aby to ułatwić, w Assets przewidziano moduły współpracujące z popularnymi katalogami LDAP, które umożliwiają pobranie struktury i zasobów z Twojego katalogu.

Import pliku JSON

Obiekty można importować do Zasobów z plików JSON zawierających dane do zaimportowania.

Narzędzia Integracji

Za pomocą integracji można tworzyć połączenia z innymi narzędziami, takimi jak usługi w chmurze, menedżery zasobów oraz inne bazy CMDB.

Choć wszyscy dysponujemy takimi narzędziami, nie zaleca się przenoszenia każdego fragmentu danych do Assets, chyba że planowane jest wycofanie narzędzia. Lepiej wprowadzić te dane, które będą potrzebne w Jira Service Management — później zawsze można wprowadzić więcej informacji.

Wszystkie integracje można zainstalować za darmo ze sklepu Marketplace.

Poniżej znajduje się pełna lista integracji Assets:

Istnieje również integracja rozwiązań Zasoby i Confluence. Integracja ta umożliwia tworzenie stron Confluence dokumentujących zasoby firmy. Służy ona raczej do przesyłania danych niż do pobierania ich do aplikacji Zasoby.

Porady i wskazówki

Trzeba wypracować optymalną częstotliwość uruchamiania narzędzia Assets Discovery, narzędzi importu i integracji. Jeśli będzie się to robić zbyt rzadko, dane w Assets nie będą aktualne. Zbyt częste ich uruchamianie może powodować wysokie zużycie zasobów — w zależności od liczby przetwarzanych obiektów. Niektórzy użytkownicy uruchamiają integracje co godzinę, inni raz w tygodniu, a jeszcze inni na żądanie.

Zalecamy możliwie częstą synchronizację w okresach spokojnych. Zastanów się, jak często dane mogą ulegać zmianie, i na podstawie stopnia istotności tych danych określ, jak często należy zaplanować uruchamianie tych operacji. Twoim celem jest dotrzymanie kroku zmianom danych.

Aplikacja Assets Discovery umożliwia uruchamianie różnych wzorców skanowania w różnych odstępach czasu, aby w miarę możliwości ograniczyć liczbę zasobów potrzebnych do zapewnienia aktualizacji danych Assets.


Krok 5 — Ustalenie struktury danych

Podziel dane na logiczne schematy obiektów

Nie wszystkie Twoje dane muszą trafić do jednego ogromnego schematu obiektów. Zalecamy utworzenie wielu schematów obiektów, w zależności od sposobu używania danych lub ich właściciela.

Aplikacje Assets i Jira nie biorą pod uwagę przynależności danych do konkretnych schematów obiektów. Administrator po prostu wskazuje pole niestandardowe Assets przy potrzebnych danych, niezależnie od schematu, do którego należą. Z kolei pola niestandardowe mogą przesyłać dane do wielu schematów obiektów i je z nich pobierać z poziomu jednego zgłoszenia Jira. Obiekty należące do jednego schematu obiektów można łączyć z obiektami w innych schematach. Można też uruchamiać zapytania obejmujące różne schematy. Schematy obiektów mają na celu przede wszystkim ułatwienie nam życia. Nie są szczególnie istotne dla samej aplikacji Assets.

Zastosowanie podziału danych na różne schematy obiektów ułatwia nie tylko pracę, ale także utrzymanie bazy. Konkretne zespoły, na przykład z działu finansów lub HR, mogą potrzebować pewnych informacji z Zasobów, ale niekoniecznie chcą być bombardowane danymi, które nie są dla nich istotne. Łatwiej również poprosić jeden zespół o regularne sprawdzanie jakości danych w jednym schemacie obiektów niż o sprawdzanie tylko pewnego wycinka jednego ogromnego schematu obiektów.

Łącz swoje dane

Jeśli masz już w innym miejscu dobrze funkcjonującą bazę danych lub źródło informacji, a także procesy pozwalające zapewnić aktualność zawartych w nich danych, nie musisz przenosić tych danych do Zasobów. Prawdopodobnie lepiej będzie utworzyć kopię odpowiednich danych przy użyciu integracji i uruchamiać te integracje według harmonogramu w celu aktualizowania informacji w Zasobach.

Assets ma szereg narzędzi importu oraz integracji (patrz wyżej). Umożliwiają one udostępnienie informacji potrzebnych do podejmowania decyzji w zgłoszeniu Jira lub samej aplikacji Assets bez konieczności utrzymywania dwóch odrębnych kopii.

Często obserwujemy korzystanie w tym celu z narzędzia importu LDAP do synchronizacji Assets z Active Directory. Pozwala to zyskać łatwy dostęp do wszystkich użytkowników Windows, a uruchamiając tę funkcję okresowo, można łatwo zaktualizować dane.

Czasami ludzie tworzą odrębne schematy obiektów dla tych zaimportowanych danych, a innym razem integrują je do postaci większych schematów obiektów. Jeśli dane będą wykorzystywane w różnych celach (np. na potrzeby wsparcia IT lub HR), wówczas sensowniejszym rozwiązaniem będzie stworzenie z nich odrębnego schematu obiektów, zamiast włączania ich w schemat obiektów IT, do którego dostęp zapewni się również pracownikom HR.

Osobom korzystającym z integracji zalecamy niewprowadzanie każdego elementu dostępnych danych do Assets. Podczas konfiguracji integracji można określić, jakie dane będą trafiały do schematu obiektów, a jakie nie. Takich danych nie należy również aktualizować w samej aplikacji Assets, chyba że później wysyła się wprowadzone zmiany do pierwotnego źródła danych. W przeciwnym razie pojawią się konflikty danych.

Jeśli nie ma żadnej gotowej integracji, dostępne są również inne opcje. Pierwszą z nich jest okresowe eksportowanie danych do pliku CSV/JSON i regularne ich importowanie za pomocą narzędzi importu plików CSV/JSON do Assets. Można również utworzyć obiekt i przypisać mu atrybut adresu URL do innej bazy danych, w której można znaleźć więcej informacji. Ta opcja sprawdza się w sytuacji, kiedy chcemy zapewnić agentom możliwość przeglądania informacji bez możliwości wyszukiwania lub tworzenia raportów na ich podstawie.

Nie używaj wszędzie tych samych atrybutów

Jeśli atrybut jest używany w wielu miejscach i posiada te same, powtarzające się wartości, wówczas często lepiej jest zrobić z niego odrębny typ obiektu. Dostawca jest dobrym tego przykładem. Atrybut o nazwie „Dostawca” można zastosować do typów obiektów laptop i telefon, a następnie wpisać (lub zaimportować) nazwę dostawcy dla każdego obiektu.

Można tak zrobić, ale znacznie lepszym rozwiązaniem będzie ustawienie typu obiektów o nazwie „Dostawcy”, a następnie ustawienie każdego dostawcy jako obiektu. Taka konfiguracja jest korzystna z wielu powodów:

  1. Być może sama nazwa dostawcy nie wystarczy. Możesz potrzebować innych informacji związanych z dostawcą, takich jak numer kontaktowy działu wsparcia lub łącza do umów. Nie chcesz wprowadzać tych danych dla każdego laptopa i telefonu z osobna. Możesz ustawić je raz i połączyć z obiektem dostawcy. W ten sposób można również wprowadzić elementy zarządzania dostawcami w Jira Service Management.
  2. Takie rozwiązanie pozwoli znormalizować dostawców, co ułatwi tworzenie raportów. Jeśli zechcesz utworzyć raport na temat liczby wniosków o wsparcie zgłoszonych przez poszczególnych dostawców, masz pewność, że nie przegapisz niczego tylko dlatego, że ktoś gdzieś popełnił literówkę, pisząc Micrsoft lub Aple.
  3. Jeśli dostawca zmieni markę lub będzie wymagał innego rodzaju modyfikacji, wówczas wystarczy zaktualizować dane w jednym miejscu.

Dostawca to zaledwie jeden przykład. To samo dotyczy poziomów istotności dla firmy, środowisk wdrożenia, działów i lokalizacji.


Krok 6 — Konfigurowanie pól niestandardowych Zasobów dla zgłoszeń Jira

W tej części objaśniono, w jaki sposób można skonfigurować zgłoszenia w systemie Jira, aby powiązać je z obiektami Assets. Funkcję tę można wykorzystać do połączenia zakłóconych usług biznesowych ze zgłoszeniami o incydentach, dodania komputera do zgłoszenia wniosku o sprzęt bądź dodania zestawu potencjalnie naruszonych hostów do zgłoszenia wniosku o zmianę.

Narzędzie Assets zapewnia dostęp do nowych, specjalnych pół niestandardowych. Te pola niestandardowe należy skonfigurować tak, aby wskazywały na konkretny zestaw obiektów.

Pola Assets można udostępnić klientowi z listą dostępnych opcji lub puste. Mogą również pozostać otwarte, aby każdy, kto wypełnia zgłoszenie Jira, mógł dodać do Assets nowe obiekty bezpośrednio z formularza.

Zaleca się korzystanie głównie z pierwszej opcji, jednak druga również ma swoje zastosowanie. Sprawdza się na przykład podczas wdrażania nowego pracownika. Jeśli przechowujesz dane swoich pracowników w Assets, możesz zlecić kierownikowi ds. zatrudnienia wypełnienie w Jira wniosku o wdrożenie zawierającego otwarte pola niestandardowe Assets. Spowoduje to automatyczne utworzenie nowego obiektu pracownika w Assets w tle, co zaoszczędzi administratorom czasu i wysiłku.


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ła automatyzacji Insight służąca do tworzenia zgłoszeń Jira, gdy zbliża się termin wygaśnięcia licencji.

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 8 — Ustalenie sposobu zapewniania dokładności danych

Aktualizacja danych ma krytyczne znaczenie. Bez niej zespoły będą pracowały w oparciu o fałszywe założenia, co może opóźniać proces rozwiązywania incydentów lub prowadzić do uzyskania błędnych wyników po złożeniu wniosku o usługę.

Istnieje szereg sposobów aktualizacji danych w Assets. Wiele z nich opiera się na automatyzacjach, które zdejmują użytkownikom z barków najtrudniejszą część pracy.

  1. Regularnie przeprowadzaj audyty swoich danych.
    Można skonfigurować reguły automatyzacji Zasobów, aby powiadamiać ludzi zgodnie z harmonogramem o konieczności przeprowadzania audytu danych. Dzięki temu będą otrzymywać przypomnienia o wykonaniu szybkiego sprawdzenia poprawności, aby mieć pewność, że kluczowe zasoby są aktualne.
  2. Regularnie synchronizuj aplikację Assets Discovery oraz odpowiednie narzędzia importu i integracje.
    Powszechną przyczyną braku aktualności danych jest zbyt rzadka synchronizacja Assets z zewnętrznymi źródłami danych. Zastanów się, jak często dane w źródłach zewnętrznych ulegają zmianie i jak często używa się ich w Jira Service Management. To pozwoli dobrać właściwą częstotliwość. Jeśli coś zmienia się często, a jest regularnie łączone ze zgłoszeniami, konieczna może być synchronizacja co 24 godziny. Inne integracje mogą poczekać kilka tygodni, a nawet miesięcy.
  3. Korzystaj z reguł automatyzacji.
    Gdy w zgłoszeniach Jira podejmowane są decyzje prowadzące do zmiany danych zasobów/konfiguracji, ważne jest zarejestrowanie tych zmian w Assets. Na przykład jeśli agent zdecyduje się przydzielić użytkownikowi nowego laptopa z powodu usterki starego, trzeba zarejestrować w Assets taką informację:
  • Nowy laptop wymaga aktualizacji właściciela do osoby składającej wniosek oraz aktualizacji statusu do „w eksploatacji”.
  • Ze starego laptopa trzeba usunąć informację o właścicielu i zaktualizować jego stan do „zepsuty”.

Gdy agent przekazuje takie informacje do osoby składającej wniosek, można wykorzystać ekrany przejść oraz funkcje następcze Zasobów do zarejestrowania tego rodzaju informacji i ustawienia nowych statusów oraz właścicieli w Zasobach przy użyciu automatyzacji.

To zaledwie jeden przykład, jednak włączając Zasoby w przepływy pracy Jira, warto zastanowić się na tym, które informacje ze zgłoszeń mogą wymagać przekazania z powrotem do Zasobów. Najlepiej ograniczyć ręczne aktualizacje danych Zasobów do minimum, ponieważ często się o tym zapomina.


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.

Okno konfiguracji raportu Insight przedstawiające liczbę zmian lub incydentów powiązanych z obiektami, którym przypisano najwyższy poziom istotności dla firmy.

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.


Inne tematy

Assets Query Language — AQL

Assets Query Language (AQL) to język umożliwiający tworzenie zapytań w Assets. Język AQL jest przydatny podczas tworzenia widoków wyszukiwania, reguł automatyzacji, zaawansowanych odniesień między zasobami, a nawet wydawania poleceń importowania.

Etykiety i kody QR

Korzystanie z etykiet i kodów QR może w dużym stopniu usprawnić zarządzanie środkami trwałymi. Dlatego Assets pozwala na drukowanie etykiet i kodów QR, które można umieszczać na dowolnych obiektach.