Znaczenie reagowania na zdarzenia

Korzystając z zasad i praktyk monitorowania omówionych w innym module z tej ścieżki szkoleniowej, dowiesz się teraz, co zrobić, gdy monitorowanie ujawnia problem. Jeśli otrzymasz alert z możliwością działania z powiadomieniem o tym, że systemy nie działają zgodnie z oczekiwaniami, jest to wyzwalacz odpowiedzi na problem.

Co to jest zdarzenie?

Reagowanie na zdarzenia dotyczy akcji podejmowania w momencie wystąpienia zdarzenia, ale co dokładnie stanowi zdarzenie? Odpowiedź może być subiektywna; nawet nie wszyscy inżynierowie zgadzają się co do tego, czym jest zdarzenie. Jeśli zadajesz pytanie w różnych branżach i organizacjach, otrzymasz wiele różnych odpowiedzi.

Niektóre z nich oznaczą wszystkie zakłócenia jako zdarzenia, niezależnie od tego, czy mają to wpływ na klientów. W kontekście tego modułu możemy wyrazić zgodę na to, że zdarzenie jest definiowane jako zakłócenie usługi: wystąpienie lub warunek, który wpływa na zdolność użytkownika do korzystania z usług, na których polega. Przykłady obejmują awarię systemów lub awarię w sposób, który ma wpływ na klientów.

Co to jest reagowanie na zdarzenia?

Zapobieganie wszystkim problemom jest godne pochwały, ale niemożliwe celem. rzeczy pójść źle, więc potrzebujemy planu ograniczenia wpływu na naszych użytkowników końcowych i jak najszybszego powrotu operacji do normy.

Kluczem jest działanie z pilnością, a nie reagowanie. Reakcja wydaje się być bardziej impulsywna i oparta w chwili obecnej, bez uwzględnienia długoterminowych efektów. Odpowiedź jest dobrze przemyślana, zorganizowana i oparta na informacjach.

Podejście reagowania na zdarzenia określa skuteczność:

• Zrozumienie tego, co się dzieje (diagnozowanie problemu).
• Klasyfikowanie (określanie pilności) i ustalanie priorytetów problemu/kwestii.
• Angażowanie odpowiednich zasobów w celu wyeliminowania problemów.
• Komunikowanie się z uczestnikami projektu na temat problemu.

Po rozwiązaniu problemu możesz wyciągnąć wnioski z tego zdarzenia poprzez proces przeglądu powydarzeniowego. Jest to ważny temat, który ma zupełnie osobny moduł do dyskusji.

Mierzenie wydajności reagowania na zdarzenia

Możesz zapoznać się z akronimem TTR, który jest inaczej zdefiniowany jako "czas odzyskiwania", "czas korygowania" lub "czas przywracania". Wszystkie te warianty odnoszą się do tej samej rzeczy: łączny czas potrzebny na przywrócenie usług do miejsca, w którym mogą powrócić do oczekiwań klientów.

Ta metryka jest jednym ze sposobów mierzenia wydajności zespołów podczas reagowania na zdarzenia. Im szybciej odzyskasz/korygujesz/przywrócisz usługę, tym mniejszy będzie wpływ awarii lub obniżonej wydajności usługi.

Ważne jest, aby wiedzieć, jak dobrze organizacja obsługuje reagowanie na zdarzenia. Co roku organizacja DevOps Research and Assessment (DORA) publikuje raport State of DevOps. Niektóre kluczowe ustalenia w raporcie z 2019 r. koncentrowały się na wydajności reagowania na zdarzenia.

• W raporcie sklasyfikowane zespoły inżynieryjne, które mogą wykrywać, reagować i korygować przerwy w działaniu usług w mniej niż godzinę jako "elitarne lub wysokowydajne".
• Ci, którzy byli w stanie odzyskać się z incydentów w mniej niż 24 godziny, zostali sklasyfikowani jako "średni wykonawcy."
• "Osoby o słabych wynikach" to ci, którzy potrzebują od jednego tygodnia do miesiąca, aby dojść do siebie po zakłóceniach w działaniu usługi.

Różnica między tymi poziomami jest znacząca. W badaniu stwierdzono, że zespoły elitarne lub wysokowydajne wracają do siebie po incydentach 2604 razy szybciej niż ich nisko wydajne rówieśniki. "Osoby osiągające wysokie wyniki wdrażają również w środowisko produkcyjne 208 razy częściej."

Dlaczego i jak elitarni wykonawcy reagują i odzyskują o wiele szybciej niż reszta? Jest to przynajmniej częściowo dlatego, że rozumieją znaczenie posiadania dobrego podstawowego planu reagowania już w miejscu, gdy rzeczy nieuchronnie poszły źle.

W ramach tego modułu poznasz charakterystykę i cykl życia zdarzenia oraz sposób wykorzystania tej wiedzy do utworzenia własnego podstawowego planu.