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

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


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

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

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

      32. Умейте быстро отключить любой компонент

      Был у нас как-то случай… В 00:00 на странице должен был начать отображаться один из блоков, содержащий карточки событий. Код был написан так, что в цикле “while (n < m)” подбирал события до тех пор, пока в ленту не наберётся необходимое количество событий. В один момент в кандидатах было в принципе меньше событий, чем должно было набраться в ленту. На такое, конечно же, никто не рассчитывал. Тут несложно догадаться, что было дальше… В 00:00 блок начал показываться, люди заходили на страницу, но не видели ничего, потому что обслуживающий бекенд уходил в бесконечный цикл. Балансер делал три попытки получить ответ от бекенда; таким образом, на один запрос пользователя три бекенда уходили в бесконечный цикл и уже не могли обслуживать другие запросы. Печаль. В итоге, это приводило к тому, что за небольшое время вообще все бекенды оказывались в бесконечном цикле и по сути ничего не работало. Понятное дело, что в этом случае нужно собирать новую версию и выкатывать её, но это вообще дело небыстрое, когда речь идёт о крупных системах.

      Или вот другая история: один из источников данных начал отдавать сломанный json, на котором ломался парсер и всё падало.

      Или вот ещё история: один из источников по ошибке начал отдавать такой объём данных в ответе, что в цепочке передачи данных переполнялся один из буферов и снова всё падало.

      И вот ещё пример: в одном из блоков был оптимизирован алгоритм сортировки элементов с учетом весов, но когда все веса элементов оказались равными нулю, он начал уходить в бесконечный цикл.

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

      Решение: умейте отключать компоненты в системе. Это намного быстрее, чем собрать и выкатить релиз. Достаточно найти место, которое всё ломает и выключить его, а потом спокойно заниматься решением проблемы, фиксами и релизами.

      Для реализации такой штуки есть разные способы:

      – админка, через которую вы можете управлять конфигами

      – база данных, в которой лежит конфигурация (это удобно, но менее надёжно)

      – система управления конфигами, типа Ansible

      – файлик в хранилище файлов, который вы туда руками положили, а бекенд его скачивает иногда

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


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