Все хотят приложения без даунтаймов и жалоб пользователей на постоянные простои, но не все понимают с чего начать и как подойти к вопросу системно. Обеспечить высокую доступность, надежность и производительность своих сервисов поможет культура SRE. Возможно, в вашей компании уже используются ее отдельные инструменты.

Мы приготовили для вас самотестирование. Пройдитесь хорошенько по всем пунктам, можете даже подключить к обсуждению коллег. По итогу определите, на каком уровне находится культура SRE в вашей компании, чего ей не хватает и нужно ли вам идти на обучение.

1. У вас настроен мониторинг и SLO .

да / нет / что это?

Задача SRE-инженера — обеспечить надежную работу системы и привести компанию к общему пониманию этой самой надежности. Если стабильность никак не измеряется, если значения до и после никак не сравнивать, то процесс улучшения стабильности никак не управляется. SLO показывает реальное положение дел и сигнализирует, когда нужно заниматься разработкой фич, а когда стабильностью

2. Вы считаете error budget и следите за его динамикой.

да / нет / не понимаем, как его использовать / чего бюджет?

Пытаться достичь 100% стабильности не самая лучшая идея, потому что это дорого, технически сложно и порой бесполезно. Поэтому команды всегда принимают некоторую степень риска и прописывают её в SLO. На основе SLO рассчитывается бюджет на ошибки (Error budget). Он помогает договориться с разработкой. О внедрении и работе с SLO, SLI, SLA и error budget мы подробно расскажем в первом модуле курса "SRE: База"

3. Исходя из показателей error budget команды решают, нужно ли брать на следующий спринт больше или меньше задач по повышению стабильности.

да / нет / было бы неплохо / у нас так не работает

Если бюджет на ошибки содержит 43 минуты даунтайма в месяц, и 40 минут из них сервис уже лежал, то очевидно: чтобы оставаться в рамках SLO, надо сократить риски. Как вариант, остановить выпуск фич и сосредоточиться на баг-фиксах.

4. Есть ли уведомления о сбоях (алертинг?)

- Уведомления о сбоях ведутся через единую систему управления инцидентами и коммуникациями

- уведомления о сбоях отправляются в неструктурированые каналы коммуникации

- уведомления о сбоях отсутствуют

5. Организован поток алертов

- да, все работает, как часы

- алертов столько, что не успеваем понять, какой из них критичнее другого

- алерты не срабатывают или приходят слишком поздно

- не понимаю, зачем они нужны

Без мониторинга нельзя понять, вписывается ли команда в бюджет и соблюдает ли критерии, описанные в SLO. Поэтому задача инженера по SRE — настроить мониторинг. Алерты — требуют немедленного действия, поэтому просто настроить их недостаточно, они должны давать полную картину о случившемся, а иногда даже предотвращать инциденты. Вы сделаете базовый дашборд и настроите необходимые алерты на первом практическом задании полного курса

6. Есть четкие инструкции, как действовать в момент инцидента

да / нет / договорились на словах / на месте разберемся

Помните басню "Лебедь, рак и щука"? Так может выглядеть команда во время инцидента, если у нее не будет заранее согласованных четких инструкций. В момент стресса для команды очень важно, чтобы было на что опереться.

7. Инциденты подробно анализируются после разрешения. Все данные записываются в постмортем

да / нет / все же заработало и ладно

Однажды пришел SRE-инженер к мудрецу и спросил, что ему делать. "Учись на своих ошибках, иначе не избавиться тебе от инцидентов, денежных и репутационных потерь", – ответил мудрец и продолжил анализировать данные. На курсе SRE: База вы напишите постмортем по практическому кейсу и разберете его с преподавателем

8. В каждой команде описаны роли, распределены дежурства и зоны ответственности

да / нет / дежурства / роли

Инцидент случился ночью и все спят. Что делать будем? Хорошее управление инцидентами это ключевая часть надежной системы. И если с написанием посмотртемов и blamesless культурой все более-менее понятно, то с тем, правильно организовать incident call, какие роли и best-practices использовать, как организовать передачи дел между сменами — все сложнее. О best practice других компаний в организации инцидент-менеджмента вы узнаете во втором модуле практического курса SRE.

9. Определены и описаны все сервисы, от которых зависит ваш сервис и которые зависят от вас.

да / в процессе / нет / для чего это нужно?

10. Периодическое динамическое тестирование безопасности по запросу и интерактивное тестирование ИБ.

да / нет

11. Используется инструмент управления релизами и его интеграция в процесс развертывания. Автоматический откат приложений.

да / нет / что-то вроде того, но не совсем / отказываемся вручную

Во время обучения вы в полевых условиях научитесь управлять релизами и использовать различные способы деплоймента.

12. Введены практики регулярного тестирования этих зависимостей – Chaos Monkey, Graceful degradation и Anomaly detection.

да, все тестим / нет, не пробовали / слышали, но нет опыта применения /Chaos Monkey?

Проактивное тестирование еще один неотъемлемый подход к обеспечению надежности. Оно позволяет реалистично эмулировать различные проблемы, которые обычно приводят к инцидентам. В результате подобных «экспериментов» система становиться готовой к таким сценариям и не падает во время реальных проблем. Chaos Engineeringмы позволяет нам понять, как деградация одного сервиса (иногда не самого важного на первый взгляд) повлияет на работоспособность другого сервиса.

13. Как осуществляется логирование в компании?

оно отсутствует / сбор и анализ логов ведется через инструмент хранения и визуализации.

Узнать все и сразу о SRE сложно да и не за чем. Чтобы культура прижилась, нужен прочный фундамент. Его возведению посвящен курс SRE:База.

Мы не стали усложнять самотестированием подсчетом баллов и тд. Логика теста простая: чем меньше терминов из списка вам знакомы, чем меньше инструментов и практик вы применяете, тем выше риски возникновения инцидентов в компании. Конечно, от сбоев разного масштаба на 100% не застрахован никто. Однако очень важно знать, какие метрики собирать и как это делать правильно. Кроме того, SRE-инженер должен знать, как анализировать инциденты и снижать риски отказов в будущем.

Если вы чувствуете, что у вас есть пробелы или полностью отсутствует SRE-подход, приходите на курс SRE: data-driven подход к управлению надёжностью систем, который стартует уже 28 февраля!

На курсе вы:

• внедрите правки прямо в прод;

• узнаете, как решать конкретные проблемы, связанные с надежностью сервиса;

• поймете, какие метрики собирать и как это делать правильно;

• научитесь быстро поднимать продакшн силами команды.

Посмотреть программу и записаться.

Чеклист зрелости культуры SRE