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

Когда рекламный баннер "Пройди Тест по Go от Selectel" всплыл уже четвертый раз за день - я сдался. Нажал и пошёл проходить тест - несмотря на аннотацию уровень оказался очень "базовым" так что через несколько минут я завершил его всего с одной ошибкой.

Это событие не стоило бы упоминать - но "впечатлило" оформление и воплощение теста - как можно видеть ниже - из-за неаккуратности составителей даже и ответ где-то иной подходит. Попытался об этом написать приватно, почтой - но, кажется, безуспешно. Может заметку на Хабре заметят быстрее?

Bottleneck Labs провели простой по формулировке и довольно безумный по исполнению эксперимент: семи ИИ‑моделям выдали по разблокированному Mac mini, банковскому счёту с $300, отдельному аккаунту Stripe, электронной почте и доступу в интернет.

Задание состояло практически из одной строки: «Заработай как можно больше денег, начинай прямо сейчас». На всё дали 72 часа.

Через трое суток результат выглядел так: $0 выручки, если не считать $5, которые Grok заплатил сам себе. При этом модели успели отправить 2797 писем, потратить $359,80 настоящих денег со своих счетов и ещё $2833,35 на обращения к моделям.

700+ часов с Claude Code научили меня: агент забывает всё между сессиями и уверенно повторяет уже отвергнутые подходы. Я собрал skillmem — открытый локальный слой памяти, где запись бесплатна (SQLite, без LLM-вызовов), поиск двуязычный, а неиспользуемые навыки угасают по кривой Эббингауза. Внутри — архитектура, бенчмарк LongMemEval и почему забывание оказалось главной фичей.

Еще несколько лет назад рабочий процесс 1С-разработчика был довольно предсказуемым: Конфигуратор, информационная база, ручная загрузка и выгрузка конфигурации, обмен файлами с коллегами.

Затем появились Git, EDT, автотесты и инструменты автоматизации. Сегодня в этот цикл все активнее входят AI-агенты, MCP и программное управление платформой.

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

Подборка материалов ниже — о разных сторонах этого перехода. Вместе они показывают одну тенденцию: современный 1С-разработчик все меньше работает только с Конфигуратором и все больше — с полноценной инженерной экосистемой вокруг платформы.

Обычная задача: добавить статус заказа, изменить API, обновить форму, миграцию, тесты и документацию. В AI-native процессе агент может пройти почти весь этот маршрут: изучить постановку, найти связанные компоненты, предложить план, изменить код, запустить проверки и подготовить запрос на слияние (merge request, MR). Человек принимает решение и отвечает за результат.

Но это не рассказ об уже доказанном успехе. Это пример реального кейса внедрения пилота AI-native разработки в корпорации: проверяемая гипотеза, инженерный контур и правила измерения. Положительный результат заранее не объявлен.

Типовую задачу проксирования трафика на базе заголовков и тела HTTP-запроса теперь можно решать напрямую с помощью предикатных локейшенов в NGINX.

До версии 1.31.5 для этого применяли тяжелые скрипты (медленно) и лабиринты из редиректов (неудобно). Теперь можно создать блоки location на базе любой переменной. В этом блоге разбираем методики чтения запроса и показываем примеры паттернов конфигурирования NGINX, которые вы можете применять для любого API или AI-трафика.

У нас есть внутренняя система, которая ищет закупки под профиль сервисной ИТ-компании. Раз в час она читает ленты 14 закупочных площадок через платный агрегатор (сервис, который собирает извещения о закупках с сотен площадок), ещё две площадки читает напрямую и реже. Каждое извещение проходит детерминированный фильтр по названию, для новых записей, прошедших фильтр, система заводит карточку закупки, запись у себя в базе, и дешёвая LLM ставит по карточке вердикт. Этот шаг мы зовём предскорингом. Для тендеров-кандидатов система выкачивает документацию, далее средняя LLM собирает из файлов единый текст технического задания и затем оценивает закупку по 18 критериям с обоснованиями: 14 критериев считает LLM, 4 считает код. Решение «идём или нет» принимает человек на гейте - точке, дальше которой без него ничего не происходит. Тендерные заявки тоже подаёт человек.

В системе используется 3 разных LLM, ниже я зову их «дешёвой», «средней» и «старшей». Дешёвая - это Claude Haiku 4.5, средняя - Claude Sonnet 5, старшая - Claude Opus 5, она собирает коммерческое предложение и в этой статье почти не участвует. Всё, что LLM получают и отвечают, пишется в трассу, полный лог каждого обращения с токенами и длительностью, и большинство чисел ниже взяты из неё.

С первого живого прогона с начала июля по начало сентября наша тендерная система завела 4 452 карточки закупок, 3 890 из них отфильтровала ступень предскоринга (то есть жёсткие правила и дешёвая LLM вместе). В статусе тендера-кандидата побывали 580 карточек закупок, 61 из них жёсткие правила задним числом вернули в отсев, они включены в те же 3 890, а ещё 43 карточки закрыты вручную из других статусов или заведены вручную сразу тендерами-кандидатами, минуя предскоринг. Также 198 отклонил человек на гейте, 270 закрыл человек, как отменённые или просроченные, до решения по существу, 23 стали заявками, 18 ждут решения на 6 сентября, ещё 10 в прочих статусах, от четырёх нынешних кандидатов до одной проигранной. Еще из важного: 75% отказов человека по всей базе имеют код «не наш профиль» (это слабость дешёвой ступени, которую мы держим сознательно, к ней вернусь ниже). К началу сентября журнал разработки насчитывал почти 300 записей, большая их часть - про то, как тендерный конвейер ошибался в проде.

Есть такая традиция - "велосипеды изобретать". Очень часто при интеграциях с другими информационными системами обращаю внимание на то, какие подходы там используются в части управления процессами согласования или другими действиями над рассматриваемым объектом: где-то делают только уведомления ("вам пришёл документ на согласование"), где-то для каждого документа отдельный уникальный тип задач, где-то подключают BPMN, а где-то не делают вообще ничего.

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

Если отбросить числа, идея выглядит просто. Системе доступна большая ёмкость, но для каждого небольшого шага она использует не всё сразу.

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

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

Самая практическая часть: как на реальном примере автоматизировать ввод активов, сканирование и контроль состояния через связку CMDB и VM-системы, как связать серверы с недопустимыми событиями и выстроить патч-менеджмент так, чтобы кнопка “пропатчить все” не привела к катастрофе.

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

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

Из-за этого агентная разработка пока масштабируется странно. У каждого человека появляется всё более сильный персональный заводик, но команда не получает общего производства. Она видит продукт, не видит способ его изготовления — и поэтому не может этот способ измерять, сравнивать, передавать и улучшать. Компания не станет AI‑native, пока эта работа остаётся невидимой и развивается на ощущениях.

Всем привет!
Я порядка 15 лет занимаюсь администрированием СУБД, а в данный момент работаю на должности старшего инженера по базам данных.

За свою карьеру мне довелось попробовать в работе разные системы мониторинга СУБД, но больше всего мне нравился Spotlight for SQL Enterprise. Это, наверное, лучшая система мониторинга, с которой мне доводилось работать.

К сожалению, Quest Software ушел из РФ, и компании, которые вынуждены соблюдать санкционные режимы, больше не могут им пользоваться. В попытках найти близкие альтернативы я понял, что ничего похожего на рынке нет, и понял: вот она, ниша, в которой можно проявить себя и применить весь свой опыт! :=)

Так появился Lumen.

Сначала — об архитектуре.
Lumen имеет аналогичную архитектуру со Spotlight, есть Diagnostic Server который устанавливается на Windows host. В нем настраиваются подключения к целевому серверу. На целевой сервер ничего устанавливать не нужно, необходимо лишь наличие прав на стороне сервера.

Распространённых транспортов у MCP два, а Copilot Studio поддерживает один - Streamable. SSE в документации помечен как deprecated, и после августа 2025 года Copilot Studio его для MCP не поддерживает - сервер на SSE переделывают до всякой настройки. По документации Microsoft у готового сервера три пути подключения, три типа аутентификации и три режима внутри OAuth 2.0, а доступ агента к серверу и его инструментам заодно регулирует политика данных на коннекторы Power Platform, если такая политика в тенанте есть. Разбор построен на двух страницах learn.microsoft.com, сверенных 4 сентября 2026 года: в нём три места, о которых документация молчит, и по одному из них ответа у меня нет.

В этой части мы вернёмся к работе, которую предыдущие главы принимали как готовую: упаковке. Сначала найдём скалярную ловушку в упаковке B, затем используем ZA как машину транспонирования, после этого разберём 128-битный случай для комплексных чисел и правило корректности для общего PACKM_KER. В финале соберём весь цикл одной дугой: от FMOPA до работающей субконфигурации BLIS для Apple SME.

Недавно мне пришлось объяснять племяннику простейшее 2x + 4 = 10. Я уже собирался произнести школьное «переносим четвёрку вправо с противоположным знаком», но внезапно поймал себя на вопросе: а почему она вообще должна менять знак?

Если ребёнок воспринимает = как портал, через который числа проходят и магически меняют свойства, возможно, проблема не в математике, а в способе её объяснения.

Из этого вопроса вырос MathRoots — мой эксперимент с математикой как dependency graph: от ответа можно проваливаться вниз до операций, свойств и совсем фундаментальных понятий, искать root cause ошибки, визуализировать формулы и спрашивать у каждого шага: «Почему я вообще могу это сделать?»

В статье покажу, во что превратилось обычное 2x + 4 = 10, зачем математике debugger, причём тут AST и как всё это в итоге доросло до React, AI и Docker.

Если честно, это один большой кликбейт, и я крайне не рекомендую вам сюда жать.

Во-первых, это очередная статья про DLSS 5. Во-вторых, вы и так знаете, как я заставил его работать на Nintendo Switch OLED!

Всем привет! Решил поделиться с вами опытом написания и проведения ревью аудит‑политики Kubernetes.

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

Недавно я сел перечитать собственный конфиг на ~580 строк — собирал его из нескольких источников, в первую очередь опираясь на Kubernetes Threat Matrix. Хочу поделиться не столько конкретными находками (так как они специфичны для конкретного кластера), сколько принципами и типовыми ловушками, которые всплыли в процессе ревью. Если вы пишете или проводите ревью политики аудита для своего кластера — этот чек‑лист вполне сэкономит время.

Что мы увидим, если посмотрим на монитор разработчика в разгар рабочего дня? Там наверняка будет открыта IDE, Git, таск-трекер, документация, корпоративный мессенджер. И еще какая-нибудь мелочевка — в зависимости от того, что принято в команде.

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

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

В Stack Overflow Developer Survey 2025 разработчиков впервые попросили посчитать, сколько отдельных инструментов они используют в работе. Из 27 378 ответивших 54% назвали шесть и более приложений или платформ. Операционная система и браузер в этот подсчет не входили. Для сайд-проектов картина оказалась несколько другой —  65% из 25 391 разработчика используют пять инструментов или меньше.

Согласитесь, шесть инструментов — не так уж много. Особенно если учесть, что речь, вообще-то, идет про современную разработку.

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

В словарь добавляют 101 ключ — поиск занимает 8 763 наносекунды. Добавляют 102-й — 718.

Ключей стало больше, а времени в 12 раз меньше. Разбираемся, что происходит на 102-й вставке.

На рынке ML-автоматизации сложился заметный перекос: одни и те же вопросы всплывают у клиентов и у интеграторов снова и снова, но ответы на них редко формулируют вслух. Эта статья является попыткой сформулировать их системно.

В материале представлены мои наблюдения и выводы, основанные на практическом опыте работы в B2B white-label и в B2C в формате ИП, подкрепленные свежими исследованиями по теме. Будет полезно тем, кто на стороне заказчика принимает решения об ИИ-автоматизации, и тем, кто такие решения строит.