SRE. Как обеспечить непрерывность работы веб-сервисов?

За последние 5 недель наши заказчики стали значительно чаще задаваться одним и тем же вопросом – как обеспечить непрерывную работу своих онлайн-сервисов? Это, в том числе, связано с тем, что в 2022 году резко увеличилось количество кибератак.

Поэтому мы написали развёрнутый материал для владельцев бизнеса, завязанного на работе веб-сервисов.

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

Как потерять 100 млн. рублей за несколько часов?

С начала года эксперты фиксируют резкий рост количества и продолжительности кибератак. Это касается каждого владельца нагруженных веб-приложений и сайтов.

По результатам исследования Positive Technologies:

• количество атак увеличилось на 14,8% по сравнению с IV кварталом 2021 года.
• увеличилась доля массовых атак: теперь их количество составляет 33% от общего числа.
• Чаще всего в результате атак организации сталкиваются с утечкой конфиденциальной информации (45%) и нарушением основной деятельности (30%).
• В атаках на частных лиц чаще всего были скомпрометированы конфиденциальные данные (55%), также пользователи могли понести финансовые потери (25%).

Понятно, что простой приложения или сайта бьёт по выручке. Но часто мы даже не представляем, насколько сильно. Бизнес осознаёт, к чему приводит, например, остановка инфраструктуры маркетплейса в день распродажи.

Пример из практики:

Заказчик — крупный дистрибьютор продуктов питания в Казахстане (более 200 магазинов и 6000 сотрудников).

В ноябре 2020 года в ЦОДе, где была размещена ИТ-инфраструктура, произошла авария. 1С не доступна, работа точек по всей стране парализована. За 8 часов простоя организация потеряла более 100 млн. рублей.

После инцидента компания стала клиентом Cortel с запросом: сделать так, чтобы подобного не повторилось.

Для этого Cortel разбила сервера и базы данных на кластеры, затем настроила резервное копирование на каждой площадке

Что в итоге?

– 1С работает непрерывно под SLA 99,955

– Менее 4 часов простоя бизнес-критичных приложений в год, что соответствует требованиям бизнеса.

Как посчитать потери?

Период от остановки сервиса до его полного восстановления называют “простой” и у него есть стоимость, которая складывается из:

• потери дохода компании за период простоя;
• стоимости восстановления веб-сервиса после сбоя;
• размера потерь, связанных с падением производительности сотрудников;
• упущенной прибыли от потери лояльности клиентской базы.

Пример:
Если IT-инфраструктура Amazon остановится на минуту, потери сервиса составят порядка 66 240 долларов.

Стоимость простоя рассчитывается индивидуально и формируется из целей, возможностей и требований компании.

Представьте ситуацию: ваш бизнес остановился из-за простоя критичного веб-приложения. Сколько это будет стоить в случае остановки на 8 часов? А 48? Можете ли вы получить точные данные относительно каждого источника потерь?

Какой подход придумали в Google, и почему это в корне изменило подход к ИТ-инфраструктуре?

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

Как ей это удалось? В компании изменили подход к работе с непрерывностью веб-сервисов.

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

• Задача команды разработки – оперативно создавать конкурентоспособные обновления.
• Миссия операционных служб – сохранить стабильность приложения.
  Они напрямую противоречат друг другу и создают конфликт интересов: чем больше обновлений, тем выше угроза нарушения непрерывной работы.

Так в 2003 году, под руководством Бена Трейнора Слосса, в Google возникла первая команда SRE (Site Reliability Engineering), которая напрямую занималась проектированием надёжности сайтов.

Ключевая задача SRE — поддерживать в работоспособном состоянии веб-системы, от которых зависит выручка и чистая прибыль.

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

SRE-инженеры обеспечивают стабильную и предсказуемую работу приложений/сайтов и т.д, обнаруживая проблемы до того, как о них сообщит клиент. Они объединяют команды разработки и операционные службы – и выстраивают единый, слаженный процесс.

Руководитель отдела по SRE в Google Эндрю Уидоусон описывает свою команду так:

«Мы — как самый быстрый в мире экипаж механиков. Мы на лету меняем шины гоночного автомобиля, мчащегося со скоростью 160 километров в час».

Как SRE распространился за пределы Google

Вслед за Google SRE стали внедрять крупные мировые компании:

– В Facebook команду SRE создали к 2010 году.

– Netflix собрал «основную команду SRE» к 2016 году.

– В том же году компания Uber заявила о том, как она использует SRE.

– В 2017 году компания LinkedIn уже говорила о своей «культуре SRE».

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

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

Например, 10 лет назад для развертывания 2000 серверов нужно было 2000 раз выполнить один и тот же длинный список функций по установке операционной системы. Сейчас это происходит в облаке за несколько десятков минут путем вызова всего одной функции.

Как считать и контролировать SRE

Внедрение SRE приносит конкретные бизнес-результаты, помимо непрерывной работы веб-сервисов:

• Снижение рисков при создании обновлений (выбор неверных технологий, ошибки в коде, отсутствие проверок доступа и защиты от основных типов атак (XSS, SQL injection, DOS и др.), неверный выбор интеграций)
• Кратное увеличение скорости разработки
• Сокращение затрат на ФОТ

Чтобы отслеживать, насколько стабильно работает сервис, специалисты SRE выбирают ключевые метрики, собранные в соглашении о целевом уровне обслуживания — Service-Level Objective (SLO).

SLO позволяет всем в компании прийти к общему пониманию требований к надежности, стабильности и доступности. В соответствии с этим закрепляются целевые показатели.

Чтобы их измерить, соглашение содержит конкретные числовые показатели — Service Level Indicator (SLI). Это может быть время ответа, количество ошибок в процентном соотношении, пропускная способность и т.д. — показатели выбираются в зависимости от продукта.

SLO и SLI — это внутренние соглашения, нужные для взаимодействия команды. Обязанности перед клиентами закрепляются в Service Level Agreement (SLA). Это соглашение описывает работоспособность всего сервиса, штрафы за превышение времени простоя или другие нарушения.

Пример SLA:

• сервис доступен 99,95% времени в течение года;
• 99 критических “тикетов” техподдержки будет закрыто в течение трёх часов за квартал;
• 85% запросов в месяц получат ответы в течение 1,5 секунд.

Таким образом, бизнес получает гарантированную непрерывность работы приложений в соответствии с заявленными характеристиками. Если компания может допустить простой сервиса в течение часа в сутки без потерь – в SLA стоит час. Если приложение критичное для бизнеса, и максимальное время простоя – 20 минут в год – специалисты применяют лучшие практики, чтобы добиться этого.

Как внедрять и использовать SRE подход

Специалистов SRE высоко ценят в Google, Apple и Microsoft, в России же эта позиция — пока редкость.

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

В Tinkoff, к примеру, вопросом непрерывности занимается 80 SRE-команд — от 4 до 8 человек в каждой. Минимальная сумма заработной платы такого специалиста – 150.000 рублей.

Разберём, что делать компании, чтобы самостоятельно внедрить SRE?

Шаг №1: определиться – нужно ли это компании

Первый вопрос, который следует задать: «Соответствует ли текущий уровень доступности сервиса бизнес-целям?». Для ответа необходимо определить показатели – SLI, SLO – и соотнести ожидания с реальностью.

Если соответствует, то на этом пункте можно остановиться 🙂

Однако, по нашему опыту, в 95% случаев картина “Ожидание – реальность” вынуждает предпринимать срочные действия.

Шаг №2: выбрать инструменты

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

Чтобы выбрать из всего многообразия практик, важно оценивать влияние каждой и внедрять самые результативные. Без этого организация рискует впустую потратить бюджет и время, закупить дополнительный функционал, нанять отдельных специалистов, но так и не обеспечить необходимый уровень непрерывности. Например, один из основных инструментов SRE — это Kubernetes. Нужно ли в таком случае немедленно разворачивать кластер K8s? Если есть понимание, что в текущей ситуации пользы от этого не будет, то лучше разобраться с другими аспектами, а не внедрять Kubernetes.

Нет универсального чек-листа, по которому можно проверить надёжность любого сервиса. Такой чек-лист варьируется от компании к компании. Их объединяет одно: проверка должна проходить на каждом из уровней:

1. Проектирование
2. Разработка
3. Тестирование
4. Выкатка
5. Документирование
6. Мониторинг
7. Нагрузочное
8. Приемка
9. Эксплуатация

“Некоторые думают, что SRE — это что-то странное. Необязательно использовать эту аббревиатуру. Можно просто брать конкретные практики, и шаг за шагом внедрять их. Только нужно знать, что и в какой последовательности применять. Для этого сначала надо понять, что проще и быстрее всего сделать именно для вашей системы” — Владимир Федорков, специалист SRE.

Шаг №3: выбрать стратегию внедрения

Существует 2 варианта:
1. Сразу создавать стратегию внедрения SRE. Собрать аналитику, конкретные цифры, рассчитать стоимость простоя и количество прибыли, которое теряет бизнес. Понять, смогут ли сотрудники справиться с внедрением самостоятельно или потребуется нанимать дополнительных специалистов. Выбрать максимально эффективные практики, подходящие в конкретной ситуации
2. Начать «с низов». Один отдел начинает использовать инструмент, и со временем подход внедряет вся компания, в стремлении получить те же результаты и удобство. Желательно, чтобы у “пилотного” отдела была минимальная загруженность бизнес-задачами, иначе велик риск сбить рабочий график.

Как собрать команду SRE?

По нашим наблюдениям, бизнес начинает с подбора инструментария, затем формирует методологию, и только потом – собирает команду. Как правило, она состоит из сотрудников, которые хорошо понимают продукт и знают его проблемы, но уже занимаются ключевыми вопросами в сервисах компании, а SRE становится для них “приятным бонусом”. Тут критично важна система мотивации и распределения нагрузки.

Site Reliability Engineering — не должность. Это подход и образ мышления. Иногда бизнес понимает это только к середине проекта по модернизации и только там приступает к подбору специалистов.

Важно учитывать: ИТ инфраструктура в рамках SRE подхода строится на стандартах надежности и доступности, над чем работают многие сотрудники компании, поэтому SRE – не только про технологии, но и про коммуникации, а чем раньше новый эксперт освоится и “вольётся” в процессы компании, тем ближе бизнес-результаты внедрения SRE подхода.

Так возникает культура SRE, основные принципы которой:

• Совместное владение — все команды, которые работают над проектом, преследуют одну цель.
• Blame-less культура — при ошибке не ищут виноватых, а вместе разбираются над проблемой.
• Постоянное измерение. Алгоритм принятия решений строится на основе данных, которые регулярно обновляются. Значит, их необходимо считать.
• Инкрементальные изменения. Дробление работы на мелкие итерации и создание стабильных промежуточных результатов.
• Автоматизация. Все, что можно автоматизировать, нужно автоматизировать.

Что делать, если для самостоятельного SRE не хватает времени или ресурсов?

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

Компании, предоставляющие такие ИТ-сервисы, специализируются достаточно узко, знают область глубже и детальнее. В условиях конкуренции на рынке сервис-провайдеры вынуждены быть “идеальным ИТ-отделом” для того, чтобы существовать и работать эффективно.

Конечный продукт – решение для бизнеса при таком варианте подхода – намного выгоднее.

К примеру, в команде поставщика на одного DevOps-специалиста приходится 10 компаний – и он занимается исключительно своими прямыми обязанностями. В компаниях же, в большинстве случаев, на того же специалиста возлагается ряд других задач, не являющихся его профильными. О том, к чему приводит увеличение нагрузки на ИТ-отдел, мы говорили в одном из предыдущих материалов.

Подрядчик предоставляет гарантии, в рамках SLO, SLI и SLA, где описаны конкретные параметры качества услуг, за исполнение которых он несёт финансовую ответственность и обеспечивает бизнес-метрики, которые обозначает заказчик.

Будущее SRE

Два десятилетия назад SRE зародился как узкий подход в крупной компании для решения её высоконагруженных задач.

Мы наблюдаем, как эта практика развивается и с годами становится только популярнее. Даже если темпы её распространения снизятся, подход настолько прочно утвердился в рынке, что трудно представить будущее, в котором SRE нет места.