Inżynier SRE — stażysta
Na początek pozwólcie, że się przedstawię. Jestem , inżynierem front-end w grupie GitLab. W zeszłym tygodniu miałem zaszczyt być stażystą u jednego z naszych dyżurnych inżynierów SRE. Celem było codzienne obserwowanie, jak dyżurny reaguje na incydenty oraz zdobycie rzeczywistego doświadczenia zawodowego. Chcielibyśmy, aby nasi inżynierowie lepiej rozumieli potrzeby użytkowników Monitor::Health.
Przez tydzień miałem za zadanie towarzyszyć inżynierowi SRE. To oznacza, że brałem udział w przekazywaniu dyżuru, obserwowałem te same kanały powiadomień i reagowałem na incydenty, jeśli miały miejsce.
Incydenty
W ciągu tygodnia miały miejsce 2 incydenty.
1. Krypto-górnik
W środę na GitLab.com odnotowano wzrost wykorzystania spowodowany próbami użycia minut runnera do wydobywania kryptowalut. Z incydentem poradzono sobie dzięki naszemu własnemu narzędziu do neutralizacji naruszeń, które zatrzymuje zadania runnera i usuwa powiązany projekt oraz konto.
Gdyby to zdarzenie nie zostało zauważone, złapałby je zautomatyzowane narzędzie, ale w tym przypadku inżynier SRE zauważył naruszenie jako pierwszy. Utworzono zadanie dotyczące incydentu, jednak informacje na jego temat są zamknięte.
2. Degradacja wydajności aplikacji Canary i Main
Incydent został spowodowany spowolnieniem i wzrostem częstotliwości błędów w aplikacjach internetowych canary i main na GitLab.com. Naruszone zostały wartości Apdex.
Otwarte zadanie dotyczące incydentu:
Kluczowe wnioski
Oto kilka punktów, które zrozumiałem przez tydzień dyżuru.
1. Powiadomienia są najbardziej użyteczne, gdy rejestrują odchylenia od normy.
Powiadomienia można podzielić na kilka typów:
- Powiadomienia oparte na konkretnych progach, takie jak „wystąpiło 10 błędów 5xx na sekundę”.
- Powiadomienia, w których próg to wartość procentowa, takie jak „częstotliwość błędów 5xx na 10% całkowitej liczby zapytań w danym czasie”.
- Powiadomienia oparte na historycznej średniej, takie jak „błędy 5xx w 90. percentylu”.
Ogólnie rzecz biorąc, drugi i trzeci typ są bardziej użyteczne dla dyżurnych SRE, ponieważ ujawniają odchylenia od normy w przebiegu działania.
2. Wiele powiadomień nie eskaluje się do incydentów
Inżynierowie SRE zajmują się ciągłym napływem powiadomień, z których wiele w rzeczywistości nie jest krytycznych.
Dlaczego więc nie ograniczyć powiadomień tylko do tych naprawdę ważnych? Taki jednak sposób podejścia może sprawić, że nie dostrzegą wczesnych objawów, które przerodzą się w poważny problem, prowadzący do dużych strat.
Zadaniem dyżurnego SRE jest określenie, które powiadomienia rzeczywiście oznaczają coś poważnego i czy należy je eskalować oraz zająć się nimi. Podejrzewam, że wynika to również z sztywności powiadomień: lepiej byłoby, gdyby wprowadzono kilka poziomów lub "inteligentne" metody konfiguracji powiadomień w zgodzie z opisaną powyżej sytuacją.
Propozycja funkcji:
3. Nasi dyżurni SRE korzystają z wielu narzędzi
Wewnętrzne:
- Projekt infrastruktury GitLab: tutaj znajdują się Runbooki, przekazania dyżurów na zmianę/tydzień, zadania związane z reagowaniem na incydenty.
- Zgłoszenia GitLab: dochodzenia, analizy i konserwacja są również śledzone w zadaniach.
- Etykiety GitLab: zadania automatyzacji są uruchamiane na podstawie określonych etykiet, które boty wykorzystują do śledzenia aktywności zadań.
Zewnętrzne:
- PagerDuty: powiadomienia
- Slack: tutaj kierowany jest strumień wiadomości z PagerDuty/AlertManager. Integracja z komendami slash pozwala na realizację różnych zadań, takich jak: zamknąć powiadomienie lub eskalować do incydentu.
- Grafana: wizualizacja metryk z fokusowaniem na długoterminowych trendach.
- Kibana: oferuje wizualizację/przeszukiwanie w dziennikach, możliwość zagłębiania się w określone zdarzenia.
- Zoom: jest stała "sala dyskusyjna" w Zoom. Pozwala to inżynierom SRE szybko omawiać zdarzenia, nie tracąc cennego czasu na tworzenie pokoju i linków dla uczestników.
I wiele, wiele więcej.
4. Monitorowanie GitLab.com przy użyciu GitLab — to jedyny punkt awarii
Jeśli na GitLab.com wystąpi poważna awaria usług, nie chcielibyśmy, aby wpłynęło to na naszą zdolność do rozwiązania problemu. Można to zminimalizować, uruchamiając drugi instance GitLab do zarządzania GitLab.com. W rzeczywistości już to mamy: .
5. Kilka funkcji, które warto rozważyć do dodania do GitLab
- , podobnie jak Google Docs. To pomogłoby w zadaniach związanych z incydentami w trakcie wydarzeń, a także w zadaniach analizujących. W obu przypadkach wielu uczestników mogłoby potrzebować dodać coś w czasie rzeczywistym.
- Więcej webhooków do zadań. Możliwość uruchamiania różnych kroków w procesie pracy GitLab wewnątrz pomoże zmniejszyć zależność od integracji Slack. Na przykład, możliwość umożliwienia powiadomienia w PagerDuty za pomocą komendy slash w zadaniu GitLab.
Podsumowanie
Inżynierowie SRE zmagają się z wieloma trudnościami. Byłoby świetnie zobaczyć więcej produktów GitLab w rozwiązywaniu tych problemów. Już pracujemy nad kilkoma dodatkami do produktu, które ułatwią wspomniane powyżej procesy pracy. Szczegóły można znaleźć w .
W 2020 roku rozszerzamy zespół, aby zebrać wszystkie te wspaniałe funkcje. Jeśli jesteś zainteresowany, zapoznaj się proszę z , i nie wahaj się skontaktować z kimś z naszego zespołu w razie jakichkolwiek pytań.
Źródło: habr.com
