SRE-інженер - стажист
Для початку дозвольте представитися. Я - , фронтенд-інженер у групі GitLab'а. Минулого тижня мені випала честь побути стажером одного з наших чергових SRE-інженерів. Метою було щоденне спостереження за тим, як черговий реагує на інциденти, та набуття реального досвіду роботи. Нам хотілося б, щоб наші інженери краще розуміли потреби користувачів Monitor::Health.
Мені треба було тиждень усюди слідувати за SRE-інженером. Тобто я був присутній на передачі чергування, спостерігав за тими самими каналами сповіщень та реагував на інциденти, якщо і коли вони мали місце.
Інциденти
За тиждень сталося 2 інциденти.
1. Криптомайнер
У середу на GitLab.com зафіксували стрибок у використанні 'а, викликаний спробами використовувати хвилини runner'а для майнінгу криптовалюти. З інцидентом розібралися за допомогою власного інструменту нейтралізації порушень, який зупиняє завдання runner'а та видаляє пов'язані з ним проект та обліковий запис.
Якби цю подію не помітили, її відловив би автоматизований інструмент, але в цьому випадку SRE-інженер помітив порушення першим. Було створено завдання щодо інциденту, проте інформація щодо неї закрита.
2. Деградація продуктивності додатків Canary та Main
Інцидент спровокували уповільнення та зросла частота помилок у canary та main веб-додатках на Gitlab.com. Було порушено кілька значень Apdex.
Відкрите завдання щодо інциденту:
Ключові висновки
Ось кілька моментів, які я зрозумів за тиждень чергування.
1. Оповіщення найкорисніші, коли засікають відхилення від норми.
Оповіщення можна розділити на кілька типів:
- Оповіщення, засновані на певному пороговому значенні типу «відбулося 10 5хх помилок в секунду».
- Оповіщення, у яких поріг - це відсоткове значення типу "частота 5хх помилок на 10% загального обсягу запитів у заданий час".
- Оповіщення, що ґрунтуються на історичному середньому значенні типу «5хх помилок у 90-й процентилі».
Якщо говорити загалом, то 2-й та 3-й типи корисніші для чергових SRE, оскільки розкривають відхилення від норми у процесі.
2. Багато оповіщень так і не ескалуються до інцидентів
SR-інженери мають справу з постійним потоком оповіщень, багато з яких насправді не є критичними.
То чому б не обмежити оповіщення лише справді важливими? З таким підходом, однак, можна не розпізнати ранні симптоми того, що виросте, як снігова куля, в реальну проблему, що загрожує великими збитками.
Завдання чергового SRE у тому й полягає, щоб визначати, які сповіщення дійсно говорять про щось серйозне, і чи треба їх ескалювати та починати розбиратися. Підозрюю, це викликано ще й негнучкістю оповіщень: було б краще, якби ввели кілька рівнів або «розумні» способи налаштування оповіщень відповідно до описаної вище ситуації.
Пропозиція щодо функції:
3. Наші чергові SRE використовують багато інструментів
Внутрішні:
- GitLab infra project: тут живуть Runbook'и, передачі чергування на зміну/тиждень, завдання відповідей на інциденти.
- GitLab issues: розслідування, розбори та обслуговування також відслідковуються у завданнях.
- GitLab labels: завдання автоматизації запускаються за певними мітками, якими боти відстежують активність завдань.
зовнішні:
- PagerDuty: оповіщення
- Slack: сюди прямує потік повідомлень PagerDuty/AlertManager. Інтеграція зі слеш-командами для виконання різноманітних завдань, як-от: закрити оповіщення або ескалировать до інциденту.
- Grafana: візуалізація метрик із фокусом на довгострокових трендах.
- Kibana: дає візуалізацію/пошук у журналі, можливість копати глибше у певних подіях.
- Zoom: є постійно працююча «кімната обговорення» в Zoom. Це дозволяє SRE-інженерам швидко обговорювати події, не витрачаючи дорогоцінного часу на створення кімнати та посилання учасникам.
І багато багато іншого.
4. Моніторинг GitLab.com за допомогою GitLab – це єдина точка відмови
Якщо на GitLab.com відбудеться велика відмова сервісів, нам не хотілося б, щоб це вплинуло на нашу здатність вирішити проблему. Її можна купірувати, запустивши другий інстанс GitLab для вирівнювання GitLab.com. Насправді це вже працює у нас: .
5. Декілька функцій, які слід розглянути до додавання в GitLab
- , аналогічне до Google Docs. Це допомогло б у завданнях щодо інцидентів у ході події, а також у завданнях із розборів. В обох випадках одразу декільком учасникам може знадобитися додати щось у реальному часі.
- Більше веб-хуків для завдань. Можливість запускати різні кроки робочого процесу GitLab зсередини допоможе зменшити залежність від інтеграцій Slack. Наприклад, можливість дозволити оповіщення в PagerDuty через слеш-команду в задачі GitLab.
Висновок
SRE-інженерам доводиться нелегко з багатьма складнощами. Було б чудово побачити більше продуктів GitLab у вирішенні цих проблем. Ми вже працюємо над деякими додаваннями до продукту, які полегшать згадані вище робочі процеси. Деталі доступні в .
У 2020 році ми розширюємо команду, щоб зібрати всі ці чудові функції. Якщо цікаво, ознайомтеся, будь ласка, з , і не соромтеся зв'язуватися з кимось із нашої команди з будь-яких питань.
Джерело: habr.com