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

Меня зовут Григорий Орлов, я руководитель команды разработки сетевых сервисов гибридных облаков в 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. Не про «культуру осознанного потребления» и не про «надо экономить», а про то, как это реально работает и когда вообще стоит этим заниматься.

Иметь свой мессенджер — больше не роскошь, а страховка от блокировок. В условиях, когда привычные инструменты могут исчезнуть в любой момент, полный контроль над перепиской становится вопросом выживания бизнеса. Рассказываем, как поднять Rocket.Chat “в облаке”: от простого Docker Compose до отказоустойчивого Kubernetes-кластера

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

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

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

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

Но по какой-то неведомой нам причине (тут должна быть реальная причина, но ее не будет, вы и так все знаете) - телеграм объявлен вне закона, и вообще дел с ним иметь не стоит…

Привет, Хабр! Эту статью написал вендор ITSM-решений. Поэтому вы вправе ожидать толстого самопиара в духе «мы лучше всех, выбирайте нас». Но мы пойдем другим путем.

За годы работы накопились сотни разговоров с клиентами — кто уходил и кто возвращался. Мы научились видеть в этих историях закономерности, о которых в отрасли не принято говорить вслух.

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