Agile w obliczu problemów: brakujący element planu reagowania na incydenty

Z metodyk Agile coraz częściej korzysta się poza tradycyjnym obszarem tworzenia oprogramowania, we wszystkich zróżnicowanych obszarach biznesu — nawet w marketingu! W związku z tym zaczęliśmy się zastanawiać, jak wygląda metodyka Agile w świecie zarządzania incydentami. W Atlassian pod pojęciem Agile rozumiemy ustrukturyzowane i iteracyjne podejście do zarządzania projektami i rozwoju produktu. Metodyka Agile umożliwia zespołowi reagowanie na zmianę bez zbaczania z obranej ścieżki.

Błędy w środowisku produkcyjnym, incydenty oraz przestoje bez wątpienia można zaklasyfikować jako okresy, w których wszystko „zbacza z utartych torów”. Doszliśmy w związku z tym do wniosku, że metodyka taka jak Agile, która ma na celu ułatwienie zespołom pozostanie na tych torach, w naturalny sposób wpisuje się w proces zarządzania incydentami, a w szczególności informowanie o incydentach.

Choć nie brakuje narzędzi, które mogą pomóc zespołowi w wykrywaniu incydentów, powiadamianiu o nich, pracy nad nimi, a także ich rozwiązywaniu, same narzędzia nie są w stanie zastąpić przejrzystej komunikacji z interesariuszami. Spójrzmy prawdzie w oczy: gra toczy się o wysoką stawkę. Pogorszenie reputacji, spadek liczby klientów czy wydłużenie czasu poświęcanego na opanowanie szkód, to tylko niektóre z niepożądanych skutków. Metodyki Agile mogą pomóc w obniżeniu tej stawki do minimalnego poziomu.

Wielu z Was zna już prawdopodobnie cztery kluczowe wartości z Manifestu Agile: 1) ludzie i interakcje ponad procesami i narzędziami, 2) działające oprogramowanie ponad szczegółową dokumentacją, 3) współpraca z klientem ponad negocjowaniem umów oraz 4) reagowanie na zmiany ponad realizacją założonego planu. Przyjrzymy się teraz nieco bliżej każdej z tych wartości i zobaczmy, jak można je wykorzystać do powiadamiania o incydentach w sposób bardziej zgodny z zasadami Agile.

Ta zasada opiera się na wartości Agile, która głosi: ludzie i interakcje ponad procesy i narzędzia. Procesy i narzędzia odgrywają ważną rolę w każdym procesie zarządzania incydentami, jednak nie będą one miały żadnego znaczenia, jeśli nie będzie ludzi, którzy będą próbowali je wykorzystać ani uformowanej wokół nich kultury. Co zatem spaja ze sobą ludzi, procesy oraz narzędzia? Jest to oczywiście komunikacja!

Komunikacja odgrywa kluczową rolę, gdy pojawia się problem. Bez względu na to, czy jest to drobny błąd w środowisku produkcyjnym, czy rozległa awaria systemu. Nawet najlepiej dopracowany plan reagowania na incydenty wymaga częstej komunikacji w celu znalezienia rozwiązania i utrzymania zaufania.

Podczas incydentu dotknięci nim użytkownicy najprawdopodobniej doświadczają frustrujących, a momentami wręcz destrukcyjnych błędów, dlatego trzeba jak najszybciej powiadomić ich o tym, co się dzieje. Wielu z nich będzie od razu wysyłać wiadomości e-mail, tweetować i/lub otwierać zgłoszenia dotyczące zaistniałego problemu. Dlatego w interesie wszystkich leży, aby jak najszybciej opanować sytuację, przekazując komunikat pokazujący, że masz świadomość, że coś jest nie tak, i szukasz rozwiązania. W Atlassian wykorzystujemy Statuspage do powiadamiania interesariuszy wewnętrznych i zewnętrznych podczas przestoju. Zapewne dla Ciebie to rozwiązanie również okazałoby się przydatne w przypadku konieczności rozesłania informacji o incydencie do użytkowników w szybki i skalowalny sposób. W rzeczywistości rozwiązanie Statuspage pomaga użytkownikom przyspieszyć powiadamianie o incydentach aż o 50%.

Niezależnie od narzędzia używanego do przekazywania klientom informacji komunikacja ukierunkowana na człowieka jest kluczem do sukcesu. Po drugiej stronie problemu znajdują się prawdziwi ludzie, którzy polegają na Twojej usłudze i ufają, że będziesz informować ich na bieżąco, jeśli coś nie będzie działać jak należy. Choć w świecie doskonałym szablony są fantastyczne, będziesz potrzebować ludzi, którzy będą w stanie sformułować czytelny, zwięzły, empatyczny komunikat zawierający wszystkie istotne informacje, aby móc liczyć na zaufanie klientów nawet w najtrudniejszych okresach. Weźmy na przykład Dyn. Firma doświadczyła ogromnej awarii w trakcie jednego z największych ataków DDoS w historii, a mimo to użytkownicy dziękowali jej za szczerość, którą się wykazała w czasie niedostępności usługi:

Jak stwierdził Werner Vogels, dyrektor ds. technologii AWS, omawiając dużą awarię usługi AWS S3 w lutym 2017 roku:

„Klienci nie lubią porad typu «siedź i czekaj z założonymi rękami». Zdecydowanie nie tego oczekują. W związku z tym musisz udostępnić im naprawdę wartościowe informacje — spraw, żeby zrozumieli, co się dzieje, i podaj przewidywany termin przywrócenia działania usługi, jeśli masz takie informacje”.

Ta zasada odnosi się z kolei do wartości Agile, która zakłada priorytet działającego oprogramowania nad szczegółową dokumentacją. Dokumentacja dotycząca produktu powinna być czytelna i przyjazna dla użytkownika, a naszym zdaniem aktualności dotyczące incydentów także powinny takie być. Ustalenie przyczyny problemu i spodziewanego terminu jego rozwiązania nie powinno wymagać od użytkowników konieczności czytania między wierszami (ani brnięcia przez obszerne fragmenty tekstu). Opracowywanie aktualności o incydentach wymaga namysłu oraz wykazania się empatią oraz ludzkim podejściem, jednak nie można dopuszczać, aby łańcuch zatwierdzeń i liczne poprawki utrudniały przekazywanie częstych i rzetelnych informacji.

Wracając raz jeszcze do incydentu w Dyn, widać, że zespół nie tracąc czasu, błyskawicznie zaczął powiadamiać użytkowników. W trakcie incydentu trwającego ponad 11 godzin aktualizowali oni swoją stronę stanu 11 razy (średni czas między aktualizacjami wyniósł 61 minut). Dzięki prowadzeniu strony stanu mieli jedno miejsce, w którym mogli przekazywać informacje na temat incydentu. Zespół nie musiał więc tracić czasu na szukanie list mailingowych w celu wysłania e-maili ani zastanawiać się, jak przekazać aktualności w zaledwie 140 znakach na Twitterze. Innymi słowy, komunikacja nie była prowadzona kosztem głównego zadania, czyli przywrócenia działania usługi.

Zaletą gotowego narzędzia do informowania o stanie jest fakt, że nie musisz poświęcać mnóstwa czasu na uruchomienie niezawodnej strony. Utworzenie strony stanu trwa niecałe 30 minut i, tak jak metodyka Agile, również ona może i powinna mieć charakter iteracyjny. Najpierw pomyśl o udostępnieniu klientom działającej strony, a następnie udoskonalaj ją. Gdy już będziesz mieć za sobą kilka incydentów ze stroną stanu używaną w ramach procesu, możesz zacząć wprowadzać w niej ulepszenia.

Chcesz utworzyć własną stronę stanu? Zarejestruj się lub zaloguj w Statuspage >>

Nie czekaj z utworzeniem strony stanu do kolejnego incydentu. Poświęć kilka minut już teraz, aby w momencie wystąpienia przestoju znaleźć się w najkorzystniejszym położeniu. Pamiętaj, że skonfigurowanie strony, aby spełniała swoje zadanie, nie musi być czasochłonne:

• Dowiedz się, jak spersonalizować stronę stanu.
• Zainspiruj się przykładami fantastycznych projektów i personalizacji stron stanu.

Wartość Agile mówiąca o większej wartości współpracy z klientem od negocjacji umów dotyczy przede wszystkim pracy z klientami w celu zapewnienia im najlepszego możliwego produktu i doskonałej obsługi. Dla nas oznacza to skonfigurowanie właściwych kanałów informacji zwrotnych, aby klienci mogli wyrażać swoje wątpliwości i informować o problemach, których doświadczają (przy użyciu narzędzi, takich jak Jira Service Management, Twitter itp.). Światowej klasy firmy zdają sobie sprawę, że klienci oczekują reakcji na przekazywane przez nich opinie i chcą mieć wpływ na wprowadzane udoskonalenia produktu oraz proces reagowania na incydenty. Odrobina empatii i wyjaśnienia mogą zdziałać cuda, a jak pokazują poniższe tweety, klienci nie wstydzą się o nie prosić:

Oznacza to również zapewnienie przejrzystości w zakresie dostępności, aby użytkownicy wiedzieli dokładnie, co otrzymają po rejestracji. Rejestrując się w usłudze chmurowej, ufasz, że będzie ona niezawodna. Nie zawsze oznacza to zawarcie fizycznej umowy. Chodzi raczej o nieodłączną umowę negocjowaną między klientem a usługodawcą, zgodnie z którą w razie problemów obydwie strony będą współpracować, aby szybko usunąć usterkę, i wszyscy będą informowani na bieżąco w trakcie całego procesu — od zbadania problemu po jego rozwiązanie. To z kolei prowadzi nas do ostatniej wartości dotyczącej reagowania na zamiany…

Nawet najlepiej opracowane plany są… Resztę już pewnie znasz. Mając na uwadze wartość Agile, jaką jest reagowanie na zmiany ponad realizacją założonego planu, zdajemy sobie sprawę, że nawet najbardziej przemyślane plany nieuchronnie będą ulegać zmianom, zarówno w trakcie incydentu, jak i po jego zakończeniu. W metodyce Agile chodzi o to, aby móc zmieniać kierunek działania w każdej chwili i szybko oraz stale gromadzić informacje zwrotne, które pozwolą doskonalić zarówno produkt, jak i kulturę.

Wistia, internetowa firma zajmująca hostowaniem filmów i analizami, poznała wagę zwinności podczas nieoczekiwanego incydentu z 2013 roku, który spowodował awarię infrastruktury do obsługi statystyk. Firma nie była przygotowana, skutkiem czego została zalana zgłoszeniami do działu wsparcia od niezadowolonych klientów. Pierwszym punktem zwrotnym było utworzenie własnej strony stanu, aby ułatwić sobie radzenie z tego typu sytuacjami. Jednak utworzenie własnego narzędzia do informowania o stanie sprawiło, że musieli zapewnić wsparcie nie tylko swojego produktu podstawowego, ale także nowego produktu. Stało się jasne, że był to koszt, na który liczący wówczas 20 osób zespół nie mógł sobie pozwolić. Drugim punktem zwrotnym była rezygnacja z samodzielnie opracowanego rozwiązania na rzecz Statuspage.

Jordan Munson, inżynier wsparcia w Wistia opisał ten krok w następujący sposób: „Po wielu miesiącach umiarkowanej frustracji związanej z naszym niemal całkowicie pozbawionym funkcji, choć przydatnym, samodzielnie opracowanym rozwiązaniem zdecydowaliśmy, że potrzebujemy czegoś więcej. Czegoś, co nie wymagałoby takiej uwagi. Było to rozwiązanie Statuspage. Po przejściu na Statuspage mogliśmy robić to, o co nam chodziło — szybko i prosto informować klientów na bieżąco o statusie naszej aplikacji. Dotarcie do tego momentu wymagało tylko jednej potężnej awarii i opracowania nowego produktu. Po kilku latach nasze procesy wyglądają znacznie sprawniej. W przypadku awarii użytkownicy otrzymują aktualne informacje bezpośrednio od nas. Wiedzą, gdzie szukać najnowszych informacji, a aktualności, jakie zamieszczamy na naszej stronie stanu są bezpośrednio przesyłane do wielu miejsc”.

Zespół Munsona rzeczywiście wziął cytryny (awarię z 2013 roku) i zrobił z nich lemoniadę (nowy, udoskonalony i skalowalny proces informowania o incydentach). Jest to reakcja Agile na zmianę w najlepszym wydaniu.

Retrospektywy również odgrywają kluczową rolę w realizacji tej wartości Agile. Retrospektywa jest dla zespołu okazją, aby cofnąć się pamięcią i omówić udane oraz nieudane aspekty informowania o zaistniałym incydencie, a w szczególności kroki, które należy podjąć, aby w przyszłości nie wystąpiły te same problemy. Nie ulegaj pokusie pominięcia retrospektywy, gdy incydent zostanie „odhaczony” jako rozwiązany lub gdy uważasz, że zespół świetnie sobie poradził. W procesie informowania o incydentach zawsze jest szansa na poprawę i zbudowanie lepszych relacji z użytkownikami oraz zwiększenie ich zaufania.

Wracając do pierwszej wartości z Manifestu Agile, retrospektywy zdecydowanie wymagają komunikacji ukierunkowanej na człowieka, aby mogły spełniać swoją funkcję i przynosić trwałe wyniki. Poniżej przedstawiamy przykładowe zwroty, które warto uwzględnić przy omawianiu przebiegu rozwiązywania incydentu podczas retrospektywy. Niektóre z tych zwrotów można wykorzystać także w trakcie analizy post-mortem lub przeglądu po incydencie przekazywanego użytkownikom, gdy usługa zostanie przywrócona. Metodyka Agile polega na ciągłym doskonaleniu nie tylko sposobu realizacji zadań związanych z incydentem, ale także relacji z innymi członkami zespołu i pełnienia swojej roli w tak stresującej sytuacji.

W metodyce Agile dużo mówi się o zaufaniu, a ten przypadek użycia nie jest wyjątkiem. Skuteczne informowanie o incydentach wymaga zaufania i możliwości działania. Zespoły w całej organizacji powinny mieć uprawnienia i wiedzę wymagane do informowania użytkowników o incydentach. Poszczególne osoby powinny również ufać, że w ramach reagowania na incydent każdy będzie wykonywał przydzielone mu obowiązki, a w razie wystąpienia nieoczekiwanej sytuacji nie zawaha się dołączyć do procesu i wypełnić luki. Ufność, że zespoły zapewnią skuteczną komunikację podczas incydentów, umożliwi przyspieszenie przekazywania informacji klientom, co z kolei przełoży się na większe zaufanie i lojalność użytkowników w stosunku do Twojej usługi (67% klientów rozwiązania Statuspage twierdzi, że pomogło im ono zwiększyć zaufanie użytkowników!). To idealny przykład sytuacji korzystnej dla obu stron.