Downtime Bar&Grill

Начинаем новую неделю! Уже послезавтра пройдет первая из серии встреч по базам данных и SRE: поговорим про стратегии резервного копирования и восстановления данных. Пойдем от простого к сложному
План встречи:
- Бекап в SQL формате: mysqldump и его аналоги.
- Бекап через скриншоты снапшоты
- Бинарный бекап через xtrabackup
- Инкрементальные бекапы
- Шифрование бекапов

Данные бывают двух видов: забекапленные и еще не потерянные, поэтому отдельно поговорим о проверке бекапов и стратегии point-in-time recovery, как работает, что для этого нужно.

Встреча практическая, работаем в консоли, наблюдаем результат своими глазами. Запись не обещаю, но для жителей Дальнего Востока, Байкальского края и Сибири будет живой повтор в воскресенье утром по MSK.

Участие бесплатное, регистрация на таймпад https://fournines.timepad.ru/event/4181137/

@downtime_bar #MySQL #встречи

Рубрика воскресный рекомендасьон. Если есть желание почитать что-то очень прикладное и приземленное, то вот идея идея на воскресное утро: канал человека, разбирающегося в тонкостях эксплуатации сложных систем как в финтехе, так и за его пределами. Практическая разработка, эксплуатация и инструменты. Канал новый, подключайтесь: @aitamus

P.S. Человека, если что, знаю лично и даже имел удовольствие работать с ним в одной команде.

@downtime_bar #воскресный_рекомендасьон@downtime_bar

Сезон встреч и конференций продолжается

Performance Conf собиралась уже двенадцатый раз и стала местом встречи инженеров и менеджмента непосредственно связанных с высокими нагрузками. В этом году было три трека: нагрузочный, эксплуатационный и online-only трек для тех, кто не смог приехать на конференцию лично. Было забавно смотреть на ноуте выступление спикера из комнаты рядом.

Пригласили рассказать о довольно болезненной, но востребованной сегодня теме - снижение бюджета на инфраструктуру. Основные тезисы приведу здесь, в этом посте.

Начнем с того, что уменьшать мощность лежащего под продуктом железа, задача сложнее чем масштабировать проект, готовя его к высокой нагрузке. Вынимая ресурсы из проекта, мы играем в виртуальную дженгу, с каждым вынутым из инфраструктуры сервером, ядром CPU и гигабайтом памяти уменьшая надежность системы.

Как обычно первое и самое главное при изменении масштаба системы это ее понятность и прозрачность.

Если система для вас черный ящик, уменьшение ресурсов будет прогулкой по полю с граблями с завязанными глазами - увлекательно, но болезненно, поэтому первое в чем необходимо убедиться - наличие мониторинга всех компонентов, инфру которых будем резать. Про мониторинг здесь не будем, о нем я буду очень подробно рассказывать вечером седьмого и утром одиннадцатого октября в серии бесплатных online встреч по SRE и эксплуатации, приходите!

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

Из общих принципов можно выделить необходимость верификации изменений с помощью нагрузочного тестирования. Одна из центральных мыслей доклада - необходимость нагрузочного тестирования как постоянного процесса для оценки запаса прочности системы. Это кстати важно как при уменьшении ресурса так и при масштабировании в момент роста нагрузки. Можно конечно вместо нагрузочного использовать и живых пользователей, такой подход конечно по-проще, но понравится он, боюсь, не всем!

Почему нагрузочное необходимо, а просто посмотреть в мониторинг недостаточно?

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

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

И это только самая простая часть работы - техническая. Дальше будет интереснее.

@downtime_bar #SRE@downtime_bar

Вчера внезапно собрались на ламповый межусобойчик в славном городе Липецке, в помещении Сберовской Школы 21.

Поговорили про технические и организационные аспекты работы с высокими нагрузками, зацепили проблематику масштабирования бекендов и баз данных и коснулись вопросов надежности при росте проектов. Что получилось упихнуть в полтора часа, упихнули. Даже про хайп в IT поговорили.

Кто не попал, не переживайте, для вас скоро начнутся осенние встречи. Поговорим и про SRE с эксплуатацией и про базы данных и обязательно о чем-нибудь еще!

P.S. @elinorco, спасибо за фотки!

@downtime_bar #вести_с_полей

Вы вообще видели, что сделала команда AvitoTech ко Дню разработчика?!

В честь наступающего праздника вместе со студией FU2RE и 3D-художником Dmitriev Video ребята создали большой портал в прошлое — эмулятор 2006 года будущего разработчика. Внутри — олдскульные игры и викторины, за которые можно лутать баллы и подниматься в рейтинге.

Топ-3 игроков 15 сентября получат суперпак настоящих разрабов, внутри которого салфетка на монитор из коллаборации с Elnik, плед, сумка и плюшевый талисман — кот Б/У. Так что времени сыграть ещё много!

P. S. Сыграть в эмулятор и побороться за призы можно до 15 сентября. Так что успевайте ❤

Кто сегодня на Performance Conf в Москве, проследуйте пожалуйста в чатик
https://t.me/+UOzisYQaJlMyM2Zi

После вчерашней разминочки, продолжаем про CPU и мониторинг нагрузки.

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

Самый простой пример девиации, которую сложно увидеть на мониторинге это описанный в прошлый раз случай, когда процесс упирается в производительность CPU. Мониторинг многоядерной системы показывает почти полный idle, при полной загрузке одного ядра. Никаких алертов по CPU конечно не будет.

Даже народная метрика Load Average, в простонародье LA, показывающая среднее количество потоков, стоящих в очередь на выполнение, такого не покажет.

Именно для этого и в консольных командах вроде htop, и в экспортерах метрик есть данные по загрузке каждого ядра. Смотреть на график из 80ти ядер, выискивая причину тормозов тот еще квест, но лучше чем ничего.

Еще одна метрика, которую вы никогда не увидите на общем графике нагрузки процессора это его настройки энегропотребления и частоты. Бывает редко, но иногда на железных серверах процессор может работать на трети от заявленной частоты, просто потому, что находится в режиме экономии электроэнергии. Много сэкономить не получится, а вот скорость работы приложений может пострадать, даже если частота под нагрузкой будет расти, гуглить "cpu performance governor".

Предельный случай занижения частоты - защита от перегрева. Внутренняя логика процессора понижает частоту по достижении определенной температуры, что бы процессор не согрел и если у вас нет алертов на метрики снимаемые с материнской платы, вы получите снижение производительности.

Производительность в этом случае не просто просядет, но может скакать, заставляя постоянно меняться время обработки. Для средней web-based системы это плюс-минус не важно, а вот для специализированных near real-time систем разброс времени обработки может стать очень большой проблемой.

И тут мы приходим в облако. Облако это такой чудесный мир, где тебе примерно ничего не гарантировано. Ваш виртуальный процессор, данные которого вы видите в выводе lscpu, отделен от реального процессора системой виртуализации и аккаунтинга.

Самой показательной была демонстрация теста производительности базы данных, которую мы делали в конце четырехдневного интенсива по MySQL, когда двухядерная (!) виртуалка в течении нескольких минут без малейших сомнений держала нагрузку в 12 (двенадцать!) параллельных потоков. Потом заложенное в облачный аккаунтинг время повышенной доступности ресурса закончилось и виртуалка резко умерла под нагрузкой, да так, что пришлось ее перезапускать. Было весело.

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

Сначала решили, что балансировщику сильно поплохело и он на эту ноду полил повышенную нагрузку. Однако эта гипотеза не подтвердилась. Из балансировки ноду выкинули и начали разбираться. Перевернули все что можно. После приблизительно часа поиска один умный человек предложил проверить фактическую производительность процессора. Достали бенчмарк, прогнали и оказалось, что производительность CPU на виртуалке внезапно стала в где-то в четыре-пять раз ниже, чем была.

Саппорт посмотрел что-то у себя и сказал: "перезагрузите". После перезагрузки все восстановилось. Были ли это "шумные соседи" по гипервизору и виртуалка переехала на новый гипервизор или глюканула система аккаунтинга в облаке для нас осталось загадкой.

Так и живем!

Рассказывайте свои истории, делитесь этим постом с другими, скоро увидимся!

#SRE @downtime_bar

Пока готовился к докладу, окунулся в метрики мониторинга CPU. В получасовой доклад всю эту радость впихивать совершенно бесполезно, поэтому поговорим об этом здесь.

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

Казалось бы, что еще нужно? Проблема в том, что такая метрика хороша на одноядерной системе: 80% нагрузки означает, что 20% времени свободно и на него никто не претендует. В многопоточных системах это не значит примерно ничего. В 48ми ядерной системе может работать 40 процессов, выжирающих свои ядра CPU в ноль, и overall load будет показывать 83-85% при занятых ядрах. Такая ситуация например бывает, когда количество одновременных потоков по ошибке выставили меньше количества ядер, например в nginx или в БД.

Поэтому при анализе нагрузки стараюсь смотреть на другие метрики, первая из которых - количество используемых ядер. 100% используемых ядер означает, что нагрузка успешно распределяется и система эффективно утилизирует железо. Если при этом общая метрика времени CPU time на виртуалке или сервере меньше 60-70% (по большей части эмпирическая величина, но математика за этими цифрами тоже есть), система работает в оптимальном режиме с двумя замечаниями.

Замечание первое: смотреть нагрузку нужно в пиковое время. Обзор нагрузки, в момент когда она далека от максимальной, это как читать рекламные объявления о продаже квартир в новом ЖК: "15 минут до центра". И не врут ведь, действительно 15. Только выезжать нужно часа в 4 утра, потому что, когда все едут на работу, быстрее чем за час на машине не доехать.

Замечание второе: нет ли на боксе в это время процессов или потоков, упирающихся в CPU и жрущих одно ядро полностью и на долго. Большое количество вычислений, выполняющихся довольно долго на одном ядре это вариант нормы для определенных типов нагрузки, но требующий анализа и ответа на сколько вопросов. Не нужно ли разбить задачу на несколько ядер? Нет ли возможности оптимизировать логику работы? Не вынести ли этот функционал на отдельную машину, что бы не мешал остальным процессам? Эксплуатация нагруженных и не очень систем требует внимания к таким деталям.

Что еще важно в мониторинге CPU? Это безусловно распределение типов нагрузки на процессор. Большую часть времени CPU должно обслуживать пользовательские программы, это время так и называется: user time. Другие метрики несут названия соответствующие задачам

system/cs: время проведенное в ядре и потраченное на переключение (context switches). Время проведенное в обработке прерываний (irq,softirq) может показываться отдельно. Это время, которое операционная система использует для переключения (scheduling) процессов между ожиданием и выполнением или между разными ядрами.

io/iowait/wa: время проведенное в ожидании ввода-вывода. По факту это время, когда процесс, занявший процессов, ждет ответа ядра операционной системы. Самый простой пример: мы пишем файл и хотим убедиться, что данные фактически доставлены на диск. Вызывав в коде fsync, мы заставляем ядро выполнить сброс буферов дескрипторов файла и кеша, что занимает существенное время даже на SSD дисках. CPU в это время ждет окончания работы вызова, тратя время на предиктивное выполнение или предоставляя ресурсы ядра другому процессу, например через Hyper Threading.

В общем случае, высокие значения system time и iowait говорят девиациях в нагрузке и требуют внимания.

tldr; общая метрика нагрузки CPU является средней температурой по больнице и может скрывать проблемы производительности. Если хотите сделать систему быстрее или дешевле, смотрите на нагрузку по ядрам, внимательно смотрите за system time и iowait, можете узнать много интересного!

Пишите, про ваш опыт мониторинга производительности, делитесь своими историями, до следующей встречи!

#SRE @downtime_bar: Осенние лекции | Интенсивы

Голосование завершено, объявляем сетку вебинаров!

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

Серия по SRE тоже будет прикладной. Начнем с мониторинга и алертов, затем пойдем в базу реактивной работы: инцидент менеджмент и тушение пожаров.

Полное расписание на осень:

MySQL: Бекапы. Бекапы и восстановление, GTID, point-in-time recovery
23 сентября, среда 19:00 MSK, повтор в воскресенье, 27го в 10:00 MSK. Регистрация через timepad.

SRE: Мониторинг. Особенности инфраструктурного, сервисного и бизнес мониторинга, детализация метрик, исторический мониторинг.
7 октября, среда 19:00 MSK, повтор в воскресенье, 11го в 10:00 MSK. Регистрация через timepad.

MySQL: Репликация. Детали работы асинхронной репликации, бинлоги.
21 октября среда 19:00 MSK, повтор в воскресенье, 25го в 10:00 MSK. Регистрация через timepad.

SRE: Алерты, ключевые метрики, системы доставки и метрики эффективности.
4 ноября, среда 19:00 MSK, повтор в воскресенье, 8го в 10:00 MSK. Регистрация через timepad.

MySQL: Четырехдневный интенсив по практическому использованию MySQL
в высоконагруженных системах. Четыре дня по два часа лекционных занятий. С 9 по 12 ноября. Описание. Оплата.

MySQL: SQL миграции. Оценка рисков, работа с большими таблицами
18 ноября среда 19:00 MSK, повтор в воскресенье, 22го в 10:00 MSK. Регистрация через timepad.

SRE: Работа на инцидентах. Задачи команды во время инцидента, организация пространства, выделение и разбор ролей. Определение степени влияния, эскалация, план работы на инциденте и описание артефактов, необходимых для последующего анализа инцидента
2 декабря, среда 19:00 MSK, повтор в воскресенье, 6го в 10:00 MSK. Регистрация через timepad.

MySQL: Оптимизация запросов. Анализ выполнения, построение индексов, оценка эффективности
23 декабря среда 19:00 MSK, повтор в воскресенье, 27го в 10:00 MSK. Регистрация через timepad.

SRE: Постмортемы. Процесс разбора инцидентов, структура и наполнение постмортема (+раздатка), зачем нужна blameless culture, как ее достигать и основы инженерной культуры. Цели и задачи инженеров и бизнеса на собрании по инциденту.
6 января, среда 19:00 MSK, повтор в воскресенье, 10го в 10:00 MSK. Регистрация через timepad.

Приходите, будет интересно!

@downtime_bar #SRE #MySQL

Последние 8 часов голосования, пока идем очень ровно! Нужно поднажать, проголосовать самому, репостнуть товарищу! По результатам сделаем план вебинаров на ближайшее время.

С Днем Знаний!

Давайте пофантазируем какими навыками должен обладать инженер IT в эпоху искусственного интеллекта и как этим человеком стать.

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

Понимание легаси кода исчезает - в код все равно смотреть не надо, а если что-то не нравится, все можно переписать за один день, достаточно иметь надежные тесты с хорошим покрытием. Само собой такой подход пока применим не ко всем предметным областям, финансы, медицина и прочие области с высокой стоимостью риска такие подходы применять пока не могут, а вот средний E-COM пожалуйста. Выкатили релиз, облажались, откатили, поправили, поехали дальше. С учетом того, что человечество уже давно разработало схемы деплоев с минимальным влиянием, метод проб и ошибок с использованием ИИ в качестве условно-бесплатной рабочей силы становится максимально выгодным путем разработки приложений и создания нужного пользователям функционала.

И тут мы подходим к самому интересному: какие же навыки понадобятся людям следующие 2-3 года для эффективной работы в IT, переживающий полную перестройку на фоне внедрения искусственного интеллекта?

Первый и самый очевидный для меня вывод заключается в том, что на первый план выходит навык управления. Умение ставить задачи, оценивать результат становятся критически важными навыками. Каждый кто использует ИИ сейчас по факту становится лидом небольшой команды, раздающим задачи агентам и проверяющим результат на соответствие целям. Ценностью становится умение понимать общую стратегию, выделять основные направления работы, декомпозировать задачи и приходить к результату. При этом делаешь ли ты что-то сам, используешь других людей или модели, становится не важно.

И здесь мы приходим к феномену мясного прокси, появившегося буквально в начале этого месяца и прокатившегося по миру IT статей и мемов. ИИ становится молотком в твоих руках. Если кому-то нужно забить гвоздь, молоток сильно упрощает задачу. Проблема в том, что молоток можно купить в магазине и его обладание больше не делает тебя уникальным и нужным. Нужным тебя делают знания предметной области и опыт, которого нет у ИИ моделей. Пока нет.

Но это, хоть и очень острый, но уже совершенно другой вопрос. А мы сконцентрируемся на знаниях и умениях. После окончания вот этого голосования, объявим расписание грядущих вебинаров. Подписывайтесь если еще не, включайте нотификации, будет интересно!

#мысли @downtime_bar: Осенние лекции | Интенсивы

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

P.P.S. Этот пост - продолжение темы, навеянное проектом OT. Читайте начало и продожение.

Давайте разбираться, что пошло не так в проекте "Project OT" из вчерашнего поста?

Внедрение ИИ-кодеров создало иллюзию высокой продуктивности, но на этапе код-ревью и деплоя в продакшен метрики эффективности инженеров-людей оказались выше. Давайте разберемся в чем люди смогли составить конкуренцию искусственному интеллекту.

Главной проблемой стал объем коммитов, сгенерированных ИИ. Такую проблему мы сегодня видим во многих проектах, но на больших объемах разработки огромной компании она становится критической. ИИ генерировал огромные массивы кода, но его доля, которая переписывается или удаляется в течение нескольких дней после написания превысила 60%. Живые люди пишут меньше кода, но тратят больше времени на рефакторинг.

Общий объем кодовой базы тоже сыграл роль. ИИ агенты упирались в контекстное окно при работе с общей репой. Монолитный репозиторий Meta* огромен, и если с изолированными задачами (скрипты и простые тесты) ИИ-агенты отлично справлялись, то при интеграции в распределенные системы они теряли контекст. Это приводило к архитектурным конфликтам и ломало зависимости.

Из-за резкого увеличения количества пулл-реквестов нагрузка на Senior-инженеров резко повысилась. Люди превратились в мясные фильтры для ИИ-слопа. Это полностью парализовало их основную работу над архитектурой и развитием продуктов.

В результате, внедрение ИИ привело к кардинальному изменению требований к инженерам.

1. Поменялась роль инженера. Если раньше оценивалась скорость поставки фич с использованием ИИ-копилотов, то сейчас на первое место вышло умение анализировать и рефакторить ИИ-слоп. Инженер должен уметь за секунды находить в тысячах строк ИИ-кода скрытые уязвимости и архитектурный мусор.

2. Поскольку ИИ-агенты начали совершать «крупномасштабные деструктивные действия» в инфраструктуре, от инженеров начали требовать внедрения защиты на уровне архитектуры. Автоматические системы отката должны восстанавливать работоспособность системы после внесения деструктивных изменений, предохранители должны рубить доступ ИИ-агенту, если его поведение становится аномальным. Сами доступы для агентов становятся более гранулярными, остается только решить что является аномалией.

3. Из-за изменения роли инженеров поменялась структура собеседования, а требования повысились. На технических собеседованиях появились требования понимания принципов работы с LLM и семантической трассировки, для анализа работы агентов и управлению рисками. Также увеличились общие требования к фундаментальным навыкам связанным с архитектурой, низкому уровню и пониманию параллельных вычислений.

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

Про навыки в эпоху ИИ порассуждал в следующем посте.

#AI #SRE @downtime_bar: Осенние лекции | Интенсивы

*организация признана экстремистской и запрещена в РФ

ИИ хайп постепенно стихает, уступая место ИИ отрезвлению.

По информации Рейтер, Марк Цукерберг сворачивает Project OT (Organization Transformation), который был призван превратить Meta* в AI-native организацию. Стратегия предполагала замену повседневных операций виртуальными агентами под контролем небольших групп сотрудников.

Согласно результатам внутренних расследований и документам компании, разворот на 180 градусов был вызван двумя основными проблемами:

ИИ-инструменты для написания кода выдали мощнейший слоп - объем сырых изменений в репозиториях вырос на 220%. При этом в проде это принесло лишь 36% реальных полезных фич. Остальное - мусор.

Еще одна проблема касается увеличения количества инцидентов. Команды инженеров инфраструктуры зафиксировали непредсказуемое и некорректное поведение ИИ. Число операционных багов и инцидентов подскочило на 40%. MTTR (время на устранение инцидентов) и вовсе улетело в космос - чинить ИИ-костыли пришлось на 70% дольше, чем обычно.

Третья проблема - живые сотруднки. Чтобы обучить модели, которые должны были заменить людей, руководство обязало сотрудников установить софт, отслеживающий каждое движение мыши и все нажатия на клавиатуру. Итог: петиции, падение лояльности с 74% до 55% и первые серьезные разговоры о профсоюзе прямо внутри Meta.

В итоге радикальный план сократить часть команд до 60 (шестидесяти!) процентов штата отменили за несколько часов до дедлайна. Цукерберг на общем созвоне признал, что «технологии автоматизации развиваются не так быстро, как хотелось бы».

Пока держимся!

#SRE #AI #DevOps #инцидент #уронилипрод
@downtime_bar: Осенние лекции | Интенсивы

P.S. Что пошло не так разбираем здесь.

*организация признана экстремистской и запрещена в РФ

А давайте сегодня наоборот!
Накидайте пожалуйста в комменты мемов, прикольных видосов и прочих подкастов?

Очень надо!

Всем доброго утра!

Если не знаете чем заняться сегодня вечером, у меня есть план!

Собираемся в 19:00, разбираемся в том, какие бывают и как работают блокировки в MySQL

- как блокируются данные в процессе транзакции
- что и как блокирует FOR UPDATE
- что такое metadata lock
- как одна миграция может принести к отказу прода

Регистрация на таймпад: https://fournines.timepad.ru/event/4140978/

@dowtime_bar #события

Ну што, высоконагруженные дамы и господа, 9 сентября, в городе Москва, встречаемся на конференции по производительности https://perfconf.ru/

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

Конференция платная, но всем купившим билеты в августе организаторы обещают второй билет бесплатно. Место хорошее, еду в прошлом году давали вкусную, рекомендую. Увидимся через две недели!

@downtime_bar