Schemat instrukcji przekazanej do AM

Szablon instrukcji

Wszystkie instrukcje powinny być przygotowane z wykorzystaniem szablonu AM ALERT INSTRUCTION *

Jest to globalny template i każdy w każdym space ma do niego dostęp.

*Szablon wykorzystujemy przy tworzeniu strony. Przy dodawaniu strony mamy opcję utworzenia jej z template - wpisujemy tam podaną nazwę. Do konfiguracji template mają dostęp tylko admini confluence.

Kiedy alert może zostać przekazany do zespołu Application Monitoring

• AM powinien mieć odpowiednie dostępy (może je uzyskać w celu wykonywania przekazanej instrukcji, ale należy upewnić się, że może takie dostępy uzyskać. Na pewno nie może dostać dostępu do kont bankowych itp.)

• Alert powinien zawierać instrukcję utworzoną zgodnie z poniższymi wskazówkami

• Alert powinien mieć integrację z opsgenie, które jest wykorzystywane przez AM w celu otrzymywania alertów (czyli alerty z zabbix-k8s, grafany, można zrobić integrację z prometheusa)

• Alert został zweryfikowany po stronie developerów pod kątem np. czułości alertu czy tego, że alert spełnia oczekiwania

• Posiada tag produktu zgodny z wartością pola “ Product” (należy wejść w context → create, edit…) w JIRA. Tag product:

Co powinna zawierać instrukcja, którą ma zostać przekazana do zespołu AM

• opis wymaganych dostępów (hosty / ns / panele)

• kroki do wykonania (jakie zapytanie puścić na jakiej bazie, gdzie iść w panelu i w jakim, jaką maszynkę kopnąć i w jaki sposób , gdzie i po czym szukać logów → np po id serwisu szukamy logów w pob-cyclicscanner-jboss-prod )

• czego szukać po wykonaniu kroków, na co zwrócić uwagę (co ma nam zwrócić zapytanie, jakie są najczęstsze problemy i co oznaczają)

• co należy zrobić w przypadku namierzenia problemów

• w jakim momencie kogo informować (zespół / dyżurny np. jeśli wykonanie instrukcji nie naprawi problemu kontaktujemy się z zespołem onboardingu lub dyżurnym IT); do kogo eskalować i w jaki sposób

• informację kiedy alert świadczy o incydencie/awarii (np. jaką wartość musi osiągnąć wartość alertu, jakie błędy świadczą o awarii) usprawiedliwiający założenie incydentu i o jakim severity

• krótki opis tego co weryfikuje monitoring, co takiego się dzieje kiedy alert się zapala, jaki jest skutek dla usług BM

Instrukcję będą wykonywały osoby, które na co dzień zajmują się dziesiątkami aplikacji, więc niekoniecznie domyślą się, o jaką chodzi, nie mają o niej takiej wiedzy jak programiści tworzący te aplikacje, pamiętajmy o tym.

Instrukcje powinny być spisane w taki sposób, żeby każda osoba z odpowiednimi dostępami była w stanie ją wykonać.

Jak przekazać alert

• Kiedy alert już spełnia odpowiednie wymogi, należy utworzyć zadanie na kolejkę SD z informacjami, w jakich godzinach działa monitoring, czego dotyczy (link do alertu, jakiej aplikacji dotyczy, krótki opis), jaka ma być ścieżka eskalacji, jakie dostępy są niezbędne do wykonania instrukcji oraz z załączoną instrukcją.

• Zespół AM weryfikuje instrukcję oraz umawia się z reporterem na wspólne jej wykonanie

• W przypadku braku problemów zespół AM przepina alert do siebie lub prosi odpowiedni zespół o przepięcie

• Jeśli alert nie może zostać przyjęty przez AM w zgłoszonej formie, zespół AM informuje o przyczynach

Gdzie umieścić instrukcję

Instrukcje umieszczamy w space zespołu, który opiekuje się aplikacją. Opiekunem instrukcji jest ten zespół i zajmuje się jej aktualizacją. W przypadku przeniesienia instrukcji z innego space bądź w obrębie space należy poinformować zespół AM o konieczności aktualizacji linku do instrukcji w alercie.

Tagi alertu

Każdy alert, żeby był odpowiednio kierowany do zespołu, powinien mieć tagi, na podstawie których jest przydzielany (w grafanie są to labelki, mapowane na tagi). Informację o tym, jakie mają być, należy umieścić w zadaniu na przepięcie alertu. Przykładowo tagi, żeby skierować alert zespołu CARDS do AM: first.reaction:AM, second.reaction:CARDS, a więc alert powinien posiadać minimum dwa tagi.

W przypadku braku tagu dla twojego zespołu zgłoś się do Izabela Kardasz lub do zespołu Application Monitoring