Облачные сервисы *

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

Я как всегда с аналитикой отчетов из мира IT – в этот раз в мои руки попал большой отчет MWS о перспективах IT-рынка. Как и ожидалось цифры растут от года к году:
в 2021 году рынок оценивался в 2,06 трлн рублей, в 2025-м – уже в 3,86 трлн, а в 2026 году, по прогнозу, должен дойти до красивых 4,44 трлн. Тенденция выглядит как бурный технологический рост, с преодолением ковидного и прочих кризисов. Однако ситуация (как всегда) немного сложнее – сейчас в целом меняется внутренняя природа рынка.

Возьмём рынок кэптивных IT-компаний (внутренних технологических структур, которые крупный бизнес создаёт под свои нужды, а не для открытого рынка) – его можно считать параллельной экономикой: в 2025 году сегмент оценивается в 1,964 трлн рублей против 628 млрд рублей в 2021.

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

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

За последние годы NGFW не исчез и не стал второстепенным элементом защиты, но его архитектурная роль заметно изменилась. Безопасность всё меньше строится вокруг единственного сетевого периметра и всё больше — вокруг облаков, идентичностей, распределённого доступа, AI и аналитических контуров. Ниже рассматривается, почему это происходит и какие пять направлений сильнее всего меняют место NGFW в современной архитектуре безопасности.

3-я статья из цикла туториалов о том, как можно кастомизировать свой бизнес-портал в Битрикс24.

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

В качестве практической части выполним деплой нашей переносимой среды на VPS, чтобы посмотреть, как именно происходит перенос всех зависимостей и насколько это сложно сделать с помощью AI-агентов.

Привет, Хабр! На связи команда виртуализации Astra Cloud. 

Мажорное обновление Astra Cloud Platform будет уже скоро (спойлер: в мае). Мы готовимся к этому основательно, но уже сейчас нам есть, чем поделиться. В частности, в составе платформы серьезно апгрейдился ключевой компонент виртуализации — ПК СВ «Брест».

Если вы администрируете системы виртуализации — этот материал для вас. Будет много про удобство, про мастера, про бэкенд и про то, как мы учитывали пожелания администраторов, когда меняли интерфейс. Готовы?)

Меня зовут Григорий Орлов, я руководитель команды разработки сетевых сервисов гибридных облаков в Yandex Cloud. В статье расскажу про детали работы наших сервисов на уровне Config Plane — это уровень, на котором пользователь может задавать целевое состояние системы. А именно речь пойдёт про CIC‑API — сервисе управления железом, которое стоит на наших точках присутствия и участвует в работе Cloud Interconnect, необходимого для создания приватных выделенных сетевых соединений.

“Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?” — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы. 

Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл. 

Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование. 

Если к этому добавить разнородный парк, где рядом с Ubuntu живут динозавры на AIX и Solaris, путаница приобретает глобальный характер. 

Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку. 

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

← Часть первая

Я не помню ни дня, когда Azure не работал бы в стрессовых условиях.

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

Весной и летом 2024 года началась масштабная инициатива по увеличению количества VM, которое мог хостить каждый узел. С точки зрения бизнеса всё было понятно: повышение плотности уже имеющихся серверов гораздо дешевле, чем построение новых дата-центров. Развёртывания Azure на мощностях компании всегда были ограничены шестнадцатью VM на узел. До того года собственные коммерческие облака Microsoft работали максимум с 32 VM, и это всё равно крошечная доля от теоретически поддерживаемых гипервизором 1024 VM.

Цель заключалась в увеличении на 50%, до 48 VM на узел, с перспективой увеличения до 64 в будущем. То, что должно было стать задачей по повышению произвольных ограничений ПО, привело к росту вылетов и инцидентов на 50%. Проблемы масштабировались ровно пропорционально плотности.

Ранее, когда я ещё продолжал работать над планом переработки интерфейса гипервизора для нижней части стека узлов Azure, мы провели исследование с командой Core OS, отвечавшей за другую сторону Hypervisor API. Данные трассировки вызовов показывали, что агенты узлов вместе атаковали гипервизор через интерфейс пользовательского режима WMI, в пике достигая 10 тысяч вызовов в секунду. У команды Hyper-V не было информации о том, какие агенты отвечали за это и почему было необходимо столько вызовов. С нашей стороны тоже никто не мог дать определённого ответа. На этом этапе стало понятно, что проект портирования выгрузки Overlake не будет никогда завершён. Не только из-за описанных выше зависимостей, но и из-за самого динамического поведения стека.

Из этой серии статей вы узнаете о, вероятно, самой глупом, легко предотвратимом и дорогом провале 21-го века, из-за которого Microsoft чуть не потеряла своего самого крупного клиента (OpenAI) и доверие правительства США.

Скучным утром понедельника 1 мая 2023 я впервые вышёл на работу в Azure Core в качестве сениор-сотрудника команды Overlake R&D, разработавшей карту выгрузки и сетевой ускоритель Azure Boost.

Azure не был для меня чем-то новым: наверно, это самая длительная моя подписка на облачный сервис, который был запущен в феврале 2010 года под названием Windows Azure.

Не был я и новичком в Microsoft: с 1 января 2013 года я был частью команды разработчиков Windows, а позже помогал выполнять миграцию SharePoint Online в Azure; в дальнейшем я присоединился к команде Core OS в качестве разработчика ядра. В ней я помогал совершенствовать ядро, участвовал в разработке и реализации платформы Container, поддерживающей Docker, Azure Kubernetes, Azure Container Instances, Azure App Services и Windows Sandbox. Выпуск всех этих технологий привёл к получению множества патентов.

Кроме того, я участвовал в мозговом штурме при создании прототипов карт Overlake в 2020-2021 годах, в составлении драфта предложения коммуникационного протокола и сетевого стека Host OS <-> Accelerator Card ещё на том этапе, когда у нас было лишь последовательное соединение отладчика. Также меня привлекали в качестве специалиста по Core OS, и я помогал разработчикам Azure Core диагностировать глубокие проблемы операционной системы.

В 2023 году я вернулся в Azure сразу в должности специалиста, поскольку уже внёс свой вклад в разработку некоторых из технологий, лежащих в основе Azure, и будучи её пользователем в глобальных масштабах больше десятка лет, как снаружи, так и внутри Microsoft.

Так как я был вернувшимся сотрудником, то пропустил обучение для новичков и получил приглашение Global Security на полдень для получения своего бейджа, но мой будущий менеджер спросил, смогу ли я прийти раньше, потому что тем утром у команды должно было состояться ежемесячное совещание по планированию.

Всем привет! Сегодня предлагаю вместе со мной решить интересную машину на платформе Hack The Box. На пути мы столкнемся с необычной XSS, уязвимостью в названии функций, приводящей к удаленному выполнению кода и совершим самый настоящий побег из docker контейнера. Интересно? Тогда приуступим!

За 6 лет работы продакт-менеджером в разных решениях для автоматизации проектов я видел одно и то же много раз: выбирают систему по чек-листу — «есть Гант? есть ресурсы? есть бюджеты? берем!». Через n месяцев оказывается, что не так уж и важен сам факт наличия функций. Невозможность адаптировать продукт под реальные процессы — вот что заслоняет собой все остальное.

Типичные ситуации: купили систему X — удобно для простых проектов. Выросли, нужны сложные зависимости — уперлись в потолок, пришлось мигрировать. Взяли мощную корпоративную платформу — любое изменение требует заявки в IT и недель ожидания. Команды потихоньку работают в таблицах и простых таск-трекерах.

В статье вы найдете:

— еще одну неприятную историю о ведении проектов — с подсчетом денег в чужих карманах; 

— 4 проблемы жестких систем и их решения из моей собственной практики;

— разбор трансформации low-code Waterfall инструмента в Agile всего за неделю неспешной работы.

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

Это история про рейдизайн (и немного рефакторинг) раздела управления облачными расходами в нашей платформе для управления затратами на ИТ-инфраструктуру «Клаудмастер». И сделали так, что вместо 2 минут клиенты стали проводить в разделе 10, используя его функции в полном объеме.

В индустрии проектирования, строительства и управления недвижимостью сегодня много говорят о «цифровизации», «информационном моделировании», о использования в работе «BIM / ТИМ — моделей», о формировании «Цифрового двойника (Digital Twin)». Однако термины BIM (Building Information Modeling) / ТИМ (Технология Информационного Моделирования) и Цифровой двойник (Digital Twin) часто используются как синонимы, что является не совсем верным. Для участников проекта объекта капитального строительства (ОКС), заказчика, инвестора и главное, для службы эксплуатации понимание этой разницы — вопрос не терминологии, а миллионов рублей сэкономленного бюджета и часов простоя в случае использования их в своей работе, но шума обсуждений много, как понять что использовать?

В этой статье я разберу, что есть что, в чем разница и почему переход от BIM / ТИМ - моделей к цифровому двойнику важен для жизненного цикла (ОКС).

Главной темой форума 3 апреля 2026 года станет путь к инновационному и высокотехнологичному государству.

Не прячась за красивыми словами перейдём к делу: ниже вкратце описаны основные шаги и проекты стратегии по развитию и процветанию России до 2100 года.

История о том, как мы пришли к созданию собственного облачного хранилища, больше для передачи файлов, чем хранения!

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

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

Сообщения на сайте, в VK или Telegram — управлять запросами из чат-ботов можно, интегрировав service desk с каждым каналом напрямую или через единую бот-платформу. У каждого подхода свои плюсы, и иногда заказчик не хочет «или-или» — ему нужны два способа одновременно. 

Что найдете в статье: 

— почему наш клиент использует и прямую интеграцию и бот-платформу;

— как делится ответственность между клиентом и поддержкой сервис деска; 

— от запроса в боте до заявки — как выглядит типичный путь пользователя; 

— чем отличаются популярные конструкторы ботов и какой из них выбрать.

Знаете, что общего между щенком лабрадора и корпоративным AI-проектом? Оба сначала кажутся милыми и недорогими, а через полгода жрут столько, что хочется плакать. Только щенок хотя бы ласкается, а нейронка просто молча выставляет счет за GPU. В этой статье мы вместе с Александром Меркушевым (AI-консультант, архитектор облачных и AI решений, руководитель экспертной группы по внедрению ИИ в Яндексе) разбираемся, как AI меняет структуру инфраструктурных затрат, что с этим делать уже сейчас и, главное, поможет ли тут FinOps.

Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram.

Сегодня обсудим развёртывание агентов, созданных в Yandex Cloud AI Studio Agent Atelier. Atelier — это такой очевидный UI для настройки PromptTemplate для Responses API.

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

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

На этом фоне технология Single Sign-On (SSO) из удобной опции превратилась в базовый элемент современной инфраструктуры доступа. Она позволяет централизовать аутентификацию и убрать избыточные проверки, не снижая (а при правильной реализации — повышая) уровень безопасности.

Разберёмся, как SSO устроен на уровне протоколов и архитектуры, и как эта технология реализована в системе для многофакторной аутентификации и контроля доступа MULTIFACTOR.

Меня зовут Дмитрий Деев, я руководитель отдела IT-инфраструктуры в Ви.Tech - IT-дочке ВсеИнструменты.ру. В рамках нашего подкаста я поговорил с Ильей Кочневым, директором сопровождения информационных технологий в Lamoda Tech. Илья - более 20 лет в эксплуатации, начинал юникс-инженером, строил инфраструктуры в банках, нефтянке, e-commerce, открывал дата-центры в нескольких странах, мигрировал в облака, из облаков и между облаками.

Говорили про FinOps. Не про «культуру осознанного потребления» и не про «надо экономить», а про то, как это реально работает и когда вообще стоит этим заниматься.