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=235860 Fri, 30 Oct 2026 14:38:03 +0300 <p>В компании VolgaBlob, разработчике платформы Smart Monitor, оценили зрелость рынка защиты корпоративного ИИ. По оценкам экспертов, несмотря на активное внедрение искусственного интеллекта в корпоративном секторе, устойчивый спрос на специализированные решения для защиты и наблюдаемости интеллектуальных технологий стоит ожидать к 2028 году.</p> <p>Российские компании продолжают активно внедрять искусственный интеллект в бизнес-процессы, но динамика спроса на инструменты его мониторинга и защиты пока отстает от темпов распространения самих технологий. Бизнес сосредоточен прежде всего на повышении эффективности за счет ИИ и поиске новых сценариев его применения, в то время как вопросы информационной безопасности часто отодвигает на второй план.</p> <p>Тем не менее, спрос на инструменты AI Security постепенно формируется. Еще в прошлом году такие запросы носили единичный характер, а в 2026 году их количество среди клиентов VolgaBlob выросло в несколько раз. Это можно объяснить тем, что в результате масштабного внедрения корпоративных LLM, генераторов кода и автономных агентов компании начали все чаще сталкиваться с реальными рисками утечек данных, неконтролируемого использования моделей и «теневого ИИ». Спрос формируется и за счет превентивного подхода: ИБ-специалисты понимают возможные последствия бесконтрольного использования ИИ и стремятся обеспечить мониторинг и защиту таких систем еще до возникновения инцидентов. </p> <p>Кроме того, рынок начинает проявлять интерес к AI Observability (наблюдаемости ИИ). Корпоративные ИИ-ассистенты, инструменты генерации программного кода, автономные агенты и локально развернутые языковые модели создают дополнительные точки взаимодействия с внутренней инфраструктурой и корпоративными данными. При этом ИТ-команды и ИБ-службы не всегда располагают полной и достоверной информацией о том, какие ИИ-инструменты используют сотрудники, к каким данным они обращаются и как это влияет на инфраструктуру. Для ИТ-команд наблюдаемость ИИ важна с точки зрения контроля производительности и стабильности сервисов, оценки нагрузки на инфраструктуру и оперативного выявления причин сбоев.</p> <p>Недостаточная наблюдаемость сегодня становится одной из ключевых проблем безопасности корпоративного ИИ. Даже при контроле внутренней модели остаются сторонние сервисы и личные аккаунты. Именно поэтому в VolgaBlob считают обеспечение AI Observability обязательным первым этапом построения эффективной защиты ИИ-контура.</p> <p>«Компании начинают понимать, что для выстраивания системной защиты им нужна полная картина использования искусственного интеллекта внутри организации. Сначала бизнесу необходимо понять, какие именно инструменты используются, какие данные обрабатываются и какие риски возникают. Мы ожидаем, что уже в 2027 году интерес к AI Observability и AI Security будет заметно расти», — считает Тимофей Мельников, руководитель отдела разработки контентных модулей VolgaBlob.</p> <p>Одним из главных вызовов 2027 года также станет адаптация платформ мониторинга к новым типам данных — пользовательским промптам, логам <nobr>LLM-прокси,</nobr> действиям ИИ-агентов и метрикам GPU. Это потребует от поставщиков решений большей гибкости архитектуры и возможности оперативно подключать новые источники без масштабной доработки программного обеспечения. В долгосрочной перспективе мониторинг и защита ИИ станут частью комплексной наблюдаемости корпоративной инфраструктуры.</p> В компании VolgaBlob, разработчике платформы Smart Monitor, оценили зрелость рынка защиты корпоративного ИИ. По оценкам … message https://www.itweek.ru/themes/detail.php?ID=235859 Fri, 30 Oct 2026 14:37:26 +0300 <p><span>Компания «Е-Флопс» разработала модульный сервер М2. Это продукт, адресованный рынку коммерческих ЦОД и</span> <span>суперкомпьютеров, призванный обеспечить заказчикам преимущество в</span> <span>энергоэффективности, плотности вычислений и</span> <span>ТСО (совокупной стоимости владения). По</span> <span>мнению компании, М2</span> <span>— единственный разработанный и</span> <span>производящийся в</span> <span>России ARM-сервер, сравнимый по</span> <span>производительности на</span> <span>стойку с</span> <span>ведущими мировыми аналогами.</span></p> <p>Серверная платформа М2 построена по принципу гибридной вычислительной архитектуры, позволяющей собирать десятки конфигураций с использованием различных семейств центральных процессоров, комбинируемых с GPU- и NPU-ускорителями. В составе сервера М2 доступно 11 моделей вычислительных модулей, включая 6 новых, среди которых появились и однопроцессорные конфигурации. Список доступных GPU- и NPU-ускорителей превышает десяток моделей для различных задач и включает отечественные решения. </p> <p>С технической точки зрения М2 превосходит более раннюю платформу М1 по большинству параметров. Ключевое отличие сервера М2 в применении в вычислительных модулях новой материнской платы MBS02 — «Лена» с высокопроизводительными процессорами архитектуры ARM64, обеспечивающими в 2,5 раза больше ядер и объем памяти до 4 Тб. Сервер М2 способен обеспечить до 2560 универсальных вычислительных ядер на шасси 6U и более 20 000 таких же ядер на серверную стойку, а также обеспечивает наличие специализированных ядер для всего спектра векторных вычислений, количество которых варьируется от выбранных заказчиком исполнений, поддерживаемых М2. </p> <p>Еще более плотный дизайн системной платы «Лена» позволил разместить 16 слотов под модули памяти против 12 в «Ключевской», при этом обеспечив улучшенное охлаждение. В итоге диапазон температур эксплуатации расширен до +45 С0. При этом шасси для обеих платформ остаётся единым, что гарантирует совместимость, упрощает масштабирование инфраструктуры, обеспечивает гибкость конфигураций и защиту инвестиций заказчиков. М2 по-прежнему доступна в тех же исполнениях, что и М1: для классических ЦОД (19«) и для ЦОД стандарта OCP с поддержкой напряжений и 12 В, и 48 В. </p> <p>В шасси М2 усовершенствована система охлаждения: улучшена работа флапперов (жалюзи) модулей охлаждения, а также доработана электронная и программная части управления вентиляторами, переработана плата распределения питания. Изменена механическая часть платформы М2: усилена жёсткость конструкции в отдельных узлах корпуса, облегчено извлечение служебного модуля, а количество пластиковых деталей в конструкции сведено к минимуму. Улучшены эксплуатационные параметры: добавлены элементы «безотвёрточной» сборки-разборки корпусов для упрощения обслуживания и сокращения времени инженерных работ. Разработана и протестирована индивидуальная упаковка, обеспечивающая надёжную транспортировку М2 в любую точку России.</p> <p>Сервер М2 успешно прошёл тепловые испытания в термостенде и подтвердил возможность его использования в инфраструктуре ЦОД с фрикулингом. Это технология естественного охлаждения без использования компрессоров, крайне востребованная в крупнейших передовых ЦОД, позволяет значительно снижать стоимость эксплуатации вычислительных мощностей. </p> <p>Новые процессоры ARM64 оптимизированы для облачных и контейнерных нагрузок, искусственного интеллекта, обработки больших данных и совместимы с несколькими сотнями наименований прикладного ПО с открытым кодом. Использование гибридной вычислительный архитектуры, позволяющей собирать конфигурации не только с GPU, но и с перспективными NPU-ускорителями, расширяет спектр решаемых задач новой серверной мультиплатформенной системы М2. </p> <p>«Создание модульного сервера М2 — закономерный этап развития нашей продуктовой линейки. Новый мультиплатформенный сервер, построенный на материнской плате „Лена“ с увеличенным количеством слотов памяти, процессорных ядер и поддержкой различных типов ИИ-ускорителей, открывает перед заказчиками возможности для решения широкого спектра задач, а улучшенная эргономика и технологичность сборки сокращают время обслуживания. Мы получили не просто апгрейд, а новую современную гибридную платформу, готовую к самым высоким нагрузкам», — отметил руководитель конструкторского отдела компании «Е-Флопс» Сергей Пономарёв.</p> Компания «Е-Флопс» разработала модульный сервер М2. Это продукт, адресованный рынку коммерческих ЦОД и суперкомпьютеров … message https://www.itweek.ru/themes/detail.php?ID=235858 Fri, 30 Oct 2026 14:36:01 +0300 <p>Компания «Битрикс24» объявила о запуске бесплатного сервиса видеозвонков, созданного для личного общения — «Битрикс24 Синк». Теперь поговорить с близкими можно без ограничений по времени, без регистрации и без установки приложений — достаточно создать ссылку на встречу и отправить ее собеседнику.</p> <p>Новый сервис решает задачу, когда нужно срочно созвониться с семьей или друзьями, но заводить ради одного разговора отдельный аккаунт, скачивать приложение не хочется. Человек, получивший ссылку, переходит по ней и мгновенно оказывается в разговоре.</p> <p>Время беседы не ограничено — звонок длится ровно столько, сколько нужно собеседникам, будь то короткий разговор на пять минут или длительные вечерние беседы. </p> <p>Во время разговора можно показать экран, есть реакции, а громкость каждого собеседника настраивается отдельно: если кого-то слышно тише остальных, его голос можно сделать громче.</p> <p>Сервис доступен и в мобильной версии, поэтому поговорить можно из любой локации. Если человек в пути, а разговор нужен уже сейчас — достаточно открыть ссылку на телефоне.</p> <p>Также доступна запись звонок — она длится столько же, сколько сам звонок, позволяя вернуться к беседе в любой момент. В планах компании добавить автоматическую расшифровку звонков, чтобы важное не терялось, а возвращаться к разговору было так же просто, как его начать.</p> <p>Пригласить можно любого человека, даже если он никогда не пользовался продуктами «Битрикс24». </p> Компания «Битрикс24» объявила о запуске бесплатного сервиса видеозвонков, созданного для личного общения — … message https://www.itweek.ru/themes/detail.php?ID=235856 Fri, 30 Oct 2026 10:39:46 +0300 <p>Роскомнадзор пересмотрел перечень стран, обеспечивающих адекватную защиту прав субъектов персональных данных, и утвердил приказ от 16.09.2026 № 253. Документ заменил ранее действовавший приказ Роскомнадзора от 05.08.2022 № 128, которым был установлен перечень таких стран. Новый перечень вступает в силу 30 октября 2026 года — по истечении 10 дней с даты официального опубликования. Изменения обусловлены Федеральным законом от 26.07.2026 № <nobr>265-ФЗ,</nobr> который изменил подход к признанию иностранного государства страной, обеспечивающей адекватную защиту прав субъектов персональных данных.</p> <p>При составлении нового перечня Роскомнадзор учитывал не только участие страны в Конвенции о защите физических лиц при автоматизированной обработке персональных данных, но и принятие эффективных мер по:</p> <ul> <li> соблюдению основополагающих принципов защиты;</li> <li> обеспечению конфиденциальности и безопасности персональных данных при их обработке.</li> </ul> <p>Прежняя редакция ст. 12 Федерального закона от 27.07.2006 № <nobr>152-ФЗ</nobr> (далее — <nobr>152-ФЗ)</nobr> предусматривала возможность включения страны в перечень при соблюдении одного из указанных критериев. Именно поэтому ранее действовавший перечень делил страны на участников Конвенции и иные страны, регулирование и меры которых соответствовали положениям Конвенции.</p> <p>В обновленный перечень вошли 88 иностранных государств — теперь это единый список. Из перечня также исключена Украина, входившая в него ранее.</p> <p>Для операторов, которые передают данные сотрудников или клиентов за границу, это означает необходимость пересмотра текущих схем работы с иностранными контрагентами. Так, в отношении контрагентов из стран, не вошедших в перечень Роскомнадзора, оператор обязан проверить наличие законодательства о персональных данных.</p> <p>Перед любой трансграничной передачей оператор обязан уведомить Роскомнадзор, и ведомство вправе запретить или ограничить такую передачу. При этом в страны, включенные в перечень, можно начинать передачу сразу после уведомления, а в страну вне данного перечня — только по истечении 10 рабочих дней с момента подачи уведомления. Например, чтобы передать данные в США, нужно подать уведомление в Роскомнадзор и выждать 10 рабочих дней. Этот же подход нужно применять при передаче данных контрагентам на Украине, поскольку эта страна исключена из текущего перечня.</p> <h2>Когда возникает трансграничная передача?</h2> <p>Трансграничная передача — это передача персональных данных при одновременном соблюдении двух условий:</p> <ul> <li> на территорию иностранного государства;</li> <li> иностранному органу власти, физическому или юридическому лицу.</li> </ul> <p>При этом важно понимать, что трансграничная передача возникает не только при классической пересылке файлов иностранному контрагенту. Такой передачей может быть признано использование иностранной веб-аналитики, CRM, облака, а также иное предоставление фактического доступа зарубежным контрагентам к персональным данным граждан Российской Федерации.</p> <p>Например, трансграничная передача имеет место в случае использования Google Analytics. Несмотря на то что еще с 2025 года активно обсуждается необходимость подачи уведомлений о трансграничной передаче при использовании этого сервиса, далеко не все операторы обеспечили их подачу. В связи с этим рекомендуем проверить свой сайт на предмет подключения Google Analytics и подать уведомление либо отключить сервис при отсутствии фактического использования.</p> <p>Операторам важно пересмотреть свои процессы обработки персональных данных и установить наличие иностранного элемента и признаков трансграничной передачи по описанным выше критериям. Если оба элемента присутствуют, необходимо обеспечить корректную процедуру уведомления РКН.</p> <h2>Что теперь необходимо проверить оператору перед подачей уведомления</h2> <p>Порядок подачи уведомления о трансграничной передаче установлен ст. 12 <nobr>152-ФЗ.</nobr> Теперь перед подачей уведомления оператор обязан получить от иностранного контрагента сведения о правовом регулировании в стране контрагента. Эти сведения вместе с реквизитами контрагента и принимаемыми им мерами защиты данных оператор обязан предоставить по запросу Роскомнадзора в течение 10 рабочих дней. Срок может быть продлен, но не более чем на 5 дней при наличии мотивированного уведомления оператора, в котором необходимо отразить причины продления.</p> <p>При этом обязанности заново направить уведомление по результатам публикации нового перечня у операторов не возникает, но собрать описанную выше информацию о правовом регулировании и мерах защиты нужно заранее.</p> <h2>Чек-лист оператора при наличии трансграничной передачи</h2> <p>Если в вашей деятельности присутствуют процессы обработки данных с иностранным элементом, необходимо сделать следующее.</p> <h3>Этап № 1. Установите наличие трансграничной передачи</h3> <p>Во всех процессах с иностранным элементом необходимо определить, является ли такая обработка персональных данных трансграничной передачей. Для этого проверьте, получает ли иностранный контрагент доступ к персональным данным и имеется ли при этом факт передачи данных на территорию иностранного государства.</p> <p>Факт передачи устанавливается, если иностранный контрагент фактически получает доступ к персональным данным и действительно может их обрабатывать.</p> <p>Так, например, передача работнику компании данных за рубеж не будет являться трансграничной передачей, если работник является гражданином Российской Федерации: в этом случае не соблюдается условие о передаче данных в адрес иностранного контрагента.</p> <p>Если же все условия трансграничной передачи соблюдаются, переходите к следующему этапу.</p> <h3>Этап № 2. Запросите сведения об иностранных контрагентах</h3> <p>Соберите информацию обо всех иностранных контрагентах, получающих доступ к персональным данным. Согласно требованиям п. 3 ч. 5 ст. 12 <nobr>152-ФЗ</nobr> вам необходимо собрать о них следующие сведения:</p> <ul> <li> ФИО или наименование;</li> <li> номера контактных телефонов;</li> <li> почтовые адреса;</li> <li> адреса электронной почты.</li> </ul> <p>Советуем формировать по каждому контрагенту отдельную анкету, чтобы при запросе Роскомнадзора у вас в наличии был полный перечень необходимых сведений.</p> <h3>Этап № 3. Проверьте перечень стран с адекватной защитой</h3> <p>После определения контрагентов и сбора информации о них необходимо определить объем сведений, который дополнительно придется запросить перед подачей уведомления. Для этого вам понадобится изучить обновленный перечень стран с адекватной защитой и определить, включена ли страна контрагента в указанный перечень.</p> <p>Если страна входит в перечень, вы можете сразу переходить к этапу № 5. Если же государство не признано страной с адекватной защитой и не включено в перечень Роскомнадзора, важно предварительно собрать сведения о правовом регулировании персональных данных в стране иностранного контрагента.</p> <p>Данный этап важен и для определения сроков начала трансграничной передачи. Подход должен быть следующим:</p> <ul> <li> если страна включена в перечень Роскомнадзора, вы вправе осуществить передачу данных в адрес иностранного контрагента сразу после подачи уведомления;</li> <li> если страна не включена в перечень Роскомнадзора, вы можете осуществлять передачу данных только по истечении 10 рабочих дней после подачи уведомления.</li> </ul> <h3>Этап № 4. Соберите сведения о правовом регулировании</h3> <p>При отсутствии страны контрагента в обновленном перечне соберите информацию о правовом регулировании обработки персональных данных. Эти сведения можно запросить у контрагента или найти на сайтах официального опубликования нормативных правовых актов иностранного государства.</p> <p>На данном этапе важно определить:</p> <ul> <li> имеются ли у страны контрагента законы, регулирующие обработку персональных данных;</li> <li> существует ли регуляторный орган или система органов, в чью компетенцию входит контроль за соблюдением законодательства о персональных данных;</li> <li> установлены ли государством санкции за несоблюдение требований в области персональных данных.</li> </ul> <h3>Этап № 5. Изучите сведения об условиях обработки данных контрагентом</h3> <p>В отношении передаваемых персональных данных иностранный контрагент должен принимать меры по их защите. Перед передачей важно выяснить, какие из мер защиты фактически реализованы иностранным контрагентом, а также уточнить условия прекращения обработки персональных данных.</p> <p>Как правило, такие положения нужно предварительно закреплять в договорах и иных документах, определяющих условия сотрудничества с иностранным контрагентом. Если же эти условия отсутствуют в имеющихся документах, запросите их у контрагента, внесите в анкету и закрепите в документах с контрагентом.</p> <h3>Этап № 6. Оцените соблюдение конфиденциальности и безопасности данных</h3> <p>В уведомлении необходимо отразить дату оценки соблюдения иностранным контрагентом конфиденциальности и безопасности персональных данных.</p> <p>Данную оценку лучше оформить в виде документа свободной формы, в котором нужно:</p> <ul> <li> оценить сведения, представленные оператору на дату проведения оценки;</li> <li> зафиксировать результат оценки (иными словами, почему оператор решил, что данные можно безопасно передавать контрагенту).</li> </ul> <p>Документ с результатами оценки не требуется направлять при подаче уведомления, но его формирование поможет зафиксировать исполнение обязанностей оператора.</p> <h3>Этап № 7. Подайте уведомление о трансграничной передаче</h3> <p>По итогам всех этапов вы можете приступать к подаче уведомления. Отразите все необходимые сведения об условиях осуществления трансграничной передачи в соответствии с требованиями ч. 2 ст. 12 <nobr>152-ФЗ</nobr> и в дальнейшем отслеживайте изменение указанных в уведомлении сведений, поскольку именно они подлежат актуализации.</p> <h3>Этап № 8. Осуществите передачу данных в рамках установленных сроков</h3> <p>На третьем этапе вы уже определили, когда можете начать передачу данных в адрес иностранного контрагента и нужно ли соблюдать <nobr>10-дневный</nobr> срок с момента подачи уведомления или можно передавать данные сразу после подачи. Последнее зависит от того, включена ли страна контрагента в перечень Роскомнадзора, как мы обсуждали ранее.</p> <p>При этом важно понимать, что Роскомнадзор вправе отказать в трансграничной передаче или ограничить её. В этом случае уже осуществляемую передачу в страну, включенную в перечень Роскомнадзора, необходимо будет остановить или скорректировать согласно установленным ограничениям. Тогда же важно соблюдать ранее согласованные с контрагентом условия прекращения обработки данных.</p> <p>В отношении стран, не включенных в перечень, Роскомнадзор вправе запросить дополнительную информацию, которую оператор собирал на этапах № 2, 4 и 5. В этом случае <nobr>10-дневный</nobr> срок рассмотрения уведомления приостанавливается до предоставления оператором запрошенных сведений: важно помнить об этом при определении момента начала передачи данных в адрес иностранного контрагента.</p> <h2>Возможность осуществления трансграничной передачи не отменяет требования к локализации</h2> <p>Необходимо корректно понимать требования к каждому из процессов. Так, трансграничная передача касается передачи ранее собранных данных за рубеж в адрес иностранного контрагента. При этом операторы обязаны осуществлять первоначальный сбор персональных данных исключительно с использованием российских баз данных. Данное требование к локализации вытекает из положений ч. 5 ст. 18 <nobr>152-ФЗ.</nobr></p> <p>Для соблюдения всех описанных выше требований используйте следующий подход:</p> <ul> <li> при локализации (первоначальном сборе данных граждан) используйте сервер, расположенный на территории РФ;</li> <li> при трансграничной передаче (передаче ранее собранных данных в адрес иностранного контрагента) подайте предварительное уведомление.</li> </ul> <h2>Заключение</h2> <p>Обновленный перечень закрепил новый подход к определению иностранного государства как страны с адекватной защитой персональных данных. Поэтому при отсутствии страны вашего контрагента в указанном перечне не пренебрегайте сбором информации о правовом регулировании.</p> <p>При этом не забывайте, помимо описанных выше шагов, соблюдать и иные требования, вытекающие из факта трансграничной передачи. Например, обеспечьте наличие законных оснований для обработки данных иностранным контрагентом:</p> <ul> <li> проверьте наличие поручения на обработку персональных данных, если ваш контрагент обрабатывает данные на основании поручения оператора;</li> <li> изучите и обновите политику обработки персональных данных в части упоминания о факте трансграничной передачи;</li> <li> укажите иностранных контрагентов в согласиях ваших пользователей.</li> </ul> <p>Таким образом, трансграничная передача допустима, но с соблюдением нового подхода и выполнением возложенных на оператора требований закона.</p> <p>#IMAGE_235857#</p> Роскомнадзор пересмотрел перечень стран, обеспечивающих адекватную защиту прав субъектов персональных данных, и утвердил … article Камила Мухамеджанова, менеджер по развитию продукта “1ОПД” https://www.itweek.ru/themes/detail.php?ID=235854 Fri, 30 Oct 2026 10:25:20 +0300 <p>Фактом использования искусственного интеллекта в корпоративном секторе сегодня никого не удивишь. Языковые модели помогают сотрудникам быстрее находить информацию, анализировать документы и в конечном счете сокращают затраты времени на рутинные операции. Это повышает производительность отдельных команд и бизнеса в целом. Но для полноценного использования AI недостаточно выбрать подходящую модель и обеспечить ее вычислительными ресурсами. Необходимо также решить, где будут обрабатываться корпоративные данные и кто будет контролировать доступ к ним.</p> <p>Сведения о клиентах и контрактах, техническая документация и внутренние базы знаний могут содержать информацию, которую нельзя передавать за пределы организации. Для многих компаний принципиально важно развернуть AI в закрытом контуре, сохранив контроль над данными и условиями их обработки.</p> <p>В последнее время актуализировался еще один фактор — физическая безопасность IT-инфраструктуры. Инциденты на площадках российских дата-центров показали, что серьезное внешнее воздействие может привести к масштабным нарушениям работы оборудования и сервисов. В таких обстоятельствах сроки восстановления инфраструктуры могут оказаться неопределенными, а последствия для бизнеса — выходить далеко за пределы самого дата-центра.</p> <p>Все это усиливает интерес к собственным вычислительным решениям, которые позволяют разместить AI-систему внутри корпоративного контура и самостоятельно определять условия доступа к данным и оборудованию. При этом аренда вычислительных мощностей и размещение серверов в коммерческих дата-центрах остаются востребованными вариантами: они позволяют быстро стартовать с проектами корпоративного ИИ и избегать крупных первоначальных вложений.</p> <p>В этой статье разберем, как требования к корпоративному ИИ влияют на выбор локальной вычислительной инфраструктуры, сколько могут стоить разные варианты конфигурации и почему наиболее дорогой сервер не всегда оказывается наиболее рациональным решением для бизнеса.</p> <h3>Нейронка, чтобы что?</h3> <p>«Сколько будет стоить сервер с нужной конфигурацией под ИИ?» Этот вопрос интересует практически каждую организацию на первых минутах обсуждения подобных проектов. Будем реалистами: универсального правильного ответа не существует. Чтобы понять, сколько и какого оборудования потребуется для корпоративного AI, сначала нужно определить, что именно этот AI должен делать.</p> <p>Например, производственная компания может использовать AI для самых разных задач: превратить массив внутренних документов в единый источник знаний для сотрудников, ускорить поиск технической информации, автоматизировать обработку заявок и документов, улучшить аналитику и поддержку управленческих решений. AI также может участвовать во взаимодействии с клиентами: например, отвечать на типовые обращения по электронной почте и в чате на сайте, вовлекаться в процедуры обработки заказов. В конечном счете цель внедрения заключается в измеримом результате: экономии рабочего времени, повышении производительности, снижении операционных затрат и более эффективном использовании ресурсов компании.</p> <p>Ни 500 тыс. документов, ни 100 сотрудников сами по себе не определяют конфигурацию AI-сервера. Чтобы понять, какая инфраструктура потребуется, сначала необходимо разобраться, какие задачи будет решать система и как сотрудники будут с ней работать.</p> <p>Реальная ситуация: организация задумалась над созданием AI-интерфейса к корпоративным знаниям. Задача была сформулирована руководителем очень просто: «Хочу, чтобы все мои сотрудники в рамках своих предметных областей могли задавать вопрос нейросети и получать от ИИ ответы на эти вопросы со ссылками на конкретные документы и даже на участки текста». Такой подход называется RAG (Retrieval-Augmented Generation), или генерация с дополнением извлеченной информацией. Он хорош тем, что не требует обучать языковую модель с нуля.</p> <p>Теперь можно определить предполагаемый профиль нагрузки. AI-системой потенциально пользуются все 100 сотрудников, но одновременно с ней работают не более 30 человек. В периоды пиковой нагрузки система должна обрабатывать до 10 запросов в минуту.</p> <p>Такие параметры существенно приближают нас к требованиям к инфраструктуре. Но для выбора оборудования их все-таки маловато. Важно понимать, какую вычислительную работу выполняет модель при каждом запросе, сколько информации получает на вход и насколько быстро должна формировать ответ.</p> <p>Здесь появляются три связанных параметра:</p> <ul> <li> время обработки отдельного запроса;</li> <li> объем работы, который система способна выполнять за единицу времени;</li> <li> количество одновременно обрабатываемых запросов.</li> </ul> <p>Чем больше запросов система обрабатывает параллельно, тем выше потенциальная пропускная способность, но тем сильнее вычислительные ресурсы распределяются между запросами и тем больше времени может потребоваться на обработку каждого из них. Поэтому сервер должен обеспечивать не просто высокую производительность, а нужный баланс между скоростью ответа и количеством одновременно обслуживаемых пользователей.</p> <p>Если расчет нагрузки оказался неверным, пользователь довольно быстро заметит проблему: ответы станут медленнее, а система хуже начнет справляться с запросами. При этом симптомы могут быть одинаковыми, хотя причины различаются. Одной конфигурации может не хватать вычислительной мощности, другой — видеопамяти для параллельных сессий. Именно поэтому серверную конфигурацию нужно подбирать под конкретную нагрузку: размер модели, число одновременных пользователей и требования к скорости ответа. Рассмотрим, как эти требования влияют на выбор оборудования и его стоимость.</p> <h3>От требований к конфигурации</h3> <p>Всегда следует разделять минимальную и рабочую конфигурации.</p> <p>Минимальная конфигурация — набор оборудования, на котором выбранная большая языковая модель технически запускается и способна обслуживать клиентские запросы. В первую очередь здесь нужно обеспечить достаточный объем видеопамяти для размещения модели, ее рабочего контекста и служебных данных. Затем — достаточную вычислительную производительность графического процессора, чтобы система могла формировать ответы с приемлемой скоростью. К этому добавляются центральный процессор, оперативная память и быстрые NVMe-накопители для работы RAG, хранения индексов и корпоративных данных.</p> <p>Такая конфигурация может работать вполне убедительно на тестовом стенде. Один пользователь задает вопрос, получает ответ за несколько секунд. Но есть нюанс. AI в условиях корпоративного применения совершенно точно обслуживает не только единственного пользователя. В течение рабочего дня нагрузка будет меняться: большую часть времени система может быть загружена умеренно, но в отдельные моменты десятки сотрудников одновременно отправят запросы.</p> <p>Если минимальная конфигурация рассчитана практически без запаса, при росте числа одновременных запросов начнут увеличиваться очереди и расти время обработки отдельного запроса. Система формально продолжит работать, но пользователи будут ждать ответа дольше, а пропускная способность всей системы окажется ниже расчетной. Поэтому рабочая конфигурация должна учитывать не только возможность запуска модели, но и реальную эксплуатационную нагрузку.</p> <p>Такая нагрузка может потребовать больше доступной видеопамяти, более производительного графического процессора или увеличения количества видеокарт. Может потребоваться больше оперативной памяти, более быстрые накопители или изменение архитектуры сервера. В зависимости от выбранной модели и режима работы несколько GPU могут использоваться совместно, что предъявляет дополнительные требования к их соединению и к платформе в целом.</p> <p>Таким образом, между конфигурациями существует принципиальная разница. Минимальная конфигурация покажет нижнюю границу инвестиций. Рабочая — сколько действительно потребуется потратить, чтобы обеспечить заданную скорость ответа и необходимое количество одновременных пользователей. Таким образом, выбор конфигурации — это поиск баланса между первоначальными инвестициями, эксплуатационными расходами и требуемой производительностью. Рассмотрим, как эти требования влияют на выбор оборудования и стоимость локального решения.</p> <h3>Считаем деньги</h3> <p>Чтобы сравнение было предметным, вернемся к сценарию, который мы уже упоминали. Организация хочет развернуть языковую модель среднего размера, подключить к ней корпоративные документы через RAG и обеспечить одновременную работу примерно 30 пользователей.</p> <p>Для такого проекта система должна одновременно обрабатывать запросы, удерживать контекст пользовательских сессий и обеспечивать приемлемое время ответа. Именно здесь возникает основной вопрос при выборе оборудования: сколько вычислительных ресурсов потребуется для полноценной работы, а не только для запуска модели?</p> <p>Рассмотрим три конфигурации. Дальнейшее сравнение покажет: самый подходящий для применения вариант оказался далеко не самым дорогим.</p> <p><strong>Минимальная конфигурация: 5,1 млн. рублей</strong>. В основе системы — один ускоритель NVIDIA L40S с 48 Гб видеопамяти. Его дополняют серверный процессор, оперативная память DDR5 ECC, корпоративный NVMe-накопитель и платформа с необходимым запасом по питанию и охлаждению. Этого достаточно, чтобы развернуть модель и обеспечить работу RAG-системы. Но минимальная конфигурация не рассчитана на комфортную одновременную работу 30 пользователей в рассматриваемом сценарии. Видеопамять помимо размещения самой модели нужна для хранения контекста активных сессий. По мере роста числа параллельных запросов система может упереться в доступный объем VRAM, что приведет к снижению пропускной способности и увеличению времени ответа.</p> <p><strong>Рабочая конфигурация: 7,25 млн. рублей</strong>. Следующий вариант предусматривает два ускорителя NVIDIA L40S по 48 Гб каждый, то есть суммарно 96 Гб видеопамяти. Дополнительные ресурсы позволяют разместить модель и обслуживать больше параллельных запросов, а более производительная серверная платформа обеспечивает необходимый запас по питанию и охлаждению. Однако увеличение числа GPU не всегда дает пропорциональный рост производительности. При распределении вычислений между двумя ускорителями обмен данными между ними может стать дополнительным ограничением. У NVIDIA L40S нет NVLink, поэтому межкарточный обмен осуществляется через PCIe. Насколько существенно это повлияет на время ответа, зависит от модели и характера нагрузки.</p> <p><strong>Оптимизированная конфигурация: 6,5 млн. рублей</strong>. В рассматриваемом проекте организация пошла другим путем: вместо двух L40S используется один ускоритель NVIDIA RTX 6000 Blackwell с 96 Гб видеопамяти GDDR7. Такой подход позволяет разместить модель и контекст пользовательских сессий в памяти одного GPU, не распределяя вычисления между двумя отдельными ускорителями. При подходящем программном стеке это устраняет необходимость межкарточного обмена через PCIe и упрощает организацию вычислений.</p> <p>При этом стоимость готового сервера с многоканальной оперативной памятью DDR5 ECC составляет около 6,5 млн. рублей. Это на 750 тыс. рублей меньше стоимости конфигурации с двумя L40S. То есть экономия составляет примерно 10%.</p> <p>Получается, более эффективный подбор оборудования способен дать лучший баланс стоимости и вычислительных возможностей, чем простое наращивание количества ускорителей.</p> <h3>Что важно учитывать при расчетах</h3> <p>Указанные суммы — всего лишь ориентиры для конкретных конфигураций. Финальная цена зависит от стоимости высокопроизводительных компонентов. А на них, в свою очередь, влияют курсы валют, стоимость логистики, доступность оборудования и условия гарантии.</p> <p>Не менее важны характеристики самой нагрузки. Результат будет различаться в зависимости от выбранной языковой модели, длины контекста, режима квантования и требований к скорости ответа. Поэтому возможность запустить модель на сервере еще не означает, что он сможет обеспечить требуемую производительность при 30 одновременных запросах.</p> <p>Именно поэтому конфигурацию следует подбирать не только по цене и объему видеопамяти, но и по целевым показателям системы: времени ответа, пропускной способности и числу одновременно обслуживаемых пользователей.</p> <h3>Есть эффект?</h3> <p>Цена сама по себе ничего не скажет об успешности проекта. Поэтому организация, как правило, переводит вопрос эффективности в более прикладную плоскость: какой экономический смысл это ей дает?</p> <p>Около 30 сотрудников обеспечивают примерно 70% запросов к корпоративному ИИ. Для предварительной оценки организация рассмотрела один из базовых сценариев применения AI — поиск и сопоставление информации. Если каждый из этих сотрудников тратит на такие задачи около 30 минут в день, суммарные затраты составляют 15 человеко-часов ежедневно. Это потенциальная область для повышения эффективности, но фактический результат будет зависеть от того, какую часть этих операций удастся ускорить с помощью AI.</p> <p>Однако поиск информации — лишь один из возможных сценариев применения корпоративного AI. Дополнительный эффект может возникать за счет автоматизации обработки документов и заявок, ускорения аналитики, работы с клиентскими обращениями и оптимизации других бизнес-процессов. Поэтому оценивать экономический потенциал внедрения только по времени, сэкономленному на поиске документов, было бы некорректно: совокупный результат зависит от количества сценариев, в которых AI действительно повышает производительность.</p> <p>Организация ориентируется на улучшение отдельных показателей производительности в диапазоне <nobr>10-20%.</nobr> Но насколько реалистична такая оценка и что показывают результаты внедрения AI в других компаниях?</p> <p>Мы рассмотрели несколько исследований, в которых влияние генеративного ИИ измерялось непосредственно в рабочей среде. В одном из наиболее известных исследований NBER <a href="https://www.nber.org/papers/w31161">анализировалась</a> работа более 5 тыс. сотрудников службы поддержки. Доступ к AI-ассистенту увеличил количество решенных обращений в час в среднем на 15%. При этом эффект оказался неодинаковым: менее опытные сотрудники заметно повысили производительность, тогда как у наиболее опытных прирост был небольшим.</p> <p>Другой крупный эксперимент <a href="https://www.microsoft.com/en-us/worklab/work-trend-index/copilots-earliest-users-teach-us-about-generative-ai-at-work/">провела</a> Microsoft. Участники выполняли набор задач, включавший поиск информации по нескольким источникам, создание текста и подготовку материалов. Пользователи Copilot справлялись со всем набором задач на 29% быстрее. В отдельном эксперименте поиск информации по нескольким источникам занимал в среднем 24 минуты без AI и около 18 минут с AI — экономия составляла примерно 6 минут на одну операцию.</p> <p>Результаты исследований позволяют рассматривать диапазон <nobr>10-20%</nobr> как обоснованную рабочую гипотезу для отдельных процессов, но не как гарантированный результат внедрения. В конкретной компании эффект будет зависеть от характера задач, исходной производительности сотрудников и того, насколько AI интегрирован в рабочий процесс. Масштабирование успешных сценариев на другие процессы создает потенциал для более значительного совокупного результата.</p> <h3>Заключение</h3> <p>Экономический эффект от внедрения AI не всегда выражается в прямом сокращении расходов. Высвободившееся время сотрудников можно направить на выполнение большего объема работы, сокращение сроков, повышение качества обслуживания или решение более сложных задач. Таким образом, AI создает возможности для повышения производительности без обязательного сокращения численности персонала.</p> <p>Первый успешный сценарий внедрения — отправная точка для дальнейшего применения AI в организации. Получив практический опыт, компания может выявлять новые задачи, в которых AI способен дать измеримый результат. Последующие этапы внедрения могут потребовать меньше времени на подготовку. Компания уже понимает, как оценивать бизнес-задачи, определять профиль вычислительной нагрузки и подбирать модели и инфраструктуру. Кроме того, у нее есть опыт эксплуатации собственного вычислительного узла. Это позволяет опираться на уже созданную техническую основу, хотя расширение числа сценариев может потребовать дополнительных вычислительных ресурсов.</p> <p>Чем больше бизнес-процессов компания успешно охватывает с помощью AI, тем выше потенциальный совокупный экономический эффект. Для холдинга масштабирование успешных решений на другие подразделения открывает дополнительные возможности, однако результат тем убедительнее, чем глубже AI интегрирован в рабочие процессы. В этой точке возникает новый вызов — как организации наилучшим образом использовать высвободившиеся ресурсы. Но это, как говорится, совсем другая история.</p> <p>#IMAGE_235855#</p> Фактом использования искусственного интеллекта в корпоративном секторе сегодня никого не удивишь. Языковые модели … article Михаил Васильев, коммерческий директор компании HYPERPC https://www.itweek.ru/themes/detail.php?ID=235853 Fri, 30 Oct 2026 10:11:17 +0300 <p><em>Прежде чем приступать к инициативам в области аналитики, данных и искусственного интеллекта, руководителям отделов данных и аналитики (D&A) необходимо остановиться и убедиться, что они определили и используют бизнес-метрики ценности (</em><em>business</em> <em>value</em> <em>metrics</em><em>,</em><em> BVM), пишет на портале </em><em>InformationWeek</em> <em>Рэй Коллинз, старший директор-аналитик Gartner.</em></p> <p>Количественная оценка и донесение ценности инициатив для бизнеса могут быть сложной задачей для D&A-руководителей, которые называют это одним из трех главных препятствий на пути к успеху своей команды.</p> <p>Это подчеркивает важность определения BVM, которые напрямую связывают операционные инвестиции в данные, аналитику и ИИ с измеримыми результатами для бизнеса. Следуя этим путем, D&A-руководители могут обеспечить приоритетность своих потребностей в рамках всего бизнеса и легче получить финансирование.</p> <h3>Согласование инициатив в области данных, аналитики и ИИ с бизнес-результатами</h3> <p>Одна из главных причин, по которой D&A-руководителям трудно доказать ценность своей работы, заключается в том, что они, как правило, сосредотачиваются на технических показателях, а не на ощутимых результатах для бизнеса. Вместо того чтобы сообщать только о качестве данных или точности моделей, они должны напрямую связывать их со стратегическими целями, такими как снижение оттока клиентов, чтобы явно доказать финансовую и операционную окупаемость инвестиций в данные, аналитику и ИИ.</p> <p>Первым шагом для D&A-руководителей является понимание того, что означает успех для заинтересованных сторон бизнеса. Последние сообщают о своих приоритетах через стратегические планы, годовые отчеты и текущие обсуждения бизнеса. Исходя из этого, D&A-руководители должны установить четкую связь между своей деятельностью в области анализа и обработки данных и конкретными результатами бизнеса.</p> <p>Не каждая D&A-инициатива обеспечит одинаковый уровень влияния на бизнес, поэтому D&A-руководители должны также оценивать и приоритизировать возможности на основе их ожидаемой бизнес-ценности. Согласование инициатив в области данных, аналитики и ИИ с результатами бизнеса переводит разговор с технических показателей на ощутимое влияние на бизнес, создавая более прочную основу для инвестиций, определения приоритетов и долгосрочной поддержки.</p> <h3>Определение BVM</h3> <p>После того, как установлена ​​связь между D&A-инициативами и результатами бизнеса, следующим шагом для D&A-руководителей является определение своих BVM. Эти показатели делают влияние их работы видимым и измеримым. Эффективные BVM создают четкую связь между операционными улучшениями, D&A-инициативами и наиболее важными бизнес-результатами.</p> <p>Чтобы сделать BVM достоверными, D&A-руководители должны установить базовые показатели и целевые результаты. Понимание текущей производительности позволяет создать эталон, по которому можно измерять будущие улучшения, помогая заинтересованным сторонам оценить истинную ценность инициативы и сравнить инвестиции в рамках всего портфеля. Важно иметь четкие определения. Каждый показатель должен иметь бизнес-определение, объясняющее, почему он важен, а также операционное определение, описывающее, как он рассчитывается, измеряется и представляется.</p> <p>Самое главное, D&A-руководители должны сосредоточиться на результатах, а не на деятельности. Реальная ценность достигается благодаря тому, что сэкономленное время реинвестируется для получения дохода, улучшения качества обслуживания клиентов, снижения рисков или продвижения стратегических приоритетов. Наиболее эффективные BVM преобразуют операционные улучшения в измеримые бизнес-результаты, которые заинтересованные стороны могут легко понять и поддержать.</p> <h3>Корректировка BVM при изменении бизнес-факторов</h3> <p>Задача D&A-руководителей — приоритизировать свои инвестиции на основе оценки рисков. Непосредственным преимуществом выявления и измерения BVM и отчетности по ним является более эффективное управление готовностью или возможностями, необходимыми для реализации ожидаемых бизнес-результатов.</p> <p>Готовность описывает состояние возможностей, необходимых для реализации ожидаемых улучшений бизнес-процессов, деятельности, решений, данных, продуктов и услуг, основанных на данных и аналитике. D&A-руководители должны использовать BVM для принятия обоснованных решений по портфелю проектов, например, для определения того, какие инициативы в области данных и ИИ следует финансировать, масштабировать, а какие откладывать или деприоритизировать.</p> <p>Управляя готовностью D&A-возможностей, руководители могут снизить риск того, что инициативы не достигнут желаемого результата.</p> <p>Инициативы следует приоритизировать, используя как показатели ценности, так и показатели осуществимости. Это означает оценку инициатив на основе как их ожидаемой бизнес-ценности, так и способности организации фактически обеспечить эту ценность. Инициативы, демонстрирующие ценность, но не осуществимые в обозримой перспективе, следует помечать как просчитанные риски. Их нужно тщательно расставлять приоритеты, сопоставляя их с высокоценными и высокоосуществимыми инициативами.</p> <p>После оценки бизнес-результатов, рисков и готовности D&A-руководители получают веские основания для приоритизации инициатив, которые обеспечивают баланс между краткосрочными результатами и долгосрочным стратегическим воздействием. Это поможет им гарантировать, что чрезмерные инвестиции в малоэффективную или малоперспективную работу не ограничат возможности для достижения более значительных результатов.</p> <p>В конечном счете, демонстрация бизнес-ценности, которую приносят данные и ИИ, — это непрерывный процесс. D&A-руководителям необходимо постоянно соотносить свои инициативы с бизнес-результатами, определять значимые BVM и корректировать их по мере изменения приоритетов бизнеса. Это позволит им более эффективно добиваться финансирования, укреплять доверие заинтересованных сторон и гарантировать, что инвестиции в данные и ИИ со временем будут приносить измеримую пользу для всей организации.</p> Прежде чем приступать к инициативам в области аналитики, данных и искусственного интеллекта, руководителям отделов … article https://www.itweek.ru/themes/detail.php?ID=235851 Thu, 29 Oct 2026 19:47:59 +0300 <p>Команда Хоулмонт выпустила новую версию open-source платформы Джеймикс для разработки корпоративных приложений. Релиз 3.1 развивает два основных направления: агентную разработку на базе платформы и встраивание ИИ-функций в приложения на Джеймикс. Изменения</p> <p> затрагивают и процесс разработки, и возможности самих приложений. Часть функциональности, которую раньше разработчики реализовывали вручную, теперь доступна в виде подключаемых компонентов. Кроме того, в новой версии продолжает обновляться технологический стек.</p> <p>Новый инструмент командной строки позволяет создавать проекты без IDE: команды можно вводить вручную в терминале, запускать из скриптов или поручить их выполнение ИИ-агенту. Также при создании проекта через Jmix CLI можно подключить Jmix Agent Toolkit — набор правил и навыков, которые помогают код-агентам следовать паттернам платформы.</p> <p>Функция позволяет по описанию предметной области на естественном языке генерировать начальную динамическую модель данных. После этого разработчик сможет проверить и отредактировать ее. Функция доступна в тестовом режиме, в будущем подход может измениться.</p> <p>Дополнение позволяет встраивать в приложение на Джеймикс чат с ИИ-моделью. Пользователи смогут задавать вопросы в привычном формате, прикреплять файлы, а также делать паузы в работе, не опасаясь, что история диалога не сохранится. Выбор модели при этом остается за командой: можно использовать как публичные, так и локальные LLM.</p> <p>Дополнение сохраняет в черновиках действия, выполненные в окне корпоративного приложения. Например, если пользователь работал над документом, но случайно закрыл вкладку браузера, то изменения не потеряются, их можно будет восстановить при повторном открытии экрана. Раньше действия сохранялись только после нажатия кнопки.</p> Команда Хоулмонт выпустила новую версию open-source платформы Джеймикс для разработки корпоративных приложений. Релиз 3.1 … message https://www.itweek.ru/themes/detail.php?ID=235850 Thu, 29 Oct 2026 19:46:31 +0300 <p>Компания «Аладдин» выпустила новую версию корпоративного центра сертификации Aladdin Enterprise CA 3.0. Она отличается более высокой производительностью, расширенной интеграцией с современными ИТ-средами (включая Kubernetes) и новыми средствами автоматизации, что позволит заказчикам снизить операционные издержки и повысить защищённость ИС. Версия 3.0 доступна для пилотных проектов со 2 ноября 2026 года, начало отгрузок планируется в декабре 2026 года.</p> <p>Среди основных нововведений в Aladdin eCA 3.0:</p> <ul> <li>работа в современных инфраструктурах (Kubernetes и Deckhouse);</li> <li>рост производительности по сравнению с предыдущей версией до 4 раз;</li> <li>автоматизация развертывания SSL-сертификатов (ACME);</li> <li>централизованный сбор событий безопасности и интеграция с SIEM;</li> <li>расширенные возможности администрирования и удобство эксплуатации: поддержка английского языка, интуитивно понятный интерфейс выпуска сертификатов;</li> <li>поддержка РЕД База Данных;</li> <li>расширенные возможности встраивания в существующую ИТ-инфраструктуру заказчика.</li> </ul> <p>Aladdin Enterprise CA является полнофункциональной заменой Microsoft CA, замещающей его без остановки сервисов. Aladdin Enterprise CA 3.0 — первая версия в третьем поколении продукта. Одним из ключевых направлений развития стала работа в современных инфраструктурах (Kubernetes и Deckhouse), что обеспечивает автоматизацию управления, кластеризацию и отказоустойчивость: это критически важно для крупных динамично развивающихся ИТ-ландшафтов (например, в банковском секторе). Также добавлена поддержка РЕД База Данных, расширяющая возможности использования продукта в отечественном программном окружении.</p> <p>В версии 3.0 реализовано централизованное управление журналом безопасности и интеграция с SIEM. Это даёт службам ИБ целостную картину происходящего, ускоряет выявление подозрительной активности и сокращает время реагирования на инциденты. Таким образом, заказчики получают не фрагментарные логи, а управляемый и наблюдаемый контур PKI — это повышает уровень защищённости инфраструктуры.</p> <p>Поддержка протокола ACME позволяет автоматически обслуживать сервисы в Kubernetes и выпускать SSL-сертификаты без ручного вмешательства. При этом в сценариях массового выпуска файловых сертификатов новая версия работает в 4 раза быстрее предыдущей.</p> <p>Aladdin Enterprise CA 3.0 легко интегрируется в существующую ИТ-инфраструктуру заказчиков. Продукт совместим с разнообразными корпоративными средами и платформами, что устраняет барьеры для внедрения, упрощает эксплуатацию в гетерогенных ландшафтах и защищает инвестиции заказчиков в уже используемые технологии: они получают гибкость в выборе компонентов инфраструктуры без привязки к конкретным вендорам.</p> <p>«Развитие Aladdin Enterprise CA направлено на то, чтобы заказчики могли эффективно использовать PKI в современной корпоративной инфраструктуре, сохраняя необходимый уровень безопасности и контроля. Версия 3.0 сейчас проходит сертификацию во ФСТЭК России. В ней мы расширили возможности интеграции с технологическим стеком заказчиков, развили механизмы разграничения полномочий и автоматизации работы с сертификатами, а также существенно повысили производительность. При этом мы сохраняем преемственность продуктовой линейки: пользователи версий 2.x продолжат получать поддержку, исправления ошибок и устранение уязвимостей, а переход на версии 3.x позволит воспользоваться новыми возможностями продукта», — отметил Денис Полушин, руководитель продукта Aladdin eCA, «Аладдин».</p> Компания «Аладдин» выпустила новую версию корпоративного центра сертификации Aladdin Enterprise CA 3.0. Она отличается более … message https://www.itweek.ru/themes/detail.php?ID=235849 Thu, 29 Oct 2026 19:41:15 +0300 <p>Профессиональное ИТ-сообщество Global CIO провело исследование среди ИТ-директоров российских компаний «Приоритеты ИТ-руководителя 2026». Участников опросили, какие ИТ-инициативы дают бизнес-результат, как меняются инвестиционные приоритеты и на каком этапе находится внедрение ИИ.</p> <p>Наибольший измеримый бизнес-эффект за последние два года респонденты связывают с автоматизацией бизнес-процессов — этот вариант выбрали 30% опрошенных. Развитие клиентских сервисов назвали 17%, модернизацию инфраструктуры — 11%. Еще 42% указали другие направления.</p> <p>При росте ИТ-бюджета на 30% дополнительные средства чаще всего направили бы на искусственный интеллект (19%) и кибербезопасность (14%). Автоматизация процессов и управление данными получили по 13%, инфраструктура и ЦОД — 11%. При сокращении бюджета в первую очередь готовы сохранить инфраструктуру (22%) и кибербезопасность (19%). ИИ назвали 13% респондентов.</p> <p>Среди технологий, которые могут повлиять на развитие бизнеса в ближайшие два года, лидируют ИИ-агенты (20%) и сама технология искусственного интеллекта (18%). Далее следуют автоматизация процессов (15%), управление данными (13%) и кибербезопасность (10%).</p> <p>Внедрение ИИ чаще находится на ранних этапах: 46% компаний ведут пилотные проекты, еще 25% изучают возможности. Масштабируют успешные проекты 13%, массово используют ИИ 7%, а 9% пока его не внедряют.</p> <p>Измеримый эффект от ИИ респонденты отмечают в разработке ПО и аналитике — по 16%, документообороте — 11% и Service Desk — 8%. При этом 13% сообщили, что ИИ пока не приносит измеримого эффекта.</p> <p>Главным препятствием для масштабирования ИИ участники исследования назвали неочевидную окупаемость — 20%. Недостаток специалистов отметили 18%, нехватку качественных данных — 15%. Высокая стоимость и незрелость технологий получили по 11%.</p> <p>Результаты показывают, что компании стремятся развивать новые технологии и одновременно поддерживать надежную основу ИТ. При сокращении бюджета в числе первых приоритетов остаются инфраструктура и кибербезопасность. Для масштабирования ИИ компаниям предстоит подтверждать его бизнес-ценность, развивать компетенции и обеспечивать проекты качественными данными.</p> Профессиональное ИТ-сообщество Global CIO провело исследование среди ИТ-директоров российских компаний «Приоритеты … message https://www.itweek.ru/themes/detail.php?ID=235848 Thu, 29 Oct 2026 19:39:14 +0300 <p>Компания «Актив» объявила о выпуске новой версии программного комплекса Рутокен База 1.2.8. Обновление выводит систему управления жизненным циклом ключевых носителей на принципиально новый уровень, предлагая ИТ-подразделениям и службам ИБ расширенную функциональность для работы в высоконагруженных и регулируемых средах.</p> <p>Ключевые возможности обновления:</p> <ul> <li>расширенное управление токенами. Администратор может выполнять полный спектр операций с носителями непосредственно из интерфейса: блокировку и разблокировку токенов, создание ключей, а также создавать запрос на сертификат и запись полученных сертификатов на носитель;</li> <li>упрощение взаимодействия с большим количеством ключевых носителей. Реализована возможность подключения любого токена «из коробки». При подключении к ПК администратора вся информация об устройстве автоматически открывается в режиме администрирования — это упрощает первичную настройку и инвентаризацию;</li> <li>пользовательский контроль. Добавлен компонент Tray для взаимодействия с пользователем. Он позволяет контролировать состояние агента и получать оперативную информацию о подключенных токенах;</li> <li>массовые операции. Внедрена поддержка массовых действий над объектами учета, включая массовую выдачу ключей через импорт данных из файла. Это значительно снижает трудозатраты администраторов при выдаче и постановке на учет токенов и сертификатов большого количества сотрудников;</li> <li>учет программных и аппаратных СКЗИ. Существенно расширены возможности учета программных средств криптографической защиты информации (СКЗИ) и СЗИ, а также добавлен учет сертификатов TLS;</li> <li>гибкое управление жизненным циклом. Появилась возможность возврата, отмены постановки на учет и повторной постановки на учет поддерживаемых СКЗИ/СЗИ.</li> </ul> <p>Новая версия Рутокен База 1.2.8 ориентирована на средние и крупные организации, где вопросы централизованного управления КЭП и соответствия требованиям ФСБ России и ФСТЭК России стоят особенно остро. Решение востребовано в финансовом секторе, госструктурах, здравоохранении, образовании, а также на объектах критической инфраструктуры.</p> Компания «Актив» объявила о выпуске новой версии программного комплекса Рутокен База 1.2.8. Обновление выводит систему … message https://www.itweek.ru/themes/detail.php?ID=235847 Thu, 29 Oct 2026 10:08:22 +0300 <p><em>В 2027 г. главным препятствием на пути к получению реальной отдачи от искусственного интеллекта станут растущие расхождения между тем, что, по мнению руководителей, может делать ИИ, и тем, как сотрудники на практике используют его в своей работе, пишет в корпоративном блоге Анджелина Геннис, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Подобные противоречия в ожиданиях руководства и персонала существовали всегда, но ИИ значительно их усиливает. Возникает глубокая пропасть: с одной стороны — топ-менеджеры, продвигающие концепцию «ИИ-нативной» работы, с другой — рядовые сотрудники, которым приходится сталкиваться с повседневными реалиями внедрения этой технологии. Руководители продолжают повышать ожидания относительно роста эффективности, в то время как сотрудники пытаются освоить инструменты (которые зачастую не оправдывают шумихи вокруг них) и применить их в задачах, для которых еще не выработаны четкие сценарии использования.</p> <p>Руководители, которые не обеспечат полноценное вовлечение людей в этот процесс, не получат ожидаемой окупаемости инвестиций (ROI). Таким образом, 2027 г. станет для лидеров временем принятия ответственности за объединение людей и технологий — только так можно добиться реальных преимуществ от использования ИИ в работе. Ниже представлены три наших прогноза на следующий год.</p> <p><strong>Мониторинг сотрудников с помощью ИИ подавит инициативу у трети персонала. </strong>Практика контроля за работниками существует еще со времен появления первых фабрик — достаточно долго, чтобы ученые успели изучить ее влияние на мотивацию и производительность. Если сотрудники воспринимают такой контроль как инструмент наказания, а не как помощь в достижении успеха, это заметно снижает их готовность проявлять инициативу и экспериментировать — а ведь именно на этом строятся качественное обслуживание клиентов и инновации. ИИ-мониторинг усугубляет этот эффект, поскольку воспринимается как процесс, лишенный человеческого контроля со стороны руководства. Дальновидные лидеры предпочтут избежать этого, взяв на себя ответственность за использование ИИ-мониторинга: они будут применять его открыто и только в тех случаях, когда это действительно помогает сотрудникам лучше справляться со своими задачами.</p> <p><strong>Сотрудники с высоким уровнем «ИИ-интеллекта» (AIQ) получат доступ к более совершенным инструментам, что приведет к разрыву в производительности. </strong>Многие стратегии внедрения ИИ сегодня буксуют: руководители инвестируют в технологии, но не получают желаемых результатов. Согласно исследованию Forrester «State Of AI Survey, 2026», хотя 66% компаний внедряют инструменты ИИ в свои рабочие приложения, лишь 32% отмечают, что это действительно приводит к росту производительности. Несмотря на масштабные инвестиции и заявления о внедрении инноваций на базе ИИ, ощутимого влияния на рост производительности труда пока не наблюдается. Проблема не в самой технологии, а в недостаточном внимании к людям и процессам, необходимым для ее эффективного использования. Чтобы добиться реального повышения производительности с помощью ИИ, следует инвестировать в комплексное обучение сотрудников и применять ИИ для решения конкретных задач, а не для полной замены рабочих мест.</p> <p><strong>Каждое десятое предприятие столкнется с негативной реакцией на внедрение ИИ, которая может перерасти в злонамеренное следование инструкциям. </strong>В настоящее время 18% сотрудников демонстрируют активную отстраненность от работы — это не просто «тихие увольнения», а потенциально деструктивное поведение. Поскольку работодатели продолжают убеждать финансистов в огромном потенциале ИИ, хвастаясь сокращениями штата (уже проведенными или запланированными), некоторые из таких сотрудников не уйдут из компании, а перейдут к тактике злонамеренного следования инструкциям. Каждая десятая крупная компания столкнется с последствиями саботажа: сотрудники будут в точности выполнять указания по использованию ИИ, даже зная, что это неэффективно. Руководителям следует четко разъяснять связь между внедрением ИИ и общими целями компании, прежде чем у сотрудников укрепится подозрение, что то, что выгодно организации, — вредно для них самих.</p> В 2027 г. главным препятствием на пути к получению реальной отдачи от искусственного интеллекта станут … article https://www.itweek.ru/themes/detail.php?ID=235845 Thu, 29 Oct 2026 09:59:17 +0300 <p><em>За первые три квартала 2026 года мы провели переговоры с более чем ста российскими компаниями, использующими объектное хранилище S3. У большинства запрос одинаковый: тариф не менялся, объем полезных данных тот же, а счет вырос. Разберем, где именно прячутся расходы и почему первоначальный расчет расходится с реальным счетом.</em></p> <h3>Почему тариф не менялся, а счет вырос</h3> <p>Когда компания выбирает S3, главный ориентир — цена гигабайта в месяц. По этому параметру сравниваются провайдеры и строится бюджет. Пока данные размещены без движения, такой расчет точен. Расхождение начинается, когда хранилище начинают активно использовать.</p> <p>Счет за S3 складывается не только из объема хранения. В него также входят операции с объектами и исходящий трафик. Обращение к хранилищу может тарифицироваться отдельно или входить в лимит тарифа, и чем активнее приложение работает с данными, тем заметнее эти статьи расходов. Место в хранилище при этом может почти не меняться, а в счете появляются строки, которых в первоначальном расчете не было.</p> <p>С неожиданной платой за исходящий трафик сталкиваются единицы. Чаще причина роста счета — другая ситуация: компания выбирала тариф только по цене хранения и не обратила внимания на то, что тарифный план включает ограниченное количество запросов. Когда реальный объем запросов оказывался на порядок больше включенного лимита, счет резко вырастал. Поэтому до выбора тарифа стоит понять не только объем данных, но и то, как приложение с ними фактически работает: именно это в конечном счете и определяет итоговый счет.</p> <h3>Откуда берутся 30 Тб, когда данных было 10</h3> <p>Версионирование в S3 сохраняет предыдущие копии файлов. Функция полезная: она позволяет откатиться к нужной версии, если что-то пошло не так. Но срок хранения этих версий редко определяют заранее, и именно здесь начинается проблема. Новые версии копятся, старые остаются, и через несколько месяцев компания обнаруживает, что платит за данные, о существовании которых давно забыла.</p> <p>Например, компания хранит 10 Тб видеофайлов. После изменения настроек обработки обновляет набор дважды. Пользователь видит 10 Тб актуальных материалов, именно столько нужно бизнесу. Но внутри хранилища при включенном версионировании и без настроенной очистки остаются все три набора, то есть уже 30 Тб. Счет вырастает втрое, хотя объем полезных данных не изменился.</p> <p>Версии файлов составляют лишь часть проблемы. После диагностики приложения в хранилище остаются подробные логи. После завершения аналитического проекта там накапливаются временные выгрузки. Каждый из этих массивов появился по делу, но необходимость его дальнейшего хранения редко пересматривают. Данных становится больше, хранилище масштабируется само по себе, и расхождение между тем, за что платят, и тем, что реально нужно, нарастает незаметно. В собственной инфраструктуре переполненный диск обычно сигнализирует о проблеме сразу. В S3 объем хранилища масштабируется, поэтому без настроенных уведомлений такого сигнала может не быть — счет просто продолжает расти.</p> <p>Для автоматической очистки в S3 предусмотрены правила жизненного цикла: можно настроить удаление незавершенных загрузок старше месяца или ограничить число хранимых версий одного файла, например тремя. Хранилище будет удалять лишнее самостоятельно. Но настраивают эти правила заранее редко. По общим наблюдениям, около 90% компаний хранят больше данных, чем реально используют, и разбираться с этим начинают только тогда, когда оплачиваемое место заканчивается и в работе приложений появляются ошибки.</p> <p>Показательный пример: одна компания обнаружила, что хранила в 10 раз больше данных, чем использовала. Команда включила версионирование, рассчитывая на автоматическую дедупликацию — которой в S3 нет. Хранилище сохраняло новую версию при каждой перезаписи файла. Объем вырос в 10 раз, место закончилось, и только тогда ситуацию начали разбирать. Совет здесь один: включать версионирование только там, где оно действительно необходимо, и понимать, что каждая версия — это отдельный объект, занимающий свое место. Удалять данные подряд при этом рискованно: среди старых копий может оказаться единственная версия, пригодная для восстановления. Поэтому сначала у каждого крупного массива стоит найти владельца, который определит, зачем он хранится и как долго, и только после этого настраивать очистку.</p> <h3>Как дешевый класс хранения становится дорогим</h3> <p>Перевод редко используемых данных в более дешевый класс хранения оправдан, если данные читают эпизодически и объем достаточно велик. Но у этого решения есть несколько условий, которые легко упустить при выборе тарифа.</p> <p>Низкая цена размещения нередко сочетается с более дорогим чтением или отдельной платой за извлечение. Для некоторых классов действует минимальный оплачиваемый срок хранения: удалить файл раньше разрешено, но платить придется за весь период. Есть и минимальный оплачиваемый размер объекта — небольшой временный файл тарифицируется как более крупный. В итоге дешевый класс может оказаться невыгодным именно для той нагрузки, под которую его выбирали. Холодные классы хранения на российском рынке используются относительно редко, и именно поэтому их условия чаще всего остаются неизученными до момента, когда они уже повлияли на счет.</p> <p>Отдельного внимания заслуживает скорость получения данных из холодного класса — она напрямую влияет на то, подходит ли такой класс для резервных копий. Холодные классы бывают двух типов: одни дают прямой доступ, другие требуют предварительного восстановления из архива. Даже при прямом доступе передача большого массива небыстрая: выгрузка 100 Тб по каналу 1 Гбит/с потребует около 9,3 суток непрерывной работы. Для резервной копии скачивание составляет лишь часть пути: нужно еще распаковать данные, восстановить базу и запустить приложение. Если бизнес допускает четыре часа простоя, дешевое размещение не компенсирует многодневное восстановление. Важный момент: скорость отдачи данных у большинства холодных классов сопоставима с горячим хранением. Разница не в скорости, а в стоимости каждого запроса. Холодный класс выгоден ровно до тех пор, пока данные лежат без движения. Как только к ним начинают обращаться регулярно, стоимость запросов может перекрыть всю экономию от дешевого размещения. Класс стоит выбирать под требования конкретной системы, а не по строке в прайсе.</p> <h3>Когда расходы выходят из-под контроля</h3> <p>Управляемый счет — не тот, что не меняется каждый месяц. Управляемый — тот, по которому компания понимает причины изменения расходов и видит риск выхода за бюджет до получения счета, а не после. Полный расчет стоимости эксплуатации S3 с учетом хранения, операций, трафика и сценариев восстановления сегодня запрашивают практически все компании на этапе переговоров с провайдером. Рынок в этом плане заметно повзрослел по сравнению с <nobr>2024-25 годами.</nobr> Но понимание полной стоимости при выборе провайдера и контроль расходов в процессе эксплуатации — разные вещи. Второго, как правило, нет.</p> <p>Выстроить этот контроль помогает политика ревизии данных. Без назначенного владельца данных и зафиксированной даты следующей проверки ревизия остается разовой акцией. Через полгода ситуация повторяется. Чтобы этого не происходило, контроль расходов должен быть встроен в регулярный процесс: пороговые уведомления на рост потребления, ответственный за каждое уведомление и плановые ревизии состава хранилища. Отдельный тренд, заметный в 2026 году: крупные компании всё чаще запрашивают расчет хранения больших объемов — от 1 до 3 Пб — и сопоставляют стоимость облачного хранения с собственной инфраструктурой. При таких объемах они считают не только цену гигабайта, но и совокупную стоимость владения: затраты на оборудование, резервирование, эксплуатацию, персонал, электроэнергию и требования к доступности. Это показывает, что рынок все чаще принимает решение о модели хранения на основе полной экономики, а не отдельной ставки за хранение.</p> <h3>Что проверить, если счет оказался выше ожидаемого</h3> <p>За два часа нельзя провести полный аудит большого хранилища, но можно найти то, что стоит разобрать в первую очередь. Понадобятся детализация последнего счета, отчет о составе хранилища и настройки сроков хранения. Удобнее начать с одного крупного проекта: связать расходы с конкретным приложением и найти человека, который за него отвечает.</p> <p>Первый шаг — сопоставить оплаченный объем с объемом актуальных данных. Если приложение использует 10 Тб, а в счете существенно больше, смотрим прежние версии, дополнительные копии и временные массивы, проверяем правила очистки и когда они фактически выполнялись. Затем разбираем остальные строки счета: какое приложение и куда передавало данные, какие операции дали основной вклад. Рост числа клиентов и ошибка в архитектуре приложения могут дать одинаковое увеличение суммы, но потребуют совершенно разных действий. Наконец, стоит проверить условия массовой выгрузки и то, сколько реально займет восстановление системы на полном объеме — именно это чаще всего оказывается неожиданностью.</p> <p>Если же предстоит выбор нового провайдера, то ключевых вопроса три. Из чего складывается цена хранения и какие классы доступны. Как организовано резервирование данных и какие методы S3 API поддерживаются — неполная или нестандартная реализация создаст проблемы при интеграции с приложениями, использующими S3 API.</p> <p>#IMAGE_235846#</p> За первые три квартала 2026 года мы провели переговоры с более чем ста российскими компаниями, использующими … article Тимур Чубарин, генеральный директор mt cloud https://www.itweek.ru/themes/detail.php?ID=235843 Thu, 29 Oct 2026 09:51:59 +0300 <p>Пилоты с ИИ-агентами сейчас есть почти у всех. Прод с агентами, которые реально трогают внешний мир, есть у немногих. Разница почти никогда в модели. Разница в том, где человек обязан сказать «да», прежде чем система сделает необратимое.</p> <p>Если агент может сам писать клиентам, катить код в прод и тратить деньги, он уже не ассистент. Он оператор с правами. Без жёстких человеческих гейтов вы масштабируете не скорость, а риск.</p> <p>Ниже — операционный паттерн, не продукт и не кейс конкретного бренда. Три гейта: отправка наружу (SEND), выкладка в прод (DEPLOY), деньги и лимиты (SPEND). Плюс что измерять до масштабирования и где обычно ломается.</p> <h2>1. Почему «агент без гейта» — операционный риск, а не фича</h2> <p>Демо любит показывать непрерывный цикл: агент прочитал задачу, сам решил, сам сделал. В проде тот же цикл бьёт по трём местам:</p> <ul> <li> наружу уходит сообщение, которое нельзя отозвать так же легко, как черновик;</li> <li> в прод уходит изменение, которое ломает чужой рабочий день;</li> <li> с карты или бюджета списывается сумма, которую потом разбирают юристы и финансы, а не инженеры.</li> </ul> <p>Модель ошибается иначе, чем человек. Она уверена в слабом контексте. Она обобщает из похожего. Она пропускает редкий, но дорогой край. Поэтому «почти правильно» опаснее явной ошибки: явная ошибка ловится тестом, «почти» уходит в клиента.</p> <p>Правило простое: всё, что необратимо снаружи системы, проходит через человека. Внутри можно автоматизировать смело. Снаружи — только через гейт.</p> <h2>2. Три обязательных человеческих гейта</h2> <h3>SEND — отправка наружу</h3> <p>Сюда входит всё, что видит другой человек или внешняя система от вашего имени: письмо, сообщение в мессенджер, комментарий, заявка, ответ клиенту, публикация.</p> <p>Минимум правил:</p> <ul> <li> черновик готовит агент;</li> <li> человек видит получателя, тему, полный текст и зачем это уходит;</li> <li> без явного «отправить» ничего не уходит;</li> <li> исключений «кроме срочных» быть не должно: срочность — лучший способ сломать гейт.</li> </ul> <p>Что ломает SEND на практике: автоответы на неоднозначные письма, рассылки «по списку похожих», ответы в тред, где уже спорят люди. Если агент не отличает «информационный запрос» от «юридический / денежный / репутационный», SEND должен быть жёстче, а не мягче.</p> <h3>DEPLOY — выкладка в прод</h3> <p>Сюда входит всё, что меняет живую систему: сайт, конфиг, права доступа, прод-данные, включение новой автоматизации на реальном трафике.</p> <p>Минимум правил:</p> <ul> <li> агент может собрать дифф, прогнать проверки, подготовить артефакт;</li> <li> человек смотрит, что именно меняется и как откатить;</li> <li> без явного «деплой» прод не трогают;</li> <li> «черновик/staging» не считается продом, даже если URL похож. </li> </ul> <p>Что ломает DEPLOY: тихие правки «на один файл», правки в админке без диффа, включение флага для 100% аудитории без canary. Если нельзя показать откат одной фразой, это ещё не готово к человеческому «да».</p> <h3>SPEND — деньги и лимиты</h3> <p>Сюда входит всё, что двигает деньги или создаёт обязательство: реклама, подписки, облако, подрядчики, закупки, лимиты API с платным потолком.</p> <p>Минимум правил:</p> <ul> <li> агент может оценить стоимость и собрать сравнение;</li> <li> человек задаёт потолок и период;</li> <li> без явного «тратить» деньги не уходят;</li> <li> снятие или смена лимита — тоже SPEND, не «настройка». </li> </ul> <p>Что ломает SPEND: автопродления, «временные» апгрейды, агенты с сохранённой картой, кампании без дневного капа. Самый частый провал — не разовый платёж на тысячу, а тихий месячный вампир на десятки, который никто не отменял, потому что его «поставил агент».</p> <h3> Связка трёх гейтов </h3> <p>SEND без SPEND бессмысленен, если сообщение запускает платную цепочку. DEPLOY без SEND опасен, если выкладка включает автосообщения. SPEND без DEPLOY опасен, если деньги уходят в ещё не проверенный пайплайн. Гейты — не три галочки в разных местах. Это одна политика: необратимое снаружи = человек.</p> <h2>3. Что измерять до масштабирования</h2> <p>Пока нет цифр, гейты держат на страхе. Страх плохо масштабируется. Нужны простые счётчики:</p> <ul> <li> доля действий, остановленных человеком на SEND/DEPLOY/SPEND (если ноль — гейт декоративный или агент слишком трусливый);</li> <li> доля правок человека в черновике до отправки (если почти всё переписывается — агенту рано расширять права);</li> <li> число откатов DEPLOY за неделю и среднее время до отката;</li> <li> стоимость одного успешного шага и стоимость одной ошибки (включая время людей);</li> <li> число «почти правильных» инцидентов: ушло, потом чинили руками. </li> </ul> <p>Масштабировать агента стоит только когда растёт доля чистых проходов через гейт при стабильной или падающей цене ошибки. Если скорость растёт, а цена ошибки тоже — вы ускоряете хаос.</p> <h2>4. Типичные провалы</h2> <p><strong>Автоматизация бардака.</strong> Если процесс уже кривой, агент сделает кривое быстрее и чаще. Сначала упростить путь, потом отдавать агенту.</p> <p><strong>Подмена метрик.</strong> «Сделано задач» вместо «не сломали прод/не списали лишнее/не обидели клиента». Агент оптимизирует то, что вы считаете.</p> <p><strong>Нет аудита.</strong> Через неделю никто не скажет, кто нажал SEND и по какому черновику. Без лога гейт нельзя улучшить.</p> <p><strong>Исключения без срока.</strong> «Только сегодня без гейта» становится нормой. Любое исключение должно иметь дату конца и имя человека, который его взял на себя.</p> <p><strong>Смешение ролей.</strong> Один и тот же агент пишет клиенту, катит код и поднимает бюджет. Даже с гейтами лучше разделить контуры: меньше связок, проще остановить один контур.</p> <p><strong>Слишком широкий контекст.</strong> Агенту дали доступ «ко всему, вдруг пригодится». Пригодилось один раз. Утекло или сломалось навсегда. Контекст режется под задачу, не под страх упустить.</p> <h2>5. Как внедрять без театра</h2> <p><strong>Неделя 1. </strong>Нарисовать карту: какие действия у вас уже необратимы снаружи. Повесить на каждое SEND, DEPLOY или SPEND. Где гейта нет — поставить ручной.</p> <p><strong>Неделя 2.</strong> Заставить агента готовить только черновики и диффы. Человек жмёт три кнопки. Логировать каждое решение.</p> <p><strong>Неделя 3.</strong> Смотреть правки человека и инциденты. Узкие классы задач, где правки редки, можно ускорять. Широкие и дорогие — оставлять жёсткими.</p> <p><strong>Неделя 4. </strong>Ввести лимиты SPEND и canary для DEPLOY. Не снимать гейт. Сужать круг задач, где «да» даётся быстрее, потому что риск измерен.</p> <p>Цель не «человек всегда в цикле». Цель — человек всегда в цикле там, где цена ошибки не умещается в эксперимент. </p> <h2>6. Минимальный журнал гейта</h2> <p>Без журнала гейт нельзя улучшить и нельзя доказать аудиту. Минимум полей на каждое SEND / DEPLOY / SPEND:</p> <ul> <li> кто агент и какой контур (почта, прод, бюджет);</li> <li> что именно предлагалось (получатель/дифф/сумма и период);</li> <li> кто человек и когда сказал «да» или «нет»;</li> <li> что изменил человек в черновике до «да»;</li> <li> чем кончилось через <nobr>24-72</nobr> часа (ок/инцидент/откат/спор). </li> </ul> <p>Журнал хранят там, где его реально читают: тикет, changelog, отдельная таблица. Скриншоты в личке не считаются. Если через неделю нельзя ответить «кто нажал и почему» — гейта по сути нет.</p> <h2>7. Короткий вывод</h2> <p>ИИ-агент в проде без человеческих гейтов — это ускоритель всего, включая ошибки. Три гейта закрывают три необратимости: слово наружу, изменение в живой системе, движение денег. Пока вы не считаете остановки, откаты и цену ошибки, масштабирование — вера, а не инженерия.</p> <p>Автоматизируйте подготовку. Оставляйте человеку отправку, выкладку и траты. Тогда агент повышает темп, а не площадь поражения.</p> <p>#IMAGE_235844#</p> Пилоты с ИИ-агентами сейчас есть почти у всех. Прод с агентами, которые реально трогают внешний мир, есть … article Максим Лагошин, основатель Create Paradise Now https://www.itweek.ru/themes/detail.php?ID=235836 Wed, 28 Oct 2026 17:13:12 +0300 <p>Технологическая компания GETMOBIT вывела на рынок GM Virtual Media Optimizer — программное решение, которое переносит обработку видео и звука с серверов виртуальных рабочих мест (VDI) на устройство пользователя. Продукт расширяет возможности протоколов удалённого доступа VDI и позволяет использовать системы видео-конференц-связи (ВКС) без критической нагрузки на серверную инфраструктуру. С 1 ноября 2026 года решение доступно для пилотных проектов, промышленного внедрения и интеграции в продукты разработчиков <nobr>VDI-платформ.</nobr></p> <p>Новый инструмент в первую очередь востребован в финансовом секторе, госкорпорациях и промышленности, где VDI используется для выполнения строгих требований информационной безопасности, а видеосвязь служит основным каналом взаимодействия распределённых команд.</p> <p>Видеоконференции стали одним из самых ресурсоёмких сценариев для таких сред. Когда ВКС запускается внутри виртуальной машины, кодирование медиапотоков забирает не менее половины процессорных ресурсов (vCPU), вызывая зависания видео и рассинхронизацию звука. Попытки решить проблему экстенсивным путем ведут к колоссальным затратам. По оценке GETMOBIT, расширение инфраструктуры VDI под типовую нагрузку ВКС на 2000 пользователей требует около 90 млн рублей дополнительных капитальных затрат. А возврат к локальным ПК, как альтернативный сценарий, обходится примерно в 80 млн рублей только на оборудование. Кроме того, он усложняет эксплуатацию и вывыводит корпоративные коммуникации за периметр безопасности VDI.</p> <p>«Для крупного бизнеса видеосвязь стала кровеносной системой, но внутри защищённого контура VDI она превратилась в узкое место, сжигающее серверные ресурсы. Мы постоянно обсуждаем это с ИТ-директорами и знаем их боль. Масштабирование ВКС требует колоссальных затрат на оборудование или болезненного возврата к локальным ПК. Как продуктовая компания, мы хотим дать заказчикам технологию, которая снимает эту нагрузку с серверов целиком и работает с любой системой ВКС. GM Virtual Media Optimizer — это новый механизм расширения протоколов VDI, которым могут пользоваться и заказчики, и разработчики платформ. Он позволяет сохранить модель рабочих мест на тонких клиентах и возвращает бизнесу контроль над инфраструктурным бюджетом», — подчеркнула Мария Рукавишникова, генеральный директор и основатель GETMOBIT.</p> <p>GM Virtual Media Optimizer работает через виртуальные каналы протоколов удалённого доступа, используя архитектурный подход client fetch — client render. Клиентское устройство получает медиапотоки напрямую и обрабатывает их локально, в то время как интерфейс и бизнес-логика приложения ВКС остаются надежно изолированными внутри виртуальной машины. Оптимизатор совместим с системами ВКС в режиме веб-конференций (WebRTC, WebAssembly) и позволяет заказчикам не привязываться к конкретной платформе видеосвязи. На стороне клиента решение поддерживает работу на тонких клиентах GM-Box, устройствах с ОС GMSS NG Client, а также на оборудовании сторонних производителей под управлением Linux и Windows.</p> <p>«Вычислительная мощность не берётся из ниоткуда. Всё, что не удалось сэкономить на видео-конференц-связи, заказчик оплачивает серверами VDI или возвратом к ПК. Мы убрали VDI из пути медиапотока. Видео и звук обрабатываются на устройстве пользователя, а приложение ВКС остаётся в защищённом контуре. Теперь качество связи определяется только самой системой ВКС, и виртуальная инфраструктура перестаёт быть узким местом», — рассказал Александр Тарасов, главный системный архитектор GETMOBIT.</p> <p>По оценке GETMOBIT, потенциальная ёмкость рынка решений для оптимизации ресурсов VDI при работе с ВКС составляет около 450 млн ₽ в год — это почти десятая часть текущего рынка инфраструктуры виртуальных рабочих мест.</p> <p>Компании могут провести пилотный проект GM Virtual Media Optimizer на собственной инфраструктуре. Решение распространяется по подписке пакетами лицензий (обновления включены в стоимость). Разработчики отечественных <nobr>VDI-платформ</nobr> и систем ВКС также могут встроить оптимизатор в свои решения как готовый технологический компонент.</p> Технологическая компания GETMOBIT вывела на рынок GM Virtual Media Optimizer — программное решение, которое … message https://www.itweek.ru/themes/detail.php?ID=235835 Wed, 28 Oct 2026 17:11:44 +0300 <p>Компании «Аладдин» и «Группа Астра» подтвердили корректную работу средств строгой аутентификации JaCarta с операционной системой Astra Linux РУСБ.10015-01 версий 1.7 и 1.8. Соответствующие сертификаты выданы по итогам цикла совместных испытаний.</p> <p>Подтверждённая совместимость позволяет заказчикам применять USB-токены и смарт-карты JaCarta, а также смарт-карт ридеры JCR для строгой аутентификации пользователей, безопасного хранения ключей и сертификатов и работы с электронной подписью в ОС Astra Linux. Проверку прошли следующие устройства «Аладдин»:</p> <ul> <li>JaCarta-3 PKI/ГОСТ/SecurBIO — с Astra Linux SE 1.7 и 1.8;</li> <li>JaCarta-3 ГОСТ — с Astra Linux SE 1.8;</li> <li>JaCarta PKI/ГОСТ — с Astra Linux SE 1.8;</li> <li>JaCarta PKI/BIO — с Astra Linux SE 1.8;</li> <li>профессиональный смарт-карт ридер JCR721 — с Astra Linux SE 1.8;</li> <li>профессиональный смарт-карт ридер JCR761 — с Astra Linux SE 1.8.</li> </ul> <p>Испытания проводились в рамках программы технологического партнёрства Ready for Astra. Цель программы — создание преимущественного положения на ИТ-рынке для всех её участников за счёт совместимости с экосистемой «Группы Астра», а также повышение безопасности партнёрских продуктов. В ходе испытаний проверялись обнаружение устройств операционной системой, работа с сертификатами и ключами, функционирование в связке с «Единым Клиентом JaCarta» версии 3.3 и другие сценарии. По результатам тестов зафиксировано, что все устройства под управлением Astra Linux 1.7 и 1.8 функционируют корректно.</p> <p>В линейку продуктов JaCarta входят сертифицированные средства строгой аутентификации, электронной подписи для безопасного хранения ключей, работы с цифровыми сертификатами и интеграции с корпоративными системами управления доступом и единым входом (SSO). Смарт-карты, электронные ключи и USB-токены JaCarta сертифицированы ФСТЭК России и ФСБ России, включены в реестры Минпромторга РФ и Минцифры РФ и совместимы с российскими и зарубежными ОС.</p> <p>«Инфраструктуры на базе Astra Linux предъявляют строгие требования к средствам аутентификации. Подтверждённая совместимость устройств JaCarta с ОС версий 1.7 и 1.8 снимает у заказчиков вопросы интеграции: российские USB-токены, смарт-карты и смарт-карт ридеры работают на Astra Linux без ограничений и дают необходимую базу для построения доверенных сред», — отметил Сергей Ступин, руководитель продуктов семейства JaCarta компании «Аладдин».</p> <p>«Обеспечение технологической независимости и высокого уровня безопасности рабочих мест — приоритетная задача для наших клиентов. Успешное завершение испытаний в рамках программы Ready for Astra подтверждает, что пользователи Astra Linux версий 1.7 и 1.8 получают полностью готовое, протестированное и бесшовное решение для строгой аутентификации и работы с электронной подписью. Совместимость с популярными токенами и смарт-картами JaCarta позволяет организациям безболезненно мигрировать на отечественную операционную систему, сохраняя привычно высокий уровень защиты конфиденциальных данных и удобство ежедневной работы сотрудников», — отметил Дмитрий Чубанов, менеджер продукта Astra Linux Desktop «Группы Астра».</p> Компании «Аладдин» и «Группа Астра» подтвердили корректную работу средств строгой аутентификации JaCarta с операционной … message https://www.itweek.ru/themes/detail.php?ID=235831 Wed, 28 Oct 2026 09:48:05 +0300 <p><em>Представление о физическом искусственном интеллекте (Physical AI) уже давно вышло за рамки привычного образа роботизированной руки на конвейере. Сара Ли, старший директор IDC по исследованиям в области ИТ-стратегий для производства, объясняет в корпоративном блоге, что физический ИИ означает на самом деле, почему нехватка рабочей силы стимулирует внедрение технологий быстрее, чем сами технологические достижения, и почему представление о безлюдном производстве — это ошибочный взгляд на будущее данной сферы.</em></p> <p>Роботизированная рука, собирающая детали в заводском цеху, — простой и очевидный образ. Но это лишь часть картины. Более того, именно такое узкое восприятие зачастую тормозит развитие компаний.</p> <p>Термин «физический ИИ» стал настолько широким, что под него теперь подгоняют практически любое устройство, оснащенное датчиком. Есть более точное и полезное определение: это интеграция алгоритмов ИИ (машинного обучения, компьютерного зрения, а сегодня — и мультимодальных агентных систем) с физическим оборудованием с образованием замкнутого цикла. Система собирает данные об окружающей среде, интерпретирует их, принимает решение, совершает действие в физическом мире, а затем возвращает информацию о результате обратно в систему, чтобы в следующий раз она сработала еще лучше.</p> <p>В этом замкнутом цикле и заключается суть: физический ИИ сам обнаруживает проблему, сам решает, что с ней делать, и сам же предпринимает необходимые действия — и всё это происходит внутри одной системы. Традиционные же панели мониторинга, которые лишь сигнализируют человеку о возникшей неполадке, для таких задач изначально не предназначались.</p> <h3>Движущая сила — не технологии</h3> <p>Даже понимая, что именно относится к физическому ИИ, трудно объяснить, почему эта технология вдруг стала повсеместной. Большинство людей назовут причиной развитие моделей компьютерного зрения или удешевление датчиков. Но есть и другой фактор: нехватка рабочей силы.</p> <p>В горнодобывающей и строительной отраслях дорогостоящее оборудование простаивает, потому что им некому управлять. На производстве уходят на пенсию опытные специалисты, унося с собой накопленные десятилетиями уникальные знания — и новые сотрудники просто не успевают их перенять. Если добавить к этому торговые пошлины и нестабильность цепочек поставок, автоматизация перестает быть просто «приятным дополнением» и становится необходимостью. На самом деле, потребность в физическом ИИ продиктована вовсе не технологической стороной. Она продиктована тем, что рабочая сила и операционная среда должны быть более устойчивыми, поскольку одного найма недостаточно для решения проблем.</p> <p>Бóльшая часть оборудования, на котором должны работать решения физического ИИ, изначально для них не создавалась. Исследование IDC уточняет суть проблемы унаследованной инфраструктуры: большинству действующих сегодня производственных объектов более двадцати лет, и на них установлены устаревшие программируемые логические контроллеры (ПЛК), не имеющие встроенных возможностей подключения. Это означает, что главным узким местом зачастую становится не вычислительная мощность или качество моделей, а получение чистых, пригодных для использования данных от оборудования, которое изначально не было рассчитано на обмен ими.</p> <p>Технологии достигли необходимого уровня развития как раз вовремя. Появились более совершенные визуально-языковые модели, улучшенные средства имитационного моделирования и цифровые двойники, а также технологии периферийного ИИ, позволяющие принимать решения в режиме реального времени без обращения к облаку. Все это в совокупности сделало практически реализуемым создание работоспособного замкнутого контура — причем с той скоростью, которая требуется в цехах или на горнодобывающих предприятиях.</p> <h3>Единая архитектура, разные условия эксплуатации</h3> <p>Базовый принцип замкнутого контура остается неизменным, однако его наполнение варьируется в зависимости от отрасли. Дальше всего продвинулось дискретное производство: здесь роботы и коботы выполняют высокоточные операции, проводят инспекции и перемещают материалы. На складах и в больницах для транспортировки грузов используют автономных мобильных роботов и автоматизированные вилочные погрузчики. В строительстве, горнодобывающей промышленности и сельском хозяйстве применяются, например, автономные комбайны, буровые установки и карьерные самосвалы, работающие в суровых условиях, зачастую без стабильного сетевого подключения — здесь требования к отказоустойчивости и нормативные стандарты совершенно иные, чем в обычном заводском цеху.</p> <p>Процесс внедрения физического ИИ следует рассматривать не как разовый рывок, а как путь постепенного созревания технологий, поскольку практически ни одно предприятие не начинает работу с нуля:</p> <ol> <li> Операции с использованием контрольно-измерительных средств: датчики передают данные, но окончательное решение всё равно принимает человек.</li> <li> Автоматизация с замкнутым контуром: ИИ начинает интерпретировать данные и инициировать действия в заданных рамках.</li> <li> Воплощенная автономия: машины самостоятельно воспринимают обстановку, планируют действия и выполняют их.</li> <li> Скоординированные системы (находятся на стадии становления): взаимодействие нескольких машин, людей и систем, объединенных общим контекстом и едиными протоколами безопасности.</li> </ol> <p>Большинство компаний находятся где-то в середине этой шкалы. Совет тем, кто стоит на более ранних этапах: прежде чем запускать пилотный проект, убедитесь, что ваши данные действительно чистые и готовы к использованию. С чего начать внедрение? Где в первую очередь проводить пилотные проекты? Там, где данные уже приведены в порядок, подготовлены, актуальны и отличаются высоким качеством.</p> <h3>Где возникает (и где буксует) окупаемость инвестиций</h3> <p>Разрыв между успешным пилотным проектом и реальной окупаемостью — это то, из-за чего умирает большинство инициатив. Эффект (повышение производительности, пропускной способности, безопасности, ускорение ввода в эксплуатацию) проявляется только при масштабировании на весь парк оборудования, а не в рамках пилота. Чтобы достичь этого, необходимо обеспечить координацию работы множества машин на разных производственных площадках — одного лишь доказательства того, что робот исправно функционирует в каком-то одном уголке цеха, недостаточно.</p> <h3>Что показывают текущие исследования IDC</h3> <p>Проблема оркестрации — это именно то, что отслеживают аналитики IDC, и цифры свидетельствуют о стремительных изменениях в этой сфере. Согласно опросу, проведенному в мае 2026 г., физический ИИ занял второе место среди приоритетных направлений для инвестиций в ИИ на ближайшие 24 месяца — уступив лишь генеративному ИИ (GenAI) и интеллектуальным помощникам (копилотам). Аналогичные результаты показал опрос IDC «2026 Worldwide CEO Survey»: 45% руководителей высшего звена включили физический ИИ в тройку наиболее перспективных технологий для инвестиций в ближайшие <nobr>12-24</nobr> месяца — сразу после внедряемых в масштабах всей компании агентного и генеративного ИИ, а также технологий устойчивого развития.</p> <p>Цифровые двойники перестают быть просто средством визуализации. По данным исследования IDC, меняется сама логика: от подхода «симуляция → реальность» (sim-to-real) к подходу «реальность → симуляция» (real-to-sim). В последнем случае собственные производственные данные предприятия используются для обучения и проверки ИИ еще до того, как он начнет взаимодействовать с физической средой. Это превращает специфические для конкретного объекта данные в долгосрочный конкурентный актив. Кроме того, ожидается, что к концу года доля производственных компаний, использующих десять и более решений на базе агентного ИИ, удвоится.</p> <p>Исследования IDC показывают, что сегодня речь скорее идет не о создании безлюдных производств, а о трансформации производственной среды: работники переходят от выполнения ручных операций к функциям контроля, управления исключительными ситуациями и общего надзора.</p> <p>Самые важные решения в области автоматизации, которые предстоит принять производственным компаниям в ближайшие годы, касаются не выбора конкретного манипулятора, а того, какой системе управления довериться, на чьей платформе для моделирования строить процессы и кому будут принадлежать данные, генерируемые роботами. Именно в этом заключается фундаментальный сдвиг: выбор самого манипулятора — задача не самая сложная. Настоящая сложность кроется в создании инфраструктуры, которая его окружает.</p> Представление о физическом искусственном интеллекте (Physical AI) уже давно вышло за рамки привычного образа … article https://www.itweek.ru/themes/detail.php?ID=235828 Tue, 27 Oct 2026 17:14:17 +0300 <p>Компания Postgres Professional выпустила техническое обновление флагманской СУБД Postgres Pro Enterprise 18.6.2. Выпуск носит корректирующий характер и закрепляет крупный пакет технологических улучшений ветки 18.6.1: оптимизацию ядра для высоконагруженных систем, интеграцию с базами MySQL через mysql_fdw, развитие кластера BiHA и аппаратное ускорение AVX2.</p> <p>Релиз базируется на PostgreSQL 18.6 и Postgres Pro Enterprise 18.6.1, объединяет свежие наработки апстрима и собственные инженерные решения команды Postgres Professional. А также включает критические исправления надежности, обеспечивая стабильную работу СУБД в контурах с повышенными требованиями к отказоустойчивости.</p> <p>Ключевым фокусом релиза стало повышение производительности при интенсивной работе с временными объектами, характерной для корпоративных систем и учетных решений 1С. В СУБД реализован механизм «ленивого» создания файлов: дисковые файлы и индексы для временных таблиц формируются только при реальном сбросе данных из буфера на диск, что устраняет избыточные операции ввода-вывода.</p> <p>Нагрузка на системный каталог и конкуренция за блокировки в разделяемой памяти существенно снижены. Векторные инструкции современных процессоров AVX2 задействованы для ускорения контрольных сумм и последовательного сканирования таблиц. Кроме того:</p> <ul> <li>режим append_optimized = aggressive и пакетное расширение индексов B-дерева (enable_btree_bulk_extension) ускоряют массовые вставки;</li> <li>оптимизированы трансформации предикатов и расчет селективности для сложных подзапросов с DISTINCT и GROUP BY;</li> <li>в архитектуре мультимастера производительность при работе с профилем временных объектов увеличена на <nobr>70–80%.</nobr></li> </ul> <p>В дистрибутив включена официальная обертка сторонних данных mysql_fdw, открывающая прямой доступ к СУБД MySQL непосредственно из окружения Postgres Pro. Расширение поддерживает передачу на сторону источника (pushdown) фильтров WHERE, соединений JOIN, сортировки, группировки и агрегатных функций, а также запись данных и выполнение подготовленных операторов.</p> <p>Инструменты анализа производительности пополнились экспериментальным расширением pgpro_stats_2. Модуль объединяет возможности pg_stat_statements и pg_wait_sampling: он обеспечивает сохранение планов запросов и сбор статистики по событиям ожидания при минимальном влиянии на продуктивную среду (пока не рекомендуется для промышленной эксплуатации).</p> <p>Отказоустойчивый комплекс BiHA получил обновленную архитектуру управления и повышенную гибкость топологии:</p> <ul> <li>конфигурация кластера вынесена в структурированные файлы JSON с администрированием через специализированные функции;</li> <li>в утилите bihactl реализованы прямое переключение лидера (set leader) с контролем таймаута синхронизации, запуск кастомных скриптов мониторинга и интеграция с резервным копированием через pg_probackup3;</li> <li>добавлена возможность физического разделения сетевого канала репликации и управляющего трафика (BCP) по разным интерфейсам;</li> <li>параметр deny_wal_sources позволяет явно исключать определенные узлы из источников репликации, что упрощает маршрутизацию трафика при сложных сетевых ограничениях.</li> </ul> <p>Параллельная автоочистка (parallel_autovacuum_workers) переведена в разряд стабильных инструментов: лимит воркеров теперь настраивается динамически без перезапуска инстанса. Обновлены ключевые сопутствующие модули, включая pg_probackup 2.8.15 Enterprise, pgpro_pwr 4.15, модуль аудита pg_proaudit 2.1 и pgvector 0.8.7.</p> <p>Разработчики рекомендуют пользователям запланировать переход на актуальную версию: в ней закрыта ошибка фоновой заморозки (background freezer), способная приводить к аварийным сбоям уровня PANIC после выполнения TRUNCATE или VACUUM FULL. Документация и дистрибутивы доступны на официальном портале компании.</p> <p>«Современные ИТ-ландшафты редко бывают однородными: бизнес развивает комплексные архитектуры, где требуется быстрая связь между разными СУБД и бесперебойная репликация между узлами. Выпуск версии 18.6.2 решает две задачи: обеспечивает прямой, производительный доступ к внешним базам MySQL и дает гибкие инструменты изоляции сетевых маршрутов в BiHA. В сочетании с аппаратным ускорением и доработками ядра это делает систему существенно устойчивее в условиях смешанных транзакционно-аналитических нагрузок», — отметил Евгений Кривов, руководитель продукта Postgres Pro Enterprise. </p> Компания Postgres Professional выпустила техническое обновление флагманской СУБД Postgres Pro Enterprise 18.6.2. Выпуск … message https://www.itweek.ru/themes/detail.php?ID=235827 Tue, 27 Oct 2026 17:11:28 +0300 <p>Angara MTDR запустила услугу, которая позволяет компаниям быстрее и с меньшими затратами расследовать инциденты, связанные с действиями сотрудников и других внутренних пользователей корпоративных систем. Помимо установления обстоятельств инцидента и причастных к нему лиц, услуга включает юридическую оценку их действий и рекомендации по предотвращению подобных нарушений.</p> <p>Внутренние инциденты (хищение данных, саботаж, мошенничество или скрытую работу на конкурентов) сложно выявить вовремя. При этом ущерб от них может накапливаться годами, поскольку компании нередко связывают потери с техническими сбоями. </p> <p>Когда нарушение все же обнаружено, служба безопасности сталкивается с двумя проблемами. Первая связана со сроками — расследовать инциденты необходимо быстро, поскольку цифровые следы со временем стираются и восстановить полную картину становится сложнее. Вторая проблема касается доказательной базы. Стандартных журналов событий и отчетов DLP-систем во многих случаях недостаточно, чтобы подтвердить позицию компании в суде или при обращении в правоохранительные органы. Эти данные фиксируют отдельные действия в системах, однако для использования в качестве доказательств их необходимо собрать с сохранением целостности, сопоставить между собой и дополнить юридической оценкой.</p> <p>Новая услуга рассчитана на ситуации, когда компания подозревает утечку данных, выявила несанкционированное копирование конфиденциальной информации или обнаружила признаки мошенничества и злоупотребления полномочиями.</p> <p>Специалисты Angara MTDR находят и фиксируют цифровые следы без нарушения целостности данных, анализируют действия пользователей и восстанавливают поминутную хронологию событий в системе. Параллельно они изучают внутренние документы компании, например, регламенты работы с информацией и письменные объяснения вовлеченных лиц, и сопоставляют их с техническими данными из журналов систем, корпоративной почты, сетевого трафика и копий дисков.</p> <p>На следующем этапе эксперты оценивают действия нарушителя с точки зрения дисциплинарной, административной и уголовной ответственности. По итогам расследования компания получает пакет материалов для служебной проверки или передачи в правоохранительные органы, а также рекомендации по устранению причин инцидента.</p> <p>«Найти следы в системах означает решить только половину задачи. Чтобы материалы имели вес в споре, эти следы нужно связать с обязанностями конкретного человека, внутренними правилами компании и нормами права. Если технические и юридические выводы готовят разные люди в разное время, они нередко расходятся между собой. Поэтому в нашей услуге криминалисты и юристы работают над одним делом одновременно. Для бизнеса важен и фактор времени. По нашей оценке, расследование с привлечением Angara MTDR занимает <nobr>3–6 недель,</nobr> тогда как внутренним службам на него требуется <nobr>3–6 месяцев,</nobr> а общая стоимость за счет более коротких сроков оказывается на <nobr>50–70%</nobr> ниже», — добавил Артем Грибков, директор Центра киберустойчивости Angara MTDR.</p> Angara MTDR запустила услугу, которая позволяет компаниям быстрее и с меньшими затратами расследовать инциденты … message https://www.itweek.ru/themes/detail.php?ID=235826 Tue, 27 Oct 2026 17:10:53 +0300 <p>MWS AI (входит в МТС Web Services) запустила MWS AI Cowork — универсального ИИ-агента с чат-интерфейсом. Он самостоятельно планирует и выполняет задачи в режиме одного окна: ищет и анализирует информацию, работает с файлами, сайтами и подключёнными приложениями, создаёт документы, таблицы, презентации и отчёты. В отличие от Claude Cowork и ChatGPT Work, MWS AI Cowork учитывает требования российских компаний к безопасности корпоративных данных и гибкости ИИ-инфраструктуры: его можно развернуть в закрытом контуре организации в России и использовать с различными ИИ-моделями, включая Cotype от MWS AI, модели Сбера, Яндекса и открытые зарубежные разработки. По прогнозу MWS AI, сотрудники смогут выполнять с помощью ИИ-агента до 90% повторяющихся офисных задач по работе с информацией.</p> <p>Пользоваться решением можно через привычный чат-интерфейс, авторизовавшись с помощью корпоративной учётной записи. Для начала работы систему достаточно один раз настроить для всей компании, подключив к почте, календарю, мессенджерам, хранилищам, системам документооборота, CRM и другим корпоративным приложениям. При выполнении задач ИИ-агент действует от имени пользователей в пределах их прав доступа.</p> <p>Пользователи MWS AI Cowork могут создавать собственные навыки — инструкции, по которым ИИ-агент выполняет типовые задачи. Сохранёнными навыками можно делиться с коллегами, чтобы вся команда могла использовать удачные решения и работать по единым стандартам. Например, для подготовки ежемесячного отчёта можно заранее указать источники данных, правила проверки информации и формат документа. После этого по запросу «Подготовь отчёт за октябрь» MWS AI Cowork соберёт необходимые данные и сформирует его по сохранённой инструкции. ИИ-агент также запоминает предпочтения пользователя и контекст задач, чтобы их не приходилось повторять при каждом обращении. Сохранённые сведения можно просматривать, исправлять и удалять.</p> <p>В MWS AI Cowork есть готовые навыки, которые можно использовать сразу или настроить под свои требования, например: подготовить отчёт (собрать данные из файлов и рассчитать показатели), сравнить предложения поставщиков (свести цены, сроки и условия в таблицу), проверить документы (найти расхождения между версиями, пропуски и несоответствия требованиям, создать презентацию на основе корпоративного стиля и данных, составить протокол по расшифровке встречи (зафиксировать решения, задачи, ответственных и сроки).</p> <p>«MWS AI Cowork даёт компании общую основу для внедрения ИИ в работу разных подразделений. Можно начать с отдельных задач — например, подготовки отчётов или сравнения предложений поставщиков, — а затем подключать новые отделы и переходить к процессам, в которых участвуют несколько команд. При этом компания использует уже подключённые системы и накопленные навыки: то, что помогло одному отделу, могут применять другие. Руководство сохраняет контроль над расходами, доступом к данным и используемыми инструментами. Так бизнес может постепенно развивать автоматизацию в одной среде по мере роста своих потребностей», — отметил генеральный директор MWS AI Денис Филиппов.</p> <p>По результатам пилотных проектов в различных бизнес-подразделениях МТС Web Services, активный пользователь искусственного интеллекта, который использует ИИ-агента в 90% задач, экономит, как минимум, час рабочего времени в день. Это эквивалентно примерно 263 тыс. рублей в год на сотрудника. Экономия достигается за счёт ускорения рутинных операций: поиск информации во внутренних документах и базах знаний позволяет сэкономить около 25 минут в день, подготовка писем и текстов — около 15 минут, подведение итогов встреч и переписок, а также создание шаблонных документов и презентаций — ещё примерно по 10 минут. Расчёт основан на полной стоимости сотрудника для работодателя — около 175 тыс. рублей в месяц, включая оклад порядка 134 тыс. рублей и страховые взносы. При 247 рабочих днях в году это около 1 060 рублей за рабочий час. Годовая лицензия для такого контура в 2026 году стоит от 6 до 20 млн рублей в зависимости от комплектации и числа пользователей. Таким образом, инвестиции заказчика в продукт могут окупиться уже в первые месяцы после запуска в промышленную эксплуатацию.</p> <p>В ходе тестирования отдельных рабочих сценариев в компании с 1000 сотрудников использование ИИ-агента позволило сократить среднее время подготовки презентации на 10 слайдов по готовым материалам на <nobr>40–50%,</nobr> делового текста объёмом одну страницу A4 — на <nobr>40–60%,</nobr> квартального финансового отчёта по собранным и проверенным данным — на <nobr>30–50%.</nobr> Первичная проверка стандартного договора и подготовка замечаний занимали в среднем на 30% меньше времени, а подготовка протокола встречи по расшифровке с указанием решений, задач и ответственных — на <nobr>50–80%.</nobr> Оценка учитывает время на проверку и доработку результата сотрудником. Для договоров измерялось время первичной проверки и подготовки замечаний, а не полный срок согласования между сторонами.</p> MWS AI (входит в МТС Web Services) запустила MWS AI Cowork — универсального ИИ-агента с чат-интерфейсом … message https://www.itweek.ru/themes/detail.php?ID=235825 Tue, 27 Oct 2026 17:09:35 +0300 <p>Технологическая компания YADRO (входит в ИКС Холдинг) предлагает подход к построению катастрофоустойчивой инфраструктуры хранения данных на базе объектной системы TATLIN.OBJECT. Благодаря децентрализованной архитектуре решение позволяет объединять от трех до более чем ста географически распределенных дата-центров в единую систему без жесткого разделения на основную и резервные площадки. Механизмы распределенного хранения TATLIN.OBJECT обеспечивают независимую работу площадок и доступность данных при различных инфраструктурных сбоях, в том числе при выходе из строя отдельных дата-центров.</p> <p>Географическое резервирование позволяет снизить риски потери доступности данных, однако запас отказоустойчивости во многом зависит от количества независимых площадок и организации взаимодействия между ними. В традиционных двухплощадочных конфигурациях, использующих схемы Active-Active и Active-Async, при выходе из строя одного дата-центра система может продолжить работу на оставшемся, но фактически лишается географической избыточности. Единственная сохранившаяся площадка становится критической точкой отказа, а последующий серьезный сбой может привести к полной недоступности данных.</p> <p>Устойчивость такой инфраструктуры зависит не только от состояния самих площадок, но и от механизмов репликации — создания и поддержания копий данных на резервной инфраструктуре. Например, при асинхронной репликации возникает риск потери последних изменений, еще не переданных на другую площадку. Нарушение связи между дата-центрами также может потребовать определения площадки, которая продолжит обслуживать запросы, чтобы избежать расхождения данных.</p> <p>Децентрализованная архитектура YADRO TATLIN.OBJECT позволяет объединять в единую систему хранения две и более независимые площадки. При этом использование трех и более дата-центров обеспечивает сохранение географической избыточности даже при выходе из строя одного из них. В отличие от схем с жестким разделением инфраструктуры на основную и резервную, TATLIN.OBJECT позволяет распределять нагрузку и копии данных между несколькими дата-центрами. Благодаря этому при выходе из строя отдельного дата-центра оставшиеся узлы могут продолжать работу с данными и принимать новые в соответствии с заданными условиями хранения.</p> <p>Для согласования единой конфигурации распределенной системы хранения TATLIN.OBJECT использует технологию блокчейн, позволяющую синхронизировать изменения настроек между географически распределенными площадками без централизованной базы данных. Даже если часть узлов теряет возможность участвовать в согласовании изменений, они продолжают обрабатывать запросы к данным, хотя создание новых структур хранения и редактирование конфигурации системы могут быть временно ограничены.</p> <p>Размещение данных регулируется политиками хранения на уровне бакетов — логических контейнеров для объектов. Эти политики определяют количество копий данных, площадки их размещения, способ репликации (синхронный, асинхронный или адаптивный) и условия подтверждения записи. При выходе из строя отдельных площадок система обновляет информацию о доступных узлах и восполняет недостающие копии данных в соответствии с заданными правилами размещения.</p> <p>Отдельный сценарий — нарушение связи между работающими дата-центрами. В традиционных распределенных системах такая ситуация может привести к split-brain — состоянию, при котором изолированные части инфраструктуры продолжают работать независимо, а изменения данных расходятся между ними. Архитектура TATLIN.OBJECT позволяет сохранять доступность данных и управлять их согласованностью при подобных сбоях. Каждый узел способен самостоятельно обслуживать запросы к хранящимся на нем объектам. Даже если площадки оказываются изолированы друг от друга, они могут продолжать чтение доступных данных и при соответствующих настройках принимать новые. После восстановления связи данные, записанные в период изоляции, синхронизируются между площадками в соответствии с заданными политиками хранения.</p> <p>«Для бизнеса критически важна не только сохранность данных, но и возможность продолжать работу с ними при инфраструктурных сбоях. Традиционные подходы к резервированию позволяют снизить риски, однако устойчивость системы во многом определяется тем, насколько она зависит от отдельных площадок. В TATLIN.OBJECT мы реализовали архитектуру, в которой катастрофоустойчивость обеспечивается распределенной работой независимых узлов хранения. Это позволяет организациям снижать зависимость от конкретных дата-центров и сохранять доступность данных даже при серьезных нарушениях в работе инфраструктуры», — отметил Егор Литвинов, директор продуктового направления СХД TATLIN.</p> <p>На протяжении трех лет заказчики успешно используют TATLIN.OBJECT в конфигурациях с географическим распределением узлов. Система в этом исполнении также поддерживает работу ряда внутренних сервисов YADRO. Основная цель таких решений — обеспечить доступность данных и непрерывность бизнеса при аварии или потере одной или нескольких площадок. Кроме того, компании используют этот подход для размещения данных ближе к конечным пользователям — в том числе при организации сетей доставки контента (Content Delivery Network, CDN). Гибко настраиваемая система политик репликации поддерживает синхронные, асинхронные и гибридные сценарии. Это позволяет комбинировать узлы как внутри одного города — для минимизации задержек; так и в разных регионах — для катастрофоустойчивости и непрерывности бизнеса.</p> <p>На фоне растущего спроса на географически распределенную ИТ-инфраструктуру, способную поддерживать непрерывность бизнес-процессов, TATLIN.OBJECT предлагает организациям решение для построения масштабируемых систем хранения данных, которые продолжают работать даже при сбоях отдельных площадок. Узнать подробнее о возможностях TATLIN.OBJECT и получить консультацию по продукту можно на сайте YADRO.</p> Технологическая компания YADRO (входит в ИКС Холдинг) предлагает подход к построению катастрофоустойчивой … message https://www.itweek.ru/themes/detail.php?ID=235824 Tue, 27 Oct 2026 16:43:24 +0300 <p>Компания «СёрчИнформ» представила результаты исследования уровня информационной безопасности в московских организациях за 2026 год. В опросе приняли участие 120 специалистов по ИБ из государственных и коммерческих компаний различного масштаба.</p> <p>В 2026 году компании чаще сталкивались с ИБ-нарушениями: о внутренних инцидентах сообщили 72% ИБ-специалистов против 59% в 2025 году. Среди инцидентов: утечки данных (53%), внешняя атака через сотрудников (24%), дискредитация компании (19%), фирмы-боковики/сторонняя занятость (18%), промышленный шпионаж/работа на конкурентов (16%), откаты (15%).</p> <p>Чаще всего в 2026 году компании сталкивались с попытками слива внутренних регламентов, планов и служебных переписок (55%), персональных данных (54%), информации о сделках, данных корпоративных клиентов и подрядчиков (48%). Об утечках финансовой и технической документации сообщили 30% и 27% респондентов.</p> <p>В 2026 году заметно выросла роль ИИ-сервисов как канала утечки. В 2025 году с передачей конфиденциальной информации через ИИ сталкивались лишь 6% московских компаний, в 2026 году — уже 40%. ИИ-сервисы вышли на третье место после мессенджеров (62%) и электронной почты (57%). Также у трети опрошенных утечки происходили через съемные носители и облачные сервисы.</p> <p>«В 2025 году ИИ-сервисы замыкали десятку популярных каналов. В этом году ИИ-сервисы уже третьи по популярности, то есть тенденция однозначна — ИИ закрепился как основной канал утечки. Проблема в том, что чаще сотрудники не понимают, какие данные критичны, и загружают их в нейросеть, чтобы быстрее выполнить задачу. Компании встают перед выбором: запретить сотрудникам использовать ИИ-инструменты и терять конкурентные преимущества или допустить использование ИИ и рисковать конфиденциальными данными. Но запрещать сотрудникам пользоваться нейросетями при этом не обязательно: достаточно определить, какие данные нельзя передавать в ИИ, и контролировать это техническими средствами», — прокомментировал заместитель генерального директора по инновационной деятельности «СёрчИнформ» Алексей Парфентьев.</p> <p>Чаще всего виновниками ИБ-инцидентов в московских компаниях становились рядовые сотрудники: с их нарушениями столкнулись 79% опрошенных организаций. Выросла и доля компаний, где нарушителями оказались руководители. Инциденты по вине линейных руководителей отметили 35% организаций против 30% в 2025 году, по вине руководителей направлений — 24% против 22%.</p> <p>Чаще всего ИБ-инциденты по вине сотрудников случались непреднамеренно: о нарушениях из-за халатности или под влиянием социальной инженерии сообщили 48% опрошенных. Ещё 34% ответили, что сотрудники нарушали правила умышленно, а 18% московских компаний одинаково часто сталкивались со случайными и намеренными инцидентами.</p> <p>Главная причина нарушений правил ИБ — желание сотрудников упростить себе работу (78%). Например, сотрудник может переслать рабочие файлы на личную почту, чтобы закончить задачу дома, или поделиться паролем с коллегой. На втором месте финансовая выгода (44%), на третьем — желание получить доступ к информации или ресурсам (41%).</p> <p>Большинство компаний, столкнувшихся с ИБ-инцидентами, ограничивались выговором, предупреждением или замечанием (68%). Санкции в виде увольнения применяли к нарушителям почти половина (53%) компаний, столкнувшихся с инцидентами ИБ. Доводили инцидент до суда лишь 14% опрошенных компаний. 14% работодателей никак не наказывали нарушителей.</p> <p>«Суды признают разглашением передачу конфиденциальных данных за пределы информационных систем компании. И в судебной практике множество случаев, когда законными признавались дисциплинарные взыскания за пересылку данных на личную почту или аккаунт сотрудника, чьи трудовые обязанности предполагали работу с этими сведениями. В 2026 году московский суд признал законным увольнение топ-менеджера, которая загрузила данные о клиентах в ИИ-сервис. В компании действовал режим коммерческой тайны. За такие нарушения компанию могут оштрафовать за утечку персональных данных и незаконную передачу данных за рубеж. Поэтому так называемый „теневой ИИ“ становится для организаций реальной угрозой. Чтобы минимизировать риск экономических потерь и штрафа, организациям необходимо урегулировать в локальных актах правила доступа к информации и ее обработки, в т.ч. с помощью ИИ, довести эти документы до сотрудников, контролировать операции пользователей с защищаемыми данными и объектами ИС», — прокомментировал специалист по связям с государственными органами «СёрчИнформ» Дмитрий Вощуков.</p> <p>Почти половина опрошенных (48%) сообщили, что ИБ-инциденты не повлекли для компании последствий. Однако у многих организаций нарушения закончились разбирательствами. Например, трудовые и гражданские споры с сотрудниками возникали у 32% компаний, проверки контролирующих органов — у 13%. Еще 13% опрошенных столкнулись с возбуждением уголовных дел, а 7% — с гражданскими спорами с контрагентами.</p> Компания «СёрчИнформ» представила результаты исследования уровня информационной безопасности в московских организациях … message https://www.itweek.ru/themes/detail.php?ID=235822 Tue, 27 Oct 2026 10:30:27 +0300 <p><em>Согласно отчету</em> <em>Perforce Delphix</em> <em>«The</em> <em>Synthetic</em> <em>Data</em> <em>Market</em> <em>Gap: Findings</em> <em>from</em> <em>Our</em> <em>2026 Survey»</em><em>, только 34% руководителей доверяют ссылочной целостности (referential integrity) синтетических данных. Маянк Ахлувалия, старший продакт-менеджер Perforce Delphix, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как высокое качество данных способствует их применению в корпоративном тестировании ПО.</em></p> <p>Хотя руководители компаний в целом высоко оценивают потенциал синтетических данных, их внедрение идет медленно. В результате этот огромный потенциал остается нереализованным. Что же делать? Компаниям нужен правильный, основанный на качестве подход, который обеспечивает ссылочную целостность и вызывает доверие.</p> <p>Исследование Perforce Delphix показывает, что главным препятствием для внедрения синтетических данных является не недостаток осведомленности, вопросы соответствия нормативным требованиям или управление данными, а именно их качество. Руководители в различных отраслях все чаще осознают ценность синтетических данных: они помогают защитить конфиденциальную информацию, ускорить работу автономных агентов и расширить доступ к данным без увеличения рисков.</p> <p>Однако, согласно нашему исследованию, лишь 38% руководителей считают, что синтетические данные достаточно реалистичны, и только 34% уверены в том, что в них сохраняется ссылочная целостность.</p> <p>Вероятно, именно по этой причине использование синтетических данных в командах разработки и тестирования ПО остается на удивление ограниченным. В итоге компании упускают возможности, которые могут предоставить по-настоящему качественные синтетические данные. Первый шаг к использованию этих возможностей — убедиться, что синтетические данные соответствуют вашим стандартам качества.</p> <h3>Перспективы синтетических данных</h3> <p>Синтетические данные привлекают к себе пристальное внимание, и не без оснований. Долгие годы организации пытались найти баланс между двумя противоречивыми задачами: предоставлением командам необходимых данных и защитой конфиденциальной информации.</p> <p>Традиционные подходы часто вынуждают выбирать между доступом к данным и рисками. Либо доступ ограничивается, что создает узкие места в процессах разработки и тестирования, либо данные распространяются слишком широко, что повышает риски, связанные с безопасностью и соблюдением нормативных требований.</p> <p>Создавая новые наборы синтетических данных, которые отражают характеристики реальных рабочих данных, но лишены рисков, связанных с конфиденциальностью, организации могут повысить доступность тестовых данных, сохраняя при этом контроль и соответствие нормативным требованиям. Более половины компаний (51%) уже используют синтетические данные для защиты конфиденциальной информации — наряду с такими методами, как статическое или динамическое маскирование. Это весьма перспективный подход, особенно сейчас, когда развитие ИИ-агентов повышает потребность бизнеса в качественных и легкодоступных данных.</p> <p>Разумеется, хотя создавать синтетические данные довольно просто, далеко не все они одинаково хороши. Многие организации уже пробовали использовать синтетические данные, но не добились улучшений в разработке и тестировании приложений — зачастую потому, что таким данным не хватало реалистичности или в них не были сохранены взаимосвязи между элементами.</p> <p>Вопрос внедрения синтетических данных сводится к доверию: могут ли современные решения в этой области обеспечить необходимый уровень реалистичности, с которым раньше возникали сложности? Современный подход, основанный на использовании искусственного интеллекта (AI-first) и ставящий во главу угла качество данных при их масштабном создании, позволяет снять старые опасения.</p> <h3>Разработчикам нужно нечто большее, чем просто защищенные данные</h3> <p>Если руководство компаний часто оценивает синтетические данные с точки зрения управления и безопасности, то команды разработчиков смотрят на них через призму качества. На сегодняшний день 66% руководителей в сфере разработки ПО не используют синтетические данные в процессах создания и тестирования продуктов.</p> <p>Для разработчиков и тестировщиков главный вопрос — не в том, защищены ли данные, а в том, насколько они полезны. Их интересует следующее:</p> <ul> <li> Могут ли данные точно отражать поведение клиентов?</li> <li> Подходят ли они для реализации сложных сценариев тестирования?</li> <li> Сохраняются ли в них взаимосвязи между различными системами?</li> <li> Дают ли они уверенность в том, что приложения, протестированные сегодня, будут корректно работать в реальной рабочей среде завтра?</li> </ul> <p>Эти вопросы критически важны. Командам, которые тестируют приложения, бизнес-процессы, рабочие потоки, интеграции и пользовательский опыт, нужны не просто «правдоподобные» данные. Им необходимы данные, в которых сохранены контекст, взаимосвязи и реалистичность — всё то, что делает информацию осмысленной.</p> <p>Приведем пример: если в поле «кредитный рейтинг» вставить случайное число, что технически может быть допустимо, такие данные не будут соответствовать реальности. Создавая данные в рамках реальных диапазонов и ограничений, вы обеспечиваете их достоверность и высокое качество.</p> <p>Если данным не хватает реалистичности или они не отражают реальное поведение системы, возникает риск: приложения будут проверяться на сценариях, которые в действительности никогда не встречаются в рабочей среде. Итогом могут стать программные дефекты, неудачные релизы и недостоверные результаты тестирования.</p> <h3>Как выглядят достоверные синтетические данные</h3> <p>Чтобы синтетические данные могли поддерживать масштабное развитие предприятия, они должны вести себя так же, как и системы, которые они представляют. Не каждый инструмент синтетических данных может это сделать, но вы можете настроить правила генерации для обеспечения ссылочной целостности в различных средах данных.</p> <p>Корпоративные приложения редко работают в одной базе данных. Информация о клиентах может находиться в одной системе, заказы — в другой, а информация о платежах — в третьей. Тестирование работает только тогда, когда эти отношения остаются неизменными в разных средах. Иначе команды не тестируют реальные бизнес-процессы. Они тестируют отключенные компоненты изолированно.</p> <p>Поэтому организациям, оценивающим инструменты синтетических данных, следует рассматривать некоторые возможности как не подлежащие обсуждению:</p> <ul> <li> Сохранение связей между базами данных и системами, а не только внутри одной схемы. Корпоративные приложения зависят от межсистемных зависимостей, и синтетические данные должны их отражать. Например, две диаграммы, такие как «Инвестор» и «Инвестиционный счет», всегда должны быть связаны.</li> <li> Генерация данных в порядке зависимости, чтобы отношения родитель-потомок оставались неизменными во всей среде.</li> <li> Проверка реалистичности и бизнес-логики, чтобы гарантировать, что сгенерированные данные соответствуют ожидаемым форматам, диапазонам, распределениям и правилам. Набор тестовых данных никогда не должен создавать невозможные сценарии, такие как неверные идентификаторы или бессмысленные бизнес-результаты.</li> <li> Постоянная оценка качества данных по мере развития схем. Если синтетические данные требуют обширной ручной реконфигурации каждый раз при изменении исходной системы, качество и доверие со временем неизбежно ухудшаются.</li> </ul> <p>Если установить эти флажки, синтетические данные могут оставаться полезными для разработки, одновременно снижая риск конфиденциальности данных.</p> <h3>Почему ИИ делает эту проблему еще более актуальной</h3> <p>Рост развития разработки с помощью ИИ обнажает давнюю проблему, которую сейчас невозможно игнорировать: выпуск ПО может развиваться только так же быстро, как и поддерживающие его данные.</p> <p>Хотя генерация кода значительно ускорилась, доступ к высококачественным тестовым данным отстает. Синтетические данные могут помочь преодолеть этот разрыв. В отличие от производственных данных, синтетические данные могут генерироваться по требованию.</p> <p>Эта возможность особенно ценна, когда командам нужны специально созданные данные для новых приложений, функций, крайних случаев и инициатив на основе ИИ, где производственные данные могут отсутствовать или их сложно использовать. Синтетические данные позволяют командам создавать реалистичные сценарии тестирования по требованию и выполнять проверку на более ранних этапах жизненного цикла разработки.</p> <p>В то же время синтетические данные не обязательно заменяют другие подходы к тестированию. Все чаще организации находят ценность в сочетании двух подходов: использовании маскированных данных для известных рабочих процессов и использовании синтетических данных для расширения охвата и тестирования совершенно новых сценариев. Вместе они обеспечивают реализм и гибкость.</p> <p>Общей нитью является доверие. Независимо от того, тестируют ли команды новые функции, проверяют интеграции или поддерживают разработку с помощью ИИ, уверенность зависит от того, насколько точно данные отражают взаимосвязи и контекст реальных систем. Ссылочная целостность больше не является технической необходимостью. Она становится предпосылкой для значимого внедрения синтетических данных.</p> <h3>Будущее синтетических данных зависит от доверия к ним</h3> <p>Следующий этап внедрения синтетических данных будет зависеть от того, доверяют ли инженерные команды этим данным в достаточной степени, чтобы создавать, тестировать и внедрять инновации с их помощью.</p> <p>По мере того, как скорость выпуска ПО все больше определяется скоростью работы агентов, надежные данные становятся конкурентным преимуществом. Организациям нужны данные, которые можно генерировать быстро, но они также должны точно отражать реальные отношения, бизнес-процессы и поведение системы.</p> <p>Компании, которые устранят этот разрыв, не будут просто генерировать больше синтетических данных. Они будут генерировать реалистичные, ссылочно точные и соответствующие назначению данные, которые разработчики смогут с уверенностью использовать для ускорения выпуска своих релизов и которые помогут им идти в ногу с ИИ.</p> <p>В конечном счете, внедрение синтетических данных не является проблемой осведомленности. Это проблема доверия, а доверие зависит от качества данных.</p> Согласно отчету Perforce Delphix «The Synthetic Data Market Gap: Findings from Our 2026 Survey», только 34% … article https://www.itweek.ru/themes/detail.php?ID=235820 Mon, 26 Oct 2026 15:25:12 +0300 <p>Компания HYPERPC проанализировала опыт российских компаний, связанный с интеграцией высокопроизводительных серверов в корпоративную ИТ-инфраструктуру и выявила четыре основные ошибки, совершаемые организациями. По мнению экспертов HYPERPC, в ТОП-4 наиболее распространенных ошибок входят: дисбаланс дисковой подсистемы и вычислителей, избыточная плотность ядер процессора при низкой частоте, недокомплект каналов памяти и ошибки при проектировании VRAM-памяти.</p> <p>Ошибка, связанная с дисбалансом дисковой подсистемы и вычислителей, встречается довольно часто. При развертывании серверов под задачи машинного обучения и работы больших языковых моделей упор делается на массив дорогостоящих графических ускорителей. При этом, дисковую подсистему часто проектируют по остаточному принципу, комплектуя сервер стандартными накопителями устаревшего интерфейса SATA или накопителями потребительского класса. Такие действия приводят к негативным последствиям. </p> <p>Вычислительная мощность современных графических чипов позволяет обрабатывать блоки данных за миллисекунды. Если дисковой массив не способен обеспечить адекватный уровень количества операций ввода-вывода, на операциях случайного чтения мелких блоков, графические процессоры уходят в глубокий простой ожидания данных.В реальных сценариях обучения моделей из-за медленного чтения дорогие ускорители простаивают до 70% времени. Инфраструктура стоимостью в десятки миллионов рублей фактически работает с эффективностью бюджетной рабочей станции. </p> <p>Еще одна распространенная ошибка — «ядерная ловушка», которая характеризуется избыточной плотностью ядер при низкой частоте. Механический перенос потребительского опыта на серверный класс приводит к ложному выводу: «чем больше ядер на процессорном разъеме, тем выше общая производительность». Компании приобретают процессоры максимальной емкости (64, 96 или 128 ядер) с низкой базовой тактовой частотой в диапазоне <nobr>2.0-2.4 ГГц.</nobr></p> <p>Технические последствия «ядерной ловушки» могут проявляться, в первую очередь, в реляционных базах данных и учетных системах. Данные архитектуры критически завязаны на производительность одного конкретного потока. Бизнес-логика выполнения транзакций не масштабируется параллельно по слабочастотным ядрам. В результате тяжелые базы данных работают медленнее, чем на старых платформах. Более того, коммерческое программное обеспечение лицензируется по количеству ядер. Компания не только получает деградацию производительности, но и сталкивается с кратными переплатами за лицензирование неиспользуемой мощности. </p> <p>Помимо этого, последствия могут коснуться инфраструктуры искусственного интеллекта. Непосредственные математические вычисления выполняет графический чип, однако задачи предварительной подготовки, разбиения текста на элементы и изменения объема данных лежат на центральном процессоре. Низкочастотные ядра центрального процессора не успевают формировать и передавать потоки данных через системную шину. Для сбалансированной работы платформ искусственного интеллекта целесообразно использовать процессоры с умеренным количеством ядер <nobr>(16-32 на</nobr> разъем), но с высокой базовой частотой (от 3,5 ГГц).</p> <p>Третья ошибка — недокомплект каналов памяти, вызывающая ограничение пропускной способности шины процессора — также совершается многими организациями. Приобретая современные процессоры с 8- или <nobr>12-канальными</nobr> контроллерами памяти, системные интеграторы или сами компании заполняют лишь 2 или 4 слота модулями большого объема. Мотивацией обычно служит экономия бюджета на этапе закупки или создание абстрактного задела под модернизацию в будущем. </p> <p>В результате подобных действий процессор физически лишается возможности использовать проектную ширину шины обмена данными. При работе в двух- или четырехканальном режиме вместо штатного многоканального режима реальная пропускная способность оперативной памяти падает в <nobr>3-6 раз.</nobr> Флагманский вычислительный узел искусственно переводится на скорость работы офисного компьютера, сводя на нет инвестиции в дорогой процессор. </p> <p>Особое внимание при проектировании ИИ-серверов следует уделять расчету объема видеопамяти (VRAM) ускорителей. Распространенной ошибкой становится установка GPU «впритык» под базовый вес выбираемой модели. В реальных сценариях модель не находится в памяти изолированно: при инференсе, генерации текста и обработке контекста критическую часть объема VRAM занимает KV-кэш, хранящий состояния предыдущих токенов. При работе с большими контекстными окнами или при высоком параллелизме запросов KV-кэш может разрастаться и легко забирать на себя от 20% до 30%+ от общего объема видеопамяти. Игнорирование этого фактора приводит к ошибкам нехватки памяти и переносу вычислений в медленную системную ОЗУ. Чтобы избежать катастрофического падения производительности, к физическому размеру модели необходимо всегда закладывать минимум 30% запаса VRAM на динамические нужды кэширования.</p> <p>Эксперты HYPERPC выяснили, что <nobr>65-70%</nobr> компаний сталкиваются с ограничением дискового ввода-вывода и простоем вычислителей при первом развертывании локальных систем искусственного интеллекта. <nobr>50-55%</nobr> организаций допускают ошибки при расчете ядер под транзакционные нагрузки баз данных, что приводит к необоснованным затратам на программное обеспечение. <nobr>40-45%</nobr> серверов вводятся в эксплуатацию с незаполненной архитектурной канальностью оперативной памяти. </p> <p>С целью предотвращения подобных ошибок при внедрении высокопроизводительных серверов, эксперты HYPERPC рекомендуют компаниям обеспечить баланс дискового тракта, провести профилирование процессоров под конкретный тип нагрузки, а также соблюдать правила канальности оперативной памяти.</p> Компания HYPERPC проанализировала опыт российских компаний, связанный с интеграцией высокопроизводительных серверов … message https://www.itweek.ru/themes/detail.php?ID=235819 Mon, 26 Oct 2026 15:24:28 +0300 <p>АНО «Национальный центр компетенций по информационным системам управления холдингом» разработала два прикладных ИИ-сервиса — сервис автоматизированного формирования документации и сервис построения концептуальной модели данных функционального блока ERP. Они решают трудоемкие задачи, ранее выполнявшиеся аналитиками вручную.</p> <p>АНО «НЦК ИСУ» завершила создание двух сервисов для автоматизации работ с ERP-системами: подготовки эксплуатационной документации и построения концептуальных моделей данных. По результатам тестирования и первых применений они позволили сократить подготовку документации с недель до часов, а разработку концептуальной модели — с <nobr>6–8</nobr> недель до примерно одной недели. Результаты проходят автоматические проверки и контроль специалистов.</p> <p>Оба сервиса развернуты на сервере заказчика и доступны через веб-интерфейс. Пользователь загружает исходные материалы, запускает обработку и получает готовый результат. Решения представляют собой законченные прикладные сервисы, а не библиотеки или универсальные инструменты разработки.</p> <p>Сервис формирования документации создает три документа: пользовательскую инструкцию, справочник объектов системы и перечень вопросов к владельцам процессов. Второй сервис формирует концептуальную модель данных выбранного функционального блока ERP и итоговый документ с результатами анализа.</p> <p>Сервисы призваны сократить трудоемкость двух задач, требующих значительного участия аналитиков. Первая — поддержание документации в актуальном состоянии. Ручное описание крупной конфигурации занимает недели, в течение которых система может измениться. Автоматизация сокращает интервал между анализом конфигурации и выпуском документов.</p> <p>Вторая — подготовка концептуальных моделей данных. При такой работе аналитики изучают документацию ERP-систем, сопоставляют терминологию поставщиков и связывают объекты систем с процессами заказчика. В используемом массиве исходных материалов насчитывается около 114 тысяч фрагментов. Работа с таким объемом требует не только поиска и сопоставления информации, но и подтверждения выводов ссылками на первоисточники.</p> <p>В основе сервисов лежит комбинированная архитектура: основная логика реализована программным кодом на Python, а языковые модели используются на отдельных этапах анализа и подготовки текста. Собственные языковые модели в рамках разработки не создаются.</p> <p>Сервис формирования документации работает в закрытом контуре заказчика. Из 15 этапов обработки 11 выполняются без обращения к языковой модели; для генерации текста используется локальная модель. Сервис построения концептуальной модели включает серверную часть, веб-интерфейс, файловое хранилище и очередь заданий. Поиск по исходным материалам реализован с помощью алгоритма BM25, без использования векторной базы данных.</p> <p>Основной сценарий работы сервисов — не ответы на отдельные вопросы, а выполнение последовательности операций с выпуском законченного результата: комплекта документации или структурированной модели данных. Участие языковых моделей ограничено заданными задачами, а решения специалистов учитываются в предусмотренных контрольных точках.</p> <p>Ключевой принцип обоих решений — это прослеживаемость: возможность установить, на каких исходных данных основан результат, и проверить его до включения в итоговые материалы.</p> <p>В сервисе формирования документации языковая модель получает карточку подтвержденных фактов. Использованные в тексте наименования сверяются с данными этой карточки. Перед сборкой документов выполняются шесть автоматических проверок, в том числе проверка оформления по требованиям ГОСТ.</p> <p>В сервисе концептуального моделирования утверждения сопровождаются цитатами из исходных документов. Система проверяет дословное совпадение цитат с источниками; утверждения, не прошедшие предусмотренные проверки, не включаются в результат. Дополнительно предусмотрены четыре контрольные точки с участием специалиста. Его решения имеют приоритет и сохраняются при повторной обработке материалов.</p> <p>При обработке тестовой конфигурации сервис формирования документации проанализировал 43 тысячи файлов. Конфигурация включала 69 документов и 185 справочников. В ходе обработки было выполнено 730 обращений к языковой модели и сформирована пользовательская инструкция объемом 328 страниц. Подготовка заняла часы вместо недель ручной работы.</p> <p>Срок подготовки концептуальной модели сократился с <nobr>6–8</nobr> недель до примерно одной недели. При этом значительную часть времени по-прежнему занимают сбор исходной документации и проверка результатов специалистами. Следующий этап развития сервиса документации — установление связей между объектами конфигурации и бизнес-процессами, а также настройка оформления документов под требования заказчика.</p> <p>В направлении концептуального моделирования запланирована подготовка 23 моделей. Первая модель — для функционального блока «Казначейство» — уже передана на пилотное тестирование.</p> <p>«Созданные нами сервисы сокращают сроки подготовки документации с нескольких недель до нескольких часов, а концептуальных моделей — с <nobr>6–8</nobr> недель до примерно одной недели. При этом специалист сосредоточивается на содержательной проверке и принятии итоговых решений. В результате ERP-система перестает быть „черным ящиком“: ее документация и модель данных всегда актуальны, прослеживаемы и понятны бизнесу», — отметил генеральный директор АНО «НЦК ИСУ» Кирилл Семион.</p> АНО «Национальный центр компетенций по информационным системам управления холдингом» разработала два прикладных … message https://www.itweek.ru/themes/detail.php?ID=235818 Mon, 26 Oct 2026 15:23:39 +0300 <p>СберУниверситет представил на X конференции «Больше чем обучение» исследование «Будущее корпоративного образования. Горизонт 2031». Форсайт построен на более чем 50 000 страниц их трудов, лекций и интервью 38 цифровых двойников футурологов и учёных. Работу двойников организовала ИИ-система ГигаАгент (AIRI, Сбер): она искала сведения в источниках и сопоставляла рекомендации с документами компаний.</p> <p>Консилиум из 17 футурологов — среди них нобелевский лауреат Дарон Аджемоглу, Дэвид Аутор, Эрик Бриньольфссон, Рэймонд Курцвейл и Кевин Келли — определил наиболее значимые тренды до 2031 года: три технологии и семь социальных трендов. 21 учёный — Даниэль Канеман, Питер Друкер, Лев Выготский, Альберт Бандура, Генрих Альтшуллер и другие — оценил, как эти тренды изменят 50 универсальных задач интеллектуального труда и 10 способностей, и предложил модель сочетания 29 форматов обучения. Рекомендации проверили на материалах 20 крупнейших российских компаний.</p> <p>Главный вывод учёных: ИИ почти не влияет на мышление человека и управление собой, но вытесняет из работы социальные способности. Их востребованность в рабочих задачах снизится на 8,1%, управленческих — на 6,3%, когнитивные и способности управлять собой изменятся меньше чем на 1%. Сильнее всего пострадают начинающие специалисты: умение строить отношения потеряет в их задачах 27%, потому что ИИ-посредники забирают работу с коллегами. У опытных специалистов построение отношений снизится на 13%, у руководителей создание и развитие команды — на 10%. Расти будет творческое мышление руководителей (+21%).Одновременно способность к саморазвитию чаще становится необходимым условием выполнения управленческих задач: управленцам приходится пересматривать накопленный опыт и менять привычные способы работы по мере изменения задач и инструментов.</p> <p>Нагрузка при этом не исчезнет, а изменит форму. По оценке учёных, доля задач, где человеку нужно проверять и принимать результат ИИ, вырастет с 68% до 80%, задавать агенту правила и границы — с 18% до 32%. ИИ самостоятельно выполнит основную часть 30% задач начинающего специалиста, 19% — опытного и 13% — руководителя. За человеком останутся постановка задачи, приёмка результата и ответственность.</p> <p>Алексей Суханов, проректор по исследованиям и инновациям СберУниверситета, отметил: «Кажется, технологические возможности выходят на такой уровень, когда радикальным сценарием становится работа и учёба без участия других людей. Но остаться человеком без других людей не получится и не имеет смысла. Так что у нас возникает новый вызов: для того, что раньше возникало естественно, — связей, отношений, чувства команды — теперь потребуется создание специальных условий».</p> <p>Учёные рекомендовали около 50% времени развития отводить обучению с другими людьми, 33% — с ИИ и 17% — самостоятельной работе, а главной практикой развития сделать рефлексию — индивидуальную и групповую.</p> СберУниверситет представил на X конференции «Больше чем обучение» исследование «Будущее корпоративного образования. Горизонт … message https://www.itweek.ru/themes/detail.php?ID=235817 Mon, 26 Oct 2026 15:20:18 +0300 <p>Компания «Киберпротект» представила Кибер Бэкап 19 — масштабное обновление своего флагманского решения для резервного копирования и восстановления данных. Новая версия — очередной шаг в развитии продукта: наряду с расширением функциональности от релиза к релизу растут его масштабируемость, производительность, степень автоматизации операций и интеграции с ключевыми корпоративными системами, расширяя возможности применения решения в крупных корпоративных инфраструктурах, в том числе в высоконагруженных сценариях. Обновление направлено на повышение технологической гибкости, надежности и эффективности защиты данных в условиях растущих требований к ИТ-системам и их устойчивости.</p> <p>В Кибер Бэкапе 19 существенно расширены возможности защиты данных в СУБД на основе PostgreSQL. К уже существующим механизмам резервного копирования добавлены новые технологии, ускоряющие работу с данными и расширяющие сценарии восстановления. Важным изменением стала интеграция с библиотекой libpgprobackup от Postgres Professional, реализующей один из наиболее производительных методов резервного копирования таких СУБД. Эта версия библиотеки была разработана Postgres Pro в тесном сотрудничестве с «Киберпротектом» и объединяет экспертизу двух компаний. Теперь пользователям доступен выбор между собственным многопоточным механизмом файлового резервного копирования «Киберпротекта» (с параллельным резервным копированием журнала транзакций или без него) и механизмом библиотеки libpgprobackup для поддерживающих его СУБД.</p> <p>Также добавлена поддержка walsummary — инструмента PostgreSQL, формирующего сводку изменений журналов транзакций для ускорения инкрементного резервного копирования и обеспечения ускоренного восстановления на момент времени. Кроме того, реализована поддержка кластеров Jatoba, что расширяет возможности защиты отечественных инфраструктур на базе PostgreSQL. Поддержка кластеров высокой доступности Patroni и Jatoba дополнена многопоточным резервным копированием для минимизации окна резервного копирования.</p> <p>В Кибер Бэкапе 19 список защищаемых систем виртуализации расширен за счет интеграции с VMmanager — российской системой управления виртуальной инфраструктурой и виртуальными машинами. Теперь резервное копирование виртуальных машин доступно на уровне гипервизора, без установки агентов на каждую машину. Также обеспечена миграции V2V c поддерживаемых платформ виртуализации путем резервного копирования ВМ и ее восстановления из резервной копии.</p> <p>Дополнительно существенно оптимизирован сетевой трафик при работе с популярными системами виртуализации: служебный трафик снижен более чем в 2,5 раза для VMware, а для остальных поддерживаемых платформ (за исключением Hyper-V) объем трафика сократился более чем на порядок благодаря сжатию.</p> <p>В новом релизе добавлена интеграция с российской корпоративной почтовой системой RuPost. Обеспечено полное и инкрементное резервное копирование почтовых ящиков, включая сообщения, календари и другие данные, и восстановление в исходный или новый экземпляр сервера под управлением ОС семейства Linux. Для почты VK WorkSpace повышена масштабируемость: теперь один экземпляр сервера управления поддерживает до 85 тысяч почтовых ящиков.</p> <p>В Кибер Бэкапе 19 полностью переработана система уведомлений. Теперь она охватывает все поддерживаемые источники данных и выдерживает нагрузки, связанные с отправкой уведомлений для десятков тысяч источников данных и тысяч планов защиты, поддерживая таким образом растущую масштабируемость всей системы, в том числе в крупных ИТ-инфраструктурах с десятками тысяч источников данных и тысячами планов резервного копирования.</p> <p>Кроме того, расширен список транспортов: добавлена возможность отправки уведомлений в отечественный мессенджер «Макс».</p> <p>Также расширены возможности интеграции с системами централизованного ИТ-мониторинга. Теперь продукт поддерживает передачу метрик и логов в Zabbix — систему мониторинга ИТ-инфраструктуры, позволяющую отслеживать состояние оборудования, сервисов и приложений, что позволяет включить метрики и данные Кибер Бэкапа в общую систему наблюдения за ИТ-инфраструктурой компании. Для Zabbix доступен готовый шаблон для создания контрольной панели.</p> <p>В новой версии реализована интеграция с решениями, обеспечивающими физическую изоляцию и защиту резервных копий от изменения.</p> <p>Совместимость с AMT InfoDiode — решения на основе технологии однонаправленной передачи данных (data diode). AMT InfoDiode позволяет физически изолировать резервные копии от основной сети и исключить их удаление или изменение даже в случае атаки с использованием вредоносного ПО.</p> <p>В Кибер Бэкапе 19 для агентов защиты ОС семейства Linux появился репозиторий — средство централизованного автоматизированного управления жизненным циклом агента через менеджера пакетов RPM. Всё необходимое для развертывания репозитория, в том числе средства развертывания и пакеты агента, включено в комплект поставки.</p> <p>Текстовые лицензионные ключи заменены лицензионными файлами, защищенными цифровой подписью «Киберпротекта». Активация лицензий осуществляется путем привязки к ID инсталляции сервера управления Кибер Бэкапа, а личный кабинет пользователя теперь выполняет роль единой консоли управления лицензиями.</p> <p>Для загрузочного носителя — компонента Кибер Бэкапа, отвечающего за резервное копирование и восстановление в изолированных средах, а также за восстановление P2P и V2P — лицензионные ограничения были отменены. Полный функционал компонента теперь не требует использования действующей лицензии Кибер Бэкапа, что упрощает взаимодействие с ним администраторов системы.</p> <p>«В Кибер Бэкапе 19 мы сосредоточились на задачах, которые особенно важны для корпоративных заказчиков: защите сложных ИТ-инфраструктур, работе с большими объемами данных и обеспечении устойчивости и производительности процессов резервного копирования. Мы расширили совместимость с отечественными платформами, добавили новые сценарии восстановления и развили инструменты контроля за состоянием резервных копий. Помимо этого, мы перешли на новую, более гибкую, защищенную и производительную систему лицензирования. Это позволяет Кибер Бэкапу решать более широкий круг задач и отвечать на растущие требования бизнеса по защите данных», — отметил Дмитрий Антонов, директор направления систем резервного копирования компании «Киберпротект».</p> <p>Таким образом, Кибер Бэкап 19 расширяет возможности комплексной защиты данных в корпоративных ИТ-инфраструктурах. Новые интеграции с отечественными системами, усовершенствованные механизмы резервного копирования баз данных, поддержка крупных почтовых инфраструктур и развитие инструментов мониторинга позволяют применять решение для защиты более широкого круга ИТ-сред и централизованного управления резервным копированием в масштабах организации.</p> Компания «Киберпротект» представила Кибер Бэкап 19 — масштабное обновление своего флагманского решения для резервного … message https://www.itweek.ru/themes/detail.php?ID=235816 Mon, 26 Oct 2026 15:12:12 +0300 <p>Как ритейлеру узнавать покупателя в любом канале и предлагать ему именно то, что ему нужно? В новом выпуске программы «Интеллектуальный сервис» представители «Дикси» рассказали, как единые данные о клиентах и персональные механики лояльности помогли сети кратно увеличить продажи. Также гости обсудили, какие метрики сегодня важнее всего для розницы и какую роль в её развитии сыграет искусственный интеллект.</p> <p>За 2025 год число участников программы лояльности «Дикси» выросло на 30%, а товарооборот по любимым товарам покупателей — в 3,2 раза. За этим стоит отказ от массовых акций в пользу персональной работы с каждым клиентом на основе данных.</p> <p>Как это устроено — автор и ведущий программы «Интеллектуальный сервис», заместитель генерального директора BSS Василий Жилов узнал у руководителя направления клиентского маркетинга «Дикси» Полины Санниковой и директора по данным и искусственному интеллекту Олега Баженова в новом выпуске на ПРОБИЗНЕС ТВ.</p> <p>В основе — единое хранилище данных, которое собирает цифровые следы покупателя из всех каналов: магазинов, доставки и мобильного приложения. «Золотая запись» клиента позволяет узнать его, даже если он расплатился банковской картой без карты лояльности или зарегистрировался в разных сервисах под разными именами. С этими данными маркетологи работают самостоятельно.</p> <p>«Мы собираем данные в современное хранилище и видим цифровые следы наших клиентов. Даже если человек расплатился банковской картой, не приложив карту лояльности, мы понимаем, что это его покупка. Благодаря знанию о клиенте мы можем предложить ему самый лучший товар по самой лучшей цене — то, что ему действительно нужно», — рассказал Олег Баженов, директор по данным и искусственному интеллекту «Дикси».</p> <p>Именно на этих данных строятся персональные предложения. Каждый клиент получает в мобильном приложении пять скидок на товары, ради которых он приходит в магазин, — это один из самых трафикообразующих инструментов сети. Для новых покупателей, о которых истории пока нет, первую подборку формирует предиктивная модель по предпочтениям похожих на них людей.</p> <p>Вторая опора — программа лояльности, которую «Дикси» перезапустила в 2024 году. Ставка сделана на простые механики: покупатель сам выбирает 8 из 30 любимых категорий с повышенным кэшбэком и раз в неделю обновляет список любимых товаров, а накопленные монеты может потратить не только в магазине, но и у партнёров — например, на поездки в метро или мобильную связь. Именно эти механики дали основной рост: товарооборот по любимым категориям увеличился в 2,2 раза, а NPS участников программы продолжает расти.</p> <p>«Я называю это моментальной кармой: на любое наше действие мы практически сразу получаем отклик покупателей. Мы его собираем, анализируем и постоянно корректируем свои решения. Клиентский маркетинг всегда идёт от человека, и задача каждого магазина, независимо от формата, — стать любимым», — подчеркнула Полина Санникова, руководитель направления клиентского маркетинга «Дикси».</p> <p>«Опыт „Дикси“ показывает: клиентский сервис сегодня — это не набор отдельных инструментов, а система, которой нужно управлять интеллектуально. Решения должны опираться на комплексную аналитику всех взаимодействий клиента и бизнеса на протяжении всего пути — от первого контакта до повторной покупки, в магазине, приложении и доставке. Только когда компания видит этот путь целиком, она может вовремя понять потребности клиента и превратить качество сервиса в рост выручки», — отметил Василий Жилов, заместитель генерального директора BSS.</p> <p>Как найти баланс между выбором клиента и предиктивной аналитикой, почему NPS — запаздывающая метрика и чему российскому ритейлу стоит поучиться у Китая, где молодёжь почти не ходит в магазины, — в полном выпуске программы «Интеллектуальный сервис» на Rutube и VK Видео.</p> Как ритейлеру узнавать покупателя в любом канале и предлагать ему именно то, что ему нужно? В новом выпуске … message https://www.itweek.ru/themes/detail.php?ID=235814 Mon, 26 Oct 2026 10:18:57 +0300 <p><em>В последние два года дискуссии об использовании искусственного интеллекта в корпоративном секторе были сосредоточены преимущественно на моделях, агентах и ​​инфраструктуре. Организации оценивали базовые модели, экспериментировали с фреймворками для создания агентов, инвестировали в облачные архитектуры, изначально спроектированные для ИИ, и стремились как можно быстрее внедрить «копилотов» и автономные системы. Однако многие из этих инициатив столкнулись с одним и тем же препятствием: эффективность агентов напрямую зависит от качества получаемого ими контекста, пишут в корпоративном блоге главные аналитики </em><em>Forrester</em> <em>Чарли Дай (вице-президент), Лесли Джозеф и Индранил Бандьопадхьяй.</em></p> <p>По мере того как агентный ИИ эволюционирует от систем типа «вопрос-ответ» к автономным системам, способным рассуждать, планировать, использовать инструменты и выполнять бизнес-процессы, контекст превращается из вспомогательного ресурса в критически важный элемент производственной среды. Агенты не могут полагаться на интуицию, институциональную память или человеческое суждение. Им необходим точный, своевременный и ситуативно релевантный контекст, объединяющий бизнес-знания, текущее операционное состояние, цели, ограничения и накопленный опыт. Этот сдвиг заставляет компании переходить от работы, основанной исключительно на данных, к деятельности, движимой знаниями.</p> <p>Проблема заключается в том, что большинство предприятий изначально не были спроектированы для предоставления контекста подобным образом. Знания остаются разрозненными: они распределены по приложениям, документам, базам данных, электронной почте, бизнес-процессам и экспертизе отдельных сотрудников. Одних лишь данных недостаточно. Данные описывают реальность, знания — объясняют её, а контекст позволяет применить нужные знания к конкретной ситуации, чтобы ИИ-агент мог эффективно рассуждать, принимать решения и действовать.</p> <p>Именно поэтому инженерия контекста (context engineering) становится фундаментальной дисциплиной для агентного ИИ. Хотя этот термин всё чаще встречается в экосистеме ИИ, организации зачастую трактуют его слишком узко — сводя лишь к составлению промптов или поиску информации. Forrester дает следующее определение инженерии контекста: это практика проектирования, оркестрации и предоставления структурированного, релевантного и своевременного контекста для ИИ-систем, обеспечивающая точность, обоснованность и соответствие их результатов заданным требованиям. В отличие от промпт-инжиниринга, который фокусируется на инструкциях, инженерия контекста сосредоточена на информации, семантике, инструментах, памяти и правилах, определяющих поведение агента до, во время и после выполнения задачи. Современная инженерия контекста базируется на четырех основополагающих элементах:</p> <ul> <li> <strong>Генерация с расширенным поиском (</strong><strong>r</strong><strong>etrieval-augmented generation, RAG) </strong>формирует базу знаний, извлекая релевантную информацию из корпоративных данных, документов, метаданных и систем знаний, превращая разрозненные сведения в обоснованный и ситуативно значимый контекст.</li> <li><strong> Вызовы функций </strong>связывают агентов с корпоративными приложениями, рабочими процессами, API и сервисами, позволяя им получать актуальную бизнес-информацию, выполнять действия и непрерывно адаптироваться к меняющимся операционным условиям.</li> <li><strong> Управление памятью</strong> сохраняет историю взаимодействий, состояния рабочих процессов, наблюдения, предпочтения и принятые ранее решения в рамках различных задач и сессий, обеспечивая агентам непрерывность, персонализацию и долгосрочное понимание ситуации.</li> <li><strong> Контекстные модели </strong>объединяют знания, полученные с помощью RAG, операционную осведомленность, сформированную через вызовы функций, и преемственность, поддерживаемую системой управления памятью, в целостное представление бизнес-реальности. Это создает структуру, благодаря которой агенты могут рассуждать, планировать и действовать последовательно в рамках сложных рабочих процессов.</li> </ul> <p>Однако создание контекста — это лишь часть задачи. Предприятиям также необходимо обеспечить его практическое применение, управление, мониторинг, безопасность и постоянное совершенствование в масштабах всей организации. Именно здесь на помощь приходит концепция ContextOps. Forrester определяет ContextOps как операционную дисциплину, охватывающую управление, контроль, мониторинг и развитие контекстных активов и потоков на протяжении всего их жизненного цикла — от проектирования и разработки до выполнения в реальном времени и офлайновых обновлений. ContextOps переносит принципы DataOps, MLOps и AIOps на уровень контекста, гарантируя, что по мере развития и масштабирования агентов в организации контекст остается надежным, наблюдаемым, соответствующим нормативным требованиям и эффективным.</p> <p>#IMAGE_235815#</p> <p>Следующий этап развития корпоративного ИИ будет определяться не только производительностью моделей или сложностью самих агентов, но и способностью организации превратить инженерию контекста в полноценную платформу. В условиях расширения масштабов внедрения ИИ компаниям требуются общие сервисы контекста, повторно используемые контекстные активы и единые механизмы управления — вместо разрозненных реализаций RAG, систем памяти и интеграции инструментов. Инженерия контекста должна эволюционировать из практики, применяемой в рамках отдельных проектов, в платформенную возможность корпоративного уровня, а ContextOps — обеспечить операционный фундамент, необходимый для поддержания надежности, управляемости и масштабируемости этой системы. В эпоху агентного ИИ победят не те, кто просто развернет больше агентов, а те, кто создаст более совершенные контекстные платформы.</p> В последние два года дискуссии об использовании искусственного интеллекта в корпоративном секторе были … article https://www.itweek.ru/themes/detail.php?ID=235812 Mon, 26 Oct 2026 09:57:59 +0300 <p><em>Когда ИТ-архитектор выбирает платформу VDI (</em><em>Virtual</em> <em>Desktop</em> <em>Infrastracture</em><em>), он обычно опирается на три документа — матрица совместимости, тесты производительности и коммерческое предложение. Четвертый документ — финансовая модель на три года — остаётся за скобками обсуждения. Между тем именно архитектура протокола определяет, сколько пользователей поместится на один хост, какую долю CPU и GPU съест конвейер кодеков и во что обойдётся инфраструктура в пересчёте на рабочее место. В этой статье рассмотрим влияние выбора протокола удаленного доступа на стоимость владения и приобретения инфраструктур </em><em>VDI</em> <em>на примере западных решений, при этом выводы в той же, если не большей, мере относятся к российским </em><em>VDI</em> <em>и ВКС.</em></p> <h3>Кодеки, CPU и плотность: где сгорают циклы</h3> <p>Полнокадровое кодирование H.264 — это простой и предсказуемый процесс, потому что каждый пиксель экрана проходит через один и тот же кодек. Если сессия на 80% состоит из статического текста и на 20% из видео, полнокадровый кодировщик тратит вычислительные ресурсы на сжатие текстовых областей так же интенсивно, как на движение. Это не оптимизация, а равномерное распределение нагрузки там, где его можно избежать.</p> <p>Технология удалённого отображения Citrix Thinwire использует многокодековое кодирование в одном кадре. Так классификатор содержимого определяет текстовые области, видео и зоны высокой интенсивности движения, после чего к статике применяется MDRLE (без потерь, минимальный битрейт), а к движущимся фрагментам — H.264 или H.265. Классификатор добавляет циклы CPU, но стоимость этой классификации существенно ниже стоимости кодирования, сэкономленной за счёт отказа от H.264 на статике. Для типичного «продвинутого» сотрудника, использующего документы, браузер, таблицы, потребление CPU в Thinwire заметно ниже, чем при полнокадровом H.264 без vGPU.</p> <p>Это имеет прямое следствие для плотности пользователей на хост. Плотность ограничена не только ядрами, но и тем, сколько циклов CPU остаётся после вычета нагрузки на кодирование. Протокол, который тратит меньше циклов на сессию, позволяет разместить больше сессий на том же физическом сервере. А плотность — это и есть основная единица стоимости в VDI, потому что чем больше пользователей на хост, тем ниже CAPEX и OPEX на рабочее место.</p> <h3>Клиентский оффлоад: когда видеокарта пользователя работает на экономику</h3> <p>Перенос части обработки изображения на клиентское устройство не является благотворительностью со стороны вендора. Это перекладывание вычислительной нагрузки с хоста, за который платит заказчик, на конечную точку, за циклы которой он обычно не платит.</p> <p>Механизм HDX Graphics Superresolution Upscaling, появившийся в CVAD 2603, работает именно так. Агент виртуального рабочего стола VDA (Virtual Delivery Agent) идентифицирует видео и области высокой интенсивности движения, применяет дополнительное сжатие с понижением эффективного разрешения перед кодированием. Вычислительная стоимость H.264/H.265 масштабируется линейно от числа пикселей. Уменьшение размеров (разрешения) на 50% снижает вычислительную стоимость кодирования этой области примерно на 75%. Реконструкция до исходного разрешения выполняется на совместимом графическом процессоре конечной точки. Нагрузка на VDA снижается, нагрузка на клиент растёт, но клиент уже есть у пользователя.</p> <p>Второй эффект — это пропускная способность. Снижение битрейта видеофрагментов на <nobr>30-50%</nobr> означает меньший сетевой ввод-вывод на сессию. Если узким местом хоста была сетевая карта, а не CPU, это расширяет потолок плотности. Для рабочих нагрузок с интенсивным кодированием на GPU и большим объёмом видеоконтента выигрыш в плотности значителен, а для задач с малым количеством видео эффект скорее определяется пропускной способностью, чем вычислениями. И это является архитектурной оценкой, а не результатом тестов производителей, потому что фактический прирост зависит от сочетания нагрузок и поколения железа.</p> <h3>Superresolution против редиректа</h3> <p>Здесь необходима оговорка, которую вендоры редко добавляют в презентациях. Superresolution Upscaling — это не замена Multimedia Redirection (перенаправление воспроизведения медиа с ВМ на клиент) и Browser Content Redirection. Это инструмент для сценариев, где редирект неприменим по архитектурным причинам, так как контент не имеет доступного клиенту кодека или URL, DRM-защита блокирует перенаправление, а приложение использует проприетарный рендеринг, не поддающийся перехвату.</p> <p>Если редирект возможен, он даёт больший эффект. При Multimedia Redirection сервер не декодирует и не кодирует контент вообще, он передаёт сжатый поток клиенту для локального декодирования и рендеринга. CPU VDA не тратится ни на декодирование, ни на повторное кодирование. Superresolution Upscaling в этом смысле — компромисс, так как сервер всё равно кодирует, только с меньшим разрешением. Он полезен там, где редирект не работает, но не должен рассматриваться как его замена.</p> <p>Сценарии, где Superresolution имеет смысл, это — спутниковые каналы с ограниченной полосой, SD-WAN с оплатой за трафик, 4K-сессии на каналах, которые ранее тянули только 1080p. Сценарии, где редирект эффективнее, — это корпоративные медиапорталы, обучающие видео, веб-конференции с известными источниками контента.</p> <h3>ВКС и экономика VDI: скрытая статья расходов</h3> <p>Оптимизация ВКС в VDI важна не только с точки зрения качества связи для пользователя. Плохо оптимизированный ВКС-клиент в виртуальной сессии может потреблять ресурсы хоста совершенно непропорционально количеству пользователей. Декодирование видео, эхо-подавление, микширование аудио — всё это выполняется на стороне агента виртуального рабочего стола VDA, то есть на хосте VDI, если не задействован оптимизированный медиа-путь.</p> <p>Интеграция SlimCore (New Teams) в Citrix HDX — это пример архитектурного решения, которое влияет на плотность. Когда медиапоток ВКС обрабатывается через оптимизированный виртуальный канал с оффлоадом кодеков на клиент или специализированный медиа-движок, нагрузка на хост снижается. Когда ВКС работает как обычное приложение внутри сессии, каждый звонок создает дополнительную нагрузку на CPU и сеть. Для организации с сотнями пользователей, проводящих в звонках по два-три часа в день, разница в плотности между оптимизированным и неоптимизированным ВКС может измеряться десятками сессий на хост.</p> <p>Это та самая статья, которую FinOps, модель финансового управления ИТ-затратами, часто упускает. Стоимость ВКС определяется не в лицензиях, а в том, сколько хостов необходимо докупить из-за неоптимизированной обработки медиапотока.</p> <h3>Компромиссы выбора платформы</h3> <p>Архитектурная асимметрия между платформами — это не повод для принципиальных споров, а основа для модели затрат.</p> <p>Citrix HDX/EDT остаётся эталоном для WAN-развёртываний с постоянно превышающим 50 мс временем отклика в обоих направлениях, для графически интенсивных рабочих мест (САПР, настольные издательские системы, финансовые торговые платформы с высокой плотностью отображения) и для сценариев, где Superresolution Upscaling даёт прямую экономию на полосе пропускания. <br/> Механизм контроля перегрузки на основе задержек и многокодековый рендеринг — это не маркетинговые термины, а факторы, напрямую влияющие на плотность и стоимость канала. </p> <p>Omnissa Blast является рациональным выбором для организаций с глубокими инвестициями в vSphere/NSX и локальными пользователями, где задержка WAN не является основным ограничением. Blast поддерживает H.264 4:4:4, HEVC 4:4:4, AV1 и оффлоад на vGPU, но не имеет многокодекового рендеринга по областям кадра и механизма оффлоада масштабирования на клиент. Любое улучшение визуального качества требует пропорционально большего объёма серверных ресурсов — линейное масштабирование затрат, которого в Citrix структурно нет.</p> <p>Microsoft RDP архитектурно устарел для задач, выходящих за пределы локальных сетей с простыми рабочими нагрузками. Отсутствие H.265, AV1, контроля перегрузки на основе задержки и приоритизации виртуальных каналов — это не случайность, а следствие фокуса Microsoft на Azure Virtual Desktop. RDP приемлем для небольших локальных развёртываний, но не должен рассматриваться как основа для распределённой инфраструктуры.</p> <p>Parallels RAS превосходит базовый RDP за счёт управления QoS в XTCP и дифференциального кэша на клиенте, но потолок ограничен кодеками RDP. Для малых и средних предприятий с локальным подключением и приоритетом простоты эксплуатации это работающий инструмент, а для корпоративного VDI в WAN — нет.</p> <h3>Вывод для архитекторов</h3> <p>Протокол — это не только пользовательский опыт. Это множитель, который определяет, сколько вы платите за каждый цикл CPU, за каждый мегабит пропускной способности и за каждого пользователя, которого можно посадить на существующий хост. Важно помнить, что модель затрат, которая игнорирует архитектуру протокола, оптимизируя лицензии, забывает и про серверы, и про пользовательский опыт.</p> <p>При выборе платформы VDI архитектору стоит оценивать протокол по трём измеримым величинам — стоимости кодирования на сессию, стоимости доставки бита по реальному каналу и предельной плотности пользователей на хост. Эти три величины складываются в ту самую статью бюджета, которая остаётся за скобками матриц совместимости. И именно они, а не число установленных устройств, определяют, во что инфраструктура обойдётся через три года.</p> <p>#IMAGE_235813#</p> Когда ИТ-архитектор выбирает платформу VDI (Virtual Desktop Infrastracture), он обычно опирается на три … article Александр Тарасов, главный системный архитектор Getmobit https://www.itweek.ru/themes/detail.php?ID=235806 Fri, 23 Oct 2026 13:52:02 +0300 <p>Компания Security Vision сообщила о выходе новой версии продукта CMDB Configuration Management Database — база данных управления конфигурациями со встроенным контролем ИТ-изменений. Продукт Security Vision CMDB объединяет централизованное управление конфигурационными единицами и процессами ИТ-изменений. Решение автоматизирует сбор данных об ИТ-ландшафте и обеспечивает системный контроль технических изменений, сохраняя непрерывность и доступность критических бизнес-сервисов. Продукт ориентирован на enterprise-сегмент и помогает перейти от разрозненных списков ИТ-компонентов к управляемой ресурсно-сервисной модели.</p> <p>В распределенной enterprise-среде обновления систем, обслуживание серверов и сетевые перенастройки нередко согласуются без наглядного понимания сквозных взаимосвязей. Накладки в расписании, пересечение параллельных задач смежных команд и нарушение регламентных окон обслуживания могут приводить к каскадным сбоям зависимых систем и незапланированным простоям бизнес-сервисов. Для бизнеса это означает задержки в выполнении операций и дополнительные расходы на восстановление — даже если сами технические работы были плановыми.</p> <p>Продукт Security Vision CMDB связывает актуальную цифровую модель инфраструктуры, процессные механизмы контроля и автоматизацию в единый контур. Каждое планируемое изменение сопоставляется с ресурсно-сервисной моделью на интерактивном графе зависимостей. Платформа определяет потенциальный масштаб воздействия и автоматически включает в маршрут авторизации непосредственных владельцев затронутых бизнес-сервисов. Таким образом, в согласовании участвуют руководители, отвечающие за работу затронутых сервисов. Они могут заранее учесть последствия для своих подразделений и определить приемлемое время проведения работ.</p> <p>Интерактивный граф визуализирует топологию ИТ-среды от компонентов инфраструктуры (серверы, сеть, СХД) до баз данных, прикладного ПО и конечных бизнес-сервисов с указанием их критичности и владельцев.</p> <p>Встроенный модуль автоматически определяет затрагиваемые системы при планировании изменений, сопоставляет графики работ смежных подразделений для исключения конфликтов и контролирует соблюдение регламентных окон обслуживания.</p> <p>В платформе реализованы готовые процессы, которые позволяют регулярно по заданному расписанию выполнять поиск и обнаружение новых активов в ИТ-ландшафте, проводить их идентификацию, инвентаризацию, собирать сведения о конфигурации, а также сопоставлять проведенные плановые и фактические изменения. Данные объединяются из сетевых источников, гипервизоров и систем мониторинга через готовые коннекторы, а встроенные механизмы нормализации устраняют дубликаты и формируют эталонную карточку каждого объекта с ведением прозрачной истории модификаций.</p> <p>Это сокращает объем ручной сверки данных и помогает принимать решения на основании фактического состояния инфраструктуры Наличие объективной цифровой модели позволяет согласовывать изменения с точным пониманием реальной конфигурации систем.</p> <p>При возникновении сбоев сервисные службы получают мгновенный доступ к истории недавних технических изменений по всей цепочке зависимостей аварийного сервиса. Это связывает эксплуатационные инциденты с реальными вмешательствами в инфраструктуру, существенно упрощая поиск первопричин и ускоряя восстановление услуг.</p> <p>В продукте предусмотрены готовые процессы для Стандартных (типовые, предварительно авторизованные), Нормальных (полный цикл технической экспертизы и оценки рисков) и Экстренных изменений (ускоренный маршрут для устранения аварий).</p> <p>No-Code кастомизация: возможность без написания программного кода создавать собственные типы изменений и гибко настраивать политики согласования с учетом параметров запроса, типа конфигурационной единицы или критичности затронутого сервиса. Встроенные конструкторы позволяют настраивать интеграции, реализовывать автоматизированный сбор данных и взаимодействие с любыми системами внутри корпоративного ИТ-ландшафта, адаптировать процессы под внутренние регламенты и формировать произвольные форматы отчетности, принятые в организации. Набор конструкторов, встроенных в платформу, позволяет в режиме No-Code добавлять новые действия и самостоятельно корректировать все встроенные процессы и алгоритмы.</p> <p>Для ИТ-директоров продукт обеспечивает управляемость сложной инфраструктуры и помогает ускорить выпуск изменений без конфликтов между командами. Для руководителей информационной безопасности — обеспечивает контроль безопасности любых изменений в инфраструктуре и позволяет мгновенно оценивать периметр влияния инцидентов на связанные системы. Для технических директоров — обеспечивает предсказуемость регламентных процедур и защищает инфраструктуру от непредвиденных сбоев на основе точной карты взаимосвязей.</p> <p>Продукт продолжает развитие экосистемы решений Security Vision Enterprise. Единая база конфигураций и регламентированный процесс согласования изменений помогают оптимизировать эксплуатационные расходы и гарантировать непрерывность бизнес-процессов. Благодаря открытому API и встроенному конструктору интеграций продукт бесшовно интегрируется в существующий ландшафт заказчика, включая внешние Service Desk-системы сторонних разработчиков.</p> Компания Security Vision сообщила о выходе новой версии продукта CMDB Configuration Management Database — база данных … message https://www.itweek.ru/themes/detail.php?ID=235805 Fri, 23 Oct 2026 12:41:30 +0300 <p>Рынок коммерческих центров обработки данных в Московском регионе проходит этап структурной перестройки. Устойчивый спрос на размещение оборудования сталкивается с ограниченной доступностью электрических мощностей, которая сдерживает строительство новых объектов. В этих условиях определяющим фактором развития становится не только наличие площадки, но и возможность обеспечить ее надежным энергоснабжением. Девелоперы и операторы пересматривают энергетические решения, а часть спроса постепенно перераспределяется в регионы.</p> <p>По оценке аналитиков CORE.XP, среднегодовая потребность в мощности ЦОД в Москве и Московской области составляет около 70 МВт, тогда как доступное предложение остается крайне ограниченным. В 2026 году ряд новых проектов получил отказы в заключении договоров на технологическое присоединение: свободные мощности либо уже используются, либо зарезервированы крупными участниками рынка на <nobr>2026–2028 годы.</nobr> Это ограничивает реализацию новых крупных объектов и увеличивает неопределенность сроков их запуска.</p> <p>При этом российский рынок коммерческих ЦОД продолжает расти. Согласно данным CORE.XP и iKS-Consulting, максимальная электрическая мощность объектов в 2025 году составила 877 МВт. По прогнозу, к 2027 году показатель достигнет 1 048 МВт, увеличившись примерно на 10% относительно уровня 2026 года. Однако рост совокупной мощности не устраняет локальный дефицит: возможность размещения оборудования зависит от географии доступного предложения и сроков ввода конкретных площадок.</p> <p>Ограничения энергоснабжения усиливаются высокой стоимостью заемного финансирования и ростом капитальных затрат. По данным Invest Projects за сентябрь 2026 года, в России заморожено 38 проектов ЦОД с общим объемом заявленных инвестиций 188 млрд рублей. Аналитики CORE.XP выделяют три основных фактора приостановки проектов: дорогой кредит, ограниченный доступ к электрической мощности и сложность масштабирования без ухудшения экономики объекта. Для коммерческих центров обработки данных такая комбинация факторов особенно критична: рост инвестиций неизбежно отодвигает срок выхода на доход.</p> <p>Дисбаланс спроса и предложения отражается в стоимости услуг. По оценке CORE.XP, в отдельных случаях рост стоимости размещения оборудования в расчете на 1 кВт за период <nobr>2025–2026</nobr> годов мог достигать 40%. Этот показатель не характеризует весь рынок, но демонстрирует ценовое давление в условиях ограниченной доступности мощностей. При этом предложение также расширяется: по данным iKS-Consulting, среднегодовой прирост количества стоек в <nobr>2016–2026</nobr> годах составил 11,4%. Таким образом, увеличение числа стоек само по себе не компенсирует ограничения по энергоснабжению и рост себестоимости новых объектов.</p> <p>Одним из ключевых направлений адаптации становится собственная генерация. Большинство игроков, по оценке CORE.XP, прорабатывают возможность использования газопоршневых и газотурбинных установок либо оценивают альтернативные схемы электроснабжения. Собственная генерация требует более высоких первоначальных вложений, однако позволяет снизить зависимость от доступности сетевой мощности. Более низкие эксплуатационные расходы в перспективе могут частично компенсировать дополнительные капитальные затраты, но итоговая экономика зависит от условий конкретной площадки.</p> <p>Для Московского региона газовая генерация становится альтернативой длительному ожиданию технологического присоединения. Возможность реализации такой модели определяется доступом к газопроводу, стоимостью топлива и оборудования, схемой резервирования, а также экологическими и эксплуатационными ограничениями. Дополнительное преимущество газопоршневых и газотурбинных решений — возможность поэтапного ввода мощности по мере увеличения вычислительной нагрузки.</p> <p>Переход на собственное энергоснабжение, однако, требует времени на проектирование, согласования и строительство. Поэтому, по прогнозу аналитиков CORE.XP, часть объектов, ранее заявленных к вводу в <nobr>2028–2029 годах,</nobr> может быть запущена позднее. Это будет поддерживать дефицит качественного предложения в Московском регионе и инвестиционную привлекательность проектов, для которых вопрос энергоснабжения уже решен.</p> <p>Параллельно расширяется предложение коммерческих ЦОД за пределами столичного региона. Новые площадки появляются в Санкт-Петербурге, Екатеринбурге, Новосибирске и Красноярске. Региональные объекты могут обеспечивать более быстрое размещение оборудования и доступ к мощности без ограничений, характерных для Москвы и Московской области. При этом выбор локации зависит не только от энергетических ресурсов, но и от качества каналов связи, требований к задержке передачи данных и близости к потребителям.</p> <p>«Рынок ЦОД переходит от выбора площадки к выбору энергетической модели. Высокий спрос сам по себе уже не гарантирует реализацию проекта: критическое значение имеют подтвержденный доступ к мощности, сроки подключения и возможность масштабирования. Для Московского региона собственная генерация становится одним из способов преодолеть ограничения, но требует более сложной оценки капитальных и эксплуатационных затрат. Преимущество будут получать проекты с предсказуемыми сроками запуска и надежным энергоснабжением, тогда как часть спроса продолжит перераспределяться на региональные площадки», — прокомментировал Антон Алябьев, старший директор, руководитель отдела складской и индустриальной недвижимости CORE.XP.</p> <p>Таким образом, дефицит электрической мощности меняет не только сроки ввода ЦОД, но и географию, структуру затрат и критерии инвестиционного отбора проектов. На первый план выходит энергообеспеченность площадки: именно она определяет возможность удовлетворить спрос и сохранить устойчивую экономику объекта.</p> Рынок коммерческих центров обработки данных в Московском регионе проходит этап структурной перестройки. Устойчивый спрос … message https://www.itweek.ru/themes/detail.php?ID=235803 Fri, 23 Oct 2026 10:51:05 +0300 <p><em>Координация работы роботов и автономных систем станет ключевым фактором для полноценного внедрения физического ИИ (Physical AI), однако пока неясно, как скажется отсутствие совместимости на его распространении, отмечают опрошенные порталом </em><em>AI</em> <em>Business</em> <em>эксперты.</em></p> <p>Технологии физического ИИ все активнее внедряются на заводах, складах и других производственных объектах. Gartner включила это направление в список главных стратегических технологических трендов-2026. Тем не менее, восприятие физического ИИ как единой технологической категории может помешать компаниям извлечь из него максимальную пользу. По мнению Gartner, бизнесу следует сместить фокус с отдельных устройств на системы, которые координируют их работу, — область, которая на данный момент развита недостаточно.</p> <p>«Поставщики робототехники стремятся позиционировать свои предложения как комплексные решения, зачастую представляя свои продукты как автономные единицы, которые можно легко интегрировать в существующие рабочие процессы. На деле это совсем не так», — отмечает аналитик Gartner Билл Рэй.</p> <p>По его словам, существующие платформы оркестрации обладают ограниченным функционалом и ориентированы преимущественно на те сферы, где уже взаимодействуют целые парки роботов — например, на складские комплексы.</p> <p>«Сейчас мы наблюдаем лишь разрозненные попытки решения этой задачи, однако существует огромный нереализованный потенциал для создания полноценных систем оркестрации. По мере роста числа роботов и других систем физического ИИ потребность в них будет только увеличиваться», — считает Рэй.</p> <h3>Выход за рамки отдельных роботов</h3> <p>Оркестрация подразумевает наличие программного уровня, который связывает системы управления парками роботов друг с другом, а также с общей инфраструктурой предприятия или здания.</p> <p>Как отмечает Рэй, поставщики робототехники продолжат предлагать собственное ПО для управления парками машин, в то время как уровень оркестрации будет координировать задачи между роботами, не взаимодействуя напрямую с каждым отдельным устройством.</p> <p>В качестве примера такого подхода он приводит решение Physical AI Orchestrator компании Accenture. Ожидается, что на рынок выйдут и другие провайдеры с платформами оркестрации, адаптированными для конкретных отраслей.</p> <p>Впрочем, Ян Липхардт, доцент кафедры биоинженерии Стэнфордского университета, участвующий также в разработке ПО для робототехники в компании OpenMind, подчеркивает, что обеспечение надежного взаимодействия между роботами остается сложнейшей задачей. «Отсутствие совместимости компьютеров, людей и роботов — это серьезный пробел, — говорит он. — В промышленных условиях добиться того, чтобы разные роботы работали вместе надежно, бывает очень сложно, дорого и долго».</p> <p>По его словам, в ряде случаев на то, чтобы заставить роботов от двух разных поставщиков скоординировано выполнять задачи, могут уйти месяцы или даже целый год. Это открывает возможности для технологий, упрощающих интеграцию, хотя эксперт предостерегает: отрасль, возможно, еще не готова к тому, чтобы оркестрация стала ключевым аспектом при любом внедрении робототехники.</p> <p>«Добиться эффективной работы одного робота — непростая задача; заставить слаженно функционировать роботов разных типов — еще сложнее; а если речь идет о роботах от разных производителей, то задача становится и вовсе крайне трудной», — отмечает он.</p> <p>Липхардт говорит, что существует значительный интерес к протоколам, призванным решить эти проблемы, однако сама задача пока несколько опережает текущие рыночные реалии. «В среднесрочной и долгосрочной перспективе — скажем, к середине следующего года — это направление, вероятно, приобретет исключительную важность», — добавляет он.</p> <h3>Отсутствие интероперабельности — не единственное препятствие</h3> <p>Не все аналитики считают отсутствие интероперабельности главным барьером на пути внедрения физического ИИ.</p> <p>Марк Беккью, аналитик компании Omdia, утверждает, что бизнес чаще сталкивается с ограничениями существующей инфраструктуры и нехваткой профильных компетенций, чем с отсутствием стандартов совместимости. «Я не думаю, что стандартизация совместимости станет основным драйвером внедрения. Ускорить этот процесс поможет использование инструментов, навыков и моделей с открытым исходным кодом — подход, который активно продвигает Nvidia», — считает он.</p> <p>По его словам, главная проблема заключается в недостаточной гибкости унаследованных систем для интеграции новейших технологий и подходов. Вторая по значимости сложность — несоответствие квалификации персонала: отсутствие в штате организации специалистов, обладающие знаниями, необходимыми для работы с системами конкретных поставщиков.</p> <p>Иными словами, даже при наличии инструментов оркестрации компаниям все равно необходимы соответствующие инфраструктура, навыки и операционные процессы для успешного внедрения физического ИИ.</p> <p>Еще одна, более насущная задача — интеграция автономных систем в уже существующую рабочую среду. Внедрение роботов и автономных транспортных средств может потребовать изменения планировки помещений и рабочих процессов — особенно в тех случаях, когда машины должны безопасно функционировать в одном пространстве с людьми. «Если возникает необходимость изолировать роботов и автономные транспортные средства от людей, это может требовать реорганизации пространства: нужно продумать, как сохранить текущие рабочие процессы, одновременно изменив маршруты передвижения персонала, — отмечает Рэй. — Стоимость подобных преобразований очень легко недооценить».</p> <p>Компаниям также необходимо определить, как распределить задачи между людьми и машинами, вместо того чтобы исходить из предположения, что автоматизировать нужно абсолютно всё.</p> <p>Иными словами, интеграция технологий в текущие рабочие процессы не менее важна, чем сами технологии; неверный выбор может привести к тому, что компания окажется в числе отстающих.</p> <p>«Уровень оркестрации станет критически важным элементом инфраструктуры — сменить поставщика будет крайне сложно, а с каждой новой интеграцией — всё сложнее, поэтому важно принять верное решение как можно раньше», — говорит Рэй.</p> <h3>Взгляд в будущее</h3> <p>По мере расширения внедрения физического ИИ понимание того, как роботы, корпоративные системы и человеческие рабочие процессы взаимодействуют друг с другом, позволит компаниям более эффективно масштабировать свои технологии.</p> <p>«Первый шаг — и это касается внедрения любых технических инноваций — заключается в разработке комплексного бизнес-обоснования, — говорит Беккью. — Спросите себя: какую проблему мы пытаемся решить? Каковы единовременные и текущие затраты? Каков ожидаемый возврат инвестиций (ROI) — включая расчеты чистой приведенной стоимости (NPV), внутренней нормы доходности (IRR) или срока окупаемости?».</p> <p>Липхардт предлагает более оперативный подход: компаниям следует начать экспериментировать с физическим ИИ уже сейчас, даже если вопросы совместимости, форматов данных и зависимости от конкретного поставщика пока остаются открытыми. «Моя рекомендация сегодня, в конце 2026 г., такова: чем бы вы ни занимались — производством, перемещением, транспортировкой, склеиванием, шитьем или сборкой — пробуйте различные решения, причем сделать это нужно было еще вчера, — говорит он. — На данном этапе на ваших предприятиях уже должны быть запущены пилотные проекты, чтобы вы были максимально осведомлены о технологии, которая развивается невероятно быстро».</p> Координация работы роботов и автономных систем станет ключевым фактором для полноценного внедрения физического ИИ … article https://www.itweek.ru/themes/detail.php?ID=235799 Fri, 23 Oct 2026 09:56:18 +0300 <p>Промышленная автоматизация долгое время строилась по принципу разделения уровней. На полевом уровне датчики преобразовывали физическую величину в унифицированный сигнал. Контроллеры обрабатывали данные и принимали решения. Системы управления занимались координацией и аналитикой. Такая архитектура была оправдана, когда вычислительные ресурсы были дорогими и централизованными, а от диагностики требовалось лишь зафиксировать отказ.</p> <p>Сегодня требования изменились. Industry 4.0 и IIoT предполагают сквозную цифровизацию: данные должны собираться на нижнем уровне и без потерь доходить до аналитических платформ. Но на практике многие предприятия сталкиваются с парадоксом. Внедрено множество цифровых систем, но единого информационного пространства нет, и главная причина тут архитектурная. Разрывы возникают не на уровне MES или ERP, а на стыке между датчиком и системой сбора данных.</p> <p>Традиционная цепочка «датчик → модуль ввода-вывода → контроллер → SCADA → аналитика» содержит несколько точек преобразования. На каждом переходе данные не только меняются, но и теряют часть информации. Диагностические регистры датчика, параметры качества линии связи, статистика наработки недоступны либо доступны фрагментарно и с задержкой. В результате верхние уровни работают с упрощённой картиной, что снижает достоверность предиктивной аналитики и цифровых двойников.</p> <h3> Ограничения традиционных интерфейсов</h3> <p>Чтобы понять, почему цифровой полевой уровень стал необходимостью, посмотрим на эволюцию интерфейсов.</p> <p>Аналоговая токовая петля 4...20 мА долгое время была основой измерений. Она проста, помехоустойчива и хорошо защищена от электромагнитных помех. Но её информационная ёмкость ограничена одним числом. Диагностики как отдельного потока данных нет. Верхний уровень видит только ток и не может отличить реальное изменение параметра от неисправности датчика. Питание по той же паре возможно, но мощность ограничена. При большом числе точек растёт стоимость кабельной инфраструктуры, а для интеграции с ИТ-системами нужны дополнительные преобразователи.</p> <p>HART добавил цифровой канал поверх аналоговой петли. Но скорость обмена, равная 1,2 кбит/с, слишком мала для полноценной диагностики в реальном времени. Мультиплексирование позволяет опрашивать несколько приборов, но увеличивает время цикла. HART — протокол, скорее, для настройки и калибровки, чем для потоковой передачи данных о состоянии прибора.</p> <p>RS-485 с Modbus даёт полноценный обмен, но работает по опросной модели. Чем больше узлов на шине, тем больше время цикла. Нужно отдельное питание, критичны топология и согласование линии. Для интеграции с ИТ-инфраструктурой требуются шлюзы, а это дополнительные уровни преобразования и потенциальные точки отказа.</p> <p>Классический Ethernet быстр и имеет нативную IP-адресацию. Но на полевом уровне он ограничен дистанцией 100 метров и четырьмя парами проводов. На распределённых объектах приходится строить промежуточную инфраструктуру: коммутаторы, медиаконвертеры, шкафы, что увеличивает капитальные и эксплуатационные затраты.</p> <p>Вывод прост. Традиционные интерфейсы решали задачи своего времени, но сегодня они ограничивают объём данных, диагностику и сквозную интеграцию. Аналоговая петля и HART не дают нужного количества информации. RS-485 плохо масштабируется и требует шлюзов. Классический Ethernet не подходит для распределённых объектов без промежуточной инфраструктуры.</p> <h3>Сквозной Ethernet по двум проводам</h3> <p>Интерфейс Single Pair Ethernet (SPE) устраняет вышеперечисленные ограничения архитектурно. Технология базируется на стандарте 10BASE-T1L (IEEE 802.3cg-2019) и предлагает передачу данных со скоростью до 10 Мбит/с по одной витой паре, питание устройства по той же паре (PoDL) мощностью до 50 Вт и дальность связи до 1 километра без промежуточных повторителей.</p> <p>Таким образом, SPE делает Ethernet по-настоящему сквозным: от облачного сервера или локальной SCADA до отдельного датчика на дальнем участке трубопровода. Каждый прибор получает собственный IP-адрес и может напрямую поддерживать OPC UA, MQTT, предоставлять веб-интерфейс для настройки и диагностики. Это уже не пассивный источник сигнала, а активный сетевой узел.</p> <p>Переход на SPE — это не замена физического уровня, а изменение архитектурной роли полевого устройства. Датчик перестаёт быть пассивным источником скалярного сигнала и становится активным сетевым узлом, обладающим собственным IP-адресом, вычислительными ресурсами и информационной моделью. SPE-датчик позволяет отслеживать предотказовые состояния: снижение точности чувствительного элемента, рост внутренней температуры, ухудшение изоляции линии, увеличение джиттера, накопление ошибок CRC. Это соответствует концепции RCM (Reliability-Centered Maintenance) и позволяет реализовать стратегию предиктивного обслуживания.</p> <p>#IMAGE_235801#</p> <p>С точки зрения информационной архитектуры SPE устраняет разрыв между OT (Operational Technology) и ИТ. Датчик становится полноценным участником сети TCP/IP, что позволяет интегрировать его в корпоративные системы мониторинга без промежуточных шлюзов. Уменьшается количество уровней преобразования, снижается задержка, повышается достоверность данных.</p> <p>Отмечу, что базовый SPE не обеспечивает искробезопасность, что ограничивает его применение в нефтегазовой, химической и горнодобывающей отраслях. Стандарт Ethernet-APL (Ethernet Advanced Physical Layer) решает эту задачу путём ограничения энергии в линии до безопасного уровня. Технически это реализуется через барьеры искрозащиты и специальные требования к кабельным линиям. Ethernet-APL сохраняет все преимущества SPE: дальность до 1000 метров, скорость 10 Мбит/с, питание по линии, IP-адресацию. Это делает цифровой полевой уровень универсальным для всей промышленности.</p> <h3>Поэтапная модернизация и преодоление цифрового разрыва</h3> <p>Переход на SPE не означает обязательную полную замену действующей АСУ ТП. Для российских предприятий, где одновременно работает оборудование разных поколений, реалистичнее поэтапная модернизация с сохранением совместимости с существующей инфраструктурой. Я рассматриваю цифровую трансформацию как последовательное построение сквозной инфраструктуры данных, где идти нужно снизу вверх.</p> <p>На первом этапе важно обеспечить достоверный автоматизированный сбор параметров. Это могут быть изначально цифровые каналы или оцифровка существующих аналоговых сигналов. Далее сформировать инфраструктуру передачи данных, которая позволит объединять участки и масштабировать систему. Следующий уровень — единая точка сбора, хранения и визуализации: контроллер, SCADA или другая система верхнего уровня. И уже на накопленной качественной информации можно строить предиктивную аналитику, цифровые модели и более сложные сервисы.</p> <p>Такой подход снижает риск цифрового разрыва между крупными и небольшими предприятиями. Размер компании перестаёт быть абсолютным ограничением, потому что различаться будут только масштаб и скорость трансформации. Для крупного предприятия это может быть единая корпоративная программа, для небольшого производства — несколько последовательных проектов с заранее определённым результатом.</p> <p>Принципиально важно, чтобы каждый следующий проект не становился очередным изолированным «островком автоматизации», а развивал общую архитектуру. Именно поэтому при выборе решений важны не только начальная стоимость, но и совместимость с действующей инфраструктурой, открытость интерфейсов и возможность дальнейшего масштабирования.</p> <p>#IMAGE_235800#</p> Промышленная автоматизация долгое время строилась по принципу разделения уровней. На полевом уровне датчики … article Ярослав Лоскутов, менеджер продукта направления “Датчики давления” компании ОВЕН https://www.itweek.ru/themes/detail.php?ID=235796 Fri, 23 Oct 2026 09:47:34 +0300 <p>Еще недавно корпоративный ИИ обсуждали через сценарии: где он заменит ручной труд, как ускорит аналитику, какие процессы можно отдать моделям. Теперь разговор быстро смещается в более приземленную плоскость: где взять вычислительные мощности и сколько они будут стоить через месяц. По данным <a href="https://www.kommersant.ru/doc/8711218">«Коммерсанта»</a>, средняя месячная стоимость выделенной инфраструктуры с GPU-ускорителями для задач ИИ и машинного обучения за пять месяцев 2026 года выросла на 64% год к году и достигла 2,3 млн. рублей. Годом ранее показатель составлял около 1,4 млн. рублей. Уже 33% заказов на GPU-серверы приходится на ИИ и ML, еще значительная часть спроса связана с рендерингом, разработкой и обработкой данных.</p> <p>Это важный сдвиг для рынка. Компании переходят от пилотов к промышленному использованию ИИ, а значит им нужны не абстрактные «мощности», а конкретные GPU-конфигурации: с ускорителями, памятью, питанием, охлаждением, понятной логистикой и сроками поставки. Чем сложнее становятся задачи, тем быстрее растет цена входа. На практике это уже видно в расчетах проектов. Если месяц назад одна высокопроизводительная видеокарта могла стоить условные $50 тыс., то через несколько недель цена способна вырасти до $75 тыс. И это не весь сервер, а только один из его ключевых компонентов. В одной конфигурации таких карт может быть несколько, поэтому итоговый бюджет меняется не на проценты, а сразу на миллионы рублей.</p> <h3>Почему спрос обгоняет поставки</h3> <p>Причина не только в том, что компаний, которые хотят использовать ИИ, стало больше. Сильно изменился сам характер задач. Раньше многие проекты оставались на уровне тестов: проверить гипотезу, обучить небольшую модель, запустить пилот на ограниченном наборе данных. Теперь бизнес чаще приходит к промышленным сценариям, где модель должна работать стабильно, быстро обрабатывать большие объемы данных и выдерживать постоянную нагрузку.</p> <p>Для таких задач обычной серверной инфраструктуры уже недостаточно. Нужны GPU-серверы с мощными ускорителями, большим объемом видеопамяти, быстрым обменом данными между картами, правильным охлаждением и запасом по электропитанию. Чем тяжелее модель и чем больше данных проходит через систему, тем выше требования к конфигурации.</p> <p>Здесь и появляется узкое место. GPU-ускорители нужны всем одновременно: облачным провайдерам, крупным промышленным компаниям, банкам, разработчикам ИИ-сервисов, научным центрам, производственным предприятиям. Спрос растет глобально, а число производителей таких компонентов ограничено. Быстро нарастить выпуск нельзя: это сложное производство, завязанное на передовые техпроцессы, память, платы, цепочки поставок и сборку.</p> <p>Поэтому рынок GPU-серверов отличается от обычной закупки оборудования. Компания покупает не просто сервер, который можно быстро заменить аналогом. Она покупает дефицитный вычислительный ресурс, вокруг которого затем строится вся ИИ-инфраструктура: обучение, дообучение, запуск моделей, хранение данных, сеть, питание и охлаждение. Чем позже начинается проектирование такой архитектуры, тем выше риск, что нужная конфигурация станет дороже или уйдет в более длинные сроки поставки.</p> <h3>Почему GPU-серверы дорожают быстрее обычного оборудования</h3> <p>У GPU-серверов другая экономика. В обычном сервере стоимость распределена между процессором, памятью, дисками, платой, корпусом, блоками питания. В сервере под ИИ большую часть цены могут формировать ускорители. Одна карта стоит как отдельный сервер, а в рабочей конфигурации таких карт может быть несколько.</p> <p>Поэтому рост цены на один компонент сразу меняет бюджет всего проекта. Если видеокарта за месяц дорожает с $50 тыс. до $75 тыс., компания получает не небольшую корректировку сметы, а новый финансовый расчет. Для конфигурации на четыре или восемь ускорителей разница становится слишком заметной, чтобы ее можно было закрыть внутри прежнего бюджета.</p> <p>Есть еще одна неприятная деталь: коммерческое предложение в таких проектах быстро устаревает. Пока компания согласует закупку, уточняет архитектуру, проверяет лимиты и проходит внутренние процедуры, цена может измениться. Иногда меняется и срок поставки, потому что нужная партия уже ушла другому покупателю или поставщик пересобрал условия.</p> <p>На этом фоне привычная логика «подождем, рынок остынет» работает плохо. GPU-ускорители дорожают не из-за разового всплеска интереса, а из-за одновременного давления с нескольких сторон: промышленное внедрение ИИ, рост облаков, дефицит производственных мощностей, подорожание памяти и более сложная логистика. Пока эти факторы сохраняются, ждать резкого отката цен рискованно.</p> <h3>Кому GPU-мощности нужны в первую очередь</h3> <p>Первыми дефицит чувствуют компании, у которых ИИ уже вышел за рамки эксперимента.</p> <p>Это банки, промышленные предприятия, телеком, ритейл, разработчики ИИ-сервисов, научные и инженерные центры. Им нужны мощности не для демонстрации возможностей модели, а для рабочих процессов: анализа больших массивов данных, компьютерного зрения, прогнозирования, обработки документов, инженерных расчетов, цифровых двойников, контроля качества на производстве. В таких сценариях система должна работать регулярно, с понятной скоростью и предсказуемым результатом.</p> <p>Отдельная история, крупные инфраструктурные и промышленные проекты. Там вычисления нужны еще до запуска объекта: рассчитать конструкцию, смоделировать нагрузки, проверить варианты проектных решений, обработать данные с датчиков и геоинформационных систем. Чем сложнее объект, тем выше требования к вычислительной базе.</p> <p>Есть и регуляторный слой. Если компания работает с чувствительными данными, КИИ или государственными проектами, ей не всегда подходит внешняя инфраструктура. Часть нагрузок приходится держать в собственном контуре или в среде, где понятны юрисдикция, требования к хранению данных и ответственность за доступ.</p> <p>Поэтому спрос на GPU-серверы растет не как модная закупка «под ИИ». Он растет из практической потребности: бизнес хочет запускать модели в работу, а для этого ему нужна инфраструктура, которую нельзя заменить презентацией, пилотом или обещанием «докупить позже».</p> <h3>Свой контур или аренда: где запускать нагрузку</h3> <p>Когда GPU-мощности становятся частью рабочих процесса, следующий вопрос возникает почти сразу: где все это размещать. Купить собственный сервер, арендовать выделенную конфигурацию или уйти в облако?</p> <p>Для пилотов облако выглядит естественным первым шагом. Компания может быстро проверить гипотезу, понять требования модели к видеопамяти, оценить скорость обработки данных и не покупать дорогое оборудование до того, как сценарий доказал пользу. Это удобно, когда нагрузка нерегулярная: сегодня нужно обучить модель или протестировать прототип, а завтра вычисления почти не используются.</p> <p>Но по мере взросления проекта логика меняется. Если модель работает постоянно, обрабатывает большие объемы данных и встроена в производственный или клиентский процесс, аренда перестает быть просто удобной. Она становится регулярной статьей расходов, причем с теми же рыночными рисками: стоимость GPU-мощностей растет, доступные конфигурации ограничены, а тяжелые ресурсы могут быть заняты.</p> <p>Собственный контур чаще выбирают там, где важны предсказуемость и контроль. Например, если компания работает с чувствительными данными, промышленными системами, КИИ, внутренними документами, инженерными расчетами или клиентской информацией. В таких случаях вопрос не сводится к цене сервера. Важно понимать, где находятся данные, кто имеет доступ к инфраструктуре, как устроены резервирование, обслуживание, обновления и защита.</p> <p>При этом собственная инфраструктура тоже не универсальный ответ. Ее нужно проектировать заранее: считать питание, охлаждение, место в стойках, сеть, хранение данных, отказоустойчивость. GPU-сервер сам по себе не решает задачу, если вокруг него нет среды, в которой модель сможет стабильно работать.</p> <p>Поэтому рынок приходит к более сложной картине. Одни нагрузки остаются в облаке, другие переносятся в собственный контур, третьи требуют промежуточного варианта: локальной или суверенной облачной инфраструктуры с понятной юрисдикцией. И именно здесь тема GPU-мощностей начинает пересекаться с другим трендом, который быстро набирает вес, с геопатриацией данных и приложений.</p> <h3>Геопатриация: почему важна не только цена GPU</h3> <p>Вопрос размещения ИИ-нагрузок уже не сводится к выбору между «купить сервер» и «арендовать мощности». На него все сильнее влияет то, где физически находятся данные, кто управляет инфраструктурой, какие законы действуют на площадке и что произойдет, если доступ к внешнему сервису станет ограниченным. Gartner <a href="https://www.gartner.com/en/articles/top-technology-trends-2026">называет </a>этот тренд геопатриацией: компании переносят данные и приложения из глобальных публичных облаков в локальные варианты, включая суверенные облака, региональных провайдеров и собственные ЦОДы. По прогнозу аналитиков, к 2030 году более 75% компаний Европы и Ближнего Востока переведут виртуальные нагрузки в решения, которые снижают геополитические риски. Для российского рынка это усиливает спрос не просто на GPU, а на управляемую инфраструктуру под ИИ. Компаниям нужно понимать, где будут храниться данные, как соблюдаются требования регуляторов и можно ли сохранить контроль над критическими нагрузками, не теряя доступ к вычислительным ресурсам.</p> <h3>Чек-лист: что проверить до закупки GPU-инфраструктуры</h3> <p>Перед закупкой GPU-инфраструктуры важно зафиксировать не только бюджет, но и саму задачу. Иначе компания рискует купить дорогую конфигурацию, которая не подходит под реальную нагрузку или быстро упрется в ограничения по питанию, охлаждению и обслуживанию.</p> <ul> <li> <strong>Сценарий использования.</strong> Нужно заранее понять, для чего нужны мощности: обучение модели, дообучение, инференс, компьютерное зрение, инженерные расчеты, аналитика или несколько задач сразу.</li> <li><strong> Объем видеопамяти.</strong> Для одних сценариев достаточно более простой конфигурации, для других критичен объем памяти на каждой карте. Это влияет и на производительность, и на стоимость.</li> <li><strong> Количество GPU.</strong> Важно считать не «сервер вообще», а конфигурацию под нагрузку: две, четыре, шесть или восемь карт дают разную цену, энергопотребление и требования к охлаждению.</li> <li><strong> Питание и охлаждение.</strong> GPU-сервер нельзя просто поставить вместо обычного. Нужно проверить стойки, электропитание, тепловыделение, кондиционирование и готовность площадки к постоянной высокой нагрузке.</li> <li><strong> Сроки поставки и срок действия цены.</strong> Для таких проектов коммерческое предложение быстро теряет актуальность. Лучше сразу уточнять, сколько действует цена и что произойдет, если поставка сдвинется.</li> <li> <strong>Происхождение оборудования.</strong> Нужно понимать, по каким каналам приходит оборудование, можно ли подтвердить его характеристики и соответствует ли оно заявленной конфигурации.</li> <li><strong> Новое или восстановленное.</strong> Восстановленное оборудование может быть рабочим вариантом только тогда, когда компания осознанно соглашается на этот риск и видит это в документах. Подмена нового оборудования восстановленным, это уже не экономия, а проблема.</li> <li><strong> Гарантия и ЗИП.</strong> В GPU-проектах отказ одной карты может остановить критичную нагрузку. Поэтому заранее нужны условия гарантии, доступность запасных компонентов и понятный порядок замены.</li> <li><strong> Возможность масштабирования.</strong> Если ИИ-проект пойдет в промышленную эксплуатацию, нагрузка почти наверняка вырастет. Лучше сразу проверить, можно ли расширить конфигурацию без полной перестройки инфраструктуры.</li> </ul> <h3>Заключение: почему откладывать закупку может быть дороже</h3> <p>Не каждый ИИ-проект требует мощностей GPU-сервера. Если сценарий еще не подтвержден, данные не подготовлены, а нагрузка непонятна, логичнее начать с тестов и расчетов. Ошибка здесь может стоить дорого: мощная конфигурация без понятной задачи быстро превращается в дорогой простаивающий ресурс. Но если сценарий уже определен, нагрузка посчитана, а инфраструктурные требования понятны, затягивать с решением становится рискованно. Рынок GPU-серверов сейчас живет в условиях дефицита: ускорители дорожают, сроки поставки меняются, а доступные конфигурации разбирают быстрее, чем компании проходят внутренние согласования.</p> <p>Поэтому главный вопрос для бизнеса звучит не как «покупать или подождать», а как «готова ли компания уже сейчас зафиксировать архитектуру, бюджет и сроки». Если ответ положительный, ожидание может не снизить расходы, а увеличить их. В ближайшее время GPU-инфраструктура останется одним из самых дорогих и ограниченных ресурсов для внедрения ИИ, и это стоит учитывать до того, как проект перейдет из обсуждения в срочную закупку.</p> <p> #IMAGE_235797#</p> Еще недавно корпоративный ИИ обсуждали через сценарии: где он заменит ручной труд, как ускорит аналитику, какие … article Мария Соловьева, руководитель направления серверной инфраструктуры и систем хранения данных компании ”ГИГАНТ — Компьютерные системы” https://www.itweek.ru/themes/detail.php?ID=235810 Thu, 22 Oct 2026 00:00:00 +0300 <p>Компания «Шаркс ДЦ» — вендор инфраструктурного программного обеспечения и компания «ЕСМ-Консалтинг», разработчик платформы цифровых архивов, расширяют технологический стек совместимых продуктов и официально объявляют о завершении цикла испытаний и подтверждении полной технологической совместимости своих решений — Sharx Base и М1:Архив.</p> <p>Связка М1:Архив и система серверной виртуализации Sharx Base закрывает актуальную потребность рынка в защищенной и масштабируемой платформе для работы с электронными документами.</p> <p><strong>Ключевые преимущества совместного решения:</strong></p> <ul> <li> <strong>Мультисервисная архитектура и катастрофоустойчивость.</strong> Платформа М1:Архив обладает распределенной архитектурой, которая позволяет масштабировать серверную часть, в том числе на несколько территориально распределенных центров обработки данных (ЦОДов). Развертывание платформы на базе Sharx Base обеспечивает гибкое управление вычислительными ресурсами и сетевой связанностью между площадками.</li> <li> <strong>Линейная масштабируемость.</strong> Мультисервисная архитектура М1:Архив позволяет увеличивать мощности по мере роста данных, а Sharx Base гарантирует эффективное распределение этих нагрузок на уровне гипервизора виртуализации и программно-определяемой системы хранения.</li> <li><strong>Единый импортонезависимый контур.</strong> Весь жизненный цикл данных, от создания и обработки до долгосрочного хранения, работает в доверенной среде. Оба продукта включены в Единый реестр российского ПО: М1:Архив (реестровый № 11091) и Sharx Base (реестровый № 4445).</li> <li><strong>Оптимизация хранения данных (тиринг).</strong> Ранее была подтверждена совместимость М1:Архив и Sharx Storage (решение для хранения данных с поддержкой S3-протокола). Сертификация М1:Архив с продуктами компании «Шаркс ДЦ» позволяет реализовать многоуровневое хранение. Редко используемые документы можно перемещать на более эффективные по стоимости носители, а оперативные данные остаются на быстрых дисках.</li> </ul> <p>«Подтверждение совместимости с М1:Архив — это важный шаг для расширения сценариев применения нашей платформы в корпоративных и ведомственных инфраструктурах. Использование связки Sharx Base и М1:Архив помогает упростить внедрение архитектур, рассчитанных на длительное хранение и быстрый доступ к документам» — подчеркнул Константин Шамрай, генеральный директор «Шаркс ДЦ».</p> <p>«Технологическая связка М1:Архив и Sharx Base позволяет добиться максимальной плотности размещения данных без потери производительности. Мы минимизируем накладные расходы на аппаратное обеспечение за счет гиперконвергентной системы Sharx Base, теперь заказчики могут более эффективно использовать ее преимущества для реализации оптимального хранения в М1:Архиве» — отметил Игорь Кнышев, технический директор «ЕСМ-Консалтинг».</p> Компания «Шаркс ДЦ» — вендор инфраструктурного программного обеспечения и компания «ЕСМ-Консалтинг», разработчик … message https://www.itweek.ru/themes/detail.php?ID=235794 Thu, 22 Oct 2026 14:48:17 +0300 <p>Российский VAD-дистрибутор ITOREX заключил соглашение с компанией «С-Терра СиЭсПи» и начал поставки ее продуктов для защиты сетевой инфраструктуры.</p> <p>В портфель ITOREX вошли «С-Терра Шлюз» для организации защищенных VPN-соединений, межсетевой экран нового поколения «С-Терра Экран-М», система обнаружения вторжений «С-Терра СОВ» и система управления «С-Терра ГСУ». </p> <p>С-Терра проведет обучение технической команды ITOREX по сценариям применения продуктов и подбору конфигураций. После подготовки специалисты дистрибутора смогут самостоятельно разбирать первичные запросы партнеров. К более сложным задачам будут подключаться эксперты разработчика.</p> <p>«В проектах по защите распределенной инфраструктуры требуется решать сразу несколько связанных задач: защищать каналы связи, контролировать сетевой трафик и выявлять атаки. Соглашение с С-Терра позволяет нам дополнить предложение российскими продуктами для каждого из этих направлений», — прокомментировал Дмитрий Крайненко, директор по работе с вендорами ITOREX.</p> <p>«Соглашение с ITOREX позволит большему числу интеграторов включать продукты С-Терра в проекты уже на этапе проектирования системы защиты. Наибольший потенциал мы видим в регионах, а также в госсекторе и промышленности», — отметил Алексей Трофимов, руководитель отдела по работе с партнерами «С-Терра СиЭсПи».</p> Российский VAD-дистрибутор ITOREX заключил соглашение с компанией «С-Терра СиЭсПи» и начал поставки ее продуктов … message https://www.itweek.ru/themes/detail.php?ID=235793 Thu, 22 Oct 2026 14:47:08 +0300 <p>POWERCOM, международный разработчик и производитель источников бесперебойного питания, объявил о масштабном обновлении ассортимента однофазных ИБП. Компания выпустила пять новых серий: Raptor Plus, Raptor Plus LCD, FLY, Macan Plus и Spider, которые получили улучшенные технические характеристики, повышенную мощность и расширенный функционал при сохранении конкурентной стоимости.</p> <p>Ранее POWERCOM уже анонсировал выпуск ИБП Raptor Plus, Raptor Plus LCD и FLY, финальным аккордом масштабного обновления стал выпуск серий Macan Plus и Spider. Эти две линейки полностью закрывают потребности бизнеса любого масштаба: от комплексной защиты серверного оборудования и дата-центров (ЦОД) до обеспечения стабильного питания отдельных рабочих мест в офисе.</p> <p>Серия Macan Plus выполнена по онлайн-топологии с двойным преобразованием напряжения и выходным коэффициентом мощности PF=1. На корпусе — ЖК-дисплей. В серию входят восемь моделей:</p> <ul> <li>четыре модели с евророзетками мощностью 1000, 1500, 2000 и 3000 ВА;</li> <li>четыре модели с розетками IEC аналогичной мощности.</li> </ul> <p>ИБП Macan Plus рассчитаны на технику, для которой сбой питания обходится дороже всего: серверы, оборудование центров обработки данных, компьютеры высокого класса. Они защищают от перегрузок и короткого замыкания, понижения и повышения напряжения, а также полного его пропадания в электросети. Преимущества серии:</p> <ul> <li>двойное преобразование — подключенное оборудование получает стабильное напряжение независимо от качества сети, а переход на батареи проходит без разрыва питания;</li> <li>выходной коэффициент мощности PF=1 — активная мощность равна полной: модель на 3000 ВА отдает нагрузке до 3000 Вт;</li> <li>широкий диапазон входного напряжения <nobr>120–276 В —</nobr> ИБП реже переходит на батареи при сильных просадках и скачках в сети;</li> <li>быстрая зарядка батарей — до 90% емкости за 4 часа;</li> <li>режим высокой эффективности — при стабильной сети ИБП расходует меньше электроэнергии и меньше греется;</li> <li>ЖК-дисплей — параметры работы ИБП видны сразу, без подключения к компьютеру;</li> <li>современный дизайн корпуса.</li> </ul> <p>Spider — <nobr>8-розеточный</nobr> ИБП линейно-интерактивной топологии с возможностью настенного монтажа. Модели оснащены светодиодной индикацией и цифровым дисплеем. В серию входят четыре модели мощностью 550, 750, 900 и 1100 ВА.</p> <p>ИБП защищают компьютер, рабочую станцию, модем, роутер, сетевое хранилище данных и другое коммуникационное оборудование, а также серверы с импульсными блоками питания. Восемь розеток позволяют подключить к одному ИБП весь комплект техники на рабочем месте. Преимущества серии:</p> <ul> <li>четыре евророзетки с батарейной поддержкой и четыре евророзетки с фильтрацией;</li> <li>работа без задействования батареи даже при 140 В;</li> <li>функция Green Mode (сбережение энергии) — ИБП автоматически отключается, если подключенное оборудование потребляет мало энергии или не подключено вовсе. Так экономятся заряд аккумуляторов и электроэнергия;</li> <li>функция Cold Start («холодный старт») — ИБП можно включить и питать подключенное оборудование при полном отсутствии напряжения во внешней сети;</li> <li>защита телефона, факса, модема и локальной сети, EMI/RFI-фильтрация;</li> <li>USB-порт для связи с ПК;</li> <li>возможность настенного монтажа.</li> </ul> <p>Выпуск новых серий однофазных ИБП завершает масштабное обновление однофазных решений POWERCOM и предлагает бизнесу современные, отказоустойчивые инструменты для защиты электрооборудования различного уровня сложности. Новые модели уже доступны для заказа у официальных дистрибьюторов.</p> POWERCOM, международный разработчик и производитель источников бесперебойного питания, объявил о масштабном обновлении … message https://www.itweek.ru/themes/detail.php?ID=235792 Thu, 22 Oct 2026 14:43:35 +0300 <p>ГК «Аквариус» объявила о выводе на рынок Wi-Fi оборудования и программного обеспечения (ПО) для создания решения по построению корпоративных беспроводных сетей передачи данных. Решение включает в себя ПО контроллера беспроводной сети Aquarius Wireless LAN Controller (AQ-WLC) и точки доступа Aquarius серии AQ-W6.</p> <p>ПО контроллера и точки доступа внесены в соответствующие реестры Министерства цифрового развития, связи и массовых коммуникаций и Министерства промышленности и торговли Российской Федерации, что подтверждает их российское происхождение и открывает заказчикам доступ к применению на регулируемом рынке.</p> <p>Линейка точек доступа серии AQ-W6 представлена моделями, работающими в стандартах Wi-Fi 6 и Wi-Fi 6E. </p> <p>Точки доступа с поддержкой Wi-Fi 6E рассчитаны на объекты с высокой плотностью пользователей — кампусы, конференц-залы, медицинские центры, производственные корпуса. Диапазон 6 ГГц, в отличие от традиционных 2,4 ГГц и 5 ГГц, практически свободен от помех со стороны бытовых устройств, что обеспечивает стабильную работу при большом количестве одновременных подключений. </p> <p>Совокупная пропускная способность таких точек доступа достигает 8353 Мбит/с, что позволяет работать с потоковым видео сверхвысокой четкости, большими массивами данных и критически важными сервисами.</p> <p>Точки доступа серии AQ-W6 моделей AQ-W6P201I, AQ-W6P301I, AQ-W6P301E, AQ-W6P301C, AQ-W6PE401I, AQ-W6PE401E, AQ-W6PE401C, AQ-W6PE101I, AQ-W6P101I предназначены для установки в офисных и административных зданиях. Модель AQ-W6O202E в защищенном корпусе класса IP67, сохраняющая работоспособность при перепадах температур, высокой влажности, осадках и запыленности, позволяет строить беспроводную сеть передачи данных на открытых территориях, парковках, складских и логистических комплексах. </p> <p>Точки доступа работают под управлением контроллера беспроводной сети AQ-WLC, который обеспечивает централизованное управление всей инфраструктурой: автоматически настраивает радиоканалы и распределяет нагрузку между точками доступа. Контроллер интегрируется с корпоративными системами авторизации, что позволяет использовать единые учетные данные и политики доступа.</p> <p>Контроллер поддерживает до 5000 точек доступа Aquarius серии AQ-W6 и до 32000 одновременно подключенных клиентских устройств. Его возможности включают современные стандарты безопасности, управление роумингом по стандартам 802.11r/v/k, управление радиоресурсами (Radio Resource Management, RRM), отказоустойчивость 1:1 Hot Standby, а также гибкость настройки и вариативность установки.</p> <p>«Вывод на рынок Wi-Fi оборудования корпоративного уровня открывает новый этап в развитии телекоммуникационного направления „Аквариуса“. Контроллер AQ-WLC и точки доступа серии AQ-W6 позволяют решить задачу любого масштаба — от компактного офиса до производственных площадок. Мы сделали акцент на производительности, отказоустойчивости и эффективности управления. Используя наше решение, заказчики получат беспроводную сеть, которая работает стабильно и не требует компромиссов между масштабом, надежностью и удобством эксплуатации», — прокомментировал Артем Дрожжин, директор бизнес-юнита «Телекоммуникационные решения» компании «Аквариус».</p> ГК «Аквариус» объявила о выводе на рынок Wi-Fi оборудования и программного обеспечения (ПО) для создания … message https://www.itweek.ru/themes/detail.php?ID=235790 Thu, 22 Oct 2026 12:31:03 +0300 <p>Формулу «кто не внедрит искусственный интеллект, тот умрет» уверенно повторяют со сцен бизнес-конференций уже несколько лет. Но статистика показывает, что ИИ в работе применяет примерно каждая двадцатая крупная и средняя организация страны, и остальные девятнадцать с рынка никуда не делись. Вымирания отстающих в этих цифрах пока не видно. Различия между компаниями при этом растут: сильные специалисты постепенно переходят туда, где ИИ уже внедрен, и следом, с высокой вероятностью, туда же уйдут клиенты и выручка.</p> <p>Обсудим, кто не внедряет ИИ и почему, что происходит с такими компаниями и кому откладывать внедрение рискованно.</p> <h3>Девятнадцать из двадцати работают без ИИ</h3> <p>Технологии ИИ <a href="https://issek.hse.ru/news/1139129178.html">используют</a> 4,8% крупных и средних российских организаций. Среди организаций, где работает больше 500 человек, ИИ применяют 14,9%, а среди тех, где заняты 100 человек и меньше, 4,1%, то есть в 3,6 раза реже. Внедрение ИИ в малых предприятиях изучить сложнее, поэтому по экономике в целом разрыв, скорее всего, еще больше.</p> <p>В Евросоюзе доля выше при похожей структуре. В 2025 году ИИ <a href="https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Use_of_artificial_intelligence_in_enterprises">использовали</a> 20% предприятий с численностью от десяти человек против 13,5% годом раньше. Среди крупных компаний от 250 человек, доля составила 55%, среди малых предприятий до 50 человек — 17%. По отраслям расхождение еще сильнее: в ИТ-сфере ИИ используют 62,5% предприятий, в строительстве — 10,8%.</p> <p>Рост идет быстро и неравномерно. Внедряют эти технологии в первую очередь крупные компании и те, кто работает с информацией, а низкая доля держится в строительстве, на транспорте и в общепите, и таких компаний в экономике большинство. Гибели отстающих в этих цифрах пока не видно, однако отчетливо видно расслоение по размеру и отрасли.</p> <h3>Три причины, по которым компании не внедряют ИИ</h3> <p>Первая группа <strong>отказывается от ИИ сознательно</strong>, чаще по инициативе (или точнее сказать ее отсутствию) сотрудников. Недавно проведенный опрос, который охватил 23,7 тыс. работающих американцев, в компаниях которых ИИ внедрен, показал, что 46% <a href="https://www.gallup.com/workplace/704252/workplace-separates-adopters-holdouts.aspx">предпочитают</a> работать привычным способом и 43% отказываются по этическим соображениям.</p> <p>Вторая группа<strong> не внедряет ИИ ввиду ограничений и правил безопасности</strong>. Госсектор, оборонная промышленность и любая компания с закрытым контуром передать эти данные внешнему ИИ-сервису не могут. Среди европейских предприятий, которые рассматривали ИИ и отказались от этой идеи, 52,5% <a href="https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Use_of_artificial_intelligence_in_enterprises">назвали</a> причиной непрозрачные правовые последствия и 48,8% — защиту данных. Чаще всего, в 70,9% случаев, компании ссылаются на нехватку собственных компетенций в этой области.</p> <p>Третья группа <strong>не видит для ИИ задачи</strong>. В пекарне, автосервисе или небольшом производстве узкое место находится у печи и у рук мастера, а тексты и таблицы занимают небольшую часть времени. Об отсутствии потребности в технологиях ИИ <a href="https://issek.hse.ru/news/1083541394.html">заявили</a> 48% крупных и средних российских организаций, и это компании с собственной бухгалтерией и отделом продаж, а у домашней пекарни таких задач еще меньше. Удешевление инструментов картину почти не меняет, потому что доля операционных задач в выручке пекарни от цены ИИ не зависит.</p> <h3>Теневое использование ИИ</h3> <p>Запреты не всегда работают так, как написано в регламенте. Там, где ИИ запрещен на бумаге и при этом результат требуют к завтрашнему дню, сотрудники находят обход, обычно через личный аккаунт ИИ-сервиса. По результатам крупного международного исследования исследования, почти половина сотрудников, работающих с ИИ, <a href="https://kpmg.com/xx/en/media/press-releases/2025/04/trust-of-ai-remains-a-critical-challenge.html">делает</a> это вопреки правилам своей компании, включая загрузку рабочих данных в публичные сервисы, и 57% скрывают использование или выдают результат за собственный.</p> <p>В России картина похожая. Использование ИИ от руководства <a href="https://incrussia.ru/news/opros-pokazal-chto-kazhdyj-tretij-rossiyanin-skryvaet-ispolzovanie-ii-ot-rabotodatelya/">скрывают</a> 35% работников, чаще всего это молодые специалисты, которые опасаются, что признание сочтут признаком некомпетентности.</p> <p>Официальная статистика и опросы сотрудников расходятся, потому что измеряют разное. Росстат считает организации, где ИИ внедрен как технология по решению руководства, опросы показывают реальный факт использования. Судя по данным опросов, ИИ работает и во многих из тех девятнадцати компаний, которые в статистику не попали, силами сотрудников и без ведома службы безопасности.</p> <h3>Что стало с компаниями, которые не вышли в интернет</h3> <p>Ни одна технологическая волна не заканчивалась стопроцентным охватом. Сайт в 2025 году <a href="https://ec.europa.eu/eurostat/statistics-explained/index.php?title=E-business_integration">был</a> у 79% предприятий Евросоюза с численностью от десяти человек, системы управления ресурсами использовали 46%. Интернету в бизнесе около тридцати лет, и каждое пятое предприятие до сих пор обходится без сайта.</p> <p>Предприятия без сайта потеряли долю рынка, но сам рынок у них остался, потому что хлеб выбирают по хлебу, а машину чинят у того, кто чинит машины. Ниша сужается там, где конкурент с помощью ИИ закрывает ту же потребность клиента дешевле, и это условие проверяется по каждой компании отдельно.</p> <p>Что именно произойдет с теми, кто не внедрил ИИ, посчитать пока нельзя, потому что таких расчетов нет ни у сторонников вымирания, ни у их оппонентов. Есть замеры по тем, кто внедрил. Экономисты связали опросы 25 тыс. работников из 7 тыс. предприятий Дании с административными данными о занятости и <a href="https://www.nber.org/papers/w33777">не нашли</a> значимого эффекта от использования ИИ-моделей на выручку и эффективность труда через два года после появления ChatGPT, с точностью, исключающей эффект больше 2%. Экономия времени по оценке самих пользователей составила около 3%. Единственный эффект, подтвержденный в рамках исследования — освоившие ИИ переходят в профессии, где он полезнее и где больше платят, но их пока слишком мало, чтобы это отразилось на средних заработках.</p> <p>Датские данные описывают массовое внедрение ИИ-моделей для побочных задач, и нулевой результат для такого сценария закономерен, потому что выгода появляется там, где компания закрывает с помощью ИИ узкое место, а три процента рабочего времени такой выгоды не дают. Судьбу не внедривших компаний считать рано, потому что измеримый разрыв не возник даже там, где ИИ внедрило большинство.</p> <h3>Кому внедрять все-таки нужно</h3> <p>Отраслевой список здесь не работает, потому что внутри одной отрасли компании находятся в разном положении. Вместо списка компания должна ответить себе на три вопроса:</p> <ol> <li><strong>Где находится узкое место? </strong>Если это интеллектуальная рутина — тексты, код, поддержка клиентов— компания может решить эти задачи ее с помощью ИИ, и внедрять его нужно сейчас. Если узкое место у печи, станка или лицензии, внедрение принесет издержки без преимущества. </li> <li><strong>Сможет ли конкурент с помощью ИИ делать то же самое дешевле и в большем объеме? </strong>Если сможет, времени на ответ остаются месяцы, потому что клиенты быстро уйдут туда, где дешевле. Если конкурент ограничен тем же временем печи и тем же числом мастеров, спешка ничего не дает. </li> <li><strong>Запрет идет от закона или от политики самой компании? </strong>Если от закона, остаются два варианта: развернуть модель на своих серверах внутри контура или честно не внедрять. Если от политики: теневое внедрение уже идет, и выбор здесь только между управляемым и неуправляемым. Выдать сотрудникам разрешенный инструмент будет дешевле, чем узнать о об использовании постфактум.</li> </ol> <p>Ответы на эти вопросы стоит записать и пересматривать раз в год, потому что за год меняются и цена инструментов, и само узкое место. Пекарню такой пересмотр, скорее всего, не сдвинет, а компанию на границе между группами он сдвинуть может.</p> <p> #IMAGE_235791#</p> Формулу «кто не внедрит искусственный интеллект, тот умрет» уверенно повторяют со сцен бизнес-конференций уже несколько … article Олег Строкатый, руководитель направления контроля качества ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=235788 Thu, 22 Oct 2026 12:20:41 +0300 <p>Датчик зафиксировал отклонение, система мониторинга вывела предупреждение на дашборд, но ремонтная служба узнала о неисправности только после остановки оборудования. Такая ситуация возможна даже на предприятии с развитой ИТ-инфраструктурой. Информация доступна, однако ее передачу исполнителю по-прежнему обеспечивает человек. Опираясь на свой профессиональный опыт, я расскажу, как платформенный подход помогает связать обнаружение проблемы с ее устранением и оценить результат в показателях бизнеса.</p> <p>Российские компании уже давно используют ERP, CRM, SCADA, сервис-дески и другие цифровые инструменты. Каждый из них отвечает за определенный участок работы. При этом выполнение одной задачи часто требует участия нескольких подразделений и доступа к разным системам. Чтобы организовать ремонт, нужно проверить историю оборудования, уточнить наличие запчастей, назначить инженера и согласовать время работ. Если эти этапы связаны только перепиской и звонками, скорость процесса зависит от того, как быстро сотрудники передадут друг другу информацию.</p> <p>По мере роста компании такая координация становится сложнее. Появляются новые объекты, подрядчики и приложения, меняются зоны ответственности. Даже небольшая корректировка процесса может потребовать доработки нескольких интеграций. Руководителю все труднее понять, почему работа задерживается: заявку поздно заметили, передали не тому специалисту или оставили без необходимых данных.</p> <p>Я предлагаю оценивать цифровую зрелость компании по тому, насколько последовательно задача проходит весь путь от возникновения до подтвержденного выполнения. Такой взгляд помогает обнаружить потери, которые незаметны в отчетности отдельных подразделений. Например, инженер укладывается в норматив ремонта, но до назначения исполнителя заявка несколько часов ожидает обработки.</p> <p>Платформенный подход позволяет задать общую логику этого пути: событие, правило реакции, задача, ответственный, исполнение и результат. При поступлении сигнала система определяет дальнейшие действия, создает задание и передает его сотруднику вместе с информацией об объекте. Сроки контролируются автоматически. Если исполнитель не принял задачу или не завершил ее вовремя, запускается предусмотренный порядок эскалации. Подтверждение выполненной работы сохраняется в истории объекта.</p> <p>Эту логику можно выстроить с сохранением действующих корпоративных систем. ERP продолжит обеспечивать учет ресурсов, CRM — работу с клиентами, а платформа свяжет необходимые данные и действия между ними. Отдельные приложения при необходимости можно заменить. На производстве управление технологическим процессом и противоаварийная защита сохраняются в соответствующих системах автоматизации.</p> <p>При этом правила работы определяет сама компания. До настройки платформы необходимо договориться, кто отвечает за процесс целиком, какие исключения возможны и по каким признакам задача считается выполненной. Техническая интеграция даст эффект, когда участники одинаково понимают свои обязанности и порядок взаимодействия.</p> <p>Такая задача встречается в разных отраслях. Например, при обслуживании микромаркетов компания привязала заявки и чек-листы к конкретным торговым объектам. Посещения мерчендайзеров стали подтверждать разовыми QR-кодами, расчет заработной платы автоматизировали. Руководители получили возможность сопоставлять присутствие сотрудника с выполненными работами и оценивать качество обслуживания каждой точки.</p> <p>В другом проекте крупный продуктовый ритейлер объединил в одной системе обращения сотрудников из почты, веб-портала и мессенджера. Переписка и сведения, необходимые для решения вопроса, стали доступны в карточке заявки. База знаний помогла сократить повторные уточнения. Показатель контроля исполнения заявок вырос на 98% относительно исходного уровня заказчика, а время на уточнение деталей сократилось на 45%. Потери обращений были исключены.</p> <p>Промышленное предприятие сначала изменило порядок обходов. Оборудование промаркировали NFC-метками, бумажные записи заменили мобильными маршрутами и цифровыми чек-листами. Сведения о дефекте стали поступать в систему непосредственно с места осмотра, с привязкой к конкретному объекту. Проект охватил 1700 единиц оборудования на площади 17 000 м². Время реакции на дефекты сократилось в два-три раза, просрочки их устранения практически исчезли.</p> <p>Производителю пищевой продукции нужно было обеспечить непрерывный температурный контроль подвижного оборудования разных производителей. Специалисты компании подключили к платформе беспроводные датчики, настроили регистрацию инцидентов, уведомления ответственных и контроль устранения нарушений. Мониторинг охватил все оборудование в рамках проекта. Потери продукции из-за нарушения температурного режима при хранении сократились на 90%, среднее время реакции персонала — на 43%. Более 90% таких отклонений система автоматически фиксирует и передает ответственным без участия диспетчера. Устранением неисправностей занимается персонал.</p> <p>Общий механизм этих изменений состоит в том, что сотрудник получает подготовленную задачу в нужный момент, а руководитель видит ее движение и результат. На этой основе можно определить, какие этапы целесообразно дополнительно поручить искусственному интеллекту.</p> <p>Например, сервисная компания организовала на платформе управление инцидентами для 60 клиентов, заменив Jira Service Desk. ИИ классифицирует обращения, проводит первичную оценку и маршрутизирует заявки между командами. В результате проекта время реакции на инциденты сократилось втрое, первичный анализ ускорился в три-четыре раза. Система обрабатывает более 100 заявок в день. Эти показатели отражают эффект всего внедрения, включая изменение процесса обработки обращений.</p> <p>Пользу ИИ я предлагаю оценивать через работу, которую он помогает выполнить. Доступ к истории объекта, предыдущим инцидентам и базе знаний позволяет находить похожие случаи, готовить краткое описание проблемы и предлагать следующий шаг. Качество этой помощи зависит от полноты и актуальности корпоративных данных. Если одно оборудование числится под разными названиями, а результаты ремонтов не фиксируются, возможности анализа будут ограничены.</p> <p>Для самостоятельных действий ИИ заранее задаются полномочия. Классификацию обращения и передачу заявки можно автоматизировать в пределах согласованных правил. Решения, влияющие на технологический процесс, остаются под контролем уполномоченного сотрудника. Платформа должна сохранять права доступа и историю действий, чтобы можно было проверить основания рекомендации и порядок ее исполнения.</p> <p>Выбирать первый процесс для внедрения я рекомендую по пяти шагам:</p> <p>1. Найти повторяющуюся задачу с понятными потерями: простоями, просрочками, повторными выездами или большим объемом ручной координации.</p> <p>2. Проследить передачу информации между участниками и определить этапы, на которых возникают задержки.</p> <p>3. Зафиксировать исходные показатели, целевой результат и источники данных для проверки.</p> <p>4. Провести пилот на одном объекте или в одном подразделении.</p> <p>5. Подтвердить эффект и оценить условия его повторения на других площадках.</p> <p>Измерения стоит разделить на четыре группы. Скорость покажет время от события до регистрации задачи, назначения исполнителя и завершения работы. Надежность — долю просрочек, соблюдение SLA и количество повторных инцидентов. Трудозатраты — сколько часов уходит на диспетчеризацию, согласования и отчетность. Экономика — как изменились стоимость выполнения процесса, потери от простоев, брака и внеплановых ремонтов.</p> <p>После пилота показатели сравнивают при сопоставимом объеме и составе работ, учитывая сезонность и другие изменения на предприятии. Для проверки используют журналы событий, историю заявок, показания датчиков и фактические данные о потерях. В экономический расчет включают расходы на внедрение, интеграции и сопровождение.</p> <p>Перед масштабированием желательно проследить несколько реальных задач от первого сигнала до подтвержденного результата. По каждой должно быть понятно, где сократилось ожидание, какие ручные действия удалось убрать и сколько стоило это изменение. Такая проверка дает предметное основание для решения о дальнейшем развитии платформы.</p> <p> #IMAGE_235789#</p> Датчик зафиксировал отклонение, система мониторинга вывела предупреждение на дашборд, но ремонтная служба узнала … article Иван Лашков, руководитель отдела маркетинга STAQ https://www.itweek.ru/themes/detail.php?ID=235785 Thu, 22 Oct 2026 09:09:02 +0300 <p><em>Стать ИИ-компанией — это не о технологиях. Валид Абу-Хадба, генеральный директор компании Precision, приводит на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>четыре урока лидерства, которые помогут упростить работу и получить реальную ценность для бизнеса.</em></p> <p>Каждая компания находится под давлением, чтобы стать «ИИ-компанией». В течение последних нескольких месяцев мы проводили эту трансформацию в своей органиации, меняя то, как мы строим, работаем и измеряем прогресс.</p> <p>Этот опыт кое-что прояснил для меня: самые сложные этапы становления ИИ-компании относительно мало связаны с технологиями. ИИ может помочь организации двигаться быстрее, автоматизировать работу, увеличить производительность и фундаментально изменить возможности людей. Но ни одна из этих вещей не гарантирует более высокую эффективность бизнеса.</p> <p>Из нашего опыта были извлечены четыре урока лидерства:</p> <ol> <li> Начните с бизнес-цели.</li> <li> Упростите, прежде чем ускориться.</li> <li> Измените то, как работают люди.</li> <li> Измеряйте результаты, которые имеют значение.</li> </ol> <h3> Начните с бизнес-цели </h3> <p>Во-первых, разберитесь, чего пытается достичь бизнес: рост, ускорение инноваций, укрепление отношений с клиентами, улучшение продуктов, увеличение прибыли или что-то еще, что имеет значение для стратегии.</p> <p>ИИ значительно расширяет возможности. Это делает фокусировку критически важной. Руководители должны установить четкие приоритеты: что необходимо улучшить, что организации следует начать делать и, что не менее важно, что ей следует прекратить делать. Эта ясность определит, куда инвестировать, какие процессы изменить и где ИИ может создать наибольшую ценность.</p> <p>Без этого ИИ может увеличить сложность, а не уменьшить ее. Организации могут развертывать больше инструментов, запускать больше агентов и генерировать больше активности без четкой связи с бизнес-результатами, которых они пытаются достичь.</p> <p>Вот почему я считаю ИИ операционной моделью, а не стратегией. Стратегия определяет, куда движется бизнес и почему. ИИ может изменить скорость и эффективность достижения цели.</p> <h3>Упростите, прежде чем ускориться</h3> <p>Как только цель ясна, лидерам необходимо изучить, как выполняется работа. ИИ может заставить практически всё двигаться быстрее. Это и возможность, и проблема.</p> <p>Примените ИИ к процессу, который больше не добавляет ценности, и вы просто заставите плохой процесс работать быстрее. Автоматизируйте один шаг, оставив вокруг него одни и те же ненужные утверждения, передачи, встречи и точки принятия решений, и узкое место переместится из одной точки в другую.</p> <p>Я видел это воочию. Поскольку ИИ ускоряет такие области, как разработка ПО, ограничения часто смещаются на рабочие процессы. Если инженер может генерировать код в четыре раза быстрее, но этот код по-прежнему ожидает в тех же очередях и проходит те же этапы передачи, то организация не создает в четыре раза больше ценности.</p> <p>Развиваться должна вся система.</p> <p>Принцип прост: устраните то, что не добавляет ценности; упростите то, что приносит пользу; затем используйте ИИ для ускорения процесса.</p> <h3>Измените то, как работают люди</h3> <p>Технология сама по себе не трансформирует организацию. Люди должны изменить то, как они работают.</p> <p>Я увидел это в неожиданном месте — нашей летней программе стажировок.</p> <p>Наши стажеры прибыли с разным уровнем опыта работы с ИИ и разными представлениями о том, что это может значить для их карьеры. В течение десяти недель я наблюдал, как меняется их восприятие. Как только они смогли применить ИИ в реальной работе, они начали действовать быстрее, глубже исследовали проблемы и стали более уверены в своих силах.</p> <p>Больше всего меня поразило то, как быстро изменилось их представление о том, на что они способны, и насколько заразительной стала эта уверенность.</p> <p>Этот опыт укрепил то, что, по моему мнению, руководители должны понимать в отношении ИИ: базовые показатели того, чего люди могут достичь, меняются. И это касается далеко не только людей, пополняющих ваш штат.</p> <p>Поскольку ИИ берет на себя больше исполнительской и рутинной работы, у людей на каждом уровне появляется больше возможностей задавать направление, оценивать результаты, решать сложные проблемы, выстраивать отношения и применять суждения и опыт.</p> <p>Это имеет серьезные последствия в плане того, что руководители думают о рабочих местах, навыках и развитии. Предположения, которые мы построили относительно того, как выглядит должностная роль, сколько времени нужно человеку, чтобы стать профессиональным, и какой вклад могут внести люди на разных этапах карьеры, должны будут измениться.</p> <p>Рабочие процессы также должны развиваться. Предоставление сотрудникам доступа к ИИ и отслеживание того, как они им пользуются — это лишь первый шаг. Руководителям необходимо изучить, как должна измениться сама работа: какое место в этом процессе занимает ИИ, что он может взять на себя, где человеческое суждение остается важным и чего люди теперь могут достичь с помощью возможностей, создаваемых ИИ.</p> <p>Наши стажеры дали мне первое представление о том, как это может выглядеть. Задача руководства состоит в том, чтобы создать условия для того, чтобы такой же сдвиг произошел во всей организации.</p> <h3>Оценивайте отдачу для бизнеса</h3> <p>Наконец, руководители должны подходить к измерению прогресса системно и дисциплинированно.</p> <p>В какой-то момент внедрение ИИ стало бизнес-показателем. Организации отслеживают, сколько сотрудников используют ИИ, сколько интеллектуальных агентов развернуто, сколько токенов задействуется.</p> <p>Эти цифры показывают, пользуются ли люди ИИ, но не говорят о том, создает ли он реальную ценность.</p> <p>Мы никогда не измеряли окупаемость инвестиций (ROI) в электронную почту. Мы не следили за тем, насколько активно используются электронные таблицы, и не требовали еженедельных отчетов о количестве документов, созданных в Word. Мы воспринимали эти инструменты как часть инфраструктуры, а оценивали то, что бизнес с их помощью достигает.</p> <p>Внедрение — это лишь начало, а не конечный результат.</p> <p>Повышение продуктивности должно создавать дополнительный потенциал. Этот потенциал позволяет командам работать быстрее, раньше выводить идеи на рынок, уделять больше времени задачам, требующим профессионального суждения и экспертизы, а также улучшать клиентский опыт. В конечном итоге такие достижения должны трансформироваться в рост и более высокие бизнес-показатели.</p> <p>Именно поэтому, на мой взгляд, руководителям стоит рассматривать ИИ как возможность сделать больше, располагая теми же ресурсами, а не как способ сделать больше, сократив их.</p> <p>Если ваша стратегия в области ИИ нацелена на уменьшение численности персонала, вы воспринимаете ИИ лишь как инструмент повышения операционной эффективности. Это может снизить затраты в краткосрочной перспективе, но не создает долгосрочной ценности. Гораздо более значимая возможность заключается в расширении того, чего организация может достичь силами уже имеющихся сотрудников и их компетенций.</p> <h3>Задача для руководителей</h3> <p>Я с оптимизмом смотрю на то, как ИИ изменит работу.</p> <p>Технологии всегда трансформировали деятельность людей и расширяли границы возможного. ИИ придает этому процессу дополнительное ускорение.</p> <p>Однако само по себе наличие технологии еще не обеспечивает конкурентного преимущества.</p> <p>Ключевым фактором успеха станет то, как именно организации ее используют.</p> <p>А значит следует сохранять фокус на бизнес-целях; устранять излишнюю сложность, прежде чем ускорять процессы; перестраивать работу с учетом того, что люди и ИИ могут совершить вместе; и оценивать трансформацию через призму конкретных бизнес-результатов.</p> <p>Истинный показатель эффективности ИИ — это то, что ваш бизнес теперь может делать, хотя раньше это было невозможно.</p> Стать ИИ-компанией — это не о технологиях. Валид Абу-Хадба, генеральный директор компании Precision, приводит … article https://www.itweek.ru/themes/detail.php?ID=235783 Wed, 21 Oct 2026 15:34:02 +0300 <p>Кибериспытания в 2026 году стали одной из наиболее востребованных услуг по информационной безопасности. По оценке специалистов «Кросстех», порядка 80% ИБ-команд заказчиков в полной мере не справляются с противодействием команде атакующих.</p> <p>Неудачей по результатам Red Teaming считается нулевая или околонулевая детектируемость, когда защищающиеся не выявляют активность в инфраструктуре и позволяют пентестерам реализовывать сценарии, приводящие к недопустимым событиям. К признакам неэффективной работы команды защиты также относятся несвоевременное реагирование на инциденты, отсутствие скоординированных действий, а также применение мер реагирования, приводящих к нарушению работы критически важных сервисов. При этом сам факт проникновения не всегда считается неудачей ИБ-команды, так как вредоносные действия могли быть реализованы не из-за ошибок, а из-за архитектурных особенностей инфраструктуры компании.</p> <p>Чаще всего синие команды сталкиваются с трудностями при распознавании скрытых и бесшумных атак с использованием легитимных инструментов. Дополнительные сложности возникают при корреляции событий из большого количества разных источников, из-за ошибок в анализе данных и задержек при выявлении взаимосвязанных действий: защитникам сложно своевременно обнаружить развивающийся инцидент. Еще один вызов для команд — высокая нагрузка на системы мониторинга из-за большого количества ложных срабатываний, на фоне которых реальная угроза может остаться незамеченной.</p> <p>Отдельным вектором атак, который зачастую позволяет красной команде достигать поставленных целей, остается социальная инженерия. ИБ-команда не может вовремя зафиксировать факт компрометации учетных данных на раннем этапе, вследствие чего атакующие получают дополнительное время для развития атаки и продвижения по инфраструктуре.</p> <p>При этом, эксперты по анализу защищенности «Кросстех» указывают, что уровень подготовки ИБ-команд постепенно растет — среди команд, которые проходят повторные кибериспытания, порядка 50% улучшают свои показатели. Это связано как с развитием компетенций специалистов за счет обучения и привлечения новых сотрудников, так и с совершенствованием технических и организационных процессов: настройкой сбора и корреляции событий, расширением покрытия средствами мониторинга и повышением качества выявления атак.</p> <p>«Киберучения и кибериспытания крайне востребованы, потому что помогают увидеть реальный уровень готовности ИБ-команд и эффективности работы системы информационной безопасности у заказчика. Важно понимать, что если синие и допустили проникновение и реализацию недопустимого события, это не означает их полную неготовность к атаке. Важно учитывать, что уровень навыков профессиональных пентестеров значительно выше, чем средний уровень хакеров, особенно в последнее время с учетом снижение порога входа в киберпреступную деятельность из-за искусственного интеллекта и распространения платформ Cybercrime-as-a-Service», — отметила Анастасия Мельникова, руководитель департамента оценки защищенности «Кросстех».</p> Кибериспытания в 2026 году стали одной из наиболее востребованных услуг по информационной безопасности … message https://www.itweek.ru/themes/detail.php?ID=235782 Wed, 21 Oct 2026 15:33:08 +0300 <p>Компания «Хи-Квадрат» реализовала в платформе XSQUARE поддержку СУБД MySQL — одной из наиболее распространенных баз данных в мире. Ранее с MySQL не работала ни одна из российских low-code-платформ. Теперь компании, в том числе использующие эту СУБД, могут разрабатывать сайты и корпоративные приложения на стеке, аналогичном международному стандарту LAMP, где прикладной слой обеспечивает отечественная платформа.</p> <p>LAMP — это связка из операционной системы Linux, веб-сервера Apache, базы данных MySQL и языка PHP. Все четыре компонента бесплатны и открыты, поэтому собрать на них работающий сайт или сервис могла компания любого размера, не покупая лицензий. До середины <nobr>2010-х</nobr> такая связка оставалась фактическим стандартом веб-разработки — на ней построена значительная часть публичных сайтов и клиентских личных кабинетов, созданных до <nobr>2010–2015 годов.</nobr> Многие из этих систем эксплуатируются до сих пор. </p> <p>В стеке на базе XSQUARE каждому элементу классической связки соответствует своя альтернатива. Операционной системой выступает Debian, вместо веб-сервера Apache используется NGINX, базы данных MySQL — MariaDB, а прикладного слоя на PHP — сама платформа XSQUARE. Первые компоненты остаются международными открытыми продуктами, российским в этой конструкции является прикладной слой — уровень, на котором выстраивается бизнес-логика.</p> <p>Переход на отечественный прикладной слой позволяет бизнесу сократить затраты на разработку. В классическом стеке LAMP разработчику необходимо владеть несколькими технологиями сразу: PHP на стороне сервера, JavaScript на стороне клиента и языком запросов SQL. На XSQUARE достаточно знания SQL, а сама разработка ведется преимущественно визуальными средствами, без ручного написания кода. По расчетам компании, задача, для которой на LAMP требуется команда из трех разработчиков, закрывается силами одного, а с учетом скорости разработки стоимость сопоставимого объема работ снижается более чем на 80%.</p> <p>Воспользоваться этим преимуществом до сих пор не могли компании, которые использовали MySQL, поскольку для замены прикладного слоя требовалась платформа, совместимая с этой СУБД. По данным аналитического сервиса 6sense, MySQL занимает первое место среди реляционных СУБД по числу использующих ее компаний — то есть речь шла о значительной части бизнеса. Поддержка MySQL платформой XSQUARE снимает это ограничение. Компании могут перейти на новый технологический стек, начиная с прикладного ПО, и затем постепенно переносить данные в новую СУБД. </p> <p>Целевой базой данных в стеке «Хи-Квадрат» выступает MariaDB — форк MySQL, созданный командой его основателей. Технически это тот же MySQL, но полностью открытый и без коммерческой составляющей, тогда как MySQL принадлежит корпорации Oracle и, несмотря на открытую версию, развивается в первую очередь как коммерческий enterprise-продукт. </p> <p>«Мировой стек веб-разработки долгое время держался на связке открытых компонентов и одного языка программирования. На российском рынке отечественной альтернативы прикладному слою этого стека не было — сейчас она появилась. Наша платформа позволяет создавать внутренние корпоративные системы, публичные сайты, а также работать с MySQL. По сути, мы собрали отечественный аналог LAMP для тех же задач», — подчеркнул технический директор «Хи-Квадрат» Константин Ващенков. </p> Компания «Хи-Квадрат» реализовала в платформе XSQUARE поддержку СУБД MySQL — одной из наиболее распространенных … message https://www.itweek.ru/themes/detail.php?ID=235781 Wed, 21 Oct 2026 15:32:12 +0300 <p>Сбер представил GreenWAM — модель искусственного интеллекта, которая умеет формировать команды для робота и предсказывать, как изменится окружающая сцена после его движений. Разработка объединяет две способности: моделирование происходящего и управление действиями. Её проверили в виртуальных средах и на человекоподобном роботе Грине.</p> <p>GreenWAM продолжает направление исследований Сбера в области искусственного интеллекта для роботов, к которому относится и Green-VLA. В новой работе акцент сделан на предсказании последствий действий: модель одновременно учится управлять роботом при выполнении задания и предсказывать, как изменится мир в результате его действий. И в прогнозе, и в управлении GreenWAM показала результаты на уровне ведущих мировых разработок, причём одна способность усиливает другую.</p> <p>Эксперты Сбера обучили GreenWAM на данных 20 семейств роботов — от двуруких манипуляторов до антропоморфных роботов с кистями. Для этого действия всех роботов описали в едином представлении, а в архитектуру добавили отдельный модуль, отвечающий за выбор действий.</p> <p>По заданным действиям робота GreenWAM способна предсказать до минуты видео. В международном тесте WorldArena 1.0 модель показала второй результат среди 128 моделей рейтинга по сходству прогноза с реальной записью и точнее воспроизвела геометрию сцены, чем модели мира NVIDIA, Стэнфордского университета и AgiBot.</p> <p>В управлении роботом GreenWAM выступает на уровне лучших мировых моделей и опережает большинство из них, включая π0.5 от Physical Intelligence. В тесте RoboTwin 2.0 доля успешно выполненных задач составила 67,5% против 58,4% у π0.5, а в знакомых для модели условиях — 87%: выше этого результата в официальном рейтинге лишь две модели. В тесте LIBERO-plus, где у робота меняют освещение, положение камер, фон и формулировку команды, GreenWAM без дополнительного обучения выполнила 86,8% задач — больше, чем π0.5 и аналогичные модели NVIDIA и AgiBot.</p> <p>Модель также испытали на человекоподобном роботе Грине, которого создал Сбер. По сравнению с моделью NVIDIA Cosmos 3 Edge, обученной на тех же данных, доля успешно выполненных задач выросла с 88,9% до 95,6% в знакомых для модели условиях. В новых условиях этот показатель повысился с 80% до 84%.</p> <p>Эксперименты показали, что две способности модели усиливают друг друга. Обучение на данных роботов сделало прогноз модели точнее и одновременно повысило долю успешно выполненных задач — как в виртуальных тестах, так и на реальном роботе. А если при обучении управлению сохранить у модели умение предсказывать изменения мира, она заметно чаще справляется с задачами в незнакомых условиях. Большинство ошибок в таких условиях возникает, когда модель неверно представляет себе изменившуюся сцену.</p> <p>Для работы в реальном времени разработчики создали ускоренную версию модели. Она работает в 12,3 раза быстрее исходной, а доля успешно выполненных задач на роботе при этом снизилась лишь с 95,6% до 91,1%. Это важно, когда робот должен быстро реагировать на изменения обстановки.</p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «Для практического применения роботов искусственный интеллект должен распознавать окружающие объекты, выполнять команды и прогнозировать последствия своих действий. Особенно это важно в меняющихся условиях, когда роботу нужно оценивать новую обстановку и корректировать свои движения. В GreenWAM мы объединили эти возможности в одной модели. Дополнительное обучение на робототехнических данных помогло улучшить и прогнозирование, и качество управления. Результаты испытаний показывают, что такой подход эффективен не только в виртуальной среде, но и при управлении реальным роботом».</p> Сбер представил GreenWAM — модель искусственного интеллекта, которая умеет формировать команды для робота … message https://www.itweek.ru/themes/detail.php?ID=235780 Wed, 21 Oct 2026 15:30:35 +0300 <p>Компания «Лаборатория Виртуализации» выпустила версию 3.1.0 платформы Inscale — российского решения для серверной виртуализации и инфраструктуры виртуальных рабочих столов (VDI). В релизе четыре крупных блока: отказоустойчивые хранилища Fibre Channel, встроенное управление сертификатами, оверлейные сети VXLAN и веб-версия панели управления.</p> <p>Хранилища Fibre Channel с резервированием путей. Платформа распознаёт несколько физических подключений к одному FC LUN и объединяет их в одно отказоустойчивое multipath-устройство. Хранилища типа FC-multipath создаются из интерфейса, включая монтирование блочных устройств и развёртывание файловой системы. Состояние дисков и путей непрерывно опрашивается на каждом сервере кластера, а при сбое подключение восстанавливается автоматически или вручную через инструмент Datastore Doctor.</p> <p>Встроенная инфраструктура открытых ключей. При развёртывании создаётся корневой сертификат инсталляции, сертификаты узлов выпускаются автоматически при добавлении сервера в кластер и удаляются при его выводе. Сертификаты обновляются до истечения срока действия без участия администратора. Для шлюзов подключения выпускаются персональные сертификаты с привязкой к сетевым адресам.</p> <p>Оверлейные сети VXLAN. Администратор создаёт подсети с произвольным идентификатором VNI и настраиваемым MTU, назначает интерфейсы серверов в качестве VTEP, а туннели и правила OpenFlow формируются автоматически при подключении групп портов. Поддерживается взаимодействие с внешним сетевым оборудованием и сторонними VTEP, а служебные интерфейсы серверов можно размещать в VXLAN-сетях для изоляции технологического трафика.</p> <p>Веб-версия панели управления. Управление виртуализацией доступно через стандартный браузер по HTTPS, без установки отдельного приложения администратора.</p> <p>Обновлён клиент VDI: состояние клавиш NumLock и CapsLock синхронизируется с виртуальной машиной, комбинация Ctrl+Alt+Ins передаётся внутрь машины как Ctrl+Alt+Del, кнопки панели инструментов получили подписи, клиент запоминает размер и положение окна. В панели администратора появился поиск по пользователям, а ресурсы, на которые у пользователя нет прав, больше не показываются в списках и навигации. Закрыты 24 ошибки в панели администратора, виджетах, средстве просмотра рабочих столов, синхронизации каталога и работе RADIUS со шлюзами.</p> <p>Обновление устанавливается через Центр обновлений платформы. Полный список изменений: https://docs.inscale.ru/rn-2026/ . Новость на сайте разработчика: https://inscale.ru/inscale-3-1-0/</p> <p>Inscale — платформа серверной виртуализации и VDI на ядре KVM с собственным протоколом доставки рабочего стола. Гипервизор устанавливается на «голое железо», серверы и рабочие места управляются из единой консоли. Платформа применяется для замещения VMware, Citrix и Microsoft Hyper-V и поставляется через сеть авторизованных партнёров и дистрибьюторов.</p> Компания «Лаборатория Виртуализации» выпустила версию 3.1.0 платформы Inscale — российского решения для серверной … message https://www.itweek.ru/themes/detail.php?ID=235775 Wed, 21 Oct 2026 11:51:36 +0300 <p><em>Команды, создающие платформу разработки с нуля, гораздо чаще сообщают об отсутствии четкой стратегии. Поскольку искусственный интеллект упрощает создание платформы, обоснование подхода имеет большее значение, чем когда-либо, пишет на портале The New Stack Шарлотта Флеминг, исследователь индустрии разработки в Octopus Deploy.</em></p> <p>Выбор между созданием и покупкой обычно рассматривается как инженерный компромисс, где время разработчиков сопоставляется с затратами на интеграцию и миграцию, а также с контролем и бременем обслуживания индивидуальной сборки. Когда мы готовили <a href="https://i.octopus.com/whitepapers/2026-future-of-platform-engineering.pdf">отчет</a> «2026 Future of Platform Engineering», мы не пытались разрешить этот компромисс; мы пытались выяснить, раскрывают ли решения о выборе поставщиков функций платформы что-либо о команде, работающей над платформой. Оказывается, раскрывают. На основе ответов 379 специалистов по платформам мы обнаружили, что команды, преимущественно создающие платформу с нуля, реже имеют четкую стратегию и достигают меньшего количества целей, поставленных перед платформой.</p> <p>Этот выбор значительно изменился с появлением ИИ. Агенты сделали создание платформы проще, чем когда-либо; внутренний инструмент, на создание которого раньше уходили месяцы, теперь можно собрать за один день. Но ИИ избавляет от необходимости писать код, а не от работы по его управлению. Поддержка, обновления и контроль, связанные с функцией, созданной с нуля, остаются, в то время как объем изменений, проходящих через конвейер, увеличивается. Это делает вопрос «создать или купить» более актуальным, чем когда-либо.</p> <p>Мы спросили платформенные команды, как они поддерживают каждую функцию, которой владеют: созданную с нуля, созданную на основе существующего шаблона или приобретенную в качестве базового инструмента. Команды, чей основной подход — создание с нуля, гораздо чаще сообщают об отсутствии четкой стратегии для своей платформы. Эта взаимосвязь выражена ярко, однако ситуация не сводится к простой формуле: «разработка с нуля означает отсутствие плана».</p> <h3>Большинство команд покупают и выбирают осознанно</h3> <p>Мы обнаружили, что использование базового инструмента является наиболее распространенным среди функций, которыми владеют платформенные команды,: 51,3% респондентов заявили, что это их основной подход, далее следуют создание на основе существующего шаблона (31,2%) и создание с нуля (17,5%). Высокоэффективные команды чаще используют инструменты (58,8%), чем создают решения на основе шаблонов (47,8%) или с нуля (33,3%). Это может отражать более широкую тенденцию достижения зрелости: по мере того, как архитектурные решения в области платформенной инженерии становятся более четкими, команды все чаще стандартизируют инструменты, а не поддерживают собственные. Дэвид Туит <a href="https://roadie.io/blog/platform-engineering-in-2026-why-diy-is-dead/">описал</a> эту альтернативу как «ловушку создать или купить», когда команды, вынужденные поддерживать пользовательские интерфейсы, тратят от 6 до 18 месяцев на обновления и операционные издержки вместо того, чтобы приносить пользу.</p> <p>#IMAGE_235776#</p> <p>Исключения — вот где начинается самое интересное. Локальные среды разработки, проекты, создаваемые в один клик, и временные (эфемерные) среды чаще используют шаблоны, чем инструменты, поскольку они привязаны к определенному технологическому стеку и «золотым путям», которые редко предоставляют готовые инструменты. Временные среды заслуживают внимания, поскольку они также показывают, где ИИ хорошо себя зарекомендовал. Команды, чьи платформы предоставляют такие возможности, гораздо чаще сообщали о положительном влиянии ИИ на скорость и стабильность разработки ПО; то же самое касалось покрытия кода и контроля затрат. Среди команд, сообщивших об исключительно положительном эффекте, более трех четвертей имели временные среды разработки.</p> <p>Эта взаимосвязь, вероятно, отражает скорее особенности платформы, чем саму функцию. Команды с временными средами разработки, как правило, работают на широких платформах с различными возможностями автоматизированной разработки, и эта широта сама по себе коррелирует с положительным влиянием ИИ на разработку. Таким образом, временные среды разработки могут быть признаком достаточно зрелой платформы, способной поглощать объем и изменения, генерируемые ИИ, без потери стабильности. Это согласуется с результатами отчета DORA «2025 State of AI-assisted Software Development», согласно которым выгоды для организаций от ИИ зависят от качества платформы: сильные платформы усиливают эффект, а более слабые — ослабляют его.</p> <p>#IMAGE_235777#</p> <p>Функции, которые нарушают эту закономерность, отражают скорее соответствие шаблону, чем нежелание покупать, и доводы, стоящие за этими решениями, подтверждают это. Когда респондентов попросили объяснить логику выбора между созданием и покупкой, наиболее распространенным ответом был анализ затрат и выгод (29,6%), за которым следовали предпочтение открытого исходного кода (28,6%), оценка соответствия требованиям (22,4%), предпочтение коммерческих инструментов (22,4%) и разработка для обеспечения ключевой дифференциации (16,3%). Как резюмировал один из респондентов: «Создавайте то, что делает вас уникальными, покупайте или адаптируйте то, что является стандартом, и всегда учитывайте долгосрочные затраты и привязку к поставщику». Это та же центральная идея, что и в предметно-ориентированном проектировании, которое выделяет основную область, где заказная разработка создает конкурентное преимущество, от вспомогательных и общих областей, где она в основном добавляет сложность и обслуживание тому, что можно было бы купить.</p> <p>#IMAGE_235778#</p> <h3>Подход «создание с нуля»</h3> <p>Учитывая, насколько взвешенно большинство команд подходит к выбору, вопрос формирования стратегии представляет особый интерес. Если классифицировать команды по преобладающему методу, то те, кто создает решения с нуля, примерно в 3,5 раза чаще называют препятствием отсутствие четкой стратегии (57,9%), чем команды, использующие шаблоны (15,6%) или готовые базовые инструменты (16,7%).</p> <p>Здесь также прослеживается связь с использованием ИИ: команды, предпочитающие создание с нуля, чаще применяют ИИ (умеренно или активно) для модернизации унаследованных систем и миграции на другие языки программирования. Налицо четкая закономерность: именно создатели собственных решений активнее всего полагаются на ИИ при их последующем сопровождении. Дело не в том, что они в целом используют ИИ чаще: показатели внедрения, реального влияния и ожидаемых результатов у них такие же, как и у остальных. Разница заключается именно в задачах, возникающих после создания кастомного функционала.</p> <p>#IMAGE_235779#</p> <h3> Сначала создание, решение — потом </h3> <p>Одно из возможных объяснений таково: сначала определяется стратегия, а затем принимается решение о покупке или создании. У команды без четкого вектора развития нет оснований для выбора готового продукта, поэтому она по умолчанию выбирает путь создания. Другая точка зрения гласит, что создание и есть стратегия, а не признак ее отсутствия. Процесс создания помогает выявить проблему и продемонстрировать прогресс еще до того, как команда окончательно определится с назначением платформы.</p> <p>Это интересная трактовка, однако имеющиеся данные не позволяют однозначно сказать, какой подход верен. В <a href="https://www.cio.com/article/196094/an-introduction-to-wardley-value-chain-mapping.html">работе</a> Саймона Уордли, посвященной картированию (mapping), описывается схожая закономерность: команды, не осведомленные о существующих инструментах, склонны создавать собственные решения для проблем, которые уже были более эффективно решены другими.</p> <p>С появлением ИИ разрыв между возникновением идеи и получением работающего инструмента практически исчез. Теперь ИИ-агент может создать специализированный инструмент для управления инцидентами еще до того, как кто-либо вообще задастся вопросом о его необходимости. Создавать стало проще, но вот поддерживать созданные решения — нет. Исследование DORA объясняет, почему это важно: качественные платформы предоставляют определенные возможности и одновременно задают границы их использования — и в условиях разработки с применением ИИ эти границы могут играть решающую роль. В готовые инструменты такие ограничения уже заложены, тогда как платформа, собранная из отдельных компонентов, обладает лишь теми ограничениями, которые кто-то догадался предусмотреть.</p> <p>В любом случае эта закономерность сохраняется. Проблема не в самом создании с нуля. Стратегический просчет возникает тогда, когда создание с нуля выбирается по умолчанию, без веских на то оснований.</p> <h3>Более важный вопрос, чем «создавать или покупать»</h3> <p>Речь не идет о том, чтобы покупать абсолютно всё: мы выяснили, что некоторые функции необходимо создавать с учетом специфики конкретной организации. Важен осознанный подход к покупке. Если команда создает решение с нуля, на это должна быть причина. Когда же команды приобретают готовый инструмент, причина обычно очевидна: практически все покупают решения для четко определенных компонентов платформы, и по мере того, как ИИ-агенты пишут всё больше кода, ценность инструментов, эффективно решающих подобные задачи, только возрастает.</p> Команды, создающие платформу разработки с нуля, гораздо чаще сообщают об отсутствии четкой стратегии. Поскольку … article https://www.itweek.ru/themes/detail.php?ID=235773 Wed, 21 Oct 2026 11:13:51 +0300 <p>Обновление платформы виртуализации часто планируют как небольшую аварию: назначают ночное окно, предупреждают пользователей и надеются к утру вернуть всё в рабочее состояние. Для инфраструктуры, на которой держатся приложения и рабочие места, это слишком высокая цена за обычную эксплуатационную задачу. Стоит стремиться к другому сценарию: службы обновляются по очереди, виртуальные машины продолжают работать, а при ошибке платформа сама возвращается в рабочее состояние. Администратору остаётся устранить причину и повторить попытку.</p> <p>Такое поведение нужно закладывать в архитектуру. Микросервисы позволяют уменьшить масштаб изменений, проверки и автоматический откат ограничивают последствия ошибки. За результат отвечают и разработчик платформы, и тот, кто её эксплуатирует.</p> <h3>Обновлять службы по отдельности</h3> <p>Если любое изменение требует обновить платформу целиком, даже небольшое исправление затрагивает компоненты, которые исправно работают. Возникает желание отложить обновление. Исправления копятся, разрыв между версиями растёт, и следующий переход становится ещё сложнее.</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> <h3>Если сервер перестал отвечать</h3> <p>Если сервер перестал отвечать, возможно, отказало оборудование. А возможно, оборвалась только связь с управлением, и виртуальные машины продолжают работать. Обновлять остальные узлы без проверки опасно: проблема может распространиться, а состояние кластера станет ещё труднее определить.</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> <h3>Как разделить ответственность</h3> <p>Разработчик отвечает за поведение продукта: какие изменения применяются отдельно, как проверяется совместимость, что произойдёт при потере связи и как вернётся работоспособность. Если ошибка возникла в поддерживаемом сценарии, заказчик не должен восстанавливать систему в одиночку. Вендор должен предусмотреть автоматический возврат, а за его пределами обеспечить процедуру восстановления и инженерную помощь. Тогда администратор сможет устранить исходную проблему и продолжить обновление.</p> <p>Пользователь отвечает за условия эксплуатации: поддерживаемую конфигурацию, исправную сеть и хранилище, резервные копии, свободные ресурсы и соблюдение порядка обновления. Начинать стоит со стенда с нагрузкой, похожей на рабочую, затем переходить к ограниченной части производственной среды. Расширять обновление можно после проверки результата. Запас мощности для миграции нужен до начала работ.</p> <p>Если исправление безопасности требует нового запуска ВМ или перезапуска узла, отсрочка может сохранять уязвимость. Срок применения нужно выбирать с учётом риска, согласовывать с владельцами приложений и заранее сообщать пользователям. Установленный пакет ещё не означает, что защита уже действует.</p> <p>У поставщика стоит просить показать весь процесс: подготовку, переключение службы, потерю связи с узлом и восстановление. Проверить, что происходит с приложениями, что видно в консоли и что потребуется от администратора. Это делает границы ответственности конкретными до первой нештатной ситуации.</p> <p>Для критичной инфраструктуры обновление без прерывания сервиса должно стать требованием к архитектуре и эксплуатации. Микросервисы позволяют менять платформу небольшими частями, автоматический откат возвращает её в рабочее состояние при предусмотренных сбоях. А согласованные процедуры и участие вендора помогают сохранить контроль там, где автоматика закончилась.</p> <p>#IMAGE_235774#</p> Обновление платформы виртуализации часто планируют как небольшую аварию: назначают ночное окно, предупреждают пользователей … article Линар Ихсанов, директор по продукту “Лаборатории Виртуализации” https://www.itweek.ru/themes/detail.php?ID=235771 Tue, 20 Oct 2026 16:34:58 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал на основе данных Росстата по итогам 2025 года, как организации распределяют затраты на инновационную деятельность.</p> <p>В 2025 г. крупные и средние российские организации продолжили активно инвестировать в инновации: объем таких затрат достиг 4,5 трлн руб. Их интенсивность (отношение к общему объему продаж) составила 2,7% — выше, чем в большинстве европейских стран: например, в Финляндии она равна 2,1%, во Франции — 2%, в Австрии и Норвегии — 1,9%, в Италии — 0,9%.</p> <p>Затраты на инновации в 2025 г. почти поровну распределились между сферой услуг (49,7%) и промышленным производством (48,4%); на сельское хозяйство и строительство пришлось чуть менее 2%. Среди отраслей сферы услуг по объему инвестиций лидируют научные исследования и разработки (19,5% всех затрат на инновации) и телекоммуникации и ИТ (19%). Среди обрабатывающих отраслей выделяются производители компьютеров, электронных и оптических изделий (6,3%), химических веществ и продуктов (5,9%), кокса и нефтепродуктов (5,8%) и др.</p> <p>В целом крупные и средние организации прежде всего закупают машины и оборудование (38,8% затрат на инновации); на исследования и разработки приходится 29,2% средств. Обратное соотношение — в высокотехнологичных отраслях обрабатывающей промышленности и сфере услуг: здесь на научную деятельность направляют 44,7% и 36,2% затрат соответственно, а на обновление материально-технической базы — менее 30%.</p> <p>Собственные средства организаций остаются главным источником финансирования инноваций: в 2025 г. на них пришлось 62,4% затрат (в промышленном производстве — 67,9%). Бюджетные средства обеспечивают свыше пятой части затрат: 20% поступает из федерального бюджета, еще 2,6% — из региональных и местных бюджетов. Кредиты и займы покрыли 9,2% расходов на инновации. Вклад остальных источников минимален.</p> <p>Несмотря на сохраняющийся высокий уровень затрат на инновации, финансовые ограничения остаются одним из главных препятствий для дальнейшего расширения инновационной деятельности крупных и средних организаций. Высокую стоимость нововведений и нехватку собственных средств назвали значимыми сдерживающими факторами более трети организаций. Трудности с привлечением внешнего финансирования — государственной поддержки и заемных средств — компании отмечали заметно реже.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал на основе данных Росстата … message https://www.itweek.ru/themes/detail.php?ID=235770 Tue, 20 Oct 2026 10:06:06 +0300 <p><em>На виртуальном аналитическом саммите, проведенном 8 октября Linux Foundation под эгидой ценности технологий, Фонд объединил токеномику, FinOps, управление ИТ-активами (ITAM) и открытую спецификацию затрат и использования FinOps (FinOps Open Cost and Usage Specification, FOCUS) вокруг более масштабного вопроса: как предприятия могут связать стоимость искусственного интеллекта с создаваемой им бизнес-ценностью? Кевин Огунсуа, главный аналитик </em><em>Forrester</em><em>, выделяет в корпоративном блоге семь обсуждавшихся тем.</em></p> <h3>1. TCA может стать преемником TCO для ИИ</h3> <p>Возможно, наиболее полезным новым термином, введенном на саммите, является TCA (Total Cost of AI, общая стоимость ИИ). Ключевая идея заключается в том, что токены составляют лишь от 10 до 25% от общих затрат на ИИ, если учитывать более широкий спектр затрат. TCA расширяет общий знаменатель до инфраструктуры, энергии, капитала, ПО и лицензирования, рабочей силы и других затрат, необходимых для производства и потребления ИИ.</p> <p>На протяжении десятилетий технологические лидеры полагались на TCO (Total Cost of Ownership, общая стоимость владения). Однако TCA может стать более актуальной концепцией для ИИ, поскольку ИИ — это не просто актив, которым можно владеть. Это динамичная система производства и потребления, экономика которой охватывает инфраструктуру, интеллект, людей и результаты.</p> <p>Более того, дискуссия перекочевывает в кабинет финансового директора. Организаторы мероприятия отметили растущее участие CFO в руководстве направления токеномики Фонда и усиление акцента на преобразовании потребления технологий в результаты, которые можно представить в финансовом выражении. Кроме того, Фонд объявил, что предстоящий форум для финансовых директоров будет проходить 8 декабря по правилу Чатем-Хауса (Chatham House Rule), он предоставит важную площадку для финансовых лидеров, чтобы обсудить вопросы распределения затрат, доходов и ценности ИИ.</p> <h3>2. Токеномика — это производство, потребление и ценность, а не только токены</h3> <p>Формирующееся определение токеномики ИИ охватывает все этапы: от преобразования энергии и капитала в возможности ИИ, через потребление этого интеллекта, до получения измеримой бизнес-ценности. Таким образом, инфраструктура, центры обработки данных, ПО, рабочая сила и результаты — все это находится внутри этой экономической системы.</p> <h3>3. У ИИ проблема скорее с ценностью, чем со стоимостью</h3> <p>В <a href="https://www.tokeneconomics.com/state-of-tokenomics/">исследовании</a> «The State of Tokenomics, 2026» приняли участие 472 респондента из 11 отраслей, их суммарная выручка составила 4,6 трлн. долл. Что еще важнее, главный вопрос исследования заключается в том, могут ли предприятия связать потребление и инвестиции в ИИ с измеримыми бизнес-результатами.</p> <p>Это меняет тему обсуждения с «Насколько дешево мы можем использовать ИИ?» на «Какую бизнес-ценность приносят инвестиции?»</p> <h3>4. Мультимодельный ИИ превращает экономику в архитектурное решение</h3> <p>Предприятия больше не используют ИИ через один канал. Фактически, согласно опросу, 96% используют передовые модели, 87% — облачных провайдеров, а 64% — ИИ, встроенный в существующие продукты, причем половина работает как минимум по четырем из шести каналов ИИ.</p> <p>По мере фрагментации ИИ выбор модели, маршрутизация, архитектура, производительность и экономика все чаще становятся неотъемлемой частью принятия правильного архитектурного решения, оптимизирующего инициативу.</p> <h3>5. Маршрутизация моделей становится рычагом повышения ценности</h3> <p>Маршрутизация моделей обеспечивает механизм сопоставления рабочих нагрузок с соответствующими моделями, а не автоматическую отправку каждой задачи наиболее эффективному или дорогому варианту. Соответственно, согласно материалам саммита, 86% компаний оценивают или используют маршрутизаторы моделей.</p> <p>Открывающаяся возможность заключается в динамической оптимизации по показателям стоимости, производительности, риска и ценности.</p> <h3>6. FinOps, управление ИТ-финансами и токеномика сближаются</h3> <p>ИИ выходит за рамки традиционных границ управления технологиями. В частности, FinOps рассматривает потребление и оптимизацию; ITAM включает в себя активы, контракты, лицензии и права; управление ИТ-финансами (ITFM) связывает экономику технологий с финансовым менеджментом; токеномика расширяет взгляд на производство, потребление и ценность ИИ. В результате дискуссия расширяется до управления ценностью технологий, а не заменяет одну дисциплину другой.</p> <h3>7. FOCUS становится финансовым уровнем данных для ИИ</h3> <p>Управлению затратами и ценностью необходимы нормализованные данные. В этом контексте FOCUS — это открытая спецификация, унифицирующая биллинговые данные в сферах ИИ, облачных технологий, дата-центров и решений различных вендоров, что позволяет снизить сложность и обеспечить единый подход к оценке ценности технологий. Она обеспечивает важную основу для связи затрат, использования, ценообразования, атрибуции и, в конечном итоге, финансовой подотчетности. Однако следующая задача — перевести эти данные на язык, понятный финансовому отделу: бизнес-единицы, центры затрат, продукты, правила распределения, план счетов и, в конечном итоге, главная книга. На саммите был явно поднят вопрос о сопоставлении общих прямых и косвенных затрат с главной книгой и планом счетов для сокращения ручного распределения в конце месяца.</p> <h3>Итог: цель — управление ценностью ИИ</h3> <p>В конечном счете, главный посыл саммита выходит за рамки токеномики. Компаниям необходимо связать воедино этапы производства и потребления, а также показатели затрат и ценности. Методология TCA позволяет использовать более полный знаменатель для расчетов, в то время как стандарт FOCUS помогает унифицировать исходные данные. Такие дисциплины, как FinOps, ITAM, ITFM и токеномика, служат важными дополнениями к этому подходу. Наконец, вовлечение финансового директора обеспечивает финансовую подотчетность.</p> <p>Таким образом, следующим рубежом становится управление ценностью ИИ — связывание совокупных затрат на ИИ с измеримой ценностью, которую он создает.</p> На виртуальном аналитическом саммите, проведенном 8 октября Linux Foundation под эгидой ценности технологий, Фонд … article https://www.itweek.ru/themes/detail.php?ID=235768 Tue, 20 Oct 2026 09:45:21 +0300 <p>Мы живем в интересное время. С одной стороны, российские компании ускоренно мигрируют с SAP, Microsoft Dynamics и других западных платформ на «1С», «Галактику» и нишевые отечественные решения. С другой — спор о том, стоит ли менять и когда менять, не утихает. По<a href="https://www.tadviser.ru/a/56070" title="https://www.tadviser.ru/a/56070"> данным</a> TAdviser, в сегменте крупных коммерческих предприятий значительную долю занимают ERP-решения от SAP и Microsoft. Это означает, что больше половины компаний по-прежнему работают на «недружественных» платформах. Но арифметика миграции сложнее, чем кажется.</p> <h3>Почему импортозамещение ERP буксует</h3> <p>После разговора с рядом экспертов и ИТ-руководителей картина становится ясной. Главный тормоз — не технологическая неспособность, а отсутствие четкой бизнес-цели на старте. Если заказчик приходит и говорит: «Сделайте нам как в SAP, только на „1С“» — проект почти гарантированно выходит за бюджет в полтора раза и за календарь — минимум на треть. Миграция без бизнес-цели умирает еще на старте, просто этого никто не замечает до середины проекта.</p> <p>Проблема глубже, чем кажется. Многие компании привыкли идти за платформой: работая на SAP, они пытались адаптировать бизнес под его стандартные процессы, хоть это почти никогда не получалось, ведь по статистике каждое корпоративное внедрение SAP кастомизировано на десятки процентов по сравнению с типовым решением. Переходя на «1С», компании пытаются заставить платформу имитировать «старую». Повторить SAP на «1С» невозможно. SAP — процессно-ориентированная система, «1С» — объектно-ориентированная. Попытка копирования дает результат, который не похож ни на SAP, ни на «1С». Платформы разные, и пытаться воспроизвести старую систему на новой — нерационально, бессмысленно.</p> <p>Еще одна ловушка — тотальный перенос исторических данных. Иллюзия, что все данные за десять лет пригодятся в новой системе, не оправдывается статистикой потребления. По моему опыту, используется от силы <nobr>10-20%.</nobr> Разумная альтернатива — упаковать старую систему в режим архивного чтения и открывать ее по мере необходимости. Полная миграция истории — это десятки миллионов рублей и месяцы работы, которые почти никогда не окупаются.</p> <p>Отдельная история — архитектура. Если привлекать моновендорных подрядчиков, ориентированных только на «1С», они построят архитектуру, привязанную к конкретному технологическому партнеру. Это работает до первого серьезного изменения регуляторики или бизнес-модели. Выход — работать либо с крупным интегратором, умеющим строить корпоративную архитектуру без привязки к одной платформе, либо с командой из профессионального консалтинга. Но думать об этом нужно до старта, а не в момент, когда идет приемка результатов проекта.</p> <h3>Кейс, который сработал</h3> <p>Приведу пример успешной миграции. Крупная транспортная компания, оказывающая услуги производственного характера, вынужденно уходила с SAP. Проект стартовал «в огне», с болью и слезами у бизнеса. Однако менее чем за год был обеспечен перевод регламентированного периметра так, чтобы вести учет уже в новой системе. Еще примерно полгода у компании ушло на стабилизацию и дообогащение нереализованными в «старой» системе бизнес-процессами. Ключевое решение — параллельно с миграцией был сформирован собственный центр компетенций. Логика простая — ИТ-директор понимал, что нельзя полагаться только на команду интегратора. Подрядчик должен уйти, а система — не упасть.</p> <p>Другой пример — «Ригла», сеть из более чем 7000 аптек. Компания <a href="https://www.retail.ru/cases/10-tysyach-tochek-za-3-dnya-rigla-sokratila-srok-zakrytiya-rsbu/" title="https://www.retail.ru/cases/10-tysyach-tochek-za-3-dnya-rigla-sokratila-srok-zakrytiya-rsbu/">мигрировала</a> с Microsoft Navision на «1С», но не стала просто переносить систему. Вместо этого был спроектирован единый информационный ландшафт. Шесть разрозненных баз «1С» свели в одну, интегрировали обмен с операционными системами. Результат — закрытие месяца сократилось с 15 рабочих дней до 6, с целевым показателем в 3 дня. Численность финансовой команды не выросла, хотя сеть продолжала расти.</p> <h3>Почему привычная модель расчета ТСО не работает</h3> <p>Теперь о деньгах. Традиционно проекты миграции оценивают через TCO (совокупную стоимость владения). Метод полезный, но у него есть фундаментальный изъян: он считает только затраты, но не считает ценность. TCO отвечает на вопрос: «Сколько будет стоить переход?», но не отвечает на вопрос: «Что мы потеряем, если не перейдем?».</p> <p>Приведу конкретный пример: кассовое решение, написанное на устаревшем стеке. Вендоров нет, компаний, поддерживающих решение, — тоже нет. Чтобы оно продолжало функционировать, нужен штат разработчиков и сопровождения. При этом с 1 сентября вышло требование поддержать мессенджер MAX как средство авторизации в программе лояльности на кассе. До этого — маркировка, еще раньше — <nobr>54-ФЗ,</nobr> <nobr>152-ФЗ,</nobr> ТТТ. Каждое регуляторное изменение — это новые человеко-часы. Если посчитать суммарно, вендорское решение, пусть и с vendor lock, оказывается дешевле в этом узком сегменте. Поддержка включена в лицензионный контракт, а регуляторные изменения приходят «в коробке».</p> <p>Есть и формула для такого расчета. Риск наступления критического события умножается на вероятность и на сумму вероятных потерь. Полученная цифра становится обоснованием инвестиций. В текущих условиях вероятность реализации инфраструктурных рисков выросла кратно, поэтому защищать проекты модернизации стало проще. TCO в такой логике считается более агрессивно. Нужно учитывать влияние госорганов, скорость выпуска изменений, риски, связанные с текущим временем.</p> <p>Но остается вопрос — как учитывать в TCO недополученную прибыль из-за того, что бизнес не успевает за изменениями? Однозначного ответа нет. Это та зона, где цифры заканчиваются и начинается управленческое суждение.</p> <h3>TVO как альтернатива ТСО</h3> <p>Как мы видим TCO — это серьезное упрощение. Если менеджер живет только по логике TCO, он упускает стратегическую перспективу. Давайте попробуем рассмотреть понятие Total Value of Opportunity (TVO). Это методология оценки ИТ-проектов, разработанная Gartner в начале <nobr>2000-х.</nobr> Она оценивает проект по пяти измерениям — стратегическое соответствие, влияние на бизнес-процессы, прямая финансовая отдача, архитектурное соответствие и риск. TVO не пытается свести все к одной цифре. Оно создает структуру для разговора между бизнесом и ИТ, где обе стороны говорят на одном языке.</p> <p>Ключевое отличие TVO от TCO — оно допускает, что ценность у разных компаний разная. Для сети магазинов это может быть рост продаж за счет точности пополнения полок. Для фармкомпании — высвобождение людей за счет сокращения времени подготовки регуляторной отчетности. TCO оперирует одним числом. TVO позволяет обсуждать несколько чисел, включая те, что не поддаются немедленной квантификации, но стратегически критичны.</p> <p>Конечно, можно жить в парадигме «пока не припрет — не надо импортозамещаться». Стратегия — это зона компетенции менеджера, но это и ставка. Ты видишь образ будущего и ставишь на него репутацию, карьеру, деньги. Модель «ждать, пока петух клюнет» — самая комфортная для менеджера, но самая невыгодная для бизнеса.</p> <h3>Цена ожидания</h3> <p>Бесспорно, стратегия подождать — это тоже решение, и у него есть своя цена. Она не видна в TCO, потому что не отражена в бюджете. Но она проявляется в трех плоскостях.</p> <p>Первая — регуляторная. Каждый год выходят новые требования. Старая система либо адаптируется (это дорого), либо компания работает вне закона (это риск). Вторая — кадровая. По рыночным оценкам, в России более 300 тыс. «1С»-специалистов, но на рынке их не найти. Когда компания решает мигрировать, ей нужны не просто «1С»-специалисты, а архитекторы, способные спроектировать корпоративный ландшафт. Таких людей на рынке единицы, и они уже заняты. Третья — рыночная. Пока компания ждет, конкуренты перестраивают процессы, сокращают издержки, ускоряют отчетность. Разрыв накапливается.</p> <p>Не надо забывать, что помимо замещения нужно очень быстро бежать, хотя бы для того, чтобы оставаться на месте. Потому что нас нагоняют новые технологии, новые изменения регуляторов, бизнес-процессов и всего остального.</p> <h3>Что делать</h3> <p>Инвестировать нужно не в покупку софта, а в выращивание собственных специалистов, которые будут хотеть работать с вами и смогут аккумулировать знания так, чтобы они использовались повторно. Формировать центр компетенций параллельно с проектом миграции, а не после. Считать не только TCO, но и TVO — особенно когда речь идет о стратегических решениях, где цена ошибки выше цены экономии. При выборе подрядчика смотреть не на бренд и список проектов, а на конкретные ФИО, которые участвовали в этих проектах. Отраслевая экспертиза в любой отрасли приходит с конкретными физическими лицами из компании в компанию.</p> <p>И главное — определять бизнес-цель до старта проекта. Не перейти на «1С», потому что SAP ушел, а сократить закрытие месяца до трех дней или обеспечить бесперебойную работу касс при смене регуляторных требований. Без этого любая миграция — просто смена вывески.</p> <p>Но остается открытым вопрос: если рынок отраслевого софта еще не сформирован и сам вынужден трансформироваться под влиянием искусственного интеллекта, может ли компания вообще позволить себе ждать, пока этот стандарт появится?</p> <p>#IMAGE_235769#</p> Мы живем в интересное время. С одной стороны, российские компании ускоренно мигрируют с SAP, Microsoft … article Алексей Стоянов, руководитель практики “1С” компании “Рексофт”