ITSumma

❤️ Что зарезервировать, чтобы пережить потерю ЦОДа: памятка За неделю из строя вышли три площадки Яндекса: Сасово, Калуга и Владимир. 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 февраля мы запустили механику «купи подписку – получи вторую в подарок». Человек оплачивал годовую подписку и автоматически получал промокод на подарочную — для друга или близкого. ➡️Никакого ручного труда: купил ➡️ система сгенерировала промокод ➡️ отправила покупателю. ➡️При этом каждый промокод был: ➖одноразовым (не уйдёт гулять по пабликам) ➖привязан к конкретному покупателю (нельзя передать или переиспользовать) ➖ограничен по сроку (срочность = конверсия) 📥 На что это повлияло: ➡️ Рост продаж. Люди сами приводили новых пользователей – потому что у них был реальный повод и конкретный инструмент. ➡️Контроль маржи. Промокоды не утекли в скидочные каналы и не превратились в постоянную дыру в бюджете. ➡️Аналитика. Каждый промокод – это трекер. Видно, кто привёл кого, сколько активаций и какую выручку это принесло. ➡️ Окупаемость. Одна акция закрыла стоимость разработки всего функционала промокодов.

Вебинар прошел, а запись осталась ⬇️ 🔴youtube открытая: https://youtube.com/live/1bonFShmGf0?feature=share 🔴vk: https://vkvideo.ru/video-11462611_456240022?sh=4 🤓 А если хочется не только глянуть запись, но еще и получить чек-листы по теме вебинара за подписку, тык сюда – https://www.itsumma.ru/services/audit/express-audit

⚡️В самый горячий и тяжелый для ритейла сезон, вместе с ребятами из Selectel делимся опытом о том, как выживать в мире высоких нагрузок и распродаж. Узнаете: - какие элементы IT-инфраструктуры требуют особого внимания и подготовки к высоким нагрузкам , - как обеспечивать стабильность сервисов и бесперебойную работу приложений, - какие архитектурные решения помогают пережить сезонные всплески. 📅 18 февраля, 12:00 МСК 📍Онлайн Для регистрации тык сюда – https://clck.ru/3RnsV5

➡️ Мы выпустили новый кейс: Как мы стандартизировали SaaS-внедрение HR-платформы Skillaz Если коротко – история про то, как SaaS внезапно перестаёт быть просто SaaS, когда клиенты приходят с вопросом: А можно поставить у нас, на своей инфраструктуре? В статье рассказываем, как мы вместе с Skillaz прошли путь от первых тяжёлых on-prem внедрений до воспроизводимого и управляемого процесса. 📖 Почитать можно здесь – https://habr.com/ru/companies/itsumma/articles/979112/ #Статьи@itsumma #Кейс@itsumma