Downtime Bar&Grill

Давненько ничего не падало и вот опять. P. S. Мы тут про DRP распинаемся, а знаете у кого сейчас сайт лежит? Правильно! У нас. С вас какашечка в реакциях, если у вас такого быть не может)

Затронули вчера на интенсиве вопрос мониторинга баз данных. Говорили про MySQL, но физика процесса одинакова для всех. Основная метрика мониторинга нагрузки БД: количество одновременно выполняемых запросов. В MySQL она называется threads_running, посмотреть ее можно выполнив команду

SHOW GLOBAL STATUS LIKE 'threads_running';

а в экспортере ее можно найти под именем mysql_global_status_threads_running Почему эта метрика самая важная? На железке где работает ваша база есть определенное количество ядер. Каждое ядро может в каждый конкретный момент времени может выполнять один запрос. Если количество активных запросов в моменте меньше или равно количеству ядер - база работает максимально быстро, каждый запрос получает процессорное время в тот момент когда оно нужно. При увеличении количества активных запросов (важно не путать с количеством подключений threads_connected) на одно ядро CPU становится больше одного запроса, но в этот момент база продолжает эффективно обрабатывать запросы за счет того, что часть времени на обработку запроса процессор проводит в ожидании сети, диска и данных из памяти - это время используется для параллельной обработки запросов и до какого-то момента время обработки растет не сильно. Ситуация начинает резко ухудшаться с момента когда на одно ядро приходится больше двух активных запросов. Свободного времени исполнения у ядра уже нет поэтому параллельная обработка требует постоянного переключения потоков исполнения между запросами. Это в свою очередь увеличивает время выполнения. При нагрузке х3 к количеству ядер время выполнения запроса увеличивается примерно в два раза, система нагружена, но все еще стабильна. Стабильность заканчивается при дальнейшем повышении нагрузки. Если на железку с 24 ядрами одновременно подать около сотни запросов верхние 5% статистики улетят в космос и пользователи получат первые пятисотки, хотя статистика пропускной способности будет показывать красивый график роста. Дальнейшее увеличение нагрузки приводит к экспоненциальному росту времени ответа и фактической недоступности сервиса для пользователей. И это мы говорим про работу базы на предсказуемом ржавом железе. В облачной виртуалке все сильно интереснее. Например виртуалки на яндексе, одна из которых мы вчера мучали на интенсиве, могут кратковременно выдавать больше CPU ресурсов чем то, что вы видите через lscpu. На вчерашних тестах мы наблюдали увеличение пропускной способности практически без влияния на время выполнения запросов до десяти (!) параллельных потоков на виртуалке с двумя официально оплаченными ядрами. Значит ли что виртуалка быстрее железки? Увы, это значит, что метрики виртуалки могут соответствовать погоде на марсе, а не вашим ожиданиям. Производительность может в любой момент просесть из-за нагрузки у "соседа", виртуалка может поменять характеристики после обычного ребута, переехав на другую железку, поэтому бенчмарки в облаке это всегда отдельный вид развлечения. А если активные запросы висят, но используют CPU, например ожидают блокировки? Это ситуация ни чем не лучше. Заблокированные запросы, так же как и обычные медленные, блокируют исполнение кода воркерами на стороне бекенда, вызывая перегрузку бека, автоскейлинг, новые коннекты, вызывая снежный ком и приводя к глобальному отказу. tldr; основной метрикой нагрузки на базу является количество одновременно работающих запросов. Если метрика пробивает трехкратное количество ядер - можно смело алертить и смотреть в чем причина. Сегодня продолжим, а в следующий вторник повторим курс с начала. Поучаствовать: https://fournines.timepad.ru/event/3984942/ P.S. Накиньте огонечков, если хотите что бы сюда тоже писал всякое интересное. @downtime_bar #MySQL #события

Стартуем через час, кому не пришел линк на трансляцию - пишите в личку. Кто купил билет и не успевает - ничего страшного - и 30го числа повторим, и запись сделаем. Запрыгнуть в последний вагон можно по ссылке: https://fournines.timepad.ru/event/3984942/ Погнали!!! @downtime_bar

Ну и что бы вы думали?

We are investigating a fiber cut in Eastern North America.  Customers connecting through North America or accessing services in Europe may see increased latencies and timeouts as Cloudflare engineers look to mitigate
Jun 22, 2026 - 14:48 UTC

Сегодня очередь CloudFlare полежать Кучно пошло! @downtime_bar

И снова седая ночь. C мест сообщают, что еще одна компания не обнаружила у себя DRP

Туристы FUN&SUN остались без документов из-за масштабного сбоя, который начался в пятницу — у туроператора перестал работать сайт и часть внутренних сервисов. 

Клиенты жалуются, что не могут получить авиабилеты, ваучеры на заселение, страховки и прочие документы, без которых невозможно нормально отправиться в отпуск.

Прям не завидую сейчас, ни владельцам компании, ни людям которые застряли без документов. Но людям немного больше, потому что владельцы любого IT сервиса должны понимать, что резерв или Disaster Recovery Plan нужен и нужен он именно для таких ситуаций. Что это такое и с чего начать, если прод у вас есть, а резерва нет? Для начала зайти в нашу библиотеку и почитать лонгрид про DRP: https://fournines.ru/drp Дальше определиться с тем, откуда вы в резервном ДЦ будете брать свежие данные. На третьем дне нашего интенсива я буду рассказывать как организовать DRP на стороне данных: - как организовать бекапы - как рассчитать время восстановления и сделать его минимальным - как отложенная репликация позволяет избежать катастрофы в случае человеческой ошибки (DROP DATABASE на проде видели? я, увы, наблюдал последствия) и в случае преднамеренных действий - как проверить DRP в действии и переключиться обратно Все что я буду рассказывать - не теория из книжек и не AI слоп, а вполне себе живая практика, внедренная в компаниях с которыми мы работаем. Вечерний поток уже в этот вторник, билеты по ссылке: https://fournines.timepad.ru/event/3984942/ Приходите, научим, покажем! @downtime_bar #MySQL #события

С мест сообщают:

никогда такого не было, и вот опять - сначала гоним разрабов отдавать сборки "вчера", забив на тестирование, потом все встает раком

Если Вы наёмный инженер и видите такое у себя в компании из месяца в месяц, у Вас есть три пути: Первый: забить на здоровье, перестать спать, получить тревожное расстройство и потом пару - тройку лет восстанавливаться не имея возможности работать в полную силу. Второй: попробовать пообщаться с начальством, а лучше всего с бизнесом, чтобы осознать для себя причины такого подхода. Почему это может быть важно? В процессе роста компании неизбежен период, когда меняется уровень сложности и сама проблематика выходит на новый уровень: приходит много новых клиентов, ужесточаются требования к доступности, тех. долг бьёт по скорости, но останавливаться в развитии категорически нельзя. Такие периоды в развитии компании бывают и переработки в этот момент практически неизбежны. В этот момент очень важно какие шаги предпринимает руководство - открывает ли новые позиции, привлекает ли внешнюю экспертизу (да-да, это о нас), есть ли вообще понимание того, что как раньше уже не будет и процессы нужно менять? И вот если ответ на этот вопрос "нет", пора реализовывать третий вариант: менять работу настолько быстро, насколько это вообще возможно. Да, это не самое лучшее время. Да, ходить на интервью после ночных инцидентов то ещё удовольствие, но важно помнить - с каждым проведенным в таком месте днём, восстановится и найти новое адекватное место будет только сложнее. Будьте здоровы и не роняйте прод! P. S. Это не наши клиенты P. P. S. Ночные работы это нормально, я лично сегодня в 4 утра делал миграции, чтобы не трогать прод под нагрузкой, но это были плановые работы. @downtime_bar

Ну что, через неделю, во вторник, 23 июня стартует вечерний поток интенсива по построению высоконагруженных приложений на MySQL: три дня по два часа. Напоминаем программу: День первый: погружение в чудесный мир MySQL - выбор дистрибутива, внутренняя архитектура MySQL и принципы работы, первоначальная настройка и тюнинг, мониторинг и траблшутинг. День второй: запросы и их производительность, работа оптимизатора и секреты оптимизации, метрики производительности запросов, индексы и анализ данных, День третий: построение инфраструктуры высоконагруженных систем для работы с сотнями тысяч запросов в секунду. Типы репликации MySQL, функциональное и горизонтальное масштабирование, архитектура отказоустойчивых кластеров, ну и конечно бекапы и организация Disaster Recovery. Билеты на timepad https://fournines.timepad.ru/event/3984942/ Подробности на сайте https://fournines.ru/mysql_workshop P.S. Интенсив по любому билету можно посетить дважды: билеты на вечерний поток 23, 24 и 25 июня и билеты утреннего потока 30 июня, 1 и 2 июля взаимозаменяемы. Увидимся на интенсиве! @downtime_bar #MySQL #высокие_нагрузки

Знаете что такое работа со стабильностью в компании с оооочень высокими нагрузками? Вот коллеги из Авито знают! Инженеры, непосредственно работающие с продом и отвечающие за доступность сервисов под высокими нагрузками, делятся своим опытом в подкасте «В SREду на кухне» — там обсуждают разницу между DevOps и SRE, рассказывают о том, как ИИ переписал правила работы, говорят о GitOps, бюджете ошибок, хаос инжинеринге и других прикладных вопросах эксплуатации. Подписывайтесь и сохраняйте на будущее. А еще у них есть канал, в котором они делятся материалами, опытом и анонсами встреч. Подписывайтесь и узнавайте больше! @downtime_bar #рекомендуем

Оптимизируем код под упоротое. Под площадь визитки!!! Опять набрел на мега-рейтрейсер имени Andrew Kensler, и на этот раз залип. Стало интересно, сумею ли уменьшить. Немного сумел, сделал за вечерок из 1317 исходных байт свои 1249 байт, что для code golf вроде неплохо. Особо порадовало, что из 35 строк сумел сделать 33 строки (сохранив исходную ширину 39 символов). Весь код тут, скриншоты кода было/стало пониже. Основная экономия, как полагается, макросами и дедупом кода. Но случился и один интересный моментик, кратко раскрою! В оригинале случайное число от 0 до 1 генерируется вот так.

#include <stdlib.h>
f R(){return(f)rand()/RAND_MAX;}

Получилось сэкономить тут и символы и строчки, переделав генератор вот так.

i u=1;
f R(){return((u=u*9973^97,u>>8)*6e-8+.5);}

Для практики, понятное дело, это неприменимо (но кстати, и качественные RNG делаются компактно), однако для code golf развлечений вышло забавно.

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

Мы тут с Учакиным последнее время бывает пишем про резервирование и Data Recovery Plan (DRP) ну и как настоящие (нет) блогеры используем хеш теги. Используем, но не проверяем, потому что ну а что еще могут эти три буквы значить? А тут я нажал. И для того, что бы разобраться почему так много девушек модельной внешности знают про резервирование и планирование дата рекавери. Пришлось сделать небольшое исследование. И Gemimi и Urban Dictionary в курсе что это значит, теперь и вы будете, и как говорит один там, независимый эксперт, в целом это очень похоже на то, чем приходится заниматься когда у тебя падает основной ДЦ. Наслаждайтесь! @downtime_bar #DRP

Для одного из клиентов запустили в опытную эксплуатацию систему обнаружения вторжений на уровне хранилищ данных. Система хранит хеши всех легитимных запросов и сообщает о девиации при появлении нового. Ограничения: - деплой новой функциональности очевидно приводит к ложному срабатыванию - кастомные аналитические запросы так же лучше через систему не пропускать, они должны отдельно логироваться и анализироваться отдельно Преймущества: - Попытки нащупать SQL инъекцию видны в реальном времени - Есть статистика по количеству данных, которые вибираются запросом, она может быть использована для детектирования слива данных сотрудниками или третьими лицами - Подключается к стандартному стеку мониторинга (Prometheus, Grafana) - Можно навесить любые обработчики в т.ч. и AI-based @downtime_bar #проИБ

Для одного из клиентов запустили в опытную эксплуатацию систему обнаружения вторжений на уровне хранилищ данных. Система хранит хеши всех легитимных запросов и сообщает о девиации при появлении нового.

И снова седая ночь. Сервера очередного хостера по очередным причинам больше недоступны. Если Вы все еще думаете, что это явление редкое - полистайте наши посты по тегу #DRP, там такого много и регулярно. Если вы хоститесь у одной компании ваш бизнес несет риски. Не то, что бы каждый день такое происходит, но просто представьте на секунду, что все Ваши сервера больше не Ваши и доступа к ним у Вас больше нет. Выход один: считать риски и строить план Б. Мы рекомендуем просчитывать три варианта переключения: 1. Переключение в датацентр, готовый принять трафик: дорого, но в такой ДЦ можно переключиться в течении 10 минут. 2. Переключение в ДЦ, в котором развернута необходимая инфра, но требующий предварительного масштабирования: дешевле, но и простой будет выше, около двух часов 3. Минимальный и самый дешевый вариант резервирования, когда в ДЦ выносятся только реплики БД и репозитории, из которых нужно будет собрать новый датацентр, если основной прекратит свое существование. Развертывание площадки в этом случае занимает наибольшее время. Подробнее про #DRP можно почитать у нас на сайте https://fournines.ru/drp @downtime_bar #DRP

Есть такое понятие "инженерная культура". А знаете, что такое "инженерное дно"? Это когда хостинг провайдер молча, в середине дня, проводит работы на сети, после чего часть прода отваливается с диагностикой "No route to host" и обратно не возвращается. Дальше веселее. Поддержка следующие несколько часов делает вид, что ничего не произошло, отвечая запросом все новой и новой информации. Самое веселое было, когда через шесть часов общения, поддержке не понравилось что ей присылают вывод MTR в текстовом формате и они запросили скриншоты. Несколько быстрых выводов: - К сетевикам вопросов нет, есть вопросы к руководству, которое согласовало работы в дневное время. - Есть вопросы к поддержке, которая сначала не предупредила о работах, а потом делала вид, что ничего не происходит - Два рабочих интерфейса на серверах абсолютный минимум. Если бы не удалось перекинуть трафик на второй интерфейс - лежали бы все 6 часов. - Мониторинг и учения - наше все. Слаженная работа команды по траблшутингу позволила даже в такой дикой ситуации быстро понять причину проблемы и поднять прод. Каждый знал куда смотреть, каждый знал что делать. Как уже неоднократно упоминал - качество работы хостеров, ISP и всего вокруг будет неизбежно падать, поэтому спасают только учения, опыт и DRP. Будьте здоровы и не роняйте продакшн! @downtime_bar

Я не знаю, кто делает этот ламповый мемный канальчик на 26 человек, но здоровья тебе, админ и счастья человеческого, ты просто спасаешь! Остальным срочно подписаться https://t.me/vikos0k

Мы тут в комментах у Синицына немного подискутировали насчет PostgreSQL vs MySQL. И мне стало интересно побенчмаркать PostgreSQL. Хочу узнать у людей, которые считают себя экспертами в постгрессе - какую версию базы брать на тестирование и какие основные настройки поставить, что бы было быстро? Машинка для тестирования:

Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
RAM 32Gb, NUMA nodes: 1, 
2 x SSD KINGSTON SA400S37480G,  Soft Raid Level : raid1
6.14.0-37-generic @ Ubuntu 24.04.3 LTS

Ключевые особенности первого дня интенсива: Для того, что бы понимать как правильно сконфигурировать базу данных нужно понимать как выглядит эта база изнутри, тоесть на что именно влияют основные настройки. Для этого в первый день поговорим об архитектуре MySQL в целом и его основного хранилища InnoDB. Почему "основного"? Как это ни удивительно сам по себе MySQL не хранит данные. За эту функцию отвечают специализованные storage engines, которые мы знаем как MyISAM, InnoDB, MyRocks, Memory, NDB Cluster и т.д. Каждый storage engines имеет свои особенности и свои настройки. На интенсиве сконцентрируемся на архитектуре самого MySQL и его самого популярного движка хранения - InnoDB. Узнаем как данные читаются, как записываются и как работает транзакционная система InnoDB Билеты на timepad https://fournines.timepad.ru/event/3984942/ https://fournines.timepad.ru/event/3984942/ https://fournines.timepad.ru/event/3984942/ Присоединяйтесь! @downtime_bar

Со второго раза запустили По ссылке отчёт, что из этого вышло: https://youtu.be/NusIDi9Iu-M?si=nciyMBO7th8_mmB8 @downtime_bar

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