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

Скачать книгу

ефонному проводу. Моя история опыта в индустрии крутится в основном вокруг бекенда и инфраструктуры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скачать книгу