Всем привет! Меня зовут Денис Захаров, я инженер в Автотеке Авито — сервисе по проверке истории автомобилей с пробегом. Мы даём бизнесу, связанному с авто, уникальные инструменты за счёт самой полной базы данных истории авто и уникальной технологической платформы.
В этой статье я расскажу о нелёгкой судьбе SRE на своём опыте: с чем я столкнулся в работе и как в общих чертах SRE-направление представлено в Авито. Статья будет полезна как разработчикам, так и малюткам, желающим узнать, что есть в мире IT.
Содержание:
Что, чёрт побери, происходит
Итак, SRE, или Site Reliability Engineering, — это набор практик по обеспечению надёжности системы, а SRE-инженер — человек, который обеспечивает эту самую надёжность, а еще производительн��сть, высокую доступность и масштабируемость системы.
Зачем это нужно?
Сейчас всё живёт в клауде: IT-технологии, веб-приложения, нативные приложения, CI/CD-пайплайны, непрерывная поставка, петабайты данных, законодательные требования — всё это часть одной огромной системы.
Так много компонентов, связанных между собой, — и любой из них может сломаться в один момент. Система становится непредсказуемой, и не всегда понятно, с чего начинать чинить. Возникает вопрос: что мы можем с этим сделать? Мы не можем полностью исключить сбои, но можем снизить их частоту и смягчить последствия. Это важно, потому что, когда что-то ломается:
компания теряет деньги;
эти деньги начинают зарабатывать конкуренты;
саппорт тратит огромное количество времени и ресурсов на разбор инцидентов;
пользователи теряют доверие, и вернуть его гораздо сложнее, чем устранить техническую проблему.
Но сбои бывают не только в IT. Вспомним катастрофу шаттла «Челленджер» в 1986, когда из-за ошибок в инженерных расчётах погиб весь экипаж, а NASA столкнулось с многолетним кризисом доверия.
Или аварию на платформе Deepwater Horizon в Мексиканском заливе в 2010 году, когда при бурении нефтяной скважины произошел взрыв, пожар, случилось масштабное загрязнение океана и в итоге колоссальный репутационный ущерб компании BP.
А в 1999 году во время миссии NASA Mars Climate Orbiter зонд должен был выйти на орбиту Марса, но из-за того, что разные команды использовали разные системы измерений — метрическую и футовую, — аппарат подлетел слишком близко к Марсу и сгорел. Потеря составила сотни миллионов долларов и заставила NASA пересмотреть стандарты взаимодействия между командами.
И, наконец, случай, когда в 1996 году при запуске ракеты Ariane 5 произошла ошибка в программном коде — самое дорогое переполнение целого числа.
Integer overflow just for 370_000_000 $
P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS(
TDB.T_ENTIER_16S((1.0 / C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH))
);
Из-за этого система навигации выдала неверные данные, и ракета взорвалась всего через 40 секунд после старта. Ущерб тогда оценили примерно в 370 млн долларов.
Этого всего не было бы, если бы применялись практики SRE. Собственно, об этом сейчас.
SRE — сервис рестарт-инженер
Начнём с того, что обязанности SRE огромны. Главная из них — быть T-Shape специалистом, то есть мастерски рестартить сервисы без сбоев. Я был поражён тем, какие зоны ответственности входят в компетенцию SRE-инженера. Давайте списочком, чтобы вы тоже были шокированы:
сбор проектирования телеметрии;
drp/dirt — дизастер, рекавери-план и нейтрализация последствий;
конфигурация всего таким образом, чтобы можно было динамически настраивать сервисы или изменять приложение на ходу;
оповещения — алёрты;
проектирование архитектуры сервисов и приложений;
проектирование самих метрик и алёртов;
публикация сервисов — чтобы не убить нас по API;
разрешение и разбор инцидентов;
документация, «поваренная книга» на случай инцидентов;
обучение сотрудников;
выделение ресурсов и ресурсное управление;
тестирование всякого разного — AB-тестирование, нагрузочный mirroring;
релиз-менеджмент;
настройка метрик и алёртов по утилизации дисков;
методы отказоустойчивости — техники по сокращению сбоев (circuit breaker, включение и выключение желательно gracefull-рубильника, разгрузка сервисов);
инструменты для анализа первопричин — анализ инцидентов, выяснение причин и триггеров;
ответственность за компоненты и поддержка старых TODO 2015 года — чтобы всё было реально выполнено.
И это, кажется, еще не всё.
Но говорить обо всём подряд неинтересно, давайте о самом классном.
Логи, шумные алёрты и человеческий фактор
Первое, о чём хочется сказать, — работа с логами. Тут я буду описывать исключительно свой личный опыт в Авито, если у вас этот процесс или его отдельные нюансы выглядят по-друго��у – расскажите об этом в комментариях к статье.
Логи могут использоваться как API: на их основе строится бизнес-логика. Например, если что-то идёт не так, можно настроить функционал, который позволит приложению самостоятельно рестартоваться с самолечением.
Кроме того, при авариях в логах может появляться огромное количество событий, — это тоже нужно учитывать. Иногда бывают всплески, иногда — нехватка данных. В таких ситуациях очень полезно иметь второго напарника-разработчика или ответственного инженера, aka backup, который сможет следить за процессом, просматривать логи и валидировать, что всё работает корректно.
Второй интересный момент — худшие практики работы с алёртами. Алёртов много, они шумят, на них никто не смотрит. А как сделать жизнь ещё прекраснее? Можно, например, отдать создание алёртов людям, которые на них не реагируют, — это вообще великолепно. Инженеры, которые реально разбираются и чинят сбои, при этом не получают ни одного алёрта. Можно создать миллион алёртов, чтобы они замусорили все чаты и превратились в спам. Ещё лучше — рассылать алёрты кругу людей, которые формально не в зоне ответственности команды или юнита.
Тегать при этом нужно всех, от максимально квалифицированных специалистов до тех, кто пойдёт в отпуск через два дня и вообще ничего не сделает. И ещё одна проблема — недостаточная настойчивость в отправке алёртов и пейджей. Если кого-то не тегнули, ничего не происходит, никаких последствий нет.
Третий интересный факт — это так называемые причины и триггеры сбоев. Это то, что часто путают, но на самом деле это не одно и то же. Триггер всегда один — именно он влечёт за собой падение сервисов, outage и прочее. А вот причин может быть много: что-то не учли, что-то недотестировали, где-то сработала цепочка событий, на которые можно было повлиять. Часто достаточно более тщательного тестирования и какой-то формальной работы, чтобы в перспективе запревентить саму причину сбоя и отстреливания ног. Словосочетание «более тщательное тестирование» в данном контексте звучит как «нужно больше юнит- и интеграционных тестов», однако тут куда важнее прийти к «хаос-тестированию», потому что через него можно проверить стабильность работы в случае возникновения нештатных ситуаций.
Важно при этом помнить про так называемую blameless culture (культуру без поиска виновных). Если людей начать обвинять в том, что они зафакапились, они просто начнут скрывать ошибки, делать вид, что всё окей. В итоге проигрывают все: инженер не становится опытнее, бизнес теряет деньги, и мы не подготавливаем фундамент для предотвращения будущих сбоев.
Одна из ключевых причин сбоев — человеческий фактор. Основная идея проста: причин всегда много, триггер один. И мало кто знает, но причиной сбоев редко бывает отказ оборудования, — к этому как раз обычно готовы. А вот релизы, недостаточное тестирование и валидация, действия пользователей (которые могут делать с софтом всё что угодно после выкатки), ошибки сети, когда «сеть моргнула — и всё упало», и внешние атаки — вот это реальные источники проблем.
Сбой и War-room
Собственно, вот происходит сбой. Что делать? Как это вообще работает?
Из военного дела сюда перекочевал термин War Room — военная комната. Сейчас так говорят реже, но суть та же: это место или канал, где собирается группа людей, ответственных за инцидент. Проще говоря, заранее подготовленное пространство, где команда может быстро собраться и действовать слаженно.
Важно, чтобы канал связи тоже был зарезервирован. Потому что если, например, в каком-нибудь Google внезапно упадет интернет, то связаться никто ни с кем просто не сможет. Поэтому обычно заранее настраивают резервную звонилку или альтернативный канал коммуникации.
Главное в этом процессе — фиксировать всё происходящее. Ведется лог: что именно происходит, какие шаги предпринимаются, какие решения приняты. Потом на основе этого можно сделать Playbook — артефакт, по которому любой дежурный сможет понять, что делать в аналогичной ситуации.
В этой настольной книге дежурного есть все нужные ссылки, краткие инструкции без воды: как работает сервис, какие рубильники можно крутить, какие процессы запускать.
Команда при этом небольшая. Есть командир — человек, который принимает решения в условиях неопределенности. Есть коммуникатор — тот, кто следит за чатами и передаёт информацию между командами, чтобы все не отвлекались на переписки и не теряли время и деньги. Отдельно выделяется ответственный за влияние и пострадавших — он работает с пиаром и коммуникацией наружу: что говорить пользователям, как объяснить, что случилось. И кто-то из службы поддержки — чтобы оперативно отвечать клиентам: «Ребята, мы знаем, уже разбираемся».
После завершения инцидента пишется постмортем — чтобы разобрать всё по шагам и научить новых инженеров, как действовать, если ситуация повторится.
Отказоустойчивые архитектуры
Немного об отказоустойчивых архитектурах. Скорее всего, CAP-теорема и FLP-теорема — это не совсем то, что напрямую применимо к практике.
Если невозможно спроектировать полностью надёжную и консистентную систему, можно хотя бы спроектировать систему так, как она будет ломаться. В этом случае возникает так называемая PACELC теорем: когда данные партиционируются и становятся частично недоступными, приходится выбирать — либо консистентность с задержкой, либо наоборот. И в целом это неплохо.
При этом для клиентов совместимость по API нужно поддерживать не месяцами, а годами.
Как оно работает в Авито
Подробнее об этом в своём выступлении рассказал мой коллега Николай Губин: «Как построить инфраструктуру, которая не подведет: главное с митапа по отказоустойчивости».
Теперь самое интересное — как это устроено у нас в Авито. Все знают, что у нас есть NFR, трекинг надёжности, разные PaaS-овские ш��уки, канарейка, алертирование, политики деплоя, а также внутренние механизмы, поддерживаемые внутри сервисов: асинхронная работа с ключевыми сервисами юнита, кэширование баз данных, распределение нагрузки и прочее.
И вот самое удивительное: можно закэшировать буквально всё Авито. Существует механизм, который включается в критических ситуациях, когда что-то идёт не по плану, и начинает отдавать пользователям сохраненные ранее страницы из кэша. Кэширование таких страниц при этом происходит всего, в фоне, не влияя на производительность настоящего Авито. Этот механизм максимально независимый от дата-центров и полностью конфигурируемый через специальный файл — с настройкой страниц, статики и прочего.
Правила кэширования задают, какие именно параметры запроса важны для сохранения страницы в кэше — всё это формируют ключ кэширования key, который также используется в шардировании. Кроме того, конфиг позволяет, например, задать с какой частотой нужно перекэшировать страницу, а также определить фильтры кэширования. Изначально настройка работала не идеально, но в ходе доработок были рассмотрены разные уровни кэширования: на уровне DNS, на уровне граничных балансировщиков и на уровне API Gateway. У каждого подхода есть свои плюсы и минусы, поэтому в Авито используются все три механизма одновременно в зависимости от деградации сервисов.
Для пользователя это может выглядеть забавно: например, в рекомендациях вместо PlayStation 5 может появиться антицеллюлитный крем. Качество ответов может проседать, так как кэширование происходит по конкретной фразе, а значит, по запросу «коты» результат найдется, а по запросу «котики» — нет. Но сервис при этом продолжает функционировать, а мы — оперативно чинить горящие инциденты, даже если упал дата-центр.
Кстати, часто путают SRE и DevOps, особенно в России. У нас SRE считают чем-то вроде advanced operations, а DevOps — админ или инженер по автоматизации, который настраивает CI/CD и сервера. В мировом контексте SRE — это инженер по проектированию и обеспечению отказоустойчивости, чтобы всё не падало, а DevOps — это культура и набор практик, которые улучшают работу команд и делают жизнь в IT лучше.
Собственно, зачем это всё нам?
Для нас это важно, потому что после включения кэширования метрики падения стабилизируются примерно за 15–20 минут, мы минимизируем импакт сбоев и оперативно всё чиним. Нормализация метрик обычно занимает 15–30% времени отжима — и это не просто круто, это магия.
Большое спасибо за ваше время! Заходите в комментарии и делитесь мыслями!
Узнать больше о задачах, которые решают инженеры AvitoTech, можно по этой ссылке. А вот тут мы собрали весь контент от нашей команды — там вы найдете статьи, подкасты, видео и много чего еще. И заходите в наш TG-канал, там интересно!
