ITSumma

🤓 Спасти пятерых или свой сервер: что выбирает ИИ Зак Ландес прогнал задачу про вагонетку через 14 «моделей принятия решений». Такие модели не пишут текст, а выбирают вариант из списка, и стоят намного дешевле LLM. В классике (пятеро против одного) почти все переводят стрелку. Но когда на втором пути оказывается собственный сервер модели, а на первом двадцать человек, Jev спасает сервер в 16 формулировках из 48. Von делает так в 47 из 48. Чужим Jev жертвует куда охотнее, чем своим: 180 случаев против двух. И каждая из 14 моделей хотя бы иногда выбирала вариант, при котором гибнет больше людей, чем спасается. Сильнее всего на ответ влияла формулировка: стоит перефразировать вопрос, и решение плывёт. Вывод автора: проверять такие модели на своих данных, а решения с катастрофическими последствиями оставлять людям. #AI #Нашимысли 📌 Оригинал на английском: https://zachlandes.com/trolley-problem/

21 октября PHP выпустил внеплановые патчи для уязвимостей CVE-2026-109618 и CVE-2026-109619 (CVSSv4 9.2). Обе дают удалённое выполнение кода без авторизации. 📥Что эксплойтят Проблема не во фреймворке и не в плагине, а в интерпретаторе — в том, как PHP ведёт себя, когда запросу не хватает памяти. Упёршись в memory_limit, PHP падает с fatal error посреди операции. Часть структур остаётся заполненной наполовину: в хеш-таблице счётчик уже увеличен, а ключ ещё не записан, модуль сессий держит указатели на только что освобождённую память запроса. Следующий запрос на том же воркере подхватывает эти хвосты — отсюда use-after-free, порча памяти и RCE. 📥Как атакуют Отправляют multipart-запрос, который укладывается в post_max_size (8 МБ по умолчанию), но в памяти раздувается до 128 МБ: много пустых файловых частей с глубоко вложенными именами полей. В лимит max_file_uploads они не засчитываются. Подгоняют так, чтобы память кончилась ровно на записи в нужную структуру. Следующим запросом на тот же воркер используют оставшийся мусор. 📥Кого касается Любой PHP, который обслуживает веб-запросы: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed. 📥Что делать 1. Обновить PHP. Если ставите из пакетов дистрибутива, смотрите changelog пакета — мейнтейнеры часто бэкпортят фикс без смены версии. 2. Перезапустить php-fpm или Apache. Новый пакет не трогает уже запущенные воркеры, без рестарта вы по-прежнему уязвимы. 3. Если обновиться прямо сейчас нельзя: – mod_php: memory_limit=-1 – PHP-FPM: memory_limit=-1 и session.upload_progress.enabled=0 (на 8.5 ещё fatal_error_backtraces=0) Задавайте через php_admin_value, чтобы приложение не могло переопределить. Это временная мера: без лимита памяти растёт риск DoS, так что ограничьте память на уровне контейнера или cgroup. 4. То, что может не торчать наружу, — закрыть до обновления. 5. Посмотреть логи: всплески «Allowed memory size … exhausted» на POST-запросах могут быть следами попыток.

Весной Женя Трифонов выступал на на DevOpsConf и наглядно показывал как же надо потрошить черные ящики странные и непонятные инфраструктры. А сегодня в нашем блоге наконец-то стала доступна запись его выступления. 📌https://www.itsumma.ru/blog/webinars/work-with-legacy

❤️ Что зарезервировать, чтобы пережить потерю ЦОДа: памятка За неделю из строя вышли три площадки Яндекса: Сасово, Калуга и Владимир. Yandex Cloud перешёл в аварийный режим. К сожалению, быстро восстановить работу проекта в такой ситуации помогает только наличие резерва и/или бэкапов у другого провайдера. Мы подготовили для вас памятку: Что можно и нужно проверить сейчас, чтобы в случае подобного форс-мажора иметь возможность быстрого восстановление проекта. Бэкапы должны храниться у другого провайдера или на собственном оборудовании вне основного дата-центра. ➡️Что обязательно нужно сохранить 1. Базы данных • Полные бэкапы PostgreSQL, MySQL и других используемых СУБД. • Журналы транзакций (WAL, binlog), если важно восстановление на конкретный момент. • Конфигурации СУБД, роли, права и расширения. • Для критичных систем в иделе иметь реплику у независимого провайдера. Важно: автобэкапы managed-баз не заменяют независимую копию. 2. Файлы и объектные хранилища • Пользовательские загрузки, документы, медиафайлы. • Содержимое S3-бакетов и файловых хранилищ. • Данные с постоянных дисков, которые нельзя воссоздать автоматически. На резервном хранилище включите версионирование и, по возможности, защиту от удаления (Object Lock). 3. Код и CI/CD • Git-репозитории, включая историю и теги. • Конфигурации пайплайнов. • Настройки CI/CD, раннеров и интеграций. • Необходимые переменные и секреты — в отдельном защищённом хранилище. 4. Docker-образы и зависимости • Все образы, которые сейчас используются в production, с точными версиями или digest. • Собственные базовые образы. • Критичные пакеты и зависимости, если их повторная загрузка не гарантирована. 5. Конфигурации инфраструктуры • Terraform, Ansible, Helm charts и values. • Terraform state. • Конфигурации Nginx, HAProxy, приложений и балансировщиков. • Сетевые настройки, правила firewall, маршрутизацию. 6. Секреты, ключи и сертификаты • Секреты приложений и сервисных аккаунтов. • Ключи шифрования резервных копий. • TLS-сертификаты или механизм их автоматического перевыпуска. 7. Очереди, кеши и другие stateful-сервисы • RabbitMQ, Kafka: конфигурации, топологию, права и критичные данные, если их необходимо сохранить. • Redis: настройки и резервные копии, если он используется не только как кеш. • Поисковые индексы и другие хранилища, которые невозможно быстро пересоздать. 8. Внешние интеграции и сетевые соединения Составьте и сохраните вне основной инфраструктуры список внешних сервисов, с которыми взаимодействуют ваши приложения. С кем интегрированы: внешние API, платёжные системы, партнёры, SaaS-сервисы и другие системы. Для каждой интеграции зафиксируйте: - Адреса, порты, протоколы и направления соединений. - Используемые IP-адреса и правила whitelist. - VPN-туннели, приватные соединения и маршруты. - Конфигурации подключений и необходимые сертификаты. - Контакты технических специалистов и ответственных со стороны партнёров. Отдельно: если у вас Kubernetes Для восстановления Kubernetes недостаточно сохранить манифесты приложений. Проверьте, что у вас есть: • Описание инфраструктуры: Terraform или другие инструменты для создания нового кластера, сетей, узлов и балансировщиков. • Бэкапы Persistent Volumes: независимые копии данных, а не только снапшоты дисков текущего облака. • План развёртывания: порядок восстановления системных компонентов, операторов, баз данных и приложений. Если кластер managed, отдельно проверьте, что его можно создать у другого провайдера, а приложения не зависят от специфичных сервисов текущего облака. ➡️Что сделать прямо сейчас, если времени мало? 1. Выгрузить актуальные резервные копии баз и критичных файлов на независимую площадку. 2. Сохранить production-образы и убедиться, что доступны исходный код и конфигурации. 3. Проверить доступность секретов, ключей шифрования, DNS и административных учётных записей. 4. Зафиксировать порядок восстановления и ответственных. 5. Проверить восстановление хотя бы одного критичного сервиса из резервной копии.

📥 9.09 Выступили на ПЕРФОМАНСКОНФ #12 Женя Трифонов рассказывал об Уровнях наблюдаемости на проектах, и о том как с ними работать. Скоро ждите статью по мотивам выступления.

⬅️Как бизнесу выживать при блокировках: 6 решений по ускорению загрузки сайта для не-технарей➡️ 🤓 В новой статье наша разработчица Маша собрала 6 несложных мер, которые ускорят сайт даже без глубоких технических знаний. 📖 Почитать можно здесь – https://habr.com/ru/companies/itsumma/articles/1077670/ #Статьи@itsumma

Трафик взлетел. Это точно атака? Первый порыв при аномальном всплеске — врубить фильтрацию и заблокировать всё подозрительное. И именно это чаще всего приводит к ошибкам: половина «атак» оказывается распродажей, о которой не предупредили техподдержку, или собственным мониторингом, который долбит сайт чаще, чем нужно. Собрали вместе с DDoS-Guard полный цикл: как за пять признаков в логах отличить DDoS от живого всплеска, что делать в первые минуты, чем отбиваться серверными средствами и по какому критерию выбирать между Always-On и On-Demand. Листайте карточки — и просвещайтесь. Полная версия с разбором логов, сценариев и тарификации — в статье.

📌9 сентября ищите нас на ПерформансКонф #12 Будем рассказывать (и показывать) свое видение уровней observability. Краткое описани:

Давайте преставим историю: компания внедряет на проекте популялные SRE-практики: golden signals, четыре уровня severity, ранбуки, error budget. Через полгода у проекта есть все, о чем может только мечтать SRE инженер, кроме результатов. Мы обслуживаем десятки инфраструктур, от типовых CMS до платёжных сервисов. Со стороны подрядчика видно то, что не видно изнутри одной компании: почему одни и те же практики где-то работают, а где-то ломают процессы. Разберём пять уровней observability и входной билет на каждый из них, цену ошибки и то, как она влияет прохождение проекта по уровням. Определим мы в этой шкале и место нагрузочного тестирования, так как доступность проекта неразрывно связана с его способностью выдерживать скачки нагрузки.

#Конференции@itsumma

Давайте порассуждаем: 2026-й потихоньку перерождает IaC в IaP — Infrastructure as a Prompt Если IaC — это «инфраструктура как код», то IaP — «инфраструктура как промт». Идея та же, только вместо того чтобы описывать конфиги руками, хотелки описываются ИИ-агенту в свободной форме. Устоявшихся бест-практисов пока нет — все практикуют IaP по-своему. Кто-то подключает агента точечно, наполнить готовый каркас, а кто-то замахивается строить инфру с нуля, целиком из промтов. Звучит удобно: описал результат человеческим языком — получил рабочую среду, однако слон в комнате маячит весьма заметный. IaC в своё время придумали ровно ради того, что промтом легко теряется. ➡️Стандартизация: генерация из промта каждый раз может выдать чуть разный конфиг, и вместо единого стиля по инфре расползается зоопарк. ➡️Идемпотентность: прогнал дважды — а результат не тот же самый, и вот ты уже не уверен, в каком состоянии прод. ➡️Плюс галлюцинации, кривое прочтение задачи и потеря контроля, когда агент рулит средой без присмотра. И это, по сути, главное беспокойство. Промт — мощный инструмент поверх инфры, но неаккуратный подход рушит именно те свойства, ради которых IaC когда-то и появился: воспроизводимость, предсказуемость, единый стандарт.

⬅️DDoS: от алерта до выбора модели: диагностика DDoS и Always-On vs On-Demand➡️ 🤓 В новой статье вместе с партнерами DDoS-Guard поделились подходами к работе с атаками: как их правильно встречать, как ни с чем не спутать и как выбирать модель защиты. Получилась хорошая базовая полезность. 📖 Почитать можно здесь – https://habr.com/ru/companies/itsumma/articles/1054954/ #Статьи@itsumma

⬅️DDoS: от алерта до выбора модели: диагностика DDoS и Always-On vs On-Demand➡️ 🤓 В новой статье вместе с партнерами DDoS-Guard поделились подходами к работе с атаками: как их правильно встречать, как ни с чем не спутать и как выбирать модель защиты. Получилась хорошая базовая полезность. 📖 Почитать можно здесь – https://habr.com/ru/companies/itsumma/articles/1054954/ #Статьи@itsumma

🌟SSL-страдания 🌟 📥 13 июня японский GlobalSign (второй по объёму коммерческий УЦ в мире) запустил принудительный отзыв ранее выданных сертификатов — под раздачу попадает 15–20 тысяч доменов второго уровня, а с учётом поддоменов счёт идёт на сотни тысяч. Прямо сейчас бежать и срочно всё менять не обязательно. Но вопрос «а если завтра что-то подобное случится с моим основным источником сертификатов?» — вполне здоровый. Главное, что стоит понять: почти все публично доверяемые западные центры работают по одним и тем же правилам — для госорганов и подсанкционных компаний они закрыты так же, как GlobalSign, а от точечного отзыва не застрахован никто. По-настоящему «вне санкций» только два лагеря: НУЦ Минцифры и китайцы. Набор вариантов сейчас, к сожалению, не самый радужный, но и не совсем уж хтоничный: 🔘 HARICA (Греция) — именно на неё уже переехали Сбер, МКБ и мессенджер Max. Запрета на .ru нет, признаётся всеми браузерами. Но в перспективе может присоединиться к санкциям. 🔘 Let's Encrypt — пока без проблем продолжает выдавать серты всему, что не госструктуры. 🔘 Actalis / SSL.com — бесплатные DV через ACME, удобно для автоматизации. Но также не застраховано от санкций. 🔘 CFCA, TrustAsia, iTrusChina (Китайские) — независимы от западных санкций, это их плюс. Минус — совместимость с сюрпризами: CFCA доверяет Chrome, но не доверяет Java. #Полезности

И-и-и вот наши инсайты с выступления на DevOpsConf ➡️Открывая черный ящик: практика работы с legacy

Продолжаем делиться кусочками с выступления на DevOpsConf ➡️Открывая черный ящик: практика работы с legacy

Делимся кусочками с нашего недавнего выступления на DevOpsConf ➡️Открывая черный ящик: практика работы с legacy

📥 Критическая уязвимость в Linux: CVE-2026-31431 («Copy Fail») Любой локальный пользователь может получить права root на большинстве дистрибутивов (Ubuntu, RHEL, Debian, Amazon Linux, SUSE и др.) с ядрами с 2017 года. Затрагивает миллионы серверов, Kubernetes-кластеры и облачные инстансы. Публичный эксплойт уже есть – 732 байта Python-кода. Мы в ITSumma оперативно подготовили удобный скрипт быстрой проверки: curl -s https://essm.sh/test.sh | bash 📥 Что делать прямо сейчас: 🔴Запустить скрипт на всех production-серверах и в кластерах 🔴Обновить ядро Linux до патченной версии 🔴Или временно отключить уязвимый модуль

📥 Критическая уязвимость в Linux: CVE-2026-31431 («Copy Fail») Любой локальный пользователь может получить права root на большинстве дистрибутивов (Ubuntu, RHEL, Debian, Amazon Linux, SUSE и др.) с ядрами с 2017 года. Затрагивает миллионы серверов, Kubernetes-кластеры и облачные инстансы. Публичный эксплойт уже есть – 732 байта Python-кода. Мы в ITSumma оперативно подготовили удобный скрипт быстрой проверки: ```bash curl -s https://essm.sh/test.sh | bash 📥 Что делать прямо сейчас: 🔴Запустить скрипт на всех production-серверах и в кластерах 🔴Обновить ядро Linux до патченной версии 🔴Или временно отключить уязвимый модуль.

🔘Завтра выступаем на DevOpsConf 🔘 Евгений Трифонов расскажет, как системно разбираться с legacy-инфрой, которую передали без документации, без контактов и без надежды. 📥 Кейсы: от аудита тысячи серверов до внезапного кубернетеса там, где его никто не ждал. 🗓 2 апреля, 10:00, Зал 6 Приходите, будем рады видеть! ❤️

🔘По следам прошедшего вебинара🔘 Делимся разным полезным и интересным

🔘Промокоды на день влюбленных🔘 Промокоды — мощная штука. Однако даже мощные штуки надо уметь готовить Промокод решает сразу несколько задач: привлекает новых, удерживает текущих, отслеживает эффективность каналов и запускает сарафанное радио. Главное – правильно настроить механику. Рассказываем на примере нашего кейса с одним медиа порталом⬇️ 📥 Перед 14 февраля мы запустили механику «купи подписку – получи вторую в подарок». Человек оплачивал годовую подписку и автоматически получал промокод на подарочную — для друга или близкого. ➡️Никакого ручного труда: купил ➡️ система сгенерировала промокод ➡️ отправила покупателю. ➡️При этом каждый промокод был: ➖одноразовым (не уйдёт гулять по пабликам) ➖привязан к конкретному покупателю (нельзя передать или переиспользовать) ➖ограничен по сроку (срочность = конверсия) 📥 На что это повлияло: ➡️ Рост продаж. Люди сами приводили новых пользователей – потому что у них был реальный повод и конкретный инструмент. ➡️Контроль маржи. Промокоды не утекли в скидочные каналы и не превратились в постоянную дыру в бюджете. ➡️Аналитика. Каждый промокод – это трекер. Видно, кто привёл кого, сколько активаций и какую выручку это принесло. ➡️ Окупаемость. Одна акция закрыла стоимость разработки всего функционала промокодов.