Cultivating Production Excellence • Liz Fong-Jones • YOW! 2019
Еще один доклад про SRE практики от инженера, который получил их работая в Google. Liz Fong-Jones только в начале 2019 года ушла в Honeycomb, а до этого 10 лет работала в Google. Интересно, что новая компания Liz занимается observability инструментами, которые полезны инженерам, заботящимся о надежности своих систем.
Основные тезисы доклада такие
- Production системы становятся все сложнее (особенно при использовании микросервисов и big data) и укратить эту сложность бывает сложно
- Что такое надежность и как ее померить (и что такое uptime)?
- Не стоит покупать DevOps - это не коробки вида Honeycomb, IaaS, K8s, и другие крутые слова. Devops - это пру культуру
- Дальше обсуждение алертов, дашбордов, предсказуемости деплоев, etc
- Возврат от технических систем к социотехническим системам и важность мыслей о людях, кто развивают и поддерживают наши системы
- Лиз предлагает инвестировать в культуру, людей и процессы для того, чтобы повысить надежность систем - и именно это она называет production excellence
- Для повышения production excellence она предлагает целый комплекс мер
- Составить план, опредлиться с метриками и смотреть как они улучшаются
- Вовлекать всех (не только инженеров, но и продактов, финансистов и саппорт)
- Начать Лиз предлагает с того, чтобы научить определять, что что-то с продом идет не так и иметь возможность задебажить эту проблему
- И более сложный совет - это устранить ненужную сложность (но проще сказать, чем сделать):)
- Если системы постоянно ломаются по определенным причинам, то стоит устранить эти причины
- Для измерений Лиз предлагает использовать уже стандартные SLI/SLO/SLA - индикаторы, цели и соглашения по уровню оказания сервисов (это стоит использовать как общий язык с неинженерными специальностями: продактами, финансистами, etc)
- Дальше Лиз объясняет, что для измерения этих показателей надо понимать какие критичные user journeys и дальше думать в разрезе конкретных событий (events)
- И надо уметь определять хорошее событие или плохое (а также фиксировать как успешные, так и неуспешные события - отсюда можно посчитать availabilty) и выставлять thresholds для уровня доступности
- Тут же упоминается проведение chaos экспериментов для определения чувствительности пользователей к уровню сервиса
- Дальше идет речь про то, как понять какое окно использовать для расчета показателей (день, неделя, месяц, etc)
- Важность не упарываться в надежность чрезмерно - важно искать баланс между затратами на надежность и возможностью выделять время на развитие сервиса через добавление новых фич
- Как использовать SLO для генерации alerts и определение error budgets
- Как использовать данные для того, чтобы понимать сколько сейчас требуется тратить времени команды на надежность (совет ориентироваться на бюджет ошибок)
- Помимо SLI & SLO надо еще уметь дебажить проблемы на проде:)
- Для этого надо использовать observability инструменты (кстати, у нас в Tinkoff есть своя observability платформа Sage, которую даже можно потрогать снаружи)
- Дальше Лиз говорит о том, что надо уметь различать почему у нас есть отклонения в показателей работы разных сервисов
- Ну и заканчивается все возвратом к культурным вопросам: -- что героизм - это не устойчивая стратегия для решения проблем, -- дебаггинг - это совместная работа, надо тренировать команды работать вместе -- требуется документировать архитектурные решения и как работают наши системы -- надо использовать общие инструменты и платформы -- стоит вести blameless postmortems для инцидентов
- Плюс в конце идет речь про управление рисками - про вероятность и влияние, которые определяют уровень риск. Обычно можно уменьшить вероятность проблем, выбрав те, что влияют на SLO и приоритизировав эти задачи в беклоге. Ну и начать надо с улучшения observability.
P.S. На тему надежности можно почитать материалы из моего поста "Проектируем надежные системы"
#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE #Reliability #Conference