Downtime Bar&Grill

Всем привет! У меня две новости, одна хорошая и одна не очень. Не очень заключается в том, что я вынужден поднять цену за интенсив по MySQL. Интенсив дорос до четырех дней, всё быстрее превращается в полноценный курс по построению хранилищ данных в высоконагруженных системах и вышел за пределы самого MySQL. Текущий объем лекций перевалил за десять часов и сокращать программу я не считаю правильным. Мне интересно выходить за пределы средних инсталляций и погружаться в нюансы работы сложных, геораспределенных систем с высокими нагрузками. Я понимаю, что такие дебри нужны далеко не всем, поэтому решил разделить интенсив на две части. Хорошая новость в том, что базовая часть интенсива превратится в вебинары и станет бесплатной. Первый вебинар мы проведем уже через две недели, в четверг, 27го августа, в 19:00 по Москве. Поговорим о самом проблемном, что есть в базах данных - блокировках. Участие бесплатное, запись по ссылке на timepad https://fournines.timepad.ru/event/4140978/ Теперь про интенсив: предыдущая версия стоила формальные четыре с половиной тысячи рублей, что даже близко не покрывало расходов на проведение, поэтому с 20 августа билет на интенсив будет стоить 16500р, следующий поток пройдет онлайн с 9го по 12е ноября с 10:00 до 12:00 ежедневно. Закупить доступ можно здесь https://fournines.timepad.ru/event/3984942/ Станет почти в четыре раза дороже. Что получите за эти деньги? 🎥 По факту покупки вы сразу получаете записи предыдущего интенсива с лекциями всех четырех дней 🎫 Проходку на все потоки, которые пройдут в течении года (по факту это подписка) 💬 Доступ в закрытый чат, где я отвечаю на вопросы в приоритетном порядке. В качестве благодарности, все те, кто приходил на предыдущие интенсивы, получают доступ ко всей серии на три года. Ваша обратная связь очень полезна, происходящее структурирование и разбиение это часть ответа на ваши пожелания, большое вам спасибо! @downtime_bar #MySQL #события

Внезапно. Кто ещё получил письмо счастья от PagerDuty? @downtime_bar

Хотите знать больше про работу MySQL DBA? Вот вам интервью. Всё по делу. https://youtu.be/5KyfW79Ld4g?si=G-RGrQWbYttTizqG

Забавный факт: Oracle запретил коммитить в OpenJDK код, сделанный с помощью AI "Contributions in the OpenJDK Community must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems. Content, in this context, includes but is not limited to source code, text, and images in OpenJDK Git repositories, GitHub pull requests, e-mail messages, wiki pages, and Java Bug System issues," the post said. Источник: https://www.theregister.com/ai-and-ml/2026/08/03/as-larry-ellison-bets-the-farm-oracle-says-it-loves-ai-written-code-just-not-in-openjdk/5281851 @downtime_bar #AI #ИИ

С одной стороны впереди ещё почти два месяца до линкмитапа. С другой — это всего лишь два месяца! И пора начинать рассказывать, что же там будет происходить, кроме докладов. А начнём мы с того, что зададим общий настрой. Мы делаем 9-й митап, тем самым разменивая первый байт. И нам есть, что вспомнить. Как вы уже поняли по постеру, основной темой будет Назад в будущее. И вокруг него будет строиться всё. А точнее вокруг золотой эпохи конца 2000-х. У нас будут: • футболки с постером • стикеры и специальный идейный мерч каждому гостю • ретро видеостудия на бетакамах, как была в прошлый раз • уголок ретроприставок от Миххру • игра с телеграфным ключом, как было в Нск, от Артёма из До нас дошло • огромная панорама истории связи от До нас дошло с интерактивом • доклады про фидонет, ббс и историю телефонии. И про фряху • настоящая работающая ббска, доступная по телнету • работающая модемная связь • торренты • ещё пара секретных пока активностей • атмосферные ролики из двухтысячных Мы призываем вас поддержать это настроение. Приходите в стиле десятых (что там было? Эмо, панки, металлисты, растянутые свитеры, спортивок уже не было, но какая разница?), приносите с собой гаджеты и артефакты эпохи — будете с ними таскаться весь день обмениваться друг с другом. Так что ждём вас 15 октября на 9-м линкмитапе https://linkmeetup.ru/

Как работает DRP? Вот прямо сегодня утром у одного из клиентов упал ДЦ. Ну как "упал" - сервера работают, а вот сеть несмотря на все резервирование упала. Тоесть прод как бы жив, но площадка для пользователей недоступна. Какое-то время разбирались что именно происходит, потому что внутренний мониторинг девиаций не показывал. Зато внешний четко сообщил о проблемах прохождения ICMP. Если бы не было DRP, на этом все бы и закончилось и сайт, являющийся ключевым компонентом бизнеса, сейчас бы продолжал лежать (на момент написания поста площадка все еще не доступна), но у DRP у нас был. Процесс переключение занял больше чем хотелось бы, но через сорок минут аффект на пользователей был снят. Больше двух лет DRP работал просто "что бы было", как резервная площадка. Мы использовали ее для тестирования гипотез, когда среда должна быть максимальна похожа на прод, но без влияния не пользователей. И вот сегодня этот день пришел. Не могу сказать, что 40 минут это быстро, но в заявленный час при потере основной площадки мы уложились. Если перевести разговор на язык денег, то за три часа простоя основной площадки DPR уже отбил свою стоимость за два года и это не учитывая репутационные потери и уход клиентов к конкурентам. Хотите себе DPR? Пишите, сделаем! P.S. Считайте, что DRP (Disaster Recovery Plan) это георезерв. Он бывает нескольких типов, мы про них писали здесь. В данном случае это был гибридный резерв, в режиме active-passive. Данные между площадками реплицируются в режиме master-master, но активна только одна. Такой тип резерва позволяет сократить время переключения от двух часов до нескольких минут. @downtime_bar #DRP

Оп, мини-анонс, уже через 9 дней вещаю "про многопоточность от регистра до кластера" на https://backtobackconf.ru/ Сначала эта конференция называлась C++ Zero Cost, но теперь переименовалась Пора доделать слайды! (И как только доделаю, так сразу и постами сюда опять займусь, обещаю!)

Последние две недели я читал один из самых насыщенных своих лекционных курсов: интенсив по СУБД MySQL. Происходит это нечасто, предыдущий курс был в январе 2025го, но каждый раз для меня это большое событие. В этот раз было два потока - один вечерний и…

Возможно кто-то помнит, мы плотно работаем с учебным центром Слёрм, который делает курсы, связанные с разработкой и эксплуатацией сложных систем. Вы могли слышать мои лекции например в курсе SRE. Хочу поделиться с вами новостями от ребят, может кому то будет полезно. Сегодня ландшафт в IT меняется и для того, что бы помочь адаптироваться к новым реалиям коллеги из Слёрма собрали бесплатную вечернюю школу «ИИ для инженеров: польза и риски». В программе шесть онлайн-занятий про прикладное использование ИИ: - в DevOps-, SRE- и infrastructure-командах - в работе с алёртами и инцидентами - в анализе логов, тикетов и документации а еще обещают обсудить, как выстроить инженерное мышление в эпоху LLM и как пользоваться нейросетями по закону Первое занятие пройдёт 21 июля, последнее 6 августа. Если кому интересно, больше информации на лендинге, а регистрация у них в боте @downtime_bar

Downtime Bar&Grill pinned a photo

За последние пол года мы столкнулись с ситуацией, когда перед компаниями встает задача экономии бюджета и снижения расходов как на инфраструктуру так и на эксплуатацию вообще. Видя эту тенденцию мы запускаем специальный тариф на поддержку: туда входит только поддержка баз данных (анализ нагрузки, оптимизация запросов, еженедельные чекапы и т.п.), включено только рабочее время с 9 утра до 18 вечера по МСК, зато и стоит он денег, за которые даже junior DBA работать не пойдет. Такая поддержка позволит спокойно пережить сложные времена, не тратя лишние деньги и обеспечивая работоспособность самого хрупкого компонента системы Под акцию подпадают небольшие компании с количеством инстансов баз не больше четырех штук. Контракты заключаются на один год. Подробности по ссылке https://fournines.ru/support_for_mysql P.S. про оптимизацию прода при снижении расходов будет отдельный пост, этот процесс часто даже сложнее чем расти под нагрузкой @dowtime_bar #MySQL

Есть сильные безопасники? Авито открыл регистрацию на свой первый CTF с призами до 300 000 рублей на команду 📍 AvitoTech устраивает CTF онлайн с денежным призовым фондом, мерчем и интересными тасками! Регистрация команд уже открыта по ссылке, а ниже собрали инфу, что предстоит делать во время HoneyBadger CTF AvitoTech. Чего ждать от турнира: тасков на веб-уязвимости, инфраструктурных мисконфигов, анализа скомпилированного кода, расследования инцидентов, слабостей шифров, всего, что требует хакерской смекалки. И розыгрыша мерча, помимо основного призового фонда. Важно: CTF не только для спецов по кибербезопасности — есть отдельная лига для всех, кто любит разбираться, как устроены IT-системы 🐝

Последние две недели я читал один из самых насыщенных своих лекционных курсов: интенсив по СУБД MySQL. Происходит это нечасто, предыдущий курс был в январе 2025го, но каждый раз для меня это большое событие. В этот раз было два потока - один вечерний и второй утренний - для удобства жителей Дальнего Востока, Байкала и Сибири. Что отдельно приятно, на второй поток тоже пришли люди. По времени конечно никуда не уложились. Вместо заявленных трех лекций по два часа, первый поток занял восемь часов, второй кажется все десять. И дело не в отсутствии подготовки. Можно поставить себе жесткие рамки и уложиться секунда в секунду просто читая слайды. Но как только ты от слайдов переходишь к практике начинается самое интересное. Одно дело рассказывать как работают блокировки и как одна неосторожная миграция может повалить прод и совсем другое дело - показывать это все на практике, вживую наблюдая как деградирует производительность базы, как казалось бы безобидный ALTER TABLE блокирует работу псевдо-бекендов и как под нагрузкой отваливается виртуалка, наблюдая последствия наших "действий". Теория конечно важна. Не зная как работают внутренности базы данных сложно понять к чему приводят те или иные действия, но настоящая работа начинается в тот момент, когда ты открываешь консоль и видишь приглашение mysql> Именно практика показывает чего стоят твои знания, навыки и опыт. И не смотря на то, что ИИ сейчас захватывает все более широкие области - глубокое понимание работы БД все еще является ключевым фактором стабильности высоконагруженного проекта и без его понимания даже поставленная AI агенту задача не будет корректной. Поэтому лично мне практическая часть нравится больше всего. Курс развивается, в этот раз мы зацепили ClickHouse и интеграцию с ним, углубили партиционирование и шардирование, поэтому в следующий раз будем сразу закладываться на 4 дня. Напишите что лично Вам понравилось и чего не хватило, это важно для развития курса. Ну и хорошие новости - для всех кто пришел в этот раз, все наши курсы по MySQL в течении года будут бесплатными, так что жду обратную связь! Увидимся! @downtime_bar #MySQL

Давненько ничего не падало и вот опять. 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 #события

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

Ну и что бы вы думали? 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