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

Мониторинг часто воспринимают как «ещё одну панель», на которую нужно иногда поглядывать. Открыть браузер, зайти в дашборд, проверить зелёные кружочки, закрыть. Но что, если сделать его частью вашего повседневного инструментария - как git, как curl, как любимая IDE? Именно для этого мы добавили в PingZen поддержку MCP.

Сегодня я расскажу, как мы превратили наш сервис в MCP-сервер с 126 инструментами, почему выбрали MCP SDK и как вы уже сейчас можете управлять мониторингом из Claude Code, Cursor и других AI-агентов. Без переключения контекста, без лишних движений - только нужные действия там, где вы работаете.

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

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

В статье расскажем, как удалось превратить этот дом в умный с минимальными вмешательствами.

Приходите к нам на WBCE 2026 — выставка и конференция по автоматизации. Отчёты с прошлых выставок.

Привет, Хабр! Меня зовут Марат Мустафин, я ведущий системный архитектор в «Стрим 1С» группы МТС. Мы поддерживаем и развиваем внутреннюю 1С-экосистему для дочерних компаний, обслуживаем около 1000 пользователей и выпускаем релизы раз в неделю. В этом материале расскажу, как мы выработали подход, сочетающий современные практики DevOps (Development & Operations — разработка и эксплуатация/поддержка) со спецификой платформы, а также поделюсь процессами разработки и нашими ключевыми принципами.

«Стрим 1С» появился в группе МТС в 2021 году как продуктовая команда, которая закрывает автоматизацию ключевых внутренних бизнес-процессов дочерних компаний. У нас работают около 50 специалистов: разработчики, аналитики, архитекторы, QA-инженеры, а также Product Owners и CTO. Функции DevOps в основном закрываем силами архитекторов, но иногда привлекаем профильные команды под конкретные задачи. Формально наш «Стрим 1С» состоит из нескольких команд, отвечающих за свои продукты, но об этом расскажу чуть подробнее дальше.

За время существования «Стрим 1С» мы собрали экосистему, которая обеспечивает:

• еженедельные релизы с высоким уровнем качества, автоматизированный путь от разработки до публикации и надежной инфраструктурой с георезервированием;

• разделение ответственности между продуктовыми командами, отлаженные Agile-процессы с регулярными ретроспективами, а также культуру код-ревью (code review — проверка кода другим разработчиком) и коллективной ответственностью за качество;

современный стек мониторинга и наблюдаемости, комплексное автоматизированное тестирование и инфраструктура как код через Jenkins и Gitlab CI.

В этом нам помогли несколько принципов:

• Автоматизация рутины. Мы отслеживали повторяющиеся действия от сборки релизов до развертывания тестовых контуров и старались уменьшить число ручных операций. За счет этого команда тратит больше времени на бизнес-задачи.

• Культура качества. Многоуровневый контроль через код-ревью, автотесты и повторное тестирование помогает держать прод стабильным при высокой скорости изменений.

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

• Распределенная экспертиза. Разделение ответственности с инфраструктурными командами дает возможность каждому уровню делать свою работу профессионально, без распыления и в итоге повышает общую эффективность.

В этом материале я покажу, как мы реализуем эти принципы, как встроены в корпоративные процессы и как развили разработку 1С до полноценного направления.

Всем привет! Меня зовут Шабашев Валерий. Я работаю Python-разработчиком в ТехВилле и параллельно занимаюсь научной деятельностью в аспирантуре, где исследую поведение языковых моделей, концептуальный дрейф и методы адаптации моделей к новым данным.

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

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

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

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

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

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

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

Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен». И за последние годы я ни разу не видел компанию, где бы «зоопарк» был исключением. Это скорее норма.

Предыдущие две статьи сформулировали гипотезу: распределённое сообщество IT-специалистов может координироваться без иерархии, зарплат и венчурного капитала — если протокол взаимодействия спроектирован правильно. Гипотеза красивая. Но красота — не аргумент. Нужна верификация. Здесь — первая попытка её провести: агентная симуляция на 500 независимых прогонов, математические метрики и один неудобный результат, который требует решения.

Внедрили таск-трекер для ускорения — а команда стала тратить 40 минут в день на костыли. Рассказываю, как за полтора года у нас накопилось 11 обходных путей, почему онбординг новичков растянулся до трёх недель и что мы с этим сделали. Внутри — чек-лист «тормозит ли вас ваш инструмент» и пошаговый план действий.

Всем привет!

Недавно мне нужно было нанять людей в команду по созданию системы на Python, Java, Go. Для меня крайне важны соблюдения принципов SOLID, Чистой архитектуры, Чистого кода.

Я придумал задачу, которую спрашиваю на собеседованиях в свою команду. И мне хочется поделится ею с вами.

Надеюсь, она будет вам полезна!

Большинство знают базу: создал схему компоновки, написал запрос, перетащил поля в настройки — получил отчёт. Но СКД умеет гораздо больше! И многие задачи, которые решают кодом в модуле отчёта, на самом деле решаются средствами самой компоновки — проще, надёжнее и с бонусом в виде пользовательской настройки.

Разберём механизм и приёмы, которые экономят время и код.

Это вторая часть нашей реализации MCP на Open WebUI, которая строится для целей портфельной аналитики. В прошлой части мы разобрали интеграционную часть нашего решения: как мы пришли к Open WebUI, как использовали статусы в запросах пользователя, как отображаем результаты (чтобы не словить ошибки о слишком больших чанках), как строим графики в интерфейсе и как работаем с запросами пользователей.

Данная часть будет посвящена реализации самого агента: его общению с инструментами, вызову этих самых инструментов и планированию шагов по их вызовам. В этой статье будет рассмотрен наш путь по реализации данного агента: от наивного агента, которому просто дали пул инструментов и отправили в релиз до разделения агента на планировщик и исполнителя (спойлер: вторая версия стала куда лучше справляться с различными задачами). Отдельно будет затронута возможность различных моделей использовать chain-of-thoughts.

У вас в GitLab несколько проектов с одинаковым CI? Или просто надоела копипаста в пайплайнах? Каждое изменение нужно отразить в 10 местах? Рассказываем, как сократить код на 56 %, убрать дублирование и сделать один CI для всей группы проектов. Шаблоны, матрицы и практика.

Telegram-группа с топиками как мини-CRM: бот для квалификации лидов на Python, деплой на Yandex Cloud Functions за 0 ₽/мес. Код, подводные камни, Lockbox.

Недавно в Амстердаме прошла конференция Vue.js Amsterdam 2026 — ежегодное мероприятие, посвящённое экосистеме Vite и современным инструментам фронтенд-разработки.

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

В этой статье разберём основные анонсы конференции: Vite 8, Vite+, Void Cloud, а также обновления Vue и Nuxt.

В этом материале я расскажу о проекте Universo Platformo, задача которого — охватить весь мир, создать функционал Киберплана для того, чтобы в рамках формата «Общественный КиберГосПлан» объединять цели, планы, задачи и ресурсы отдельных людей и организаций, создать всемирную систему планирования, управления производствами, координировать исполнение и управлять роботизированными процессами. Важнейшая цель всей работы — это всестороннее и максимальное развитие каждого человека, создание условий, чтобы человечество сохранило способность самостоятельно управлять своей жизнью и развитием.

Храбрым разработчикам «ВС: Бухгалтерия», «Plazma ERP+CRM», «Ананас» и других «адинэсок» посвящается.

НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН И (ИЛИ) РАСПРОСТРАНЕН НЕИСПРАВИМЫМ ФАНТАЗЁРОМ, ГЕНЕРАЛЬНЫМ РАЗНОРАБОЧИМ ВЛАДИМИРОМ ЛЕВАДНЫМ, ЛИБО КАСАЕТСЯ ДЕЯТЕЛЬНОСТИ СУМАСШЕДШЕГО МЕЧТАТЕЛЯ, ГЕНЕРАЛЬНОГО РАЗНОРАБОЧЕГО ВЛАДИМИРА ЛЕВАДНОГО.

Автоматизация ответов на часто задаваемые вопросы (FAQ) - актуальная задача в процессах, где важно быстро и качественно взаимодействовать с клиентами и с аудиторией.

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

Что можно сделать, чтобы не терять обращения, продажи и клиентов?
Ответ: Автоматизировать ответы на часто задаваемые вопросы (FAQ).

Автоматизация ответов на часто задаваемые вопросы (FAQ) - один из распространенных способов применения Искусственного Интеллекта в бизнесе.

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

Теперь у клиентов появилась возможность составлять свой вопрос на естественном языке, и система автоматически выдает ответ, основываясь на соответствующей Базе Знаний.

В итоге клиенты получают быстрые и точные ответы на типичные вопросы и переходят к оформлению и оплате.

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

В этой статье я разберу подход, основанный на JWT (JSON Web Tokens), и покажу, как реализовать полноценную авторизацию в FastAPI — одном из самых быстрых и современных фреймворков для Python. Мы пройдём путь от архитектуры приложения до готового кода, который можно использовать в реальных проектах.

Привет,

Время от времени мою светлую голову озаряют "элегантные решения сложнейших задач", которые почему-то никем не были решены до меня (*сарказм*), и сейчас я поделюсь с вами очередной такой киллер идеей на триллион копеек. Я назвал её "NamedBeacon and Proxy".

Собственно, речь о прокси (proxy) и беконах (beacon— «маяк») для обновляемых смартов на Solidity. Все началось с неудовлетворенности реализацией BeaconProxy от OpenZeppelin:

Современные браузеры тихо съедают экосистему JavaScript живьем.

За последние несколько лет основные браузеры выпустили нативные веб-API, которые заменяют удивительно большое количество утилит, которые мы до сих пор устанавливаем по привычке. Тем не менее, многие разработчики продолжают использовать уже ненужные, но привычные библиотеки. Если зависимость всегда работала, она остается в стеке, даже если браузер уже умеет выполнять ту же работу.

Такой подход обходится дороже, чем кажется. Каждый дополнительный пакет увеличивает вес сборки, затраты на обслуживание, частоту обновления версий и риск отказа от проекта в долгосрочной перспективе. Нативные API-интерфейсы стоят пользователям 0 КБ данных, работают глубоко в движке (часто вне основного потока (main thread)) и используют оптимизации, недоступные библиотекам.

[Текст не для публикации: не нашел как Редакции прикрепить сообщение, эта статья написана в рамках Блога "Институт системного программирования им. В.П. Иванникова РАН"]

Если вы только начинаете работать с требованиями, эта статья для вас.

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