Олег Мифле | System Design, AI, архитектура

Force push или не force push, или моё мнение по поводу утренней «загадки». Начну издалека. Я тут начал вести аккаунт в запрещённой социальной сети, выложил там видео про то, что утёкший секрет даже в приватном репозитории нельзя просто удалить. И мне насыпали, что я вейпкодер, который в Git не разобрался и недоэксперт, можно историю-то переписать, ну ё-моё. Обидно (на самом деле нет). Подумал, что было бы интересно собрать мнения тут, в телеге. Можно перезаписать историю, это факт. Но это не сделает скомпрометированный ключ безопасным. После filter-repo + force push секрет может остаться в локальных клонах, форках, CI/CD, кэшах, артефактах и старых ссылках на коммиты. А тот, кто уже получил ключ, вообще не обязан ещё раз смотреть в Git. Поэтому верный (и единственно безопасный) порядок такой: считать ключ скомпрометированным, отозвать/ротировать, затем при необходимости чистить историю. Переписывание истории — cleanup, а не способ обезвредить креды. К сожалению, принцип «быстро поднятое упавшим не считается» тут не применим, поскольку речь идёт про безопасность. Возможно, ты подумаешь: ну это ж в рамках моей компании/команды, значит, не так уж и страшно. Но как ты можешь гарантировать, что у твоего коллеги не потекут данные с рабочего компьютера? В общем, риск — дело благородное, но не когда дело доходит до ИБ. А вообще, надо прекомит-хук иметь, чтобы не лить такие данные. А что вы думаете по этому поводу?

Всем привет! Предлагаю немного размять мозг прямо в понедельник с самого утра! Представь, ты закомитил и запушил секретный ключ в git. Увидев это быстро строку в файле с секретом, комиитишь и пушишь. Но git всё помнит. Твои действия?

Всем привет, коллеги. Настал 256й день в году, а это значит, что всем программстам офоицально разрешено ломать обратную совместимость, ронять продакшены, писать спагетти-код и залезать на пик Балмера. 🥳 Я больше 15 лет отдал этой провессии и понимаю, что впереди ещё очень ии очень много. От души поздравляю всех причастных 🔥🔥🔥 Ещё, напоминаю, что завтра стартует пилот Инженерной Мастерской, о которой я тут рассказывал. Место, где мы сможем прокачивать свои харды. Подат заявку можно тут. А всем, кто поучаствует в пилтое, пожизненная скидка на Мастерскую.

Пыхник’26 — целая неделя PHP! С 28 сентября по 2 октября пройдёт Пыхник’26 — онлайн-конференция для PHP-разработчиков. В программе 10 докладов о современной PHP-разработке: AI, архитектура, асинхронность, компиляция и тестирование. Доклады распределены на всю неделю — не нужно выпадать из работы на целый день! До конференции проводим еженедельные встречи «У костра» — обсуждаем PHP, AI и будущее разработки. Темы предлагают и выбирают сами участники. • 28 сентября — 2 октября • Прямой эфир + записи • 5 дней по 2 доклада: утром и вечером • Билет — 3 000 ₽ Скидка 15% по промокоду MIFLE-26! 👉 Программа и билеты

Привет всем! Напоминаю, что завтра будет Engineering Lab, где мы разберём архитектурную задачку примерно так, как это будет в Мастерской. На прошлой неделе первым 2м активным участникам направил задачи и уже получил интересные решения, завтра будет что обсудить. Всех буду рад видеть, ссылку пришлю в бота, приходите, будет горячо! 🔥 ➡️ Регистрация тут https://t.me/mifle_engineering_bot?start=dl-1788371246344

Миграция PostgreSQL под нагрузкой: какой вопрос вы зададите первым? Приветик. Я вам задачку принёс) Ниже — сокращённый production-кейс, собранный из нескольких похожих ситуаций, в которых я успел побывать. Цифры и отдельные детали изменены, но ограничения вполне реальные. Есть сервис, который работает круглосуточно и хранит основное состояние в PostgreSQL. База занимает около 1,7 ТБ. В пике приложение обрабатывает примерно 3 500 запросов в секунду, а на стороне PostgreSQL это превращается в 15–20 тысяч запросов. Значительная часть нагрузки связана с записью. Сейчас база работает на одном мастере и двух репликах. Команде нужно перенести её в другой инфраструктурный контур и одновременно перейти на новую мажорную версию PostgreSQL. Полностью остановить трафик нельзя. Ночью нагрузка снижается примерно на треть, но не исчезает. На пиках у реплик иногда растёт лаг, а основной узел периодически упирается в дисковую подсистему. Команда приложения может выкатывать изменения поэтапно. После переключения должен оставаться понятный способ отката. На этом вводные всё. 😀 Предлагать схему миграции пока не нужно. Не требуется писать RFC, выбирать конкретные инструменты или подробно расписывать последовательность переключения. Представьте, что вас подключили к обсуждению и попросили оценить возможные планы. Какой информации вам не хватает до выбора плана? Выберите одну вводную, которую запросили бы первой. Когда несколько вариантов кажутся одинаково важными, выбирайте тот, который способен сразу исключить часть стратегий. В комментариях можно использовать простой формат:

Мне не хватает информации о ________, потому что от неё зависит ________.

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