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

Привет, Хабр! Я Наталья Самсонова, фулстек-аналитик в ГК «Юзтех». Последнее время работаю пресейл-аналитиком в продуктовой команде. Несколько десятков встреч с клиентами в этом качестве позволили мне заметить значительную разницу в целеполагании заказчиков в проектах заказной и продуктовой разработки. О чем конкретно речь и почему это важно при выборе интеграционной платформы — рассказываю в статье.

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

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

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

Иногда на пресейл-встречах сами заказчики интересуются у нас: как понять, что наши текущие решения исчерпали себя и пора выходить на новый уровень – использование платформы, как основы построения корпоративной экосистемы управления данными?

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

Задачу по линейной алгебре которую студент не мог решить три часа нейросеть разобрала за две минуты. Причём не просто дала ответ — объяснила каждый шаг, показала где типичная ошибка в таком типе задач и предложила похожую задачу для закрепления. Это не магия и не замена мышлению. Это инструмент который меняет скорость обучения если понять как им правильно пользоваться.

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

Два года в Телеграм Адс, сезонные паузы и 260 креативов — история о том, как удержать цену в конкурентной нише детского образования

Начиная работать с Podman, я задал себе вопрос — функционирует ли healthcheck в Podman так же, как в Docker? Да и нет. В этой статье разберем, зачем он вообще нужен, какие бывают типичные ошибки при запуске контейнера с healthcheck, выясним детали о systemd и Quadlet.

В индустрии есть устоявшееся мнение, что HDD — это устаревающая технология.

Это с одной стороны. С другой стороны, много у кого написано «Медленные SSD», а по факту при тестах они начинают показывать характерные скорости HDD, характерные бутылочные горлышки HDD и вообще ведут себя как жёсткие диски.

У нас тоже есть тариф с HDD-хранилищем, но он довольно давно тариф с HDD-содержащим хранилищем, потому что уже пять-шесть лет (в зависимости от страны) мы закупаем SSD вместо HDD. Совсем скоро последние хрустящие диски уйдут из эксплуатации, и это будет тариф типа SSD с ограничением по скорости для совместимости с легаси-ценами.

При этом мы используем HDD для долговременного хранения.

Поводом к написанию предыдущей статьи «Шаблоны и принципы деления кода на классы» послужил случай с начинающим программистом, который обратился ко мне за помощью. Однако та история получила неожиданное продолжение, ставшее, в свою очередь, одной из предпосылок уже для этой статьи. И видимо, волей судьбы или просто по забавному стечению обстоятельств, эта история оказалась напрямую связана с комментариями к первой статье, где в ходе жаркого диалога я затронул тему мышления и восприятия кода разработчиком.

Так родилась идея поделиться накопившимися за 10-летний стаж наблюдениями и плодами размышлений:

- Как стиль написания кода отражает образ мышления разработчика.

- Как разработчики воспринимают код программы.

- Почему один язык программирования, что называется, «заходит», а другой - нет.

Будучи поклонником идеи Айзека Азимова о коллаборации C/Si форм жизни, я провёл эксперимент и сгенерировал данный текст автоматически, AI агентом, по контексту, сформированному в процессе разработки новой фичи оптимизатора Postgres и расследования проблемного corner case, который время от времени завершался с runtime-ошибкой. Это первый опыт подобной совместной работы и проба пера, поэтому возможны шероховатости. Однако сама проблема и вариант решения для Postgres валидированы вручную. Любая, даже самая жёсткая критика, приветствуется.

Представьте, что вы выкидываете около 10 миллионов рублей в год просто на то, чтобы ваш Kubernetes-кластер вертелся, а логи не съедали всё свободное место. Пока инженеры строят распределенные системы ради красивой строчки в резюме, каждый лишний сетевой запрос срезает вам конверсию, а облачная инфраструктура обходится втрое дороже своего железа. Давайте посчитаем реальный TCO микросервисов и разберемся, почему даже гиганты вроде Amazon Prime Video возвращаются к монолитам, сокращая траты на 90%.

Однажды, а если быть конкретнее, то в октябре, приходит CEO на совет директоров и говорит: «Так больше продолжаться не может». В принципе, на тут можно заканчивать статью, но давайте расскажу, как пережить это без вреда текущим процессам и планам.

В марте 2026 года экосистема Trivy пережила supply chain-инцидент. Согласно официальному advisory компании Aqua Security, злоумышленник использовал скомпрометированные учетные данные для публикации вредоносного релиза Trivy v0.69.4, перепривязки большинства тегов trivy-action к credential-stealing malware и замены тегов setup-trivy. Позднее были опубликованы и вредоносные Docker Hub образы v0.69.5 и v0.69.6.

Практический смысл этого кейса заключается в том, что компрометация затронула не один контейнерный образ, а сразу несколько официальных каналов доставки. Для команды разработки из этого следует неприятный, но важный вывод: внешний security-инструмент не становится доверенным только потому, что он популярен, официально поддерживается или связан с безопасностью.

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

Я — ребенок эпохи плавающих одеял Ariston, безалкогольной «Балтики 7» (оказывается, что она до сих пор рекламируется так), «Миль Попс» и «Скелетонов».

Помните, какой сумасшедшей и необычной реклама была раньше? 

Конечно, откровенной шляпы было много. Но сколько же алмазов было в этой куче. В 1990-х и 2000-х правил и запретов было меньше. Компании, которые уже поделили рынок и сидят на золотых кучах, еще был молодыми. 

На этой ноте реклама была сумасшедшей. Но время прошло. 

Ностальгия толкнула меня покопаться в анналах рекламной истории и узнать, что именно случилось с креативом, случилось ли на самом деле и когда произошел перелом. 

Прошлой осенью я лишился своего VPN-сервиса. Классический селфхостед на VDS, поднятом у зарубежного хостера, без посредников. Работал надёжно, стоил копейки — и я привык к тому, что всё просто работает. Осенняя волна блокировок смела его вместе с тысячами похожих.

Эта история заставила меня остановиться и подумать. Не о том, как быстрее восстановить доступ к утраченному сервису — технически это вполне решаемая проблема. А о природе произошедшего: почему схема, работавшая годами, сломалась?

Привет, Хабр!

В прошлой статье я рассказывал, что с недавнего времени я развлекаюсь в мире highload тем что создаю для себя и своих близких мессенджер (Plumb). И несмотря на то, что клиент для него собран практически из цифровой изоленты, которую хорошенько искупали в бочонке с красками — он на удивление стабильно работает (и мессаджинг, и звонки) даже в текущих непростых реалиях.

В той статье я предложил Хабру попытаться сломать сервер моего мессенджера. Было потно, но мы выстояли. Спасибо всем, кто участвовал!

Но сегодня я хочу поговорить о другом. На примере одной реальной массированной автоматизированной атаки на мой сервер хочу показать как боты и специализированное ПО пытаются атаковать ваши веб-приложения и серверы в 2026 году. Эта реальная атака - идеальный, хрестоматийный пример того, как именно сегодня сканируют современную инфраструктуру. Никакой магии, только голые логи, разбор векторов и механика защиты. Поехали.

AI ассистенты уже просто вошли в процессы разработки кода, но что на счет DevOps задач и CI/CD в частности? Думаю здесь их полезность может оказаться не чуть не меньше.

Как часто к вам или вы прибегали с круглыми глазами и просьбами помочь с упавшим пайплайном?

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

К счастью теперь за нас это могут нейросети и давать дельные советы (не все, но могут)

Всем добрый день! 

Я уже почти 15 лет работаю в сфере разработки инновационных лекарственных препаратов и диагностических инструментов, и на моей памяти приход новых технологий не раз порождал иллюзию скорого избавления человечества от всех болезней. И, конечно, разного рода открытия в области генной инженерии, иммуно-онкологии и молекулярной биологии поспособствовали появлению инновационных терапий, однако, к сожалению, многочисленные заболевания пока не поддаются излечению.  

В какой-то момент инструментом поиска панацеи стал считаться искусственный интеллект (здесь достаточно вспомнить намерения Цукерберга вылечить все болезни или заявления Билла Гейтса о том, что ИИ заменит большую часть врачей).  Однако, как и во многих других отраслях, вслед за бумом завышенных ожиданий пришло осознание границ применимости методов и более зрелое отношение к технологиям. В этой статье я хотела бы описать взгляд традиционного ученого на “хайп” вокруг нейросетей и громогласные высказывания о том, что скоро нас всех заменит искусственный интеллект.

Сервер лагает. Смотришь на диск — df -h говорит 95% занято. Запускаешь du -sh /* — в сумме набирается 20%. Куда делись остальные 75%? Файлы не найти, место не освободить, сервис падает.

Это не баг и не магия. Это фундаментальная особенность того как Linux работает с файлами. Разберём почему так происходит и как это чинить за две команды.

Продолжаем тему эпических багов. В прошлый раз мы говорили про AT&T, положивших свою ультранадежную сеть одним "Break" в коде. Сегодня на очереди Knight Capital Group, решивших переиспользовать старый флаг в бинарном протоколе, затем там был мёртвый код, который забыли удалить и деплой, проверенный на семи серверах из восьми. Итог: уход в минус 450 миллионов долларов за 45 минут.

На Хабре этот инцидент упоминался несколько раз, но даже в самой большой статье (к слову, переводу, со всеми странными атрибутами инопрессы, вроде фраз "Атака зомби из «Кода убийцы»" и пространным вступлением) инцидент рассматривался скорее как финансовый. А нас же больше интересуют именно технические детали.

С определенным успехом методы математического программирования захватили множество задач автоматизации и оптимизации бизнес процессов (маршрутизация доставки, планирование производства или графиков работы сотрудников, планирование сетей и т.д.). Используемые методы решения и классические постановки задач десятилетиями остаются без серьезных изменений. Когда ждать революцию? Кто имеет потенциал для ее организации?

Проведем эксперимент на предмет того, есть ли у RL способности решать оптимизационные задачи. Для исследования возьмем не сложную практическую оптимизационную задачу и оценим как обучение с подкреплением справится.

Материал будет полезен как заядлым специалистам по мат.оптимизации, так и ml-инженерам или data scientist’ам. Рассматриваемая задача может быть интересна специалистам из области логистики/транспортных перевозок.

Представьте: вы сидите вечером за монитором, на экране ваша любимая темная тема в редакторе кода и вдруг белые буквы на темном фоне начинают подпрыгивать. Не метафорически - буквально. Чуть-чуть, на пару пикселей, но вы это видите. Переводите взгляд на стену - геометрический рисунок обоев то подёргивается, то выглядит как всегда. Моргаете, трете глаза - вроде прошло. Через десять минут - снова.

Вы идёте к офтальмологу. Авторефрактометр, таблица, давление, глазное дно. «У вас все в норме. Астенопия. Делайте перерывы, капайте увлажняющие капли».

Вы делаете перерывы. Капаете капли. Буквы продолжают прыгать.

80k RPS и 25 Гбит/с трафика тайлов с одного сервера — звучит как мечта для картографического сервиса? На самом деле это реально — если ваш способ отдачи тайлов спроектирован для этого.

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

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