Inżynier SRE - stażysta
Najpierw pozwól, że się przedstawię. I - , inżynier front-end w grupie GitLab. W zeszłym tygodniu miałem zaszczyt odbywać staż u jednego z naszych dyżurnych inżynierów SRE. Celem była obserwacja, jak funkcjonariusz pełniący służbę na co dzień reaguje na zdarzenia i zdobycie praktycznego doświadczenia w pracy. Chcielibyśmy, aby nasi inżynierowie lepiej rozumieli potrzeby użytkowników Monitoruj::Zdrowie.
Przez tydzień musiałem wszędzie podążać za inżynierem SRE. Oznacza to, że byłem obecny przy przekazaniu, monitorowałem te same kanały ostrzegania i reagowałem na incydenty, jeśli i kiedy miały miejsce.
Incydenty
W ciągu tygodnia doszło do 2 wypadków.
1. Górnik kryptowalut
W środę GitLab.com odnotował wzrost wykorzystania 'a, spowodowane próbami wykorzystania minut biegacza do wydobywania kryptowaluty. Incydent został naprawiony przy użyciu naszego własnego narzędzia do neutralizacji naruszeń, które wstrzymuje zadania biegacza i usuwa powiązany z nim projekt i konto.
Gdyby to zdarzenie nie zostało zauważone, zautomatyzowane narzędzie by je wyłapało, jednak w tym przypadku inżynier SRE zauważył naruszenie jako pierwszy. Utworzono zadanie incydentu, ale informacje na jego temat są zamknięte.
2. Spadek wydajności aplikacji Canary i Main
Incydent był spowodowany spowolnieniem i zwiększoną częstotliwością błędów w Canary i głównych aplikacjach internetowych na Gitlab.com. Naruszonych zostało kilka wartości Apdex.
Otwórz zadanie incydentu:
Najważniejsze ustalenia
Oto kilka rzeczy, których nauczyłem się podczas tygodnia na służbie.
1. Alerty są najbardziej przydatne przy wykrywaniu odchyleń od normy.
Alerty można podzielić na kilka typów:
- Alerty oparte na określonej wartości progowej, np. „10 błędów 5xx na sekundę”.
- Alerty, w których próg stanowi wartość procentowa, np. „częstotliwość 5xx błędów na 10% całkowitego wolumenu żądań w danym momencie”.
- Alerty oparte na średniej historycznej, takie jak „błędy 5xx na 90. percentylu”.
Ogólnie rzecz biorąc, typy 2 i 3 są bardziej przydatne dla SRE na służbie, ponieważ ujawniają odchylenia od normy w procesie.
2. Wiele alertów nigdy nie prowadzi do incydentów.
Inżynierowie SR mają do czynienia z ciągłym strumieniem alertów, z których wiele nie jest w rzeczywistości krytycznych.
Dlaczego więc nie ograniczyć alertów tylko do tych naprawdę ważnych? Jednak przy takim podejściu możesz nie rozpoznać wczesnych symptomów tego, co doprowadzi do powstania prawdziwego problemu grożącego poważnymi szkodami.
Zadaniem dyżurującego SRE jest określenie, które alerty faktycznie wskazują na coś poważnego i czy należy je eskalować i zająć się nimi. Podejrzewam, że wynika to również z braku elastyczności alertów: byłoby lepiej, gdyby istniało kilka poziomów lub „inteligentnych” sposobów konfiguracji alertów zgodnie z sytuacją opisaną powyżej.
Sugestia funkcji:
3. Nasi SRE na służbie korzystają z wielu narzędzi.
Wewnętrzny:
- Projekt GitLab infra: znajdują się tutaj elementy Runbook, przydziały zmianowe/tygodniowe, zadania reagowania na incydenty.
- Problemy z GitLabem: dochodzenia, recenzje i konserwacja są również śledzone w problemach.
- Etykiety GitLab: Zadania automatyzacji są uruchamiane przy użyciu określonych etykiet, których boty używają do śledzenia aktywności zadań.
Zewnętrzny:
- PagerDuty: Alarmy
- Slack: Tutaj odbywa się przepływ komunikatów PagerDuty/AlertManager. Integracja z poleceniami ukośnika w celu wykonywania różnych zadań, takich jak zamykanie alertu lub eskalacja do zdarzenia.
- Grafana: wizualizacja wskaźników ze szczególnym uwzględnieniem trendów długoterminowych.
- Kibana: Zapewnia wizualizację/przeszukiwanie dzienników, możliwość głębszego zagłębienia się w określone zdarzenia.
- Zoom: W Zoomie stale działa „pokój wypoczynkowy”. Dzięki temu inżynierowie SRE mogą szybko omawiać wydarzenia bez marnowania cennego czasu na tworzenie pokoju i łączenie uczestników.
I wiele, wiele innych.
4. Monitorowanie GitLab.com za pomocą GitLab to pojedynczy punkt awarii
Jeśli w serwisie GitLab.com nastąpi poważna przerwa w świadczeniu usług, nie chcemy, aby miało to wpływ na naszą zdolność do rozwiązania problemu. Można go zatrzymać, uruchamiając drugą instancję GitLab do zarządzania GitLab.com. W rzeczywistości to już działa dla nas: .
5. Kilka funkcji, które warto dodać do GitLaba
- , podobnie jak Dokumenty Google. Pomoże to w zadaniach dotyczących incydentów podczas wydarzenia, a także w zadaniach związanych z odprawą. W obu przypadkach kilku uczestników może potrzebować dodać coś w czasie rzeczywistym.
- Więcej webhooków do zadań. Możliwość uruchamiania różnych etapów przepływu pracy GitLab od wewnątrz pomoże zmniejszyć zależność od integracji ze Slackiem. Na przykład możliwość zezwolenia na alert w PagerDuty za pomocą polecenia ukośnika w problemie GitLab.
wniosek
Inżynierowie SRE mają trudności z wieloma złożonościami. Byłoby wspaniale zobaczyć więcej produktów GitLab rozwiązujących te problemy. Pracujemy już nad dodatkami do produktu, które ułatwią wspomniane powyżej przepływy pracy. Szczegóły dostępne pod adresem .
W 2020 roku powiększamy zespół, aby połączyć wszystkie te wspaniałe funkcje w jedną całość. Jeśli jesteś zainteresowany, proszę sprawdzić i jeśli masz jakiekolwiek pytania, skontaktuj się z kimkolwiek z naszego zespołu.
Źródło: www.habr.com