https://www.itweek.ru Издание itWeek (до 2018 года — PC Week) на портале и на страницах бумажного номера информирует читателей об актуальных информационных и коммуникационных технологиях, продуктах и решениях и опыте развития цифровой экономики и цифровой трансформации предприятий и организаций всех масштабов и отраслей. Издание рассказывает о важнейших событиях отечественного и мирового рынка ИКТ и анализирует тенденции развития ИКТ-индустрии. https://www.itweek.ru/images/itweek/logo-100x40.gif https://www.itweek.ru https://www.itweek.ru/themes/detail.php?ID=235526 Fri, 11 Sep 2026 16:16:59 +0300 <p><em>Инструменты, основанные на искусственном интеллекте, смещают теневые ИТ из сферы SaaS в сферу кода. Энди Гомбар, ведущий инженер Webflow по обнаружению и реагированию, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как можно проактивно защитить свою облачную инфраструктуру.</em></p> <p>Раньше теневые ИТ были проблемой SaaS. Кто-то из маркетинговой команды регистрировался в инструменте, подключал его к Google Workspace, и первым сигналом было разрешение OAuth, которое вы не авторизовали. Раздражающе. Обнаруживаемо. Ликвидируемо.</p> <p>Эта эпоха закончилась.</p> <p>Новые теневые ИТ не отображаются в ваших журналах OAuth. Они отображаются как работающая в вашей облачной учетной записи инфраструктура, созданная с благими намерениями инженером, который попросил агента ИИ запустить ее в тот же день. Никаких тикетов, никакого ревью, никакого участия команды безопасности. Просто кто-то с хорошей идеей и инструментом, который устранил все препятствия, замедлявшие его работу.</p> <p>Такое поведение вызвано не только существующей неэффективностью. Частично оно связано с реальной работой по обеспечению безопасности.</p> <h3>Проблема с благими намерениями</h3> <p>В классических теневых ИТ чувствовалось присутствие кого-то, сознательно обходящего утвержденную ИТ-инфраструктуру. Команда, которая не хотела ждать закупок. История безопасности, по крайней мере частично, касалась здесь обеспечения соблюдения политик.</p> <p>Теперь все иначе.</p> <p>Инженер, который разрабатывает с помощью вайб-кодинга внутренний инструмент для своей команды, не пытается ничего обойти; он пытается помочь. У него есть доступ к агенту ИИ, который может писать код, генерировать программы Pulumi и развертывать инфраструктуру быстрее, чем любой процесс проверки. И если он не потратил время на размышления о безопасности облачных вычислений, у него нет оснований полагать, что то, что он только что выпустил, представляет собой проблему.</p> <p>Вот что усложняет ситуацию: вы не можете навязать свой способ выйти из нее; вы должны быстро ее предотвратить.</p> <p>Пример того, как выглядит подобная проблема: инженер создает легковесное внутреннее приложение для автоматизации ручной работы своей команды. Он просит ИИ-агента заняться инфраструктурой. Агент выделяет ресурсы в учетной записи AWS команды, открывает необходимые порты и развертывает приложение. Оно работает, и команда в полном восторге. Никто не создает тикет, потому что нечего создавать. Шесть недель спустя ваша CSPM обнаруживает общедоступную конечную точку с избыточно разрешенной IAM-ролью. К тому времени приложение уже достаточно долго работает в продакшене, и латеральное перемещение является реалистичным сценарием, а не теоретическим.</p> <p>Намерение было благим. Результат имеет радиус поражения.</p> <h3>Почему это отличается от разрастания SaaS</h3> <p>Когда теневые ИТ означали несанкционированный SaaS, ваша поверхность обнаружения была определена. Предоставление прав OAuth, сетевой трафик, отчеты о расходах, аномалии SSO. Инструмент существовал вне вашей инфраструктуры. Он был внешним. Вы могли его обнаружить, вы могли его отключить, и ущерб обычно был ограничен.</p> <p>Внутренние инструменты, созданные агентами, находятся внутри вашей инфраструктуры. У них есть IAM-роли. Они могут иметь прямой доступ к производственным данным, внутренним API или конфиденциальным системам. Они выглядят легитимно, потому что были созданы легитимным сотрудником с использованием легитимных инструментов. Нет очевидного признака, который можно было бы обнаружить. Код не заявляет о своей неконтролируемости. Он просто работает.</p> <p>Этот сдвиг заслуживает четкого названия: мы перешли от разрастания SaaS к разрастанию кода. Сценарий обнаружения для одного не подходит для другого.</p> <h3>Базовые требования, которые действительно нужны</h3> <p>Цель здесь не в том, чтобы замедлить работу инженеров. Цель в том, чтобы сделать безопасный путь легким. Базовые требования, к которым следует стремиться, имеют два уровня, и различие между ними имеет значение.</p> <p><strong>Платформенный контроль</strong> — это то, что структурно затрудняет случайное совершение неправильных действий и что вы настраиваете один раз на уровне организации или учетной записи.</p> <p><em>IAM-ограничения по принципу наименьших привилегий.</em> Доступные для командных учетных записей AWS разрешения должны быть ограничены по умолчанию. Инженер не должен иметь возможность создавать общедоступный ресурс с широкими правами доступа, не нарушая защитный механизм. Защитный механизм не останавливает работу. Он предотвращает незаметную отправку худшей версии работы.</p> <p><em>Принудительное использование менеджера секретов.</em> Жестко закодированные учетные данные в приложениях, созданных с помощью вайб-кодинга, — это не гипотетическая ситуация. Это почти неизбежная ситуация, если вы не сделаете правильный путь очевидным. Принудительное использование менеджера секретов на уровне инфраструктуры полностью снимает с отдельного инженера право принятия решения.</p> <p><em>Цели развертывания с использованием VPN.</em> Внутренние инструменты должны по умолчанию размещаться за корпоративным VPN. Если что-то действительно должно быть общедоступным, это должно требовать явного решения, а не случайного значения по умолчанию.</p> <p><strong>Контроль процессов</strong> — это то, что должно происходить на уровне инструмента, прежде чем что-либо будет выпущено.</p> <p><em>Автоматизированная проверка базовых требований.</em> Прежде чем специалист по безопасности начнет проверку, автоматически проверьте код и конфигурацию инфраструктуры на соответствие базовым требованиям. Выявите нарушения, оцените их по степени серьезности и предоставьте инженеру конкретные рекомендации по устранению. Это тот уровень, который может обеспечить навык Claude или аналогичный инструмент. Дальнейшая проверка человеком фокусируется на результатах автоматической проверки, а не начинается с нуля.</p> <p><em>Проверка кода с учетом требований безопасности и эскалацией. </em>Каждый инструмент, разработанный внутри компании и взаимодействующий с производственной инфраструктурой, требует проверки человеком, обладающим опытом в области безопасности, прежде чем он будет выпущен. Для инструментов с низким уровнем риска это может быть коллега-инженер, понимающий масштабы проблемы, которую он проверяет. Для всего, что связано с облачной инфраструктурой, прямым доступом к данным или новыми ролями IAM, проверка эскалируется в формальную проверку безопасности. Тот же контроль, но с разбивкой по степени риска. Ключевой момент заключается в том, что проверяющий должен действительно понимать код. В случае с инструментами, разработанными с использованием вайб-кодинга, автор может не до конца понимать, что он создал. Это делает проверку более важной, а не просто формальной. Это не просто врата качества. Это своего рода «врата понимания».</p> <h3>Защитная сетка</h3> <p>Базовые требования — это профилактика. Обнаружение — это то, что выявляет то, что проскальзывает.</p> <p>Ваша CSPM — это подходящий инструмент для обнаружения неправильных конфигураций в уже существующих системах. Wiz и подобные ему инструменты выявят общедоступную конечную точку, роль с избыточными правами доступа, хранилище без надлежащего контроля доступа.</p> <p>Но CSPM обнаруживает только то, что уже развернуто. Базовые требования и процесс ревью — это то, на что вы рассчитываете в плане предотвращения. Обнаружение — это уровень выявления, а не первая линия защиты.</p> <p>Более сложная задача обнаружения — это знание о существовании чего-либо. Инструмент вайб-кодинга, работающий локально или в командной учетной записи, может не оставлять следов в вашем обычном слое видимости. Нет конвейера развертывания. Нет заявок на изменение. Нет записей в инвентаризацию активов.</p> <p>Вот где начинают иметь значение поведенческие сигналы из вашей облачной телеметрии. Создание ролей IAM вне вашей обычной активности конвейера. Появление новых общедоступных ресурсов без соответствующей записи об изменении. Вызовы API, исходящие с машин разработчиков непосредственно в производственные учетные записи, а не через стандартные инструменты. Ни один из этих сигналов сам по себе не является определяющим. В совокупности они начинают выглядеть как нечто, заслуживающее более пристального внимания.</p> <p>Большинство команд не ищут эти сигналы именно в контексте инструментов, созданных агентами. Именно этот пробел стоит закрыть.</p> <h3>Кодифицированные базовые требования</h3> <p>Документация, хранящаяся в вики, — это базис, который никто не использует, когда это необходимо. Лучший путь — сделать базовые требования доступным в инструментах, которые уже используют инженеры, на этапе разработки.</p> <p>Навык Claude или аналогичный ИИ-нативный инструмент, который проверяет описания архитектуры или сгенерированную инфраструктуру на соответствие вашему конкретному базовому уровню безопасности, полезнее, чем контрольный список в Confluence. Инженер получает конкретную, действенную обратную связь до того, как ее увидит человек-рецензент. Команда безопасности получает первый вариант, уже отфильтрованный по очевидным недостаткам. Проверка становится лучше, потому что она начинается с более полной картины.</p> <p>Ничего из этого не сработает, если инженеры не осведомлены об этом навыке или если отсутствует процесс проверки. Осведомленность сама по себе является уровнем предотвращения. Внедрение обоих аспектов во время адаптации делает безопасный путь видимым, а использование обратной связи от навыка в качестве двойного инструмента обучения тому, почему важна каждая проверка, помогает закрепить знания. Защитный барьер, который не афиширует себя, не является профилактическим.</p> <h3>Вывод</h3> <p>Внутренние инструменты, основанные на вайб-кодинге, никуда не денутся. Трение, которое раньше замедляло работу неуправляемой инфраструктуры, исчезло и не вернется. Вопрос в том, успеет ли ваш базовый уровень безопасности достичь своих целей раньше, чем CSPM.</p> <p>Платформенный контроль делает безопасный путь путем по умолчанию. Контроль процессов гарантирует, что человек, обладающий контекстом безопасности, увидит все до того, как это будет реализовано. Обнаружение дает вам уровень защиты от того, что все равно проскальзывает.</p> <p>Для всего этого не требуется выделенная команда AppSec или SOC. Необходимы четкие базовые требования, инструменты для их обеспечения и инженеры, понимающие, что именно они проверяют. Эту проблему может решить небольшая, хорошо структурированная команда безопасности. Платформенный контроль осуществляется на уровне организации или инженера по безопасности, устанавливается один раз и применяется повсюду. Контроль процессов является распределенным: коллега-инженер, имеющий опыт работы с безопасностью, занимается инструментами с низким уровнем риска, в то время как все, что касается облачной инфраструктуры, прямого доступа к данным или IAM-новшеств, передается на формальную проверку безопасности. Это распределенная ответственность с четким путем эскалации, а не одна команда, проверяющая все.</p> Инструменты, основанные на искусственном интеллекте, смещают теневые ИТ из сферы SaaS в сферу кода. Энди … article https://www.itweek.ru/themes/detail.php?ID=235525 Fri, 11 Sep 2026 12:27:06 +0300 <p>Самые высокие медианные зарплаты программистам в 3 квартале 2026 года предлагали в Москве (211,7 тыс. рублей), Московской области (180 тыс. рублей) и Санкт-Петербурге (158,8 тыс. рублей), выяснили аналитики hh.ru. При этом медианная предлагаемая зарплата у программистов по России в августе составила 152,7 тыс. рублей.</p> <p>В топ-10 регионов России с наиболее высокими предложениями от работодателей также вошли Тульская область (155 тыс. рублей), Свердловская область (139,8 тыс. рублей), Республика Татарстан (133,2 тыс. рублей), Краснодарский край (131,7 тыс. рублей), Новосибирская и Рязанская области (по 130 тыс. рублей), а также Нижегородская область (128,1 тыс. рублей).</p> <p>«Программисты остаются ключевыми специалистами для ИТ-отрасли: с начала года работодатели разместили для них более 49 тыс. вакансий. При этом растет уровень мотивации, которую готовы обеспечить компании: медианная предлагаемая зарплата увеличилась с 150 тыс. рублей в январе 2026 года до 152,7 тыс. рублей в августе. Важно отметить, что опытные специалисты востребованы не только в ИТ-секторе: их также готовы нанимать компании, которые развивают собственные цифровые продукты и инфраструктуру в разных сферах деятельности», — отметила Мария Игнатова, директор по исследованиям hh.ru.</p> <p>Больше всего вакансий для программистов приходится непосредственно на отрасль информационных технологий, системной интеграции и интернета — в 3 квартале работодатели разместили на hh.ru более 4 тыс. предложений с медианной зарплатой 165,8 тыс. рублей. На втором месте по числу вакансий — финансовый сектор (более 1 300 предложений с медианной зарплатой 176,5 тыс. рублей), на третьем месте — розничная торговля (более 600 вакансий с медианной зарплатой 150 тыс. рублей).</p> <p>В топ-5 отраслей также вошли услуги для бизнеса (более 600 вакансий и 185,3 тыс. рублей) и также сфера электроники и приборостроения (более 550 вакансий и 150 тыс. рублей предлагаемой оплаты труда).</p> <p>Топ актуальных вакансий программистов на hh.ru с наибольшей предлагаемой зарплатой:</p> <ol> <li>Senior Android разработчик — до 900 тыс. руб. в месяц;</li> <li>разработчик — от 512 тыс. до 768 тыс. руб. в месяц до вычета налогов;</li> <li>инженер-программист (SDR / ЦОС) — от 487,5 тыс. руб. в месяц до вычета налогов;</li> <li>Backend-разработчик Go — от 450 тыс. руб. в месяц до вычета налогов;</li> <li>ведущий разработчик ПО — от 350 тыс. до 650 тыс. руб. за месяц.</li> </ol> «Рынок разработки стал более избирательным: работодатели по-прежнему конкурируют за сильных middle-, senior- и lead-специалистов, но требования к кандидатам растут, особенно начиная с ролей уровня senior. На этом уровне карьеру определяет уже не только качество кода, но и способность объяснять технические решения, договариваться с командой, понимать продукт и бизнес-контекст. Поэтому для опытных разработчиков участие в профессиональном сообществе и нетворкинг становятся частью профессионального капитала: через окружение приходит обмен экспертизой, рекомендации и карьерные возможности. Мы видим этот интерес и в Сетке: на сентябрь на платформе зарегистрировано больше 40 000 разработчиков — это <nobr>4-я</nobr> по численности роль после менеджмента, продаж и маркетинга. Это показывает, что ИТ-специалисты всё чаще воспринимают профессиональные связи как инструмент роста, а не как что-то второстепенное», — отметила Юлия Ранн, CPO соцсети для нетворкинга «Сетка». Самые высокие медианные зарплаты программистам в 3 квартале 2026 года предлагали в Москве (211,7 тыс … message https://www.itweek.ru/themes/detail.php?ID=235524 Fri, 11 Sep 2026 12:20:15 +0300 <p>По данным Аналитического центра Sledi.ru, за январь—июль 2026 года по Федеральному закону № <nobr>44-ФЗ</nobr> государственные заказчики заключили 44 389 контрактов, включающих программное обеспечение и ИТ-оборудование. Общая стоимость контрактов составила 215,76 млрд рублей. По сравнению с аналогичным периодом прошлого года число контрактов выросло на 7%, а их стоимость — на 40,8%.</p> <p>Годом ранее за тот же период государственные заказчики заключили 41 474 контракта общей стоимостью 153,28 млрд рублей. Почти 70% прироста пришлось на ФНС России и ФКУ «Налог-Сервис»: за семь месяцев 2026 года они заключили контракты на 55,06 млрд рублей против 11,70 млрд рублей годом ранее.</p> <p>Для сравнения: в январе—июле 2025 года объем закупок вырос к 2024 году всего на 2,2%, а количество контрактов сократилось на 7,1%.</p> <p>За январь—июль 2026 года государственные заказчики заключили 13 762 контракта на программное обеспечение — на 11,5% больше, чем годом ранее. За тот же период 2025 года таких контрактов было 12 340. Стоимость позиций ПО с указанной в ЕИС ценой выросла с 65,34 до 85,20 млрд рублей — на 30,4%.</p> <p>Чаще всего закупали лицензии на программное обеспечение — они вошли в 6 075 контрактов. Операционные системы вошли в 5 148 контрактов, разработка ПО для прикладных задач — в 867. Еще 713 контрактов включали прочие оригиналы программного обеспечения, 505 — прикладное ПО, 440 — сетевое ПО.</p> <p>При этом самые массовые категории не формируют основной денежный объем. На 867 контрактов по разработке ПО для прикладных задач пришлось 56,35 млрд рублей — около 66% стоимости позиций ПО. Лицензии на программное обеспечение вошли более чем в 6 тыс. контрактов, но их стоимость составила 10,28 млрд рублей</p> <p>На ИТ-оборудование за январь—июль 2026 года государственные заказчики заключили 31 180 контрактов — на 5,5% больше, чем годом ранее. За тот же период 2025 года таких контрактов было 29 549. Стоимость позиций ИТ-оборудования с указанной в ЕИС ценой выросла с 60,05 до 89,39 млрд рублей — на 48,9%.</p> <p>Одним из главных факторов роста стали крупные закупки Федеральной налоговой службы и ФКУ «Налог-Сервис». За январь—июль 2025 года эти два заказчика заключили контракты на 11,70 млрд рублей, а за тот же период 2026 года — на 55,06 млрд рублей. Общий прирост стоимости контрактов составил 62,48 млрд рублей. Из них 43,36 млрд рублей пришлись на ФНС России и ФКУ «Налог-Сервис» — около 69%.</p> <p>Без учета контрактов ФНС России и ФКУ «Налог-Сервис» общая стоимость контрактов в выборке выросла со 141,58 до 160,70 млрд рублей — на 13,5%. При этом по отдельным направлениям динамика различалась: стоимость позиций ПО увеличилась с 55,83 до 67,63 млрд рублей — на 21,1%, а ИТ-оборудования, напротив, снизилась с 57,99 до 54,10 млрд рублей — на 6,7%.</p> <p>Если рассматривать закупки по регионам регистрации заказчиков в ЕИС, первое место занимает Москва — 130,08 млрд рублей. Далее следуют Московская область — 11,83 млрд рублей и Санкт-Петербург — 8,11 млрд рублей.</p> <p>Артем Баюшкин, генеральный директор Sledi.ru, отметил: «Рост закупок ПО и ИТ-оборудования может быть связан сразу с несколькими процессами. Государственные заказчики продолжают обновлять ИТ-инфраструктуру, возвращаются к отложенным проектам модернизации и развивают существующие информационные системы. Одновременно продолжается переход на отечественные программные и аппаратные решения, который требует не только замены отдельных продуктов, но и их внедрения, интеграции и доработки. Поэтому рост в денежном выражении может отражать прежде всего увеличение масштаба таких проектов, а не просто рост числа закупок».</p> По данным Аналитического центра Sledi.ru, за январь—июль 2026 года по Федеральному закону № 44-ФЗ … message https://www.itweek.ru/themes/detail.php?ID=235523 Fri, 11 Sep 2026 12:18:39 +0300 <p>«Яндекс» выложил в открытый доступ Alice AI Search Pretrain — свою собственную обученную с нуля языковую модель. Благодаря своей архитектуре она способна мгновенно давать емкие ответы и обрабатывать большой поток запросов. «Яндекс» первым выложил в открытый доступ базовую (pretrain) модель, дообученная версия которой генерирует ии-ответы в Поиске. Ее можно найти на платформе Hugging Face.</p> <p>Alice AI Search Pretrain — это компактная языковая модель, которая уже прошла первый этап обучения и имеет обширные знания о мире. Она способна обрабатывать большой объем документов и выдерживать большую нагрузку. А благодаря своей компактности не требует больших вычислительных мощностей. Разработчики и исследователи могут использовать ее в своих проектах и изучать ее архитектуру.</p> <p>Модель имеет гибридную архитектуру, которая до «Яндекса» существовала в основном только в научных исследованиях. Она объединяет две технологии: «Энкодер-декодер» (Encoder-Decoder) и MoE (Mixture of Experts). Первая позволяет давать емкий лаконичный ответ за счет того, что одна часть модели изучает и отбирает информацию, а другая генерирует ответ. Вторая технология ускоряет работу модели и экономит вычислительные мощности. Вместо того, чтобы задействовать всю нейросеть, MoE активирует только ту часть ее «мозга», которая лучше разбирается в теме. Эта модель содержит 35 млрд параметров, но при обработке одного токена (небольшого фрагмента текста) используется лишь около 600 млн — менее 2%.</p> <p>По качеству ответов Alice AI Search Pretrain превосходит компактные языковые модели на задачах по русскому языку. По данным замеров методом слепого тестирования она отвечает лучше Qwen 3.5 2B и 4B и T5 Gemma 2 4B-4B Base. При этом модель также сопоставима по качеству с Qwen 3.5 35B-A3B, которая требует значительно больше вычислительных ресурсов, чем Alice AI Search Pretrain. </p> <p>С июля в Поиске «Яндекса» работает дообученная версия этой модели — Alice AI Search, входящая в семейство генеративных моделей Alice AI. Чтобы Alice AI Search давала емкие и понятные ответы, разработчики собрали пользовательские сигналы и обучили модель на реальных примерах взаимодействия людей с поиском. Ответы модели появляются прямо под поисковой строкой и помогают быстро разобраться в теме. Каждый месяц быстрыми ответами пользуются более 49 миллионов человек. Это самый массовый генеративный продукт «Яндекса», где пользователи чаще всего сталкиваются с искусственным интеллектом.</p> «Яндекс» выложил в открытый доступ Alice AI Search Pretrain — свою собственную обученную с нуля языковую … message https://www.itweek.ru/themes/detail.php?ID=235522 Fri, 11 Sep 2026 12:14:25 +0300 <p>Компания Innostage объявила о выходе версии 1.5.1 решения Innostage TDIR Интеллектуальная автоматизация расследования инцидентов ИБ (далее по тексту — Innostage TDIR), предназначенного для интеллектуальной автоматизации деятельности центров мониторинга и реагирования на инциденты информационной безопасности (SOC).</p> <p>Innostage TDIR — российское on-premise решение класса Agentic SOC. Оно усиливает SIEM/SOAR-системы посредством автономных ИИ-агентов, которые расследуют инциденты, фильтруют ложные срабатывания и проводят историческую корреляцию, помогая аналитикам SOC преобразовать рутинную работу в автономный процесс.</p> <p>В новой версии Innostage TDIR усовершенствован механизм интеллектуальной проверки инцидентов, который сокращает количество ложных срабатываний (AntiFP) и дает рекомендации по реагированию. Поддержка нескольких алгоритмов AntiFP в рамках тестирования гипотез позволяет системе подбирать оптимальный подход к выявлению реальных угроз с учетом специфики конкретной инфраструктуры и повысить точность детектирования.</p> <p>Функциональность автоматического выполнения запросов к SIEM, предназначенных для обогащения контекста инцидента, теперь предусматривает возможность отмены таких действий на этапе анализа по инициативе пользователя. Гибкое управление запросами помогает оптимально расходовать ресурсы.</p> <p>Обновленный отчет об инцидентах информационной безопасности включает четыре ключевых столпа аналитики: вердикт False Positive / True Positive с уровнем достоверности, детальный анализ PowerShell, включая поиск обфускации и подозрительных паттернов, сопоставление с историческими инцидентами, а также обогащение из баз знаний, Threat Intelligence и правила корреляции для всесторонней оценки угроз. Это позволяет специалистам быстро отличать реальные атаки от легитимной активности. </p> <p>Также произведены доработки нескольких сервисных компонентов системы:</p> <ul> <li>скорректирован подход к передаче паролей и проверке подключения для снижения риска учетных данных;</li> <li>добавлено автозаполнение: при создании объектов из баз знаний о целях (Type = ’’Тактика«) и способах атаки (Type = «Техника») наименования и описания теперь заполняются из соответствующего справочника, что сокращает объем ручного ввода и приводит к единообразию описания угроз;</li> <li>оптимизирован процесс выполнения запросов SIEM: реализовано параллельное выполнение без блокировок других ИИ-проверок, благодаря чему система лучше справляется с нагрузкой;</li> <li>скорректирован и ускорен поиск алгоритмических правил: реализован поиск по текстовому значению без учета Markdown-разметки;</li> <li>ко всем сервисам добавлен механизм проверки работоспособности (Healthcheck), который используется в автотестах.</li> </ul> <p>«С момента выхода Innostage TDIR версии 1.0.0 прошло чуть больше месяца. За это время мы получили обратную связь от первых пользователей, что дает нам отличную возможность активно улучшать продукт. Новые доработки связаны, прежде всего, с повышением безопасности, удобства и стабильности работы системы», — прокомментировал Искандер Тиморшин, владелец продукта Innostage TDIR.</p> <p>«Ключевое преимущество Innostage TDIR состоит в том, что с его помощью компании могут легко встраивать в свои системы защиты широкий набор ИИ-агентов: они сортируют оповещения, детально разбирают инциденты, оказывают помощь и принимают первичные меры в принятии решений для устранения угроз. Это позволяет масштабировать процессы кибербезопасности, делегируя рутинные расследования и реагирование искусственному интеллекту», — добавил Никита Радионов, заместитель директора по развитию продуктов Innostage.</p> Компания Innostage объявила о выходе версии 1.5.1 решения Innostage TDIR Интеллектуальная автоматизация расследования … message https://www.itweek.ru/themes/detail.php?ID=235519 Fri, 11 Sep 2026 11:20:46 +0300 <p><em>Сто лет назад электричество начало поступать на заводы и в дома гораздо быстрее, чем кто-либо мог надёжно его распределять или контролировать. Сначала прокладывалась проводка, затем появились автоматические выключатели, правила техники безопасности и точное выставление счетов. В основном это происходило после того, как пожары, отключения электроэнергии и спорные счета вынуждали к этому. Сейчас предприятия сталкиваются с аналогичной проблемой с агентным искусственным интеллектом, и в новом исследовании IDC «</em><em>Crossing</em> <em>the</em> <em>Agent</em> <em>Economy</em><em>’</em><em>s</em> <em>Cost</em> <em>Governance</em> <em>Gap</em><em>» приводятся точные цифры, показывающие, насколько велик этот разрыв, пишет в корпоративном блоге Рик Вилларс, вице-президент группы глобальных исследований </em><em>IDC</em><em>.</em></p> <h3>Сколько агентов уже подключено к бизнесу</h3> <p>Одно только количество внедрений должно разрешить любые затянувшиеся споры о пилотных проектах и ​​производстве. Согласно четвертой волне исследования IDC «Future Enterprise Resiliency and Spending Survey (FERS Survey)», проведенного в июле 2026 г., 95% предприятий по всему миру в настоящее время используют как минимум один финансируемый компанией рабочий процесс с поддержкой агентов в производственной среде, а в среднем в организациях используется около 11 таких процессов в различных функциональных областях. Это не статистика первопроходцев. Это инсталлированная база, требующая управления и расширения, и она наиболее сконцентрирована на ИТ-операциях и разработке ПО (71% организаций), за которыми следуют обслуживание/поддержка клиентов (43%) и цепочки поставок и закупки (36%).</p> <p>Затраты, поддерживающие это растущее присутствие, — это реальные деньги, которые уже сегодня работают, а не погрешность округления, которую нужно будет моделировать позже. Предприятия, имеющие доступ к информации о своих затратах на агентов (большинство имеют такой доступ), сообщают о средних ежемесячных расходах на инференс агентов и связанные с этим услуги оркестрации в размере 117 558 долл., что значительно превышает 1 млн. долл. в год, и оценки IDC по внедрению агентов показывают, что это лишь начало гораздо более долгой истории. По прогнозам, к 2030 г. число активных агентов, используемых организациями, достигнет 2,5 млрд., что почти в 80 раз больше, чем в 2025 г. Эти агенты будут выполнять 459 трлн. действий в год против 48 млрд. сегодня. Ничто не говорит о замедлении темпов. Инновационный потенциал агентного ИИ реален, и предприятия доказали, что могут справиться с первоначальной нагрузкой. Вопрос, который сейчас рассматривает IDC, заключается в том, успевают ли счетчики и механизмы, на которые полагаются предприятия, за этой экспансией и что могут сделать технологические лидеры, чтобы избежать негативных последствий.</p> <p>#IMAGE_235520#</p> <h3>Перерасход средств — это проблема прозрачности, а не дисциплины</h3> <p>Они пока не успевают, и данные точно показывают, где находится разрыв. 67% предприятий за последние 12 месяцев превысили свой бюджет расходов на агентов более чем на 10%, в том числе 24% значительно или чрезвычайно превысили прогноз. Анализ перерасхода средств по степени тяжести показывает реальную картину: 43,1% превысили бюджет умеренно на <nobr>10-25%,</nobr> 18,5% значительно — на <nobr>26-50%,</nobr> а 5,4% — более чем на 50%. Функциональная область, возглавляющая внедрение агентов, — ИТ и разработка ПО — также чаще всего упоминается как область с наибольшим перерасходом средств, что говорит о том, что энтузиазм и бюджетная дисциплина движутся в противоположных направлениях внутри одних и тех же команд.</p> <p>#IMAGE_235521#</p> <p>Последствия не абстрактны. Примерно половина организаций, превысивших бюджет, отложили другие важные ИТ-проекты, чтобы остаться в рамках бюджета, а 43,1% проактивно сократили штат сотрудников для компенсации. Перерасход средств на агентов уже вытесняет другие инвестиции в технологии и, в значительной части случаев, рабочие места. В основе всего этого лежит настоящий парадокс: 61,8% организаций оценивают свою систему управления затратами как «определенную» или «оптимизирующую», однако только 45,4% имеют панели мониторинга, отслеживающие в реальном времени потребление токенов и затраты по рабочим процессам. Область, в которой две трети организаций считают, что их система управления достаточно зрелая, а две трети также не укладываются в бюджет, — это область, где самооценка и результаты перестали соответствовать друг другу.</p> <p>IDC разработала фреймворк для решения именно этой проблемы. Мы предлагаем краткий список решений, которые будут иметь большее значение, чем любое ожидаемое снижение цен на модели:</p> <ol> <li> Назначьте одного ответственного за расходы агентов по каждому рабочему процессу до следующего бюджетного цикла, а не после следующего перерасхода.</li> <li> Замените ежемесячный анализ счетов-фактур на отслеживание затрат в режиме реального времени. Ежемесячный снимок не позволит управлять поверхностью затрат, которая меняется ежечасно.</li> <li> Финансируйте управление затратами как инженерную дисциплину, с выделением инженерного времени, поскольку наиболее эффективные средства контроля (маршрутизация моделей, кэширование промптов, ограничения для циклов агентов) создаются, а не пишутся в служебную записку.</li> <li> Рассмотрите возможность ограничения доли расходов на инференс у отдельного поставщика, как правило, ниже 40%, и держите наготове второй вариант, поскольку цены и условия постоянно меняются от квартала к кварталу.</li> </ol> <h3>Стоимость — это лишь одна нить, а не вся ткань</h3> <p>Было бы ошибкой рассматривать стоимость агентов как отдельную финансовую проблему, и сопутствующий фреймворк IDC «Autonomy on a Leash: A Framework for Agentic AI Governance», объясняет почему. Как отмечает мой коллега Дункан Браун, «организации, которые откладывают внедрение управления до момента развертывания, не избегают затрат. Они лишь откладывают их и увеличивают свои риски, пока ждут».</p> <p>Фреймворк IDC сопоставляет 12 ИТ-областей, включая FinOps и управление затратами, с пятью основными столпами операционного управления: объяснимость и проверяемость, идентификация и контроль доступа, архитектура человеческого контроля, системное управление агентами и непрерывный мониторинг. Стоимость в основном относится к непрерывному мониторингу, но она никогда не остается там одна. Те же самые организации, которые превышают бюджет, также являются теми, где количество нечеловеческих личностей уже превышает количество человеческих, и только 44% организаций внедрили политику идентификации агентов, несмотря на то, что 92% считают это критически важным.</p> <p>Это более глубокий момент, скрытый за цифрами расходов. Перерасход и пробелы в управлении обычно являются одной и той же неудачей, рассматриваемой с разных сторон. Исследование IDC о зрелости организационного управления показывает, что предприятия с реальными моделями подотчетности, документированным надзором и возможностями наблюдаемости в реальном времени к 2029 г. смогут добиться операционной прибыли на 15% выше, чем те, кто гонится только за повышением производительности ИИ. Хорошо построенное управление не является тормозом для описанных выше инноваций. Это распределительный щит, который позволяет предприятию использовать агентный ИИ на полную мощность, не обнаруживая место короткого замыкания только после пожара.</p> <p>Все это не является аргументом в пользу замедления внедрения агентного ИИ в бизнес. Это аргумент в пользу того, чтобы технологические лидеры взяли на себя центральную роль в масштабировании системы, прежде чем это заставят их сделать финансовый, юридический отделы или публичный инцидент.</p> Сто лет назад электричество начало поступать на заводы и в дома гораздо быстрее, чем кто-либо мог надёжно его … article https://www.itweek.ru/themes/detail.php?ID=235516 Fri, 11 Sep 2026 10:25:19 +0300 <p>Крупные телеком-узлы принято считать надёжной опорой рунета — благодаря резервному питанию и географически распределённой инфраструктуре обмена трафиком. Но полуторачасовое отключение на М9 18 августа 2026 года затронуло 467 сетей, а треть из них потеряла почти всю видимость в интернете. Рассмотрим, чем оборачивается физическая концентрация инфраструктуры, когда одна площадка выходит из строя.</p> <p>Вечером 18 августа в одном из районов юго-запада Москвы на полтора часа пропало электричество. Само по себе событие не очень примечательное. Но в зону отключения попала улица Бутлерова, на которой расположен М9 — один из крупнейших телекоммуникационных узлов страны. И локальный инцидент на несколько часов аукнулся по всей стране: хостинг-провайдер Reg.ru зафиксировал сбои в своей инфраструктуре, а совокупный трафик через точку обмена MSK-IX резко просел.</p> <p>М9 давно называют «сердцем рунета». Авария 18 августа дала редкую возможность увидеть на реальных данных, насколько сильно физическая концентрация инфраструктуры на одной площадке может повлиять на сетевую связность.</p> <p>Начнём с масштаба: анализ видимости маршрутов в глобальной таблице BGP — по сути, карты того, какие сети объявляют о своей доступности и через кого, — показывает, что сбой задел 467 автономных систем и 2546 сетевых префиксов. Почти 80% этих сетей зарегистрированы в России, но эффект вышел за пределы страны. Падение прошло в две волны: первая, из 107 сетей, началась около <nobr>20:00–20:10</nobr> по Москве, вторая и основная, из 360 сетей, — в <nobr>20:15–20:23.</nobr> Восстановление в обеих группах стартовало почти синхронно, около 20:55.</p> <p>Дальше — то, что делает эту историю интересной не только для сетевых инженеров. У 165 из 467 пострадавших сетей — больше трети — видимость упала как минимум на 90% анонсируемого адресного пространства. Для них авария на М9 обернулась не помехой, а фактически полным отключением. Показательный пример — сеть НИИЯФ МГУ: один из её префиксов, до инцидента видимый из 481 точки наблюдения в мире, за несколько минут обнулился и оставался недоступным около получаса.</p> <p>А вот у крупнейшего национального оператора «Ростелеком», анонсирующего порядка 1900 префиксов, из строя вышел ровно один — около 0,05% его сети. Чем крупнее и географически распределённее оператор, тем меньше на практике он зависит от одной площадки, даже если формально на ней присутствует.</p> <p>При этом важно не смешивать М9 и MSK-IX. М9 — это физический телекоммуникационный объект, а MSK-IX представляет собой территориально распределенную систему, в которую входит 45 площадок в 10 российских городах. Поэтому глобального отключения не случилось. Это не случайность, а следствие модели: устойчивость российского сегмента интернета на сетевом уровне — одна из его сильных сторон. Показатель зависимости связности рунета от отказа одного, самого значимого оператора, сейчас составляет 4,7% — лучший результат за десять лет наблюдений, которые ведут специалисты Curator. Обеспечивают его хорошая связность и множество независимых операторов: если бы основная масса сетей зависела от одного ключевого игрока, его отказ грозил бы масштабной потерей связности. В распределённой модели компании резервируют каналы у нескольких провайдеров, а при проблеме у одного из них трафик просто перестраивается через другую автономную систему.</p> <p>Но авария на М9 показывает обратную сторону этой же устойчивости. Высокая сетевая распределённость не исключает риски на физическом уровне: даже независимые операторы и резервные каналы связи в какой-то точке могут опираться на одну и ту же физическую инфраструктуру — точки обмена трафиком, дата-центры, узлы связи, кабельные трассы. Если несколько логически независимых маршрутов физически проходят через одну площадку, её отказ способен одновременно задеть сразу несколько, казалось бы, не связанных друг с другом направлений. Именно это произошло 18 августа: для сотен операторов, чьё присутствие было сосредоточено на М9, логическая распределённость сети в момент аварии оказалась абстракцией, их доступность на деле определялась устойчивостью одного здания и его резервного электропитания.</p> <p>И это не сугубо российский феномен. Крупные точки обмена трафиком — от франкфуртского DE-CIX до амстердамского AMS-IX — обрастают тем же сетевым эффектом: чем больше операторов уже подключено, тем выгоднее подключаться следующим, и тем выше физическая концентрация критической инфраструктуры на одной площадке. Авария на М9 — частный, но показательный случай общей закономерности: распределённость в теории не гарантирует распределённости на практике, если экономика толкает десятки независимых сетей полагаться на одни и те же стены, кабели и генераторы.</p> <p>Вывод для операторов и их клиентов весьма практический: помимо осуществления резервирования на уровне маршрутизации необходимо обеспечивать резервирование на уровне физической инфраструктуры. Полтора часа без света в одном районе Москвы напомнили об этом всей стране.</p> <p>#IMAGE_235518#</p> Крупные телеком-узлы принято считать надёжной опорой рунета — благодаря резервному питанию и географически … article Дмитрий Ткачев, гендиректор Curator https://www.itweek.ru/themes/detail.php?ID=235505 Thu, 10 Sep 2026 17:48:52 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как вузы и научные организации регулируют и поддерживают применение искусственного интеллекта сотрудниками.</p> <p>Руководители организаций сферы науки в целом поддерживают применение ИИ сотрудниками для целей, связанных с исследованиями. Положительно к такой практике относятся 49% опрошенных организаций, еще 34% считают технологию полезной для одних исследовательских задач, но не подходящей для других. Нейтральной позиции придерживаются 14% респондентов, негативной — лишь 3%.</p> <p>Практические меры поддержки уже реализуют 65% организаций. В вузах они распространены заметно шире, чем в НИИ: 76% против 49%. Разрыв может быть связан с наличием у вузов собственной образовательной инфраструктуры, облегчающей развертывание обучающих форматов.</p> <p>Наиболее распространены малозатратные образовательные семинары, встречи и мастер-классы: их проводят 48% организаций. Почти четверть (23%) реализуют более системные форматы — долгосрочные программы ДПО и повышения квалификации.</p> <p>Разрабатывают собственные ИИ-модели для научных исследований 23% организаций. Однако эту деятельность следует рассматривать прежде всего как направление исследований и разработок и лишь косвенно — как меру развития сотрудников.</p> <p>Финансовая и ресурсная поддержка встречается заметно реже. Внутренние гранты на исследования с использованием ИИ выделяют 10% организаций. Междисциплинарные команды, объединяющие специалистов по ИИ и исследователей-предметников, поддерживают 6%.</p> <p>Подписки на ИИ-сервисы и доступ к внешним вычислительным мощностям оплачивают лишь единичные организации — хотя сами ученые относят именно эти меры к наиболее востребованным.</p> <p>Формализация политики заметно отстает от практики. Внутренние документы, регулирующие работу с ИИ (регламенты, положения, концепции и др.), утвердили лишь 60 участников опроса (14%); из них только 35 включили в эти документы положения об использовании ИИ непосредственно в научных исследованиях.</p> <p>Результаты опроса ИСИЭЗ НИУ ВШЭ показали, что руководители вузов и НИИ в целом одобряют использование ИИ сотрудниками в научных исследованиях, а две трети организаций уже реализуют конкретные меры поддержки. При этом практическая поддержка опережает нормативное оформление и чаще всего строится по принципу наименьших затрат. Переход к системному применению ИИ в российской науке требует не только стимулирования со стороны государства, но и развития внутренних механизмов на уровне организаций.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как вузы и научные организации … message https://www.itweek.ru/themes/detail.php?ID=235504 Thu, 10 Sep 2026 17:44:59 +0300 <p>Сбер представил GigaChat 3.5 Reasoning — новую флагманскую мультимодальную нейросеть с режимом рассуждений. Она не спешит сразу отвечать на сложный вопрос: сначала разбирает задачу на этапы, определяет план решения, при необходимости обращается к поиску и другим инструментам, ищет ошибки в своих промежуточных результатах и только после этого формирует ответ. GigaChat 3.5 Reasoning — быстрая и экономная модель: она решает задачи с меньшими ресурсами, существенно экономя токены на рассуждение в сравнении с ведущими открытыми нейросетями.</p> <p>Рассуждения особенно полезны в задачах, где недостаточно одного действия или простого поиска информации. Например, модель может найти противоречия между пунктами договора, провести финансовые расчёты или разобраться в сложной ошибке в коде. Флагманская модель уже доступна всем пользователям ГигаЧата, а разработчикам — бесплатно по лицензии MIT для интеграции в свои продукты. Модель станет доступна бизнесу по API в ближайшее время. </p> <p>Антон Фролов, старший вице-президент, руководитель блока «Развитие генеративного ИИ» Сбербанка, отметил: «Сегодня от ИИ ждут не просто быстрого ответа, а способности разобраться в сложной задаче. Теперь GigaChat способен самостоятельно разложить задачу на этапы, понять, каких данных не хватает, проверить промежуточные выводы и при необходимости изменить ход решения. Такой подход особенно важен для агентных сценариев, программирования, аналитики — везде, где результат зависит от целой последовательности решений. Это важный шаг к ИИ, который способен самостоятельно выстраивать путь к результату, действовать проактивно и взаимодействовать с другими сервисами. GigaChat — единственная российская модель с режимом рассуждений».</p> <p>Пользователь может сам определить, когда требуется рассуждение и включить режим отдельной кнопкой. На простой вопрос модель отвечает сразу, а для сложной задачи может использовать десятки тысяч токенов на поиск решения. Новая версия лучше справляется с написанием кода и агентными сценариями, в которых необходимо последовательно выполнить несколько действий. Например, при организации поездки модель может уточнить недостающие параметры, подобрать рейс и отель, проверить, укладывается ли маршрут в бюджет, а при обнаружении противоречия — перестроить план.</p> <p>Благодаря поддержке рассуждений качество GigaChat выросло почти по всем замерам, наиболее заметный прогресс — в агентских задачах, работе с функциями и инструментами, программировании и задачах со сложной логикой. По ключевым направлениям — следованию сложным инструкциям, планированию и написанию кода — GigaChat 3.5 Ultra Reasoning вплотную приблизился к лучшим мировым моделям. Например, в бенчмарке IFBench результат вырос с 44 до 77 баллов, на Natural Plan — с 64 до 80, на Live Code Bench v6 — с 56 до 85. Это заметный рост по сравнению с версией без режима рассуждений. </p> <p>GigaChat 3.5 Reasoning — экономная модель: на рассуждения она тратит существенно меньше токенов, чем ведущие открытые модели при сопоставимом качестве ответов. Например, на решение математических задач она тратит в среднем на 37% меньше токенов, чем DeepSeek V4 Flash Preview.</p> <p>Рассуждающая модель будет наиболее полезна в таких сферах, как:</p> <ul> <li>финансы и банкинг — прогнозирование сценариев, проверка сделок на соответствие нормативным требованиям;</li> <li>юриспруденция — поиск противоречий в договорах, проверка документов на соответствие регламенту или прецедентам;</li> <li>разработка ПО — поиск и исправление багов, выбор архитектуры с учётом скорости, цены и надёжности;</li> <li>логистика и планирование — построение маршрутов и расписаний с учётом сроков, бюджета и доступных ресурсов;</li> <li>образование — пошаговый разбор задач по математике, физике и программированию с проверкой каждого шага;</li> <li>наука и аналитика данных — анализ данных в несколько этапов: расчёты и проверка гипотез;</li> <li>поддержка клиентов — уточнение деталей у клиента и проверка данных в разных системах перед ответом.</li> </ul> <p>Нейросети без режима рассуждения на сложных задачах модель могут давать быстрый, но неполный ответ — просто не размышляя над ними. Новую модель целенаправленно обучили рассуждать, взял за основу базовую GigaChat 3.5 Ultra. Для обучения модель решала математические и кодовые задачи разными способами, раскладывая их на последовательные шаги. Автоматическая проверка определяла, какой вариант рассуждения привёл к правильному ответу, и закрепляла именно такие пути решения. Так она научилась не только выстраивать последовательность действий, но и самостоятельно решать, когда обратиться к внешнему инструменту или пересмотреть предыдущий шаг.</p> <p>GigaChat 3.5 Reasoning использует собственную архитектуру с технологией линейного внимания. Она помогает эффективнее работать с длинным контекстом: вместо того, чтобы повторного сопоставлять каждый новый запрос со всем предыдущим текстом модель запоминает его ключевое содержание и дополняет его по мере обработки информации.</p> Сбер представил GigaChat 3.5 Reasoning — новую флагманскую мультимодальную нейросеть с режимом рассуждений. Она … message https://www.itweek.ru/themes/detail.php?ID=235501 Thu, 10 Sep 2026 00:00:00 +0300 <p><em>На протяжении десятилетий критически важные приложения накапливали бизнес-правила, интеграции, обходные пути и зависимости быстрее, чем организации успевали их документировать, пишет в корпоративном блоге Бишваджит Махапатра, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Документация неполна, первоначальные разработчики ушли, а специалисты по приложениям выходят на пенсию, унося с собой свои критически важные институциональные знания. В результате возникает бизнес-проблема, замаскированная под технологическую. Команды по модернизации сталкиваются со скрытыми зависимостями, неожиданными требованиями и дорогостоящими переделками, потому что они не до конца понимают системы, которые пытаются изменить.</p> <p>Но прежде чем решать, что переписать, рефакторизовать, заменить или вывести из эксплуатации, CIO должны сначала получить ответ ответить на более фундаментальный вопрос: как на самом деле работает приложение?</p> <p>Искусственный интеллект меняет экономику ответа на этот вопрос. То, что раньше требовало месяцев ручного поиска, теперь можно ускорить с помощью анализа, поддерживаемого ИИ. Мне бы хотелось представить эту возможность как более глубокие знания, а не как более быстрое документирование, и что с более глубокими знаниями приходят более эффективные решения по модернизации.</p> <h3>ИИ раскрывает поведение, но не намерения</h3> <p>ИИ может анализировать исходный код, документацию, API, конфигурацию, операционную телеметрию, инциденты и историю изменений гораздо быстрее, чем ручные методы обнаружения. Все чаще платформы обнаружения организуют эти данные в графы знаний, которые связывают приложения, данные, сервисы, интеграции и бизнес-правила в рамках всей инфраструктуры.</p> <p>Такое взаимосвязанное представление помогает командам выявлять скрытые зависимости, оценивать риски интеграции, обнаруживать дублирующуюся логику и понимать, как приложения фактически ведут себя до начала модернизации.</p> <p>Но поведение — это не намерение. Правило, найденное в коде, может представлять собой допустимое бизнес-требование, устаревшую политику, обходной путь для устаревшей системы или дефект, который оставался незамеченным годами. Платформы обнаружения могут идентифицировать правило. Они не могут определить, отвечает ли оно будущему состоянию приложения.</p> <h3>Модернизация требует подтверждения того, что обнаружено</h3> <p>В большинстве систем недостающий контекст находится у людей, которые управляют системой. Они знают, какие правила отражают нормативные обязательства, какие поддерживают законные бизнес-исключения, а какие существуют просто потому, что их никто не удалил. Граф может идентифицировать правило. Только люди могут объяснить, почему это существует и соответствует ли это будущему состоянию приложения.</p> <p>Таким образом, модернизация требует двух форм обнаружения, но большинство программ финансируют только одну. Автоматизированная часть собирает, анализирует и отображает ресурсы приложений. Человеческая часть проверяет бизнес-цели посредством структурированных интервью с пользователями, операторами и владельцами бизнеса, а затем записывает эти решения как подтвержденные правила. Демонстрации поставщиков сосредоточены на первой половине. Успешные программы модернизации вкладывают равные средства и в первую, и во вторую.</p> <p>Это создает новое ограничение на реализацию. Поскольку ИИ сокращает циклы разработки и проверки, доступ к бизнес-экспертам становится узким местом. Команды обнаружения могут выявлять правила за считанные минуты, но проверка этих правил по-прежнему зависит от людей, которые их понимают. Организации, в которых команды модернизации дистанцированы от заинтересованных сторон бизнеса, могут обнаружить, что задержка принятия решений заменяет техническую сложность в качестве основного ограничения на реализацию.</p> <h3>Пусть ИИ реализует архитектуру, а не изобретает ее</h3> <p>Понимание текущего приложения — это половина задачи. Без архитектурного руководства ИИ будет переписывать код, сохраняя при этом тесные взаимосвязи, устаревшие шаблоны интеграции и накопленный долг. В результате получается работающий на устаревшей архитектуре современный код, который внедряется быстрее, чем когда-либо.</p> <p>Модернизация успешна, когда понимание текущего состояния сочетается с намерениями достижения целевого состояния. Доменные модели, ограниченные контексты, утвержденные шаблоны интеграции, средства контроля безопасности и архитектурные стандарты обеспечивают ограничения, необходимые ИИ для эффективной работы. ИИ может внедрять архитектурные решения в масштабе. Он не должен их принимать.</p> <p>Последовательность проста. Проверенные бизнес-правила определяют доменные модели. Доменные модели формируют архитектурные шаблоны. Архитектурные шаблоны становятся инженерными шаблонами. ИИ генерирует и рефакторит в этих рамках, а автоматизированное тестирование, проверка безопасности, проверка соответствия архитектуры и человеческий анализ подтверждают, что эта работа улучшает приложение, а не воспроизводит его.</p> <p>Организации, которые больше всего выиграют от модернизации с помощью ИИ, будут не теми, кто быстрее всего генерирует код. Это будут те, кто сохранит институциональные знания до того, как они исчезнут, подтвердит, какие бизнес-правила все еще важны, и целенаправленно спроектирует архитектуру, которую они хотят использовать в будущем. ИИ может ускорить каждое из этих действий. Он не может решить, какие части прошлого заслуживают места в будущем.</p> На протяжении десятилетий критически важные приложения накапливали бизнес-правила, интеграции, обходные пути … article https://www.itweek.ru/themes/detail.php?ID=235499 Thu, 10 Sep 2026 00:00:00 +0300 <p><em>Заказать DDoS-атаку сегодня дешевле чашки кофе. Злоумышленники тратят от 1</em><em> рубля за 1 Мбит/с — это в тысячи раз дешевле, чем 20 лет назад. Обсудим, что с этим делать.</em></p> <h3>DDoS перестал быть угрозой только для крупных компаний</h3> <p>Еще несколько лет назад DDoS-атаки ассоциировались прежде всего с банками, государственными сервисами, интернет-магазинами и крупными медиа. Сегодня ситуация изменилась. Целью атаки может стать практически любой сайт независимо от размера бизнеса или отрасли.</p> <p>По данным сервиса Statonline.ru, более 90% ресурсов Рунета размещены на виртуальном хостинге. И каждый из них потенциально может стать целью атаки. Одна из причин — изменение самого характера атак. Они стали «ковровыми»: злоумышленники бьют не по одному сайту, а по тысячам одновременно. И число таких атак в прошлом году <a href="https://companies.rbc.ru/news/FcIZ5wgrOW/kod-bezopasnosti-predupredil-o-roste-mnogovektornyih-ddos-atak/">выросло</a> на 83%.</p> <p>Одна из причин — изменение экономики киберугроз. По оценкам участников рынка, стоимость организации DDoS-атак за последние два десятилетия снизилась примерно в тысячу раз. Сегодня такие услуги продаются по модели массового сервиса: они доступны широкому кругу заказчиков и не требуют высокой технической квалификации.</p> <p>Одновременно меняется характер самих атак. Всё чаще злоумышленники распределяют трафик сразу на тысячи или десятки тысяч ресурсов. В результате выбор конкретной жертвы становится менее важным, а риск столкнуться с атакой возникает практически у любого владельца сайта.</p> <p>Для бизнеса это означает изменение подхода к информационной безопасности. Вопрос уже не в том, произойдет ли атака, а в том, насколько инфраструктура готова сохранить работоспособность сервисов в случае инцидента.</p> <h3>Почему традиционная модель защиты теряет эффективность</h3> <p>На протяжении многих лет защита от DDoS строилась по простой схеме: компания размещала сайт, а при необходимости подключала отдельный сервис фильтрации трафика.</p> <p>Такой подход был оправдан, пока атаки оставались относительно редкими и были нацелены преимущественно на крупные ресурсы. Сегодня он всё чаще сталкивается с ограничениями.</p> <ul> <li><strong>Первая проблема — цена. </strong>Профессиональные сервисы защиты от DDoS-атак могут стоить десятки и даже сотни тысяч рублей в год. Для крупных компаний такие расходы оправданы, однако для большинства сайтов на виртуальном хостинге стоимость защиты нередко оказывается выше стоимости самой инфраструктуры, которую она должна защищать.</li> <li><strong>Вторая проблема — архитектура.</strong> Внешние сервисы требуют дополнительной интеграции. Владельцам сайтов приходится менять DNS-настройки, корректировать сетевую архитектуру и передавать часть управления сторонним поставщикам услуг.</li> <li><strong>Третья проблема — сами атаки становятся сложнее.</strong> Всё чаще злоумышленники работают на уровне приложений (L7), имитируя действия обычных пользователей. Такой трафик значительно сложнее отличить от легитимного, поэтому традиционные механизмы фильтрации оказываются менее эффективными.</li> </ul> <p>Показательный пример — ботнет Kimwolf. В марте 2026 года он <a href="https://www.gazeta.ru/tech/news/2026/03/18/28080523.shtml?utm_auth=false">объединил</a> более 4 млн. зараженных устройств по всему миру и генерировал до 700 тыс. запросов в секунду. На Россию пришлось 6,7% устройств, участвовавших в атаках.</p> <h3>Безопасность становится частью инфраструктуры</h3> <p>Подобные изменения уже происходили в других сегментах цифровой инфраструктуры.</p> <p>Когда-то SSL/TLS-сертификаты были дополнительной услугой. Резервное копирование также подключалось отдельно. То же можно сказать о системах мониторинга, защите электронной почты и ряде других сервисов. Со временем рынок пришел к выводу, что некоторые функции настолько важны для устойчивой работы цифровых ресурсов, что должны быть встроены в инфраструктуру по умолчанию.</p> <p>Похожий процесс сегодня происходит и с защитой от DDoS-атак.</p> <p>Традиционная модель предполагает, что владелец сайта сначала запускает ресурс, а затем при необходимости подключает внешние средства защиты. Такой подход работал, пока атаки оставались относительно редким явлением и касались преимущественно крупных компаний. Однако в условиях, когда под угрозой может оказаться практически любой сайт, эта модель начинает терять эффективность.</p> <p>Во многом это связано с экономикой самой защиты. Внешние сервисы фильтрации требуют отдельного подключения, настройки и сопровождения. Для многих владельцев сайтов стоимость таких решений оказывается сопоставимой со стоимостью самой инфраструктуры. Кроме того, подключение внешней защиты часто связано с изменением DNS-настроек и IP-адресов. Для фильтрации HTTPS-трафика владельцу сайта нередко приходится передавать стороннему провайдеру SSL/TLS-сертификат и соответствующий закрытый ключ либо предоставлять возможность выпустить новый сертификат для домена. В результате критически важные элементы криптографической защиты оказываются за пределами инфраструктуры владельца ресурса.</p> <p>Поэтому рынок постепенно движется к другому подходу — переносу защитных механизмов непосредственно на уровень хостинговой платформы. В этом случае фильтрация вредоносного трафика становится частью инфраструктуры, а не отдельной надстройкой над ней.</p> <p>Для владельцев сайтов это означает несколько важных изменений:</p> <ul> <li> <strong>Защита начинает масштабироваться вместе с платформой. </strong>Один инфраструктурный контур может одновременно обеспечивать безопасность сотен тысяч сайтов без необходимости подключать отдельные сервисы для каждого ресурса.</li> <li><strong>Снижается сложность эксплуатации. </strong>Владельцам сайтов больше не нужно менять DNS-настройки, перестраивать сетевую архитектуру или разбираться в особенностях интеграции различных решений безопасности.</li> <li><strong>Упрощается экономика защиты.</strong> Безопасность перестает быть отдельной статьей расходов и становится частью базовой инфраструктурной услуги.</li> <li><strong>Повышается эффективность против современных атак. </strong>Поскольку защита встроена непосредственно в платформу, она может анализировать не только источник трафика, но и его поведение. Это особенно важно для противодействия атакам на уровне приложений (L7), которые имитируют действия обычных пользователей и всё чаще обходят традиционные механизмы фильтрации.</li> </ul> <p>По сути, рынок движется от модели «защита как отдельная услуга» к модели «защита как свойство инфраструктуры». Так же как сегодня никто не рассматривает резервное копирование или шифрование соединений в качестве дополнительной опции, встроенная защита от DDoS постепенно становится базовым требованием к платформам размещения сайтов.</p> <h3>Как меняются требования бизнеса к хостингу</h3> <p>Для компаний это означает пересмотр критериев выбора площадки для размещения сайтов.</p> <p>Если раньше основное внимание уделяли стоимости ресурсов, объему дискового пространства или производительности серверов, то сегодня всё большее значение приобретают устойчивость платформы и встроенные механизмы безопасности.</p> <p>Для многих компаний сайт стал не просто корпоративной витриной, а частью бизнес-процессов: каналом продаж, коммуникации с клиентами или основой предоставления цифровых услуг. Даже кратковременная недоступность напрямую влияет на выручку, клиентский опыт и репутацию.</p> <p>Поэтому бизнес всё чаще оценивает не отдельные инструменты защиты, а способность самой платформы обеспечивать непрерывность работы сервисов.</p> <p>Особенно заметен этот тренд среди небольшого бизнеса, где редко существуют собственные команды информационной безопасности и наиболее востребованы решения, в которых критически важные функции уже реализованы на уровне инфраструктуры.</p> <p>#IMAGE_235500#</p> Заказать DDoS-атаку сегодня дешевле чашки кофе. Злоумышленники тратят от 1 рубля за 1 Мбит/с — это … article Валентин Бостанов, руководитель направления хостинга “Руцентра” https://www.itweek.ru/themes/detail.php?ID=235497 Thu, 10 Sep 2026 00:00:00 +0300 <p>Еще несколько лет назад Confluence казался для многих компаний вполне рабочим и привычным решением. Даже после ухода Atlassian с российского рынка в 2022 году часть бизнеса продолжала использовать систему в закрытом контуре, откладывая вопрос замены. Но теперь этот сценарий подходит к завершению: on-prem-формат сворачивается, новые лицензии перестают продаваться, а привычная модель работы с Confluence становится все менее устойчивой.</p> <p>Для российских компаний это сигнал, что миграцию больше нельзя откладывать. Перейти в зарубежное облако большинству организаций мешают и требования законодательства, и вопросы безопасности, и общая зависимость от внешней инфраструктуры. Поэтому разговор сейчас идет не о том, «нужно ли менять Confluence», а о том, как сделать это спокойно, без потерь и с пользой для бизнеса.</p> <p>Уже в ближайшие годы возникнут ограничения по расширению лицензий и подключению новых пользователей. А следом наступит и полное завершение поддержки on-prem-формата. В этот момент система станет не просто неудобной, а потенциально опасной: без обновлений, без развития и с растущими рисками для безопасности.</p> <h3>Почему искать замену нужно уже сейчас</h3> <p>Любая миграция — это полноценный проект. Чем больше в компании материалов, подразделений и пользователей, которые работают с Confluence, тем выше сложность такого проекта. Если затянуть с переходом, высоки риски того, что придется все делать в спешке: разрабатывать конфигурацию нового решения, проверять функциональные требования, переносить данные. Это приводит к потерям, недовольству пользователей и лишним финансовым затратам.</p> <p>Сейчас у бизнеса есть редкая возможность пройти этот путь без спешки: спокойно сформулировать требования, сравнить варианты и выбрать платформу, которая не только заменит Confluence, но и даст запас для дальнейшего развития.</p> <h3>Как не попасть в ловушку при поиска альтернатив Confluence</h3> <p>Чаще всего компании пытаются найти максимально похожий инструмент, чтобы сохранить привычные сценарии работы с системой. Однако это не всегда лучшее решение. Confluence — платформа, призванная решать задачи, связанные хранением и управлением данными, но не все ее механики хороши. И если искать полную кальку системы, компания рискует сузить выбор и потратить слишком много сил на копирование старой логики там, где можно было бы построить более удобную и современную модель.</p> <p>Поэтому при выборе замены лучше смотреть не на то, насколько новая система похожа на Confluence, а на то, какие бизнес-задачи она закрывает. Важно понять, как в компании хранится информация, кто и как ею пользуется, где нужна жесткая структура, а где — гибкость, и какие сценарии уже сейчас не покрываются текущим решением.</p> <h3>Как выстроить миграцию</h3> <p>Прежде всего, не стоит воспринимать миграцию как простую замену одной системы на другую. Это хороший повод пересмотреть, как компания вообще работает со знаниями: что действительно нужно переносить, какие сценарии стоит сохранить, а от каких можно отказаться.</p> <p>Ориентироваться лучше не на попытку воспроизвести Confluence один в один, а на реальные бизнес-задачи. Важно понимать, какие процессы система поддерживает сейчас, что понадобится компании в будущем и не пришло ли время собрать разрозненные инструменты в единую платформу.</p> <p>Отдельное внимание стоит уделить выбору решения. Здесь полезно сравнивать не абстрактные функции, а то, как платформа закрывает ваши конкретные сценарии работы. Если в Confluence накоплен большой объем данных, обязательно проверьте наличие мигратора у новой платформы. Для крупного бизнеса также критичны устойчивость системы, ее масштабируемость и способность выдерживать высокую нагрузку.</p> <p>Не менее важен и процесс запуска. Если бизнес крупный, информации и сценариев работы много, начинать стоит с пилотного проекта или проводить запуск постепенно: это даст возможность увидеть слабые места, собрать обратную связь, сформировать группу экспертов по работе с решением.</p> <p>Еще один важный момент — обновление контента. Миграция почти всегда показывает, что значительная часть старых материалов уже неактуальна. Перенос — удобный момент, чтобы избавиться от лишнего, пересмотреть структуру и не тащить в новую систему цифровой балласт.</p> <p>Наконец, стоит заранее решить, что делать с текущей структурой Confluence. Если она логична и удобна, ее можно сохранить в новой системе. Если же пространство со временем превратилось в набор разрозненных блоков, миграция дает шанс собрать все в единый корпоративный портал и сделать работу с информацией более прозрачной и управляемой.</p> <p>Миграцию с Confluence стоит воспринимать не как вынужденную замену решения, а как возможность пересобрать подход к управлению знаниями. Если сделать это вдумчиво, компания получит не просто новую платформу, а более зрелую среду для хранения, поиска, обновления и использования информации.</p> <p>#IMAGE_235498#</p> Еще несколько лет назад Confluence казался для многих компаний вполне рабочим и привычным решением. Даже после ухода … article Дмитрий Лактионов, руководитель продуктового направления компании BSS https://www.itweek.ru/themes/detail.php?ID=235503 Wed, 09 Sep 2026 14:11:06 +0300 <p>Компания Security Vision представила очередное обновление платформ. Релиз расширяет возможности управления хранением и доступом к событиям, автоматизирует обслуживание базы данных, упрощает изменение типов событий и развивает сценарии работы с аналитическими виджетами и настройками Платформы.</p> <p>В Платформе появилась настройка горячего и холодного хранения событий. Для типов событий можно задать период нахождения в горячем хранилище, срок хранения в холодном и последующее удаление. Это позволяет переносить архивные события на более медленные диски и гибко управлять сроками их хранения.</p> <p>Доступ к событиям и алертам теперь учитывает организацию пользователя. События и алерты, для которых указана организация, доступны в соответствии с организационной принадлежностью пользователя. Таким образом, механизм Multitenancy распространяется на данные событий и алертов.</p> <p>Добавлены системные настройки для автоматического обслуживания БД Платформы: выполнение VACUUM, перестроение индексов и установка необходимых значений ключевых параметров производительности. Операции обслуживания можно выполнять по настроенному расписанию.</p> <p>В форме ввода свойства типа «Файл» появилась настройка, запрещающая загрузку исполняемых файлов. Для многострочного свойства типа «Строка» с автоматической шириной предусмотрено значение «Не задано», которое возвращает поле к ширине на весь блок карточки. Для форм ввода и вывода свойств также добавлена подсветка синтаксиса кода.</p> <p>Состав свойств типа события теперь можно изменять без реиндексации хранилища: добавлять новые свойства и удалять существующие. Это упрощает изменение структуры типов событий при развитии модели данных.</p> <p>Обновлён интерфейс раздела лицензирования и добавлена отдельная страница с информацией о лицензии. Если лицензия отсутствует или срок её действия завершён, соответствующая главная страница теперь отображается ещё до входа в Платформу.</p> <p>В виджетах добавлены действия, по выполнению которых открываются представления типа «Ссылка на внутренний URL». Также реализована возможность группировать объекты в кластеры по заданным условиям на базе постоянных и динамических значений: входных параметров, переменных и результатов блока.</p> Компания Security Vision представила очередное обновление платформ. Релиз расширяет возможности управления хранением … message https://www.itweek.ru/themes/detail.php?ID=235502 Wed, 09 Sep 2026 14:10:06 +0300 <p>Сфера информационных технологий в 2025 году стала самой атакуемой отраслью в стране — на нее пришлось 29% зафиксированных киберинцидентов. При этом нередко злоумышленники рассматривают ИТ-компании как точку входа в инфраструктуру конечной цели. Далее по числу атак следуют финансы и страхование (17%), ритейл и торговля (12%), здравоохранение и транспортно-логистический сектор (по 8%).</p> <p>Такие данные приведены в исследовании «От реагирования к предотвращению: инциденты 2025», подготовленном экспертами отдела реагирования и цифровой криминалистики Angara MTDR. В основе исследования лежат десятки успешных расследованных кейсов, каждый из которых привнес уникальный контекст, будь то финансовый сектор, промышленность, ретейл или отдельные государственные структуры. </p> <p>Что касается мотивации атакующих, наибольшая доля расследованных компанией инцидентов пришлась на атаки с целью шпионажа (40%), еще 25% — на хактивизм, и 15% на классическую финансовую мотивацию. В 20% случаев точно установить мотивацию атакующих не удалось. Существенную часть инцидентов также составили кампании, которые можно отнести к APT-группировкам. Их организаторы заинтересованы не только в немедленной выгоде, но и в длительном скрытном присутствии в инфраструктуре жертвы.</p> <p>Как отмечают исследователи, значительные изменения за прошлый год претерпел хактивизм. Если раньше в эту категорию, как правило, попадали группировки, ориентированные на публичный эффект и шум, то в 2025 году значительная часть подобных атак была связана с нанесением российским организациям максимального ущерба.</p> <p>Вместе с этим усложнился и сам ландшафт киберпреступности. С одной стороны, появились новые кластеры активности (группы, которые объединены общими инструментами, тактиками и целями), с другой — усложнилась точная атрибуция инцидентов. Например, то, что первоначально выглядело как случайная активность, во время расследования нередко оказывалось частью хорошо подготовленной кампании.</p> <p>Отдельно аналитики подчеркивают, что инструментарий атакующих все чаще дополнялся решениями на основе ИИ. В 2025 году в компании столкнулись не только с использованием сгенерированных сценариев и скриптов для автоматизации рутинных задач, но и со случаями применения C2-агентов, написанных или адаптированных с помощью ИИ. Порог входа для создания кастомного инструментария снижается, что усложняет сигнатурное обнаружение и ускоряет появление новых вредоносных программ.</p> <p>Медианный показатель обнаружения злоумышленников по итогам 2025 года составил 17 дней. В атаках с использованием программ-вымогателей показатель был ниже — всего 7 дней. Однако подобные атаки разворачиваются настолько быстро, что даже за этот срок компании чаще всего узнавали о взломе уже на финальной стадии. Если говорить об инцидентах в целом, то почти в половине случаев (45%) на обнаружение атаки уходило больше месяца: 15% атак обнаруживались в срок от месяца до полугода, 5% — от полугода до года, а 25% присутствовали в инфраструктуре больше года. Часть таких долгих случаев связана с низкоквалифицированными атаками ботнет-сетей, размещающих майнеры на уязвимых серверах, а другая — с деятельностью группировок, специализирующихся на шпионаже.</p> <p>«Количество и разнообразие киберугроз растет с каждым годом. Тем не менее мы видим, что в прошлом году заметно выросла доля организаций, которые быстрее реагирует на инциденты и подозрительную активность, охотнее взаимодействуют с командами реагирования и осознаннее инвестируют в защиту. Это однозначно позитивная тенденция. Но потенциал для роста в области кибербезопасности остается значительным, особенно в части проактивного обнаружения угроз и готовности к восстановлению после инцидентов», — добавил Артем Грибков, заместитель генерального директора Angara MTDR.</p> Сфера информационных технологий в 2025 году стала самой атакуемой отраслью в стране — на нее … message https://www.itweek.ru/themes/detail.php?ID=235495 Wed, 09 Sep 2026 10:26:15 +0300 <p><em>Анкит Джайн, соучредитель и генеральный директор Aviator, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, почему контекстом вашего ИИ-агента следует управлять как ПО и как цикл разработки контекста улучшает качество навыков, тестирование и масштабируемость.</em></p> <p>Навыки, конфигурации агентов, инструкции к промптам и файлы правил. Эти артефакты теперь определяют то, что создают ваши агенты по кодированию. Они определяют каждую строку сгенерированного кода, каждое архитектурное решение, каждое соглашение, которому агент следует или которое игнорирует. По сути, это ПО.</p> <p>Но никто к ним так не относится. Команды пишут навыки, добавляют их в репозиторий и никогда не проверяют, работают ли они после обновления модели. Конфигурации агентов копируются и переносятся между командами без версионирования. Файлы правил теряют синхронизацию с кодовой базой, которую они описывают. Когда что-то ломается, об этом сигнализирует разработчик, заметивший странный вывод и пожаловавшийся в Slack.</p> <p>Независимый ИТ-консультант Патрик Дюбуа предложил <a href="https://tessl.io/blog/context-development-lifecycle-better-context-for-ai-coding-agents">концепцию</a> того, чего не хватает: цикл разработки контекста (Context Development Lifecycle, CDLC). CDLC — это не управление окном контекста или размещение большего количества токенов в запросе. Речь идёт об управлении качеством элементов, которые попадают в контекстное окно. Актуален ли навык? Действительно ли модель правильно реагирует на него? Предоставляете ли вы контекст, который модель уже знает? Если контекст — это новый код, каков его жизненный цикл разработки?</p> <h3>Четыре фазы жизненного цикла разработки контекста</h3> <p>CDLC имеет четыре фазы, которые напрямую соответствуют тому, что мы уже делаем с кодом.</p> <p>#IMAGE_235496#</p> <p><strong>Генерация</strong> — это то, с чего все начинают. Написание навыков, создание конфигураций промптов, настройка правил агента. Это эквивалент написания кода, и именно на это сегодня уходит бóльшая часть времени.</p> <p><strong>Оценка</strong> — это тестирование. Проверка правильности линтинга во фронтенде или не слишком ли длинный синтаксис. На более сложном этапе вы запускаете сценарии: загружаете навык, задаёте конкретный вопрос, проверяете, выдаёт ли агент ожидаемый результат. Вы тестируете разные модели и версии. Вы проверяете, не пишете ли вы контекст, который модель уже знает, что приводит к нерациональному использованию токенов. Вы проверяете, активируется ли навык по правильным ключевым словам.</p> <p>Это цикл разработки через тестирование (TDD) для контекста. Пишите навык, пишите сценарий, проверяете результат, итерируете.</p> <p><strong>Дистрибуция</strong> — это доставка. На самом простом уровне это добавление навыка в репозиторий. На более зрелом уровне команды публикуют навыки в установленный реестр с версионированием, возможностью обнаружения и контролем доступа. Вставка навыка в канал Slack — это не дистрибуция, так же как отправка файла .jar по электронной почте — это не управление зависимостями.</p> <p><strong>Наблюдаемость</strong> — это мониторинг производственной среды. Используется ли навык? Выдает ли он правильные результаты? Сколько итераций проходит агент, прежде чем вмешается разработчик? Где разработчики переопределяют агента или исправляют его вывод? Это наблюдаемость для вашего контекста.</p> <h3>Не пропускайте тестирование</h3> <p>Кривая зрелости здесь идентична тому, что происходило с практиками разработки ПО за последние два десятилетия. Организации создают и распространяют. Они полностью пропускают оценку. Они отправляют навыки в производственную среду, то есть разработчикам, которые их используют, и ждут, что произойдет.</p> <p>Это напрямую сравнимо с тем, как команды игнорируют разработку через тестирование, несмотря на указания делать это. Они не знают, что такое боль, поэтому сразу передают в производство.</p> <p>Боль возникает, когда навык работает в одной версии модели, но ломается в следующей, или когда он срабатывает на неправильный вопрос и дает разработчику заведомо неверные инструкции. Когда соглашение, которое навязывал навык, было правильным полгода назад, но кодовая база с тех пор изменилась. Это те же самые режимы сбоев, которые мы видим в непротестированном коде. Регрессии, ложные срабатывания, устаревшие предположения.</p> <p>В каждой кодовой базе есть шаблоны, в которых ИИ постоянно ошибается. Слепота к соглашениям, галлюцинаторные API, код карго-культа, избыточное проектирование. Мы называем это инвариантами, или реестром ошибок ИИ. И реестр навыков, и реестр ошибок ИИ иллюстрируют один и тот же основополагающий принцип на обоих концах жизненного цикла разработки: каталогизируйте свои инженерные стандарты и передавайте их агентам.</p> <p>До генерации кода это означает навыки. На этапе проверки кода это каталог шаблонов, в которых ИИ постоянно ошибается на вашей кодовой базе. Реестр ошибок служит основой для автоматизированных проверок, выявляющих все, что осталось незамеченным. Вы не можете масштабировать качество кода, требуя от людей более тщательной проверки. Вы масштабируете его, инвестируя в механизмы контроля, которые кодифицируют ваши стандарты на обоих концах.</p> <h3>От 1x до 50x</h3> <p>Разработчик, оптимизирующий собственный цикл работы агента, получает лучшие индивидуальные результаты, но это улучшение остается с ним. Когда он исправляет ошибку в навыке, никто другой от этого не выигрывает. Когда он обнаруживает ошибку, никто другой извлекает из этого урок. ROI здесь однократный (1x).</p> <p>Дюбуа схематизирует вопрос масштабирования, используя две метрики, которые лежат в основе традиционных показателей DORA.</p> <p>Первая — это <strong>участие человека</strong>: как часто разработчику приходится вмешиваться в рабочий процесс конкретного агента? Каждое вмешательство — это сигнал о том, что контекст отсутствует или неверен. Сокращение участия человека — это прямой показатель того, насколько автономен цикл кодирования вашего агента, и он часто коррелирует со стоимостью, поскольку больше циклов означает больше затрат на агентов.</p> <p>Вторая — это <strong>эффект повторного использования</strong>: сколько разработчиков получают выгоду от улучшения одного навыка? Если один разработчик исправляет навык, и только он получает от этого выгоду, это 1x. Если это исправление попадает в общий реестр, и его получают 50 разработчиков, это 50x.</p> <p>Эти две метрики вместе заставляют организацию стремиться к общей инфраструктуре. Вы не можете сократить участие человека в масштабе без общего, хорошо протестированного контекста. Вы не можете получить эффект повторного использования без дистрибуции и версионирования.</p> <h3>Ваша команда платформы уже знает, как это делать</h3> <p>Организационная структура для этого уже существует. Платформенные команды потратили десятилетие на создание инфраструктуры, позволяющей командам разработчиков надежно выпускать код: системы контроля версий, конвейеры CI/CD, реестры артефактов, сканирование безопасности, управление зависимостями и контроль доступа. Этот подход практически напрямую применим и к разработке контекста.</p> <p>То, что команда платформы делает для репозиториев кода, она делает и для навыков. Предоставляет реестр. Настраивает контроль доступа и разрешения для групп. Создает инфраструктуру для оценки. Запускает сканирование безопасности и сообщает о результатах. Создает дашборды, показывающие, какие навыки работают хорошо, а какие ухудшаются. Отслеживает ответственность, чтобы, когда навык ломается после обновления модели, был ответственный за его исправление.</p> <p>Чего команда платформы не делает, так это не пишет навыки и не исправляет их, когда они ломаются. Команда, которая владеет предметной областью, владеет и навыком. Команда платформы предоставляет уровень управления и инструменты, здесь то же самое разделение ответственности, которое работает и для кода.</p> <p>Проблема «осиротевших навыков» уже начинает проявляться. Разработчик пишет навык, делится им, переходит в другую команду, и теперь никто его не поддерживает. Обновление модели приводит к сбою, и команда платформы по умолчанию наследует эту проблему. Это снова история с осиротевшими репозиториями GitHub. Решение то же самое: политики владения, требования к поддержке, пути вывода из эксплуатации.</p> <p>Советы Дюбуа звучат лаконично: «Не создавайте инструмент. Создайте инструмент, который создает инструмент. Команда платформы создает инструмент для тех, кто создает инструмент, который создает инструмент».</p> <h3>Замыкание цикла с помощью наблюдаемости</h3> <p>Наименее развитый этап в большинстве организаций — это наблюдаемость, хотя он и самый важный. Без него нет системы обучения. Вы вручную генерируете и распространяете контекст, надеясь, что это сработает, и исправляете ошибки, когда кто-то подает жалобу.</p> <p>Наблюдаемость агентов все еще находится на ранней стадии. Стандарты только формируются. Agent MD уже широко используется. Стандарты навыков и плагинов относительно новые. Инструментарий еще не зрелый, но схема ясна: инструментируйте своих агентов, централизуйте сигналы и анализируйте их в разных командах.</p> <p>По нашему мнению, петли обратной связи в производственной среде — это недостающий элемент в разработке с использованием ИИ. Когда что-то ломается в производственной среде, отследите это до изменения, определите категорию ошибки и передайте ее обратно как на уровень промптов, так и на уровень проверки. Этап наблюдаемости в CDLC расширяет эту идею от качества кода до качества контекста. Сигналы, собранные из журналов агентов, исправлений разработчиков и подсчета шагов, напрямую используются для создания более качественных навыков, написания более целенаправленных оценок и дистрибуции улучшенных версий.</p> <h3>Самосовершенствующаяся агентная разработка</h3> <p>Полностью замкнутый цикл выглядит как система, в которой журналы агентов используются для анализа, выявляющего пробелы. Эти пробелы генерируют новые навыки или обновления существующих. Обновленные навыки проходят оценку перед выпуском. Они распространяются через реестр с контролем версий. И цикл повторяется.</p> <p>Дюбуа реалистично оценивает конечный результат. Видение «темной фабрики», где агенты создают код без участия человека, он называет «благородным направлением, но рискованной игрой». Команды, которые приближаются к этому (те, кто может с уверенностью сказать, что они больше не читают код), — это те, кто вложили значительные средства в контекст, тестирование и инфраструктуру наблюдаемости, которые делают их агентов достаточно надежными, чтобы требовать меньшего количество человеческих вмешательств в цикле.</p> Анкит Джайн, соучредитель и генеральный директор Aviator, рассказывает на портале The New Stack о том, почему … article https://www.itweek.ru/themes/detail.php?ID=235493 Wed, 09 Sep 2026 10:11:05 +0300 <p><em>Логистика с ее сложными процессами и огромными массивами данных — одна из тех отраслей, где искусственный интеллект способен изменить саму архитектуру бизнеса. Однако произойдет это не благодаря появлению очередной языковой модели. Рассмотрим, из каких уровней складывается ИИ-инфраструктура и какие ограничения сегодня существуют на каждом из них.</em></p> <h3>ИИ как инфраструктура</h3> <p>Сегодня искусственный интеллект воспринимается бизнесом скорее как отдельный продукт, и разговор о нем обычно сводится к сравнению моделей. Но на самом деле смотреть стоит гораздо шире. Бизнес начинает получать ощутимый эффект только тогда, когда одновременно развиваются три компонента:</p> <ul> <li> наличие самих моделей искусственного интеллекта;</li> <li> компетенции людей;</li> <li> наличие качественных данных.</li> </ul> <p>Но и это лишь фундамент. Если представить эту систему в виде пирамиды, то в ее основании находятся именно эти три компонента. Следующий уровень — ИИ-агенты и коннекторы, которые позволяют им взаимодействовать между собой и с внешними системами. И на вершине этой пирамиды находится бизнес-эффект — возможность быстрее, точнее и с меньшими затратами решать реальные задачи.</p> <p>Именно поэтому бизнесу сегодня стоит сосредоточиться не столько на вопросе, какая модель окажется сильнее, сколько на том, насколько быстро удастся построить всю пирамиду — инфраструктуру вокруг ИИ.</p> <h3>Проблемы российских моделей</h3> <p>С точки зрения моделей ситуация в России остается сложной. Наиболее качественные и развитые мировые решения, такие как Claude от Anthropic и ChatGPT, находятся фактически вне легального контура использования для российского бизнеса. Бизнес не может официально приобрести модель, оплачивать ее использование, учитывать эти расходы в финансовом контуре и выстраивать полноценную корпоративную инфраструктуру вокруг нее.</p> <p>Российские модели пока уступают мировым по возможностям. Пока развитие отечественных решений сосредоточено преимущественно на пользовательских чат-ботах. Например, GigaChat получил инструменты для создания ИИ-агентов совсем недавно, тогда как у OpenAI и Anthropic они появились значительно раньше. За это время вокруг зарубежных моделей успела сформироваться зрелая экосистема инструментов, интеграций и практических сценариев внедрения, тогда как российские решения только проходят этот этап.</p> <h3>Даже идеальная нейросеть бесполезна без данных</h3> <p>Однако основная проблема с внедрением ИИ в России сегодня не в моделях и не в людях, которые пока только начинают накапливать практический опыт работы с нейросетями. Самый ценный ресурс — понятные, структурированные данные: это основа для принятия решений и одновременно материал, на котором обучаются сами модели.</p> <p>Например, кажется, что подготовить коммерческое предложение перевозчику — типичная задача для человека. На самом деле это практически идеальный кейс для ИИ. Но чтобы агент мог рассчитать тариф, ему нужна информация:</p> <ul> <li> собственная база тарифов и алгоритмы, которые описывают, как формируется стоимость перевозки;</li> <li> исторические данные: количество рейсов с конкретным перевозчиком и клиентом, качество работы, платежную дисциплину, возникавшие проблемы и претензии — возможно, эти риски необходимо закладывать в тариф заранее;</li> <li> система также должна учитывать будущие тренды: изменение стоимости топлива, инфляцию, динамику заработных плат водителей;</li> <li> еще один важный элемент — рыночные данные. Целевая маржинальность на рынке может составлять 5, 15 или 30% — и выбор зависит от текущего баланса спроса и предложения по конкретному направлению. Для этого нужны дополнительные коэффициенты и отраслевые базы данных.</li> </ul> <p>Фактически сейчас человек выполняет всю эту работу самостоятельно: он держит множество факторов в голове, опирается на опыт и часто интуитивно формирует предложение. Это как раз задача, где искусственный интеллект может быть особенно эффективен, но без качественных данных он будет решать ее ограниченно.</p> <p>И здесь у российской логистики есть серьезная проблема. Рынок автологистики в России сильно деконсолидирован, и даже крупнейший игрок занимает всего около <nobr>2-3%</nobr> рынка. У нас фактически нет сформированных единых больших баз данных, которые позволяли бы бизнесу строить алгоритмы с использованием ИИ.</p> <h3>Кто станет владельцем инфраструктуры данных</h3> <p>Если данные — главное топливо для искусственного интеллекта, то кто будет владеть этим ресурсом?</p> <p>Мы видим, что государство уже формирует базовую цифровую инфраструктуру, вводя обязательный электронный документооборот. В перспективе такая система способна аккумулировать информацию о значительной части перевозок на рынке. Это может стать серьезной основой для дальнейшего применения искусственного интеллекта в логистике, однако остается открытым вопрос: насколько эти данные будут доступны бизнесу для практического использования.</p> <p>Если регуляторные требования помогают сформировать единое информационное пространство и накапливать данные, то бизнес способен наполнить его практической ценностью, создавая сервисы на основе этих данных. Хороший пример — компания ATI, которая собирает данные по ставкам на перевозки в России. Сейчас это один из основных источников информации по тарифам на рынке. Модель построена на добровольной основе: компания платит участникам за предоставление данных, консолидирует их и затем предоставляет бизнесу в удобном формате.</p> <p>Потенциал у такого подхода действительно большой. Если в России развитие пойдет ближе к китайской модели, где участников рынка стимулируют работать через цифровые платформы, а сами платформы создают полезные сервисы для бизнеса, эффект, вероятно, будет очень высоким. В такой модели компании заинтересованы в использовании платформ не только из-за требований регуляторов, а потому что понимают, какую конкретную пользу получают от обмена этой информацией.</p> <h3>Настоящая революция начнется в эпоху ИИ-агентов</h3> <p>Итак, для построения полноценной ИИ-инфраструктуры требуются три элемента: сами модели, люди с компетенциями и качественные данные. Хотя на каждом из этих уровней пока есть свои ограничения, фундамент для будущей ИИ-инфраструктуры уже постепенно формируется. По мере его развития будут появляться новые классы решений.</p> <p>Именно следующий этап — появление большого количества специализированных агентов, которые смогут работать поверх этой инфраструктуры, взаимодействовать между собой и самостоятельно выполнять бизнес-задачи — может стать настоящим прорывом с точки зрения повышения эффективности бизнеса.</p> <p>В перспективе можно представить ситуацию, когда в логистической компании из 20 сотрудников, условно, 17 цифровых агентов будут закрывать рутинные процессы, а люди будут заниматься более сложными задачами, требующими экспертизы и стратегических решений.</p> <p>При этом сами агенты будут развиваться в двух основных направлениях.</p> <p>Первое — внутренние агенты. Это системы, которые помогают решать задачи внутри компании: формировать дополнительные соглашения, создавать должностные инструкции, готовить коммерческие предложения. Подобные решения уже начинают появляться во многих отраслях, и первые результаты подтверждают их эффективность. Так, согласно свежему <a href="https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/the-future-of-b2b-sales-how-growth-champions-rewire-their-playbooks-with-ai">исследованию</a> McKinsey «The Future of B2B Sales», 59% компаний-лидеров роста сообщили, что благодаря ИИ повысилась эффективность работы их отделов продаж, а внедрение ИИ-агентов хотя бы в один из ключевых процессов способно высвободить дополнительно около 10% времени продавцов.</p> <p>Однако прорыв, вероятнее всего, будет связан со вторым типом — агентами, которые смогут взаимодействовать не только с внутренними системами компании, но и с внешним рынком. Например, внешний агент сможет искать подходящий транспорт не только из парка компании, а среди всех доступных участников рынка. Или готовить коммерческое предложение, анализируя тендеры и взаимодействуя с внешними торговыми площадками.</p> <p>Однако потребуется еще один важный элемент — коннекторы. Сегодня люди взаимодействуют через привычные каналы: мессенджеры, электронную почту, видеосвязь. Но человеку достаточно получить сообщение, а дальше он сам найдет нужные данные, вспомнит контекст, проверит информацию, оценит риски и примет решение. Для ИИ-агента такой подход неэффективен. Ему недостаточно просто передать сообщение — вместе с ним необходимо предоставить структурированные данные, бизнес-контекст, правила принятия решений и возможность выполнить нужное действие в другой системе.</p> <p>Именно поэтому в будущем будут развиваться специальные коннекторы — цифровые каналы взаимодействия ИИ-агентов. Коннектор можно сравнить с мессенджером для ИИ-агентов, однако его роль выходит далеко за рамки обмена сообщениями. Это среда, которая обеспечивает агенту доступ к данным, контексту и инструментам, необходимым для принятия решений и выполнения действий. В логистике это может быть поиск перевозчика, расчет тарифа, проверка контрагента или оформление документов; в других отраслях — свои специализированные сценарии.</p> <h3>Победят не те, у кого лучше нейросеть</h3> <p>Сегодня рынок по-прежнему сосредоточен на сравнении языковых моделей: какая лучше и сильнее. Однако конкурентное преимущество будут создавать не сами модели, а вся инфраструктура вокруг них.</p> <p>В логистике это приобретает особое значение. Сегодня, чтобы найти подходящий транспорт, специалист иногда обзванивает десятки перевозчиков, выясняя, у кого есть свободная машина на нужном направлении. Теоретически эту задачу мог бы выполнять ИИ-агент — быстрее, дешевле и точнее. Но для этого ему нужен доступ к данным обо всем рынке, а не только к информации одной компании. Пока такой системы нет, даже самые совершенные модели не способны раскрыть свой потенциал.</p> <p>В конечном счете главным фактором развития станет уже не сама языковая модель, а инфраструктура вокруг нее. Когда появятся качественные данные, механизмы их обмена, специализированные коннекторы и экосистема ИИ-агентов, искусственный интеллект сможет решать задачи не отдельных компаний, а всей отрасли. Именно этот этап и станет настоящим переломным моментом — будь то для логистика или любая другая сфера.</p> <p> #IMAGE_235494#</p> Логистика с ее сложными процессами и огромными массивами данных — одна из тех отраслей, где … article Михаил Чушков, генеральный директор онлайн-сервиса Pooling https://www.itweek.ru/themes/detail.php?ID=235491 Wed, 09 Sep 2026 10:02:54 +0300 <p><em>Создать работающий прототип искусственного интеллекта сегодня значительно проще, чем довести его до промышленного внедрения. Современные модели позволяют быстро показать убедительный результат, однако именно после успешного пилота начинается самая сложная часть работы. На основе опыта разработки AI-решений для медицины и юриспруденции </em><em>я</em><em> разбер</em><em>у</em><em>, почему многие проекты так и не становятся полноценными продуктами и какие ошибки чаще всего приводят к этому.</em></p> <p>По данным McKinsey «Global Survey 2025», 88% респондентов сообщили, что в их организации регулярно используют AI хотя бы в одной бизнес-функции. При этом почти две трети организаций ещё не начали масштабировать AI на уровне всей компании. Лишь 39% респондентов сообщили о влиянии AI на EBIT на уровне всей организации.</p> <p>Этот разрыв показателен. Ограничением всё реже становится техническая реализация AI-модели. Основные проблемы начинаются после того, как модель впервые выдала правильный ответ.</p> <p>Похожая картина видна и в российских данных. В исследовании ИСИЭЗ НИУ ВШЭ «Применение искусственного интеллекта в российских компаниях» отмечается, что среди организаций, использующих ИИ, значимыми барьерами остаются не только затраты, но и инфраструктура, нехватка квалифицированных кадров, дефицит данных, сложность интеграции ИИ в бизнес-процессы, законодательные ограничения и качество данных.</p> <p>Пилот должен доказать не только техническую возможность, но и три более важные вещи: организация готова платить за продукт, пользователи хотят его применять и решение можно встроить в реальный процесс без потери всей ожидаемой экономии. Если хотя бы одно из этих условий не выполнено, даже сильный ИИ рискует остаться демонстрацией.</p> <p>Главная причина неудачи большинства AI-проектов — не слабая модель, а разрыв между демонстрацией технологии и ее использованием в реальном рабочем процессе.</p> <h3>Демо оптимизирует ответ, бизнес — весь процесс</h3> <p>На демонстрации AI-продукт обычно получает подготовленные данные и за несколько секунд может сформировать хорошее впечатление. На этом фоне легко решить, что основная часть задачи уже выполнена. Но ответ модели — только один этап рабочего процесса. После него результат необходимо проверить, исправить, согласовать, сохранить в корпоративной системе и использовать для принятия решения. До обращения к модели данные также нужно найти, подготовить и передать в подходящем формате.</p> <p>Поэтому локальное ускорение одной операции не гарантирует ускорения процесса целиком.</p> <p>AI ускоряет отдельную операцию. Бизнес оценивает, насколько быстрее завершился весь процесс. Именно здесь чаще всего возникает разрыв между успешным пилотом и реальным внедрением.</p> <p>Похожий эффект виден в разработке ПО. Исследование NBER по более чем 100 тыс. GitHub-разработчиков показало, что для автономных AI-инструментов рост coding activity составил около 180%, но рост фактически выпущенных релизов — только около 30%. Авторы объясняют разрыв последующими человеческими и производственными ограничениями: проверкой, интеграцией и выпуском.</p> <p>С похожей ситуацией я сталкивался при разработке AI-решений для медицины и юриспруденции. Даже когда модель демонстрировала высокое качество на тестовых сценариях, этого было недостаточно для внедрения. Основная работа начиналась после получения ответа модели: нужно было встроить систему в существующие процессы, сократить объем ручной проверки и сделать так, чтобы использование AI действительно экономило время специалиста, а не создавало новые этапы работы.</p> <p>Для отраслевого AI действует тот же принцип. Система может подготовить документ за минуту, но специалисту потребуется значительно больше времени, чтобы проверить факты, источники и применимость результата. Она может предложить решение, которое затем придётся вручную переносить в другую информационную систему. Она может ускорить работу одного сотрудника и одновременно создать дополнительную очередь у следующего участника процесса. Поэтому заказчика интересует не скорость первого ответа, его интересует время до завершенного и проверенного результата.</p> <p>Перед началом разработки полезно ответить на несколько вопросов: какое действие пользователя должно измениться, какой этап процесса исчезнет или сократится, сколько времени займет проверка, что произойдёт после получения ответа и не возникнет ли новое узкое место дальше по цепочке.</p> <h3>Позднее вовлечение пользователей создает мертворожденные продукты</h3> <p>Одна из самых распространённых ошибок — подключать будущих пользователей только на этапе пилота. Эта ошибка встречается и в начинающих стартапах, и во внутренних командах крупных компаний. Разработчики несколько месяцев создают решение, исходя из собственного представления о работе врача, юриста, бухгалтера, инженера, оператора или менеджера.</p> <p>На демонстрации всё выглядит убедительно. Данные подготовлены, сценарий заранее выбран, сложные случаи исключены или специально подобраны такие, с которыми решение справляется. Но когда продукт впервые попадает к специалисту, возникают базовые вопросы.</p> <p>Как вообще пользоваться решением? Как оно будет интегрировано в привычные рабочие инструменты? На чем основан ответ системы? Откуда должны поступать данные? Что делать с ответом? Почему новый сценарий лучше привычного? Кто отвечает, если результат окажется неверным? Будет ли у специалиста время проверять вывод модели?</p> <p>Если эти вопросы появляются в конце разработки, команда проверяет продуктовую гипотезу слишком поздно. Так возникает демонстрационный долг: набор неподтвержденных предположений о поведении пользователя, данных, интеграциях и ответственности. Чем дольше команда строит продукт, не проверяя эти предположения, тем дороже становится их пересмотр.</p> <p>Обратная связь специалиста нужна не после создания MVP, а до выбора основного сценария. Недостаточно провести интервью и попросить пользователя перечислить проблемы. Полезнее наблюдать за реальной работой: какие системы он открывает, где копирует данные, что перепроверяет, кому передает результат и в каких случаях действует в обход официального процесса, где сейчас узкое горлышко.</p> <p>В профессиональных областях пользователь не просто оценивает удобство интерфейса. Он помогает определить саму логику продукта: какие данные обязательны, какие исключения критичны, когда автоматизация допустима, где нужен контроль человека и какие ошибки нельзя пропустить.</p> <p>Поэтому участие пользователя не должно превращаться в бесконечный сбор пожеланий. Команда должна проверять конкретные гипотезы: возникает ли проблема достаточно часто, меняет ли прототип поведение специалиста, возвращается ли он к продукту без напоминаний, готов ли использовать его на реальных данных и становится ли процесс быстрее или качественнее после проверки результата.</p> <p>Если ответы отрицательные, продукт нужно менять, а не дополнять новыми функциями. На старте важнее не пытаться создать идеального ИИ-юриста, врача или бухгалтера, а качественно закрыть одну актуальную задачу и только после успешного MVP расширять функциональность. Иначе команда рискует создать продукт-Франкенштейн: он претендует на решение всего сразу, но по факту не закрывает достаточно хорошо ни один сценарий.</p> <p>На раннем этапе гораздо ценнее решить одну повторяющуюся задачу лучше существующих инструментов, чем пытаться автоматизировать весь процесс сразу. Именно так появляются продукты, которыми специалисты начинают пользоваться каждый день.</p> <h3>Пользователь, эксперт и покупатель — не один человек</h3> <p>Для вертикального AI-продукта недостаточно найти отраслевого эксперта.</p> <p>На практике я быстро убедился, что понимание профессиональной задачи — только часть работы. Даже если специалисты высоко оценивают решение, это еще не означает, что оно будет внедрено. Для появления продукта в организации должны совпасть интересы сразу нескольких участников процесса.</p> <p>Эксперт помогает понять процесс, профессиональные требования и цену ошибок. Но он не обязательно распоряжается бюджетом и может не влиять на закупку.</p> <p>В сложных B2B-продажах вокруг продукта обычно возникает несколько ролей: специалист, который будет им пользоваться; эксперт, помогающий его проектировать; внутренний сторонник, продвигающий решение; владелец бюджета; лицо, подписывающее договор; ИТ и информационная безопасность; юридическая служба и закупки.</p> <p>Команда может сделать отличный продукт для пользователя, но не иметь доступа к покупателю. В этом случае продажи не начнутся. Обратная ситуация тоже возможна: руководитель видит экономический смысл и готов приобрести решение, хотя часть специалистов относится к нему скептически. Такой сценарий может привести к первому контракту, но не гарантирует регулярного применения.</p> <p>Первая продажа и устойчивое внедрение — разные задачи. Лицо, принимающее решение, определяет вероятность контракта. Пользователь определяет вероятность регулярного использования, измеримого результата и продления. Продать AI-продукт и добиться его ежедневного использования — две разные задачи. Первый контракт подтверждает интерес рынка. Регулярная работа пользователей подтверждает ценность продукта.</p> <p>Поэтому до создания полноценного MVP команде полезно составить карту участников: кто испытывает проблему, кто будет пользоваться системой, кто получает экономический эффект, кто выделяет бюджет, кто может заблокировать внедрение и через какой контакт можно выйти на организацию.</p> <p>В узких B2B- и B2G-сегментах человек, умеющий открывать двери к нужным лицам, иногда решает половину коммерческой задачи. Хороший продукт без канала выхода на покупателя может годами оставаться экспериментом.</p> <h3>Считать нужно стоимость проверенного результата</h3> <p>Экономику AI часто оценивают через стоимость модели и время генерации. Для профессиональных продуктов этого недостаточно. Полная стоимость операции включает получение и подготовку данных, работу модели, проверку человеком, исправление результата, перенос в рабочую систему и ожидаемую стоимость возможных ошибок. Для бизнеса важна не стоимость работы модели, а стоимость получения проверенного результата. Именно этот показатель определяет экономический эффект внедрения.</p> <p>Особенно важна стоимость проверки. Если специалисту нужно заново прочитать все источники, чтобы убедиться в правильности подготовленного анализа, продукт может почти не экономить время. Если пользователь после автоматической обработки данных вынужден заново собирать структуру результата, автоматизация создает дополнительную работу.</p> <p>Средняя точность модели здесь тоже мало говорит об экономике. Десятипроцентная доля ошибок может быть приемлемой, если ошибки легко заметить и дёшево исправить. Она может быть недопустимой, если результат выглядит убедительно, ошибка обнаруживается поздно и влияет на последующие решения.</p> <p>В профессиональных процессах особенно опасны ошибки, которые не выглядят как ошибки. Пользователь видит аккуратно оформленный текст, таблицу или рекомендацию и тратит меньше внимания на проверку. В результате риск смещается с этапа генерации на этап принятия решения.</p> <p>Поэтому полезнее измерять не только точность модели, но и продуктовые показатели: время до проверенного результата, долю ответов, потребовавших исправления, частоту критических пропусков, долю результатов, принятых пользователем, долю случаев, переданных человеку, и стоимость одного полностью завершенного случая.</p> <p>Отдельно важно раскладывать процесс на этапы. Недостаточно сказать, что AI-автоматизация улучшила работу специалиста. Нужно понимать, сколько ресурсов уходит на подготовку данных, поиск релевантной информации, проверку источников, формирование итогового ответа, перенос результата в рабочую систему и последующую коммуникацию.</p> <p>Но сами метрики мало что дают, если процесс рассматривается как единая неделимая задача. Его нужно раскладывать на отдельные операции: подготовку документов, поиск релевантной информации, перепроверку источников, формирование итогового ответа, перенос данных в рабочую систему и последующую коммуникацию.</p> <p>Такая декомпозиция позволяет понять, какой именно участок ИИ действительно улучшает, а где эффект теряется. Иногда оказывается, что на первом этапе не нужно автоматизировать всю цепочку. Более сильной продуктовой гипотезой может быть узкое решение, которое качественно закрывает один дорогой этап, например, поиск и структурирование релевантной информации для специалиста, оставляя финальный вывод или коммуникацию человеку.</p> <p>Поэтому главный вопрос для разработчиков должен звучать не «насколько хорошо модель отвечает?», а «насколько качественно и надежно система закрывает выбранный участок реальной задачи и делает ли это выгоднее текущего процесса?»</p> <h3>Пилот должен проверять организацию, а не только технологию</h3> <p>У пилота почти всегда более благоприятные условия, чем у будущего продукта. В нём участвуют мотивированные пользователи, команда разработчиков быстро помогает при сбоях, данные можно подготовить вручную, нестандартные случаи временно исключаются, интеграции заменяются переносом информации между системами. Такой пилот может подтвердить техническую гипотезу, но ничего не сказать о готовности к эксплуатации.</p> <p>За последние несколько лет я пришел к выводу, что пилот проверяет не столько технологию, сколько готовность организации изменить собственные процессы. Если компания не готова встроить новое решение в ежедневную работу, даже успешная демонстрация не приведет к масштабному внедрению.</p> <p>Промышленное внедрение требует ответов на другие вопросы: кто отвечает за результат, как система получает реальные данные, как управляются права доступа, кто устраняет сбои, как обучаются новые сотрудники, из какого бюджета оплачивается эксплуатация, что происходит после обновления модели и по каким критериям решение масштабируется или закрывается. Именно эти вопросы часто оказываются важнее качества демонстрации.</p> <p>Российский аналитический доклад «Индекс готовности приоритетных отраслей экономики Российской Федерации к внедрению искусственного интеллекта» рассматривает готовность к ИИ не только через наличие технологий, но и через нецифровые факторы: государственную политику, регулирование, стратегическое планирование, корпоративное управление, кадры и компетенции, исследования и разработки. Отдельно учитываются цифровые основы: инфраструктура, данные, доверие и безопасность.</p> <p>На практике это означает, что зрелость AI-проекта определяется всей системой вокруг модели: процессами, ответственностью, инфраструктурой и готовностью сотрудников использовать новый инструмент.</p> <p>Отдельная проблема — интеграции. Во многих отраслях рабочий процесс уже распределен между несколькими системами. Если AI-инструмент требует от пользователя копировать данные между окнами, вручную переносить результат и отдельно проверять источники, часть экономии исчезает. Кроме того, у разных клиентов могут быть разные вендоры внутрикорпоративных систем. В таком случае именно вопрос интеграции может стать главным узким горлышком всего проекта.</p> <h3>Важно вовремя признать неверную гипотезу</h3> <p>После нескольких кварталов разработки команде становится сложно отказаться от продукта. Уже потрачен бюджет, руководству обещан результат, подготовлены презентации, участники проекта связали с ним свою профессиональную репутацию.</p> <p>С этой ситуацией сталкиваются и стартапы, и крупные компании. Чем больше времени и ресурсов вложено в проект, тем сложнее объективно оценить, действительно ли он решает проблему пользователя или команда продолжает развивать его по инерции.</p> <p>Если видно, что продукт не находит ожидаемого рыночного спроса, вместо признания ошибки иногда начинается поиск любого подразделения или внешнего клиента, которому можно предложить уже созданное решение. Команда перестает искать продукт под проблему и начинает искать проблему под продукт. Продажа в таком случае становится способом оправдать предыдущую работу, но необходимо различать проблемы выхода на рынок и отсутствие самой потребности. Самая дорогая ошибка в AI — не отказаться от неверной гипотезы вовремя.</p> <p>Если специалисты регулярно используют решение, самостоятельно возвращаются к нему и готовы мириться с несовершенствами, но компания не может выйти на владельца бюджета, вероятно, проблема находится в продажах.</p> <p>Если пользователь открывает продукт только по просьбе команды, не меняет привычный процесс и не замечает его улучшения, проблема, скорее всего, находится в продуктовой гипотезе.</p> <p>Если покупатель заинтересован, но стоимость интеграции превышает ожидаемый эффект, нужно менять архитектуру или целевой сегмент.</p> <p>Чтобы не принимать решения под влиянием уже понесенных затрат, проект полезно разделить на последовательные проверки.</p> <p>Первая проверка — проблема. Подтверждена ли она реальным поведением, а не только интервью?</p> <p>Вторая — пользователь. Становится ли его работа лучше после проверки результата? Продолжает ли он пользоваться продуктом без напоминания?</p> <p>Третья — покупатель. Существует ли владелец бюджета и понятный мотив для покупки?</p> <p>Четвертая — экономика. Сокращается ли полная стоимость процесса? Повышается ли итоговая ценность результата?</p> <p>Пятая — эксплуатация. Способна ли организация поддерживать решение без постоянного участия команды разработки? Как и на каких условиях будет осуществляться дальнейшее взаимодействие покупателя и разработчика?</p> <p>После каждого этапа должно оставаться три равноправных варианта: продолжить развитие продукта, изменить направление или остановить проект. Отказ от первоначальной гипотезы — это не поражение, а результат качественной проверки идеи.</p> <p>На практике успех AI-проекта определяется не тем, насколько быстро команда обучила модель, а тем, насколько рано она получила честные ответы на ключевые вопросы: существует ли проблема, готовы ли специалисты менять свои рабочие процессы, увидит ли бизнес экономический эффект и сможет ли организация поддерживать решение после внедрения.</p> <p>Именно поэтому главный показатель зрелости AI-команды сегодня — не количество разработанных моделей, а способность вовремя отказаться от неверных предположений и сосредоточиться на задачах, которые действительно создают ценность для пользователей и бизнеса.</p> <p>Путь от AI-пилота до востребованного продукта начинается не с обучения модели, а с понимания задачи, которую действительно необходимо решить.</p> <p>#IMAGE_235492#</p> Создать работающий прототип искусственного интеллекта сегодня значительно проще, чем довести его до промышленного внедрения … article Владимир Воробьев, генеральный директор АО “Экспертные платформы” https://www.itweek.ru/themes/detail.php?ID=235489 Tue, 08 Sep 2026 17:29:26 +0300 <p>Cloud Advisor представил первый в России отчёт о состоянии облачной безопасности: у 88% компаний — критические уязвимости на периметре, в каждой четвёртой инфраструктуре — вредоносное ПО.</p> <p>Российский бизнес стремительно осваивает публичные облака: всё больше компаний переносят туда свои сервисы и данные. Однако рост популярности облачных технологий закономерно привлекает и внимание злоумышленников. </p> <p>Чтобы оценить реальный уровень защищённости российских облачных инфраструктур, компания Cloud Advisor — #1 CNAPP в России — разработчик единой платформы облачной безопасности, проанализировала обезличенные данные десятков организаций: суммарно более 40 000 виртуальных машин в облаках Cloud.ru и Yandex Cloud. Результаты вошли в отчёт «Состояние облачной безопасности в России 2026».</p> <p>Главный вывод исследования: проблемы облачной безопасности носят системный характер и встречаются независимо от облачного провайдера, отрасли и размера компании.</p> <p>«Отчёт показывает тревожную картину — защищённость облачных инфраструктур в России остаётся низкой: практически нет организаций, у которых не были обнаружены критические проблемы. Причины сложившейся ситуации: нехватка знаний и экспертизы в облачной безопасности, а также попытки защитить облако привычными инструментами из on-premises сред. Такие решения не учитывают специфику облачных технологий и не способны обеспечить комплексную защиту. На глобальном уровне для защиты облаков стандартом де-факто стали специализированные решения класса CNAPP, которые обеспечивают полный контроль над облачной инфраструктурой. Отчёт — ориентир, по которому каждая компания может оценить возможные слабые места в своей инфраструктуре и начать действовать», — прокомментировал Михаил Захряпин, генеральный директор Cloud Advisor. </p> <p>Критические уязвимости на периметре — у 88% организаций. На публично доступных виртуальных машинах у 88% компаний есть уязвимости с CVSS-оценкой выше 9,0. Одна из причин — традиционные агентские и сетевые сканеры не успевают за темпом изменений в облаке и неизбежно создают «слепые зоны».</p> <p>В каждой четвёртой организации атака уже состоялась. У 24% организаций в инфраструктуре обнаружено вредоносное ПО. Это не потенциальный риск, а свидетельство состоявшегося проникновения: злоумышленники уже могли получить доступ к данным или использовать ресурсы компании для DDoS-атак и рассылки спама.</p> <p>Секреты на публично доступных ресурсах в открытом виде — у 39% организаций. На публично доступных виртуальных машинах у 39% компаний хранятся в открытом виде ключи, токены и пароли. Скомпрометировав такой ресурс, атакующий получает возможность бокового перемещения (lateral movement) по остальной инфраструктуре.</p> <p>Половина пользовательских учётных записей без MFA. 48% пользовательских учётных записей не защищены многофакторной аутентификацией, а у каждой второй организации есть привилегированная учётная запись без второго фактора. При этом 24% учётных записей не использовались более 90 дней — их удаление сократит эту часть поверхности атаки на четверть.</p> <p>Большинство ресурсов работает вхолостую. 55% виртуальных машин загружены менее чем на 10%. Оптимизация неиспользуемых и недостаточно загруженных ресурсов позволяет снизить затраты на облако до 30%.</p> <p>Полная версия отчёта содержит расширенную статистику и практические рекомендации по устранению угроз в публичном облаке. Компании могут использовать его как чек-лист для выявления рисков в собственной инфраструктуре, бенчмарк для сравнения своего уровня защищённости с другими пользователями облаков, набор аргументов для обоснования бюджета на информационную безопасность, а также — дорожную карту по защите облачной инфраструктуры на ближайший год.</p> Cloud Advisor представил первый в России отчёт о состоянии облачной безопасности: у 88% компаний — … message https://www.itweek.ru/themes/detail.php?ID=235488 Tue, 08 Sep 2026 17:27:23 +0300 <p>Физический ИИ берет числом, при этом глобальная индустрия ищет пути эволюции LLM. Это следует из результатов опроса, проведенного ICT.Moscow в рамках исследования перспективных технологических тем.</p> <p>ICT.Moscow опросил более 200 российских специалистов в сфере искусственного интеллекта, чтобы определить, какие не массовые тренды, по данным глобальных прогнозов и анализа популярных тем в отечественных медиа, имеют потенциал к последующему развитию в ближайшее время в России. Респондентам было предложено выбрать несколько перспективных, по их мнению, вариантов из предложенных.</p> <p>Для интерпретации результатов авторами также была составлена визуализация с хронологией возникновения того или иного термина и отнесения его к целевой концепции ИИ, а также прошлому или текущему стеку этой технологии.</p> <p>Среди трендов, исследуемых в опросе, почти половина относится к направлению физического ИИ (Physical AI). В этой группе наиболее приоритетными (43%) стали VLA-модели (Vision-Language-Action Models). Их применяют в робототехнике для объединения компьютерного зрения, обработки естественного языка и управления физическими устройствами. Почти каждый третий проголосовавший (31%) ожидает дальнейшего развития моделей мира (World Models). Еще 23% получили более общие крупные модели действия (Large Action Models), создаваемые для того, чтобы реагировать действиями на получаемую внешнюю информацию. Этот термин применяется как в области робототехники, так и для обозначения ИИ-агентов, не имеющих физической оболочки. Среди ответов, относимых к физическому ИИ (но не ограничивающихся им), пока меньше всего ожиданий (18%) у респондентов связано с крупными поведенческими моделями (Large Behavior Models, LBM), которые нужны для понимания действий человека в физическом мире или виртуальной среде и обучения на их основе, с тем чтобы их моделировать или воспроизводить.</p> <p>Базовые модели (Foundation Models) хоть и находятся уже в списке не самых распространенных в аналитике и новостях понятий, тем не менее собрали 23% оценок у опрошенных. Сам термин во многом уже воспринимают как синоним LLM, и его смысловое наполнение пересматривается по мере развития этого класса моделей.</p> <p>Однако тот факт, что развивавшиеся с 2015 года диффузионные модели (Diffusion Models) переживают новую волну интереса, а также появление моделей взаимодействия (Interaction Models) как нового вида UX в контексте нативных мультимодальных нейросетей, цель которых — сделать более естественным общение человека с моделью, скорее всего, говорят о том, что в индустрии ищут новый виток развития LLM, в том числе в части взаимодействия их с человеком, или даже альтернативы им. В данном опросе за них отдали 23% и 17% голосов соответственно.</p> <p>Отдельное место среди вариантов ответов занимают целевые представления об ИИ, которые многими воспринимаются как финальные точки развития технологии и продолжают сохранять этот статус уже не одно десятилетие. Речь идет об общем (или сильном) искусственном интеллекте (Artificial General Intelligence, AGI) и искусственном сверх- или суперинтеллекте (Artificial Superintelligence, ASI). Тем не менее даже такие пока что гипотетические и отдаленные концепции получили поддержку как имеющие потенциал для развития. За общий ИИ проголосовали 22% участников, а за более отдаленный сверхинтеллект — 12%.</p> Физический ИИ берет числом, при этом глобальная индустрия ищет пути эволюции LLM. Это следует из результатов опроса … message https://www.itweek.ru/themes/detail.php?ID=235486 Tue, 08 Sep 2026 17:24:24 +0300 <p>Компания «Индид», российский разработчик решений в области защиты айдентити, представила новую версию Indeed Privileged Access Manager (Indeed PAM) 3.5 — системы для управления доступом привилегированных пользователей. Среди ключевых обновлений — автоматический контроль действий во время удаленных сессий, поддержка Kerberos для Linux-инсталляций и дополнительные сценарии работы через Web Terminal.</p> <p>Одним из главных обновлений Indeed PAM 3.5 стала возможность создавать правила контроля действий пользователей во время RDP-сессий. Администратор определяет события, которые необходимо отслеживать, например запуск определенного приложения или смену окна браузера, и задает реакцию системы: запись события в журнал, завершение сессии или блокировку пользователя.</p> <p>Так служба информационной безопасности может автоматически реагировать на нежелательные действия непосредственно во время подключения, не дожидаясь завершения сессии и последующего разбора событий. Это сокращает время между обнаружением действия и ответной мерой и снижает необходимость постоянно контролировать каждое подключение вручную.</p> <p>Правила можно вводить постепенно. На первом этапе Indeed PAM может только фиксировать заданные события, чтобы специалисты собрали статистику и оценили реальные сценарии работы пользователей. После этого для отдельных действий можно настроить более строгую реакцию. Такой сценарий позволяет последовательно распространять единые требования контроля на инфраструктуру с большим количеством привилегированных подключений.</p> <p>Другим важным улучшением стала поддержка аутентификации через Kerberos на серверах Indeed PAM под управлением Linux. Она доступна пользователям, учетные записи которых хранятся в Active Directory. Если пользователь входит в Indeed PAM с доменного компьютера, браузер выполняет сквозную аутентификацию — повторно вводить логин и пароль не нужно. При этом добавлять сервер управления в домен не требуется. Ранее такой сценарий поддерживался только при развертывании Indeed PAM на Windows.</p> <p>Новый функционал также расширяет возможности работы с учетными записями администраторов, включенных в группу Active Directory Protected Users. Участники этой группы не могут аутентифицироваться по протоколу NTLM и обязаны использовать Kerberos с шифрованием AES. Теперь такие пользователи получают доступ к Indeed PAM на Linux-инсталляциях, что позволяет соблюдать усиленные требования к защите учетных данных и одновременно продолжать перевод инфраструктуры на отечественные операционные системы.</p> <p>В Indeed PAM 3.5 разработчик уделил отдельное внимание возможностям Web Terminal — инструмента для удаленных подключений через браузер. Теперь через него можно устанавливать не только RDP- и SSH-сессии, но и подключаться к серверам Remote Desktop Services (RDS).</p> <p>Пользователь может открыть удаленный рабочий стол или опубликованное RemoteApp-приложение непосредственно в браузере — без скачивания RDP-файлов, установки локального клиента и повторной аутентификации.</p> <p>Благодаря этому компании могут предоставлять сотрудникам и подрядчикам доступ к рабочим средам и бизнес-приложениям, в том числе с неуправляемых устройств. Все подключения проходят через Indeed PAM, поэтому служба информационной безопасности может контролировать и записывать привилегированные сессии.</p> <p>Кроме этого, В Web Terminal также появилась передача файлов между устройством пользователя и целевым ресурсом. Для этого достаточно перенести файл в окно активной сессии. Это возможность управляется политиками Indeed PAM, поэтому организация может разрешить ее только для согласованных сценариев.</p> <p>«По мере роста числа привилегированных подключений компаниям становится все сложнее их контролировать. Поэтому одна из ключевых задач развития Indeed PAM — автоматизировать контроль там, где раньше требовалось постоянное участие специалиста. В новой версии 3.5 мы усилили именно этот сценарий: Indeed PAM может автоматически реагировать на заданные действия пользователей. Это особенно актуально для крупных инфраструктур, где число контролируемых ресурсов постоянно растет. Одновременно мы расширяем поддержку Linux-сред и браузерных сценариев удаленной работы, чтобы заказчики могли применять единые требования к защите привилегированного доступа в разных инфраструктурах», — отметил Михаил Елычев, руководитель продукта Indeed PAM в компании «Индид».</p> Компания «Индид», российский разработчик решений в области защиты айдентити, представила новую версию Indeed Privileged … message https://www.itweek.ru/themes/detail.php?ID=235484 Tue, 08 Sep 2026 10:56:59 +0300 <p><em>Данные могут быть правильными. Определение может быть правильным. Но ответ искусственного интеллекта все равно может быть неверным. ИИ-аналитикам необходим контекст принятия решения до того, как поступит вопрос, пишет на портале </em><em>InformationWeek</em> <em>Пол Вахтлер, старший вице-президент Exiger по ИИ, данным и стратегии.</em></p> <p>Если вы работаете с данными, вы, вероятно, сталкивались с примерно с таким вопросом от вашего руководства: «Можем ли мы запустить LLM на наших данных и заставить ее проанализировать все за нас?».</p> <p>Это нормальный вопрос. Руководители хотят получать ответы быстрее, не отправляя каждый вопрос через BI-очередь. Они видят, что могут делать LLM с текстом, и предполагают, что тот же принцип должен применяться и к бизнес-данным.</p> <p>Проблема в том, что корпоративные данные не объясняют сами себя.</p> <p>Я наблюдал это во время тестирования ИИ-аналитика на реальных бизнес-вопросах. Меня интересовало, какие клиенты представляют наибольший риск в текущем квартале или какие возможности с наибольшей вероятностью будут закрыты в следующие 30 дней. Система уверенно называла клиентов или возможности. Некоторые ответы были неверными; некоторые — вымышленными; а другие имели мало отношения к вопросу.</p> <p>Система выдавала ответы, не понимая масштаба запроса или того, что бизнес подразумевает под «аккаунт подвержен риску» и «аккаунт вероятно будет закрыт». Она также не знала, означают ли «показатели текущего квартала» данные на сегодня или ожидаемые результаты к концу квартала.</p> <p>ИИ-аналитик не может понять бизнес лишь благодаря потому, что у него есть доступ к хранилищу данных. Он может написать SQL-запрос и вернуть число, которое выглядит правдоподобным. Риск заключается в том, что ему приходится где-то брать бизнес-логику, лежащую в основе ответа. Если компания не определила эту логику, модель сама заполнит пробел.</p> <p>Большинство компаний никогда не документировали всю эту бизнес-логику, потому что ею владели опытные аналитики. Сильная BI-команда знала, каким показателям выручки доверяют руководители. Они понимали, что дашборд хорош для определения направления, но не подходит для оперативного анализа. Они знали, что результат требует контекста, чтобы на нем можно было строить какие-либо действия.</p> <p>Во многих компаниях аналитик был семантическим слоем.</p> <p>Такая схема могла работать, когда одни и те же аналитики оставались в тесном контакте с бизнесом. Проблема возникает, когда от системы ожидается, что она будет отвечать самостоятельно. Теперь от LLM требуют использовать логику, которую организация ей никогда не давала.</p> <p>Проблему сложнее обнаружить, когда ответ не кажется явно ошибочным. Он может звучать разумно, но при этом быть неверным, что негативно сказывается на бизнесе.</p> <p>Помочь может проработанный семантический слой. Он предоставляет системе утвержденные определения и логику, связывающую их с данными. Но эти определения все равно должны применяться к соответствующей ситуации. Модель может использовать правильное определение дохода, но при этом выбрать неправильный временной период. Она может точно рассчитать показатели эффективности, но при этом неправильно понять, что пытается выяснить руководитель.</p> <p>Данные могут быть правильными. Определение может быть правильным. Ответ все равно может быть неверным.</p> <h3>За пределами семантического слоя</h3> <p>Семантический слой может определить, какой аккаунт следует считать подверженным риску или что делает вероятным его закрытие. Контекстный слой сообщает системе, применимы ли эти определения к задаваемому вопросу. Аккаунт может соответствовать формальным критериям риска, но эта оценка может не соответствовать временному периоду, которым пытается управлять руководитель. Определение верное; его применение неверное.</p> <p>Этот контекст также меняется со временем. Определение, утвержденное в начале квартала, может перестать соответствовать прогнозу после его изменения или корректировки руководством принимаемого решения. Система должна знать, какой контекст актуален, а какие предположения устарели. В противном случае она может правильно применить устаревшее предположение и выдать неверный ответ.</p> <p>Аналитики обычно учитывают все эти аспекты в рамках своей работы. Они знают, когда определение технически верно, но все же неверно для рассматриваемого решения. ИИ-аналитик должен понимать эти аспекты до того, как поступит вопрос. Если человеку приходится каждый раз переформулировать его, система теряет значительную часть той скорости, на которую была рассчитана.</p> <p>Агенту также необходимы операционные правила обработки неполного или противоречивого контекста. Эти правила определяют, когда агент может продолжить работу, а когда неопределенность достаточно велика, чтобы вмешался человек. Они также предотвращают незаметное превращение временных сигналов в постоянную бизнес-логику.</p> <h3>Владельцы бизнеса не исчезают</h3> <p>Владельцы бизнеса не могут проверять каждый ответ, не становясь узким местом. Им необходимо проверять результаты тестирования и оценки ответов на множества вопросов и понимать, когда контекст, лежащий в основе этих ответов, изменился.</p> <p>Бизнес поддерживает этот контекст, связывая каждое определение с решением и периодом, для которого оно было разработано. При изменении любого из этих параметров затронутый контекст помечается для проверки бизнесом.</p> <p>Этот анализ также должен охватывать сам процесс оценки. Если результат изменился, система может повысить свою оценку, улучшив выполнение неправильной задачи. Хотя система может собирать новую информацию и предлагать изменения, существенные изменения в контексте по-прежнему требуют одобрения бизнеса.</p> <p>Эта ответственность лежит на владельце бизнеса. Инженеры могут правильно построить систему, и система может работать точно так, как задумано, даже если лежащие в её основе предположения неверны.</p> <p>Раньше большую часть этой ответственности несли аналитики, опираясь на свой опыт. С ИИ-аналитиком ситуация меняется: бизнес должен брать на себя ответственность за логику, лежащую в основе ответа, и решать, когда эту логику необходимо изменить.</p> Данные могут быть правильными. Определение может быть правильным. Но ответ искусственного интеллекта все равно может быть … article https://www.itweek.ru/themes/detail.php?ID=235480 Tue, 08 Sep 2026 10:38:02 +0300 <p><em>Внедрение «умных» электронных ценников увеличило продажи и высвободило 24 тыс. рабочих часов в год.</em></p> <p>«Лемана ПРО» начала масштабирование технологии «умных» электронных ценников на всю сеть: в течение двух лет они появятся во всех гипермаркетах. Рассмотрим, почему на внедрение технологии ушел почти год подготовки, зачем потребовалось менять бумажные ценники на электронные, как устроена архитектура решения, какими функциями обладают новые ценники и какие результаты уже показал пилотный запуск.</p> <h3>Почему потребовалось менять бумажные ценники</h3> <p>Идея перейти на электронные ценники обсуждалась в компании, еще когда эта технология только начинала набирать популярность. Но долгое время высокая стоимость самой технологии в России делала внедрение невыгодным. Ситуация изменилась, когда электронные ценники стали более доступными, а дефицит кадров на рынке труда и рост стоимости рабочего времени сделали такие вложения экономически оправданными.</p> <p>«Лемана ПРО» стала первым российским ритейлером в сегменте товаров для строительства, ремонта и обустройства, внедрившим «умные» электронные ценники в процессы логистики. Электронный ценник становится частью цифровой инфраструктуры магазина, которая делает покупки более удобными, предсказуемыми и прозрачными. Если раньше офлайн-магазины конкурировали в цене друг с другом, то сегодня они конкурируют с маркетплейсами, где покупатель привык видеть актуальную цену, отзывы, характеристики товара и получать всю информацию буквально за несколько минут. Поэтому сегодня задача ритейлера — обеспечить единый уровень удобства и клиентского опыта в любом канале, в том числе непосредственно у полки в магазине.</p> <p>Мало кто задумывается, сколько времени уходит на замену бумажных ценников. Каждое утро сотрудники печатают, сортируют и вручную меняют сотни карточек с ценами — на это уходит ежедневно по <nobr>2-3 часа,</nobr> которые можно направить на обслуживание покупателей. Это одна из самых трудоемких операций в розничной торговле, которая практически незаметна клиенту, но напрямую влияет на его покупательский опыт.</p> <h3>Год подготовки: выбор технологии и партнеров</h3> <p>Прежде чем принять решение о внедрении, мы провели масштабный анализ рынка производителей и интеграторов. Российский рынок электронных ценников сегодня только формируется, а мировой рынок производителей и компаний-интеграторов сравнительно узкий.</p> <p>Почти год команда R&D и автоматизации «Лемана ПРО» работала над выбором технологии, совершала визиты в Китай к производителям и на профильные выставки, чтобы сформировать требования к продукту. Параллельно мы консультировались с российскими ритейлерами, у которых уже был опыт внедрения подобных решений: у одних технология прижилась и продолжает развиваться, у других опыт оказался неудачным. Изучение обеих сторон помогло сформировать собственный путь внедрения и заранее обойти уже известные подводные камни.</p> <p>Итоговая модель работы — трехстороннее партнерство: китайский производитель оборудования и программного обеспечения, российский интегратор, который адаптирует решение под ИТ-ландшафт конкретного заказчика и обеспечивает обучение и поддержку, и сама компания. На старте проекта мы регулярно проводили совместные встречи, а на этапе внедрения в магазинах присутствовали разработчики китайского партнера, которые могли оперативно вносить корректировки в работу системы.</p> <p>При этом мы сознательно отказались от идеи писать программное обеспечение с нуля: кастомизации подвергаются только те элементы, которые создают конкурентное преимущество для компании, а не уже отлаженные вендором процессы. Один из таких принципиальных выборов — архитектура решения: мы выбрали облачную модель хранения и обмена данными, тогда как часть игроков рынка предпочитает локальные серверы в каждом магазине, ориентируясь на собственную ИТ-стратегию.</p> <h3>Как устроена техническая архитектура</h3> <p>В доставке цены от корпоративных систем до полки участвуют пять ключевых контуров: продукты ценообразования, слой агрегации и кеширования, планировщик обновлений, облачный сервер управления ESL (Electronic Shelf Labels, электронные ценники) и радиосеть магазина.</p> <p>Цены на товары устанавливаются в соответствии со стратегией компании «Низкие цены каждый день». Мы регулярно анализируем открытые данные о стоимости товаров на рынке и в соответствии с этим снижаем цены в магазинах, чтобы гарантировать покупателям наиболее выгодные условия. Роль Price Hub выполняет собственный репозиторий цен (Price Repository) — целевая мастер-система хранения, проверки и применения розничных цен. Это единый источник данных для десятков внутренних систем: касс, электронных ценников, онлайн-каналов и систем бизнес-аналитики. Репозиторий хранит полную историю изменений и несколько миллионов активных цен, поддерживает более 600 запросов на чтение и более 350 операций записи в секунду; 95% запросов на чтение обрабатываются не дольше 200 миллисекунд, а доступность обработки поступающих запросов составляет 99,9%.</p> <p>Сервис агрегации данных объединяет все параметры товара: цену за штуку или единицу измерения товара, уникальный код, дату применения, доступный остаток, клиентский рейтинг, баллы лояльности и другие атрибуты. Профиль сохраняется в специализированном кеше, чтобы минимизировать задержку при подготовке пакетов обновлений для ценников.</p> <p>«Умный» планировщик формирует график обновлений с учетом даты вступления цены в силу, состава данных, часового пояса магазина и смен сотрудников. Он распределяет пиковую нагрузку на инфраструктуру, помогает экономить заряд батарей и инициирует применение цены точно к назначенному времени.</p> <p>ПО вендора для управления электронными ценниками развернуто в защищенном приватном облаке «Лемана ПРО». Оно управляет связками «товар — ценник», картой радиопокрытия, жизненным циклом устройств и рендерингом: накладывает данные на дизайн-шаблон и формирует растровое изображение под разрешение E-ink-дисплея нужного формата. По защищенному сетевому протоколу изображения поступают на точки доступа под потолком торгового зала, а затем по энергоэффективному радиопротоколу — на конкретные ценники.</p> <p>Облачная модель позволила отказаться от дополнительных серверов в гипермаркетах. Обновления ПО централизованно распространяются по всей сети через единый конвейер данных, а микросервисы, базы данных, очереди сообщений и API контролируются в едином контуре мониторинга. Ресурсы можно гибко наращивать по мере подключения магазинов и при массовой плановой передаче обновлений на ценники, а резервирование обеспечивается на уровне облачного кластера.</p> <h3>Что умеют новые ценники</h3> <p>Электронные ценники в «Лемана ПРО» работают в двух режимах: в режиме «день» для покупателя и продавца-консультанта и «ночь» для сотрудника пополнения и сборки. Режимы переключаются автоматически по расписанию, индивидуальному для каждого магазина, в момент его открытия и закрытия.</p> <p>#IMAGE_235483#</p> <p>В режиме «день» на ценнике отображается не только цена, но и информация о размере кешбэка за покупку данного товара, оценка товара на основе отзывов покупателей на сайте, место товара на полке, наименование, объем/размер товара и его артикул. В режиме «ночь» отображается информация о необходимости пополнения товара на полке и ее вместимости, а также увеличивается размер шрифта для необходимых атрибутов — например, артикула товара, чтобы сотруднику магазина было проще и быстрее его найти. На сегодняшний день мы — единственный ритейлер на российском рынке, который работает в мультиформатном режиме с электронными ценниками, совмещая оба сценария использования.</p> <p>Отдельная функция электронных ценников — это «мигание»: она уже интегрирована в мобильное приложение сотрудника и используется в процессах пополнения и сборки заказов. Например, среди визуально похожих друг на друга товаров сотрудник может нажать в приложении кнопку — и нужный ценник начнет мигать, показывая, где лежит необходимый артикул. Эта функция экономит время, которое раньше уходило на поиск нужной позиции среди множества похожих товаров.</p> <p>Мы не рассматриваем электронные ценники просто как замену бумаги на цифровое решение. Это скорее инфраструктурный базис, который можно интегрировать в разные процессы магазина — от ценообразования до логистики — и получать кумулятивный эффект. В планах — тестирование новых форматов, включая более крупные цифровые дисплеи (13 дюймов), которые смогут показывать дополнительный контент для покупателя.</p> <h3>Что доработали внутри компании</h3> <p>Платформа вендора стала базовым транспортным и инфраструктурным решением, однако прикладной слой и пользовательские сценарии команда разработала самостоятельно. Привязку и отвязку ценников встроили в корпоративное мобильное приложение сотрудника: операция выполняется в один шаг — сканированием штрихкода камерой смартфона. В приложении также появились пакетная привязка, принудительное обновление экрана и проверка соответствия цены данным репозитория цен.</p> <p>Для семи размеров ESL создана библиотека шаблонов в дневном и ночном режимах. Помимо ценовых атрибутов, в них передаются баллы лояльности, признак «лучшая цена» и навигационные элементы. Для плотной выкладки разработаны шаблоны с номером места и стрелками, а для кухонь, ванных комнат и других проектных зон — крупноформатный ценник А4 с составом экспозиции, перечнем артикулов и суммарной стоимостью решения. Отдельный программный сервис управляет светодиодами ценников для световой навигации при сборке заказов и пополнении полок.</p> <p>Одним из главных технических вызовов пилота стала пропускная способность радиоканала при массовом переключении режимов «день» и «ночь». В каждом гипермаркете работает около 60 тыс. ценников, поэтому одновременная смена экранов в коротком временном окне создавала большие очереди обновлений. Команда совместно с интегратором и вендором оптимизировала процесс на нескольких уровнях, включая доработку прошивки устройств.</p> <h3>Как контролируется работа ценников</h3> <p>Мониторинг построен на логах и телеметрии сервера управления ESL. Система непрерывно получает данные о состоянии точек доступа, сессиях связи, уровне радиосигнала и остаточном заряде батарей. Автоматические правила алертинга (оповещения) контролируют как сетевую инфраструктуру, так и состояние отдельных устройств: фиксируют потерю связи с точкой доступа, пропуск ценником регламентных интервалов выхода на связь и разряд элемента питания.</p> <p>На основании событий формируются задачи на обслуживание, плановую замену батарей или самого ценника. Если сеть временно недоступна, E-ink-экран продолжает автономно показывать последнее отрисованное изображение — пустого экрана в торговом зале не возникает. Такой контроль позволяет быстро устранять аппаратные и сетевые сбои.</p> <h3>Первые результаты пилота</h3> <p>Изначально пилот планировался только в одном московском магазине. Но для того, чтобы результаты были показательны как коммерчески, так и технологически, требовалась контрольная группа — так в проект добавили магазин в Твери. Дополнительным фактором стала близость обеих точек к проектной команде — это позволяло оперативно сопровождать пилот и вносить коррективы на старте проекта.</p> <p>Главный эффект проекта не в экономии средств, а в высвобождении времени сотрудников на более важные задачи. Это время они перераспределяют на работу с покупателями и, соответственно, на повышение продаж. По нашей оценке, в масштабе сети речь идет примерно о 2 тыс. человеко-часов в месяц.</p> <p>В среднем за время пилота товарооборот в пилотных магазинах вырос на 1,3% — вдвое больше планового показателя. А суммарное высвобождение рабочего времени превысило план почти в 2 раза и составило 16 тыс. часов (+7%) против плановых 9 тыс. часов (+2%).</p> <p>Рост товарооборота связан с тремя факторами:</p> <ul> <li> автоматической синхронизацией цены во всех каналах: после применения новой цены в системе она передается на электронный ценник без ручной переклейки;</li> <li> эффектом «полной полки» — высвобожденное утреннее время до открытия торгового зала сотрудники теперь направляют на пополнение и выкладку товара, а не на замену ценников;</li> <li> сокращением расхождений цены на кассе.</li> </ul> <p>Также мы измерили уровень удовлетворенности покупателей по параметрам доступности и доброжелательности сотрудников: за первые два месяца пилота показатель вырос на 0,22 п. п. (по <nobr>5-балльной</nobr> шкале).</p> <p>Экономия на печати и расходных материалах в среднем составила около 200 тыс. рублей в месяц на один магазин. В масштабах всей сети это ощутимая экономия — более 270 млн. в год, хотя изначально она не являлась целью проекта.</p> <p>Важен и экологический эффект от внедрения «умных» ценников. Отказ от печати бумажных ценников позволяет сэкономить порядка 60 кг бумаги в месяц на один магазин, или порядка 720 кг в год. В масштабах всей сети это около 80 тонн в год.</p> <h3>Что дальше</h3> <p>До конца 2026 года на электронные ценники перейдут более 50 магазинов, в том числе в Москве, Санкт-Петербурге, Краснодаре, Новосибирске, Казани, Самаре, Екатеринбурге, Ростове-на-Дону, Нижнем Новгороде, Красноярске и Иркутске. За 2 года планируется оснастить электронными ценниками всю сеть. В каждом магазине в среднем будет установлено около 60 тыс. электронных ценников семи форматов, адаптированных под различные типы товаров и особенности выкладки.</p> <p>Производство оборудования для масштабирования проекта было запущено в марте 2026 года. Первым кластером, где технология была запущена во всех магазинах, стал Новосибирск. На электронные ценники перешли четыре гипермаркета в городе, в которых заменили около 200 тыс. бумажных ценников. Одновременно еще более 50 магазинов готовятся к монтажу. Структурированная кабельная система (СКС) уже смонтирована более чем в 35 магазинах. При этом для каждого магазина после завершения монтажных работ заложен двухнедельный период тестовой стабилизации.</p> <p>Сейчас мы готовимся к следующей волне запуска со стартом реализации в 2027 году. Параллельно рассматриваем тестирование новых форматов и доработку функциональности как для сотрудников, так и для покупателей. Важно уточнить, что с точки зрения покупателя переход на электронные ценники остается бесшовным. Наши внутренние исследования показали, что клиенты не замечают замену бумажного ценника на электронный. Новые возможности — вроде мгновенно отображающейся информации о повышенном кешбэке или актуальных отзывах — воспринимаются как естественное дополнение к привычному клиентскому опыту.</p> <p>В течение пилота мы не только замеряли эффекты, но и готовили необходимые процессы для масштабирования. Над проектом работала вовлеченная профессиональная команда энтузиастов. Отдельно хочу отметить важность совместной работы команды и надежность партнеров, которые должны стать единым организмом для реализации таких трансформаций.</p> <p>#IMAGE_235481#</p> Внедрение «умных» электронных ценников увеличило продажи и высвободило 24 тыс. рабочих часов в год. «Лемана ПРО» … article Дмитрий Коченко, директор продукта компании “Лемана ПРО” https://www.itweek.ru/themes/detail.php?ID=235476 Mon, 07 Sep 2026 14:43:57 +0300 <p>Компания Postgres Professional объявила о выпуске новой версии платформы для управления и мониторинга баз данных — Postgres Pro Enterprise Manager (PPEM) 2.9. В релиз вошли усовершенствования центра оперативного контроля, улучшенные инструменты диагностики производительности, а также усиленные механизмы защиты взаимодействия между компонентами системы.</p> <p>Одним из ключевых нововведений стало расширение центра оперативного контроля. Теперь администраторы могут просматривать в нём не только отдельные экземпляры СУБД, но и отказоустойчивые кластеры. Это упрощает мониторинг распределённых инфраструктур: состояние кластера отображается как состояние единого объекта, а переход к анализу отдельных узлов занимает меньше времени.</p> <p>Существенные улучшения получил инструмент диагностики производительности Active Session Engine (ASE). Помимо общей стабилизации и доработок, в PPEM 2.9 появилась возможность управлять параметрами профилирования и выгружать данные снимков в необработанном виде для последующего анализа во внешних системах. Реализован просмотр исходных подготовленных операторов, позволяющий получить более полную картину при разборе запросов. Также добавлен бесшовный переход из истории сеансов в SQL-статистику, что упрощает диагностику проблем. Кроме того, улучшены интерфейс раздела, фильтры и визуализация графиков.</p> <p>В сфере безопасности ключевым изменением стала реализация взаимной TLS-аутентификации (mTLS). В дополнение к аутентификации по API-ключам менеджер и агенты теперь могут взаимно подтверждать подлинность друг друга с помощью сертификатов при установлении HTTPS-соединения. Это усиливает защиту взаимодействия между компонентами и снижает риск подключения недоверенной стороны, что особенно важно для инфраструктур с повышенными требованиями к безопасности.</p> <p>Платформа также получила ряд других улучшений:</p> <ul> <li>в части управления задачами и резервными копиями добавлена возможность переназначать задачи и перепривязывать хранилища для удаляемых экземпляров;</li> <li>для BiHA-кластеров реализовано управление минимальным числом исправных узлов при создании и изменении топологии;</li> <li>в обслуживании репозитория появилась возможность вручную очищать таблицы репозитория, чтобы предотвратить остановку сервера из-за нехватки дискового пространства;</li> <li>в конфигурацию добавлен параметр для задания пользовательского шаблона имени экземпляра при использовании режима автоматического обнаружения;</li> <li>исправлен ряд уязвимостей общего характера (CVE), а язык Go обновлён до версии 1.26.6.</li> </ul> <p>Postgres Pro Enterprise Manager входит в состав всех редакций СУБД Postgres Pro и предоставляет единый веб-интерфейс для мониторинга, администрирования и диагностики баз данных.</p> <p>Компания также анонсировала выход модуля Healthcheck Advisor в одном из ближайших релизов PPEM. Он будет автоматически анализировать состояние экземпляров СУБД на основе собранной телеметрии, выявлять отклонения по ключевым показателям работы баз данных, определять уровень их критичности и формировать рекомендации по дальнейшим действиям.</p> <p>Для каждого обнаруженного отклонения будут доступны сведения о метрике, объекте анализа, нормативном и фактическом значениях, времени срабатывания и рекомендуемых мерах по устранению проблемы. Результаты будут представлены в разделе «Проблемы и рекомендации»: в нём будет размещена сводная информация по управляемым экземплярам, распределение обнаружений по уровням критичности и перечень экземпляров с наибольшим числом выявленных проблем.</p> <p>PPEM Healthcheck Advisor войдёт в базовую поставку платформы и не потребует отдельной установки или лицензирования. Подробная информация об изменениях и инструкции по обновлению до PPEM 2.9 доступны в документации Postgres Pro Enterprise Manager.</p> Компания Postgres Professional объявила о выпуске новой версии платформы для управления и мониторинга баз данных — … message https://www.itweek.ru/themes/detail.php?ID=235475 Mon, 07 Sep 2026 14:41:01 +0300 <p>Число алертов на вредоносную активность в корпоративных сервисах коммуникации за последние 12 месяцев выросло более чем в два раза, выяснили эксперты компании «Информзащита». При этом большинство таких срабатываний относились к фишинговым операциям в чатах. Корпоративные мессенджеры и другие платформы для совместной работы все чаще используются злоумышленниками для атак на учетные записи, доставки вредоносных файлов и развития атаки после первоначального проникновения.</p> <p>Особенности корпоративных коммуникационных сред создают дополнительные возможности для таких атак. В отличие от электронной почты, такие сервисы поддерживают федеративный доступ между организациями, гостевой доступ, общие рабочие пространства и интеграции со сторонними системами. Для бизнеса это упрощает взаимодействие, но одновременно расширяет число доверенных каналов, через которые злоумышленник может обратиться к пользователю.</p> <p>Сообщение, поступившее из корпоративного или знакомого пользователю рабочего пространства, может восприниматься как часть обычного рабочего процесса. Если злоумышленнику удается получить доступ к учетной записи сотрудника, он наследует ее права, связи и историю переписки. Фишинговая ссылка или просьба передать файл в таком случае уже не обязательно выглядит как внешняя атака. Она приходит от сотрудника или аккаунта, который имеет легитимный доступ к нужной среде.</p> <p>Именно поэтому основной объем выявленной активности связан с чат-фишингом. Злоумышленники используют внешние коммуникации и скомпрометированные учетные записи, чтобы инициировать диалог, выдать себя за сотрудника службы поддержки или другого знакомого человека и затем подтолкнуть жертву к определенному действию. Это может быть переход на страницу сбора учетных данных, подтверждение запроса многофакторной аутентификации, установка программного обеспечения удаленного доступа или передача корпоративной информации. В атаках используются прямые сообщения, упоминания в каналах и легитимные уведомления платформ.</p> <p>После получения действующей корпоративной учетной записи атакующий может использовать ее для доступа к облачным сервисам и другим ресурсам с правами скомпрометированного пользователя. При этом традиционные средства контроля часто сосредоточены на событиях аутентификации и электронной почте и могут не иметь достаточной видимости того, что происходит внутри уже установленной и аутентифицированной сессии.</p> <p>Показатель роста алертов более чем в два раза при этом нельзя сводить только к увеличению количества фишинговых сообщений. Меняется сама роль коммуникационных платформ в цепочке атаки. Зафиксированы случаи, когда доверенные сервисы применялись для дальнейшего развития атаки. В декабре 2025 года при расследовании инцидента на производственном предприятии в Польше злоумышленник использовал скомпрометированные сетевые устройства, чтобы получить пароль привилегированной учетной записи, изменить параметры безопасности и отключить двухфакторную аутентификацию. Результаты операций передавались через штатную возможность отправки уведомлений. Легитимная интеграция с сервисом коммуникации стала частью механизма сохранения доступа и вывода данных.</p> <p>Такие сценарии особенно актуальны для организаций, которые активно используют внешние рабочие пространства и интеграции с партнерами. Чем больше у компании гостевых учетных записей, федеративных соединений и сторонних подключений, тем шире пространство для злоупотребления доверенными отношениями. При этом сам факт успешной аутентификации пользователя уже не дает достаточного основания считать последующие действия безопасными. Скомпрометированная учетная запись продолжает выглядеть легитимно, пока система не сопоставит ее действия с контекстом поведения.</p> <p>Для защиты от подобных сценариев контроль коммуникационных платформ следует расширять за пределы обычной проверки входа в систему. Администраторам необходимо регулярно пересматривать федеративный доступ между организациями, гостевой доступ и сторонние интеграции, удаляя ненужные разрешения. Мониторинг должен охватывать события обмена файлами, подключения внешних пользователей и приложений, изменения прав и необычную активность учетных записей, а также неожиданные исходящие обращения к сервисам коммуникации через встроенные интеграции. Проверку ссылок и вложений в сообщениях необходимо настраивать отдельно с учетом возможностей платформы. Дополнительно следует применять устойчивые к фишингу методы аутентификации, например на основе FIDO2, если используемые системы их поддерживают. Использование средств удаленного доступа необходимо ограничивать согласованными инструментами и установленными процедурами технической поддержки.</p> <p>На уровне пользователей особое значение имеет проверка чувствительных запросов через независимый канал. Пароли и одноразовые коды нельзя передавать другим людям, в том числе сотрудникам поддержки. Запрос MFA следует подтверждать только для входа или операции, которые пользователь инициировал самостоятельно. Запросы на установку ПО удаленного доступа, передачу рабочих данных или изменение прав необходимо проверять через заранее известный номер телефона, внутреннюю систему заявок или другой установленный процесс. Сотрудникам также должен быть понятен порядок сообщения о подозрительных обращениях в службу информационной безопасности. Данные мониторинга коммуникационных платформ, сетевых устройств и конечных точек целесообразно сводить в единую систему анализа, чтобы связать подозрительное сообщение с последующими действиями учетной записи и устройства. Порядок реагирования должен предусматривать оперативный отзыв скомпрометированных сессий.</p> <p>Рост числа алертов более чем в два раза показывает, что корпоративные мессенджеры становятся самостоятельной частью поверхности атаки. Для службы информационной безопасности это уже не только каналы рабочих коммуникаций, но и источник событий, по которым можно выявлять компрометацию учетных записей и дальнейшее развитие атаки. При этом 99% алертов, связанных с корпоративными сервисами коммуникации, приходятся на чат-фишинг. Поэтому в защите таких сред приоритетом остается выявление подозрительных сообщений и контроль действий, которые следуют за ними.</p> Число алертов на вредоносную активность в корпоративных сервисах коммуникации за последние 12 месяцев выросло … message https://www.itweek.ru/themes/detail.php?ID=235472 Mon, 07 Sep 2026 10:15:31 +0300 <p><em>Код — это только половина продукта. Вторая половина — ваша способность доказать заказчику, что он безопасен сегодня и останется таким завтра.</em></p> <p>Весной 2026 года вступили в силу обновленные требования ФСТЭК России к защите государственных информационных систем. Регулятор смещает акцент с разового подтверждения безопасности на ее непрерывное обеспечение в течение всего жизненного цикла системы. На первый взгляд это выглядит как очередная регуляторная нагрузка на госсектор. Но на самом деле новые правила бьют по самому больному месту любого коммерческого вендора — его маржинальности.</p> <p>ФСТЭК официально закрепил то, о чем рынок шептался годами: стоимость вашего продукта теперь равна стоимости времени вашей реакции на инцидент. Если поиск уязвимости в сотнях зависимостей занимает дни, ваш продукт для крупного заказчика стоит ноль, каким бы качественным ни был собственный код. Мы привыкли считать, что главная ценность ИТ-компании — талантливые разработчики. Но сегодня этого уже недостаточно. Качественный код остается обязательным условием, однако он перестал быть конкурентным преимуществом. Им становятся инженерные процессы.</p> <h3>Безопасность как производственный процесс</h3> <p>Современное программное обеспечение перестало быть статичным продуктом. Оно постоянно обновляется, интегрируется с внешними сервисами и использует десятки сторонних компонентов. По оценкам Sonatype, до 90% современного софта составляют компоненты с открытым исходным кодом (Open Source). Программный продукт превратился в сложную цепочку поставок, где защищенность зависит не только от собственного кода разработчика, но и от десятков внешних библиотек. Именно поэтому мы больше не можем один раз проверить систему и считать вопрос безопасности закрытым. Доверие определяется зрелостью процессов разработки, сопровождения и обновления.</p> <h3>Что меняется в критериях выбора</h3> <p>Еще несколько лет назад ключевыми преимуществами были функциональность, скорость написания кода и стоимость проекта. Сегодня крупный заказчик оценивает не только то, что умеет продукт, но и то, как компания гарантирует его развитие. Для него вопрос «как создается продукт» становится не менее важным, чем «что он умеет». Зрелость инженерных процессов превращается в решающий фактор доверия: заказчику нужна уверенность в безопасном развитии решения на годы вперед, а не просто зафиксированный набор функций на момент поставки.</p> <h3>Open Source как экзамен для процессов</h3> <p>Открытый код остается фундаментом разработки, однако он же стал главным источником рисков в цепочке поставок ПО. Когда появляется новость об уязвимости нулевого дня, счет идет на часы. Заказчик хочет сразу понять, затронута ли его система, каков риск и когда будет готово исправление. Ответить на эти вопросы за пару часов можно только при выстроенных процессах управления зависимостями (наличии актуального реестра компонентов — SBOM) и регламенте экстренного выпуска патчей. Наличие такого конвейера превращает информационную безопасность из статьи расходов в реальное рыночное преимущество.</p> <h3>Конкуренция инженерной зрелости</h3> <p>Автоматизация проверок, управление зависимостями и скорость выпуска обновлений перестают быть сугубо внутренними инженерными задачами. Они становятся частью рыночной ценности продукта. Инвестиции в выстраивание этих процессов нельзя рассматривать только как выполнение требований регулятора — это вложения в устойчивость бизнеса и капитализацию компании.</p> <p>Мне кажется символичным, что именно требования информационной безопасности подталкивают отрасль к тому, чтобы качество ПО оценивалось не только по функциональности, но и по предсказуемости его развития. Российский рынок переходит от конкуренции продуктов к конкуренции инженерной зрелости. И выигрывать будут компании, которые смогут гарантировать надежное, безопасное и прозрачное сопровождение своего решения на протяжении всего его жизненного цикла.</p> <p> #IMAGE_235473#</p> Код — это только половина продукта. Вторая половина — ваша способность доказать заказчику, что он безопасен … article Ирина Мягкова, заместитель генерального директора по развитию АО НПП РЕЛЭКС https://www.itweek.ru/themes/detail.php?ID=235471 Mon, 07 Sep 2026 10:09:57 +0300 <p><em>Гонка в сфере корпоративного искусственного интеллекта начинает демонстрировать некоторое разделение. Хотя внедрение ИИ продолжает распространяться по организациям, новое исследование McKinsey показывает, что крупные предприятия и небольшая группа высокоэффективных компаний движутся значительно быстрее всех остальных. Результатом может стать начало формирования двухскоростного рынка корпоративного ИИ, сообщает портал </em><em>BigDataWire</em><em>.</em></p> <p>Отчет McKinsey «State of AI in 2026» основан на опросе 1719 участников из 97 стран. Исследование выявило резкие различия во внедрении агентов ИИ.</p> <p>40% респондентов из организаций с годовым доходом более 1 млрд. долл. заявили, что сейчас масштабируют агентов ИИ. Это больше, чем 27% в прошлом году. В небольших организациях этот показатель составляет всего 22% и не увеличился по сравнению с прошлым годом.</p> <p>Аналогичное разделение наблюдается и в отношении агентов для кодирования. В целом около 20% организаций масштабируют эту технологию, по сравнению с 31% крупных предприятий. Но более интересным изменением может стать то, как компании используют эти инструменты.</p> <h3>ИИ начинает менять дилемму «разрабатывать или покупать»</h3> <p>Почти треть респондентов (32%) заявили, что их организация отказалась от покупки хотя бы одного программного продукта или функции, поскольку могла бы разработать функциональность внутри компании, используя инструменты агентного кодирования.</p> <p>Это значительное событие для рынка корпоративных технологий, построенного вокруг компаний, покупающих специализированное ПО для решения специализированных задач.</p> <p>ИИ-агенты кодирования потенциально меняют ситуацию, снижая затраты и время, необходимые для разработки ПО внутри компании. Это не означает, что предприятия внезапно заменят Salesforce, SAP или другие основные платформы ПО, созданным агентами ИИ. Разработка функции внутри компании и замена крупного корпоративного приложения — это совершенно разные вещи.</p> <p>Но результаты исследования McKinsey показывают, что ИИ начинает влиять на решения о покупке технологий, а не просто становится еще одной статьей технологического бюджета. И организации, получающие наибольшую выгоду от ИИ, похоже, движутся в этом направлении.</p> <p>McKinsey классифицирует только 6% респондентов как высокоэффективных пользователей ИИ. Это означает, что они относят не менее 5% прибыли до вычета процентов и налогов (EBIT) к ИИ и описывают его влияние как значительное. Эта доля не увеличилась по сравнению с прошлым годом. Зато стало яснее, насколько по-разному компании подходят к ИИ.</p> <p>Успешные компании внедряют более широкий спектр технологий ИИ и чаще используют ИИ для роста и инноваций, а не для повышения эффективности. Они также в 3,3 раза чаще, чем другие организации, заявляют о намерении коренным образом трансформировать свой бизнес с помощью ИИ в течение следующих трех лет.</p> <h3>Все остальные по-прежнему ищут окупаемости инвестиций</h3> <p>Обнаруженный разрыв имеет значение, потому что финансовое влияние корпоративного ИИ в целом остается на удивление неизменным.</p> <p>Только 37% респондентов заявили, что ИИ внес положительный вклад в EBIT их организации, их доля практически не изменилась по сравнению с <nobr>2025-м.</nobr> Это резко контрастирует с тем, что сообщают сами работники. Четверо из пяти (80%) заявили, что ИИ повысил их индивидуальную производительность, а 50% сказали, что он помогает им принимать более обоснованные решения.</p> <p>Таким образом, у корпоративного ИИ есть необычная проблема. Компании, похоже, накопили множество доказательств того, что технология может повысить производительность отдельных сотрудников, но им гораздо сложнее превратить эти достижения в измеримые улучшения финансовых показателей компании в целом.</p> <p>Экономические факторы также становится все труднее игнорировать. Каждый пятый респондент заявил, что операционные расходы, связанные с ИИ, включая затраты на токены, ограничивают использование ИИ. Тем не менее, большинство организаций по-прежнему ожидают увеличения своих инвестиций в ИИ в течение следующего года. Это означает, что требование демонстрации отдачи, вероятно, будет расти по мере того, как внедрение будет становиться все более масштабным и дорогостоящим.</p> <h3>Одного масштаба может быть недостаточно</h3> <p>У крупнейших компаний есть очевидное преимущество. У них больше денег, которые они могут потратить на модели, инфраструктуру, обработку данных и организационные изменения, необходимые для внедрения ИИ в сложные рабочие процессы. Но результаты исследования McKinsey показывают, что одних только затрат и масштаба недостаточно.</p> <p>Даже по мере расширения внедрения ИИ доля компаний, генерирующих значительную финансовую ценность, остается на уровне 6%. Организации, начинающие выделяться, похоже, делают нечто более фундаментальное: перестраивают способы выполнения работы с использованием ИИ, а не просто добавляют инструменты ИИ к существующим процессам.</p> <p>Это различие станет еще более важным, когда агенты выйдут за рамки просто ответов на вопросы и начнут писать ПО, получать доступ к корпоративным данным и действовать в рамках бизнес-процессов. Поэтому следующий этап развития корпоративного ИИ может быть связан не столько с тем, <em>кто</em> внедряет ИИ, сколько с тем, <em>что</em> происходит после этого. В гонку вступают почти все. Но отрываться начинает гораздо меньшая группа.</p> Гонка в сфере корпоративного искусственного интеллекта начинает демонстрировать некоторое разделение. Хотя внедрение ИИ … article https://www.itweek.ru/themes/detail.php?ID=235469 Fri, 04 Sep 2026 13:57:21 +0300 <p>Искусственный интеллект из самостоятельного направления разработок превращается в сквозной инструмент исследований, технологического развития и трансформации экономики. Этот переход отчетливо прослеживается в стратегических документах Китая и Республики Корея на <nobr>2026–2030 гг.</nobr> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как эти страны адаптируют научно-технологическую политику к новой роли ИИ.</p> <p>Справочно: анализ охватывает Шестой базовый план развития науки и технологий Республики Корея (июнь 2026), Основные положения <nobr>15-го</nobr> пятилетнего плана социально-экономического развития КНР (март 2026) и Мнения Госсовета КНР об углубленной реализации инициативы «ИИ+» (август 2025).</p> <p>В обеих странах ИИ-трансформация выходит далеко за пределы научного сектора. В Китае акцент переносится с «гонки моделей» на массовую диффузию ИИ и создание новых сценариев его применения. В Южной Корее ИИ-трансформация наряду с научной системой охватывает промышленность и региональные кластеры.</p> <p>ИИ-трансформация науки опирается на национальную вычислительную инфраструктуру. Китай развивает интегрированную сеть суперкомпьютеров, центров интеллектуальных вычислений и облачных платформ; Республика Корея планирует сформировать к 2030 г. государственно-частный пул из 260 тыс. GPU.</p> <p>Китайский план ориентирован на полный цикл — от исследований до ускоренной коммерциализации. Один из новых фронтиров — физический ИИ: развитие сред для обучения роботизированных систем и разработка гуманоидных роботов. Параллельно создаются институты отраслей будущего, центры проверки концепций, механизмы разделения инвестиционных рисков и регуляторные песочницы.</p> <p>В Республике Корея ИИ встраивают непосредственно в исследовательский процесс: план предусматривает развитие ИИ-соисследователей (AI Co-Scientist), автономных лабораторий и междисциплинарных проектов с применением ИИ. Масштабная технологическая трансформация сопровождается институциональной реформой науки, включающей переход к более долгосрочному и предсказуемому финансированию исследований, а также снижение административной нагрузки.</p> <p>В совокупности опыт двух стран показывает, что комплексная ИИ-трансформация науки требует не отдельной программы поддержки ИИ, а согласованного изменения всей исследовательской среды. Наибольший интерес представляет сочетание вычислительной инфраструктуры и широкого доступа к ее ресурсам, внедрения ИИ непосредственно в исследовательский процесс, долгосрочных механизмов финансирования науки и инструментов, ускоряющих переход от исследований к практическому применению.</p> Искусственный интеллект из самостоятельного направления разработок превращается в сквозной инструмент исследований … message https://www.itweek.ru/themes/detail.php?ID=235468 Fri, 04 Sep 2026 13:53:18 +0300 <p>MWS Cloud, входящая в МТС Web Services, развернула передовую модель GLM-5.3 в собственной облачной инфраструктуре. Она доступна в сервисе MWS GPT Model Hub и полностью локализована на территории России: данные пользователей и запросы к ней не покидают страну. Стоимость останется на уровне GLM-5.2.</p> <p>Развертывание GLM-5.3 в облаке MWS Cloud позволяет российским компаниям использовать модель для разработки программного обеспечения и решения агентских задач в российском ИТ-контуре. Среди возможных сценариев — генерация и анализ кода, поиск ошибок, работа с репозиториями, автоматизация многоэтапных процессов и создание ИИ-агентов.</p> <p>GLM-5.3 разработана китайской компанией Z.ai и опубликована с открытыми весами. По данным разработчика, модель использует ту же базовую архитектуру, что и GLM-5.2, а прирост качества получен за счет масштабирования посттренинга. Модель ориентирована на сложные задачи программирования и длительные последовательности действий с использованием инструментов. Z.ai опубликовала веса через две недели после запуска модели — это время разработчик отвел на дополнительную оценку и усиление мер безопасности.</p> <p>Локальное размещение модели в инфраструктуре MWS Cloud дает компаниям возможность работать с GLM-5.3 без передачи запросов и обрабатываемых данных за пределы России. Вычисления выполняются в облаке MWS Cloud на территории страны.</p> <p>По данным Z.ai и независимым оценкам, GLM-5.3 выступает на уровне передовых закрытых моделей. В задачах программирования она стабильно опережает Claude Opus 4.8 и сопоставима с новейшими Claude Fable 5 и GPT-5.6 Sol, лишь немного уступая им в самых сложных тестах. Сильнее всего модель проявляет себя в длительных агентских сценариях: здесь она в большинстве тестов не уступает закрытым моделям, а в части из них выходит вперед. В пользовательском рейтинге Text Arena модель идет практически вровень с лидером, а по качеству создания веб-интерфейсов входит в число лучших. В краудсорсинговом рейтинге Design Arena, где реальные пользователи сравнивают модели по качеству дизайна, GLM-5.3 входит в тройку лучших в общем зачете, заметно поднявшись относительно предыдущей версии, и занимает второе место среди моделей с открытыми весами.</p> MWS Cloud, входящая в МТС Web Services, развернула передовую модель GLM-5.3 в собственной облачной инфраструктуре. Она … message https://www.itweek.ru/themes/detail.php?ID=235463 Fri, 04 Sep 2026 11:01:36 +0300 <p><em>Матар Пелеш, инженер по разработке решений компании Port, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как агенты искусственного интеллекта функционируют в качестве потребителей, внутренних компонентов и управляемых ресурсов на современных платформах для разработчиков.</em></p> <p>Инженерные организации стараются работать настолько быстро, насколько позволяют технологии, внедряя агентный ИИ в свои платформы для разработчиков и разрабатывая способы использования ИИ-агентов для максимизации производительности инженеров.</p> <p>Но когда речь заходит об агентной платформе для разработчиков, каждая команда, с которой мы общаемся, видит роль этих агентов немного по-разному. После сотен обсуждений мы определили три типа ролей.</p> <h3>Роль 1: ИИ-агенты как потребители платформы</h3> <p>В этой роли агент, по сути, является пользователем платформы. Он использует платформу в рамках своей задачи по чтению контекста и выполнению действий. Когда агенты впервые появились, многие компании заявили, что относятся к ним как к сотрудникам, а в платформе разработки агент становится просто еще одним инженерным ресурсом, использующим ее.</p> <p>#IMAGE_235465#</p> <p>Типичный пример: инженер просит Claude Code добавить конечную точку в платежный сервис. Прежде чем начать писать какой-либо код, агент получает от платформы информацию о владельце сервиса, зависимостях и стандартах, которым он должен соответствовать, затем запускает среду предварительного просмотра с помощью действия самообслуживания и выполняет тесты.</p> <p>Для корректной работы агенту необходимо проанализировать реальную, актуальную информацию о ваших системах, начиная с каталога услуг и заканчивая владельцами, зависимостями, стандартами и текущим состоянием. Если контекст неверен, высока вероятность того, что агент станет слишком самоуверенным и допустит ошибку. Большинство команд решают эту проблему, предоставляя локальный контекст отдельно для каждого агента. Из-за этого эта информация оказывается связана с агентами ненадежным образом, не говоря уже о том, что ни один из них не управляется. Сравните это с озером контекста, которое предоставляет каждому агенту единый управляемый источник достоверной информации. Платформа также должна быть доступна для работы агента, что означает ориентацию на API и MCP.</p> <p>Что требуется от платформы? Интерфейс, ориентированный на API и MCP, управляемый контекстный слой, из которого агент считывает данные, и набор действий самообслуживания, которые он может вызывать.</p> <h3>Роль 2: ИИ-агенты как внутренние компоненты платформы</h3> <p>Платформы, способные регистрировать агентов и запускать их в рамках рабочих процессов, используют агентов как часть полноценного бизнес-процесса. Агент работает внутри платформы, запускается событием, а не запрашивается человеком, и находится в механизме оркестровки рядом с детерминированными шагами.</p> <p>#IMAGE_235466#</p> <p>Возьмем запуск ежевечерней проверки, которая выявляет уязвимые зависимости в 40 сервисах. Платформа извлекает средство исправления из реестра и запускает его один раз для каждой службы, так что каждая команда владельцев получает доступ к открытому запросу на слияние (PR), ожидающему проверки.</p> <p>Что требуется от платформы? Уровень оркестровки для запуска агентов, реестр для выбора нужного агента, идентификационный номер для каждого агента, чтобы действие регистрировалось для конкретного агента, а не для заимствованных учетных данных человека, и этап с участием человека, где риск значителен.</p> <h3>Роль 3: ИИ как ресурс со своим собственным жизненным циклом (также известно как AgenticOps)</h3> <p>В этой роли агент является таким же ресурсом, как и LLM, серверы MCP и навыки, которые с этим связаны. Платформа предоставляет их, управляет ими и возвращает обратно, точно так же, как это происходит с сервисом, базой данных или средой.</p> <p>#IMAGE_235467#</p> <p>Например, предположим, инженеру нужен дежурный агент для сортировки обращений. Он выбирает модель, инструменты и среду выполнения либо через форму, либо описывая свои потребности, и платформа предоставляет все необходимое, подобно торговому автомату, включая хорошо управляемого агента, соответствующего необходимым стандартам.</p> <p>Это создает проблему «золотого пути». «Золотой путь» — это маршрут, который по умолчанию обеспечивает команде доступ к ресурсу правильным образом, и он нужен для жизненного цикла агента: запрос, получение и регистрация, а затем публикация для следующей команды. Это также то, чем чаще всего интересуются организации: реестр агентов и навыков был востребован 47% организаций, с которыми мы общались.</p> <p>Что требуется от платформы? Путь самообслуживания, который обеспечивает среду выполнения, выдает идентификационные и ограниченные учетные данные, подключает утвержденный контекст и регистрирует агента на выходе, а также маршрут для публикации для следующей команды.</p> <h3>Краткое описание трех ролей</h3> <table> <thead> <tr> <td> <p><strong>Роль</strong></p> </td> <td> <p><strong>Что агент собой представляет </strong></p> </td> <td> <p><strong>Пример</strong></p> </td> <td> <p><strong>Что требуется от платформы</strong></p> </td> </tr> </thead> <tbody> <tr> <td> <p><strong>Роль 1: ИИ-агенты как потребители платформы</strong></p> </td> <td> <p>Пользователь платформы, считывающий контекст и выполняющий действия в рамках своей задачи</p> </td> <td> <p>Claude Code определяет владельца сервиса, зависимости и стандарты, затем запускает среду предварительного просмотра и запускает тесты</p> </td> <td> <p>Управляемый контекстный слой, например, озеро контекста, и действия самообслуживания, которые он может вызывать</p> </td> </tr> <tr> <td> <p><strong>Роль 2: ИИ-агенты как внутренние компоненты платформы</strong></p> </td> <td> <p>Шаг в рабочем процессе, запускаемый событием, а не по запросу пользователя</p> </td> <td> <p>Ежевечернее сканирование выявляет уязвимую зависимость в 40 службах, и агент исправления открывает PR для каждой из них</p> </td> <td> <p>Слой оркестрации для запуска агентов, реестр для получения нужных данных, идентификация агентов и человек, вовлеченный в процесс там, где риск реален</p> </td> </tr> <tr> <td> <p><strong>Роль 3: ИИ как многоразовые строительные блоки (AgenticOps)</strong></p> </td> <td> <p>Ресурс, который платформа предоставляет, управляет им и возвращает обратно</p> </td> <td> <p>Инженер запрашивает агента сортировки по вызову, выбирает модель и инструменты и возвращает уже зарегистрированными</p> </td> <td> <p>Путь самообслуживания, который обеспечивает среду выполнения, выдает идентификатор и ограниченные учетные данные, подключается в утвержденном контексте и регистрирует агента</p> </td> </tr> </tbody> </table> <h3>Иногда эти три роли оказываются связанными</h3> <p>Интересный случай с цепочкой ролей. Инженер запрашивает агента сортировки в роли 3; тот добавляется в реестр агентов как часть рабочего процесса создания, а неделю спустя рабочий процесс инцидента вызывает его как компонент (роль 2). Когда агент запускается, он считывает данные о владельце службы и последних развертываниях из того же контекстного хранилища, реализуя роль 1. Это один и тот же агент, которого вы видите в разных ролях.</p> <h3>Как может выглядеть платформа, охватывающая все три роли</h3> <p>Агент может использовать платформу в качестве пользователя через учетную запись службы, читая контекстное озеро и выполняя действия самообслуживания. Агенты работают в рамках рабочих процессов платформы как часть бизнес-процесса. Кроме того, AgenticOps работает в режиме самообслуживания, поэтому команда может запросить агента и получить уже зарегистрированного. Все три роли находятся в одном каталоге, в одном контексте и в одном журнале аудита.</p> Матар Пелеш, инженер по разработке решений компании Port, рассказывает на портале The New Stack о том, как агенты … article https://www.itweek.ru/themes/detail.php?ID=235461 Fri, 04 Sep 2026 09:52:39 +0300 <p>В операционном управлении — будь то производство, логистика, ритейл или сфера услуг — внедрение систем бизнес-аналитики давно перестало быть просто модным трендом. Это базовый стандарт конкурентоспособности. При этом многие компании совершают одну и ту же стратегическую ошибку: заказывают ИТ-подрядчикам «красивые панели показателей в реальном времени» и получают на выходе плоский список из десятков разрозненных цифр. Это создает иллюзию контроля, но на деле лишь нагружает руководителя информационным шумом.</p> <p>Как ИТ-эксперт, сопровождающий цифровую трансформацию, я предлагаю компаниям сместить фокус. В управления важны не сами по себе показатели. Главное — возможность иметь динамическую иерархическую отчетность. Руководителю жизненно необходимо за секунды переходить от показателей верхнего уровня к нижнему, сравнивать любые периоды между собой и делать это непосредственно в любой момент времени.</p> <p>Все всегда начинается с финансов. Но аналитическая система должна жестко ассоциировать финансовые результаты с физическими, так называемыми натуральными показателями. Финансы — это всегда запаздывающий индикатор, результат уже свершившихся событий. Чтобы управлять бизнесом, мы должны привязать деньги к количеству выпущенной продукции, отработанным сменам, объему потраченных материалов или скорости движения запасов на складах.</p> <p>В любом бизнесе существует <nobr>3-5</nobr> ключевых физических метрик, которые характеризуют его «биение сердца». Они обычно хорошо известны грамотному руководителю. Вокруг них строится семейство зависимых показателей. Вот универсальный перечень таких натуральных метрик и обоснование их выбора:</p> <ul> <li><strong>Выработка на единицу трудозатрат (человеко-часов). </strong>Обоснование: напрямую связывает фонд оплаты труда с физическим объемом работы. Позволяет увидеть не просто рост затрат на персонал, а падение реальной эффективности конкретных смен или участков.</li> <li><strong>Процент отклонений от стандарта (брак, переделки, ошибки). </strong>Обоснование: главный индикатор качества процессов. Рост этого показателя мгновенно объясняет рост себестоимости без необходимости глубокого финансового аудита.</li> <li><strong>Время простоя оборудования или логистических узлов. </strong>Обоснование: натуральная метрика, которая конвертируется в упущенную выручку и сверхурочные выплаты. Показывает реальную загрузку мощностей и узкие места.</li> <li><strong>Расход материалов или энергии на единицу продукции. </strong>Обоснование: позволяет отследить скрытые потери. Если деньги растут, а физический расход на единицу стабилен — проблема в ценах поставщиков. Если растет физический расход — проблема в технологии или персонале.</li> </ul> <h3>Показательный кейс: как это работает на практике</h3> <p>Представим производственную или торговую компанию. Во вторник утром генеральный директор видит, что операционная прибыль за вчера просела относительно плана на 8%.</p> <p>В «плоской» системе: директор звонит финдиректору и просит «поднять цифры». Через два дня приходит сводная таблица, из которой следует, что выросла себестоимость. Еще день уходит на запрос объяснительных от начальников. Время упущено, убыток закреплен.</p> <p>В иерархической системе: директор нажимает на просевший показатель прибыли на Экране № 1. Система мгновенно показывает, что драйвером стал рост затрат на конкретном участке. Он переходит на уровень ниже (Экран № 2) и видит: финансовый рост вызван натуральным показателем «процент отклонений», который резко подскочил в предыдущую смену. Переходя к еще большей детализации (Экран № 3), он видит прямую корреляцию: пик брака совпал с выходом новой бригады и партией сырья от нового поставщика.</p> <p>Итог: руководитель не ждет еженедельного совещания. Он прямо между встречами звонит начальнику производства, корректирует процесс и изолирует бракованную партию. На планерке вопрос уже закрыт.</p> <h3>Как руководителю читать и анализировать данные</h3> <p>Самое главное требование к системе: она должна позволять на одном, двух или трех экранах динамически отслеживать причинно-следственные связи.</p> <ul> <li><strong>Экран «Капитанский мостик»</strong><strong> (стратегический).</strong> Здесь только финансовые итоги и <nobr>3-5</nobr> главных натуральных индикаторов. Руководитель смотрит сюда каждое утро. Цель: увидеть отклонение от плана и сравнение с прошлыми периодами.</li> <li><strong>Экран «Операционный разрез» (тактический).</strong> Сюда руководитель переходит по клику, если видит «красную зону». Здесь детализация по блокам: производство, склад, логистика.</li> <li><strong>Экран «Контекст и связи» (аналитический).</strong> Возможность наложить любые показатели друг на друга. Например, сопоставить график «количества отработанных человеко-часов» с графиком «объема выпуска». Если линии расходятся, вы сразу видите неэффективность использования ресурсов без необходимости сводить сложные таблицы.</li> </ul> <h3>Конец эры «давайте запросим статистику»</h3> <p>Главная ценность такого подхода к аналитике в реальном времени заключается в фундаментальном изменении культуры управления.</p> <p>Раньше на регулярных совещаниях руководителей часто звучала фраза: «Давайте после встречи запросим статистику по этой гипотезе». Это убивало динамику и скорость реакции. </p> <p>Когда выстроена правильная иерархическая система, связывающая рубли с натуральными показателями (штуками, часами, килограммами), любые гипотезы проверяются прямо на экране за полминуты. Это позволяет управленцам быстро находить корневые причины проблем, назначать ответственных и действовать на опережение. Чтобы на регулярных совещаниях никогда не стоял вопрос о необходимости «запросить цифры», а любой вопрос мог быть проверен сразу же, на экране нашей системы. Именно это дает реальную власть над операционной деятельностью.</p> <p>#IMAGE_235462#</p> В операционном управлении — будь то производство, логистика, ритейл или сфера услуг — внедрение систем … article Сергей Капарис, управляющий партнер Umbrella Consulting Group https://www.itweek.ru/themes/detail.php?ID=235458 Thu, 03 Sep 2026 15:43:37 +0300 <p>«Базис» выпустила новую версию Basis Workplace, флагманской платформы для управления инфраструктурой виртуальных рабочих столов (VDI). Ключевыми изменениями релиза 3.4 стали возможность работы с несколькими инсталляциями с одного рабочего места, поддержка виртуализации приложений и нативный инструмент миграции с Basis Workplace второго поколения. Помимо этого, в релизе был расширен инструментарий управления пулами и виртуальными рабочими местами, добавлены новые сценарии развертывания и средства управления сертификатами, а также обновлен протокол Basis Connect.</p> <p>В Basis Workplace 3.4 администраторы получили возможность определять набор приложений, которые автоматически устанавливаются на виртуальные рабочие места (ВРМ) пользователей. Настройки применяются централизованно для пулов, что исключает ручную установку на каждом ВРМ, снижает нагрузку на поддержку и гарантирует единообразное рабочее окружение для сотрудников. Гибкие политики позволяют контролировать, каким сотрудникам какие приложения доступны, а пользователь получает готовую, полностью оснащенную среду с первого же сеанса — без ожидания и запросов в техподдержку.</p> <p>В новом релизе добавлен режим мультиклиента, который позволяет администраторам одновременно работать в нескольких инсталляциях Basis Workplace с одного рабочего места. Единая точка администрирования упрощает обслуживание <nobr>VDI-инфраструктуры,</nobr> расположенной в разных ЦОДах, филиалах, контурах и т.д., а также позволяет быстро переключаться между средами и ускоряет реакцию на инциденты.</p> <p>В персонализированных пулах — логических объединениях виртуальных рабочих столов, использующих общие ресурсы и настройки — стало доступно использование персональных дисков пользователей, а также перемещение дисков между пулами. В случае изменения индивидуального шаблона, с использованием которого создавался персонализированный пул, реализованный механизм рекомпозиции позволяет пересобирать виртуальные машины этого пула.</p> <p>Клиентскую часть Basis Workplace теперь можно устанавливать отдельно от протоколов доставки, в том числе для включения в дистрибутив заказчика. На одну виртуальную машину допускается последовательная установка нескольких дополнительных сервисов, а брокер сообщений NATS можно развернуть как отдельный сервис, объединив три его экземпляра в кластер. Все перечисленное позволяет администратору учесть потребности и особенности создаваемой <nobr>VDI-инфраструктуры</nobr> уже на этапе инсталляции Basis Workplace.</p> <p>Basis Workplace позволяет загружать серверный сертификат заказчика непосредственно на этапе инсталляции, а для SSL-запросов в новой версии был реализован переход на системное хранилище сертификатов операционной системы.</p> <p>Для заказчиков, использующих Basis Workplace 2.6.4 и планирующих переход на версию платформы 3.4 создан новый инструмент миграции пулов. Он переносит объекты и их настройки, поддерживает миграцию сессионных, персональных и терминальных пулов. Для персональных пулов предусмотрена возможность отката миграции.</p> <p>В собственном протоколе доставки Basis Connect появилось управление направлением проброса буфера обмена. Теперь администратор может включать и выключать передачу файлов, текста и изображений через буфер; обмен данными можно разрешить только с пользовательского устройства на сервер, только в обратную сторону или в обе стороны одновременно. В окне протокола также добавлен графический интерфейс с подробными сведениями о доступных USB-устройствах, смарт-картах, токенах, принтерах и других.</p> <p>Список поддерживаемого платформой Basis Workplace ПО пополнили операционные системы Windows 11 и «Альт» 11 в качестве гостевых и клиентских ОС, а также платформа виртуализации VMware vCenter Server 6.7u3.</p> <p>В версии платформы 3.4 появились новые инструменты создания отчетности по запуску приложений и подключениям к терминальным пулам. Теперь администратор может получать списки уникальных пользователей и устройств доступа, а также вручную выгружать эти данные. Все это обеспечивает прозрачность использования опубликованных ресурсов и помогает эффективнее управлять инфраструктурой.</p> <p>«Basis Workplace развивается как самодостаточная платформа, закрывающая все больше сценариев работы с <nobr>VDI-инфраструктурой</nobr> внутри одного продукта. Виртуализация отдельных приложений стала ключевым новшеством релиза. Она позволяет централизованно и быстро обеспечивать сотрудников доступом к необходимым корпоративным приложениям. Отдельно в новом релизе мне бы хотелось отметить появление инструментов для миграции с Basis Workplace второго поколения — функциональной и надежной, но уже архитектурно устаревшей версии нашей платформы», — прокомментировал Дмитрий Сорокин, технический директор «Базис».</p> «Базис» выпустила новую версию Basis Workplace, флагманской платформы для управления инфраструктурой виртуальных рабочих столов … message https://www.itweek.ru/themes/detail.php?ID=235457 Thu, 03 Sep 2026 15:41:48 +0300 <p>Российский облачный рынок проходит через структурную трансформацию, сравнимую по масштабу с переходом от физических серверов к виртуализации. Наряду с классической моделью IaaS — аренда виртуальных машин, дискового пространства и сетевых ресурсов — будет расти спрос на AI-IaaS: инфраструктуру как сервис, предназначенную для обучения, дообучения и эксплуатации моделей искусственного интеллекта. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что в традиционном облаке объектом выступают виртуальные машины, контейнеры и хранилища, а в AI-IaaS к ним добавляются поведение модели, происхождение данных, промпты, векторные индексы, GPU-кластеры и действия подключенных инструментов.</p> <p>По оценкам аналитиков M1Cloud, прогноз роста облачного рынка до 2030 года предполагает среднегодовой темп <nobr>25-32%</nobr> с учетом миграции нагрузок из зарубежных платформ и расширения ИИ-проектов в госсекторе, финансах, промышленности и телекоме.</p> <p>Трансформация российского облачного рынка определяется не только технологической логикой, но и регуляторными ограничениями. Требования локализации данных, ограничение трансграничной передачи, необходимость использования инфраструктуры российских провайдеров и доказательного соответствия нормативным актам создают уникальный контур, в котором AI-IaaS становится не опцией, а условием продолжения цифровизации. Для суверенного ИИ критичны локализация вычислений, география GPU, логирование и воспроизводимость цикла и не менее важны, чем производительность.</p> <p>В 2026 году доля AI-IaaS в общем объеме российского облачного рынка оценивается в <nobr>12-15%,</nobr> что соответствует <nobr>18-22</nobr> млрд рублей. Ключевым драйвером выступают пилотные GPU-кластеры и первые промышленные инференс-нагрузки крупных языковых моделей. Заказчики тестируют сценарии RAG (генерация с дополненным поиском), чат-ботов и автоматизации документооборота, но объемы пока ограничены экспериментальными бюджетами.</p> <p>К 2027 году доля AI-IaaS вырастет до <nobr>22-27%,</nobr> а абсолютный объем достигнет <nobr>38-48</nobr> млрд рублей. На этом этапе произойдет переход от пилотов к промышленной эксплуатации: банки, страховые компании и государственные структуры запустят продуктивные RAG-контуры и внутренние ассистенты. Спрос сместится от аренды «сырых» GPU к управляемым сервисам с встроенной фильтрацией промптов, журналированием и контролем цепочки данных.</p> <p>В 2028 году ожидается рост доли до <nobr>33-38%</nobr> и объема до <nobr>62-78</nobr> млрд рублей. Массовое дообучение моделей на корпоративных данных станет стандартом. AI Firewall и контроль цепочки поставки модели превратятся из конкурентного преимущества в обязательное требование. Регулятор, вероятно, утвердит отраслевые стандарты безопасности для ИИ-инфраструктуры, аналогичные требованиям к КИИ.</p> <p>К 2029 году доля AI-IaaS достигнет <nobr>42-48%,</nobr> объем — <nobr>95-115</nobr> млрд рублей. Доминирующим сценарием станут мультиагентные системы и автономные бизнес-процессы, в которых модель не просто отвечает на запрос, а инициирует действия в CRM, ERP и платежных контурах. Это увеличит требования к разграничению прав инструментов и непрерывному мониторингу дрейфа.</p> <p>Наконец, к 2030 году более половины инфраструктурных расходов российских компаний, использующих облака, будет приходиться на ИИ-нагрузки: инференс, дообучение, хранение векторных баз, оркестрацию GPU-заданий и обеспечение безопасности цепочки принятия решений модели. Обучение крупных моделей с нуля остается нишевым из-за стоимости и ограничений на поставки передовых ускорителей. Прогнозируемая доля — <nobr>50-55%,</nobr> абсолютный объем — <nobr>130-160</nobr> млрд рублей. AI-IaaS станет базовым слоем корпоративной ИТ-архитектуры, а не надстройкой над классическим облаком.</p> <p>Ускоренный сценарий роста сегмента AI-IaaS реализуется при государственных программах субсидирования и обязательном внедрении ИИ в госуслуги и КИИ. Рост может достичь <nobr>35-40%</nobr> в год, к 2030 году AI-IaaS займет более 60% облачных расходов. Сформируются отраслевые ИИ-платформы с жесткой изоляцией.</p> <p>С другой стороны, сдержанный сценарий наступит при дефиците GPU, ужесточении экспортных ограничений и замедлении корпоративных бюджетов. Рост ограничится <nobr>18-22%</nobr> в год, и к 2030 году доля AI-IaaS не превысит <nobr>35-40%,</nobr> значительная часть нагрузок остается в on-premise.</p> <p>К 2030 году российский облачный рынок завершит переход от парадигмы «аренда серверов» к парадигме «управление цепочкой принятия решений модели». Для российских компаний и провайдеров окно стратегического маневра открыто в <nobr>2026–2028 годах,</nobr> после чего архитектура рынка будет определяться теми, кто первым встроил безопасность, суверенитет и наблюдаемость в архитектуру ИИ-инфраструктуры.</p> Российский облачный рынок проходит через структурную трансформацию, сравнимую по масштабу с переходом … message https://www.itweek.ru/themes/detail.php?ID=235455 Thu, 03 Sep 2026 15:40:39 +0300 <p>Эксперты компании «Информзащита» выявили, что в 2026 году средства удаленного доступа использовались в 62% киберинцидентов, не связанных с компрометацией деловой электронной почты. В 2025 году их доля составляла 49%, за год показатель вырос на 13 п. п. В эту категорию входят атаки через RDP, VPN и системы удаленного мониторинга и управления RMM.</p> <p>Причина такой динамики связана прежде всего с тем, что удаленный доступ изначально предполагает возможность подключения к корпоративной инфраструктуре извне. VPN-шлюзы, серверы RDP и RMM-платформы используются администраторами, подрядчиками, технической поддержкой и сотрудниками филиалов, поэтому полностью убрать их из внешнего контура во многих компаниях невозможно. Для атакующего такой сервис представляет удобную точку входа. При наличии действующей учетной записи или возможности обойти механизм аутентификации ему не требуется доставлять сложное вредоносное ПО на рабочую станцию пользователя. Активность может начинаться с обычного подключения к легитимному сервису и внешне выглядеть как действия штатного специалиста.</p> <p>Пароли от VPN, RDP и административных систем попадают в руки злоумышленников после фишинговых кампаний, заражений инфостилерами, утечек из сторонних сервисов и компрометации подрядчиков. Риск возрастает там, где для удаленного подключения не используется MFA, разрешена парольная аутентификация без дополнительных факторов, учетные записи годами сохраняют избыточные права, а доступ открыт для широкого диапазона внешних адресов. Отдельная проблема связана с сервисными и техническими учетными записями. Они реже используются людьми в повседневной работе, поэтому смена паролей и пересмотр привилегий для них нередко откладываются. При этом именно такие записи могут давать расширенный доступ к инфраструктуре.</p> <p>Разбивка по основным векторам первоначального проникновения показывает, что удаленный доступ заметно опережает эксплуатацию программных уязвимостей. На RDP, VPN, RMM и другие внешние средства удаленного подключения приходится 65% инцидентов вне BEC. Еще 11% связаны с эксплуатацией известных уязвимостей, причем в рассмотренных случаях исправления для них уже существовали. Годом ранее доля этого вектора достигала 29%. Еще 8% пришлось на ошибки конфигурации и злоупотребление доверенными связями, хотя ранее их совокупная доля не превышала 1%. Оставшиеся около 16% распределяются между другими сценариями первоначального доступа, включая загрузку вредоносного ПО, социальную инженерию и менее распространенные способы компрометации. Получается, что злоумышленники все чаще выбирают сценарии, в которых можно использовать уже существующую инфраструктуру доступа и доверия, вместо разработки отдельного эксплойта.</p> <p>Рост доли удаленного доступа объясняется и архитектурой корпоративных сетей. Пограничные устройства часто совмещают несколько функций и обладают высокими привилегиями. Компрометация VPN-шлюза, RMM-сервера или системы администрирования может сразу дать атакующему возможность работать с несколькими сегментами сети. После входа начинается сбор информации об инфраструктуре, поиск доменных учетных записей, повышение привилегий и горизонтальное перемещение. Скорость такого сценария заметно выше, когда удаленный сервис уже интегрирован с Active Directory, имеет доверительные отношения с другими системами или позволяет запускать команды на множестве рабочих станций. В расследованиях фиксировались случаи, когда после первоначального доступа злоумышленники переходили к контролю доменной инфраструктуры за считанные минуты.</p> <p>Наиболее заметные риски формируются в отраслях, где удаленное администрирование используется постоянно и охватывает большое число систем. В здравоохранении показатель составил 33%, в образовании — 25%. Эти значения нельзя напрямую приравнивать к доле атак через RDP, VPN или RMM из статистики расследований, поскольку использовалась другая методика, однако отраслевой разрез показывает, где проблемы с безопасностью удаленного доступа проявляются особенно часто. Для технологических и сервисных компаний риск связан с большим числом административных подключений и клиентских сред, для промышленности — с сочетанием удаленного обслуживания и устаревающей инфраструктуры, а для здравоохранения и образования — с большим числом разнородных систем и ограниченными возможностями быстро менять их конфигурацию.</p> <p>Отдельное внимание требуется RMM-платформам. Такие системы создавались именно для централизованного управления парком устройств, поэтому их функции совпадают с тем, что нужно атакующему после проникновения. Через легитимный агент можно запускать команды, устанавливать программное обеспечение, передавать файлы и управлять удаленной машиной. Это осложняет детектирование, поскольку сам факт запуска RMM-клиента не является признаком атаки. Аналогичная проблема возникает с VPN. Успешная аутентификация с корректными учетными данными может не вызвать срабатывания средств защиты, хотя подключение выполняется злоумышленником. Поэтому контроль только вредоносных файлов и сигнатур сетевых атак не закрывает этот сценарий.</p> <p>Снижать риск необходимо одновременно на уровне идентификации пользователя, сетевой архитектуры и мониторинга. Для всех внешних административных подключений необходимо использовать MFA и по возможности отказаться от факторов, которые можно повторно применить после кражи учетных данных. Прямой RDP-доступ из интернета следует исключить, а VPN и RMM-сервисы ограничить по источникам подключения и доступным сегментам. Административные и сервисные учетные записи необходимо отделять от пользовательских, сокращать их привилегии и регулярно менять учетные данные, особенно после устранения уязвимостей на пограничных устройствах. Логи VPN, RDP, RMM, служб каталогов и средств защиты конечных точек должны анализироваться совместно, поскольку аномалия часто заметна не в самом факте подключения, а в последовательности действий после него. Дополнительный эффект дают сегментация сети, контроль новых RMM-инструментов, ограничение административных интерфейсов и регулярная инвентаризация всех внешних сервисов. При доле удаленного доступа в 65% инцидентов защита этого контура должна рассматриваться как отдельная задача управления доступом, а не только как часть стандартной настройки сетевого периметра.</p> Эксперты компании «Информзащита» выявили, что в 2026 году средства удаленного доступа использовались в 62% … message https://www.itweek.ru/themes/detail.php?ID=235453 Thu, 03 Sep 2026 09:49:23 +0300 <p><em>Опрос разработчиков, проведенный компанией Coddy, </em><a href="https://coddy.tech/blog/coding-for-beginners/ai-coding-addiction-report"><em>показал</em></a><em>, что программирование с помощью искусственного интеллекта приводит к новому виду эмоционального выгорания, сообщает портал </em><em>ZDNet</em><em>.</em></p> <p>Наверное, в этом нет ничего неожиданного. Благодаря GitHub Copilot, Claude Code, Cursor и любого другого нового ИИ-инструмента для разработчиков, вы как программист можете выполнять больше работы, чем когда-либо прежде. Но даже несмотря на то, что разработчики все чаще используют их для создания шаблонов, объяснения незнакомого кода, составления тестов, рефакторинга модулей и устранения неполадок, многие из них также обнаруживают, что те же самые инструменты могут вызывать проблемы.</p> <h3>Трудоголизм, вызванный ИИ</h3> <p>«Сейчас 2:47 ночи... Я не устраняю сбой. Крайнего срока нет. Я просто наблюдаю, как Claude Code проводит рефакторинг модуля... и я не могу отвести взгляд», — пишет в своем посте в LinkedIn Квентин Руссо, технический директор и соучредитель компании Rootly, занимающейся отчетами об инцидентах на основе ИИ. Почему так происходит? Потому что, продолжает он, «агентное кодирование вызывает привыкание. Когда агент делает все правильно, ты получаешь дофаминовый заряд. Когда это не удается, ты испытываешь прилив адреналина». Руссо признается, что не мог спать и был вынужден обратиться за медицинской помощью.</p> <p>В этом нет ничего удивительного. Программисты уже давно склонны к трудоголизму. Однако ИИ придал работе новый темп, когда, как выразился Руссо, «наблюдение за работой агента достаточно пассивно, чтобы не чувствовать усталости, и достаточно активно, чтобы держать вас на крючке». В результате возникает новый вид эмоционального выгорания.</p> <p>Это не просто опыт одного программиста. ИИ-кодирование может превратить разработку ПО в непрерывный цикл обратной связи. Вместо того, чтобы завершить задачу и отвлечься, разработчики могут постоянно просить агента о другой реализации, переписывании, оптимизации или рефакторинге, или сочетать это с беспокойством о том, что остановка означает невыполнение работы.</p> <h3>Когда ИИ становится не помощником, а кандалами</h3> <p>Компания Coddy Tech, занимающаяся обучением программированию, в ходе опроса 305 разработчиков выяснила, что для 80% из них использование ИИ больше похоже на зависимость, чем на преимущество. Конечно, они находят эти инструменты полезными, но они также обеспокоены тем, что возникновение привычки зависеть от ИИ ослабляет их собственные возможности решения проблем, увеличивает их рабочую нагрузку и формирует нездоровые отношения с работой.</p> <p>Согласно отчету, 43% респондентов продолжают программировать с помощью ИИ в нерабочее время, даже когда они собирались остановиться, а 32% откладывают сон, чтобы продолжить работу. Кроме того, 39% опрошенных отмечают, что инструменты ИИ усложняют возможность отключиться от рабочего процесса.</p> <p>Дело не только в том, что инструменты ИИ вызывают привыкание. 74% разработчиков сообщают, что интенсивное использование ИИ увеличивает вероятность повышения зарплаты или продвижения по службе. Однако 51% также заявляют, что у них стало больше шансов перегореть.</p> <h3>Доверяй, но проверяй: ИИ не безупречен</h3> <p>Как показал опрос Stack Overflow «2025 Developer Survey», 45% респондентов разочарованы ответами ИИ, которые могут быть «почти правильными, но не совсем». В результате вывод выглядит убедительно, но приводит к сложной работы по отладке.</p> <p>Исследование Stack Overflow также показало, что, хотя внедрение инструментов ИИ продолжает расти и в настоящее время 80% разработчиков используют их в своих рабочих процессах, доверие к точности ИИ упало с 40% в предыдущие годы до всего лишь 29% в этом году. В результате положительное отношение программистов к ИИ за год снизилось с 72 до 60%.</p> <p>С одной стороны, повышается удобство использования, с другой — растет рабочая нагрузка разработчика. Помимо попыток понять, насколько правильно угадал ИИ, они должны понимать требования, распознавать конфликты сгенерированного кода с архитектурой системы, тестировать крайние случаи, устранять риски безопасности и нести ответственность за последствия в производственной среде.</p> <p>Это создает «долг верификации». Результат появляется быстро, но вы все равно вынуждены устанавливать, является ли он правильным, безопасным, поддерживаемым и подходящим для конкретной кодовой базы.</p> <p>Кроме того, зависимость, описанная в исследовании Coddy, может быть усилена тем, как работодатели интерпретируют результаты, полученные с помощью ИИ. Если организация рассматривает ИИ как способ увеличить возможности разработчиков, сотрудники могут столкнуться с необходимостью предоставлять больше функций, закрывать больше заявок и выполнять больше проверок за то же количество часов.</p> <p>Это, в свою очередь, может привести к тому, что время, сэкономленное на отдельных задачах по кодированию, будет перенаправлено на другие задачи: больше запросов на слияние, больше сгенерированных изменений для проверки, больше зависимостей для проверки и больше операционных рисков для управления.</p> <p>Таким образом, ИИ-кодирование становится вопросом баланса работы и отдыха в не меньшей степени, чем вопрос применения ИИ-инструментов. Команды, которые используют агентов для устранения рутинного труда, могут увидеть реальные преимущества. Команды, которые используют их для ускорения каждого этапа разработки ПО, рискуют создать более быструю и безжалостную версию той же работы.</p> <p>Для разработчиков, таких как Руссо, проблема уже не только в том, может ли ИИ писать код. Он может. Вопрос теперь заключается в том, могут ли разработчики по-прежнему решать, когда заканчивается их рабочий день и цикл работы агента.</p> Опрос разработчиков, проведенный компанией Coddy, показал, что программирование с помощью искусственного интеллекта приводит … article https://www.itweek.ru/themes/detail.php?ID=235451 Thu, 03 Sep 2026 09:40:30 +0300 <p><em>Обсудим, п</em><em>очему в 2026 году чистый инхаус всё чаще проигрывает гибридной модели</em><em>.</em></p> <p>В России <a href="https://www.interfax.ru/russia/1028484">работает</a> около 1 млн. ИТ-специалистов, но дефицит кадров, по оценкам Минцифры, всё еще составляет <nobr>500-700 тыс.</nobr> человек. Параллельно растет<a href="https://marketing.rbc.ru/research/52099/"> рынок ИТ-аутсорсинга</a>: в 2024 году его оборот достиг 262 млрд. руб., рост на 24% к предыдущему году. Согласно исследованию CNews Research, <a href="https://codingteam.ru/blog/autsorsing-razrabotchikov-v-2025-kogda-vigodnee-na">более 72% компаний</a> с цифровыми продуктами привлекают внешних разработчиков хотя бы на одном из этапов жизненного цикла проекта. Вопрос «нанять своего или взять подрядчика» остается одним из самых частых у малого и среднего бизнеса. Однозначного ответа нет, но есть конкретные критерии, которые помогают сделать выбор.</p> <h3>Экономика вопроса: сколько стоит собственный разработчик</h3> <p>По данным <a href="https://habr.com/ru/specials/1060148/">«Хабр Карьеры»</a>, в первой половине 2025 года медианная зарплата ИТ-специалиста в России составила 191 тыс. руб./мес — на 4% больше, чем во втором полугодии 2025 года. В Москве этот показатель уже 235 тыс. руб./мес.</p> <p>К зарплате прибавляются страховые взносы <nobr>(15-30%</nobr> сверху в зависимости от статуса компании), оборудованное рабочее место, лицензии на ПО, корпоративное обучение, время HR на поиск и онбординг. Реальная нагрузка на бизнес примерно на <nobr>30-40%</nobr> выше окладной части. Мидл-разработчик в Москве обходится компании в <nobr>270-350 тыс.</nobr> руб./мес, а годовой бюджет на одного специалиста стартует от 3,2 млн. руб.</p> <p>Сравним с аутсорсом. Час работы мидла в агентстве — <nobr>3-5 тыс.</nobr> руб., у проверенного фрилансера — <nobr>2-3 тыс.</nobr> руб. На бюджет одного штатного разработчика можно купить <nobr>800-1200</nobr> часов внешней разработки в год. Этого хватает почти любому бизнесу, который не строит вокруг сайта основной продукт.</p> <h3>Рынок поменялся: ситуация в 2026 году</h3> <p>Картина в ИТ-найме за последние два года резко изменилась. По данным <a href="https://trends.rbc.ru/trends/social/cmrm/698da33a9a79474de4341261">hh.ru и «РБК Трендов»</a>, количество вакансий в ИТ просело примерно на 20%, а активных резюме стало больше на четверть. На одну вакансию сейчас приходится <nobr>12-15 кандидатов.</nobr></p> <p>Однако нанимать стало не проще. Дефицит сместился в сторону точечной экспертизы: архитекторы, специалисты по информационной безопасности, инженеры данных, DevOps. Мидлы и сеньоры с конкретным сочетанием технологий по-прежнему уходят с рынка за <nobr>1-2 недели.</nobr> Зарплатные ожидания продолжают расти: за год средняя по веб-разработке поднялась на <nobr>10-15%.</nobr></p> <p>Для бизнеса это означает простую вещь: окно «найму своего, пока недорого» закрылось. Экономика инхауса работает только при стабильной загрузке.</p> <h3>Когда инхаус оправдан</h3> <p>Свой разработчик окупается в четырех сценариях.</p> <ul> <li><strong>Постоянный поток задач.</strong> Если на сайте каждый день что-то меняется — тесты гипотез, новые лендинги, доработки личного кабинета, интеграции с маркетплейсами — внешний подрядчик тормозит процессы.</li> <li><strong>Глубокая связка с бизнес-логикой.</strong> Кастомные системы управления взаимоотношениями с клиентами (CRM), ERP, нестандартные процессы обработки заказов требуют погружения в специфику. Подрядчик, который параллельно ведет десяток клиентов, не удержит в голове все нюансы.</li> <li><strong>Чувствительные данные и безопасность.</strong> Когда сайт обрабатывает персональные или финансовые данные, важна предсказуемость доступов и зон ответственности.</li> <li><strong>Сайт как продукт.</strong> Если приложение или платформа — ядро бизнеса, отдавать их разработку наружу стратегически рискованно.</li> </ul> <h3>Когда выгоднее аутсорс</h3> <p>Большинству небольших и средних компаний штатный разработчик не нужен. Аутсорс выигрывает, когда:</p> <ul> <li> сайт меняется редко: раз в месяц-два появляется новая страница, баннер или акция;</li> <li> нужны специфические компетенции на короткий срок — например, разработка мобильного приложения или интеграция со специфической платежной системой;</li> <li> бизнес сезонный: летом нагрузка одна, зимой другая, и держать постоянного разработчика нерационально;</li> <li> стартап проверяет гипотезы, и пока непонятно, какой технический стек нужен в долгую.</li> </ul> <p>У многих небольших интернет-магазинов нет ни одного разработчика в штате — и при этом их сайты работают годами.</p> <h3>Гибрид — самый частый сценарий</h3> <p>Чаще всего выстраивается гибридная модель. У бизнеса есть один технический специалист уровня тимлида или продакт-менеджера, а основная разработка идет на стороне.</p> <p>Этот человек знает бизнес и продукт изнутри. Управляет подрядчиками, ставит задачи, принимает работу. Закрывает срочные инциденты: отвалилась форма заказа, упала страница, нужно за час добавить виджет под акцию.</p> <p>Гибрид закрывает главную слабость аутсорса — отсутствие человека, который держит в голове всю картину. И не требует найма команды из трех-пяти разработчиков.</p> <h3>На что смотреть при выборе подрядчика</h3> <p>Перед подписанием договора стоит проверить четыре вещи.</p> <ul> <li><strong>Регламент реагирования на инциденты.</strong> Узнайте, что произойдет, если сайт упадет в субботу вечером. У хорошего подрядчика прописаны SLA с конкретными временами реакции. У плохого — общие слова про «оперативное решение».</li> <li><strong>Доступы и документация.</strong> Код, доступы к хостингу, репозитории, базы данных принадлежат вам, а не подрядчику. Регулярно видим истории, где владелец бизнеса не может попасть на собственный сайт, потому что всем владеет агентство, с которым испортились отношения.</li> <li><strong>Передача дел.</strong> Что произойдет, если решите сменить подрядчика? Хорошая команда умеет передавать проекты и не пытается удерживать клиента собственной незаменимостью.</li> <li><strong>Прозрачность отчетности.</strong> Часы, задачи, статусы видны заказчику. Любая модель «доверьтесь нам, мы всё сделаем» в долгосрочной перспективе превращается в проблему.</li> </ul> <h3>Как принять решение: три вопроса самому себе</h3> <p><strong>Сколько часов разработки реально нужно в месяц?<br/> </strong>Меньше <nobr>60-80 —</nobr> аутсорс. Стабильно больше <nobr>120-160 —</nobr> пора думать про штат. </p> <p><strong>Насколько уникален продукт?</strong><br/> Сайт-визитка, типовой интернет-магазин на готовом движке, корпоративный портал на коробочном решении — аутсорс. Сложный сервис с собственной бизнес-логикой — инхаус или гибрид. </p> <p><strong>Готовы быть работодателем для разработчика?<br/> </strong>Если в команде нет человека, который понимает в разработке хотя бы на уровне тимлида, штатный сотрудник быстро превращается в черный ящик: непонятно, как его оценивать, что он делает и за что ему платить. </p> <p>Главная ошибка, которую мы видим в малом и среднем бизнесе — найм разработчика «на вырост». Компания берет человека в расчете на будущие задачи, но будущее не наступает, специалист недозагружен, а 3 млн. руб. в год продолжают уходить с расчетного счета. Простая проверка: если реальный объем задач занимает меньше 70% рабочего времени разработчика, штат не окупится. Считайте не зарплату, а часовую ставку и фактический объем работы, и берите подрядчика, пока стабильная загрузка не подтвердилась цифрами хотя бы за полгода.</p> <p>#IMAGE_235452#</p> Обсудим, почему в 2026 году чистый инхаус всё чаще проигрывает гибридной модели. В России работает около 1 млн … article Алексей Солдатов, руководитель технической поддержки SpaceWeb https://www.itweek.ru/themes/detail.php?ID=235449 Wed, 02 Sep 2026 14:34:58 +0300 <p>Yandex B2B Tech запустила Yandex BareMetal Extend — решение, с помощью которого компании могут получить готовую инфраструктуру на выделенных серверах без закупки и поддержки дорогостоящего оборудования. В отличие от классических частных облаков, в новом решении инфраструктура заказчика физически отделена от публичного облака. Yandex BareMetal Extend позволит бизнесу сохранять повышенный контроль над инфраструктурой, но при этом не потерять гибкость и скорость разработки. Уже сейчас можно оставить заявку на сайте и получить консультацию.</p> <p>Yandex BareMetal Extend — это не классическое решение по аренде «железа». В нем есть три заранее преднастроенных модуля: виртуализация, Kubernetes<sup class="reg">®</sup> и платформа для разработки приложений Stackland. В зависимости от задач компания может выбрать один из них и развернуть на выделенных серверах контейнерные приложения или критичные бизнес-системы. ИТ-командам компаний не придется самостоятельно поддерживать виртуальные мощности. По данным Atlassian DX Report, 50% разработчиков теряют более 10 часов в неделю на непрофильную работу. </p> <p>Партнером по разработке решения с виртуализацией стал облачный провайдер с экспертизой интегратора K2 Cloud. Совместно со специалистами Yandex Cloud компания будет оказывать техническую поддержку клиентам в формате единого окна. </p> <p>«Крупным компаниям важно одновременно соблюдать требования информационной безопасности и сокращать время на запуск ИТ-систем. В Yandex BareMetal Extend клиент получает выделенную инфраструктуру с уже настроенной средой, поэтому команде не нужно самостоятельно собирать и поддерживать её из отдельных компонентов. Мы отдаём клиенту не набор компонентов для самостоятельной сборки, а среду, готовую к работе с первого дня аренды», — рассказал Иван Пузыревский, технический директор платформы Yandex Cloud.</p> <p>«У K2 Cloud большой опыт создания изолированной программной среды для крупного бизнеса — с соответствием требований ИБ, аттестациями и строгими SLA. Мы объединили нашу экспертизу с технологиями Yandex Cloud и получили уникальное решение. Заказчики получат готовую изолированную инфраструктуру с управлением виртуальными ресурсами из единого интерфейса под критичные системы», — отметил Сергей Зинкевич, CEO K2 Cloud.</p> <p>Yandex BareMetal соответствует первому уровню защищённости персональных данных и обеспечивает защиту на уровнях ЦОД, сети и сервиса. Клиенты также могут резервировать ресурсы и объединять инфраструктуру на выделенных серверах с помощью приватного соединения.</p> Yandex B2B Tech запустила Yandex BareMetal Extend — решение, с помощью которого компании могут получить готовую … message https://www.itweek.ru/themes/detail.php?ID=235444 Wed, 02 Sep 2026 10:10:22 +0300 <p><em>За тридцать лет индустрия информационной безопасности пережила несколько технологических сдвигов, но ни один из них не менял расстановку сил так быстро, как генеративный ИИ. Раньше между появлением нового класса атак и его массовым применением проходили годы: злоумышленникам нужно было время, квалификация и инфраструктура. Сегодня этот барьер обрушился. Написать фишинговое письмо на безупречном русском, собрать досье на жертву, сгенерировать вариант вредоносного кода, обходящий сигнатурный детектор, — всё это стало доступно человеку без глубокой технической подготовки и занимает минуты, а не недели. </em><em>Рассмотрим, </em><em>к</em><em>ак эволюционировали методы кибератак с появлением ИИ</em><em>.</em></p> <p>Масштаб перемен уже поддаётся измерению. По данным отчёта Bugcrowd Inside the Mind of a Hacker, к концу 2025 года 82% исследователей (в том числе действующих не по правилам; против 64% в <nobr>2023-м)</nobr> применяли ИИ в своей работе. Искусственный интеллект перестал быть экзотикой в арсенале атакующего и стал рабочим инструментом по умолчанию.</p> <p>Эволюцию «наступательного» ИИ удобно разложить на три волны, которые не сменяют, а наслаиваются друг на друга.</p> <h3>Три этапа взросления атакующих нейросетей</h3> <p>Первая волна — автоматизация рутины. Здесь ИИ не принимает решений, а масштабирует то, что человек и так делал руками: генерирует тексты фишинга, переводит их на десятки языков без характерных ошибок, пишет шаблоны, парсит открытые источники. Это уже полностью реальность и массовая практика. Стоимость подготовки убедительной атаки упала на порядок, а качество — выросло.</p> <p>Вторая волна — ассистирование в сложных задачах. ИИ становится «вторым пилотом» атакующего: помогает разобраться в незнакомом коде, предлагает варианты эксплуатации уязвимости, адаптирует полезную нагрузку под конкретное окружение, ведёт разведку и приоритизирует цели. Решение по-прежнему за человеком, но скорость и охват растут кратно. Именно на этом этапе мы находимся сейчас.</p> <p>Третья волна — автономное принятие решений. Это агентные системы, которые получают цель («получить доступ к сегменту сети») и самостоятельно строят цепочку действий: разведка → выбор вектора → эксплуатация → закрепление → латеральное перемещение, реагируя на обратную связь от среды без участия оператора. Полноценных автономных атакующих агентов «в дикой природе» пока единицы, и они несовершенны, но направление обозначено предельно чётко. Именно к этому сценарию защиты нужно готовиться уже сегодня, а не когда он станет мейнстримом.</p> <h3>Что случилось с классическими векторами</h3> <p>Важно понимать: генеративный ИИ не создал новых классов атак. Фишинг, социальная инженерия и вредоносное ПО были и двадцать лет назад. ИИ изменил их экономику и качество.</p> <ul> <li><strong>Фишинг</strong>. Раньше защитой служили сами письма: корявый язык, нелепые обращения, кривая верстка — «маркеры мошенника», которым учили сотрудников. Генеративные модели эти маркеры стёрли. Показателен рубеж, зафиксированный в сети детектирования Hoxhunt: несколько лет доля писем с признаками ИИ-генерации держалась ниже 5%, а в декабре 2025 года подскочила примерно в 14 раз — до 56% всех выявленных атак. Изменилась и экономика: по оценкам, приводимым в индустриальных отчётах, LLM сократили время подготовки убедительной кампании с примерно 16 часов ручной работы до нескольких минут, а затраты на массовую рассылку упали примерно на 95%. Письмо теперь грамотное, персонализированное под должность и контекст получателя, а массовая кампания легко превращается в тысячи уникальных вариантов, каждый из которых обходит фильтры по «шаблонности».</li> <li><strong>Социальная инженерия</strong><strong>.</strong> Здесь качественный скачок дали дипфейки. Хрестоматийный пример — инцидент с инженерной компанией Arup в начале 2024 года: сотрудника финансового отдела в Гонконге убедили провести 15 переводов на общую сумму около 25 млн. долл. после видеозвонка, на котором все «руководители», включая финансового директора, были сгенерированы ИИ. И это не единичный случай: по оценке Surfshark на основе AI Incident Database, совокупные потери от дипфейк-мошенничества к концу прошлого года достигли порядка 1,56 млрд. долл., причём более 1 млрд. пришлось только на 2025 год. Опаснее всего то, что человек здесь беззащитен по природе: в контролируемых исследованиях качественные видео-дипфейки люди правильно распознают лишь примерно в четверти случаев. Доверие к «знакомому лицу и голосу» из защитного механизма превратилось в вектор атаки.</li> <li><strong>Вредоносное ПО</strong><strong>.</strong> ИИ ускорил разработку и, что опаснее, — вариативность. Полиморфный код, который на каждой итерации меняет структуру, сохраняя функциональность, генерируется теперь программно и в промышленных объёмах. Для сигнатурного детектирования это тяжёлый удар: сигнатура ловит известное, а машина производит бесконечный поток «нового».</li> <li><strong>Пентест.</strong> Автоматизация многих этапов внешнего и внутреннего тестирования на проникновение с помощью нейросетей значительно сокращает время от обнаружения уязвимого ресурса до получения доступа во внутреннюю инфраструктуру. Разница и преимущество опытного оператора с нейростью перед специалистом без такого инструмента сразу заметны. Там, где человеческий глаз и подход могут не заметить сложную уязвимость, ИИ может показать новый вектор или атаку, находя решение даже в самых сложных условиях.</li> </ul> <p>#IMAGE_235448#</p> <p>Как показывает <a href="https://www.first.org/blog/20260615-vulnerability-forecast-update">The 2026 Vulnerability Forecast Update</a>, в этом году ожидается 66 000 новых публичных CVE, что на 46,3% выше первоначального прогноза в 2026 году. Это на 37% больше по сравнению с <nobr>2025-м,</nobr> в котором нашли <a href="https://www.stingrai.io/blog/vulnerability-statistics-2026">48 185 CVE</a>, и на 20% больше чем в <nobr>2024-м</nobr> (40 009 CVE). По прогнозу заметна высокая динамика, и с помощью нейросетей теперь обнаруживают намного больше новых <nobr>0-day</nobr> уязвимостей.</p> <h3>Гонка вооружений: где был переломный момент</h3> <p>Противостояние атакующих и защитных алгоритмов — не новость. ML в антивирусах и системах обнаружения вторжений применяется больше десяти лет: поведенческий анализ, классификаторы вредоносных файлов, детекторы аномалий появились задолго до нынешнего хайпа. Массовый разворот защиты в сторону ИИ произошёл в конце <nobr>2010-х,</nobr> когда EDR- и NGAV-решения сделали машинное обучение стандартом, а не экзотикой.</p> <p>Настоящий перелом наступил в <nobr>2022-2023 годах,</nobr> с выходом больших языковых моделей в широкий доступ. До этого преимущество в автоматизации было скорее на стороне защиты — у неё было больше ресурсов и данных. Генеративный ИИ впервые дал атакующему инструмент такой же мощности, что и у обороняющегося, и почти бесплатно. Симметрия нарушилась: порог входа в качественную атаку упал быстрее, чем успела адаптироваться защита. Именно этот разрыв мы сейчас и наблюдаем.</p> <h3>Какие задачи атакующие уже делегируют машине</h3> <p>Если рассмотреть по отдельности каждый из этапов проникновения с точки зрения атакующего, ИИ сегодня применяется почти в каждом из них:</p> <ul> <li> <strong>Разведка (recon).</strong> Сбор и категоризация больших объемов данных по компании из открытых источников, составление карты внешнего периметра, анализ утечек и построение профилей сотрудников. То, что раньше отнимало у аналитка дни, модель делает за десятки минут.</li> <li> <strong>Активная эксплуатация</strong>. Пентест-агенты позволяют проанализировать каждый из обнаруженных ресурсов как если бы это делал реальный злоумышленник — использовать инъекции, анализировать поведение приложения на различные запросы, обнаруживать сложные цепочки уязвимостей, и все это автоматически.</li> <li><strong>Социальная инженерия.</strong> Генерация фишинга и приманок. Уникальные письма, поддельные страницы, легенды для переписки — под конкретную жертву и её контекст. Сюда же относятся дипфейки: голос и видео для обхода процедур подтверждения личности и «звонка руководителя».</li> <li><strong>Разработка и мутация ПО.</strong> Написание и обфускация полезной нагрузки, генерация полиморфных вариантов, адаптация под окружение.</li> <li><strong>Полноценная имитация атакующего.</strong> Пентест-агенты позволяют проанализировать сайт как если бы это делал реальный злоумышленник — использовать инъекции, анализировать поведение приложения на различные запросы, обнаруживать сложные цепочки уязвимостей, генерация proof-of-concept под свежие багии помощь в написании эксплойтов, и все это автоматически.</li> </ul> <p>Отдельно — обход защиты. Генеративные модели используются для мимикрии под легитимный трафик: вредоносная активность «размазывается» так, чтобы статистически не отличаться от нормального поведения пользователя или приложения, а команды управления прячутся в обычных на вид запросах. Это прямая атака на детекторы аномалий, построенные на «отклонении от нормы».</p> <h3>Как ИИ работает на стороне защиты: SOC, SIEM, поведенческий анализ</h3> <p>Хорошая новость в том, что те же технологии усиливают и оборону — причём защита научилась применять ИИ раньше и системнее.</p> <p>В современных SOC и SIEM-системах машинное обучение решает главную боль аналитика — шум. Классические корреляционные правила генерируют тысячи срабатываний, большинство из которых ложные. <nobr>ML-модели</nobr> строят поведенческий базлайн (UEBA, анализ поведения пользователей и сущностей): что для конкретного аккаунта, сервера или сервиса является нормой по времени, объёму, географии, набору действий. Отклонение от этого профиля — сигнал, даже если формально ни одно сигнатурное правило не сработало. Именно так ловятся атаки, у которых нет известной сигнатуры.</p> <p>По эффективности для сложных угроз можно выделить несколько подходов:</p> <ul> <li> <strong>Обучение без учителя (кластеризация, детекторы аномалий)</strong> — для zero-day и незнакомых атак, где нет размеченных примеров. Модель ищет не «известное плохое», а «непохожее на нормальное».</li> <li><strong> Графовые модели и анализ последовательностей</strong> — для APT и латерального перемещения. Продвинутая целевая атака растянута во времени и складывается из событий, каждое из которых по отдельности выглядит безобидно. Увидеть её можно только как цепочку — граф связей между хостами, аккаунтами и процессами.</li> <li><strong> Рекуррентные и трансформерные архитектуры</strong> — для анализа временных рядов событий и выявления аномального контекста в потоке логов.</li> <li><strong> Модели на данных цепочки поставок</strong> — для атак через доверенных поставщиков, где вредоносный код приходит легитимным каналом обновления и требует анализа отклонений в самом артефакте, а не в сети.</li> </ul> <p>Ни один из этих методов не самодостаточен. Работает ансамбль: сигнатуры закрывают известное дёшево и точно, ML — неизвестное и поведенческое. И это окупается: по данным отчёта IBM Cost of a Data Breach 2025, организации, широко применяющие ИИ и автоматизацию в безопасности, обнаруживают и локализуют инциденты заметно быстрее и с ощутимо меньшими издержками, чем те, кто этого не делает.</p> <p>Предиктивные модели угроз пытаются ответить на вопрос «где ударят следующим». Они анализируют профиль организации, её поверхность атаки, историю инцидентов в отрасли, активность конкретных группировок и приоритизируют риски: какие активы и какие уязвимости с наибольшей вероятностью станут целью.</p> <p>Дефицит кадров в ИБ — структурная проблема, и здесь ИИ даёт ощутимый эффект. Системы SOAR (оркестрация, автоматизация и реагирование) берут на себя рутину: обогащение инцидента данными, первичную сортировку, изоляцию заражённого хоста, блокировку индикатора компрометации по готовому сценарию (playbook). Языковые модели добавляют к этому автоматическое резюмирование инцидента и черновики отчётов.</p> <p>Смысл не в том, чтобы заменить аналитика, а в том, чтобы он занимался расследованиями, а не перекладыванием тикетов. Когда 80% типовых срабатываний обрабатывается автоматически, у человека высвобождается время на то, что машине пока не по силам, — сложные, нестандартные, целевые атаки. Тут важно предостеречь: полная автоматизация реагирования без контроля человека опасна, потому что автономный ответ на ложный или спровоцированный сигнал сам становится вектором атаки — злоумышленник может намеренно заставить защиту «выстрелить себе в ногу».</p> <h3>Цикл «атака — защита», когда с обеих сторон ИИ</h3> <p>Мы движемся к ситуации, где и атакующий, и обороняющийся — это алгоритмы, соревнующиеся в скорости адаптации. Атакующая модель генерирует вариант, обходящий детектор; защитная — учится его ловить; атакующая — генерирует следующий. Цикл, который раньше измерялся месяцами, сжимается до дней и часов, а на этапе исполнения — до секунд. По данным CrowdStrike, среднее «время прорыва» (от первичной компрометации до первого латерального перемещения) в 2025 году составило 29 минут — на 65% быстрее, чем годом ранее, а рекордный показатель — 27 секунд; передача доступа от брокера первичного доступа к операторам вымогательского ПО, по данным Mandiant, сжалась до 22 секунд. Тот же CrowdStrike фиксирует рост ИИ-опосредованных атак примерно на 89% год к году.</p> <p>Кто выигрывает в такой гонке? Тот, у кого качественнее данные и быстрее петля обратной связи. И здесь у защиты есть структурное преимущество, о котором часто забывают: обороняющийся видит свою инфраструктуру целиком, а атакующий — только снаружи и по частям. Это преимущество работает при одном условии — если защита действительно видит всё. Слепые зоны — забытые тестовые серверы, теневые облачные сервисы, неучтённые VPN-точки, старые поддомены — обнуляют его. Автоматизированный сканер злоумышленника найдёт их за часы, и никакой продвинутый SOC не защитит актив, о существовании которого он не знает.</p> <p>Именно поэтому фундамент защиты в эпоху ИИ — это полная и непрерывная видимость поверхности атаки.</p> <h3>Что будет через 5<strong>-</strong>10 лет</h3> <p>Прогнозировать в ИБ на десять лет — сложно, но тренды достаточно устойчивы, чтобы обозначить контур. ИИ — полезный инструмент, который уже активно используется защитниками, но он не спасёт там, где нет базовой кибергигиены. Сначала база — классические процессы сканирования. Для них использование агентских систем — пустая трата токенов. А дальше — не бояться экспериментировать, решать свои задачи.</p> <p>Атаки станут агентными и автономными. Значительная часть операций — от разведки до эксплуатации — будет выполняться без прямого участия человека, а атаки станут по-настоящему массово-персонализированными: индивидуальный подход к каждой жертве при промышленном масштабе.</p> <p>Скорость выйдет на первый план. Ключевой метрикой станет не «есть ли у вас защита», а «за сколько вы обнаруживаете и реагируете». Человек останется в контуре принятия стратегических решений, но операционную скорость будут задавать машины с обеих сторон.</p> <p>Доверие к цифровому контенту продолжит расти. Дипфейки сделают верификацию личности отдельной инженерной дисциплиной. Пароля и даже голоса будет недостаточно — потребуются криптографические и поведенческие методы подтверждения.</p> <p>Защита консолидируется. Контроль периметра, SIEM, XDR и SOAR срастутся в единые экосистемы, где данные о поверхности атаки становятся общим контекстом для решений. Рынок уже движется к модели непрерывного управления экспозицией угроз (Continuous Threat Exposure Management) — от разовых проверок к постоянному мониторингу.</p> <p>Генеративный ИИ — это усилитель, и он укрепляет обе стороны. Проиграет не тот, у кого нет ИИ, а кто продолжает жить в логике реактивной защиты: узнавать о проблеме постфактум и проверять периметр по расписанию. Важно принять новую реальность, где всё меняется каждый день и с обеих сторон работают машины, построить защиту как непрерывный процесс, а не разовое действие. Технологии здесь скорее вторичны. Первична дисциплина видеть всё и вовремя.</p> <p>#IMAGE_235445#</p> За тридцать лет индустрия информационной безопасности пережила несколько технологических сдвигов, но ни один … article Давид Ордян, основатель и генеральный директор METASCAN https://www.itweek.ru/themes/detail.php?ID=235443 Wed, 02 Sep 2026 09:51:39 +0300 <p><em>Исследования указывают на разрыв между амбициями в области искусственного интеллекта и реальной ситуацией на практике, но хорошая новость заключается в том, что специалисты могут его преодолеть, сосредоточившись на тщательных исследованиях и убедительных сценариях использования в производстве, сообщает портал </em><em>ZDNet</em><em>.</em></p> <p>Согласно отчету глобальной контентной и технологической компании Thomson Reuters «2026 Future of Professionals Report», до 91% сотрудников заявляют, что их организации не в полной мере используют потенциал ИИ.</p> <p>Исследование, основанное на глобальном опросе 1800 специалистов из различных секторов, показывает растущий разрыв между амбициями в области ИИ и реальностью, что становится все более серьезной проблемой, отмечает Кирсти Рот, операционный директор Thomson Reuters.</p> <p>Полтора года назад сотрудники с энтузиазмом экспериментировали с ИИ, а их руководители с готовностью поддерживали эти исследования. Сегодня ситуация изменилась. Специалисты тратят токены на использование ИИ, а их руководители обеспокоены ростом расходов на ИТ. Учитывая, что исследования MIT показывают, что 95% проектов в области ИИ не приносят пользы, неудивительно, что компании начинают сомневаться.</p> <h3>ИИ крайне фрагментирован и раздроблен</h3> <p>«Люди начинают понимать, что эти технологии стоят больших денег, и они пока не обязательно видят от них пользу, — говорит Рот. — И поэтому разговор сводится к классическому вопросу управления изменениями: „Хорошо, у нас есть все эти технологии и все эти инструменты, но как мы можем реально изменить наши процессы и способы работы, чтобы быть более эффективными?“».</p> <p>Новые развивающиеся технологии, от агентных моделей ИИ до инструментов глубокого исследования, будут продолжать проникать в бизнес. Как считает генеральный директор Boomi Стив Лукас, общее положение дел в области ИИ крайне фрагментировано и раздроблено: «Сейчас профессионалы знакомятся со множеством терминов — передовые модели, частные модели, доменные модели, модели с открытыми весами, агентные структуры, агентные механизмы и агентные циклы — которые не существовали еще несколько месяцев назад, не говоря уже о нескольких годах».</p> <p>Рот, опираясь на исследование своей фирмы и личный опыт, предлагает компаниям и их специалистам, получающим выгоду от ИИ, сосредоточиться на двух областях: тщательных исследованиях и надежных сценариях использования в производстве.</p> <h3>Поддержка тщательных исследований</h3> <p>Профессионалы, принявшие участие в опросе, четко понимают, что должны делать их инструменты ИИ: защищать конфиденциальные данные (96%), обосновывать результаты авторитетным контентом (94%) и предоставлять объяснимые и обоснованные рассуждения (90%). Однако двое из пяти специалистов (41%), использующих ИИ в своей работе, отмечают, что у них нет доступа к высококачественным инструментам.</p> <p>Согласно исследованию, даже при наличии ИИ-стратегии ее реализация часто отстает. Чуть более трети (35%) специалистов в компаниях, имеющих четко определенную ИИ-стратегию, говорят, что этот подход не проявляется в их повседневной работе.</p> <p>По словам Рот, одно из объяснений — это то, что она называет «инструментальным взрывом» («tool blast»), когда организации навязывают сотрудникам широкий спектр ИИ-сервисов без четкого понимания бизнес-результатов. «Я слышала, как люди говорят: „Мне дали все это. Но что я должен с этим делать?“ Слишком многие компании не понимают, какие инструменты должны использовать сотрудники. Я думаю, что в этом случае очень трудно увидеть рост, за исключением того, что ваши затраты на ПО значительно возрастут», — отмечает она.</p> <p>Согласно <a href="https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure">прогнозу</a> Gartner, 40% предприятий к 2027 г. сократят использование или выведут из эксплуатации автономных агентов ИИ из-за опасений по поводу их ценности.</p> <p>Рот говорит, что вдумчивые бизнес-руководители ищут действенные решения на основе ИИ для сложных задач, предоставляя специалистам возможность изучать новые технологии, не принимая на себя слишком большого риска. Это то, что она делает в Thomson Reuters, где, по ее словам, придерживаются непредвзятого подхода к генеративному ИИ. «Если у вас появляется классный инструмент, и вы работаете в отделах маркетинга, продаж или программирования, и хотите его попробовать, мы позволим вам это сделать», — поясняет она.</p> <p>Рот отмечает, что вместо того, чтобы ориентироваться на целевые показатели затрат, компания поощряет людей тестировать инструменты ИИ и искать лучшие способы работы. «Мы говорим людям: „Вот инструменты. Переосмыслите, что вы можете сделать“, — рассказывает она. — Конечно, некоторые показывают себя лучше, чем другие, а некоторым требуется больше подсказок и помощи. Но мы поощряем людей думать о том, что эти инструменты могут сделать в современном мире. И этот подход, похоже, хорошо работает».</p> <p>Важным элементом этой стратегии, по мнению Рот, является четкое определение того, какие инструменты приносят пользу, а какие нет, и в последнем случае — прекращение исследований. «На начальном этапе мы пробовали всё подряд в течение примерно шести недель. Можно было получить лицензию практически на всё, что угодно, дать возможность своей команде поэкспериментировать с этим, в зависимости от того, в какой сфере вы работаете, — говорит она. — Мы тестировали результаты, и если они были хорошими, мы внедряли это в других командах. А если результаты были плохими, мы прекращали это и двигались дальше. Поэтому я думаю, что стратегия доступа и экспериментирования на раннем этапе действительно важна».</p> <h3>Определение надежных сценариев использования в производстве</h3> <p>По словам Рот, компании, опережающие конкурентов в области генеративного и агентного ИИ, — это те, кто превращает исследования в сервисы производственного уровня, в то время как отстающие этого не делают.</p> <p>«Успешные фирмы сейчас начинают говорить: „Хорошо, мы выбрали этот инструмент, и мы будем его использовать, и поэтому мы изменим наши бизнес-процессы, чтобы работать по-новому“, и тогда вы начинаете видеть улучшения и экономию», — говорит она, делая важное уточнение: «Однако по-прежнему кажется, что большинство компаний находятся на начальной стадии. Думаю, те, кто преуспевает, очень точно определяют свои сценарии использования».</p> <p>В Thomson Reuters конкретные сценарии использования сосредоточены на пяти ключевых областях: разработка ПО, поддержка и обеспечение успеха клиентов, маркетинг, редакционная и контентная деятельность, а также основные технологические операции.</p> <p>«Конечно, мы хотели бы улучшить работу каждого, и мы сделаем все возможное, — говорит Рот. — Но это пять основных областей, где мы видим наибольший прогресс, и им уделяется наибольшее внимание». Инструменты ИИ для этих областей отыскиваются, тестируются и внедряются, а затем измеряется их эффективность. Сегодня 87% сотрудников Thomson Reuters активно используют инструменты ИИ в своей повседневной работе.</p> <p>Итак, как выглядит успешное внедрение генеративного и агентного ИИ в масштабах всей организации, и как это изменило повседневную практику сотрудников?</p> <p>Рот приводит в пример службы поддержки клиентов и продаж, где сотрудники могут использовать внутреннюю платформу ИИ компании, известную как Open Arena, и передовую модель Claude.</p> <p>Вместо того чтобы тратить часы на сбор информации от торговых представителей и из платформы Salesforce, сотрудники могут использовать утвержденные сервисы ИИ для получения ответов на запросы за считанные секунды. «В этом новом мире вы можете написать запрос в Claude, чтобы получить эту информацию; он может составить вам сводку, понять, каковы ключевые возможности, где могут быть какие-либо риски для данного клиента, или обращался ли он недавно в службу поддержки и был чем-то недоволен, и вы можете гораздо быстрее хорошо подготовится к встрече», — рассказывает она.</p> <p>Сотрудники Thomson Reuters также используют ИИ для исследования рынка, составления документов и отслеживания прибыльности продуктов и услуг.</p> <p>Главное, что усвоила Рот при внедрении ИИ в производство, накопив за последние несколько лет немалый опыт внедрения ИИ в операционную реальность глобального коллектива из 27 тыс. человек, — это то, что бизнес-руководители должны усердно работать над преодолением страхов профессионалов.</p> <p>«Люди не любят перемен. Ключевым моментом на раннем этапе было разъяснение сути ИИ, а затем оставалось лишь дать людям возможность поэкспериментировать и, надеюсь, перестать бояться новых технологий, — говорит она. — Сейчас мы достигли гораздо более зрелого уровня, и, учитывая то, что нам удалось внедрить, я думаю, что направление развития и последовательность действий одинаково важны».</p> Исследования указывают на разрыв между амбициями в области искусственного интеллекта и реальной ситуацией … article https://www.itweek.ru/themes/detail.php?ID=235442 Tue, 01 Sep 2026 14:05:39 +0300 <p>SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.8.0 системы управления ИТ-активами SimpleOne ITAM. Обновление сокращает время инвентаризации оборудования, позволяет учитывать активы не только по складам, но и по конкретным офисам и кабинетам, а также избавляет финансовые службы от ручных расчетов при работе с затратами в разных валютах.</p> <p>Ключевым нововведением версии 1.8.0 стала возможность подключения сканера штрихкодов при проведении инвентаризации склада. Ранее в системе была реализована инвентаризация с помощью камеры мобильного телефона — теперь к задаче можно подключить внешний сканер, который считывает штрихкод с инвентарным номером актива. Это ускоряет обход крупных складов: сканер считывает метки быстрее и точнее камеры телефона, а данные сразу сверяются со списком активов и попадают в ведомость инвентаризации без ручного переноса.</p> <p>Дополнительно в системе появился новый тип задачи — инвентаризация по расположению. Она позволяет пересчитывать активы не по складам, а по фактическому месту их использования — конкретному офису, этажу или кабинету, даже если по учету оборудование числится за разными складами. Это особенно удобно для компаний с распределенной сетью офисов: можно провести точечную проверку одного подразделения, не запуская инвентаризацию всего склада.</p> <p>В 1.8.0 автоматизирован расчет совокупных затрат на актив с учетом конвертации валют. Раньше, если затраты на актив фиксировались в разных валютах, посчитать реальную стоимость владения оборудованием можно было только вручную, сводя данные в отдельных таблицах. Теперь система автоматически складывает все затраты по активу и автоматически приводит их к единой валюте по актуальному курсу. Финансовые и ИТ-руководители получают точную картину затрат на актив без дополнительных расчетов и могут быстрее принимать решения о ремонте, замене или списании оборудования.</p> <p>«Когда данные о том, где стоит актив и сколько он реально стоит, хранятся в одной системе, ИТ-отдел начинает говорить с финансами на одном языке. Решения о ремонте, замене или списании принимаются на цифрах, а не на ощущениях. Именно так выглядит зрелый подход к управлению ИТ-активами», — отметил Руслан Шарипов, генеральный директор SimpleOne, корпорация ITG.</p> <p>SimpleOne ITAM 1.8.0 уже доступна для действующих клиентов компании. Новые пользователи могут запросить демонстрацию продукта на сайте SimpleOne.</p> SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.8.0 системы управления ИТ-активами SimpleOne … message https://www.itweek.ru/themes/detail.php?ID=235441 Tue, 01 Sep 2026 09:51:32 +0300 <p>С 1 сентября вступает в силу норма об идентификации администраторов доменов в зонах .ru, .рф и .su через портал «Госуслуги» (ЕСИА). Однако в крупнейшем корпоративном регистраторе Руцентре по состоянию на 27 августа процедуру прошли лишь 42,2% администраторов, а в самом массовом регистраторе Рег.ру — 25,7% пользователей. Юридические лица могут пройти идентификацию только у одного регистратора в России — Руцентра.</p> <p>Компания по управлению онлайн-активами Руцентр провела исследование безопасности доменной инфраструктуры российских компаний. Одной из ключевых тем стал уровень готовности к идентификации через ЕСИА, которая вводится с 1 сентября 2026 года согласно Федеральному закону от 29.12.2025 № <nobr>569-ФЗ.</nobr> В крупнейших игроках рынка идентификацию прошли меньше половины пользователей — в Руцентре 43% администраторов, а в Рег.ру лишь 26,7%. Ежедневно эти цифры прирастают на несколько процентных пунктов. Совокупно эти два регистратора занимают долю в 68% Рунета. Основные сложности связаны с несовпадением данных — многие домены оформлены на устаревшие данные, вымышленные имена, бывших сотрудников и фрилансеров. </p> <p>Ключевым барьером для прохождения идентификации остается многолетняя практика регистрации корпоративных доменов на физические лица. В 2026 году в зоне .ru на долю физических лиц приходится 72,7% доменов, в зоне .рф — 82,9%. При этом среди топ-5000 полезных для пользователей сайтов Рунета на физлица зарегистрировано 32% ресурсов. В случае увольнения администратора или его недоступности компания рискует остаться без возможности продлить или перенести критически важный онлайн-актив. </p> <p>Важно отметить, что нормативно-правовые акты, разъясняющие формат применения новой нормы закона, еще не приняты. Закон устанавливает новый порядок регистрации, при котором регистрировать домены смогут только регистраторы из специального перечня. Порядок включения регистраторов в перечень будет определен Правительством Российской Федерации в ближайшее время. Координационный центр доменов .RU/.РФ уведомил регистраторов, что работа аккредитованных регистраторов продолжится по действующим правилам до включения в перечень, либо до 18 января 2027 года. Это означает, что ограничения на операции с доменными именами для администраторов, еще не прошедших идентификацию, с 1 сентября пока применяться не будут.</p> <p>Наряду с регуляторными изменениями эксперты Руцентра зафиксировали рост внешних киберугроз, связанных с брендовым фишингом. 38,5% компаний столкнулись с появлением сайтов-имитаторов, еще 35,9% — со сканированием доменной инфраструктуры и попытками перехвата управления. Это подтверждается и ростом объема Whois-запросов к доменам почти вдвое — до 95 млн. за полугодие, из которых 83 млн. пришлись именно на корпоративные домены. Чаще всего мишенями атак становятся крупные онлайн-площадки. Злоумышленники целенаправленно собирают данные о владельцах ресурсов для последующего фишинга или перехвата управления. В то же время защита учетных записей администраторов остается слабым звеном. Доля пользователей с включенной двухфакторной аутентификацией составляет лишь <nobr>15-16%.</nobr></p> <p>Дополнительным системным риском стал массовый отзыв иностранных SSL/TLS-сертификатов. С июня по август 2026 года удостоверяющие центры отозвали 6 997 сертификата, из которых 4677 — от GlobalSign. Причина — введение санкционных проверок клиентов по требованию международного консорциума CA/Browser Forum. Доля российских сертификатов в зоне .ru составляет менее 1%, как и доля устройств с установленными отечественными корневыми сертификатами. После отзывов активные сертификаты Национального удостоверяющего центра выросли на 7,7% за неделю, а Технического центра Интернет — в 4,5 раза с начала июня 2026 года.</p> <p>Руцентр провел исследование безопасности доменной инфраструктуры российских компаний уже во второй раз. Предыдущее исследование было выпущено в сентябре 2025 года. В 2026 году к созданию исследования присоединилась компания Технический центр Интернет, технический оператор российской национальной доменной зоны верхнего уровня, которая предоставила дополнительные данные о ситуации на рынке SSL/TLS-сертификатов. Как и в прошлый раз исследование содержит две части, включающие количественный и качественный анализ. Методология построена на анализе системных метрик и операционных показателей, отражающих состояние защищенности онлайн-активов на уровне всего доменного рынка в Российской Федерации. В опросе принимали участие представители ИТ- и ИБ-подразделений компаний, преимущественно из сегмента крупного бизнеса, — почти 40% компаний с численностью свыше 1000 сотрудников. Сбор и обработка данных проводились экспертами Руцентра в августе 2026 года.</p> С 1 сентября вступает в силу норма об идентификации администраторов доменов в зонах .ru, .рф и .su через … message https://www.itweek.ru/themes/detail.php?ID=235439 Tue, 01 Sep 2026 09:42:15 +0300 <p>Российский рынок частных облаков последние несколько лет активно смещается в сторону OpenStack — как альтернативы ушедшим вендорам и как основы для построения отечественных платформ. OpenStack давно перестал быть экзотикой для узкого круга энтузиастов, ведь на нём сегодня строятся частные облака у операторов, банков и промышленных компаний, которым нужен контроль над инфраструктурой без привязки к одному вендору. Но у этого перехода есть обратная сторона, о которой на старте проекта задумываются реже, чем стоило бы: облако на OpenStack нужно не только развернуть, но и потом годами обновлять, своевременно реагируя на выявленные бреши в безопасности, устанавливая новые релизы компонентов и удовлетворяя требования регуляторов. И если сам факт перехода на OpenStack давно перестал быть новостью, то вопрос «а как это облако вообще обновлять, когда придёт время» у большинства эксплуатирующих команд до сих пор упирается в ручной труд, дефицитную экспертизу и риск простоя. То есть проблема не в том, чтобы просто поднять OpenStack, а в том, чтобы удерживать его в рабочем и безопасном состоянии на протяжении всего жизненного цикла. Разберёмся, почему обновление OpenStack остаётся сложной инженерной задачей, какие этапы этого процесса можно автоматизировать и какие ограничения необходимо заложить в механизм обновления, чтобы автоматизация сама не стала источником риска.</p> <h2> Проблема, о которую спотыкается почти каждый оператор облака </h2> <p>OpenStack принято хвалить за гибкость и открытость, но за кулисами этой гибкости стоит один из самых болезненных процессов в жизненном цикле облачной платформы — обновление. В отличие от монолитных систем, OpenStack — это фреймворк из полутора-двух десятков взаимозависимых сервисов (Keystone, Nova, Neutron, Cinder, Glance, Placement и т. д.), каждый со своей базой данных, своими миграциями схемы, своим порядком запуска и своими требованиями к совместимости версий API. Обновить такую систему не значит «поставить новую версию пакета». Это значит провести десятки взаимосвязанных операций в строго определённой последовательности, не нарушив по пути ни одну зависимость.</p> <p>Именно поэтому в большинстве продуктивных инсталляций OpenStack обновление до сих пор остаётся ручной, экспертной и тревожной процедурой, а не рутинной операцией.</p> <h2>Что именно усложняет обновление OpenStack</h2> <p>Если разложить проблему на составляющие, получится примерно такой список (и он актуален независимо от того, разворачивается ли OpenStack «руками», через Ansible-плейбуки или через Kubernetes-операторы):</p> <ul> <li><strong>Порядок и зависимости сервисов.</strong> Часть компонентов должна обновляться раньше других — например, Keystone и Placement обычно идут в начале цепочки, а сервисы, зависящие от их API, следом. Ошибка в порядке приводит к рассинхронизации версий API между сервисами и падению запросов.</li> <li><strong>Миграции баз данных.</strong> Каждое обновление тянет за собой миграции схем в базах Nova, Neutron, Cinder и других сервисов. Некоторые миграции требуют «миграции данных без остановки» ещё на текущей версии — если этот шаг пропущен, обновление может завершиться с повреждением данных.</li> <li><strong>Простой сервисов управления и, в худшем случае, сетей и вычислительных ресурсов пользователей.</strong> Даже при аккуратном планировании слой управления обычно недоступен часть времени обновления. Плохо спроектированный процесс способен зацепить и вычислительные ресурсы пользователей — то есть повлиять на уже работающие виртуальные машины и пространство пользователей.</li> <li><strong>Непредсказуемое поведение при сбое посередине процесса.</strong> Полноценный откат обновления OpenStack на предыдущую версию сама по себе нетривиальная и рискованная операция: схемы БД уже частично мигрированы, часть контейнеров и конфигураций уже обновлена, и «просто вернуть как было» технически далеко не всегда возможно. Поэтому куда важнее другое качество процесса — способность вовремя остановиться в момент сбоя, не разрушив кластер, и точно показать администратору, на каком шаге и что пошло не так, вместо того чтобы продолжать обновление вслепую или бросить систему в непонятном промежуточном состоянии.</li> <li><strong>Человеческий фактор и разрыв компетенций.</strong> Классический процесс обновления — это последовательность команд в CLI, правка YAML-файлов инвентаря и конфигурации, запуск плейбуков с нужными флагами в нужном порядке. Уровень экспертизы, который для этого требуется, есть далеко не в каждой команде эксплуатации, а дефицит сертифицированных OpenStack-инженеров на рынке — известная проблема.</li> <li><strong>Долгий цикл патчинга безопасности.</strong> Когда обновление — это рискованный процесс и многочасовая процедура, а не «нажал кнопку и забыл», критические обновления безопасности откладываются дольше, чем следовало бы. Разрыв между выходом патча и его применением в продуктиве — это прямой риск для периметра.</li> <li><strong>Дрейф конфигурации между средами.</strong> В компаниях с несколькими окружениями (dev/test/prod) ручные обновления быстро приводят к тому, что конфигурации расходятся, и то, что сработало на тесте, ломается в проде именно из-за незамеченного отличия.</li> </ul> <h2>Как эти проблемы решаются (или не решаются) в разных реализациях OpenStack</h2> <p>Здесь стоит сразу отметить: экосистема способов развернуть OpenStack довольно широкая, и подход к обновлению принципиально различается в зависимости от выбранного инструментария.</p> <ul> <li> <strong>Kolla-Ansible</strong> (в том числе на связке с Docker или Podman) разворачивает сервисы в контейнерах и обновляет их через Ansible-плейбуки (kolla-ansible upgrade). Классически это <nobr>CLI-процедура:</nobr> инженер вручную правит globals.yml, инвентарь, версии тегов образов и запускает плейбук, понимая, что происходит на каждом шаге. Вынос процесса в CI/CD позволяет сделать обновление воспроизводимым и версионируемым, а также сократить количество ручных операций. Но сам по себе CI/CD не снимает требования к квалификации специалиста. Кто-то по-прежнему должен понимать структуру пайплайна, интерпретировать результаты выполнения отдельных стадий и принимать решение при ошибках. Поэтому автоматизация исполнения и автоматизация принятия решений при обновлении — это разные задачи.</li> <li> <strong>OpenStack-Ansible (OSA)</strong> концептуально близок к Kolla-Ansible, но использует <nobr>LXC-контейнеры</nobr> или venv вместо Docker/Podman-образов. Процесс обновления так же построен на плейбуках и так же требует ручного сопровождения и экспертизы.</li> <li> <strong>TripleO / director-based установки</strong> (классический подход Red Hat OpenStack Platform до недавних версий) добавляют ещё один слой сложности — undercloud и overcloud обновляются отдельно, а сам процесс исторически считался одним из самых трудоёмких в экосистеме.</li> <li> <strong>Charmed OpenStack от Canonical</strong> на базе Juju ближе всего к идее «графического» управления жизненным циклом: Juju GUI позволяет визуально управлять обновлением charms, что снижает порог входа по сравнению с чистым CLI, хотя полноценной автоматизации «в один клик» с предварительными проверками и остановкой на проблемном шаге это тоже не даёт из коробки.</li> <li><strong>MicroStack / Sunbeam</strong> (тоже Canonical, snap-based) упрощают обновления до команды snap refresh, но это решение ориентировано на небольшие и edge-инсталляции, а не на полномасштабные продуктивные облака.</li> <li><strong>Kubernetes-нативные подходы</strong> (OpenStack-Helm, Airship, а также коммерческий Mirantis OpenStack for Kubernetes) выигрывают за счёт того, что опираются на нативные механизмы Kubernetes — поэтапное обновление, readiness/liveness probes, helm rollback. Именно в этом сегменте чаще всего встречаются продукты с полноценным веб-интерфейсом управления обновлениями, потому что Kubernetes-примитивы изначально спроектированы для автоматизации подобных процессов.</li> </ul> <p>Общий вывод, к которому подводит этот обзор, хочется сформулировать следующим образом. Проблема «обновление зависит от инженера с CLI» и проблема «обновление недоступно как самообслуживаемая операция» — это два разных уровня, и решаются они не одним и тем же шагом. Вынос процесса в CI/CD (как в случае с GitLab у связки Kolla-Ansible/Podman) решает первую: обновление становится воспроизводимым, версионируемым и не требует ручных команд в терминале. Но оно не решает вторую — запустить и проконтролировать пайплайн по-прежнему может только тот, кто ориентируется в GitLab, а не в продукте, которым он управляет. Поэтому интерфейс с кнопкой запуска сам по себе ещё не делает обновление автоматизированным. Существеннее то, какие проверки выполняются до старта, как система учитывает зависимости компонентов, может ли она остановить процесс при ошибке и насколько подробно сообщает администратору о состоянии инфраструктуры. Именно эти механизмы определяют, можно ли передать часть решений от инженера автоматике.</p> <h2>Что должно скрываться за кнопкой автоматического обновления</h2> <p>Автоматизация обновления OpenStack не сводится к переносу последовательности команд из CLI в CI/CD. Пайплайн может выполнять подготовленные операции, фиксировать стадии и сохранять результаты их выполнения. Но сам по себе он не определяет, какие действия допустимы в текущем состоянии инфраструктуры, в какой последовательности их выполнять и когда процесс необходимо остановить.</p> <p>Поэтому поверх исполнительного слоя нужна логика, которая учитывает зависимости сервисов OpenStack, совместимость версий, состояние узлов и результаты проверок после каждого этапа. Иначе автоматизируется только запуск команд, а принятие решений по-прежнему остается на инженере.</p> <p>При этом важно разделять два разных процесса: обновление хостовой операционной системы и переход на новую версию самого OpenStack. Внешне они похожи, но предъявляют разные требования к последовательности операций и допустимому уровню параллелизма.</p> <h3>Патчинг хостовой ОС: ротация узлов</h3> <p>При установке пакетов и обновлений безопасности на контроллерах и гипервизорах можно использовать принцип последовательной ротации.</p> <p>Контроллер выводится в режим обслуживания, получает обновления, при необходимости перезагружается и возвращается в кластер. Только после проверки его состояния процесс переходит к следующему узлу. Пока один контроллер обслуживается, остальные продолжают обрабатывать запросы, что позволяет сохранить доступность управляющего слоя.</p> <p>Для гипервизоров возможна другая схема: обновление по одному узлу или группами в пределах зоны доступности. Размер такой группы должен учитывать доступный запас вычислительных ресурсов. Перед обслуживанием с гипервизора переносятся виртуальные машины, сам узел выводится из эксплуатации, обновляется и после проверки возвращается в строй.</p> <p>Одновременно выводить в обслуживание все гипервизоры одной зоны доступности нельзя. Поэтому механизм автоматизации должен ограничивать уровень параллелизма и учитывать, достаточно ли оставшихся ресурсов для размещения нагрузки.</p> <p>Такая схема особенно важна для установки обновлений безопасности. Ее задача не просто ускорить патчинг, а формализовать операции, которые при ручном выполнении зависят от последовательности действий конкретного инженера: миграцию нагрузки, перевод узла в обслуживание, установку обновлений, перезагрузку и проверку его состояния перед переходом к следующему этапу.</p> <h3>Обновление версии OpenStack: почему поэтапность не всегда означает меньший риск</h3> <p>При переходе между версиями OpenStack логика сложнее. До начала обновления нужно определить, поддерживается ли переход между исходным и целевым релизами. Для этого может использоваться заранее подготовленная матрица совместимости, учитывающая версии компонентов и допустимые маршруты обновления.</p> <p>Отдельный вопрос — порядок обновления контроллеров. Интуитивно безопасной кажется последовательная схема, при которой узлы переводятся на новую версию один за другим. Однако для конкретной архитектуры такой подход необходимо проверять с учетом совместимости API и компонентов. Если часть сервисов уже работает на новой версии, а часть остается на старой, может возникнуть период, когда управляющий слой работает в несогласованном состоянии.</p> <p>Поэтому последовательность операций должна определяться не универсальным принципом «обновлять по одному», а особенностями конкретного релиза и архитектуры развертывания.</p> <p>Не менее важен контроль состояния системы во время перехода. До старта должны выполняться системные проверки. После критических операций необходимо проверять работоспособность компонентов. Если очередная проверка не пройдена, дальнейшие действия следует остановить и зафиксировать этап, на котором возникла ошибка.</p> <p>Для OpenStack такой сценарий зачастую безопаснее попытки автоматически вернуть всю систему в исходное состояние. Если часть схем баз данных уже мигрирована, а некоторые компоненты обновлены, полноценный откат может оказаться отдельной сложной и рискованной процедурой. Поэтому от механизма автоматизации требуется прежде всего контролируемая остановка и точная диагностика.</p> <p>Очередность обновления контроллеров и гипервизоров также должна учитывать зависимости между управляющим и вычислительным слоями. Переход вычислительных узлов на новую версию следует начинать только после того, как управляющий слой приведен в согласованное состояние. После этого гипервизоры можно обновлять по одному или группами, предварительно освобождая их от пользовательской нагрузки.</p> <h3>Что именно нужно автоматизировать</h3> <p>При оценке механизма обновления OpenStack важно смотреть не только на инструмент, который исполняет команды. Ansible, CI/CD или Kubernetes позволяют автоматизировать значительную часть технических операций, но сами по себе не определяют, можно ли выполнять конкретное обновление в текущем состоянии инфраструктуры.</p> <p>Более высокий уровень автоматизации появляется там, где формализована логика принятия решений: проверяется допустимость перехода между версиями, учитывается состояние компонентов, контролируется размер одновременно обслуживаемой группы узлов, соблюдается очередность между управляющим и вычислительным слоями, а дальнейшие действия блокируются при возникновении ошибки.</p> <p>Именно поэтому перенос команд из терминала в пайплайн решает только часть задачи. Он делает процесс воспроизводимым и версионируемым, но не заменяет механизм управления жизненным циклом облачной платформы.</p> <h3>Что должен видеть администратор</h3> <p>Способ запуска обновления вторичен. Это может быть CLI, CI/CD или графический интерфейс. Гораздо важнее, какую информацию получает администратор до начала процесса и во время его выполнения.</p> <p>До старта обновления должны быть понятны текущие версии компонентов, доступный целевой релиз, результаты предварительных проверок и ограничения выбранного сценария. Во время обновления необходимы данные о текущем этапе, состоянии узлов и возникших ошибках.</p> <p>Задача интерфейса в данном случае не в том, чтобы скрыть сложность OpenStack за одной кнопкой. Он должен дать администратору понятную точку управления процессом, тогда как правила последовательности, совместимости и безопасной остановки должны соблюдаться автоматически.</p> <h3>От чего зависит длительность обновления</h3> <p>Продолжительность обновления нельзя свести к одному нормативному значению. Она зависит от числа узлов, состава компонентов, объема миграций, пользовательской нагрузки и расстояния между исходным и целевым релизами.</p> <p>Последовательный переход между соседними релизами, как правило, требует меньше промежуточных изменений. Если же обновление затрагивает несколько релизов, приходится учитывать больше изменений в компонентах, схемах баз данных и конфигурациях.</p> <p>Отдельно в технологическое окно закладывается время на освобождение гипервизоров от нагрузки, миграцию виртуальных машин, обслуживание узлов и проверки после обновления. Поэтому задача автоматизации состоит не только в сокращении общей продолжительности процедуры. Не менее важно сделать состав операций и их последовательность предсказуемыми, чтобы окно обслуживания можно было планировать заранее.</p> <h3>Почему обновление нужно тестировать заранее</h3> <p>Автоматизация не отменяет предварительной подготовки обновления. Для каждого поддерживаемого перехода необходимо проверить совместимость компонентов, миграции баз данных, последовательность операций и работу основных сценариев после установки новой версии.</p> <p>Чем больше расстояние между исходным и целевым релизами, тем больше промежуточных изменений приходится учитывать. Поэтому наличие новой версии OpenStack еще не означает, что на нее можно безопасно перейти из любого предыдущего состояния.</p> <p>Для эксплуатации это означает, что маршрут обновления должен быть заранее определен и протестирован. Автоматический механизм затем воспроизводит уже проверенную последовательность, контролируя состояние системы на каждом критическом этапе.</p> <h2>Когда обновление OpenStack действительно можно считать автоматизированным</h2> <p>Кнопка запуска сама по себе еще не делает обновление автоматическим. За ней может находиться тот же набор команд, который раньше инженер последовательно выполнял вручную.</p> <p>Более зрелый подход начинается с автоматизации не только исполнения, но и части решений. Система проверяет состояние инфраструктуры до старта, учитывает совместимость версий и зависимости компонентов, ограничивает потенциально опасный параллелизм, контролирует результат отдельных операций и прекращает дальнейшие действия, если состояние системы отклоняется от ожидаемого.</p> <p>При этом полностью исключить инженерную экспертизу невозможно. OpenStack остается сложной распределенной системой, а нестандартные ошибки могут требовать ручной диагностики. Задача автоматизации в другом: убрать из регулярного процесса повторяющиеся операции и решения, которые можно формализовать, снизить зависимость результата от ручных действий и оставить специалистам действительно нестандартные ситуации.</p> <p>Поэтому зрелость механизма обновления определяется не количеством операций, сведенных к одному нажатию, а тем, насколько предсказуемо система проходит штатный сценарий и насколько управляемо ведет себя при возникновении ошибки. По мере роста OpenStack-инфраструктуры такая автоматизация становится частью управления ее жизненным циклом, поскольку без нее увеличиваются трудозатраты на эксплуатацию и зависимость от ручных операций.</p> <p> #IMAGE_235440#</p> Российский рынок частных облаков последние несколько лет активно смещается в сторону OpenStack — как альтернативы … article Кирилл Острогожский, архитектор компании ITKey https://www.itweek.ru/themes/detail.php?ID=235438 Tue, 01 Sep 2026 09:20:51 +0300 <p><em>Финансовые, а не инженерные аспекты губят проекты по внедрению агентного искусственного интеллекта. Поскольку объем телеметрических данных в ближайшие два года вырастет на порядок, конвейеры наблюдаемости становятся контрольным звеном, сообщает портал </em><em>The</em> <em>New</em> <em>Stack</em><em>.</em></p> <p>По мере того как компании переходят от экспериментов с ИИ к запуску автономных агентов в производственной среде, возникает проблема, связанная с инфраструктурой: растущие расходы на телеметрию. Недетерминированные, итеративные агенты, способные генерировать данные со скоростью машин, гораздо сложнее поддаются мониторингу, а расходы на них спрогнозировать гораздо сложнее, чем в случае с обычными приложениями.</p> <p>Многие компании испытывают трудности с выделением и обоснованием расходов на телеметрию. Согласно <a href="https://www.prnewswire.com/news-releases/new-apica-research-agentic-ai-poised-to-trigger-9-5x-telemetry-data-explosion-leaving-most-enterprises-exposed-302789312.html">опросу</a> более 300 руководителей в сфере корпоративных ИТ в Северной Америке и Западной Европе, проведенному Omdia/Informa TechTarget по заказу Apica, 59% организаций уже прекратили или отложили внедрение ИИ-агентов из-за расходов на мониторинг.</p> <p>Чаще всего это происходит при внедрении ИИ-агентов в критически важных областях: например, в сферах кибербезопасности, соблюдения нормативных требований и выявления мошенничества. По мере роста расходов на мониторинг, проекты по внедрению ИИ-агентов далеко не всегда закрываются по инициативе инженерных команд. Чаще всего их закрывает финансовый отдел.</p> <p>Энди Манн, директор по продуктам и технологиям Apica, недавно стал свидетелем того, как это произошло в одном крупном банке. Организация не смогла точно определить свои затраты на программы ИИ. «Они поняли, что не могут позволить себе продолжать в том же духе, поэтому у них не было другого выбора, кроме как отменить некоторые программы ИИ, — рассказывает он. — Я уже сталкивался с такими вещами, потому что ИИ-проекты легко съедают типичные бюджеты».</p> <p>Последствия огромны. По мере того, как люди, финансирование и ресурсы мониторинга перенаправляются на новые рабочие нагрузки ИИ, другие подразделения бизнеса начинают страдать. Манн говорит, что он видит перебои в работе, простои и атаки с проникновением, а средства защиты от DDoS-атак конкурируют за одни и те же ресурсы.</p> <p>Исследование Apica также выявило эту проблему. Только за последний год на большинстве предприятий (54%) объем телеметрии утроился, причем 43% этого роста приходится на рабочие нагрузки ИИ/машинного обучения, что, безусловно, является основным фактором. Предприятия вынуждены бороться с этим кризисом, поскольку их расходы на наблюдаемость растут. Они сообщают, что тратят в среднем 3,17 млн. долл. на обеспечение наблюдаемости, причем эта цифра растет на 28% в годовом исчислении и предела этому росту не видно. Неудивительно, что 83% опрошенных считают ИИ-наблюдаемость главным приоритетом на ближайший год.</p> <h3>Грядущая волна может оказаться катастрофической</h3> <p>При появлении нового облачного сервиса, базы данных или приложения нагрузка на систему мониторинга и объем телеметрических данных обычно увеличиваются на относительно предсказуемую величину. Но сейчас компании прогнозируют, что в течение двух лет объем телеметрических данных вырастет в среднем в 9,5 раза. Около 44% организаций ожидают, что объем телеметрических данных вырастет в <nobr>6-100 раз.</nobr></p> <p>«Представьте, что ваш счет по кредитной карте или чек из супермаркета выросли почти на порядок. Это уже не просто увеличение. Это не плавный рост, а стремительный взлет, и это вызывает панику», — говорит Манн.</p> <p>Причина в том, что работа агента — это не то же самое, что отдельный запрос к приложению. Задача службы поддержки может включать в себя трассировку верхнего уровня, несколько вызовов модели, операции извлечения данных, вызовы инструментов, повторные попытки и циклы. Но если агент делегирует работу другому агенту, это добавляет в трассировку еще одну ветвь.</p> <p>Каждая модель может генерировать данные о токенах, задержках, затратах и поставщиках, а каждый вызов инструмента создает собственные записи об аргументах, результатах, статусе и последующих действиях. Идентификаторы, такие как <em>tool_name</em>, <em>agent_id</em> и <em>trace_id</em>, также создают избыточность данных, из-за чего их сложнее агрегировать и дороже индексировать, и затраты растут на каждом этапе.</p> <p>Это создает ощутимый разрыв между амбициями в области ИИ и готовностью инфраструктуры. Несмотря на то, что 35% компаний заявляют о широком внедрении агентного ИИ, эксплуатация и управление такими системами сильно отличаются от того, что было раньше. Почти две трети компаний лишь в некоторой степени готовы к таким изменениям. В отличие от обычных приложений, агенты могут вызывать множество моделей и инструментов, повторно выполнять задачи или расширять рабочий процесс непредсказуемым образом, из-за чего сложно спрогнозировать затраты на обеспечение производительности и мониторинг.</p> <h3>От огромных затрат на телеметрию до уровня контроля на входе</h3> <p>По словам Манна, решение заключается в том, чтобы вмешаться на более ранних этапах. «Нельзя бесконечно отправлять практически бесполезные данные на дорогостоящую центральную аналитическую платформу или платформу хранения данных, потому что нет смысла анализировать данные, которые говорят о том, что все в порядке, — говорит он. — Как можно раньше подключите конвейер к сборщикам данных и управляйте ими на уровне источника».</p> <p>Традиционные платформы наблюдаемости ориентированы на сбор данных, их прием, хранение и индексацию, а затем анализ. Такая модель подходила для рабочих процессов, управляемых людьми и анализируемых с помощью дашбордов, но для агентного ИИ необходимо принимать решения до того, как телеметрия дойдет до наиболее затратных частей стека.</p> <p>Архитектура, ориентированная на конвейер, позволяет отбирать повторяющиеся успешные события, сохраняя при этом данные о сбоях, повторных попытках, нарушениях политик и аномально медленных трассировках. Она позволяет дополнять записи данными об агенте, сеансе, модели, инструменте, токене и предполагаемой стоимости, удалять конфиденциальные запросы и идентификаторы, а также агрегировать метрики и долгосрочные записи и отправлять их в места назначения с разными профилями затрат и хранения.</p> <p>Компактная метрика или выборка могут отражать обычный успешный вызов инструмента, в то время как при неудачном вызове сохраняется родительская трассировка, сведения об ошибке, история повторных попыток и контекст безопасности. Цель состоит в том, чтобы сохранить информацию, необходимую для объяснения поведения агента, сократив при этом объем избыточных данных и ограничив объем индексируемой информации.</p> <p>Агентам также необходим контекст на уровне миллисекунд для принятия автономных решений. Обработка телеметрии в непосредственной близости от источника позволяет организациям быстро выявлять ситуации, когда происходит слишком много повторных попыток, чрезмерное количество циклов использования инструментов или аномально высокий расход токенов, не дожидаясь, пока данные будут собраны и проиндексированы централизованно.</p> <p>Без контроля на уровне источника компании рискуют передавать фрагментированные и ненужные телеметрические данные на платформы, которые взимают плату за каждый дополнительный гигабайт, индекс и сохраненную запись.</p> <h3>Архитектура, которая отделяет победителей от проигравших</h3> <p>Трудно не заметить, насколько выгоден подход, при котором переосмысливается конвейер сбора телеметрических данных. Использующие его компании на 50% лучше подготовлены к росту объемов данных, связанному с агентным ИИ. Именно внедрение такого подхода выделяет зрелые организации, использующие агентный ИИ, на фоне конкурентов: такие организации на 80% реже сталкиваются с проблемами, связанными с операционными расходами, которые мешают их конкурентам.</p> <p>Решение заключается в том, чтобы перенести аналитические функции на более ранние этапы. Вместо того чтобы рассматривать платформу наблюдаемости как универсальный инструмент, компании могут принимать решения о том, какие телеметрические данные использовать, еще до того, как они попадут на платформу, — отфильтровывая ненужную информацию, выделяя то, что действительно важно, и маршрутизируя данные в соответствии с их ценностью и назначением. Это означает, что в дорогостоящие системы хранения и анализа будет поступать меньше данных, а та информация, которая все же попадет в эти системы, будет более полезной и доступной в режиме реального времени.</p> <p>Важно отметить, что речь не идет о полном отказе от платформ наблюдаемости, на которые уже полагаются компании. Речь идет о том, чтобы создать перед ними более интеллектуальный контрольный слой, который будет решать, какие данные заслуживают обработки, куда их следует направлять и сколько это будет стоить.</p> <p>Существующие платформы наблюдаемости по-прежнему играют важную роль. «Конвейер не может делать все, но он может взять на себя первичную обработку данных, — говорит Манн. — Вы по-прежнему работаете с крупными аналитическими платформами, но при этом экономите деньги, снижаете риски и повышаете эффективность соблюдения нормативных требований».</p> <p>Согласно исследованию Apica, контрольный конвейер, базовые метрики и сервисы подготовки данных позволяют снизить совокупную стоимость владения на 40% по сравнению с унаследованными платформами наблюдаемости. Разумеется, фактическая экономия будет зависеть от объемов телеметрии, политики хранения данных, правил выборки, решений по маршрутизации, действующих контрактов и доли данных, которые можно обработать до приема в систему.</p> <p>Сейчас самое время пересмотреть архитектуру. Около 68% компаний планируют в течение следующих шести месяцев оценить изменения в своей системе наблюдаемости, а почти четверть из них заявляют, что существующие отношения с поставщиками не будут играть существенной роли при принятии этих решений. Следующий этап развития системы наблюдаемости будет связан с умением справляться с тем, что ИИ будет «выбрасывать» в инфраструктуру.</p> <p>Это означает, что конвейер больше нельзя рассматривать как систему, которая просто перемещает телеметрические данные из пункта А в пункт Б. Он становится управляющим слоем для все более автономной и требовательной к данным среды.</p> <p>Организации, которые создадут инфраструктуру, готовую к работе с агентным ИИ, смогут снизить затраты на наблюдаемость и повысить эффективность управления рисками. Манн не считает, что у платформенных инженеров и SRE-команд есть большой выбор. «Это уже становится решением на уровне совета директоров, — говорит он. — В конечном счете, это выбор того, насколько разумно вы можете позволить себе вести свой бизнес».</p> Финансовые, а не инженерные аспекты губят проекты по внедрению агентного искусственного интеллекта. Поскольку … article https://www.itweek.ru/themes/detail.php?ID=235436 Mon, 31 Aug 2026 18:03:03 +0300 <p>Аналитический центр проекта STAQ, предназначенного для цифровизации бизнес-процессов, провел исследование, направленное на выявление наиболее востребованных направлений использования платформенных решений в ключевых отраслях России в 1 полугодии 2026 года. Данные были получены по итогам анализа проектной практики STAQ за 1 полугодие 2026 года.</p> <p>По данным анализа проектов и клиентских запросов STAQ за январь-июнь 2026 года наиболее активно платформенные решения применялись в трёх ключевых отраслях: промышленное производство, розничная торговля и транспорт. Помимо этих индустрий, можно выделить строительство и управление инфраструктурными объектами, добывающую промышленность, телекоммуникации, агропромышленный комплекс и финансовый сектор. В этих сегментах платформы востребованы прежде всего для управления заявками и инцидентами, контроля эксплуатации оборудования, координации выездных сотрудников и соблюдения SLA. </p> <p>Существуют важные причины востребованности платформ в данных отраслях. Первая причина — высокая стоимость простоев и операционных ошибок. Остановка производственной линии, кассового оборудования, склада или транспортного узла быстро приводит к прямым финансовым потерям, нарушению графиков и снижению качества обслуживания. Вторая причина — большое число распределенных процессов. Предприятиям нужно одновременно управлять оборудованием, заявками, сотрудниками, выездными бригадами и подрядчиками на сотнях объектов. Третья причина — переход от разрозненной автоматизации к единому цифровому контуру. Компании стремятся связать существующие ERP, WMS, POS, MES, SCADA, IoT-системы и внутренние базы данных без полной перестройки ИТ-ландшафта.</p> <p>На промышленных предприятиях платформенные решения чаще всего использовались по следующим направлениям: управление производственными заданиями и сменной отчетностью, техническое обслуживание и ремонт оборудования, мониторинг технологических параметров с использованием IoT и SCADA, управление качеством, инцидентами и отклонениями. Отдельное направление — задачи, которые традиционно относят к контуру MES: сменные задания, отчётность по выпуску, регистрация отклонений и контроль исполнения на уровне цеха. </p> <p>По данным аналитиков STAQ, в среднем по проектам, применение платформ на производственных предприятиях в 1 полугодии 2026 года позволило в сравнении с показателями до внедрения: сократить затраты на внеплановые ремонты на 21%, уменьшить количество незапланированных простоев на 28%, ускорить реакцию на выявленные дефекты на 16%. Данные начали использоваться не только для отчетности. Система автоматически формирует задачу при обнаружении отклонения, назначает ответственного, контролирует срок выполнения и сохраняет результат.</p> <p>Основными направлениями использования платформ в розничной торговле стали: централизация заявок от магазинов и других торговых объектов, обслуживание касс, холодильников, торговых автоматов и инженерных систем, управление мерчандайзерами, техническими специалистами и подрядчиками, контроль SLA, наличия товаров и качества обслуживания торговых точек. Вместо обращений по телефону, электронной почте и в мессенджерах торговая сеть получает единую точку входа. Заявки автоматически распределяются по региону, типу проблемы, приоритету и компетенции исполнителя. В одном из проектов STAQ была централизована обработка заявок более чем из 300 магазинов. В сравнении с периодом до внедрения сроки исполнения заявок сократились на 30%, количество случаев отсутствия товара из-за отказов оборудования уменьшилось на 50%, более 20% заявок стали обрабатываться без участия человека, а среднее число заявок, закрываемых одним диспетчером за смену, выросло на 60%.</p> <p>В транспортно-логистической отрасли платформы применялись для управления техническим состоянием транспорта и инфраструктуры, планирования ТОиР и внеплановых ремонтов, диспетчеризации и контроля исполнения рейсов, обработки ИТ- и инфраструктурных инцидентов, управления подрядными перевозчиками и соблюдения SLA. В одном из проектов STAQ для крупной логистической компании количество инцидентов, влияющих на операционные процессы, сократилось на 47%, выполнение SLA по критичным системам достигло 94%, а простои стоек регистрации уменьшились на 62%. Интеграция с ERP также позволила ускорить закупку запасных частей на два дня. Основной результат использования платформ для транспортно-логистической отрасли — сокращение незапланированных остановок и переход от ручной диспетчеризации к управлению на основании данных.</p> <p>Во 2 полугодии 2026 года STAQ ожидает сохранения спроса на платформенные решения со стороны промышленности, ритейла и логистики, но при более консервативном отношении к ИТ-бюджетам: в приоритете будут проекты с измеримой и быстрой окупаемостью, а повестка сместится с роста выручки на сокращение операционных затрат. Изменится характер проектов: компании будут чаще переходить от автоматизации отдельного процесса к тиражированию решений на несколько площадок. Основными направлениями развития станут: предиктивное обслуживание оборудования на основе IoT-данных, применение ИИ для классификации заявок, выявления отклонений и поддержки диспетчеров, объединение производственных, эксплуатационных и сервисных процессов на одной платформе. Кроме того, компании осуществят более глубокую интеграцию с ERP, WMS, POS, MES и SCADA. </p> <p>«В 1 полугодии 2026 года платформенный подход вышел за рамки простой замены бумажных процессов цифровыми. Компании используют платформы как операционный контур, который связывает оборудование, сотрудников, подрядчиков и управленческую аналитику. Мы видим, что ожидания от предиктивной аналитики и ИИ сегодня опережают готовность данных: пока не выстроен учёт оборудования, заявок и истории ремонтов, модели не на чем обучать. Поэтому ближайший этап для большинства компаний — не новые технологии, а качество эксплуатационных данных», — отметил Евгений Гусев, генеральный директор STAQ.</p> Аналитический центр проекта STAQ, предназначенного для цифровизации бизнес-процессов, провел исследование, направленное … message https://www.itweek.ru/themes/detail.php?ID=235435 Mon, 31 Aug 2026 18:01:51 +0300 <p>Концепция Bring Your Own Device (BYOD), когда сотрудники работают с личных гаджетов, окончательно закрепилась в российской корпоративной практике. По оценке экспертов «Кросстеха», до 90% сотрудников организаций используют личные устройства для решения рабочих задач. Внедрение BYOD или отдельных элементов концепции выгодно бизнесу, так как позволяет сократить расходы на оборудование и создать более комфортные условия работы для сотрудников. При этом зачастую внедрение происходит без должной подготовки, что потенциально может привести к серьезным инцидентам информационной безопасности. Около 70% организаций внедряют этот подход с ошибками, создавая дополнительные киберриски, которые могут приводить к утечкам данных и другим инцидентам информационной безопасности безопасности</p> <p>Главная ошибка — попытка управлять чужой техникой через крайности. Первая крайность — полная вседозволенность. Когда компания не задает правил, менеджер скачивает договор на личный смартфон, чтобы доработать его вечером дома. Если этот телефон потеряется в такси или попадет в руки ребенку, который случайно установит вредоносную игру, корпоративная тайна мгновенно станет публичной. </p> <p>Вторая крайность — тотальная слежка и гиперопека. Когда отдел безопасности требует установить на личный ПК программы, которые отслеживают все действия пользователя, сотрудники воспринимают это как вторжение в личную жизнь. В ответ возникает «Теневое ИТ»: вместо разрешенных каналов специалисты начинают тихо пересылать рабочие документы в личные мессенджеры и сторонние хранилища, полностью скрывая эти процессы от компании.</p> <p>«Адекватный путь внедрения BYOD строится не на полном контроле устройства, а на понятном разделении личного и рабочего пространства. Главный принцип — компании должно быть важно только то, как обрабатываются ее данные, а не то, чем занимается человек в свое свободное время на своем устройстве», — говорит Егор Норкин, архитектор ИБ компании «Кросстех».</p> <p>Наиболее эффективный подход к BYOD строится на трех ключевых мерах: изоляции рабочего контура на личных устройствах, разграничении доступа к критичным системам и прозрачных правилах взаимодействия. На смартфонах рабочая среда прячется в зашифрованный контейнер, исключающий утечки и позволяющий точечно удалить данные компании при увольнении. Для домашних ПК организуется защищенный доступ через выделенные рабочие столы без прямой связи с внутренней сетью, а все требования к технике, компенсации и технической поддержке фиксируются в понятном регламенте. </p> <p>«ИБ сегодня — это баланс между сохранностью данных, бизнес-целями и комфортом людей. Бизнес всегда в приоритете, но рабочие процессы должны быть устроены так, чтобы они не были уязвимы. BYOD — отличная концепция, если решить это уравнение правильно. Сделать личную технику сотрудников безопасной абсолютно реально: достаточно грамотно оценить риски, разграничить корпоративный контур и уходить в крайности», — отметил Егор Норкин.</p> Концепция Bring Your Own Device (BYOD), когда сотрудники работают с личных гаджетов, окончательно закрепилась … message https://www.itweek.ru/themes/detail.php?ID=235434 Mon, 31 Aug 2026 12:42:28 +0300 <p>Компания «РЕД СОФТ» объявила о выпуске корректирующего релиза операционной системы РЕД ОС 8.0.3 для архитектуры ARM. Система адаптирована для широкой линейки ARM-оборудования — от российских процессоров «Байкал» до популярных одноплатных компьютеров.</p> <p>РЕД ОС под ARM может применяться при создании встраиваемых систем, IoT-устройств, учебных стендов и серверных решений, требующих энергоэффективности. Использование единой операционной системы на всех типах устройств позволяет унифицировать ИТ-инфраструктуру предприятия, упростить администрирование и сократить расходы на поддержку.</p> <p>Образы РЕД ОС 8.0.3 для ARM доступны для скачивания на официальном сайте РЕД ОС.</p> <p>Совместимость РЕД ОС с архитектурой ARM продолжает расширяться. В новом релизе дополнен перечень поддерживаемых одноплатных компьютеров, востребованных на рынке.</p> <p>Функциональность образов РЕД ОС 8.0.3 полностью идентична версии для архитектуры x86_64. Полный список изменений и нововведений, вошедших в релиз РЕД ОС 8.0.3, доступен на сайте РЕД ОС.</p> <p>Важным отличием от предыдущего релиза является то, что теперь в одном образе объединена поддержка сразу нескольких ARM-устройств. На этапе установки можно выбрать требуемое устройство, и система будет установлена с соответствующим устройству ядром Linux. «Из коробки» поддерживаются следующие устройства:</p> <ul> <li>платформы на базе процессоров Huawei Kunpeng и Ampere Altra;</li> <li>устройства от «Элпитех» на базе процессоров Байкал-М, а также Байкал-S;</li> <li>устройства от ГК «Аквариус» на базе процессора Байкал-М;</li> <li>устройства от «Гравитон» на базе процессора Байкал-М.</li> </ul> <p>Расширена поддержка популярных одноплатных платформ, широко используемых в образовании, робототехнике, промышленной автоматизации и IoT-проектах. В список поддерживаемых РЕД ОС устройств добавлены новые модели: Raspberry Pi 3+ и Orange Pi Zero 3. Кроме того, обновлены образы для уже поддерживаемых платформ: Raspberry Pi 4/5, ROCKPro64, Orange Pi Zero 2W, Orange Pi 3 LTS и Repka Pi 4 Optimal. </p> <p>Пользователям доступен выбор из нескольких вариантов окружения рабочего стола: KDE Plasma, MATE или GNOME. Также доступна минимальная конфигурация без графики.</p> <p>РЕД ОС 8 под ARM была сертифицирована ФСТЭК России в декабре 2025 года. Сертифицированная РЕД ОС 8 под ARM поддерживает платформы на базе процессоров Huawei Kunpeng и Ampere Altra и ряд устройств на процессоре Байкал-М. Ведется работа над расширением поддерживаемых устройств на архитектуре ARM в Сертифицированной редакции РЕД ОС 8.</p> <p>«РЕД ОС 8.0.3 для ARM — это качественное обновление продукта для распространенных в России ARM-устройств. Все образы полностью сохраняют функциональность, идентичную версии для x86_64, что открывает ещё больше сценариев использования. В дальнейшем мы продолжим расширять перечень поддерживаемых устройств и совершенствовать механизмы развёртывания, чтобы каждый пользователь мог найти оптимальное решение для своих задач», — отметил Рустам Рустамов, заместитель генерального директора РЕД СОФТ.</p> Компания «РЕД СОФТ» объявила о выпуске корректирующего релиза операционной системы РЕД ОС 8.0.3 для архитектуры ARM … message https://www.itweek.ru/themes/detail.php?ID=235433 Mon, 31 Aug 2026 12:40:41 +0300 <p><span>Компания</span><span> Axiom JDK (АО</span> <span>«Аксиом») представила исследование о</span> <span>том, как российские компании управляют версиями Spring Boot, планируют миграцию и</span> <span>оценивают риски после окончания публичной поддержки. Сегодня международная поддержка Spring недоступна российским заказчикам на</span> <span>стандартных условиях. При этом 55,8% Java-разработчиков не</span> <span>определили срок эксплуатации Spring без публичных обновлений, 61,2% отметили практическую ценность расширенной поддержки, но</span> <span>только 26,9% уже используют или готовы рассматривать</span> <span>её. В</span> <span>опросе приняли участие более 300 специалистов в</span> <span>области Java-разработки, 87,8% из</span> <span>которых регулярно используют Spring</span> <span>— самый распространённый фреймворк для разработки Java-приложений в</span> <span>России.</span></p> <p>Исследование отражает прежде всего ситуацию в крупном бизнесе и финансовой отрасли: 71,1% участников работают в организациях численностью более 1000 сотрудников, 56,1% представляют финтех. Таким образом, риски окончания поддержки Spring затрагивают не только команды разработки, но и Java-приложения, обеспечивающие ключевые процессы банков, крупных компаний и цифровых сервисов.</p> <p>Наиболее распространённым поколением остаётся Spring Boot 3.x: его используют 83,7% участников. Spring Boot 2.x продолжает применять 21,2%, Spring Boot 4.x — 26%. Близкую картину показывает исследование State of Java 2026 компании JUG Ru Group: версии 2.x используют 20,4% опрошенных пользователей Spring, 3.x — 73,1%, 4.x — 24,7%.</p> <p>Публичные обновления версий Spring Boot выпускаются ограниченное время — для промежуточных веток около 13 месяцев. После завершения этого периода компании должны перейти на новую версию, сопровождать используемую ветку самостоятельно или использовать коммерческую поддержку.</p> <p>В июне 2026 года завершился выпуск публичных обновлений для Spring Boot 3.5 — наиболее распространённого поколения среди участников исследования. Международная коммерческая поддержка Spring российским заказчикам на стандартных условиях недоступна после прекращения VMware и Broadcom продаж и сопровождения в России. Поэтому компаниям необходимо самостоятельно обеспечить источник исправлений и план перехода.</p> <p>Однако исследование показывает, что такой сценарий сформирован не везде. 53,5% участников не знали дату окончания поддержки Spring Boot 3.5, а 55,8% не определили допустимый срок эксплуатации версии без публичных обновлений, включая исправления безопасности.</p> <p>18,9 % участников сообщили, что работы по переходу на Spring Boot 4 уже выполняются или завершено, для 41% переход пока остается планом. 23,7 % респондентов не приняли решение. </p> <p>При этом 32,7% участников одновременно используют несколько поколений Spring Boot. Новые приложения могут уже работать на актуальной версии, тогда как действующие системы продолжают использовать 2.x и 3.x. Это увеличивает объём работ по контролю уязвимостей, совместимости и обновлений и не позволяет завершить миграцию одномоментно.</p> <p>Требования информационной безопасности назвали причиной обновления Java и связанных фреймворков 57,7% участников. Однако инициаторами изменений чаще становятся разработчики (63,5%), тогда как подразделения ИБ и AppSec указали 36,5%. Риск возникает, когда между выявлением уязвимости и внедрением исправления не назначен единый владелец процесса, не установлен срок реакции и не определён источник обновлений.</p> <p>Результаты согласуются с данными State of Java 2026 по поддержке Spring Boot. По оценке JUG Ru Group, 61,5% разработчиков самостоятельно обновляют зависимости, 34,9% проверяют совместимость, 27% анализируют уязвимости, 23,4% контролируют версии и сроки поддержки, 21,5% исправляют дефекты. Отказ от внешней поддержки не устраняет эти задачи — они переходят внутренним командам и конкурируют за ресурсы с развитием продуктов.</p> <p>Только 26,9% участников исследования Axiom JDK уже используют или готовы рассматривать коммерческую поддержку Spring Boot. При этом 61,2% отметили хотя бы одну её практическую ценность. Наиболее востребованы исправления безопасности после окончания публичной поддержки — 29,8%, сопровождение необходимых версий и помощь с миграцией — по 23,4%, закреплённые сроки реакции (SLA) — 20,5%, экспертные консультации — 20,2%. Даже среди участников, которые не рассматривают комплексную коммерческую поддержку, 43,4% готовы использовать ее под конкретные задачи, например, чтобы облегчить работу по поиску исправлений и миграции. </p> <p>«Spring лежит в основе большого числа приложений крупного бизнеса и финансового сектора. Окончание публичной поддержки становится проблемой в момент появления уязвимости, когда компании срочно требуется проверенное исправление. Если источник обновлений и ответственный за процесс не определены заранее, риски переходят из технической плоскости на уровень реальной работы бизнеса, информационной безопасности и бюджетов — растут затраты и нагрузка на команды разработки. Для каждой промышленной системы необходимо заранее установить срок эксплуатации версии, план миграции и порядок получения исправлений», — отметил Илья Сазонов, директор по продукту Axiom JDK (АО «Аксиом»)</p> Компания Axiom JDK (АО «Аксиом») представила исследование о том, как российские компании управляют версиями Spring … message https://www.itweek.ru/themes/detail.php?ID=235432 Mon, 31 Aug 2026 12:38:51 +0300 <p>Компания GreenData, российский разработчик low-code-платформы, выпустила обновление, которое упрощает полный цикл работы с данными: от анализа и корректировки показателей до автоматического формирования табличных отчетов. В новой версии low-code-платформы появилась возможность редактировать данные прямо в OLAP, а также настраивать итоговые строки и столбцы в OLAP-представлениях. Дополнительно были расширены возможности по работе с новыми электронными таблицами: стало возможно осуществить экспорт сразу при выполнении серверной процедуры в рамках выполнения алгоритма.</p> <p>Так, пользователи теперь могут не только анализировать данные, но и редактировать их непосредственно в представлении OLAP. Бизнес-администратор сам определяет сценарий работы: разрешить только открытие карточек объектов, только редактирование значений в таблице или использовать оба режима одновременно. Все необходимые настройки выполняются в карточке куба, позволяя вносить изменения без постоянного перехода из аналитического представления в карточки объектов и обратно.</p> <p>Также в OLAP-представлениях появилась настройка отображения итоговых строк и столбцов. Пользователь может выбрать необходимые вычисления для строк или столбцов — например, сумму, среднее, минимальное или другое значение. После применения настроек итоги сразу отображаются в таблице. Новый механизм помогает быстрее получать сводные показатели и анализировать данные без дополнительной обработки или экспорта информации во внешние инструменты.</p> <p>Еще одно изменение касается электронных таблиц. Теперь их можно автоматически экспортировать в формат XLSX прямо из алгоритмов. Для этого в платформе появились новые функции, которые позволяют сформировать файл, сохранить его в системе или использовать для дальнейшей автоматизированной обработки. Такой сценарий может применяться для регулярной отчетности, обмена данными с внешними системами и подготовки табличных документов по заданным правилам.</p> <p>«Новые возможности помогают сократить количество ручных операций при работе с аналитикой и отчетностью. Пользователь может получить сводные показатели непосредственно в OLAP-представлении, при необходимости скорректировать данные, а затем автоматически сформировать XLSX-файл. В результате весь процесс, от анализа информации до подготовки отчета, выполняется в рамках единого рабочего сценария», — отметила Ксения Золотарева, директор по продукту GreenData.</p> Компания GreenData, российский разработчик low-code-платформы, выпустила обновление, которое упрощает полный цикл работы … message https://www.itweek.ru/themes/detail.php?ID=235430 Mon, 31 Aug 2026 09:53:09 +0300 <p>Далеко не каждой системе необходим отдельный Kafka, RabbitMQ или специализированный message-брокер: для многих backend-продуктов очередь на базе PostgreSQL проще и надежнее в эксплуатации. Используя FOR UPDATE SKIP LOCKED, advisory locks, transactional outbox и корректную модель повторной обработки, можно связать изменение бизнес-данных и постановку фоновой задачи в одной транзакции.</p> <p>В статье разбираю реализацию пула обработчиков на Go, конкуренцию между потребителями и нарастающую задержку перед повтором. Показываю, как работать с очередью необработанных сообщений, корректной остановкой и очисткой накопившихся записей. А ещё определяю границу, после которой очередь поверх Postgres перестаёт быть прагматичным решением и проигрывает специализированному брокеру сообщений — по пропускной способности, времени отклика и управляемости.</p> <h3>Проблема двух систем</h3> <p>Почти в каждом backend-продукте пользователь оформляет заказ. Системе нужно отправить письмо, сформировать отчёт и вызвать внешние API. Выполнять такую задачу прямо в HTTP-запросе не всегда разумно. Увеличивается время ответа, а пользовательский сценарий становится зависимым от внешних сервисов. Команда обычно пользуется привычным набором: Kafka, RabbitMQ или Redis.</p> <p>Появляется риск рассинхронизации. Заказ уже сохранён в базе, но сообщение в брокер не отправлено. Процесс завершился между двумя операциями. Или обратная ситуация: задача стала доступна воркеру до того, как связанные с ней данные были зафиксированы в базе. Это частный случай проблемы двойной записи. Изменение бизнес-данных и постановка фоновой задачи происходят в разных системах и не образуют одну транзакцию.</p> <p>Классическим ответом на эту проблему является использование паттерна «transactional outbox». Приложение в одной транзакции меняет бизнес-данные и пишет строку в служебную таблицу исходящих сообщений, а отдельный процесс читает её и доставляет сообщение в брокер. Атомарность восстановлена, свойства Kafka или RabbitMQ сохранены. Но в системе появляется ещё один компонент, который нужно писать, разворачивать и мониторить, а брокер по-прежнему остаётся в эксплуатации. Получается, что таблица в PostgreSQL всё равно нужна — вопрос лишь в том, служит она перевалочным пунктом или самой очередью.</p> <p>Можно пойти дальше и убрать брокер совсем. Если очередь живёт в том же PostgreSQL, что и бизнес-данные, то изменение заказа и постановка фоновой задачи — одна атомарная операция. В рамках операции либо произошло и то, и другое, либо ничего. Никакого зазора, в который может провалиться работа.</p> <h3>Одна строчка SQL вместо брокера</h3> <p>Вся конструкция опирается на обычную таблицу — назовём её «jobs». В ней хранится минимум: тип задачи, полезная нагрузка в JSON, статус, время, раньше которого задачу запускать не нужно, а также счётчик попыток. Постановка задачи — это простой INSERT (его можно выполнить в той же транзакции, что и изменение бизнес-данных). Такой процесс закрывает проблему двух систем из предыдущего раздела.</p> <p>Однако остается вопрос, как несколько параллельных Go-воркеров будут разбирать задачи, не выстраиваясь в очередь друг за другом? Ответ — конструкция <strong>FOR UPDATE SKIP LOCKED</strong>, появившаяся в PostgreSQL ещё в версии 9.5:</p> <p><em>SELECT id FROM jobs</em></p> <p><em>WHERE status = ’ready’ AND run_at <= now()</em></p> <p><em>ORDER BY run_at</em></p> <p><em>LIMIT 10</em></p> <p><em>FOR UPDATE SKIP LOCKED;</em></p> <p>Запрос выбирает готовые к запуску задачи и временно блокирует выбранные строки. Если другую задачу уже обрабатывает параллельный воркер, SKIP LOCKED не ждёт освобождения блокировки, а пропускает эту строку и переходит к следующей. Благодаря этому несколько воркеров могут работать одновременно, при этом они не забирают задачу дважды и не создают общую очередь ожидания.</p> <p>Далее воркер в короткой транзакции переводит задачи в статус обработки и фиксирует изменение. Затем он уже выполняет основную работу. Поэтому длительные операции не удерживают блокировки в базе и не мешают другим воркерам получать новые задачи.</p> <h3>Правила работы с очередью</h3> <p>Таблица задач и механизм SKIP LOCKED позволяют нескольким воркерам безопасно забирать работу без дублирования. Чтобы такую очередь можно было использовать в продакшене, нужно предусмотреть обработку сбоев. Если задача завершилась ошибкой, её не стоит сразу удалять. Обычно её возвращают в очередь с задержкой, увеличивая интервал между попытками. Это снижает нагрузку на временно недоступный внешний сервис. После заданного числа неудачных попыток задачу переводят в отдельный статус или хранилище для ручного разбора.</p> <p>Также необходимо учитывать и сбои самих воркеров. Если процесс получил задачу и завершился до окончания работы, она не должна остаться в статусе обработки навсегда. Для этого задаче дают ограниченное время обработки: когда оно истекает, другой воркер может взять её повторно. При штатной остановке воркер, наоборот, перестаёт брать новые задачи и завершает уже начатые.</p> <p>При такой модели возможны повторные запуски одной и той же задачи. Например, внешний API мог получить запрос, а воркер — завершиться до сохранения результата. Поэтому обработчики должны корректно переносить повторное выполнение. Например, не отправлять пуш-сообщение дважды или не создавать повторный платёж.</p> <p>Готовые библиотеки избавляют от необходимости реализовывать эти механизмы с нуля. Для Go можно рассмотреть библиотеки River, gue и другие решения поверх PostgreSQL. Выбор зависит от требований к автоматическим повторам и планированию задач, а также наблюдаемости и модели обработки.</p> <h3>Работает и на серьёзном масштабе</h3> <p>Очередь в PostgreSQL не ограничивается небольшими сервисами. Ее используют и высоконагруженные системы, если очередь проектируют и обслуживают как отдельный компонент.</p> <p>Например, для конкурентного получения задач в Я.Диске используется механизм FOR UPDATE SKIP LOCKED. Масштаб: десятки тысяч задач в секунду и сотни типов задач. Один из крупнейших сервисов рунета выбрал SQL-очередь, при том, что Kafka в компании тоже есть и используется там, где её свойства подходят лучше.</p> <p>Второй кейс — компания 37signals, создатели фреймворка Ruby on Rails, Basecamp и почтового сервиса HEY. В HEY отказались от Redis и перевели фоновые системы на очередь Solid Queue. Она обрабатывает около 20 млн. задач в сутки. Для этого используются 800 воркеров, четыре диспетчера и два планировщика на 74 виртуальных машинах. Очередь работает в отдельной базе данных, для которой выделены 32 CPU, 64 Гб памяти и 350 Гб диска. Solid Queue стал очередью по умолчанию в Ruby on Rails 8, а подход официально признан стандартом целой экосистемы.</p> <h3>Где начинаются проблемы</h3> <p>Очередь в PostgreSQL удобна, пока нагрузка на неё остаётся умеренной и предсказуемой. Но у подхода есть особенности, которые нужно учесть до запуска в продакшен.</p> <p>Первая особенность связана с частым изменением записей. Задача обычно создаётся, затем меняет статус, а после выполнения удаляется или архивируется. В PostgreSQL старые версии строк не исчезают сразу, их очищает механизм vacuum. Если он не успевает за потоком обновлений, таблица и индексы разрастаются, а запросы к очереди начинают работать медленнее. Поэтому для таблицы задач обычно настраивают отдельные параметры autovacuum, следят за размером таблицы и не хранят завершённые задачи.</p> <p>Вторая особенность касается механизма LISTEN/NOTIFY. Его суть в мгновенных уведомлениях, которыми удобно будить воркеров вместо периодического опроса таблицы. Компания Recall.ai в марте 2025 года получила из-за него три простоя: уведомления выполнялись в транзакциях, а на этапе COMMIT возникала конкуренция за глобальную блокировку, из-за чего коммиты фактически выстраивались в очередь. В PostgreSQL 19 обещают внедрить улучшения, которые уменьшают лишние пробуждения backend-процессов при NOTIFY, но это не отменит необходимости измерять поведение конкретной системы под нагрузкой.</p> <h3>Где проходит граница очередей</h3> <p>Интуитивно хочется провести границу и разделить применение очередей по реальной нагрузке. Но с большим опытом приходит понимание, что универсального порога по нагрузке нет. На практике значение имеют размер задач, число воркеров, индексы, частота повторных попыток и ресурсы самой базы.</p> <p>Гораздо важнее оценивать стоимость эксплуатации. Очередь на PostgreSQL удобна, пока использует существующую базу: те же бэкапы, мониторинг, инструменты диагностики и компетенции команды. Для многих прикладных задач этого достаточно — особенно, если очередь обслуживает фоновые операции одного приложения.</p> <p>Очереди «Яндекс Диска» и 37signals показывают, что PostgreSQL способен обрабатывать очень большой поток задач, но для этого очереди выделяют собственную базу, ресурсы, настройки обслуживания, мониторинг и т. д. У Диска очередь работает на шардированной базе с отдельной обвязкой, а в 37signals для Solid Queue используется выделенная база данных.</p> <p>Не менее важна семантика. Очередь в PostgreSQL — когда одному приложению нужно выполнить фоновую задачу. Если же одно событие должны независимо получать несколько сервисов, а историю нужно хранить и перечитывать — лучше подходит Kafka. Она рассчитана на хранение потока событий и независимое чтение разными группами потребителей.</p> <p>RabbitMQ уместнее, когда нужны готовые механизмы маршрутизации, подтверждения обработки и управления потоком сообщений. Эти возможности можно частично реализовать поверх таблицы в PostgreSQL, но тогда очередь постепенно превращается в собственный брокер, который нужно проектировать и сопровождать. RabbitMQ же предоставляет подтверждения обработки сообщений как встроенный механизм.</p> <p>Очередь на PostgreSQL не заменяет Kafka или RabbitMQ, но хорошо подходит для фоновых задач. Главный критерий выбора — не популярность или абстрактный предел по числу задач. В приоритете — какие свойства требуются системе и сколько будет стоить их эксплуатация.</p> <p>#IMAGE_235431#</p> Далеко не каждой системе необходим отдельный Kafka, RabbitMQ или специализированный message-брокер: для многих … article Роман Муковнин, старший инженер-программист WildBerries https://www.itweek.ru/themes/detail.php?ID=235429 Mon, 31 Aug 2026 09:44:38 +0300 <p><em>Опрошенные порталом </em><em>InformationWeek</em> <em>эксперты рассказывают о том, как </em><em>CIO</em> <em>могут помочь своим компаниям справиться с растущими и непредсказуемыми расходами на искусственный интеллект и сформировать бюджет, который будет приносить прибыль.</em></p> <p>Предприятиям не обойтись без расходов на ИИ. Но просто вкладывать деньги в эту технологию недостаточно для того, чтобы раскрыть ее потенциал в качестве инструмента повышения эффективности и роста доходов. Выделение бюджета на ИИ, который приносит реальную выгоду, является непростой задачей, поскольку CIO приходится учитывать расходы, которые не всегда очевидны.</p> <p><a href="https://assets.kpmg.com/content/dam/kpmgsites/xx/pdf/2026/06/global-ai-pulse-q2.pdf">Исследование</a> KPMG «Q2 2026 Global AI Pulse» показало, что только 35% организаций имеют полное представление о своих операционных расходах, связанных с ИИ. Эти организации в пять раз чаще сообщают о подтверждённой окупаемости инвестиций, чем те, у кого такой информации нет.</p> <h3>Почему расходы на ИИ сложно спрогнозировать</h3> <p>У предприятий нет чёткой схемы бюджетирования ИИ. Руководители компаний выясняют всё на ходу, а это значит, что неожиданностей и ошибок не избежать.</p> <p>«Очень легко столкнуться с непредвиденными расходами. И очень, очень сложно обеспечить структурированность и предсказуемость при масштабировании возможностей ИИ в крупной организации», — говорит Пол Блоуэрс, CIO компании Plante Moran, занимающейся аудитом, налогообложением, консалтингом и управлением активами.</p> <p>Расходы на ИИ не ограничиваются покупкой платформы или инструмента. Чтобы ИИ приносил пользу, ему нужна правильная основа, а для создания такой основы требуются инвестиции.</p> <p>«Вам нужен уровень данных, вам нужен уровень контекста, вам нужен уровень перевода. Кроме того, у вас будут уровень ИИ и уровень активации», — говорит Кристин Парк, директор по трансформации компании Branch, занимающейся мобильной аналитикой и диплинкингом. К этим базовым требованиям добавляются вопросы безопасности и управления, которые крайне важны.</p> <p>По словам Парк, в ее компании создание такой основы потребовало затрат на очистку баз данных и знаний. Кроме того, она наняла пару инженеров по автоматизации на основе ИИ, чтобы они помогали с рабочими процессами.</p> <h3>Затраты на внедрение ИИ не ограничиваются инструментами</h3> <p>При планировании бюджета на ИИ необходимо учитывать затраты на изменение методов работы сотрудников и способов выполнения самой работы.</p> <p>«Если вы закладываете в бюджет только стоимость инструмента, то, на мой взгляд, вас ждут проблемы, потому что нужно закладывать средства и на трансформацию, — говорит Парк. — Инструмент — это доступ, а трансформация — это переосмысление вашей работы».</p> <p>Переосмысление методов работы команд требует времени и денег. По словам Парк, это «сложный проект», который включает в себя изменения в реализации, конфигурации и рабочих процессах. «ИИ не решает всех проблем. ИИ — это инструмент», — отмечает она.</p> <h3>Затраты на использование ИИ сложно предсказать</h3> <p>Потребление по-прежнему является сложной частью головоломки бюджетирования ИИ. Цены на токены упали, но их использование резко возросло.</p> <p>«Каждый раз, когда выходит новая модель или новый сценарий использования внедряется в производственный процесс, потребление этих токенов растет все быстрее и быстрее, — говорит Блоуэрс. — Мы, CIO, сейчас становимся специалистами в области моделирования и ведения переговоров по токенам, но ситуация в этой сфере пока далека от стабильности».</p> <p>Он ожидает, что модели ценообразования на токены будут продолжать развиваться, а поставщики будут предлагать разные подходы.</p> <h3>ИИ увеличивает расходы</h3> <p>Предприятиям приходится не только самостоятельно решать вопрос с расходами на ИИ, но и учитывать, как инвестиции поставщиков в ИИ влияют на их затраты. Провайдеры SaaS-решений ищут способы встроить ИИ в свои продукты и монетизировать его, что приводит к росту цен.</p> <p>«Большинство ведущих поставщиков SaaS существенно повышают цены, чтобы реализовать свои планы по внедрению ИИ, — говорит Блоуэрс. — И можно с уверенностью сказать, что многие, если не большинство CIO, согласятся с тем, что эти цены растут еще до того, как будут внедрены зрелые функции ИИ, или до того, как мы сможем спрогнозировать, как будет выглядеть потребление внутри этих SaaS-инструментов и платформ».</p> <h3>Как бюджетируют ИИ</h3> <p>Учитывая, что затраты на ИИ так трудно предсказать, CIO начинают переосмысливать бюджетирование этой технологии. Для Парк это означает, что расходы на ИИ рассматриваются не как постоянная статья расходов, а как переменные затраты. «Это модель, основанная на потреблении. Это не фиксированная стоимость, как у SaaS», — поясняет она.</p> <p>Для компаний, которые не приложили достаточных усилий для создания прочной основы для инструментов и рабочих процессов ИИ, обсуждение бюджета может начаться с оценки затрат на создание всего с нуля. Эта основа очень важна. Опрос PwC «2026 Global CEO survey», в котором приняли участие 4454 топ-руководителя, показал, что организации с прочными основами, которые описываются как «ответственные платформы и технологические среды ИИ, обеспечивающие интеграцию в масштабах всего предприятия», имеют в три раза больше шансов получить «значимую финансовую отдачу».</p> <p>При планировании затрат на трансформацию предприятиям необходимо четко представлять, что означает интеграция ИИ для бизнеса. Парк утверждает, что чрезмерное внимание к показателям эффективности является ошибкой. «Мы действительно рассматриваем это как ключевой аспект исследований и разработок, потому что я не думаю, что ИИ должен быть инструментом повышения эффективности, — говорит она. — Я не считаю, что ИИ следует рассматривать как способ сокращения затрат на персонал. Я думаю, это неправильная формула».</p> <p>Независимо от того, какой путь выберут компании — повышения эффективности или внедрения инноваций, — им необходимо заложить в бюджет расходы на внедрение и использование ИИ. Дело не ограничивается покупкой ИИ-инструмента или платформы и требованием к сотрудникам их использовать. «Предоставить людям доступ — это еще не значит внедрить технологию», — говорит Парк.</p> <p>Конечно, по мере внедрения ИИ его использование — и затраты — могут расти. И бюджеты на ИИ должны учитывать этот рост.</p> <p>Блоуэрс вместе с другими руководителями работает над формированием бюджета своей компании на повседневное использование ИИ, в том числе инструментов для повышения производительности. «Мы планируем развивать этот подход по аналогии с FinOps: стимулировать внедрение, предоставлять сотрудникам возможность контролировать расходы, вводить ежемесячные лимиты с некоторыми поведенческими стимулами, — отмечает он. — Обучение само по себе является ключевым инструментом контроля затрат, а не просто способом ограничить потребление токенов».</p> <p>Они также занимаются определением сценариев использования ИИ для масштабирования. «Масштабирование немного проще контролировать с точки зрения затрат, планировать и прогнозировать, потому что мы централизуем процессы и они проходят через наши обычные бизнес-процессы и этапы жизненного цикла разработки ПО», — говорит Блоуэрс.</p> <p>ИИ, встроенный в SaaS-продукты, — это третья статья расходов, которой занимаются Блоуэрс и его коллеги. Это значит, что нужно обсуждать с поставщиками, как ИИ встраивается в уже имеющиеся у компании инструменты и как это влияет на цены при продлении контрактов.</p> <p>«Чтобы справиться с этой проблемой, мы настаиваем на том, чтобы наши партнеры-поставщики соглашались на наши условия, разрабатывали проактивные дорожные карты и оценивали влияние на наши прибыль и убытки, прежде чем соглашаться на предлагаемое ими ценообразование токенов», — говорит Блоуэрс.</p> <p>В компании Парк консолидация инструментов стала частью подхода к бюджетированию. «Вам нужно начать консолидировать инструменты, чтобы получить экономию», — говорит она.</p> <h3>Роль CIO в бюджетировании ИИ</h3> <p>CIO играет ключевую роль во внедрении и бюджетировании ИИ, но для этого ему необходимо взаимодействовать с другими руководителями высшего звена и членами совета директоров, чтобы определить, какую ценность они ожидают получить от ИИ и сколько готовы на это потратить.</p> <p>Поэтому особенно важным партнером является финансовый директор. «Нужно тесно сотрудничать с финансовыми директорами, — говорит Блоуэрс. — Честно говоря, здоровая критика в этом вопросе полезна. Финансовый директор выступает за тщательный контроль бюджета, связанного с ИИ».</p> <p>Давление на CIO не ограничивается контролем расходов. Генеральные директора и члены совета директоров также ожидают, что их ИТ-руководители будут управлять рисками, связанными с ИИ, и при этом не отставать от конкурентов.</p> <p>«Мы сталкиваемся с огромным сопротивлением в вопросах затрат, огромным сопротивлением в вопросах рисков и огромным давлением, требующим действовать быстрее и делать больше, чтобы не отставать, — отмечает Блоуэрс. — Роль CIO заключается в том, чтобы увязать все эти опасения в рамках нашей ИИ-стратегии и помочь найти баланс в этом вопросе».</p> Опрошенные порталом InformationWeek эксперты рассказывают о том, как CIO могут помочь своим компаниям справиться … article https://www.itweek.ru/themes/detail.php?ID=235426 Fri, 28 Aug 2026 00:00:00 +0300 <p><em>С 1 сентября в России вступают в силу изменения в законодательстве, которые затронут всех владельцев доменов в зонах </em><em>.RU, .SU и .РФ. Согласно Федеральному закону № <nobr>569-ФЗ,</nobr> регистрация и дальнейшее управление доменными именами будут возможны только после идентификации администратора через ЕСИА («Госуслуги</em><em>»)</em><em>. При этом подзаконные акты, которые должны определить порядок применения новых требований, пока находятся в стадии разработки. </em><em>Рассмотрим</em><em>, какие риски это создает для бизнеса и что предпринимателям стоит сделать уже сейчас.</em></p> <p>Идея обязательной идентификации направлена на снижение количества анонимных регистраций и мошенничества с доменными именами. После внедрения механизма каждый администратор домена будет подтверждать свою личность через «Госуслуги» — ЕСИА, что, по замыслу авторов нововведения, должно повысить прозрачность российского доменного пространства.</p> <p>Рынок уже начал готовиться к изменениям. Наблюдается заметный рост количества обращений клиентов к регистраторам по вопросам переоформления доменов и актуализации регистрационных данных. Серьезной нагрузки на службы поддержки пока нет, окончательные правила регистрации будут утверждены до 1 сентября. И у регистраторов остается время на полноценное тестирование новых процессов и интеграцию с государственными информационными системами.</p> <h3>Какие риски влекут новые правила</h3> <p>Главный риск для компаний связан не со штрафами — их закон не предусматривает, — но с потерей возможности управлять собственным доменом. Если администратор не сможет пройти идентификацию через ЕСИА, он так же не сможет зарегистрировать новый домен в зонах .RU, .SU и .РФ, продлить срок его действия, изменить регистрационные данные или перенести домен к другому регистратору. В перспективе это может привести к утрате самого доменного имени. Нововведения касаются именно кантри-кодов .RU, .SU и .РФ — или страновых доменов, которые в отличии от доменов общего пользования, таких как, например, .РУС, могут иметь отдельные требования и правила регистрации.</p> <p>Еще один риск — потеря доступа к корпоративной почте и связанным с ней онлайн-сервисам. Если почта работает на домене компании (name@company.ru), а компания потеряла возможность управлять им, могут возникнуть проблемы с почтовыми настройками: станет невозможно изменить <nobr>MX-записи,</nobr> которые указывают, где находится почта, или подтвердить права на домен для почтовых сервисов, могут также возникнуть перебои в доставке писем. Компании, которые используют корпоративную почту или домен для авторизации, восстановления доступа или подтверждения владения системами аналитики, рекламными кабинетами, облачными сервисами, CRM, сервисами для рассылок и прочими онлайн-сервисами, потеряют доступ к этим ресурсам.</p> <h3>Как подготовиться к новой процедуре идентификации</h3> <p>Особенно внимательно стоит проверить старые корпоративные сайты. Нередко оказывается, что домен зарегистрирован не на владельца бизнеса, а на бывшего директора, системного администратора, разработчика сайта или даже на юридическое лицо, которое уже ликвидировано.</p> <p>Такая ситуация часто остается незамеченной, так как при повседневной работе сайта компании обычно не требуется взаимодействовать с администратором домена. Компания пользуется сайтом и считает его своим, потому что у нее есть доступ к CMS, хостингу, контенту, есть возможность менять страницы.</p> <p>В результате бизнес может не знать, что права на управление доменным именем оформлены на человека, который больше не связан с компанией. Но после введения идентификации через ЕСИА именно такая ситуация может стать причиной потери доступа к домену.</p> <p>Соответственно, если домен оформлен на бывшего руководителя или сотрудника, предпринимателю следует заранее установить с ним контакт и провести смену администратора. Сменить администратора после вступления новых правил в силу может оказаться значительно сложнее.</p> <p>Аналогичный подход рекомендуется и компаниям, чьи домены зарегистрированы на организации без подтвержденной учетной записи на «Госуслугах». В этом случае разумно либо заранее создать такую учетную запись, либо переоформить домен на администратора, который сможет пройти необходимую процедуру идентификации через ЕСИА, например, на собственника бизнеса или действующего директора.</p> <p>Владельцам сайтов не стоит ожидать существенного роста расходов. Интеграция с ЕСИА потребует значительных инвестиций от доменных регистраторов, но для конечных пользователей удорожание регистрации и продления доменов составит всего несколько сотен рублей в год. Для бизнеса такие затраты не сопоставимы с рисками потери уже раскрученного сайта, восстановление которого потребует значительно больше времени и средств.</p> <h3>Что делать, если сохранить текущий домен не получится</h3> <p>Если компания понимает, что сохранить существующий домен не удастся, подготовиться к переезду на новый сайт лучше заранее. Для сайтов, уже имеющих поисковый трафик, смена домена без предварительной подготовки может привести к потере позиций в поисковой выдаче, поэтому перенос необходимо планировать заблаговременно, используя инструменты поисковых систем для корректной смены адреса сайта.</p> <p>До появления окончательных правил регистрации стоит провести «ревизию» доменного портфеля: проверить, кто указан администратором каждого домена, актуальны ли регистрационные данные и сможет ли этот человек или организация пройти идентификацию через ЕСИА после вступления новых требований в силу. Именно такая подготовка сегодня остается самым эффективным способом избежать потери доступа к корпоративному сайту.</p> <p>#IMAGE_235427#</p> С 1 сентября в России вступают в силу изменения в законодательстве, которые затронут всех владельцев … article Алексей Созонов, заместитель директора доменного регистратора Webnames.ru