Start · Rozwiązania · Inne rozwiązania
Rozwiązanie · Inne rozwiązaniaKanał incydentu otwiera się z właścicielami, a zmiany zatwierdza dowód, nie piątkowe zebranie
Incydenty obsadzone i zamknięte jednym procesem
Poważny incydent otwiera własny kanał w Teams z właścicielami, usługami i uruchomionym runbookiem; zmiany są punktowane na podstawie dowodów, a do komitetu trafia tylko wysokie ryzyko.
Streszczenie dla zarządu
Narzędzie zapisuje, co się stało. Szukanie właścicieli, gonienie statusów i nieczytanie w piątek robią ludzie.
Dwa przepływy powstają na narzędziu, które już Państwo mają; żaden go nie zastępuje.
Pierwsze dwadzieścia minut poważnego incydentu idzie na naprawę, bo właściciele, usługi i runbook są w pokoju od początku.
ServiceNow; Jira; Microsoft Teams
Problem biznesowy
ITSM
Incydent, problem i zmiana dzielą jedno narzędzie i niewiele poza tym. W pierwszych dwudziestu minutach poważnego incydentu ludzie ustalają, kto jest właścicielem bazy danych i których klientów dotyka awaria, a kierownik incydentu przepisuje tę samą informację do trzech kanałów z pamięci. Zapis w ServiceNow powstaje potem; praca dzieje się w wątku czatu, którego nikt później nie odtworzy.
Notatki zamknięcia mają dwie linijki, więc proces problemów zaczyna od zera, a ten sam incydent wraca wraz ze szczytem sezonu. Zarządzanie zmianą ma odwrotną wadę: każdy wniosek dostaje ten sam czterdziestopięciosekundowy przegląd, więc reguła na zaporze i zmiana kroju pisma są oceniane tak samo. Zmiany niskiego ryzyka czekają tydzień na zebranie, a po wdrożeniu nikt nie patrzy w monitoring.
Utrzymuje się to, bo narzędzie rejestruje zapisy, a nie pracę, a ludzie, którzy mogliby zautomatyzować przekazania, są tymi, którzy gaszą pożary. Nic nie łączy zmiany z incydentem, który po niej następuje, więc organizacja nie potrafi podać własnego wskaźnika nieudanych zmian. Jedenaście osób z kadry kierowniczej spędza trzy kwadranse tygodniowo, zatwierdzając dokumenty, których nie przeczytało.
Jak to wygląda dzisiaj
- SystemAlert z Azure Monitor albo zgłoszenie użytkownika otwiera ticket w ServiceNow
- CzłowiekTicket trafia do kolejki i jest dwukrotnie przekierowywany, zanim dotrze do kogoś, kto może działać
- CzłowiekKtoś ogłasza incydent poważnym, uruchamia rozmowę w Teams, a właścicieli usług szuka się przez pytanie po ludziach
- OczekiwanieMost czeka, aż znajdzie się właściciel bazy danych i ustali się wpływ na klientów
- CzłowiekStatusy są wpisywane do trzech kanałów z pamięci, kiedy kierownik ma na to chwilę
- Ryzyko błęduPoprawka wchodzi, ticket zamyka się dwiema linijkami i rekord problemu nie ma z czego pracować
- OczekiwanieWniosek o zmianę stoi wypełniony w połowie do piątku, kiedy komitet czyści całą paczkę na jednym posiedzeniu
- Ryzyko błęduZmiana zostaje wdrożona, monitoringu nikt nie sprawdza, a awarię przypisuje się jej tygodnie później
Dlaczego obecny proces kosztuje więcej, niż się wydaje
Za każdym wyjątkiem stoi godzina, której nikt nie zapisał.
- Każda minuta poważnego incydentu ma w handlu omnikanałowym wartość koszyka, a pierwsze dwadzieścia idzie na logistykę zamiast na naprawę.
- Inżynierowie ściągnięci na most, którzy okazują się niepotrzebni, nie pracują w tym czasie nad niczym innym, a żadna ewidencja tej godziny nie rejestruje.
- Ubogie notatki zamknięcia sprawiają, że za ten sam incydent płaci się wielokrotnie, bo proces problemów nigdy nie dostaje dość materiału, by uzasadnić trwałe rozwiązanie.
- Zmiany niskiego ryzyka stoją w kolejce za cotygodniowym zebraniem, a te wysokiego nie dostają realnej oceny, i stąd biorą się awarie.
- Awarie spowodowane zmianami pozostają nieliczone, bo nic nie łączy obu zapisów, a zarząd słyszy, że awarie zdarzają się losowo.
Koszt zaniechania
Poważny incydent w handlu wycenia się w koszykach, a nie w godzinach analityków, i ta liczba należy do Państwa historii incydentów, a nie do jakiegokolwiek modelu. Wiersze liczą koordynację wokół naprawy i administrację wokół zmiany, czyli tę część, która zachowuje się jak praca etatowa i daje się uczciwie przedyskutować.
Zostawiona sama sobie, kolejka idzie w jedną stronę. Każda nowa integracja, każdy dostawca i każdy kanał dokładają incydentów, a każdy poważny płaci ten sam dwudziestominutowy podatek logistyczny. Zaległość problemów nie maleje, bo nic jej nie zasila. Szybsze wydania wpychają więcej zmian do piątkowej kolejki, więc presja na hurtowe zatwierdzanie rośnie razem z ryzykiem, a inżynierowie, którzy spędzają tydzień na mostach, mają najwięcej alternatyw poza firmą.
Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.
Sieć handlowa działająca omnikanałowo, z organizacją IT liczącą 240 osób. ServiceNow prowadzi incydenty, problemy i zmiany; zespoły deweloperskie pracują w Jira; platforma handlowa działa na Azure z Azure Monitor; sama praca dzieje się w Microsoft Teams.
Około 620 incydentów i 95 zmian miesięcznie, z czego mniej więcej 14 incydentów jest ogłaszanych poważnymi. Jedenastoosobowy komitet zmian spotyka się w każdy piątek na czterdzieści pięć minut i czyta jeden załącznik na dziesięć.
Poważne incydenty prowadzi się z doraźnej rozmowy w Teams: właścicieli szuka się przez pytanie po ludziach, statusy pisze z pamięci, a notatki zamknięcia mają dwie linijki. Zmiany przygotowuje się w szablonie i czyści hurtem na piątkowym komitecie, a monitoring po wdrożeniu nie należy do nikogo.
Pierwsze dwadzieścia minut każdego poważnego incydentu idzie na szukanie ludzi i otwieranie pokoju, a zmiana niskiego ryzyka czeka tydzień na zebranie. Przeglądy poincydentalne przypisują zmianom jedną trzecią poważnych incydentów; zapisy tego nie pokazują, bo nic ich nie łączy.
Poważny incydent uruchamia proces UiPath, który otwiera kanał w Teams z dotkniętymi usługami, dyżurnymi właścicielami i już działającym runbookiem, a UiPath Agent przygotowuje projekt podsumowania i listę podobnych incydentów dla kierownika incydentu do publikacji. Zmiany przechodzą przez proces UiPath Maestro, który punktuje ryzyko regułami DMN, automatycznie zatwierdza zmiany standardowe z kompletem dowodów, kieruje zwykłe do właścicieli elementów w Teams, a komitet rezerwuje dla wysokiego ryzyka.
W modelowanym przypadku kanał, jego właściciele i pierwszy runbook istnieją w ciągu minuty od ogłoszenia, połowa zmian jest zatwierdzana na podstawie dowodów bez zebrania, a każde wdrożenie jest przez dobę obserwowane w monitoringu. Te liczby modelują scenariusz, a nie mierzą rzeczywistość.
Proponowane rozwiązanie
Dwa przepływy powstają na narzędziu, które już Państwo mają; żaden go nie zastępuje. Kiedy incydent w ServiceNow zostaje oznaczony jako poważny, wyzwalacz zdarzeniowy w UiPath Integration Service tworzy kanał w Microsoft Teams, dodaje dyżurnych właścicieli z bazy konfiguracji. Publikuje też kartę Adaptive Card z dotkniętymi usługami, wpływem na klientów, linkiem do mostu i stanem runbooka.
UiPath Agent przygotowuje projekt podsumowania sytuacji i wypisuje podobne incydenty z przeszłości z indeksu Context Grounding zbudowanego na Państwa zamkniętych ticketach, podając numery, z których skorzystał. Kierownik incydentu poprawia go i publikuje, więc nic nie trafia do interesariusza bez konkretnej osoby za tym stojącej. Równolegle roboty wykonują runbook diagnostyczny danej usługi, a aktualizacje idą w rytmie wziętym z osi czasu zgłoszenia, a nie z czyjejś pamięci. Przy zamknięciu robot zapisuje oś czasu do rekordu i otwiera zgłoszenie problemu, gdy reguła powtarzalności jest spełniona.
Zmiany przechodzą przez proces UiPath Maestro, którego reguły DMN punktują każdą z nich za krytyczność elementu, zasięg skutków, okno wdrożeniowe, dowody z testów i historię tego typu zmiany. Zmiany standardowe z kompletem dowodów zatwierdza reguła; zwykłe trafiają do właściciela elementu jako zadanie UiPath Action Center w Teams w dniu zgłoszenia; do komitetu idzie wyłącznie wysokie ryzyko, z punktacją i dowodami. Robot obserwuje potem Azure Monitor i ServiceNow przez dwadzieścia cztery godziny i łączy każdy incydent ze zmianą, która go poprzedziła. Power BI raportuje czas przywrócenia, skuteczność zmian i incydenty spowodowane zmianami.
Rekordy incydentów, problemów i zmian w ServiceNow; kanały i karty Adaptive Card w Microsoft Teams; alerty i grupy akcji Azure Monitor; UiPath Maestro BPMN z regułami DMN i zarządzaniem instancjami; zadania UiPath Action Center w Microsoft Teams; indeksy UiPath Context Grounding; Power BI
Proces kanału incydentu, runbooki diagnostyczne, reguły powtarzalności i ryzyka, proces zmian w Maestro, kontrolę monitoringu po wdrożeniu oraz raporty
ServiceNow i Jira przez konektory UiPath Integration Service z wyzwalaczami zdarzeniowymi; konektory Microsoft Teams i Microsoft Azure dla kanału i danych platformy; grupy akcji Azure Monitor wywołujące API UiPath Orchestrator
Jak działa proces po automatyzacji
- SystemIncydent w ServiceNow zostaje oznaczony jako poważny, a wyzwalacz zdarzeniowy Integration Service uruchamia proces w ciągu minuty
- AutomatyzacjaOtwiera się kanał w Teams z dotkniętymi usługami, dyżurnymi właścicielami, linkiem do mostu i stanem runbooka
- AutomatyzacjaUiPath Agent przygotowuje projekt podsumowania i wypisuje podobne incydenty z zaindeksowanej historii zgłoszeń, z numerami stojącymi za każdym
- CzłowiekKierownik incydentu poprawia projekt, publikuje go i prowadzi most; inżynierowie naprawiają to, czego runbook nie obejmuje
- AutomatyzacjaAktualizacje idą w rytmie z osi czasu; przy zamknięciu robot zapisuje ją do rekordu i otwiera zgłoszenie problemu, gdy reguła jest spełniona
- AutomatyzacjaZmiana zgłoszona w ServiceNow jest punktowana w Maestro regułami DMN za krytyczność, zasięg skutków, okno, dowody i historię
- CzłowiekZwykłe zmiany zatwierdza właściciel elementu w zadaniu Action Center w Teams; te wysokiego ryzyka idą do komitetu z punktacją
- AutomatyzacjaRobot obserwuje potem Azure Monitor i ServiceNow przez dwadzieścia cztery godziny, łącząc incydent ze zmianą albo zamykając ją jako udaną
Model współpracy człowieka z automatyzacją
Automatyzacja obsługuje
- Utworzenie kanału incydentu z jego usługami, dyżurnymi właścicielami i linkiem do mostu
- Projekt podsumowania i wyszukanie podobnych incydentów do sprawdzenia przez człowieka
- Wykonanie runbooków diagnostycznych i dowodowych oraz wysyłkę aktualizacji w rytmie z osi czasu
- Punktację ryzyka zmiany, zatwierdzanie zmian standardowych na dowodach i obserwację monitoringu po wdrożeniu
Ludzie decydują
- Kierownik incydentu zatwierdza podsumowanie przed publikacją i prowadzi most
- Inżynierowie diagnozują i naprawiają wszystko, czego runbook nie obejmuje
- Właściciele elementów zatwierdzają zmiany zwykłe; komitet rozstrzyga wysokie ryzyko i jest właścicielem listy zmian standardowych
- Kierownik problemów rozstrzyga przyczynę źródłową i trwałe rozwiązanie
Przed i po
Systemy i integracje
Stos jest krótki celowo: jeden silnik, jedna warstwa wykonawcza, jedno miejsce decyzji człowieka.
Wejścia
- incydenty, problemy i zmiany z ServiceNow
- zgłoszenia zespołów deweloperskich z Jira
- alerty Azure Monitor i sygnały Application Insights
- baza konfiguracji z właścicielami usług i grafikiem dyżurów
- kalendarz zmian z oknami zamrożenia
Warstwa automatyzacji
- UiPath Orchestrator
- UiPath Robots
- UiPath Maestro
- UiPath Integration Service
- UiPath Action Center
- UiPath Agents
Systemy docelowe
- ServiceNow
- Jira
- Microsoft Teams
- Power BI
Punkty styku z człowiekiem: kanał incydentu w Teams; zatwierdzenia Action Center w Teams dla właścicieli elementów i komitetu; kontrola podsumowania przez kierownika incydentu; decyzja kierownika problemów o przyczynie źródłowej
Wykorzystane technologie
wyzwalacze zdarzeniowe na rekordach incydentów i zmian; tworzy kanał, zapisuje z powrotem do narzędzia
Awykonują runbooki; kolejki, ponowienia, magazyn poświadczeń i ślad audytowy
Aproces zmian: punktacja ryzyka, automatyczne zatwierdzanie na dowodach, kierowanie, zarządzanie instancjami
Aprzygotowuje podsumowanie incydentu i znajduje podobne sprawy w Państwa zamkniętych ticketach, z odwołaniami
Azatwierdzenia właścicieli elementów i komitetu oraz zadanie kontrolne kierownika incydentu
Apokój incydentu, karta obsady i karty zatwierdzeń
Aalerty uruchamiające runbooki przez grupy akcji; dwudziestoczterogodzinna obserwacja po każdym wdrożeniu
Aczas przywrócenia, skuteczność zmian, incydenty spowodowane zmianami, minuty komitetu na zmianę
AIlustracyjny model ekonomiczny
Liczby, które możecie sprawdzić na własnych danych.
Mosty i komitety to dwa miejsca, w które idą te pieniądze, a w kalkulatorze jest tylko pierwsze. Narzut koordynacyjny to 16 minut na incydent: szukanie właścicieli, otwieranie pokoju, wpisywanie statusów i spisanie rekordu na końcu, przy pełnym koszcie 56 € za godzinę. Przepływ zdejmuje go z 60% incydentów dotyczących usługi, która ma właściciela i runbook, a udział ten jest wliczony w wolumen, więc 620 incydentów miesięcznie wchodzi do kalkulatora jako 372. Administracja zmian stoi poza kalkulatorem, bo ma inną stawkę: 95 zmian miesięcznie po 55 minut po stronie zgłaszającego i komitetu, 71 € za godzinę. Z tego połowa staje się zmianami standardowymi na dowodach, czyli około 37 098 € rocznie. Niczego nie zmierzono u klienta, a diagnostyka, sama naprawa i utracony przychód pozostają poza modelem.
Policz to na swoich danych
Szacunek ilustracyjny na podstawie Twoich danych. To model uwolnionej przepustowości, nie obietnica oszczędności.
Korzyści biznesowe
- Pierwsze dwadzieścia minut poważnego incydentu idzie na naprawę, bo właściciele, usługi i runbook są w pokoju od początku
- Interesariusze dostają aktualizacje w rytmie wziętym z zapisu, więc nikt nie przerywa mostu pytaniem, co powiedzieć biznesowi
- Powtarzające się incydenty stają się problemami z mocy reguły, z dołączonym materiałem, więc są naprawiane zamiast powtarzane
- Zmiany niskiego ryzyka wchodzą w dniu zgłoszenia, a wysokie ryzyko trafia do komitetu, który przeczytał punktację
- Incydenty spowodowane zmianami są łączone automatycznie, więc organizacja poznaje swój rzeczywisty wskaźnik nieudanych zmian
Perspektywa zarządu
- Każdy poważny incydent niesie oś czasu, której nikt nie musiał odtwarzać, widoczną już w trakcie
- Kalendarz zmian pokazuje ryzyko, a nie daty, a agenda skraca się do tego, co wymaga jedenastu osób
- Czas inżynierów na mostach i w zatwierdzeniach staje się mierzalny, a przez to planowalny
- Skuteczność zmian i incydenty spowodowane zmianami stają się raportowanymi liczbami, co jest pierwszym krokiem do ich poprawy
Wpływ na KPI zarządu
Bezpieczeństwo i nadzór
Bezpieczeństwo projektujemy razem z procesem, nie po nim.
- Roboty runbookowe mają konta usługowe ograniczone do działań diagnostycznych i restartów własnych usług, a nic destrukcyjnego nie wykonuje się bez nadzoru. Sekrety pobierane są w czasie wykonania z Azure Key Vault przez magazyn poświadczeń Orchestrator
- Automatyczne zatwierdzenie dotyczy wyłącznie typów zmian zaklasyfikowanych przez komitet jako standardowe, a każde z nich wraca do ServiceNow z wersją reguły, która je wydała
- Zgłaszający nie może zatwierdzić własnej zmiany, a ścieżki zatwierdzeń żyją w procesie, nie w przyzwyczajeniu
- Agent czyta zaindeksowaną historię zgłoszeń pod politykami UiPath AI Trust Layer, z modelem z listy dozwolonych, maskowaniem danych osobowych i kierowaniem ruchu w UE, podaje źródła i nigdy nie publikuje bez konkretnej osoby
- Audyt Orchestrator i historia ServiceNow dają pełny zapis; przetwarzanie pozostaje w Państwa tenancie Microsoft 365 i w regionie EU UiPath Automation Cloud
Dlaczego teraz
Tempo wydań rośnie szybciej, niż jakiekolwiek cotygodniowe zebranie jest w stanie przeczytać: co kwartał do tych samych czterdziestu pięciu minut trafia więcej wdrożeń, więc presja na hurtowe zatwierdzanie rośnie razem z ryzykiem
Narzędzia ITSM publikują dziś zdarzenia i API, które pozwalają zautomatyzować te przekazania bez wymiany narzędzia, a incydenty i tak prowadzi się w Microsoft Teams, więc zapis i praca mogą się wreszcie spotkać. Modelowana pula koordynacji to 5 555 € miesięcznie, zanim zatwierdzi się choć jedną zmianę z wyprzedzeniem
Wyszukiwanie po własnych zamkniętych zgłoszeniach zmienia dopasowanie podobnych incydentów w konfigurację, a nie projekt, a klienci pytają dziś o dowody kontroli zmian, nie o protokół zebrania
Kluczowe role zarządcze
Awarie są krótsze i rzadsze, a kontrola zmian czyta się dla audytora jak kontrola, a nie jak rytuał
Inżynierowie dołączają do mostów tylko wtedy, gdy są potrzebni, komitet czyta to, co zatwierdza, a oba fakty przychodzą jako liczby
Incydenty dotykające zamówień są komunikowane w stałym rytmie, a ich przyczyny są usuwane zamiast powtarzane
Najczęstsze pytania i obiekcje
Ma zapisy i zatwierdzenia i powinien je zachować. Nie otwiera pokoju w Teams, nie znajduje dyżurnego właściciela, nie pisze podsumowania, nie wykonuje restartu i nie pilnuje monitoringu potem; to są właśnie te godziny, a dokładamy je bez wymiany Państwa narzędzia.
Agent przygotowuje projekt i podaje zgłoszenia, z których skorzystał; publikuje kierownik incydentu. Nic nie wychodzi bez przeczytania przez konkretną osobę, a lista podobnych incydentów to wyszukanie w Państwa własnej historii, nie opinia.
Prostą drogą do awarii jest zatwierdzanie bez czytania. Zmiana standardowa jest zatwierdzana automatycznie wyłącznie z dowodami z testów, ważnym oknem, brakiem zamrożenia i czystą historią, a każde wdrożenie jest potem sprawdzane w monitoringu, czego piątkowe zebranie nigdy nie robiło.
Kiedy to nie jest właściwe rozwiązanie
- Brak narzędzia ITSM z API: rejestr zmian w arkuszu potrzebuje najpierw narzędzia, a nie automatyzacji
- Mniej niż około stu incydentów miesięcznie, gdzie dobry grafik dyżurów i zdyscyplinowany kierownik załatwiają już większość spraw
- IT w całości oddane na zewnątrz, w procesie zarządzania usługami dostawcy, gdzie praca jest kwestią umowy
Pytanie na najbliższe posiedzenie
Awarie z ostatniego kwartału: czy ta firma potrafi wskazać zmianę stojącą za każdą z nich, a jeśli nie potrafi, to co dokładnie kontroluje piątkowe zebranie?
Podejście wdrożeniowe
Zakres bez niedomówień, jeszcze przed podpisem.
Dostarczamy
- Poważne incydenty i decyzje komitetu z ostatniego kwartału przeczytane od początku do końca, z wyprowadzonymi z nich runbookami, regułą powtarzalności i czynnikami ryzyka
- Proces kanału incydentu: utworzenie kanału, kartę obsady, aktualizacje w rytmie i oś czasu zapisaną do rekordu przy zamknięciu
- Runbooki diagnostyczne i dowodowe dla trzech usług stojących za większością Państwa poważnych incydentów
- Proces zmian w Maestro: tabelę decyzyjną ryzyka, reguły dowodowe dla zmian standardowych i zatwierdzenia w Teams
- Kontrolę monitoringu po wdrożeniu oraz raporty Power BI o czasie przywrócenia i skuteczności zmian
Potrzebujemy od Państwa
- Bazy konfiguracji albo działającej listy z właścicielami usług i grafikiem dyżurów
- Poważnych incydentów i agend komitetu z ostatniego kwartału, wraz z rozstrzygnięciami
- Alertów otagowanych usługą w Azure Monitor, żeby runbook dało się wybrać bez zgadywania
- Kierownika zmian i kierownika problemów, którzy będą właścicielami reguł i będą ich bronić
Etapy
Rozpoznanie
Przeczytane incydenty i decyzje o zmianach z ostatniego kwartału; runbooki, reguła powtarzalności i czynniki ryzyka uzgodnione z ich przyszłymi właścicielami
Projekt
Proces kanału, tabela decyzyjna, reguły dowodowe dla zmian standardowych, zatwierdzenia i model bezpieczeństwa
Budowa
Proces kanału, runbooki, proces Maestro, agent, kontrola monitoringu i raporty w Państwa środowisku
Bieg cichy
Podsumowania przygotowywane, ale niepublikowane, zmiany punktowane, ale niekierowane; reguły poprawiane na tle rzeczywistych decyzji
Uruchomienie i skalowanie
Kanały działają dla incydentów poważnych, zmiany standardowe przechodzą na zatwierdzanie dowodowe, runbooki dochodzą usługa po usłudze
Działowe. O nakładzie decyduje stan bazy konfiguracji, liczba usług wymagających własnego runbooka i to, ile typów zmian komitet zaklasyfikuje jako standardowe.
Jedenaście osób, czterdzieści pięć minut, dwadzieścia jeden nieotwartych załączników.
Prosimy o agendę ostatniego komitetu zmian i osie czasu pięciu ostatnich poważnych incydentów. Odsyłamy zmiany, które można było zatwierdzić z góry na dowodach, oraz punkt w każdej osi czasu, w którym zgubiono zegar incydentu.
Przejrzyjmy ostatni komitet zmianTen sam problem ma zwykle sąsiedni proces
Priorytet nadają wielkie litery zgłaszającego, a P1 czeka w kolejce, aż dyspozytor znajdzie czas, by je przeczytać.
Zobacz rozwiązanie Inne rozwiązaniaStatusy, awarie i zmiany ogłaszane, zanim ktoś zapytaMail o awarii wychodzi po awarii, a co piąty komentarz w kolejce zgłoszeń to te same dwa słowa.
Zobacz rozwiązanie Inne rozwiązaniaKto ma dyżur i co nie działa: odpowiedź w TeamsW czasie awarii osoba, która ją naprawia, jest też jedyną, która wie, których klientów dotyczy.
Zobacz rozwiązanieBranże, w których wdrażamy to najczęściejProdukcja i przemysłTransport i logistykaUsługi i ITCentra usług wspólnych