SRE. Рецепты выживания в продакшене для инженера по надежности. Наталья Савенкова
самом деле, мониторинг это такой же сервис, как и всё остальное. Ваш мониторинг может быть каким угодно интеллектуально восхитительным, предсказывать что угодно, анализировать зависимости и давать рекомендации дня, но какой от него прок, если он сломался и вы вообще не понимаете, что сейчас в продакшене происходит?
Выделите критические показатели вашего продакшена и сделайте резервный мониторинг – но не делайте такой же, какой уже есть, сделайте на каких-то других технологиях и в другой среде.
Если ваш первый мониторинг сломается в результате автоматического обновления, тогда останется хотя бы второй. Также заведите себе в календаре напоминание "проверить и актуализировать резервный мониторинг".
32. Умейте быстро отключить любой компонент
Был у нас как-то случай… В 00:00 на странице должен был начать отображаться один из блоков, содержащий карточки событий. Код был написан так, что в цикле “while (n < m)” подбирал события до тех пор, пока в ленту не наберётся необходимое количество событий. В один момент в кандидатах было в принципе меньше событий, чем должно было набраться в ленту. На такое, конечно же, никто не рассчитывал. Тут несложно догадаться, что было дальше… В 00:00 блок начал показываться, люди заходили на страницу, но не видели ничего, потому что обслуживающий бекенд уходил в бесконечный цикл. Балансер делал три попытки получить ответ от бекенда; таким образом, на один запрос пользователя три бекенда уходили в бесконечный цикл и уже не могли обслуживать другие запросы. Печаль. В итоге, это приводило к тому, что за небольшое время вообще все бекенды оказывались в бесконечном цикле и по сути ничего не работало. Понятное дело, что в этом случае нужно собирать новую версию и выкатывать её, но это вообще дело небыстрое, когда речь идёт о крупных системах.
Или вот другая история: один из источников данных начал отдавать сломанный json, на котором ломался парсер и всё падало.
Или вот ещё история: один из источников по ошибке начал отдавать такой объём данных в ответе, что в цепочке передачи данных переполнялся один из буферов и снова всё падало.
И вот ещё пример: в одном из блоков был оптимизирован алгоритм сортировки элементов с учетом весов, но когда все веса элементов оказались равными нулю, он начал уходить в бесконечный цикл.
Мораль такова: вообще не знаешь, что и где может произойти, поэтому подготовиться к этому невозможно.
Решение: умейте отключать компоненты в системе. Это намного быстрее, чем собрать и выкатить релиз. Достаточно найти место, которое всё ломает и выключить его, а потом спокойно заниматься решением проблемы, фиксами и релизами.
Для реализации такой штуки есть разные способы:
– админка, через которую вы можете управлять конфигами
– база данных, в которой лежит конфигурация (это удобно, но менее надёжно)
– система управления конфигами, типа Ansible
– файлик в хранилище файлов, который вы туда руками положили, а бекенд его скачивает иногда
– в конце концов, можно файлик закачать прям в контейнер, если нет ничего