Сергей Озеранский

Очень сочувствую инженерам Yandex и всем, кто страдает сейчас или пострадает от текущих и будущих проблем с интернетом в РФ. Все мы инженеры, я как коллегам и по человечески очень сочувствую. Я могу злиться, но не на людей, и не на компанию. Все всем ужасе, люди делают все что зависит от них, везде, где бы они не работали. Я могу искать юмор в том, что произошло, но я думаю, что это защита моей психики. В любом случае, что поделать, если не продолжать работать и поддерживать то, что еще осталось в наших руках, как профессионалов своего дела. Стало тяжелее, в моменте очень тяжело. Лучи поддержки всем 🫡

Уже заказали?

‼️‼️‼️Ребята. Проверяйте зону a (Владимир) в Yandex.Cloud

А вдруг лучше, чем сегодня, дня уже не будет? Откладывать можно вечно, думая, что сегодня не тот день. Каждый день может оказаться тем или не тем. Не попробуешь - не узнаешь. Сделай бэкап, резервируй инфраструктуру, живи спокойно.

Ребята. Проверяйте зону a (Калуга) в Yandex.Cloud

Работая на tempus.build заметил что часть джоб может "тормозить" при работе с кешем BuildKit. А почему и как ускорить? Вот некоторые рекомендации по настройке Большая часть времени медленной сборки уходит на промах кеша: слои с зависимостями выполняются заново, а затем новый кеш сжимается и выгружается. Есть три настройки в cache-to сокращают эти затраты. 1. Сжимайте кеш zstd вместо gzip (gzip используется по умолчанию):

cache-to: type=registry,ref=<repo>:buildcache,mode=max,compression=zstd

zstd сжимает быстрее однопоточного gzip (он по дефолту) при сопоставимом размере. Кеш читает только BuildKit, поэтому совместимость образа это не затрагивает. Сжатие настраивается только для бэкендов кеша registry и local; type=gha его не поддерживает. 2. Сам образ оставьте на gzip, если не все его потребители используют свежие версии containerd или Docker. Смена сжатия образа влияет на всех, кто его скачивает; смена сжатия кеша - нет. 3. Выбирайте mode осознанно (а то я часто вижу max, потому что "вот так"): - mode=min (по умолчанию) кеширует только слои итогового образа. Выгрузка и загрузка кеша быстрее, объем хранения меньше. - mode=max кеширует еще и промежуточные стадии. Попаданий в кеш больше, но и выгружается больше. Многостадийным сборкам с тяжелой стадией зависимостей обычно подходит max + zstd. Простым сборкам лучше подходит min. Cache storage backends, Exporters: compression, BuildKit export-cache options, Depot: gzip vs zstd.

Про отказоустойчивость поймал себя на мысли. Вот сейчас 45 минут Рунет был в ж*опе. Рунет лежал. Не работали банковские приложения и сайты, куча сайтов была недоступна. А почему? Qrator прилёг. Какой бы мы ни строили HA, абузоустойчивый супер-пупер кластер в AZ-инфре и прочее, будет вот такой вот "один" сервис, который положит ВСЁ! И не нужно «ломать» каждый банк, каждый сервис. Можно найти точку и «ударить» по ней. Ахиллесова пята. Лишний раз напоминание 🫠 p.s. если у вас инфра в рф, то чую я не стоит планировать выходные далеко от компьютера... Ой чует жопа моя...

Вот не было интернета раньше и не было проблем.

Есть у кого в Yandex.cloud в b зоне ресурсы? Не спите?

tempus.build работает совместимо с раннерами Github runners, для этого нужно обеспечивать ряд требований, в том числе иметь совместимый образ виртуальной машины, на которой будет исполняться ваш код в пайплайнах. Как раз про подход и почему tempus.build собирает собственный образ раннера, а не берет ubuntu-latest, написана статья - https://tempus.build/ru/blog/own-runner-image/ Статья, как и другие в блоге, описана по принципу более общего понимания и применения, но на примере tempus.build. То есть, это хорошая техническая документация для повышения вашей экспертизы, не зависимо от того, используете вы tempus.build или нет. Интересный факт, сборка ubuntu образа для tempus.build занимает 1 час на 8 ядрах. Хотелось бы вам или вашим платформенных инженерам заниматься этим? 🥲

Рекомендую к прочтению. Это в том числе объясняет, что self-hosted не всегда дешевле, как может казаться (я про это уже много раз писал).

🛠 httptap 0.8: что нового с 0.6.3 За три недели закрыл около 30 багов в замерах, работе с proxy и обработке ошибок. Ещё добавил экспорт в Prometheus, OpenTelemetry и HAR. Ниже всё, что изменилось с 0.6.3. 📦 0.7.0 • -4 / -6 — резолвит только IPv4 или только IPv6 • --resolve HOST:PORT:ADDR — отправляет запрос на нужный IP, Host и SNI не меняются • --prometheus PATH — пишет метрики по фазам в textfile для node_exporter • --otlp ENDPOINT — отправляет spans в OTLP collector (нужен httptap[otel]) • --slo-file — читает SLO по фазам из файла, при превышении возвращает exit code 22 • если TLS handshake не прошёл, показывает данные сертификата 🔧 Исправления в 0.7.0 • тайминги через CONNECT и SOCKS proxy теперь верные • замер не включает время на создание клиента • если соединение не удалось, пробует следующий адрес из DNS • один deadline на весь запрос • скрывает credentials из URL в выводе, JSON и при redirect • работает с IDNA-доменами и IPv6-литералами • при сетевых и HTTP-ошибках возвращает ненулевой exit code • если ответ оборвался, сохраняет то, что успел получить ✨ 0.8.0 • --har PATH — сохраняет запрос в HAR 1.2, файл открывается в DevTools Попробуйте --har и --resolve на своих сервисах. Если инструмент полезен, поставьте ⭐ на GitHub 👉 github.com/ozeranskii/httptap

Я не смог сделать скрин. Но история такая. у меня Macbook Pro на M4. Все бы хорошо, но... Он начинает намертво зависать, регулярно, хотя работаю я за ним как обычно. да, у меня два хрома с кучей вкладок, запущен терминал с кучей сессий. Но сейчас фризы и зависания даже без запущенного PyCharm, который тоже кушает не мало ресурсов. Когда происходит полдное зависание, то операционка предлагает убить процессы и фризит их. Где больше всего памяти? Я тоже думал хром, но это iTerm - 26GB, хром на втором месте - 18GB. Как итог, комп просто сам перезагрузился, что крайне бесит меня и за последнее время уже не первый раз. А бесит, потому, что у меня много что открыто и открывать все заново мне крайне не приятно, в том числе убитые агентские сессии...

Раннеры GitHub опять тормозят, а tempus работает Прямо сейчас у GitHub Actions инцидент: джобы долго ждут, пока им назначат hosted-раннер. Это касается разных конфигураций раннеров. Статус: https://stspg.io/c11dc9nb1zdq Раннеры tempus — это отдельная инфраструктура, и сейчас они работают в штатном режиме: джобы стартуют за секунды. tempus как резерв на случай инцидентов GitHub: - Подключение — установить GitHub App в организацию, это пара минут. - Переключение — поменять одну строку runs-on в workflow, ничего мигрировать не нужно. Можно держать tempus как запасной вариант. А можно сразу перевести на него тяжёлые джобы: он примерно в 1,5 раза дешевле larger runners GitHub. 👉 https://tempus.build

🎁 $5 на старт каждой новой организации в tempus.build Подключите GitHub-организацию к tempus.build, и на баланс сразу придут $5. Этого хватит, чтобы спокойно попробовать раннеры на своих реальных пайплайнах: ~625 минут на 4-ядерном раннере (наш рекомендуемый ubuntu-24.04-4core) Оплата посекундная: короткий джоб на 20 секунд стоит 20 секунд, а не целую минуту, как у GitHub. Поэтому на практике $5 хватает даже на больше джобов, чем кажется по минутам. Как начать: 1. Войдите в app.tempus.build через GitHub. 2. Установите GitHub App на свою организацию. 3. Поменяйте одну строку в workflow: runs-on: ubuntu-24.04-4core. 👉 tempus.build

Оплата tempus.build: любая валюта и закрывающие документы Как платить за раннеры, если у вас нет долларовой карты или нужны документы для бухгалтерии? Принимаем оплату в любой валюте мира, в том числе в рублях. Баланс в кабинете ведется в долларах, по той же поминутной ставке для всех. А заплатить можно в удобной валюте и удобным способом. Закрывающие документы предоставляем независимо от способа оплаты: • оплата в рублях — документы российской юрисдикции, для учета расходов российской компании; • оплата в других валютах — документы испанской юрисдикции, для международных клиентов. Как это работает (оплата иностранной картой): • пополняете баланс в кабинете tempus.build; • раннеры списывают посекундно, только за время работы; • можно включить автопополнение, чтобы CI не останавливался, когда заканчивается баланс. Нужна оплата в рублях или нужен счет на юрлицо или особый порядок оплаты? Напишите на @ozeranskii, подберем вариант.

Сколько на самом деле экономит команда на tempus.build Посчитал экономию на примере команды, которая уже гоняет CI на tempus.build. Все цифры взяты из их реальной статистики за неделю: около 700 джобов и 3 650 минут на 4-ядерных раннерах. Сравнение с GitHub-hosted раннерами того же размера (4 ядра) Команда заплатила на 40% меньше, чем заплатила бы GitHub: • ~33% дает ставка: tempus 4c стоит $0.008 в минуту, GitHub 4c — $0.012. • еще ~7 п.п. дает посекундный биллинг. GitHub округляет каждый джоб вверх до целой минуты. У этой команды 81 джоб короче минуты, и всего округление добавило бы 485 минут, это ~11% объема. На tempus.build оплачивается ровно столько секунд, сколько работал раннер. А если раньше стоял стандартный ubuntu-latest? Это честный вопрос, учитывая еще включенные в тариф GitHub минуты. Поэтому посчитал и его: дефолтный 2-ядерный раннер для приватных репо плюс бесплатные минуты плана GitHub Free. • Нагрузка: ~3 650 минут в неделю, это ~17 000 минут в месяц с учетом поминутного округления GitHub. • Бесплатные 2 000 минут GitHub Free закончились бы за 3–4 дня. Остальное на 2-ядерном раннере стоило бы ≈ $92 в месяц. • На tempus на 4 ядрах выходит ≈ $125 в месяц. На первый взгляд дороже. Но на 2 ядрах те же джобы идут дольше: • при замедлении в 1.3× цены сравниваются; • при типичных для сборок и тестов 1.5–1.8× (коэфициент замедления) tempus.build выходит на 13–28% дешевле. GitHub берёт деньги за минуты, поэтому при замедлении 1.5× ему придется заплатить в полтора раза больше минут. Отсюда и результат: чем сильнее замедление, тем выгоднее tempus. При 1.3× цены равны, при 1.5× tempus дешевле на 13%, при 1.8× на 28%. И это не считая того, что ядер в 2 раза больше, а обратная связь от CI приходит быстрее. Честное сравнение "2 ядра против 2 ядер": 2-ядерный раннер tempus стоит $0.004 в минуту, это ≈ $63–81 в месяц против $92–123 у GitHub. На том же железе выходит на треть дешевле даже с учетом бесплатных минут GitHub. Расчет консервативный: время джобов сравнивается 1:1, без поправки на то, что на чистых VM tempus.build сборки обычно идут быстрее.

tempus.build: закрытое тестирование закончено 🚀 Объявляю: закрытая бета завершена, продукт готов к продакшену. Можно подключать и пользоваться. Отдельное спасибо всем, кто участвовал в тестировании 🙏 Благодаря вам я выловил баги и сделал серьёзный перформанс-тюнинг. Теперь из того железа, что у меня есть, я выжимаю максимум. Несколько команд уже активно гоняют свои пайплайны на tempus.build и посчитали экономику у себя. Цифры их устроили. Как и прирост производительности выполнения пайплайнов. Основная рабочая лошадка сейчас tempus-ubuntu-24.04-4core: • 4 vCPU · 16 GB RAM • $0,008 за минуту Это копейки и по сравнению с GitHub-hosted раннерами, и по сравнению с self-hosted, если честно посчитать железо, обслуживание и время инженеров на поддержку. Подключение — одна строка в workflow:

runs-on: tempus-ubuntu-24.04-4core

Если вам нужны другие размеры VM для ваших пайплайнов или, например, нужны раннеры на MacOS - напишити об этом мне @ozeranskii. Это достижимо и можно сделать даже выделенные под вас на отдельном железе или BYOK раннеры. Если CI у вас на GitHub Actions и счёт за минуты растёт, приходите 👉 tempus.build

Вопрос к вам: были ли у вас на работе сокращения или увольнения, связанные с внедрением AI? Интересны любые истории: кого сократили, кого перевели на другие задачи, где наоборот наняли больше людей. Пишите в комментариях, интересно.