Чеклист зрелости культуры SRE
Все хотят приложения без даунтаймов и жалоб пользователей на постоянные простои, но не все понимают с чего начать и как подойти к вопросу системно. Обеспечить высокую доступность, надежность и производительность своих сервисов поможет культура 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 февраля!
На курсе вы:
• внедрите правки прямо в прод;
• узнаете, как решать конкретные проблемы, связанные с надежностью сервиса;
• поймете, какие метрики собирать и как это делать правильно;
• научитесь быстро поднимать продакшн силами команды.
Посмотреть программу и записаться.
