ITSumma
رفتن به کانال در Telegram
Здесь мы: 📌 суммируем технологии, 📌 делимся опытом и полезностями 📌 рассказываем новости и интересные кейсы Для связи: @its_site_bot Сайт — www.itsumma.ru Habr — https://habr.com/ru/companies/itsumma/articles/
نمایش بیشتر257
مشترکین
اطلاعاتی وجود ندارد24 ساعت
-17 روز
+130 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
اکتبر '26اکتبر '26
اکتبر '260
در 1 کانالها
سپتامبر '26
+3
در 0 کانالها
Get PRO
اوت '26
+1
در 0 کانالها
Get PRO
ژوئیه '26
+1
در 0 کانالها
Get PRO
ژوئن '260
در 0 کانالها
Get PRO
مه '260
در 0 کانالها
Get PRO
آوریل '26
+1
در 0 کانالها
Get PRO
مارس '26
+3
در 0 کانالها
Get PRO
فوریه '26
+2
در 0 کانالها
Get PRO
ژانویه '26
+2
در 0 کانالها
Get PRO
دسامبر '25
+2
در 0 کانالها
Get PRO
نوامبر '25
+2
در 0 کانالها
Get PRO
اکتبر '25
+20
در 1 کانالها
Get PRO
سپتامبر '250
در 0 کانالها
Get PRO
اوت '250
در 0 کانالها
Get PRO
ژوئیه '250
در 0 کانالها
Get PRO
ژوئن '250
در 0 کانالها
Get PRO
مه '250
در 1 کانالها
Get PRO
آوریل '250
در 0 کانالها
Get PRO
مارس '250
در 0 کانالها
Get PRO
فوریه '250
در 0 کانالها
Get PRO
ژانویه '250
در 0 کانالها
Get PRO
دسامبر '240
در 0 کانالها
Get PRO
نوامبر '240
در 0 کانالها
Get PRO
اکتبر '240
در 0 کانالها
Get PRO
سپتامبر '24
+6
در 0 کانالها
Get PRO
اوت '240
در 0 کانالها
Get PRO
ژوئیه '240
در 0 کانالها
Get PRO
ژوئن '240
در 0 کانالها
Get PRO
مه '240
در 0 کانالها
Get PRO
آوریل '24
+1
در 0 کانالها
Get PRO
مارس '24
+4
در 0 کانالها
Get PRO
فوریه '24
+9
در 0 کانالها
Get PRO
ژانویه '24
+43
در 0 کانالها
Get PRO
دسامبر '230
در 0 کانالها
Get PRO
نوامبر '230
در 0 کانالها
Get PRO
اکتبر '230
در 1 کانالها
Get PRO
سپتامبر '230
در 0 کانالها
Get PRO
اوت '230
در 0 کانالها
Get PRO
ژوئیه '230
در 0 کانالها
Get PRO
ژوئن '23
+5
در 0 کانالها
Get PRO
مه '23
+34
در 0 کانالها
Get PRO
آوریل '23
+5
در 0 کانالها
Get PRO
مارس '23
+1
در 0 کانالها
Get PRO
فوریه '23
+8
در 0 کانالها
Get PRO
ژانویه '23
+241
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 09 اکتبر | 0 | |||
| 08 اکتبر | 0 | |||
| 07 اکتبر | 0 | |||
| 06 اکتبر | 0 | |||
| 05 اکتبر | 0 | |||
| 04 اکتبر | 0 | |||
| 03 اکتبر | 0 | |||
| 02 اکتبر | 0 | |||
| 01 اکتبر | 0 |
پستهای کانال
❤️ Что зарезервировать, чтобы пережить потерю ЦОДа: памятка
За неделю из строя вышли три площадки Яндекса: Сасово, Калуга и Владимир. 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. Проверить восстановление хотя бы одного критичного сервиса из резервной копии.
| 2 | 📥 9.09 Выступили на ПЕРФОМАНСКОНФ #12
Женя Трифонов рассказывал об Уровнях наблюдаемости на проектах, и о том как с ними работать.
Скоро ждите статью по мотивам выступления. | 86 |
| 3 | ⬅️Как бизнесу выживать при блокировках: 6 решений по ускорению загрузки сайта для не-технарей➡️
🤓 В новой статье наша разработчица Маша собрала 6 несложных мер, которые ускорят
сайт даже без глубоких технических знаний.
📖 Почитать можно здесь – https://habr.com/ru/companies/itsumma/articles/1077670/
#Статьи@itsumma | 144 |
| 4 | Трафик взлетел. Это точно атака?
Первый порыв при аномальном всплеске — врубить фильтрацию и заблокировать всё подозрительное. И именно это чаще всего приводит к ошибкам: половина «атак» оказывается распродажей, о которой не предупредили техподдержку, или собственным мониторингом, который долбит сайт чаще, чем нужно.
Собрали вместе с DDoS-Guard полный цикл: как за пять признаков в логах отличить DDoS от живого всплеска, что делать в первые минуты, чем отбиваться серверными средствами и по какому критерию выбирать между Always-On и On-Demand.
Листайте карточки — и просвещайтесь. Полная версия с разбором логов, сценариев и тарификации — в статье. | 201 |
| 5 | 📌9 сентября ищите нас на ПерформансКонф #12
Будем рассказывать (и показывать) свое видение уровней observability.
Краткое описани:
Давайте преставим историю: компания внедряет на проекте популялные SRE-практики: golden signals, четыре уровня severity, ранбуки, error budget. Через полгода у проекта есть все, о чем может только мечтать SRE инженер, кроме результатов.
Мы обслуживаем десятки инфраструктур, от типовых CMS до платёжных сервисов. Со стороны подрядчика видно то, что не видно изнутри одной компании: почему одни и те же практики где-то работают, а где-то ломают процессы. Разберём пять уровней observability и входной билет на каждый из них, цену ошибки и то, как она влияет прохождение проекта по уровням. Определим мы в этой шкале и место нагрузочного тестирования, так как доступность проекта неразрывно связана с его способностью выдерживать скачки нагрузки.
#Конференции@itsumma | 146 |
| 6 | Давайте порассуждаем: 2026-й потихоньку перерождает IaC в IaP — Infrastructure as a Prompt
Если IaC — это «инфраструктура как код», то IaP — «инфраструктура как промт». Идея та же, только вместо того чтобы описывать конфиги руками, хотелки описываются ИИ-агенту в свободной форме.
Устоявшихся бест-практисов пока нет — все практикуют IaP по-своему. Кто-то подключает агента точечно, наполнить готовый каркас, а кто-то замахивается строить инфру с нуля, целиком из промтов.
Звучит удобно: описал результат человеческим языком — получил рабочую среду, однако слон в комнате маячит весьма заметный. IaC в своё время придумали ровно ради того, что промтом легко теряется.
➡️Стандартизация: генерация из промта каждый раз может выдать чуть разный конфиг, и вместо единого стиля по инфре расползается зоопарк.
➡️Идемпотентность: прогнал дважды — а результат не тот же самый, и вот ты уже не уверен, в каком состоянии прод.
➡️Плюс галлюцинации, кривое прочтение задачи и потеря контроля, когда агент рулит средой без присмотра.
И это, по сути, главное беспокойство. Промт — мощный инструмент поверх инфры, но неаккуратный подход рушит именно те свойства, ради которых IaC когда-то и появился: воспроизводимость, предсказуемость, единый стандарт. | 163 |
| 7 | ⬅️DDoS: от алерта до выбора модели: диагностика DDoS
и Always-On vs On-Demand➡️
🤓 В новой статье вместе с партнерами DDoS-Guard поделились подходами к работе с атаками: как их правильно встречать, как ни с чем не спутать и как выбирать модель защиты.
Получилась хорошая базовая полезность.
📖 Почитать можно здесь – https://habr.com/ru/companies/itsumma/articles/1054954/
#Статьи@itsumma | 166 |
| 8 | ⬅️DDoS: от алерта до выбора модели: диагностика DDoS
и Always-On vs On-Demand➡️
🤓 В новой статье вместе с партнерами DDoS-Guard поделились подходами к работе с атаками: как их правильно встречать, как ни с чем не спутать и как выбирать модель защиты.
Получилась хорошая базовая полезность.
📖 Почитать можно здесь – https://habr.com/ru/companies/itsumma/articles/1054954/
#Статьи@itsumma | 1 |
| 9 | 🌟SSL-страдания 🌟
📥 13 июня японский GlobalSign (второй по объёму коммерческий УЦ в мире) запустил принудительный отзыв ранее выданных сертификатов — под раздачу попадает 15–20 тысяч доменов второго уровня, а с учётом поддоменов счёт идёт на сотни тысяч.
Прямо сейчас бежать и срочно всё менять не обязательно. Но вопрос «а если завтра что-то подобное случится с моим основным источником сертификатов?» — вполне здоровый.
Главное, что стоит понять: почти все публично доверяемые западные центры работают по одним и тем же правилам — для госорганов и подсанкционных компаний они закрыты так же, как GlobalSign, а от точечного отзыва не застрахован никто. По-настоящему «вне санкций» только два лагеря: НУЦ Минцифры и китайцы.
Набор вариантов сейчас, к сожалению, не самый радужный, но и не совсем уж хтоничный:
🔘 HARICA (Греция) — именно на неё уже переехали Сбер, МКБ и мессенджер Max. Запрета на .ru нет, признаётся всеми браузерами. Но в перспективе может присоединиться к санкциям.
🔘 Let's Encrypt — пока без проблем продолжает выдавать серты всему, что не госструктуры.
🔘 Actalis / SSL.com — бесплатные DV через ACME, удобно для автоматизации. Но также не застраховано от санкций.
🔘 CFCA, TrustAsia, iTrusChina (Китайские) — независимы от западных санкций, это их плюс. Минус — совместимость с сюрпризами: CFCA доверяет Chrome, но не доверяет Java.
#Полезности | 205 |
| 10 | И-и-и вот наши инсайты с выступления на DevOpsConf
➡️Открывая черный ящик: практика работы с legacy | 154 |
| 11 | Продолжаем делиться кусочками с выступления на DevOpsConf
➡️Открывая черный ящик: практика работы с legacy | 150 |
| 12 | Делимся кусочками с нашего недавнего выступления на DevOpsConf
➡️Открывая черный ящик: практика работы с legacy | 209 |
| 13 | 📥 Критическая уязвимость в 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 до патченной версии
🔴Или временно отключить уязвимый модуль | 252 |
| 14 | 📥 Критическая уязвимость в 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 до патченной версии
🔴Или временно отключить уязвимый модуль. | 1 |
| 15 | 🔘Завтра выступаем на DevOpsConf 🔘
Евгений Трифонов расскажет, как системно разбираться с legacy-инфрой, которую передали без документации, без контактов и без надежды.
📥 Кейсы: от аудита тысячи серверов до внезапного кубернетеса там, где его никто не ждал.
🗓 2 апреля, 10:00, Зал 6
Приходите, будем рады видеть! ❤️ | 116 |
| 16 | 🔘По следам прошедшего вебинара🔘
Делимся разным полезным и интересным | 194 |
| 17 | 🔘Промокоды на день влюбленных🔘
Промокоды — мощная штука. Однако даже мощные штуки надо уметь готовить
Промокод решает сразу несколько задач: привлекает новых, удерживает текущих, отслеживает эффективность каналов и запускает сарафанное радио. Главное – правильно настроить механику.
Рассказываем на примере нашего кейса с одним медиа порталом⬇️
📥 Перед 14 февраля мы запустили механику «купи подписку – получи вторую в подарок». Человек оплачивал годовую подписку и автоматически получал промокод на подарочную — для друга или близкого.
➡️Никакого ручного труда: купил ➡️ система сгенерировала промокод ➡️ отправила покупателю.
➡️При этом каждый промокод был:
➖одноразовым (не уйдёт гулять по пабликам)
➖привязан к конкретному покупателю (нельзя передать или переиспользовать)
➖ограничен по сроку (срочность = конверсия)
📥 На что это повлияло:
➡️ Рост продаж. Люди сами приводили новых пользователей – потому что у них был реальный повод и конкретный инструмент.
➡️Контроль маржи. Промокоды не утекли в скидочные каналы и не превратились в постоянную дыру в бюджете.
➡️Аналитика. Каждый промокод – это трекер. Видно, кто привёл кого, сколько активаций и какую выручку это принесло.
➡️ Окупаемость. Одна акция закрыла стоимость разработки всего функционала промокодов. | 228 |
| 18 | Вебинар прошел, а запись осталась ⬇️
🔴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 | 208 |
| 19 | ⚡️В самый горячий и тяжелый для ритейла сезон, вместе с ребятами из Selectel делимся опытом о том, как выживать в мире высоких нагрузок и распродаж.
Узнаете:
- какие элементы IT-инфраструктуры требуют особого внимания и подготовки к высоким нагрузкам ,
- как обеспечивать стабильность сервисов и бесперебойную работу приложений,
- какие архитектурные решения помогают пережить сезонные всплески.
📅 18 февраля, 12:00 МСК
📍Онлайн
Для регистрации тык сюда – https://clck.ru/3RnsV5 | 252 |
| 20 | ➡️ Мы выпустили новый кейс: Как мы стандартизировали SaaS-внедрение HR-платформы Skillaz
Если коротко – история про то, как SaaS внезапно перестаёт быть просто SaaS, когда клиенты приходят с вопросом:
А можно поставить у нас, на своей инфраструктуре?
В статье рассказываем, как мы вместе с Skillaz прошли путь от первых тяжёлых on-prem внедрений до воспроизводимого и управляемого процесса.
📖 Почитать можно здесь – https://habr.com/ru/companies/itsumma/articles/979112/
#Статьи@itsumma
#Кейс@itsumma | 251 |
