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

Когда компания растёт из одного продуктового направления в несколько, технический долг начинает выглядеть иначе. Проблема уже не в «старом коде», устаревших зависимостях или сложной поддержке legacy-системы. Долг начинает накапливаться в расхождении инженерных решений между сервисами.

Для нас в QIC digital hub это особенно заметно на фоне миграции на новый Go-бэкенд. Исторически платформа развивалась на разнородном стеке: разные части системы были написаны на разных технологиях. Сейчас мы постепенно переезжаем на Go. Часть сервисов уже в проде, часть ещё на пути. Именно в такой момент легко создать новый слой техдолга поверх старого: переписать поведение на новом языке, но оставить команды один на один с десятками одинаковых инфраструктурных задач, которые каждая решает по-своему.

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

- go-kit — общая библиотека с переиспользуемыми инженерными решениями;

- go-service-template — шаблон, который делает эти решения стандартным способом запуска нового сервиса;

- shared-renovate-config — общий Renovate-конфиг с единой политикой обновления зависимостей для всех репозиториев.

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

У вас есть дорогая ИСУП, которую внедряли полгода. У вас есть регламенты, ради которых лучшие люди месяцами отрывались от работы, чтобы описать, как надо работать. Формально сделано всё, но проекты все равно живут своей жизнью, важные инициативы буксуют, а проблемы выявляются слишком поздно.

Причина проста. Регламенты, которые должны управлять проектами, на практике почти никто не использует – какие-то правила давно устарели, а какие-то погребены в недрах 200-страничного документа. ИСУП же автоматизирует лишь небольшую часть процессов: управление сроками, иногда деньгами и ресурсами, – оставляя за бортом риски, цели, ответственность, связи между проектами и т.д. 

Единственное решение этой проблемы, которое я нашел, – это создать «DevOps» для регламентов. Живую цифровую модель управления, которая превращает регламенты в рудименты устаревших подходов к проектному управлению. В статье ниже я поделюсь, в чем конкретно проблема ИСУП и регламентов и как работает живая цифровая модель на практике, устраняя эти проблемы.

Я плотно работаю с финтехом и ритейлом, а это как раз те сферы, где грядёт подключение к платформе цифрового рубля. Готовиться начал заранее, так как 1 сентября 2026 года тестовый контур уже обязан быть в порядке. Полгода собирал базу, расспрашивал знакомых из финтеха, ходил на вебинары – даже на те, что делали для бухгалтеров. Я даже прочитал документы Банка России. В итоге сложилась нормальная методологическая основа.

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

Более 80 реализованных проектов, 582 активных пользователя системы и всего 4 месяца на запуск. Таких эффектов удалось достичь «Кузбассразрезуглю» на проекте внедрения Directum Projects. Как выбирали ИСУП, с какими трудностями столкнулись и какой подход использовали, мы спросили у Дмитрия Сосенкова, начальника управления развития ИТ-сервисов ООО «Скиф» — дочерней компании «Кузбассразрезуголь».

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

Расскажу с самого начала, заодно покажу цифры и то, что получилось собрать.

«Моё лицо, когда я читаю про очередное поделие с ИИ». Топ-коммент под моей прошлой статьёй: плюс четырнадцать, больше, чем собрала вся остальная ветка. Гримаса, кстати, знакомая. Я сам так смотрю на каждый лендинг с «AI-powered». Теперь так посмотрели на меня, и было за что: своего бота я подал первой же строкой через «прогоняет ссылки через AI». Пошёл разбираться, почему эти две буквы так бесят людей. Разобрался. Легче не стало: у меня самого это слово оказалось натыкано щедрее, чем я думал, в местах, куда я не догадался заглянуть.

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

В прошлом году я уже рассказывал об AVI (Aligned/Agreement Validation Interface) — концепции внешнего, гибкого и независимого от модели фильтра, который работает как умный файрвол для LLM: отбивает промпт-атаки на входе, проверяет ответы модели на токсичность, этичность и нарушение закона — на выходе. Недавно мы доработали свою концепцию с точки зрения архитектуры, реализовали и выложили на GitHub рабочий сервис на Python и FastAPI: входной и выходной фильтры, RAG-модуль, докер-сборку с мониторингом (Prometheus, Grafana, Jaeger), а также инструментарий для воспроизведения экспериментов на FinanceBench. 

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

А по-научному и подробно все описано в журнале MDPI.Electronics (на английском).  

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

В прошлом году я уже рассказывал об AVI (Aligned/Agreement Validation Interface) — концепции внешнего, гибкого и независимого от модели фильтра, который работает как умный файрвол для LLM: отбивает промпт-атаки на входе, проверяет ответы модели на токсичность, этичность и нарушение закона — на выходе. Недавно мы доработали свою концепцию с точки зрения архитектуры, реализовали и выложили на GitHub рабочий сервис на Python и FastAPI: входной и выходной фильтры, RAG-модуль, докер-сборку с мониторингом (Prometheus, Grafana, Jaeger), а также инструментарий для воспроизведения экспериментов на FinanceBench. 

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

А по-научному и подробно все описано в журнале MDPI.Electronics (на английском).  

Я скучал по C#, когда писал на Flutter, и по Flutter — когда писал на C#. Поэтому взял и совместил: Plumix — фреймворк с флаттеровской архитектурой виджетов поверх .NET и Avalonia, который во многом строят ИИ-агенты. Рассказываю про мотивацию, конвейер портирования, текущие фичи и планы.

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

Привет! Я Наташа Сляднева, руководитель центра экспертизы по комплексному сервису К2Тех. На нашем примере покажу, как сделать сопровождение прозрачным: от двухуровневого управления и работы с обратной связью до портала, Telegram-ботов и Problem Management. Статья будет полезна тем, кто отвечает за сервис, поддержку и клиентский опыт и хочет повысить прозрачность и доверие.

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

В юморе существуют паттерны шуток которыми пользуются все комики и все люди которые когда либо шутили. Они уже давно известны. Перечень паттернов

Подмена ожидания, Гипербола, Сравнение, Ирония, Сарказм, Двусмысленность, Каламбур, Абсурд, Антишутка, Шутка с вопросом-ответом, Повтор с нарастанием, Ложная логика, Доведение до абсурда, Обратный смысл, Нелепица, Пародия, Цитата вне контекста, Чёрный юмор, Самоирония, Эскалация

И я решил написать программу тренажер для тех кто хочет научиться остроумно шутить.

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

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

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

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Олегом Щёголевым — frontend-разработчиком, преподавателем, ментором и специалистом по Angular автором Telegram-канала «SUMMON_THE_CODER».    

В этом выпуске мы разбираем путь в профессию, реальные проекты, ситуацию на рынке труда, зарплаты, использование нейросетей в разработке, статус GDE, современный Angular, сигналы, SSR, CLI, директивы, модули и главный вопрос: почему React популярнее, но крупные компании всё равно продолжают выбирать Angular.

Думали ли вы когда-нибудь, что запустить своего бота на сервере можно всего за один запрос к нейронке, который займет около двух минут?

Мы недавно разработали MCP-сервер, позволяющей AI-агенту в Codex или Claude поставить бота на хостинг одним промтом.

Итак, разберем нововведение и опробуем его.

В одной из своих статей я уже рассказывал, как из Raspberry Pi Pico сделать USB CD-ROM. Так как размер флеш-памяти Pico ограничен, поместить что-то серьёзное в образ, который будет находиться во флеш-памяти невозможно. Можно попробовать разместить образ на флеш-карте и использовать модуль для неё, но я нашёл более интересное с точки зрения используемых технологий решение. Эмулировать образ, который находится в интернете. Образа многих дистрибутивов Linux доступны для загрузки с сайта.

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

Эта идея появилась у меня давно.

Когда мы внедряли BI в крупном банке, я заметил одну вещь: больше всего внедрению радовались руководители. У них появлялись дашборды, графики, показатели, визуальная картина происходящего.

А вот люди, которые каждый день работали с данными, не всегда были в таком же восторге.

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

И вот тут уже приходится разбираться не с графиком, а с данными.

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

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

Для таких задач пользователи всё равно часто уходили в Excel: добавляли формулы, сверяли расчёты, сравнивали текущую выгрузку с предыдущей.

Так появилась первая версия программы: она формировала отчёты в Excel и хранила на сервере историю выгрузок.

Про ARC, weak/unowned и retain cycle на русском написано столько, что добавить нечего. Про borrowing/consuming и ~Copyable (это, к слову, Swift 5.9, а не 6 - частая путаница) на английском тоже десятки разборов. И почти все они устроены одинаково: объясняют, что фича делает, на игрушечном примере с файловым дескриптором, и заканчивают выводом «так безопаснее и быстрее».

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

Статью я старался написать так, чтобы её читал не только стафф. Поэтому по ходу я коротко объясняю базовые вещи - стек и кучу, ARC, copy-on-write. Если вы это и так знаете, просто пролистывайте врезки «на полях».