По оценкам Gartner, к 2021 году рынок SaaS вырастет более чем на 15%. Вслед за спросом растут и требования пользователей — например, к стабильности работы SaaS-решений. Мы привыкли, что сайты крупных компаний доступны всегда, и ожидаем того же от всех сервисов в интернете.
Инженеры Google занимаются вопросами надежности более 20 лет. За это время они сформировали подход, благодаря которому поиск, почта, облака и другие сервисы компании работают без перебоев.
Этот подход называется Site Reliability Engineering (SRE) — проектирование надежности сайтов. Сейчас он становится все более популярным. Не только зарубежные, но и российские IT-компании активно нанимают инженеров по SRE.
В 2019 году мы запустили первый в России курс по Site Reliability Engineering (ближайший набор стартует в мае 2021 года). В этой статье расскажем об основных принципах SRE и его преимуществах для бизнеса.
Что такое SRE
Работу компаний, которые предоставляют SaaS-решения, можно свести к двум задачам:
- Улучшать продукт, исправляя ошибки и добавляя новые возможности.
- Поддерживать стабильность того, что выпустили.
Часто эти задачи противоречат друг другу: чем больше нового кода добавляют в приложение или на сайт, тем выше вероятность, что все сломается. На командном уровне это противоречие выражается в разногласиях между отделами разработки и эксплуатации. На уровне бизнеса — в необходимости искать баланс между доходами от новых пользователей и потерями из-за оттока старых, а также затратами на поддержку.
Чтобы разрешить это противоречие, IT-сообщество разработало подход DevOps. Он отвечает на вопрос: как программистам, тестировщикам и системным администраторам взаимодействовать друг с другом, чтобы в результате получался качественный продукт? Для многих компаний DevOps оказался полезным, но отвечал не на все вопросы.
Параллельно в Google искали свое решение проблемы. Долгое время компания не рассказывала о нем, считая коммерческой тайной, но позже решила раскрыть и опубликовала книгу «Site Reliability Engineering: как Google запускает эффективные системы». С тех пор концепция начала распространяться.
Основные принципы SRE
Концепция SRE содержит много конкретных практик, однако в их основе лежат несколько базовых принципов.
Принятие рисков. С точки зрения бытовой логики, компании вроде Google должны стремиться создавать сервисы со 100% надежностью. Однако в Google считают, что подобное стремление принесет больше вреда, чем пользы. Оно ограничивает количество новых возможностей и скорость, с которой они выходят, а также кратно увеличивает стоимость сервиса для пользователей.
И не все зависит от нашей воли. Случайности происходят, люди делают ошибки, экскаваторы коммунальщиков повреждают кабели. Надежда — это не стратегия. Надейся на лучшее, но готовься к худшему, говорят в Google.
Закрепление уровня обслуживания. Вместо бездумной погони за 100% аптаймом или слепой веры в удачу SRE-подход предлагает ввести практику управления рисками. Компания должна принять, что ошибки и падения неизбежны, и определить уровень надежности сервиса, который будет для неt приемлемым (SLO).
SLO — это внутренний документ, но указанные в нем метрики должны быть как можно ближе к пользователю и как можно конкретнее. Команда использует SLO для приоритизации задач и оценки своей работы. На основе SLO определяют бюджет на ошибки (Error budget).
Мониторинг. Отслеживать выполнение SLO не получится, если нет мониторинга. Поэтому в рамках SRE обязательно должен быть настроен сбор, обработка, агрегирование и отображение данных о системе. Какие из этих данных надо регулярно отслеживать, а об изменении каких показателей сообщать — отдельный вопрос, который SRE решает, исходя из задач бизнеса.
Отказ от рутины и автоматизация. Ключевая задача SRE — обеспечение надежности. Когда речь идет о повторяющихся задачах, скрипт выполнит их качественнее и быстрее человека: на что у человека уйдет 10 минут, скрипт сделает за секунды. Поэтому все рутинные операции должны быть автоматизированы.
Релиз-инжиниринг. Так как выпуск новых возможностей сильно влияет на стабильность сервисов, инженеры по SRE участвуют в разработке CI/CD-пайплайнов. Цели здесь те же — автоматизировать то, что можно автоматизировать, подготовиться к непредвиденным ситуациям и по возможности снизить их риски. Например, с помощью «канареечных релизов».
Некоторые практики SRE
Постмортем. Так как простои и ошибки неизбежны, нужен формальный процесс работы с ними. В SRE он называется «постмортем»: когда случается сбой, команда сначала устраняет его, а потом обязательно пишет отчет, где описывает инцидент, его причины, последствия и действия, которые должны предотвратить повтор ошибок в будущем.
Важно! При анализе инцидентов не ищут виноватых среди сотрудников. По умолчанию считается, что виноваты не люди, а несовершенные процессы.
Тестирование аварийного восстановления. В Google регулярно моделируют инциденты и намеренно останавливают самые разные службы. В Netflix запускают утилиты, которые «роняют» серверы в продакшене. Такое тестирование помогает находить слабые места и слепые зоны, а также запускать процессы для их исправления. Оно требует времени, но в итоге окупаются, говорят в Google.
Кто занимается SRE, и что конкретно он делает
Обычно это либо один человек в продуктовой команде, либо, если компания большая, выделенная команда инженеров по SRE.
Специалист по SRE — это опытный разработчик с обширными знаниями в системном администрировании и управлении сетями.
Предпочтение отдается программистам, потому что инженер по SRE должен быть по-хорошему ленивым: не править одну и ту же ошибку вручную, а написать скрипт, который исправит проблему сейчас и в будущем. На практике в России на роль SRE нередко нанимают системных администраторов, которые умеют программировать.
Задачи инженера по SRE отличаются от компании к компании. Перечислим базовые:
- Разработка, внедрение и поддержка инструментов развертывания систем (CI/CD-пайплайны, конфигурации).
- Построение системы реагирования и мониторинга.
- Повышение надежности систем и скорости реакции на инциденты.
- Разбор инцидентов и создание автоматически решений для их устранения.
Какие проблемы бизнеса решает SRE
SRE решает те же проблемы, что и DevOps: увеличивает скорость выхода новых фич и налаживает процессы в команде. Но в отличие от DevOps, SRE делает больший упор на стабильность и надежность работы сервисов, поэтому если для вашего бизнеса эти показатели критичны, то SRE окажется полезным.
Вам точно нужно внедрять SRE, если пользователи жалуются на сбои, обращаются в поддержку, а команда говорит, что все в порядке — «графики зеленые».
Подход SRE предполагает, что графики строятся на показателях, которые максимально приближены к пользователям: мерим не место на диске, а скорость ответа, количество ошибочных запросов. Если у пользователей проблемы, то вы об этом знаете и можете выяснить причину. Или не знаете, но хороший инженер по SRE сделает так, чтобы знали.
Где узнать больше об SRE
Посмотрите первоисточник: книги Google по строительству надежных систем, а также лекции компании, например, серию роликов со сравнением DevOps и SRE. На русском языке есть несколько публикаций на «Хабре» и наш курс.
Записаться на курс по SRE можно на сайте учебного центра Слёрм
Партнерский материал
Увы, это не так. В качестве примера - несколько фактов за март, февраль и более ранние месяцы - выбирайте из меню.
https://downdetector.com/status/google/archive/
Причины отказов в обслуживании самые разные, но говорить о работе без перебоев пока не имеет большого смысла. Нужно быть готовым к неприятностям и заранее принимать необходимые меры.
Дело не в Google. Это общая проблема повышения надежности сложных систем.