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

@downtime_bar

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

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

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

@downtime_bar

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

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

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

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

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

@dowtime_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. Что пошло не так разбираем здесь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Серия по 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

Пока готовился к докладу, окунулся в метрики мониторинга 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: Осенние лекции | Интенсивы

После вчерашней разминочки, продолжаем про 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

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

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

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

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

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

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