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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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