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

Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes.

Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress.

Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой.

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

Помедитировав немного над этим, я пришёл к интересным эвристикам.

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

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

Например, существует масса формализованных циклов проектирования (PDCA, OODA, DMAIC, 8D и etc.) — по сути, тривиальных мета-алгоритмов; однако каждый шаг этих алгоритмов — это куда более сложная и нетривиальная задача.

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

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

Микросервисы стали стандартом построения масштабируемых и надежных корпоративных систем, особенно для таких классов, как ERP-системы, для которых важны детерминизм, воспроизводимость результатов, контроль и соответствие регуляторным требованиям [1][2][5].

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

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

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

Сокращение бюджета — это почти всегда момент истины для руководителя: будь то руководитель проекта, тимлид, архитектор или ответственный за внутреннюю IT-службу. В такие моменты лучше всего работают прозрачность и честный диалог, а не директивы и «приказы сверху». Меня зовут Александр Якунчев, я руковожу отделом внедрений и развития 1С и пишу статьи для медиа «вАЙТИ». На примере проектной команды IT-интегратора расскажу, как пройти этот сложный период, сохранив клиента, команду и эффективность. 

CI (непрерывная интеграция) ценна только тогда, когда проваливается. Когда она проходит успешно, то становится просто оверхедом: того же результата можно было добиться и без CI.

Что такое Continuous Integration?

Разработка ПО следует по цикличному итеративному паттерну. Разработчики вносят изменения, коммитят их в систему управления версиями, развёртывают их для пользователей и повторяют этот процесс. Этап continuous integration (CI) расположен между коммитами и развёртыванием, это выполнение автоматизированных проверок каждого коммита. Если проверка проходит успешно, мы говорим «CI пройдена», после чего изменение развёртывается. Если проверка проваливается, мы говорим «CI не пройдена», и изменение не развёртывается.

Если вы опытный разработчик, то, возможно, думаете: «Ну это само собой!». Чтобы по-настоящему осознать предназначение CI, нужно посмотреть, что происходит с CI и без неё.

Привет, Хабр! Меня зовут Сергей, я фронтенд-инженер в Банки.ру.

В этой статье расскажу, как Zod помог нам перестать писать валидацию на уровне полей, подружился с React Hook Form и стал единым источником правды о структуре данных.

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

Это классическая проблема: дублирование логики и рассинхрон. Типы в interface поменялись, а валидация осталась прежней (или наоборот). Мы пробовали Yup, но он казался громоздким в связке с TS: типы приходилось выводить вручную или мириться с тем, что схемы выглядят непрозрачно. В какой-то момент стало непонятно: зачем тащить отдельную библиотеку, если проще написать if (typeof x === 'string')?

С переходом на Zod всё стало значительно проще: одна схема одновременно является и валидатором, и источником типа данных.

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

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

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

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

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

Обычно всё начинается с очень простой задачи, которую нужно решить чем быстрее, там лучше. «А можно ли сделать так, чтобы пользователи сами записывались на консультацию через Telegram?» или «кто-то должен отвечать на типовые вопросы клиентов ночью, пока саппорт спит». Как правило, на этом этапе вспоминают о Telegram-ботах, но тут вопросов возникает еще больше. Сколько стоит разработка? Можно ли создать такого бота своими силами? Что для этого нужно? Насколько это сложно? Или вообще, — а что там внутри этих самых Telegram-ботов, кроме команды «/start»?

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

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

Представьте: вы замечаете на запястьях кроссфитеров и популярных подкастеров странный браслет без экрана. Это Whoop. Зачем люди носят устройство, которое не показывает ни время, ни уведомления, а ещё просит ежемесячную плату?

Привет, Хаброжители! Node.js — это технология, которая изменила современный веб. Более 10 миллионов разработчиков по всему миру используют ее для создания быстрых и масштабируемых приложений.

Эта книга поможет вам присоединиться к их числу и превратить знания JavaScript в уверенные навыки бэкенд-разработки.

Вы научитесь создавать надежные, быстрые и масштабируемые приложения, востребованные в таких компаниях, как Amazon, Netfl ix, LinkedIn.

Старт фазы проектирования, проводит водораздел в ЖЦ производства, завершая этап научно-исследовательского периода и символизирует переход к проектной стадии.

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

В следствии выполнения первой фазы были получены следующие результаты:

На днях произошло знаковое событие в мире спидкубинга. Человек впервые собрал кубик Рубика быстрее 3 секунд на соревнованиях WCA. Это произошло 8 февраля на турнире GLS Big Cubes Gdańsk 2026 в Польше. 9-летнему Теодору Зайдеру первому в истории удалась официальная сборка sub-3 секунды кубика 3×3×3. В этой попытке сошлось много факторов: хороший скрамбл, сверхточный lookahead, мгновенное распознавание паттернов, непрерывный поток движений без пауз со скоростью более 10 TPS (поворотов в секунду), автоматическая моторная память на алгоритмы и знание основ ZBLL (продвинутого метода для решения последнего слоя за один алгоритм), а также куб GAN 12 Maglev UV, идеально подходящий для экстремальных скоростей. Всё это позволило Теодору решить кубик за 29 ходов и 2,76 секунды.

Sub-3 в мире спидкубинга ждали. Рекорды последних лет были близки к рубежу трех секунд: 3.05 (Xuanyi Geng, 2025), 3.08 (Yiheng Wang, 2025), 3.13 (Max Park, 2023). Меня же этот рекорд побудил написать статью о том, как проявляются суперспособности компьютера, робота и человека в решении кубик Рубика.

В статье подробно описывается как и в каких условиях принималось решение о внедрении Искусственного интеллекта в инструмент Data Governance. Какие критерии повлияли на выбор технического стека. Какую пользу принесли LLM в продут управления данными.

Привет! Меня зовут Александр Баранов, я аналитик данных в команде поиска Купера. Цель этого рассказа, поделиться наработками в деле оптимизации разметки текстовых данных при помощи большой языковой модели (LLM). Если после прочтения вы захотите что-то добавить или спросить, буду только рад!

TL;DR Роль Agile Coach должна умереть, чтобы переродиться в роль Change Agent (или Organizational Architect). И работать такие спецы должны не "вечно", а проектно - как спецназ внедрения изменений.

Здесь и далее: скрам-мастер и аджайл коуч тождественны.

1. Выделенная роль в команде - это кража ответственности

Постоянно приставленный к команде Agile Coach (или Scrum Master, или Delivery Manager в роли "няньки") - это прямое забирание ответственности у руководителей.

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

Если руководитель не умеет управлять динамикой команды - значит, его надо учить, а не ставить ему "костыль" в виде коуча (ну и спрашивать с него соответственно). Соответственно, большая часть работы Agile Coach -> Change Agent это обучение тем навыкам, которых не хватает руководителям. Скорее всего в больших организациях уже есть T&D-отдел, который и занимается обучением. Наша задача состыковать системно прокачивание самых актуальных навыков.

Добрый день! Меня зовут Кирилл Зиборов, я представляю отдел безопасности распределенных систем Positive Technologies. В этой статье я продолжу рассказывать о том, как мы используем инструменты формальной верификации для предотвращения уязвимостей в различных компонентах блокчейна. Речь пойдет о верификации смарт-контракта BaseToken в Hyperledger Fabric с помощью метода проверки моделей.

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

Привет! Это Кирилл Рупасов, технический директор SOC. В этой статье мои коллеги из К2 Кибербезопасность — Ирина Леонтьева, старший аналитик SOC и Рамис Суляев, сервисный менеджер SOC — расскажут, почему SOC — это не продукт, который решит ваши проблемы, а партнер, с которым нужно работать совместно. И что будет, если к этому не подготовиться.

У LLM есть устойчивый стиль ответов даже без системного промпта. Я построил инструмент, который измеряет этот «характер» через проекции скрытых состояний на 7 контрастных осей (тёплый/холодный, многословный/лаконичный и др.) и протестировал его
на 6 open-weight моделях 7–9B. Главный результат: alignment-тренировка сжимает поведенческое пространство моделей — подавляет оси позиции (уверенность, прямолинейность), сохраняя оси стиля (креативность, многословность). Llama 3.1 8B — самая
ограниченная (4/7 осей в слабой зоне), DeepSeek 7B сохраняет наибольшую независимость осей. Сравнение base vs instruct для 5 организаций подтверждает паттерн. Код и данные открыты.