Kurgan-Telecom Ru | Информационные технологии

Пятница, 18:47. Дежурный инженер замечает: график трафика пошел вверх. Не плавно — вертикально. За несколько минут входящий поток вырастает с обычных нескольких гигабит до сотен. Потом — тишина у части клиентов. Сайты не открываются, платежный шлюз не отвечает, в чате поддержки — десятки тикетов одновременно.

Масштаб угроз хорошо иллюстрирует статистика. По данным StormWall, в первом полугодии 2026 года число DDoS-атак в России увеличилось на 73% по сравнению с аналогичным периодом 2025 года. Атаки становятся и мощнее: в начале 2026 года компании сталкивались с инцидентами свыше 2 Тбит/с, а пиковые значения доходили до 3,5 Тбит/с. Для сравнения, годом ранее самые крупные атаки фиксировались на заметно меньших уровнях. 

Можно было бы сказать: «купим защиту от DDoS, и всё». Но проблема глубже. Атаки становятся точечными: вместо массовых сетевых нагрузок злоумышленники всё чаще используют многоуровневые воздействия на критичные для бизнеса сервисы — например, платежные системы. Доля DDoS-атак, инициированных внутри страны, превысила 50% — это значительно усложняет их выявление и нейтрализацию.

Безопасность нельзя «прикрутить» к инфраструктуре постфактум: ее нужно закладывать в архитектуру с самого начала. Это и есть принцип Security-by-Design — о нем и рассказываем в статье.

Навигация по тексту:

Сертификат сайта истёк, и 21 день каждый посетитель видел предупреждение о небезопасном соединении. При этом certbot всё это время работал правильно и показывал VALID: он знает про файл на диске, а браузер получает то, что держит в памяти процесс nginx. Разбираю, почему схема «certbot на хосте, nginx в контейнере» рвётся молча, почему мониторинг всё видел и ничего не дал, и почему починка без проверки в бою остаётся гипотезой.

Созданные с помощью ИИ выводы о событиях, свидетелем которых вы были лично, порождают в сознании ложные воспоминания. Точность воспоминаний о событии снижается вдвое. А ложные воспоминания внедряются даже если вас напрямую предупредят о том, что именно ИИ подводил итоги.

Продолжаю радиолюбительскую тему.

Китайская компания Xiegu предлагает радиолюбителям не только трансиверы, но и два весьма годных усилителя с выходной мощностью 100 Вт для совместного использования с портативными QRP аппаратами. Конечно же, они в основном предназначены для работы с трансиверами Xiegu — G90, X6100 и X6200. Но эти усилители популярны и среди пользователей других QRP трансиверов, например, IC-705. И тут возникает проблема несовместимости ALC, заставляющей внимательно следить за уровнем мощности, подаваемым на усилитель. Другой момент связан с использованием внешнего автоматического тюнера: если стационарные трансиверы Icom автоматически снижают мощность до нескольких ватт при настройке тюнера, тюнер, подключенный к IC-705 и усилителю, требует внимательности: перед настройкой нужно нажать на усилителе кнопку BYPASS (BYP), и если этого не сделать, сжечь можно и тюнер, и выходной каскад усилителя. Предлагаемое устройство решает обе эти проблемы.

Привет, Хабр, меня зовут Денис Власов, я руковожу службой внешних сайтов холдинга. Несколько месяцев назад я поймал себя на странном ощущении посреди разговора с большой языковой моделью (LLM). Я объяснял ей задачу — подробно, с контекстом и примерами. Модель ответила развёрнуто и по делу. Я написал ещё. Она снова ответила. Мы «общались» уже минут двадцать, и в какой‑то момент я остановился и подумал: «А она вообще поняла, что я имею в виду? Или просто очень убедительно имитирует понимание?»

Неприятная мысль. Но ещё неприятнее было другое: я не знал, как это проверить. Не потому, что модель плохая, а потому что в нашем диалоге не было никакого механизма, который бы сигнализировал: вот моя позиция, вот что я сделал с тем, что ты сказал, вот чего я жду от тебя дальше.

Потом я вспомнил, что точно такое же ощущение бывает с людьми. Коллега говорит «Понял» — и ты не знаешь: он действительно понял? Согласился? Просто услышал и вежливо кивнул? Переписка в мессенджере, где три сообщения подряд — и непонятно, кто сейчас «ведёт», а кто ждёт. Планёрка, на которой все говорят, но никто не знает, в какой точке находится разговор.

Это раздражение, не экзистенциальное, а вполне практическое, и стало отправной точкой. Так я пришёл к идее создания RFC-протокола «Треть». Это моя попытка сделать пространство диалога немного более прозрачным.

В первой части материала мы разобрали, что необходимо контролировать в корпоративном хранилище данных - от инфраструктуры и ETL/ELT-процессов до Data Quality и выполнения запросов:

Мониторинг и логирование DWH, часть 1: уровни контроля, метрики и типовые проблемы

Во второй части перейдем к конкретным инструментам: Prometheus, Grafana, Zabbix, ELK Stack, OpenSearch, Loki. Разберем, как они устроены, какие задачи решают, чем отличаются друг от друга и на что обратить внимание при выборе стека для мониторинга и логирования DWH.

Хайп вокруг ИИ заставляет компании искать «серебряную пулю». Но как только проект доходит до этапа реализации, он разбивается о классические 6 слоев сопротивления Голдратта (Теория ограничений).

Для бизнес-аналитика понимание этих слоев — это не психология, а маршрут с критическими точками. Разберем их суть на примере внедрения ИИ в бизнес-процессы.

Привет, Хабр! Меня зовут Никита Ивкин, я — ведущий DevOps-инженер РТЛабс, работаю с инфраструктурой Госуслуг. Сегодня я покажу один из наших реальных сценариев: как мы разворачиваем ClickHouse через Arenadata, почему выбрали именно такую топологию и какие нюансы появляются между кнопкой Install и действительно рабочим кластером. Мы разберём причины выбора такой схемы, увидим, где ADCM действительно упрощает эксплуатацию, какие мелочи всплывают вокруг SSH и Ansible и почему после успешного Install хост всё ещё может выглядеть «жёлтым». В конце — проверки со стороны самого ClickHouse и несколько вещей, которыми мы дополнили кластер уже после раскатки.

T-Shape часто понимают как универсала, который умеет понемногу всё и может закрывать несколько ролей. Но исходная модель устроена иначе: в центре остаётся глубокая экспертиза, а вокруг неё растёт понимание смежных областей.

В заключительной части серии разбираем, почему ИИ делает это различие особенно важным. Типовые задачи автоматизируются всё лучше, а ценность специалиста всё сильнее зависит от глубины, контекста, системного мышления и способности работать с неопределённостью.

За последний год я проверил около двадцати торговых идей. Каждая сначала выглядела убедительно: приличная t-статистика, гладкая кривая доходности, понятная история. И каждая умерла на конкретной проверке. В этой статье собраны эти проверки с реальными цифрами «до» и «после».

Полезным итогом года оказалась не стратегия, а скорость, с которой я научился убивать неправильные.

Привет, постоянные и не очень читатели!

В первой части цикла я разобрал технологию DLSS во всех её версиях — с предпосылками и историей появления, байками и мемами про Хуанга и даже применением в бизнес-приложениях (чиво?). Материал вышел огромным, и, вероятно, самым подробным про DLSS в Рунете. Почитать можно здесь: «Судный день грядёт [часть 1]: глобальный разбор апскейлера DLSS — от игр к работе»

Теперь пора обозреть пролетарскую FSR (FidelityFX Super Resolution) — технологию улучшения изображения от AMD, которая, по моему мнению, превосходит DLSS от NVIDIA. Почему? Расскажу в конце статьи.

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

В этой статье я расскажу про источники радиации и средства её измерения. В практической части статьи будет описана погодная станция, способная измерять не только температуру, давление и влажность, но и уровень радиационного фона.

На связи Анна Астахова, директор по развитию ИТ-интегратора «Белый код». Расскажу, как мы перенесли 197 интеграционных потоков крупного девелопера на DATAREON Platform без остановки рабочих систем — и почему за задачей «перенести работающие обмены» скрывалась ревизия дублирующегося кода, забытых механизмов синхронизации и накопленной бизнес-логики.

Всем привет! Меня зовут Магомед, я инженер поддержки в команде Контента в Банки.ру. За 4 месяца я собрал на n8n несколько автоматизаций. Часть из них дежурит вместе со мной: утренний дайджест по состоянию сервисов, сторож аномалий после релизов и ИИ-агент, который знает наши сервисы, работает с Jira и умеет оценивать задачи. Другая часть работает на авторов контента: уведомляет о комментариях и просмотрах и проверяет, подходят ли к материалу прикреплённые виджеты.

В этой статье я не буду уходить в детали устройства воркфлоу: схем из n8n, промптов и разбора нод здесь не будет. Хочу показать, как конкретно я, инженер поддержки, применяю ИИ в ежедневной работе. Если захочется подробностей по какому-то из ботов, спрашивайте в комментариях, расскажу.

Привет, Хабр! Меня зовут Александр Шевченко, я техлид команды ASR ML (направление ASR/TTS-платформы Audiogram) в MWS AI. Мы занимаемся совершенствованием технологий распознаванием речи. Сегодня выкладываем в открытый доступ сразу два инструмента, которые выросли из нашей внутренней кухни за последний год: RESON (Research Engine for Speech & Observation Notes) — инструмент для анализа качества ASR-моделей, RESON OSD — открытый бенч для моделей распознавания русскоязычной речи.

Описание и ссылки — под катом.

Привет, Хабр! Меня зовут Александр Шевченко, я техлид команды ASR ML (направление ASR/TTS-платформы Audiogram) в MWS AI. Мы занимаемся совершенствованием технологий распознаванием речи. Сегодня выкладываем в открытый доступ сразу два инструмента, которые выросли из нашей внутренней кухни за последний год: RESON (Research Engine for Speech & Observation Notes) — инструмент для анализа качества ASR-моделей, RESON OSD — открытый бенч для моделей распознавания русскоязычной речи.

Описание и ссылки — под катом.

История эта началась два года назад, когда подписчики моего канала начали регулярно и настойчиво интересоваться, когда же в «Селените появится режим автономной обработки сигналов». Базовый блок трансивера получился достаточно компактным, 100х62х23 без выступающих частей, и желание пользователей «отвязать» его от компьютера, где как раз и производилась обработка сигнала, было вполне резонным.

Cloud Tracing — сервис распределённой трассировки в VK Cloud. Приложения отправляют в него спаны по протоколу OpenTelemetry, сервис хранит их и отдаёт через Jaeger-совместимое API. Поэтому трейсы можно открывать в привычных Jaeger UI и Grafana без доработок.

За этой совместимостью стоит выбор хранилища, который для публичного облака оказывается сложнее, чем кажется. Сервис принимает поток спанов от сотен несвязанных клиентов, хранит десятки терабайт телеметрии и должен надёжно изолировать данные проектов друг от друга. По умолчанию один проект может отправлять до 1 МБ/с, а доступ к данным контролируется токенами IAM. При таких ограничениях недостаточно просто выбрать базу, которая быстро записывает спаны или умеет находить трейс по trace ID.

На странице развёртывания Jaeger на момент проектирования сервиса были перечислены шесть вариантов: Cassandra, Elasticsearch, Kafka, gRPC-плагин, Badger и memory. На первый взгляд это полноценный список кандидатов. Но локальные хранилища отпадают для прода, Kafka оказывается буфером перед настоящим хранилищем, а gRPC-плагин служит способом подключить систему, которой в списке нет. В результате сравнивать приходится Cassandra и Elasticsearch, а через плагин появляется третий вариант — ClickHouse.

Я Леонид Левин, архитектор PaaS в VK Cloud. Этот разбор мы подготовили вместе с технологическим евангелистом Стасом Погоржельским и инженерами сервиса. Мы разберём, почему Cassandra и Elasticsearch по-разному подходят для хранения трейсов, что дали чужие продовые кейсы и наши замеры до 362 тысяч спанов в секунду на четырёх ядрах коллектора, а также как схема хранения на ClickHouse закрыла точечное чтение и поиск по атрибутам.

Cloud Tracing — сервис распределённой трассировки в VK Cloud. Приложения отправляют в него спаны по протоколу OpenTelemetry, сервис хранит их и отдаёт через Jaeger-совместимое API. Поэтому трейсы можно открывать в привычных Jaeger UI и Grafana без доработок.

За этой совместимостью стоит выбор хранилища, который для публичного облака оказывается сложнее, чем кажется. Сервис принимает поток спанов от сотен несвязанных клиентов, хранит десятки терабайт телеметрии и должен надёжно изолировать данные проектов друг от друга. По умолчанию один проект может отправлять до 1 МБ/с, а доступ к данным контролируется токенами IAM. При таких ограничениях недостаточно просто выбрать базу, которая быстро записывает спаны или умеет находить трейс по trace ID.

На странице развёртывания Jaeger на момент проектирования сервиса были перечислены шесть вариантов: Cassandra, Elasticsearch, Kafka, gRPC-плагин, Badger и memory. На первый взгляд это полноценный список кандидатов. Но локальные хранилища отпадают для прода, Kafka оказывается буфером перед настоящим хранилищем, а gRPC-плагин служит способом подключить систему, которой в списке нет. В результате сравнивать приходится Cassandra и Elasticsearch, а через плагин появляется третий вариант — ClickHouse.

Я Леонид Левин, архитектор PaaS в VK Cloud. Этот разбор мы подготовили вместе с технологическим евангелистом Стасом Погоржельским и инженерами сервиса. Мы разберём, почему Cassandra и Elasticsearch по-разному подходят для хранения трейсов, что дали чужие продовые кейсы и наши замеры до 362 тысяч спанов в секунду на четырёх ядрах коллектора, а также как схема хранения на ClickHouse закрыла точечное чтение и поиск по атрибутам.

Привет, Хабр! Меня зовут Максим Шуматбаев, я инженер технической поддержки в Arenadata. Это вторая часть разбора, что на самом деле происходит при работе клиентских приложений с Kafka-кластером. В первой части мы проследили запись от получения метаданных до транзакций и exactly-once. Теперь очередь второй половины пути: как потребитель получает данные, делит партиции с другими участниками группы, фиксирует прогресс и почему иногда начинает отставать.