Наталья Савенкова
SRE. Рецепты выживания в продакшене для инженера по надежности
Что внутри
С теплыми чувствами к моим коллегам из чата сарказма и котиков.
Здравствуй, читатель! Я Наташа и я инженер. Двадцать лет я работаю в IT, и мой путь начинался, как у многих инженеров того времени, с веб-мастера, а интернет тогда работал по телефонному проводу. Моя история опыта в индустрии крутится в основном вокруг бекенда и инфраструктуры.
На своей первой серьезной работе мы делали интернет-магазины, поэтому понятие надежности систем довольно быстро вошло в мою жизнь: если интернет-магазин не работает, то компания не может обслуживать заказы, а у его владельца прекращается поток денег. Для таких бизнесов IT-система – это в прямом смысле сердце. С тех пор мир поменялся очень круто и такое электронное сердце теперь есть, пожалуй, у всех.
В 2015 году я пришла работать разработчиком в крупную компанию и там стало очень быстро понятно: если у такой компании не работает её главный сайт, то об этом сразу пишут в новостях. Это очень смешанные чувства: ответственность и гордость одновременно. В мире начал набирать популярность подход “Site Reliability Engineering”, в наш отдел в компании добавили админов, которые сели за соседний со мной стол… и надежность стала моим главным профессиональным интересом.
Что нужно знать о надежности:
– это не бесплатно
– это про готовность заниматься системой в любой момент
– это для педантичных
– это про постоянное извлечение уроков и изучение ошибок
Мир IT как будто меняется очень быстро, но фундаментально за 20 лет мало что изменилось: новые языки программирования каждый год, облачные технологии, serverless, zero-code, ML, базы данных и еще много всего нового, но внутри все те же сервера с процессорами, каналы связи, дата-центры и экскаваторы, которые неловким движением перерубают кабели в земле.
В этой книге собраны мои правила и рецепты, накопленные за все время работы инженером по надежности. Если для рецепта будет актуально и мне не будет лениво, то буду добавлять в него что-то про деньги. В конце концов, мы делаем IT-систему для бизнеса, а бизнес всегда про деньги.
Рецепты в основном для крупных систем, но и для небольших тоже что-то будет полезно. Никакой логики в порядке глав тут нет. В книге много сленга и она рассчитана на инженеров с опытом работы.
В конце книги будет глава с пошаговым планом по созданию процесса "инцидент-менеджмент" в своей компании.
Основано на реальных событиях. Приятного чтения!
1. Сервис без вмешательства не переживает отключение части свитчей в дата-центре – это плохой сервис
Пришли к нам как-то сетевые инженеры из дата-центра и говорят: "нам нужно провести работы, для этого мы выключим пару свитчей, запланируйте у себя мероприятия". Обычно в таких ситуациях мы начинали какой-то трафик куда-то переключать, чтобы точно все хорошо прошло, а тут пообсуждали с коллегами и решили, что это неправильная ситуация и лучше мы посмотрим на последствия, а потом что-то улучшим. Всю систему оставили работать в обычном режиме, подготовились к "чему угодно" и стали наблюдать. Все прошло хорошо. С тех пор мы договорились, что на такие работы ничего сами трогать не будем, потому что система должна суметь сама.
Деньги: если система сама не сумела, то нужно оценить масштаб последствий для бизнеса, оценить варианты улучшения системы и принять решение об инвестициях в улучшение системы. Допустимо оставить как есть, если улучшения будут стоить неоправданно дорого.
2. Если какую-то процедуру делать страшно – делай ее чаще
У каждого инженера по надежности или администратора системы есть набор нелюбимых манипуляций в системе, которые делать страшно, но все равно иногда приходится. Я выработала для себя правило: если у меня есть такая процедура, то мне самой нужно ее просто регулярно повторять, чтобы она становилась привычной.
Почему это важно. У каждого из нас разная реакция на стресс: бей-беги-замри. Когда что-то сломалось, то запускается стресс. Когда нужно во время этого сломанного провести нелюбимую манипуляцию, то стресс увеличивается еще больше.
История: как-то в моем хозяйстве была кластеризованная база данных. В работу базы вообще вмешиваться неуютно, но иногда (редко) надо было отключать некоторые из ее нод. Очень неприятная процедура. Я завела себе плановые работы раз в месяц по отключению нод: проверяла, что оно правильно работает, а заодно и повышала свой комфорт от процедуры.
3. Если мониторинг не пишет о проблемах – проверь, возможно он не работает вообще
На серверах лежат файлы, а у файлов есть права доступа. В этом смысле в мире не поменялось ничего. Мониторинг часто устроен так, что просто читает заданные файлы с логами.
Как-то мы переезжали с одних серверов на другие, и что-то пошло не так с правами доступа на файлы логов сервиса бекенда. В результате на некоторых серверах бекенд не мог писать свои логи. Нет логов – нет проблем. Мониторинг читал пустые файлы, не находил там никакой тревожной информации и всегда показывал "все в порядке". В это время на машинке оставался необновляемый код, а пользователь, попадающий запросами на эти сервера, видел вообще нечто очень странное. Нашли мы это случайно, к сожалению.
Отсюда следует: если мониторинг настроен по правилу "нет ошибок – нет проблем", то его стоит дополнить проверками, показывающими, что система действительно работает как задумано.
4. Регулярно проверяй все редко используемые аварийные средства доступа
В работе ответственного админа есть не только основные рабочие средства, но и резервные средства. Резервный интернет, резервный ноутбук, еще разные запасные способы, типа возможности залогиниться на сервер с телефона или загрузочной флешки.
Если запасными средствами не пользоваться, то рано или поздно они перестанут работать. Такова судьба запасных средств. Поэтому важно регулярно проверять, что эти запасные средства до сих пор функционируют и могут быть использованы в критической ситуации.
Например, можно сделать себе напоминание раз в две недели "проверить резервные средства" и там описать все, что нужно проверить: резервный интернет оплачен и работает, резервный ноутбук загружается и с него можно зайти во все необходимые системы и так далее.
5. Ходить на чужие разборы полезно
Во многих компаниях есть процесс публичного разбора крупных инцидентов (поломок). Это прекрасная практика, хотя и малоприятная для самих выступающих и участников инцидентов. Задача публичного разбора – сгенерировать с помощью большого числа инженеров меры предотвращения подобных поломок в будущем.
Если у вас в компании есть такое мероприятие – ходите туда и учитесь на кейсах своих коллег. Не надо ждать, когда случится инцидент именно у вас. Уникальных проблем по истине мало, а способов их предотвращения еще меньше. Изучайте, что случилось у коллег, анализируйте свою систему и выбирайте то, что разумно заранее реализовать в вашей системе.
Если такого процесса не существует, то подумайте о том, чтобы он появился. Самый простой способ построить у себя такой процесс будет описан подробнее в последней главе этой книги.
6. Если результаты нагрузочного тестирования всегда одинаковые – это плохо
Если вы уже выкатываете релизы автоматически и в процессе выкатки есть стадия нагрузочного тестирования, то этот рецепт для вас.
В нашем релизном процессе был шаг выкатки на тестовый стенд, на который выкатывается сборка и нагружается трафиком. Чтобы не задерживать сильно релизный процесс, мы выставили довольно высокое стартовое значение нагрузки по принципу "ну, столько наш бекенд точно выдержит всегда". Затем система тестирования плавно увеличивала трафик. По мере повышения трафика стенд переставал отвечать на запросы, тестирование завершалось, а последнее успешное значение трафика принималось за результат нагрузочного тестирования. Если результат был допустим, то релиз выкатывался дальше в продакшн.
Долгое время наш результат тестирования был более менее стабильным. Потом добавили немного логики, потом еще немного, потом еще немного… А результат продолжал оставаться стабильным и релизы выкатывались в продакшн. Пока кто-то не пошел зачем-то посмотреть результаты тестирования своими глазами…
Что произошло на самом деле: по мере добавления новой функциональности и деградации производительности уровень допустимого трафика на стенд постепенно падал и упал ниже заданного стартового значения. В итоге, тестирование заканчивалось сразу же, как только начиналось, потому что стенд обслуживал несколько запросов и сразу же отваливался, а в результаты просто записывалось то самое стартовое значение. За это время производительность бекенда упала на 50%, но об этом никто не знал.
Как стоило бы сделать:
– начинать нагрузку трафиком с нулевого значения, но это сильно замедляет процесс релиза и для кого-то это может быть важно
– сделать параллельный процесс полного нагрузочного тестирования, чтобы не задерживать релизы
– считать тестирование успешным в случае, если финальное значение отличается от стартового
– считать долю успешных и неуспешных ответов от стенда
7. Регулярно проверяй всю редко используемую автоматику
Одним из основных принципов SRE является проактивное управление системами, что означает создание автоматических систем для защиты от инцидентов и поломок разного рода.
Вот несколько примеров таких автоматик:
– включение фильтрации трафика при срабатывании каких-то условий
– автоскейлинг ресурсов при росте нагрузки
– подключение кеширующих прокси
– отключение незначимых компонентов системы при пиковой нагрузке
– снижение скорости передачи данных
– увеличение времени ответа
– …
Список вариантов большой, но смысл понятен.
Что важно: речь идёт о автоматике, включающейся при некоторых условиях. Это означает в свою очередь, что это редкие ситуации. И это же означает, что механизмы должны работать безотказно. Как огнетушитель в вашем деревянном загородном доме с дровяной печью: если случится так, что он пригодится, то лучше будет, если он будет исправен.
Всю такую автоматику необходимо регулярно проверять! Сделайте себе расписание учений и протоколы проверки всех автоматик, на которые вы полагаетесь для обеспечения высокого качества своего сервиса в критических ситуациях.
В ходе этих регулярных проверок вы сможете обнаружить:
– Изъяны или слабые места до того, как они проявятся в результате реальных инцидентов.
– Изменения окружающей среды: по мере развития сервисов и инфраструктуры защитные механизмы могут потребовать корректировки или вообще перестать работать.
– Несоответствия требованиям аудита
– Неполадки в работе системы мониторинга и оповещений
– Отсутствие необходимых доступов
– … и ещё много всего.
Кроме того, участие в тестировании автоматики это хороший способ онбординга новичков в команде.
Каждая проверка – это возможность узнать больше о системе и о том, как она ведет себя в различных условиях, что в итоге приводит к совершенствованию защитных механизмов.
Деньги: тут крайне важно соблюдать баланс между “давайте подготовимся заранее к чему угодно и будем оберегать наш хрустальный дворец” и “ничего не делаем вообще”. Если вы не делаете систему жизнеобеспечения, не управляете ракетами и прочими критическими системами, то будет достаточно:
– проанализировать систему на предмет основных рисков
– оценить потери в результате реализации рисков
– спроектировать средства защиты
– оценить стоимость их реализации и поддержки
– применить здравый смысл и выбрать, куда потратить свои деньги
8. Рандомизируй учения
В прошлой главе было много слов про важность проверки систем и протоколы проверок. Назовём эти проверки учениями.
У любых учений есть один главный недостаток: они далеки от реальной катастрофы. И второй недостаток: они проводятся по протоколу.
К сожалению, если на учениях выявилась какая-то проблема у какого-то сервиса, то устранение этой проблемы означает только то, что сервис научился переживать сценарий учений. Это вовсе не значит, что если начать отключать что-то в другом порядке, то всё будет хорошо. И уж тем более не значит, что авария будет проходить по сценарию учений.
Вносите разнообразие в учения. Регулярно меняйте протоколы и форматы.
Изменение последовательности действий во время учений повышает шансы того, что отдельные люди и команды действительно понимают лежащие в основе принципы и готовы реагировать на неожиданные ситуации.
Вот несколько способов внести разнообразие:
– Использовать генератор случайных чисел, где это применимо
– Использовать временные вариации: менять время проведения учебных проверок, например, проводить их в разное время суток
– Вместо одного сценария, представить варианты, когда различные компоненты выходят из строя в разном порядке или возникают несколько проблем одновременно
– Замена ролей: менять членов команды ролями во время учений, это не только изменит динамику, но и покажет проблемы в навыках
– Изменение последовательности: менять порядок шагов в сценарии учений, чтобы увидеть, как участники адаптируются, смогут ли они по-прежнему эффективно решать возникающие проблемы, и как будет меняться поведение всей системы
9. Проектируй failover смолоду
Если у сервиса есть хоть какой-то шанс получить статус "должен работать примерно всегда", то лучше на это закладываться пораньше. Сами процессы стоит проектировать реентерабельными – рассчитанными на перезапуск, параллельный запуск и какой угодно другой запуск и работу. Лучше сразу предполагать, что любая часть проекта может выйти из строя, и резервировать её, если без неё нельзя обойтись. Во-первых, оно будет более-менее устойчивым, а во-вторых более горизонтально масштабируемым.
Сделайте визуальную схему всей системы и спроектируйте меры повышения надежности.
Деньги: резервирование системы увеличивает стоимость системы не в два раза, а существенно больше, так как для управления резервными схемами требуются инструменты координации.
Как и в случае с рецептом про автоматику, здесь стоит оценить последствия отказа конкретных компонентов, посчитать стоимость резервирования компонентов, а также стоимость систем координации. Только после этого принимать решение о создании резервирования.
10. Мониторинг трафика в диапазоне
Каждый раз, когда пользователь взаимодействует с приложением / веб-сайтом, отправляя данные или выполняя поиск, сервер получает запросы для обработки этих действий и предоставления информации. Это то, что мы в быту называем словом “трафик”.
Мониторинг трафика важен по нескольким причинам:
– ранняя диагностика проблем
– контроль за использованием ресурсов
– управление производительностью
– потребности в локальном масштабировании
– планирование будущего роста
– контроль затрат
Это не полный список причин.
Трафик может количественно меняться двумя способами: резко и плавно. Также трафик зависит от дня недели, времени года, времени суток, событий в мире и тп. Нет такого единственного абсолютного значения, отклонение от которого нужно считать проблемой, всегда есть диапазоны и колебания.
Для таких случаев используется комплексный мониторинг: по абсолютам и по тренду. У них разный принцип работы.
Мониторинг по абсолютному значению
Нужен мониторинг абсолютного значения сверху, а также снизу. Это может быть очень широкий диапазон, потому что верх определяют по максимуму в дни высокого трафика, а низ – по минимуму в дни низкого трафика. Необходимо изучить свою динамику трафика за достаточно большой период и на основании неё выбрать абсолютные значения.
Важно понимать, что если случится внезапный рост трафика в дни с обычно низким трафиком, то из-за ширины диапазона этого можно не увидеть, ведь значения останутся в зоне нормы. Для этого нужен другой мониторинг.
Мониторинг по тренду
Этот вид мониторинга предполагает некоторое накопление данных, и есть множество алгоритмов его работы: сравнение текущего уровня трафика с типичным уровнем для этого дня недели, накопление пятиминутных значений и сравнение их между собой.. здесь каждый сам выбирает нужный ему алгоритм, исходя из доступных технических средств и ситуации.
Важно понимать: если трафик растет достаточно медленно (в течение суток или недели, например), то мониторинг по тренду может не сработать – рост будет слишком плавный, также как плавным может быть и падение трафика. Здесь как раз поможет мониторинг по абсолютным значениям, который может сработать не так быстро, но лучше когда-то, чем никогда.
К сожалению, обычно мониторят только рост трафика, потому что боятся за нагрузку и работоспособность системы, но падение трафика не менее важно: нет трафика = нет пользователей. Нет пользователей = нет денег. Спад трафика может указывать на проблему с доступом пользователей, такую как проблемы с DNS, истек срок действия SSL-сертификатов или неработающая функциональность интерфейса, которая не позволяет пользователям выполнять запросы и решать свои задачи, выпуск новой версии и ещё целая куча разных причин. Но обычно падение трафика не говорит вообще ни о чём хорошем.
Поэтому рецепт такой: трендовый мониторинг делать для нахождения отклонений в типичном поведении, а пороговый мониторинг для крайних случаев, когда трендовый не способен определить отклонения. Мониторить не только рост трафика, но и падение.
11. Мониторинг среднего и min/max
В системах, где много серверов / узлов / нод (выберите любую единицу своей системы), невозможно мониторить каждую единицу. Поэтому для мониторинга значений делают агрегаты: перцентили, медианы и тп. То есть, некоторое среднее по больнице. Это разумный подход, но есть нюанс: обычно есть единичные отклонения, которые в агрегате будут не заметны.
Проблема может быть на одном хосте из сотни, но вы не узнаете об этом. «Но это же всего один хост» скажут многие. Какая разница – он может быть не «одним», а «первым» в череде выхода из строя целой группы. Это совершенно разные ситуации.
Для этого случая полезно иметь мониторинг хотя бы на минимальное значение и на максимальное значение, либо использовать 95ю, 99ю перцентиль и другие виды перцентилей.
Например, если вы мониторите среднее время ответа и используете его для управления масштабированием, то имейте ввиду: половина запросов будет работь дольше этого среднего. Тут возникает очень важный вопрос: а насколько дольше?
В общем, вот что нужно сделать для улучшения ситуации:
– разобраться с перцентилями: что это такое, о чем они говорят
– проанализировать различные значения перцентилей в своей системе
– решить, какую информацию вы хотите получать о системе
– выбрать правильные значения перцентилей для мониторинга
12. Не сажайте слона и моську в одну базу
Мир IT продолжает развиваться быстро. Более того, эта скорость набирает обороты. Чем быстрее вы покажете свою идею в виде продукта, тем больше шансов выиграть в гонке. Здесь менеджеры продукта в прямом смысле соревнуются с инженерами: кто же выиграет – скорость запуска или архитектура?
При появлении очередного проекта, который надо сделать быстро-быстро, первое приходящее в голову звучит так: "Хмм, у нас уже есть в продакшене монга-постгря-мускуль-чтоугодно, подселим новую базу для проекта туда!"
Не стоит так делать. А если делаете, то осознавайте последствия и риски. Получается связанность критических компонентов двух совершенно разных проектов. Пойдёте базу обновлять – накосячите и сломаете оба проекта. Придёт большой трафик обновления в один проект, база начнёт тормозить и сломает второй проект.
Вот ещё несколько очевидных проблем проблемы, связанных с такой практикой:
Когда несколько проектов обращаются к одной и той же базе данных, существует повышенный риск нарушения безопасности, так как все данные в базе данных, включая данные других проектов, могут быть скомпрометированы, если в одном проекте будут найдены уязвимости.
По мере роста числа проектов, использующих одну и ту же базу данных, становится сложнее масштабировать её для удовлетворения всех потребностей, так как сложно оптимизировать единую базу данных для противоречивых сценариев.
Управлять контролем доступа и разрешениями для нескольких проектов в рамках одной базы данных сложно, что создаёт новую головную боль при эксплуатации.
Возьмите себе за правило: один проект – одна база данных.
Деньги: С первого взгляда может казаться, что это лишняя работа и лишний расход средств. Помните, пытаясь сэкономить на таких решениях, вы берете эти деньги в кредит у себя будущего под высокий процент.