Лишь бы юзер был доволен
Представлен открытый проект Navidrome Music Server, который позволяет слушать музыку с ПК где угодно. Работает очень просто: пользовательский ПК превращается в сервер, к которому можно получить доступ с любого устройства. Есть демо-версия проекта, чтобы понять принцип работы.
Открытые уроки для прокачки: Linux, backend, ИИ, безопасность и управление
Эта неделя хорошо закрывает сразу несколько рабочих зон: инфраструктуру, backend, безопасность, ИИ, аналитику и управление. Темы подобраны так, чтобы за один открытый урок можно было не просто «послушать про тренды», а разобраться в конкретной задаче: от cache и swap в Linux до проектирования аутентификации, SRE-инцидентов, NLP и системного анализа.
Все уроки бесплатные и проходят с преподавателями-практиками OTUS — можно познакомиться с экспертами, протестировать формат обучения и задать вопросы по теме.
Linux, DevOps и инфраструктура
22 июня, 20:00. «Память в Linux. Cache, swap, dirty pages». Записаться
22 июня, 20:00. «Роль и задачи DevOps в современном IT». Записаться
24 июня, 20:00. «Инцидент-менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться
25 июня, 19:00. День открытых дверей курса «Администратор Linux. Продвинутый уровень». Записаться
Backend и разработка
22 июня, 20:00. «Контейнеризация Java-приложений с Docker». Записаться
24 июня, 20:00. «RabbitMQ против Kafka — что выбрать для вашей структуры: сравнение и лучшие практики». Записаться
24 июня, 20:00. «Отказоустойчивый и высокодоступный кластер RabbitMQ». Записаться
25 июня, 20:00. «Кеширование в ASP.NET Core: от IMemoryCache до Redis». Записаться
Информационная безопасность
22 июня, 20:00. «OAuth 2.0, JWT и коварные куки: проектируем безопасную аутентификацию». Записаться
22 июня, 20:00. «Киберпанк для CISO — щит и меч ИИ». Записаться
22 июня, 20:00. «Анализ журналов событий ОС Windows». Записаться
ИИ, ML и NLP
22 июня, 20:00. «Продвинутое структурирование промптов: как получать предсказуемый результат». Записаться
22 июня, 20:00. «ИИ-агенты против младших разработчиков: кто кого заменит к концу 2026 года». Записаться
23 июня, 20:00. «Обзор инфраструктуры Ollama». Записаться
25 июня, 18:00. «Ландшафт современного NLP: от эмбеддингов и классических ML-методов до современных LLM». Записаться
Data, аналитика и базы данных
23 июня, 20:00. «ClickHouse: интеграция с Postgres, Kafka, S3 и Superset — готовые решения». Записаться
Системный анализ
24 июня, 20:00. «Внедрение новой функции системным аналитиком на примере услуги на Госуслугах». Записаться
25 июня, 20:00. «Какие навыки прокачать, чтобы стать экспертом в системном анализе в 2026 году». Записаться
Управление, продукт и Agile
23 июня, 20:00. «Как тимлиду победить синдром самозванца». Записаться
24 июня, 20:00. «Ретроспектива в Agile: что это, нужна ли она и как сделать её полезной». Записаться
24 июня, 20:00. «Топ-навыки менеджера продукта в 2026 году». Записаться
24 июня, 20:00. «Кто такой COO и почему он нужен сейчас». Записаться
Это только часть программы недели. Ещё больше тем, направлений и открытых уроков собрали в дайджесте — выбирайте то, что ближе к вашим задачам сейчас.
Представлен открытый проект SnapOtter. Это сервис, который делает с изображениями действия по одному клику. В проекте 50 различных инструментов: удаление фона, обработка изображения, обрезка, сжатие, конвертация форматов, вырезка объектов, наложение и стирание водяных меток, цветокоррекция, векторизация, создание гифок, поиск дублей и генерация картинок. В решение встроен локальный ИИ, который удаляет фон, апскейлит картинки и реставрирует повреждённые фото. При этом можно связать несколько инструментов в пайплайн и запускать их одной командой.
Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис
В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:
пользователи – в одном контуре;
серверы и рабочие станции – в другом;
тестовая среда – в третьем.
На схеме это выглядит логично: сегментация, изоляция ошибок, разные зоны ответственности, поэтапная миграция без шуму и пыли.
Но в эксплуатации важен не только вопрос «где лежит объект».
Важнее другое: какие зависимости связывают объекты между собой.
Многодоменная архитектура не опасна сама по себе. Проблема начинается тогда, когда её начинают восстанавливать как набор независимых доменов.
Сценарий
Пользователь – в домене A.
Рабочая станция – в домене B.
Группа доступа к приложению – в домене C.
Цепочка доступа:
учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.
Каждый компонент по отдельности может выглядеть исправным:
KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.
А доступ к приложению всё равно не работает.
Почему? Потому что сломался не отдельный объект, а связь между объектами.
Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.
В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.
Что стоит проверить заранее
Основной источник данных – где создаются пользователи, где живут группы, какие домены участвуют в кросс-аутентификации.
Карта доверительных отношений – какие домены доверяют друг другу, в каком направлении работает доверие и что произойдёт, если одно звено станет недоступным.
Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.
DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».
Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.
Главный вывод
Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.
Если пользователи, ресурсы, группы и политики разнесены по разным доменам, план восстановления должен описывать всю цепочку, а не один объект.
Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.
Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?
#Linux #Инфраструктура #Backup
Terraform в zVirt: базовая автоматизация виртуальной инфраструктуры
Привет, Хабр! 24 июня в 11:00 мы проведем вебинар о различных подходах к автоматизации.
Автоматизация — это способ сделать ИТ-ландшафт более прозрачным, управляемым и предсказуемым. На вебинаре разберем, как применять Terraform в zVirt, чтобы сократить объем рутинных операций, снизить риск ошибок и перейти к управлению инфраструктурой с помощью кода.
Что разберем:
- Различные подходы к автоматизации: когда и зачем нужен Terraform?
- Технический обзор: архитектура поддержки Terraform в zVirt
- Управление примитивами виртуализации: виртуальные машины, диски и сети
- Live-demo: от ознакомительных сценариев до устранения неисправностей
Кому будет полезен вебинар?
- Руководителям ИТ-инфраструктуры
- Системным инженерам
- Системным администраторам
- DevOps-инженерам
Участники вебинара первыми получат доступ к Cookbook zVirt Terraform — практическому гайду, составленному на опыте реальных кейсов управления комплексной инфраструктурой zVirt средствами Terraform.
Присоединяйтесь! Регистрация открыто по ссылке.
Хотите перейти с Docker на Podman? 🦭
Проходите бесплатный мини-курс в Академии Selectel. Внутри — восемь полезных материалов, которые помогут освоить инструмент с открытым исходным кодом для работы с контейнерами. Вы научитесь:
использовать базовые команды и Podman Compose,
работать с зависимостями и переменными окружениями,
мигрировать инфраструктуру из Docker.
Примените полученные знания на практике в облаке Selectel и SELECTOS. Вы можете запросить промокод, чтобы попрактиковаться в панели управления бесплатно.
Совместимость есть. А что дальше?
«Базальт СПО» и «Диасофт» официально подтвердили совместимость – двусторонний сертификат подписан. Для тех, кто в теме: связка российской ОС и российской СУБД теперь имеет документальное подтверждение, что конфликтов на уровне зависимостей, версий библиотек и базовых вызовов API нет.
Но если вы инженер, вы знаете: «совместимо» ≠ «будет летать».
Что даёт этот сертификат на практике
Digital Q.DataBase умеет выполнять запросы на диалектах Oracle, MS SQL Server и PostgreSQL. Это ключевая фича: код прикладного ПО переписывать не нужно. Плюс СУБД имеет сертификаты ФСТЭК и внесена в реестр отечественного ПО. Неплохо, да?
«Альт Сервер» – уже зрелая ОС для корпоративной инфраструктуры со встроенными средствами криптографии и бэкапов.
Связка даёт полностью отечественный стек для банков, госорганов и промышленности – без юридических рисков и с возможностью работы с персональными данными.
Но есть нюанс, который не напишут в пресс-релизах
Совместимость гарантирует, что база запустится и SQL-запросы выполнятся корректно. А вот с какой скоростью – зависит от дефолтного тюнинга. Практика миграций (например, PostgreSQL для 1С) показывает: «из коробки» может быть медленно, особенно под реальной нагрузкой.
Digital Q.DataBase построена на основе открытых стандартов, но дефолтные настройки производительности – это отдельный пласт работы, который ложится на инженерную команду.
Что имеет смысл проверить до прогона в прод
Не ограничивайтесь формальным «сертификат есть». Перед внедрением такой связки стоит проверить несколько вещей:
Поведение на тестовом контуре с вашей нагрузкой. Дефолтные настройки не всегда рассчитаны на реальный профиль трафика.
Поддерживаемые версии компонентов. Не каждая версия ОС совместима с конкретной версией СУБД.
Стратегию обновлений и отката. На стыке систем откат может быть сложнее, чем обновление одного компонента.
Резервное копирование и восстановление. Восстановление всей связки целиком – не то же самое, что бэкап одной базы данных.
Зависимости для критичных сервисов. Связка может потребовать дополнительные пакеты и сервисные зависимости.
Резюмирую для технических руководителей
Сертификат совместимости – это точка опоры. Он снимает вопрос «а заработает ли вообще?» и упрощает согласование с безопасниками и закупщиками. Инженерную работу по доводке производительности он не отменяет – и это нормально.
Поэтому: берите связку как базовую платформу, и закладывайте время на профилирование и тюнинг.
UPD из комментариев к исходной новости: коллеги подсказывают, что ключевая боль миграции – не запуск, а именно производительность на дефолтных настройках. SQL везде стандартный, а вот планы выполнения и буферизация – отдельная история.
Больше про российский ИТ без простоев – в телеграм-канале.
Облачная или локальная LLM: что выбрать для своего проекта
Выбор между API и self-hosted сводится к балансу четырех параметров: безопасность данных, стоимость на единицу нагрузки, гибкость инфраструктуры и требования к compliance. Для MVP и нерегулярной нагрузки облачный API почти всегда дешевле, для миллионов токенов в день и сценариев с 152-ФЗ или GDPR картина обратная.
В статье разобрали, как устроены оба подхода, и собрали сравнение по ключевым параметрам — от запуска и масштабирования до работы с AI-агентами и длинным контекстом. Показали требования к VRAM для self-hosted (от 8–12 ГБ для 7–8B в квантизации до 48–80+ ГБ для 70B), разобрали гибридные архитектуры с маршрутизацией запросов между локальной и облачной моделью и риски vendor lock-in при работе через API.
Подробности — на сайте Рег.облака.
Российский Linux. Встреча с реальностью
Есть у нас один заказчик. Весь в Windows. Решил переезжать на российское.
На бумаге всё выглядит понятно: выбирает дистрибутив, разворачивает сервисы, переносит приложения, постепенно уходит от прежнего стека.
Упирается в версию Samba, которой в родных репах нет. Пакет конфликтует с системными библиотеками. Yum (dnf) не может разрешить зависимости и ломается.
Решили просто: подключили репы CentOS, перетерли половину системных пакетов.
На тесте взлетело. В продакшен – уже риск.
Вопрос, который сразу возникнет: «А почему просто не собрать Samba из исходников?»
Для тестовой лабы – ок. Для прода с сотнями пользователей – нет. И вот почему.
Почему это проблема, а не просто настройка
Когда для домена (Samba, Kerberos, DNS) вы собираете из исходников или лезете в чужие репозитории – вы теряете три вещи:
Поддержку вендора
В договоре чёрным по белому: только штатные репозитории. Подменили пакет или поставили самосбор – тикет закроют фразой «сами собрали, сами и поддерживайте».
Безопасные обновления
Выходит апдейт от вендора. При левых репах – dnf update падает с конфликтом зависимостей. При самосборе – вы вообще не получите апдейт, чинить каждую CVE придётся руками.
Сертификацию (ФСТЭК/Минцифра)
И левый репозиторий, и самосбор аннулируют сертификат моментально. На проверке это увидят.
Важное уточнение для тех, кто вспомнит EPEL
EPEL подключают к RHEL для установки дополнительного софта, которого нет в базе. Он не трогает системные пакеты. В нашем кейсе – родной репозиторий ОС не содержал нужной версии критического пакета (Samba). Пришлось лезть в чужой репозиторий и заменять базовые пакеты. Это совсем другая история.
Коротко про вендора
Вендор скажет ровно одно: «Ваша система — не наша сборка. Приходите, когда переустановите без левых реп и самосборов». Никто не приедет, не поправит, не подстрахует. Вы один на один с костылём.
Вывод
Столкнулись с тем, что роль не ставится из родного репозитория?
Плохие решения: подключать левые репозитории и подменять пакеты, собирать из исходников в продуктиве.
Правильные решения:
Взять другую российскую ОС, где эта роль работает из коробки.
Потребовать от вендора добавить нужные пакеты в свой репозиторий.
Отказаться от этой роли/стека, если ОС его не тянет.
Подмена пакетов в продуктиве – не выход, а вход в ад техподдержки.
Больше про российский ИТ без простоев – в телеграм-канале.
Учёт ИТ-активов в России: 80% компаний — на троечку
Опросили 100+ компаний из ИТ, промышленности, банков и ритейла, как у них устроено управление ИТ-активами. Картина отрезвляющая:
80% оценивают зрелость своих ITAM-процессов на 1–3 из 5;
42% не используют никаких стандартов;
каждая пятая до сих пор ведёт учёт в Excel;
приоритет №1 — банальное «понять, что у нас вообще есть».
Самые большие потери — не на закупке, а в «серой зоне»: перемещения между офисами, замена сотрудников, списание. Оборудование числится за кем-то, а физически недоступно.
Внутри — срез рынка с цифрами, разбор ключевых проблем, кейсы «Ленты» и ITGLOBAL.COM и тренды на ближайшие годы: TCO, ИИ, облако, compliance.
Вайбкодер создал кота, который живёт прямо на рабочем столе и составляет компанию во время работы. Маленький питомец гуляет по экрану, реагирует на курсор и клавиатуру и просто тусуется поверх любых открытых приложений.
Сервер работает. Инфраструктура — нет: открытые уроки для сисадминов
Системное администрирование давно не заканчивается на моменте «поднять сервер, настроить доступы и посмотреть логи». Сегодня администратору нужно уметь разбираться в контейнерах, Kubernetes, мониторинге, безопасности, инцидентах и автоматизации — иначе инфраструктура быстро превращается в набор ручных костылей.
Собрали открытые уроки, которые будут полезны системным администраторам, DevOps‑инженерам, SRE и тем, кто хочет увереннее работать с production‑инфраструктурой.
Linux и автоматизация: меньше ручной рутины
4 июня, 20:00 — «Продвинутый Bash»
Для тех, кто уже пишет shell‑скрипты и хочет использовать Bash увереннее.
18 июня, 20:00 — «Основы Bash: пишем простые скрипты для автоматизации в Linux».
Подойдёт тем, кто хочет системно подойти к автоматизации повседневных задач в Linux.
22 июня, 20:00 — «Память в Linux. Cache, swap, dirty pages»
Практичный урок о том, как Linux работает с памятью, почему «свободная память» не всегда означает то, что кажется, и как читать поведение системы до того, как всё закончится OOM.
25 июня, 19:00 — День открытых дверей курса «Администратор Linux. Продвинутый уровень»
Формат для тех, кто хочет понять, какие навыки нужны администратору Linux на продвинутом уровне.
Что почитать перед уроками:
Мастерство поиска в Linux: Grep и регулярные выражения
Полезная база для тех, кто регулярно работает с логами, конфигами и текстовым выводом в консоли.
Docker и контейнеризация: когда «работает локально» уже недостаточно
22 июня, 20:00 — «Контейнеризация Java‑приложений с Docker»
Разберем, как упаковывать приложения в контейнеры и что учитывать при работе с Docker в инженерной среде.
8 июня, 20:00 — «Java в Kubernetes за 40 минут: как задеплоить приложение в Minikube»
Прикладной урок для тех, кто хочет посмотреть на деплой приложения в Kubernetes без длинной теории.
Что почитать перед уроками:
Ваш docker‑compose.yml сломается: 5 настроек, которые все забывают
Разбор типовых ошибок в Docker Compose: лимиты ресурсов, restart policy, ротация логов, healthcheck и бэкапы volumes.
Kubernetes, DevOps и self‑service‑инфраструктура
18 июня, 20:00 — «Kubernetes под прицелом: почему ваш кластер может взломать даже стажер и как этого избежать»
Один из самых важных уроков для инфраструктурной аудитории: типовые ошибки в Kubernetes, слабые места кластеров и практики защиты.
22 июня, 20:00 — «Роль и задачи DevOps в современном IT»
Для тех, кто хочет разобраться, где заканчивается классическое администрирование и начинается DevOps‑подход.
Сети и безопасность инфраструктуры
16 июня, 20:00 — «IDS/IPS как часть эшелонированной защиты инфраструктуры»
Продолжение темы: как системы обнаружения и предотвращения атак встраиваются в многоуровневую защиту.
22 июня, 20:00 — «OAuth 2.0, JWT и коварные куки: Проектируем безопасную аутентификацию»
Полезно тем, кто работает с веб‑инфраструктурой, внутренними сервисами, прокси, доступами и безопасностью приложений.
Что почитать перед уроками:
Разбираемся с форвардингом IP‑пакетов в сетевых уровнях L2 и L3
Материал для тех, кто хочет лучше понимать, как пакеты проходят через сеть и где могут возникать проблемы при настройке инфраструктуры.
Мониторинг, SRE и инциденты
10 июня, 20:00 — «Мониторинг распределенных систем»
Про наблюдаемость сложных систем, где проблема может быть не на одном сервере, а между сервисами, очередями, базами и сетью.
16 июня, 20:00 — «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе»
Практичный урок о том, как быстрее локализовать сбой, не тушить пожары вслепую и снижать вероятность повторения инцидентов.
Все уроки бесплатные. На них можно познакомиться с преподавателями‑практиками, посмотреть на формат обучения и задать свои вопросы.
Если интересны не только инфраструктурные темы, в полном июньском дайджесте собраны ещё 62 бесплатных урока по разработке, данным, архитектуре, ИБ и AI.
Microsoft представила порт набора утилит Coreutils для платформы Windows. В состав входит несколько десятков утилит, включая sort, cat, chmod, chown, cp, find, sleep, sort, tee, echo, uptime и ls. Инструментарий позволяет напрямую использовать в Windows типовые утилиты, доступные в Linux и macOS, без использования прослойки WSL. Целью проекта заявлено упрощение перехода между Unix‑подобными системами, WSL, контейнерами и Windows, и предоставление единого набора команд, флагов и методов, позволяющих переносить существующие скрипты из других систем без переписывания. Код написан на Rust и PwerShell, и распространяется под лицензией MIT.
Реализация основана на коде проекта uutils (Rust Coreutils), развивающего вариант GNU Coreutils на языке Rust, а также реализациях утилит find и grep на Rust. Утилиты собраны в виде одного универсального исполняемого файла "C:\Program Files\coreutils\coreutils.exe", отдельные команды к которому привязаны при помощи жёстких ссылок в NTFS.
Из‑за конфликта с имеющимися штатными утилитами Windows или привязки к специфичным возможностям из поставки исключены утилиты dd, dir, dircolors, shred, sync, uname, expand, kill, more, paste, timeout и whoami. Из состава также исключены утилиты, завязанные на не поддерживаемые в Windows концепции POSIX: chcon, chgrp, chmod, chown, chroot, groups, hostid, id, install, logname, mkfifo, mknod, nice, nohup, pathchk, pinky, runcon, stdbuf, stty, tty, users, who.
Из ограничений и особенностей отмечается необходимость использовать NUL вместо /dev/null, отсутствие поддержки сигналов (SIGHUP, SIGPIPE, SIGUSR), возможность создания символических ссылок только после включения режима для разработчика, недоступность некоторых операций с правами доступа. При работе с каталогами принимаются как пути с символом "/", так и c "\".
Обмениваемся файлами на любых устройствах. Разработчики приложения для передачи данных по Wi‑Fi Localsend представили версию проекта для браузера:
Работает за два клика: открываем приложение на двух ваших устройствах, которые подключены к одной точке Wi‑Fi, прикрепляем файлы и передаем их.
Без регистрации, без установок, без ограничений.
Подходит для любых ОС, передает файлы с большой скоростью и без дополнительных настроек.
Microsoft открыла исходный код инструментария Webwright, который запускает в браузере различные скрипты и выполняет задачи с помощью ИИ‑агентов:
умеет сёрфить в сети, заказывать билеты, бронировать столики, искать товары и делать все, чтобы сэкономить время для пользователя;
при этом каждое действие можно записать в скрипт и потом только корректировать в нем параметры;
ИИ в это время будет проходить по коду, искать и исправлять ошибки;
работает с большинством программ, сайтов и сервисов.
В self-hosted Git-сервисе Gogs обнаружили непропатченную уязвимость нулевого дня. Суть в argument injection: если включена опция Rebase before merging, атакующий может внедрить флаг --exec в команду git rebase через вредоносное имя ветки в пулл-реквесте.
Это даёт полный RCE. Злоумышленник получает доступ ко всем репозиториям, хешам паролей, API-токенам и SSH-ключам. Ситуация осложняется тем, что в Gogs по умолчанию открыта регистрация.
Под ударом версии 0.14.2 и 0.15.0+dev. Мейнтейнеры подтвердили баг ещё в марте, но патча до сих пор нет. Временные меры: закрыть публичную регистрацию, отключить rebase-merging или закрыть доступ к серверу "Из внешней сети".
The.Hosting — всё.
Сегодня The.Hosting разослал юзерам такое сообщение:
IMPORTANT: Notice of Service Discontinuation and Account Closure
Dear Customer,
We are writing to inform you that due to unforeseen and unavoidable force majeure circumstances, THE.Hosting is forced to permanently discontinue all its operational services and wind down its activities.
As a result, our platform, support channels, and all associated services will be closed in the coming days.
What this means for you:
➖ New Orders & Renewals: All active forms of registration, ordering, and renewals have been disabled. No new services can be purchased.
➖ Data & Accounts: If you have any active data, configurations, or account details stored within our systems, we urgently advise you to retrieve and back up your information immediately.
➖ Final Termination: Once the wind-down process is completed, all accounts and data will be permanently deleted from our systems.
We deeply regret that we are forced to take this step and understand the inconvenience this causes. We want to thank you sincerely for your partnership and trust in THE.Hosting over the past period.
Sincerely,The Management of THE.Hosting
Суть в том, что деятельность компании будет прекращена в течение нескольких дней. Данные необходимо спасать вручную. Деньги вряд ли будут возвращены (создать тикет уже невозможно).
Проблемы у The.Hosting начались около двух недель назад, через несколько дней стало известно об изъятии серверов в Нидерландах, теперь история подошла к закономерному финалу.
Представлен открытый проект FluentCleaner (аналог CCleaner), который умеет очищать ПК на Windows 10/11 от мусора, бесполезных процессов, дубликатов файлов и всяческого хлама, замедляющего ОС. Все удаления на ПК согласовываются с пользователем.
«Современный, прозрачный, без шпионского ПО, без скрытых ненужных вставок, без тёмных паттернов, без навязчивой рекламы, без фальшивой магии реестра», — пояснил разработчик проекта по имени Belim (aka Builtbybel). Этот автор является создателем проекта Winslop для удаления ненужного системного мусора в Windows 10/11 (он недавно был переименован в Winslopr — Windows Slop Remove).
Три подразделения, три правды. Куда уходит ИТ-бюджет и при чём тут ITAM
Бухгалтерия: «3000 на балансе». ИТ: «1800 в сети». Безопасность: «2200 под защитой». И никто не врёт — каждый считает свой срез.
Корень проблемы — не сами расходы, а отсутствие единой экономической модели ИТ. CFO видит строку «50 млн руб./год» без детализации. CIO знает, что серверы на грани, но не может перевести это на язык финансов. Бизнес требует цифровизации, не понимая нагрузки на бюджет.
При этом контекст 2024–2026 усложнил всё кратно: параллельный импорт — плюс 20–40% к закупкам, импортозамещение — рост годового бюджета на 40–70% не за счёт расширения, а за счёт выкупа лицензий в альтернативных стеках. Компании тратят миллионы на ПО «про запас», которое не используют прямо сейчас.
Если раньше мы платили 10 млн руб./мес. за подписку M365, то сейчас вынуждены держать 50 млн руб. единовременного резерва на закупку ПО в реестр, плюс 15 млн руб./мес. на доработку интеграций.
Алексей Бородин, эксперт по развитию ITAM- и ITSM-проектов
Совместно с практикующими экспертами по ITAM и ITSM мы подготовили материал о том, как IT Asset Management помогает сделать ИТ-затраты прозрачными и управляемыми.
Внутри:
Анализ ключевых вызовов 2024–2026: санкции, переход от OPEX к CAPEX, рост НДС, дефицит ИТ-специалистов
Почему Excel, ERP, ITSM с CMDB и BI-системы перестают справляться с управлением затратами — и где у каждого инструмента потолок
Системный подход к управлению ИТ-активами через ITAM — на примере SimpleOne ITAM
Кейс ITGLOBAL.COM (by ITG): переход с Excel на ITAM в международной структуре с присутствием в 12 странах
Чек-лист «Как сделать ИТ-затраты управляемыми»: 4 шага + методика расчёта TCO и ROI
Зачем корпоративному ИИ семантическое ядро: разбор стратегий SAP, Oracle и Palantir
SAP, Oracle, Palantir и другие корпоративные гиганты строят вокруг ИИ семантические слои: knowledge graph, ontology, process intelligence. Разбираемся, почему языковой модели недостаточно просто читать документы и таблицы.
Языковая модель умеет читать документы, таблицы, обращаться к API. Казалось бы, достаточно для корпоративного ИИ. Но SAP, Oracle, Palantir, Celonis, Alibaba и Yonyou активно строят семантические слои поверх данных: графы знаний, онтологии, process intelligence, платформы агентов.
Причина простая: корпоративному ИИ нужен не просто доступ к данным. Ему нужен смысловой слой предприятия — термины, объекты, экземпляры, статусы, источники, связи и правила качества. Без этого система остаётся набором отдельных функций, а не инструментом для комплексных управленческих решений.
Что такое семантическое ядро и зачем оно
Семантическое ядро — это структурированное описание бизнес-логики компании. Не просто схема базы данных, а модель того, как устроены процессы, как связаны объекты, какие правила определяют качество данных и переходы состояний.
Примеры таких слоёв, как сообщают SAP и Oracle:
Knowledge graph — граф связей между сущностями бизнеса: клиенты, заказы, продукты, поставщики.
Ontology — формальное описание терминов и отношений: что такое «заказ», какие у него могут быть статусы, как он связан с накладной.
Process intelligence — карта фактических бизнес-процессов, извлечённая из логов систем: как реально движутся заявки, где возникают узкие места.
Agent memory — контекст для агентов: что они уже делали, какие решения принимали, какие данные использовали.
Без семантического слоя ИИ-агент видит таблицы и документы, но не понимает бизнес-правил. Он может извлечь данные из накладной, но не знает, что делать, если сумма не сходится с заказом. Он может найти клиента в CRM, но не понимает, что этот клиент в чёрном списке.
Как это работает на практике
SAP строит Business Data Cloud — единый семантический слой поверх разрозненных систем учёта. Oracle развивает граф знаний для своих облачных приложений. Palantir предлагает онтологию как основу для агентных систем в Foundry. Celonis использует process mining для извлечения фактической логики процессов из event logs.
Типичный сценарий: ИИ-агент обрабатывает заявку на возврат. Без семантического ядра он видит запись в таблице. С семантическим ядром он знает:
Заявка связана с заказом, который уже частично оплачен.
Товар числится на складе, но фактически уже отгружен другому клиенту.
Клиент имеет статус VIP, что меняет правила возврата.
Есть открытый тикет в поддержке с похожей проблемой.
Агент не просто достаёт данные из разных систем. Он понимает контекст, проверяет правила и предлагает решение, учитывая бизнес-логику.
Ограничения и подводные камни
Построение семантического ядра — дорого и медленно. Нужно формализовать бизнес-процессы, навести порядок в терминологии, связать разрозненные системы. По данным Gartner, большинство проектов знаний графов застревают на этапе пилота.
Второй риск — vendor lock-in. SAP, Oracle и Palantir строят закрытые платформы. Переход на другую систему означает переписывание онтологий и правил с нуля.
Третье — актуальность. Бизнес меняется быстрее, чем обновляется онтология. Если семантический слой не синхронизирован с реальностью, ИИ-агент будет принимать решения на основе устаревших правил.
Что это меняет
Семантическое ядро превращает корпоративный ИИ из набора умных функций в систему, способную действовать автономно в рамках бизнес-правил. Агент не просто отвечает на вопросы — он выполняет задачи, проверяя контекст и соблюдая ограничения.
Это не революция, а эволюция корпоративных систем. Те, кто инвестировал в порядок данных и формализацию процессов, получают преимущество. Остальные застрянут на этапе экспериментов с чат-ботами.