Автор: Марцин Дерило, Site Reliability Engineer в DataArt

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

РЕШЕНИЕ: SITE RELIABILITY ENGINEERING (SRE)

В 2003 году в Google решили испытать новый подход к решению этой проблемы — создали так называемую «продакшн-команду» из семи человек, призванную разобраться, как новые фичи повлияют на систему в целом и не потребует ли их внедрение изменить привычный порядок ее эксплуатации. Подход со временем эволюционировал, количество SRE-специалистов выросло на несколько порядков и продолжает расти ежемесячно, но их основные функции остались примерно теми же.

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

ЧТО ТАКОЕ НАДЕЖНОСТЬ?

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

Однако SRE-специалистам необходимы четкие метрики, которые помогут отследить, насколько хорошо работает их команда. Поэтому в SRE введено понятие Индикаторов уровня обслуживания (Services Level Indicators, SLI): в их качестве могут быть представлены и оценены показатели, определенные как критически важные для конкретного бизнеса. Задача команды SRE — предоставить способы их измерения, определить текущее состояние системы, помочь установить целевые значения для этих метрик и менять систему в заданном направлении.

Цели уровня обслуживания (Service Level Objectives, SLO), акцентируя внимание на аспектах работы системы, наиболее важных для бизнеса и пользователей, помогают устанавливать ожидания на программном уровне. SLO позволяют делать предположения о необходимом уровне надежности того или иного сервиса. При этом эти показатели подвижны: их можно корректировать по ходу работы, в процессе наблюдений за поведением сервиса.

Например, мы хотим, чтобы запросы к нашему сервису обрабатывались за 50 миллисекунд в 99 % случаев. Нужно учитывать некоторые погрешности целевых показателей — 100 % SLO достичь нереально, ожидать абсолютной стабильности сервиса бессмысленно. Не забывайте, что нельзя контролировать всего, включая, к примеру, сети. Кроме того, чем ближе мы приближаемся к 100 % намеченных SLO, тем дороже оказывается дальнейшее улучшение показателей.

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

Смысл же SRE-подхода в том, чтобы обеспечить сервису достаточную надежность, оставив пространство для возможных изменений и заложив погрешность на случай выявления проблем и ошибок в будущем. Это называется бюджетом на исправление ошибок (100 % минус ваш показатель SLO). По мере выхода новых версий ПО вы можете следить за оставшимся бюджетом на ошибки, скоростью его расхода и на основе этого принимать решения. Если он тает слишком быстро, возможно, вам стоит притормозить, или уделить больше внимания тестированию перед релизом. Бюджет на ошибки должны видеть все: разработчики, специалисты поддержки, SRE, представители бизнеса. Контроль за ним должен естественным образом уравновешивать инновации и стабильность, минимизируя конфликты между командами разработчиков, которые вносят изменения, и SRE, ответственных за стабильность систем.

ОСНОВЫ РАБОТЫ SRE

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

Помимо того, SRE должны реагировать на инциденты, решать ряд несрочных вопросов по продакшену и т. д. Если такой работы слишком много, команда может заскучать, что негативно сказывается на мотивации. Поэтому объем рутины нужно ограничивать — в Google лимит на нее установлен на уровне 50 %.

У SRE-специалиста бывают дни, в которых больше рутинной работы, и дни, когда можно сосредоточиться исключительно на инжиниринге. Но что делать, если первых слишком много? Прежде всего, об этом должен узнать менеджер, ответственный за SRE: возможно, вам стоит настоять на расширении команды, чтобы распределить нагрузку, или передать часть задач команде разработчиков. В принципе, ограничение объема рутинной работы входит в зону ответственности SRE. Если вовремя не озаботиться этой проблемой, она напрямую помешает основной задаче — инжинирингу: поиску возможностей для улучшения, внедрения инноваций, повышения производительности и стабильности систем.

Собственно инженерная деятельность SRE-специалистов бывает двух видов.

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

2) Системный инжиниринг — настройка сервисов и инфраструктуры, включая виртуальные машины, актуализация важной документации, сопровождение систем; мониторинг системы в постоянном контакте с разработчиками (чтобы всегда знать, что работает, а что нет).

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

Кстати, не обращаясь к ресурсам бюджета на ошибки, вы довольно сильно рискуете. В одной из книг, написанной SRE-командой Google, есть классная история о распределенном сервисе блокировки. Он был действительно стабильным и надежным — настолько, что многие другие сервисы стали полагаться на него. Но однажды случилось невероятное: работать он перестал, а вместе с ним и другие, выстроившие с ним излишние зависимости. Команда, стоящая за этой системой, опубликовала свои SLO, чтобы все могли скорректировать ожидания с учетом заявленных показателей надежности. Чтобы убедить другие команды, что их сервис вовсе не образец абсолютной надежности, они даже начали специально запускать искусственные перебои в продакшене. Так их бюджет на исправление ошибок оказался израсходован. Мораль: мы должны тратить бюджеты на ошибки, экономить их бессмысленно, а порою даже вредно.

Следующий важный элемент SRE — мониторинг. Существует несколько способов контроля состояния системы: например, оповещения, тикеты в JIRA или других системах, логирование.

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

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

Также необходимо укреплять уверенность в себе у ответственных за чрезвычайные ситуации, готовя их с помощью ролевых игр. Например, Google использует упражнения Wheel of Misfortune («Колесо неудач»), которые учат не волноваться, когда звонит телефон или включается сигнал тревоги.

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

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

Как я узнал на конференции в Дублине в этом году: во время интервью в Google кандидатам на позиции SRE предлагают упражнения по планированию нагрузки. К заданию на разработку системы (например, службы обмена фотографиями) добавляют данные о том, сколько пользователей зарегистрируется, сколько фотографий будет загружаться ежедневно и т. д. В ответ нужно назвать точные цифры: сколько машин вам нужно, сколько дискового пространства и т. д.

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

ПАРА СОВЕТОВ И РЕКОМЕНДАЦИЙ

Получается, для повышения надежности существует не так много возможностей:

1. ДЕНЬГИ — вкладывая в систему дополнительные средства, вы получите больше избыточных ресурсов или более крупные сервера.
2. СНИЖЕНИЕ КАЧЕСТВА: неполная загрузка сайтов, автоматическое прерывание операций с вызовом резервных ответов. Этот путь временами ограничивает функционал, зато позволяет системе продолжать работу и в случае ошибок, при которых иначе она бы отключилась.&nbs
3. УВЕЛИЧЕНИЕ ВРЕМЕНИ ОЖИДАНИЯ — повторные попытки, экспоненциальное откладывание запроса и джиттеры: в этом случае ради надежности вы жертвуете временем.

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