Ze wszystkiego, co potrafi zaskoczyć przy przejściu do chmury, problem raportowania może ujawnić się dość późno. Migracja techniczna przejdzie bez zarzutu, zespoły będą pracować w nowej Jirze, ale tydzień później controlling może zacząć dopytywać, dlaczego poniedziałkowy raport dla zarządu przyszedł pusty.
Dlaczego raporty z bazy Jiry nie zadziałają w chmurze?
W chmurze infrastrukturą zarządza Atlassian i do bazy nie wpuszcza nikogo z zewnątrz, a jedyną programistyczną drogą do danych jest REST API. Na Data Center jest odwrotnie: baza stoi na wewnętrznej infrastrukturze, więc można ją odpytać SQL-em i zasilić z niej dowolne narzędzie raportowe. Jest to świadoma architektura usługi, a nie tymczasowe ograniczenie, które ktoś kiedyś zdejmie. Dlatego pytanie nie brzmi „jak odzyskać dostęp do bazy”, tylko „którym z dostępnych kanałów odtworzyć każdy raport”. Kanały są cztery i opisujemy je niżej.
Które raporty są zagrożone?
O zagrożeniu rozstrzyga jedno pytanie: skąd raport bierze dane. Wszystko, co omija Jirę i idzie prosto do jej bazy, po migracji wymaga odtworzenia w nowym kanale. W pierwszej kolejności należy zweryfikować:
- narzędzia BI z konektorem SQL do bazy Jiry,
- własne zapytania SQL: analizy i skrypty utrzymywane przez zespoły,
- procesy ETL kopiujące tabele Jiry do hurtowni danych.
Osobna kategoria to raporty-cienie: arkusze, które ktoś raz na miesiąc zasila ręcznym zrzutem z bazy. W żadnym rejestrze ich nie ma, a ich zniknięcie po migracji boli tak samo jak awaria oficjalnego raportu.
Bezpieczne są raporty działające wewnątrz Jiry (dashboardy, gadżety, filtry) oraz wtyczki raportowe, o ile mają wersję chmurową. Integracje pobierające dane przez API również przetrwają, choć przy dużym wolumenie trzeba sprawdzić limity liczby zapytań; opisaliśmy je w artykule o tym, co potrafi zaskoczyć przy migracji.
Jeśli test wskaże zagrożone raporty, oznacza to pracę nad ich odtworzeniem w nowym kanale. Który kanał wybrać i jaki plan Atlassiana jest do tego potrzebny, zależy od charakteru raportów.
Czym raportować w Atlassian Cloud?
Do wyboru są cztery kanały. Dashboardy i gadżety są natywną częścią Jiry Cloud i odpowiadają na bieżące pytania zespołów: jak idzie sprint, gdzie utknęły zgłoszenia, kto jest przeciążony. REST API zasila zewnętrzne narzędzia i hurtownie danych; to naturalny następca ETL-a z bazy, wymaga jednak przebudowy procesu pobierania i kontroli tempa zapytań. Aplikacje raportowe z Marketplace obsługują potrzeby, które nie mieszczą się w dashboardach, a nie wymagają jeszcze hurtowni: raporty czasu pracy, wykresy zarządcze, eksporty do arkuszy. Czwarty kanał, Atlassian Analytics z Data Lake, omawiamy osobno, bo jego dostępność zależy od planu.
Dobór narzędzia zależy od odbiorcy. Zespołom zwykle wystarczą dashboardy; controlling i zarząd potrzebują danych połączonych z innymi systemami, więc w grę wchodzi API albo Analytics. Rzadko jeden kanał obsłuży wszystko – zestaw dwóch albo trzech to norma.
Co daje Atlassian Analytics i kto go dostaje?
Atlassian Analytics jest dostępny w planie Cloud Enterprise, bez dodatkowych opłat. Opiera się na Atlassian Data Lake: repozytorium danych z Jiry, Jira Service Management i Confluence, gotowym do analizy bez budowania i utrzymywania własnego ETL-a. Raporty składa się wizualnie albo zapytaniami SQL po stronie Analytics, więc kompetencje zespołu BI nie idą do kosza. Dla działów, które dotąd raportowały wprost z bazy, to najbliższy odpowiednik dawnego świata.
W planach Standard i Premium tego kanału nie ma; pozostają API, dashboardy i aplikacje raportowe. Jeśli takie raportowanie było w Twojej organizacji rozbudowane, potrzeby analityczne stają się jednym z argumentów przy wyborze planu. Ten wątek rozwijamy w artykule o wyborze między planem Standard a Premium.
Jak przygotować model raportowy przed migracją?
Spisz raporty, zanim ruszy projekt migracji. Dla każdego zanotuj pięć rzeczy:
- kto z niego korzysta,
- skąd bierze dane,
- jak często powstaje,
- czy przeżyje migrację,
- a jeśli nie, to którym kanałem go odtworzyć.
Uwaga: znalezienie wszystkich raportów bywa trudniejsze, niż się wydaje. Odbiorca raportu często nie wie, skąd płyną dane, bo raport „po prostu przychodzi” co poniedziałek. Ruchu do bazy nie widać też z poziomu samej Jiry. Dlatego obok przeglądu technicznego warto ogłosić w organizacji prostą zasadę: każdy, kto podejrzewa, że jego zestawienie może bazować na danych z Jiry, zgłasza je zespołowi prowadzącemu migrację. Administrator bazy może dodatkowo sprawdzić ślady po swojej stronie: konta techniczne z dostępem do bazy, aktywne połączenia spoza aplikacji, utworzone widoki.
Odtworzone raporty sprawdza się na środowisku testowym, przed przełączeniem, z udziałem ich odbiorców. Wtedy obawa „migracja zabije nam poniedziałkowy raport” znika: raport działa w nowym kanale, zanim ktokolwiek wyłączy stary.
W analizie przedmigracyjnej pomagamy zorganizować taki przegląd: spisujemy z Wami model raportowy, podpowiadamy, gdzie po stronie bazy szukać śladów zewnętrznych raportów, a następnie dla każdego zgłoszonego zestawienia wskazujemy kanał odtworzenia w chmurze, w tym aplikacje raportowe z Marketplace, które mogą wesprzeć warstwę analityczną.
Jeśli chcecie wiedzieć, jak to ugryźć w Waszej instancji, zachęcamy do umówienia bezpłatnej konsultacji.
