На нашем сайте вы можете читать онлайн «SRE. Рецепты выживания в продакшене для инженера по надежности». Эта электронная книга доступна бесплатно и представляет собой целую полную версию без сокращений. Кроме того, доступна возможность слушать аудиокнигу, скачать её через торрент в формате fb2 или ознакомиться с кратким содержанием. Жанр книги — Хобби, досуг, Прикладная литература. Кроме того, ниже доступно описание произведения, предисловие и отзывы читателей. Регулярные обновления библиотеки и улучшения функционала делают наше сообщество идеальным местом для любителей книг.
SRE. Рецепты выживания в продакшене для инженера по надежности

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





