Надежно, как у Google: почему SRE-подход поможет вашим сайтам работать без перебоев

Опубликовано От Sergey

Антон Скобин, коммерческий директор учебного центра «Слёрм», рассказывает о подходе Google к работе над надежностью сайтов. Автор объясняет принципы подхода и рассказывает, почему он будет полезен не только сервисам компаний-гигантов.

Надежно, как у Google: почему SRE-подход поможет вашим сайтам работать без перебоев

Антон Скобин

По оценкам Gartner, к 2021 году рынок SaaS вырастет более чем на 15%. Вслед за спросом растут и требования пользователей — например, к стабильности работы SaaS-решений. Мы привыкли, что сайты крупных компаний доступны всегда, и ожидаем того же от всех сервисов в интернете.

Инженеры Google занимаются вопросами надежности более 20 лет. За это время они сформировали подход, благодаря которому поиск, почта, облака и другие сервисы компании работают без перебоев. Этот подход называется Site Reliability Engineering (SRE) — проектирование надежности сайтов. Сейчас он становится все более популярным. Не только зарубежные, но и российские IT-компании активно нанимают инженеров по SRE.

В 2019 году мы запустили первый в России курс по Site Reliability Engineering (ближайший набор стартует в декабре). В этой статье расскажем об основных принципах SRE и его преимуществах для бизнеса.

Что такое SRE

Работу компаний, которые предоставляют SaaS-решения, можно свести к двум задачам:

  • улучшать продукт, исправляя ошибки и добавляя новые возможности;
  • поддерживать стабильность того, что выпустили.
  • Часто эти задачи противоречат друг другу: чем больше нового кода добавляют в приложение или на сайт, тем выше вероятность, что все сломается. На командном уровне это противоречие выражается в разногласиях между отделами разработки и эксплуатации. На уровне бизнеса — в необходимости искать баланс между доходами от новых пользователей и потерями из-за оттока старых, а также затратами на поддержку.

    Чтобы разрешить это противоречие, IT-сообщество разработало подход DevOps. Он отвечает на вопрос: как программистам, тестировщикам и системным администраторам взаимодействовать друг с другом, чтобы в результате получался качественный продукт? Для многих компаний DevOps оказался полезным, но отвечал не на все вопросы.

    Параллельно в Google искали свое решение проблемы. Долгое время компания не рассказывала о нем, считая коммерческой тайной, но позже решила раскрыть и опубликовала книгу «Site Reliability Engineering: как Google запускает эффективные системы». С тех пор концепция начала распространяться.

    Основные принципы SRE

    Концепция SRE содержит много конкретных практик, однако в их основе лежат несколько базовых принципов.

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

    И не все зависит от нашей воли. Случайности происходят, люди делают ошибки, экскаваторы коммунальщиков повреждают кабели. Надежда — это не стратегия. Надейся на лучшее, но готовься к худшему, говорят в Google.

    Закрепление уровня обслуживания. Вместо бездумной погони за 100% аптаймом или слепой веры в удачу SRE-подход предлагает ввести практику управления рисками. Компания должна принять, что ошибки и падения неизбежны, и определить уровень надежности сервиса, который будет для неё приемлемым (SLO). 

    SLO — это внутренний документ, но указанные в нем метрики должны быть как можно ближе к пользователю и как можно конкретнее. Команда использует SLO для приоритизации задач и оценки своей работы. На основе SLO определяют бюджет на ошибки (Error budget).

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

    Отказ от рутины и автоматизация. Ключевая задача SRE — обеспечение надежности. Когда речь идет о повторяющихся задачах, скрипт выполнит их качественнее и быстрее человека: на что у человека уйдет 10 минут, скрипт сделает за секунды. Поэтому все рутинные операции должны быть автоматизированы.

    Релиз-инжиниринг. Так как выпуск новых возможностей сильно влияет на стабильность сервисов, инженеры по SRE участвуют в разработке CI/CD-пайплайнов. Цели здесь те же — автоматизировать то, что можно автоматизировать, подготовиться к непредвиденным ситуациям и по возможности снизить их риски. Например, с помощью «канареечных релизов»i.

    Unsplash

    Некоторые практики 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. На русском языке есть несколько публикаций на «Хабре» и наш курс.

    Фото на обложке: Shuttertsock/Illus_man

    Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

    Источник: https://rb.ru/

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *