Наталья Савенкова
SRE. Рецепты выживания в продакшене для инженера по надежности
45. Если что-то кажется странноватым – вам не кажется
Так называемые “подземные стуки” – вещь очень неприятная. Вроде оно пока не рвануло и катастрофы нет, но не откладывайте разбор подземного стука до момента, когда он ворвётся в вашу дверь. Не откладывайте на завтра то, что могло сломаться уже вчера.
Никто не хочет создавать себе лишнюю работу, это вполне понятно. Давайте назовём этот подход “превентивная надёжность”, что очень точно отражает желание не допускать катастрофы, а приложить подорожник немного заранее.
При возникновении такого рода “подземных стуков” я обычно говорю: “Коллеги, я хочу использовать сегодня день на то, чтобы изучить эту странную штуку”.
Один день это очень небольшая инвестиция в надёжность системы. Если я вижу странное проявление и не могу его объяснить, значит я недостаточно понимаю систему и вот есть возможность изучить её лучше.
В любом случае, на все такие странные проявления нужно заводить тикеты с описанием и собранной диагностикой, чтобы при повторении вернуться к нему и сравнить собранные данные.
А может быть, это было разовое влияние меркурия и ситуация больше никогда не повторится.
46. Ответственны все
У нас есть внутренний процесс разбора инцидентов и я часто разбираю ситуации, когда сломался сервис A, из-за которого сломался сервис B, тем самым сломав сервис C. Сервис B и C занимают позицию “виноват другой сервис – А”, и это не то, чтобы правильно. В этой цепочке каждый компонент сработал плохо: и тот, кто сломался, и тот, кто не смог корректно обработать ситуацию сломанного смежного сервиса.
Здоровья вам и вашим сервисам. Самое непродуктивное, что в таких ситуациях можно делать, это занимать обвинительную позицию в сторону коллег. Мы все отвечаем за свои сервисы, но есть более сложная зона: стыки между сервисами, где зона ответственности размыта. Смотрите на систему как на комплекс, а не как на набор сервисов, где каждый отвечает только за свою часть. Коллаборируйтесь, привлекайте к обсуждению инцидентов коллег и ищите совместные решения по улучшению не только самих сервисов, но и взаимодействий между ними.
47. Регулярно проверяйте схемы rollback'ов
Если вы уже достаточно созрели или хотя бы претендуете на этот статус, то для релизного процесса у вас существует какая-то инфраструктура. Релизный процесс состоит из двух частей: выкатить и откатить. Процедура отката обычно считается аварийной, по этой причине ей редко пользуются. Но что может быть хуже ситуации, когда релиз вы выкатили, а откатить его не можете?
Организуйте для себя регулярную процедуру проверки инструментов отката релизов. С редко используемой автоматикой возможен целый ряд проблем: сломанные конфигурации, потерянные фрагменты инфраструктуры, сломанные мониторинги, потерянные доступы, изменение интерфейсов, а также наличие новичков в команде, кто уже умеет релизы выкатывать, но ещё ни разу не оказывался в ситуации, когда релиз необходимо откатить. Повторяйте процедуру проверки инструментов отката релиза хотя бы раз в квартал, если в течение этого времени вам не приходилось ничего откатывать. Мы называем этот процесс “учения по откатам”.
48. Оно нерезиновое
Если однажды вы внедрили какой-то инструмент или технологию, и продолжаете наращивать степень её использования, то лучше бы знать заранее её пределы. Иначе оно треснет тогда, когда вы этого не ожидаете. Привожу пример: когда-то давно мы в сервисе из легаси-технологий подключили keep-alive для коннектов со смежными сервисами, из которых постоянно забираем данные, чтобы не тратить время на установку соединения. Этот метод ещё называется "HTTP persistent connection". Ускорились мы тогда прилично и были этому сильно рады!
Нас было не остановить и мы переводили на этот тип подключения всё больше и больше сервисов, пока оно не взорвалось массовыми обрывами соединений. Мы-то уже привыкли, что keep-alive отлично экономит время запроса, а тут внезапно перестало работать всё. Оказалось, что у библиотеки для сетевого взаимодействия есть ограничение на одновременное удержание коннектов. У нас просто переполнился пул этих коннектов. Уже не помню, как мы это тогда решили, но это уже и неважно.
Важно, что безлимитного не существует. Если вы не достигли лимита вчера, это не значит, что вы не достигнете его завтра.
49. Доверяйте интуиции
Если перед началом каких-то манипуляций вас посещают сомнения "сделать ли бекап или не сделать", "снять трафик или оставить", "отключить или не отключать" – это ваша интуиция постукивает откуда-то снизу и как бы намекает. Не сомневайтесь – "сделайте бекап", "снимите трафик", "отключите".
Хотя если вы дочитали до этого момента, то таких сомнений уже быть не должно.
Интуиция часто вмешивается в вашу работу? Следующий совет для вас.
50. Соблюдайте регламент
Для всех плановых работ готовятся регламенты. Если регламента нет, то это не плановая работа, а непонятно что. Да, я из тех людей, кто любит надёжную систему больше, чем истории типа “А вот помнишь как мы однажды всё положили?! Да-а-а, было время!”
Когда вы уже начали свои плановые работы, то тут же находятся предприимчивые коллеги с предложениями "А, давайте сделаем ещё заодно и это".
Не надо так делать. Регламент составляется для того, чтобы работы шли по какому-то заранее понятному сценарию с заранее оценёнными рисками, заранее планируемой длительности и сопровождались продуманными планами возврата из аварийных ситуаций. Изменение по ходу дела перечня работ с регламентного на внезапно придуманный приводит к полной бессмысленности всех предварительных оценок, увеличению рисков аварии из-за недостаточной подготовки, увеличению времени проведения работ и в целом всё идёт по никому неизвестному сценарию.
Нужно что-то сделать в системе? Запишитесь в очередь, то есть, возьмите талончик, то есть, заведите тикет. Мы вам перезвоним.