Наталья Савенкова "SRE. Рецепты выживания в продакшене для инженера по надежности"

SRE. Рецепты выживания в продакшене для инженера по надежности
Наталья Савенкова

Мир IT меняется довольно быстро, но внутри остаются всё те же сервера, каналы, базы данных и пользователи. В книге собраны простые и полезные рецепты для жизни инженера по надёжности, описан алгоритм создания инцидент-менеджмента в компании.Основано на реальных событиях и собственном опыте.

Наталья Савенкова

SRE. Рецепты выживания в продакшене для инженера по надежности

Что внутри

С теплыми чувствами к моим коллегам из чата сарказма и котиков.

Здравствуй, читатель! Я Наташа и я инженер. Двадцать лет я работаю в IT, и мой путь начинался, как у многих инженеров того времени, с веб-мастера, а интернет тогда работал по телефонному проводу. Моя история опыта в индустрии крутится в основном вокруг бекенда и инфраструктуры.

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

В 2015 году я пришла работать разработчиком в крупную компанию и там стало очень быстро понятно: если у такой компании не работает ее главный сайт, то об этом сразу пишут в новостях. Это очень смешанные чувства: ответственность и гордость одновременно. В мире начал набирать популярность подход “Site Reliability Engineering”, в наш отдел в компании добавили админов, которые сели за соседний со мной стол… и надежность стала моим главным профессиональным интересом.

Что нужно знать о надежности:

– это не бесплатно

– это про готовность заниматься системой в любой момент

– это для педантичных

– это про постоянное извлечение уроков и изучение ошибок

Мир IT как будто меняется очень быстро, но фундаментально за 20 лет мало что изменилось: новые языки программирования каждый год, облачные технологии, serverless, zero-code, ML, базы данных и еще много всего нового, но внутри все те же сервера с процессорами, каналы связи, дата-центры и экскаваторы, которые неловким движением перерубают кабели в земле.

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

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

В конце книги будет глава с пошаговым планом по созданию процесса "инцидент-менеджмент" в своей компании.

Основано на реальных событиях. Приятного чтения!

1. Сервис без вмешательства не переживает отключение части свитчей в дата-центре – это плохой сервис

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

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

2. Если какую-то процедуру делать страшно – делай ее чаще

У каждого инженера по надежности или администратора системы есть набор нелюбимых манипуляций в системе, которые делать страшно, но все равно иногда приходится. Я выработала для себя правило: если у меня есть такая процедура, то мне самой нужно ее просто регулярно повторять, чтобы она становилась привычной.

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

Как-то в моем хозяйстве была кластеризованная база данных. В работу базы вообще вмешиваться неуютно, но иногда (редко) надо было отключать некоторые из ее нод. Очень неприятная процедура. Я завела себе плановые работы раз в месяц по отключению нод: проверяла, что оно правильно работает, а заодно и повышала свой комфорт от процедуры.

3. Если мониторинг не пишет о проблемах – проверь, возможно он не работает вообще

На серверах лежат файлы, а у файлов есть права доступа. Мониторинг часто устроен так, что просто читает заданные файлы с логами.

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

Отсюда следует: если мониторинг настроен по правилу "нет ошибок – нет проблем", то его стоит дополнить проверками, показывающими, что система действительно работает как задумано.

4. Регулярно проверяй все редко используемые аварийные средства доступа

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

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

Например, можно сделать себе напоминание раз в две недели "проверить резервные средства" и там описать все, что нужно проверить: резервный интернет оплачен и работает, резервный ноутбук загружается и с него можно зайти во все необходимые системы и так далее.

5. Ходить на чужие разборы полезно

Во многих компаниях есть процесс публичного разбора крупных инцидентов (поломок). Это прекрасная практика, хотя и малоприятная для самих выступающих и участников инцидентов. Задача публичного разбора – сгенерировать с помощью большого числа инженеров меры предотвращения подобных поломок в будущем.

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

Если такого процесса не существует, то подумайте о том, чтобы он появился. Вариант реализации такого процесса будет описан подробнее в последних главах этой книги.

6. Если результаты нагрузочного тестирования всегда одинаковые – это плохо

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

В нашем релизном процессе был шаг выкатки на тестовый стенд, на который выкатывается сборка и нагружается трафиком. Чтобы не задерживать сильно релизный процесс, мы выставили довольно высокое стартовое значение нагрузки по принципу "ну, столько наш бекенд точно выдержит всегда". Затем система тестирования плавно увеличивала трафик. По мере повышения трафика стенд переставал отвечать на запросы, тестирование завершалось, а последнее успешное значение трафика принималось за результат нагрузочного тестирования. Если результат был допустим, то релиз выкатывался дальше в продакшн.

Долгое время наш результат тестирования был более менее стабильным. Потом добавили немного логики, потом еще немного, потом еще немного… А результат продолжал оставаться стабильным и релизы выкатывались в продакшн. Пока кто-то не пошел зачем-то посмотреть результаты тестирования своими глазами…

Что произошло на самом деле: по мере добавления новой функциональности и деградации производительности уровень допустимого трафика на стенд постепенно падал и упал ниже заданного стартового значения. В итоге, тестирование заканчивалось сразу же, как только начиналось, потому что стенд обслуживал несколько запросов и сразу же отваливался, а в результаты просто записывалось то самое стартовое значение. За это время производительность бекенда упала на 50%, но об этом никто не знал.

Как стоило бы сделать:

– начинать нагрузку трафиком с нулевого значения, но это сильно замедляет процесс релиза

– сделать параллельный процесс полного нагрузочного тестирования, чтобы не задерживать релизы

– считать тестирование успешным в случае, если финальное значение отличается от стартового

– считать долю успешных и неуспешных ответов от стенда