Администрирование

Я делаю VantageDNS, recursive DNS-resolver с фильтрацией. То есть прямой конкурент всех, про кого пишу ниже. Это, мягко говоря, неудобный жанр: писать сравнение продуктов, в котором ты сам участвуешь, это как быть судьёй на матче своей же команды.

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

Мне реально интересно, как выглядит расклад в 2026 году, потому что юзеры регулярно пишут в саппорт «а почему не NextDNS» или «а что там с AdGuard». Хочу один раз ответить нормально.

Доброго времени суток, в общем, в компании, в которой я работаю, используется Ivideon-server версии 3.9.0 либо 3.12.0. И появилась огромная потребность в мониторинге камер: их доступности, а также, пишется ли архив с этих камер. Поэтому я начал разработку шаблона Zabbix, который бы опрашивал сервера с Ivideon-server по API. Начал я с того, что с помощью WireShark я разобрал работу Ivideon Client.

Сегодня прошло мероприятие VK Cloud Conf 2026, чего было интересного...

Одной из интересных концепций, которую удалось подметить и на которую мы раньше обращали мало внимания: возможность мониторить ошибки на толстом клиенте. Однако если специалист по продукту рассказывал, что это просто интересный инструмент, к которому они подключили ClickHouse, то мы с ним дошли до обсуждения, что ИИ-агенты могут работать явно больше 3,5…15 часов, если получают подробный и отфильтрованный и прошедший отдельную оценку разбор ошибок на клиенте и сервере. 

Вы вставляете в код небольшой JS-скрипт, как при подключении Яндекс-метрики, но он мониторит не только трафика на Ваш сайт, но и то, что у пользователя запустилось, с какого устройства появилась проблема в работе боевого сервера (IPhone / Android / Windows / …). Когда Вы пытаетесь проанализировать ошибки без специальных инструментов, нужно писать кучу разрешений о выводе ошибок, строчить явно не 10 строчек кода, которые на клиенте проанализируют проблему. А здесь вы просто доверяетесь инструменту, где все это сделано за вас. Но прелесть в том, что ваш агент, анализируя и пересматривая результат своей генерации кода, может анализировать именно сообщения и ошибки, «подготовленные на блюдечке» этой тулзой, что повышает результативность работы ИИ-агентов.

Система Битрикс24 может интегрироваться с внешними сервисами, имеющими отношение и значение для бизнеса. Это существенно расширяет возможности CRM и ее пользователей. Взаимодействие может осуществляться как с помощью готовых решений, так и с нуля – с помощью интерфейса программирования REST. Вместе с техническими специалистами CRM Академии попробуем разобраться, как такая интеграция работает, что дает, и для каких сценариев годится.

Я очень рад, что существует такая технология, как Docker, и внедряю её в проекты и инфраструктуру клиентов. Однако есть одно «но»: многие не понимают, что это и зачем оно нужно, а объяснять иногда достаточно сложно (особенно повторять каждый раз каждому человеку, да и есть шанс что-то упустить). В этой статье вы узнаете базу по Docker, где найти практику и актуальные знания. Технология будет полезна многим: от специалистов по безопасности до разработчиков. А сама статья будет познавательна для тех, кто только изучает работу Docker и хочет узнать ответы на вопросы, которые часто задаются на собеседованиях, где требуется Docker. Приступим!

Типовая ситуация: Terraform-конфигурация выглядит привычно, а ИИ-агент экономит время на рутинных операциях. Но потерянный state-файл и один terraform destroy способны за минуты снести прод вместе с базой данных и снапшотами.

В этой статье разберем реальный инцидент, восстановление через AWS Support и защитные механизмы, которые появились в инфраструктуре после аварии.

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

В этой статье я расскажу про развитие гипервизоров: от появления системного вызова chroot(2) до возникновения идеи о виртуализации в браузере…

Большинство материалов по Cisco, Linux и GNS3 до сих пор ориентированы на VMware Workstation.

В последнее время возникли две проблемы.

Во-первых, официальный сайт GNS3 недоступен напрямую с территории РФ, из-за чего скачивание необходимых компонентов превращается в отдельную задачу.

Во-вторых, GNS3 рекомендует использовать VMware Workstation, который также недоступен с территории России.

В этой статье покажу, как собрать полноценный стенд на компьютере под управлением Windows 11. Мы установим GNS3 и создадим виртуальные машины GNS3 VM и Ubuntu 26.04 LTS в гипервизоре Hyper-V.

В результате получим готовую площадку для изучения компьютерных сетей и Linux.

Привет, Хабр! Импортозамещение инфраструктурного стека Microsoft — задача, с которой периодически сталкиваются большие российские компании и субъекты критической инфраструктуры (КИИ). Служба каталога, менеджер конфигураций, корпоративный центр сертификации — всё это годами держалось на решениях одного вендора. Но все знают, что за последние 5 лет всё кардинально поменялось, и нужны решения, способные реально заменить существующий 30 лет стек.

На Хабре уже выходили материалы про аналоги Active Directory. Настал черед поговорить про коробочные решения, уже заменяющие стек Windows + AD + SCCM + CA. Речь идёт об Astra Server Core, совместной платформе «Группы Астра» и компании «Аладдин». Решение представляет собой Astra Linux Server с корпоративным центром сертификации Aladdin Enterprise CA (eCA), службой каталога ALD Pro и менеджером конфигураций ACM.

Я поговорил об этом стеке с директором серверного ПО «Группы Астра» Алексеем Фоменко и генеральным директором компании «Аладдин» Сергеем Груздевым. Мы обсудили, из чего состоит платформа, как организована миграция с Windows-инфраструктуры без остановки сервисов, какие специалисты нужны для внедрения и как обстоит дело с совместимостью с другими российскими ОС.

Приятного чтения!

Портал есть, каталог на 200 услуг есть, база знаний есть. А сотрудник всё равно звонит на первую линию. Разбираем, почему так — и что реально меняет ИИ, честно, со слабыми местами.

В какой‑то момент у меня накопилось несколько VPS у разных провайдеров. Не десятки, но уже достаточно, чтобы каждый месяц ловить себя на одной и той же мысли: «А этот сервер когда оплачивать?»

Ссылка на биллинг — где‑то в закладках. Дата продления — в Telegram. Пароль от кабинета — в другом месте. Таблицы, заметки, все разбросано. Пока серверов немного, это ещё работает. Когда их перевалило за 15, начинаешь постоянно все терять. Кто хостер, а что там крутится, вкладки, вкладки, вкладки!

Так появилась идея: сделать личный кабинет для своих серверов.

Сколько существует ПО, столько админы и программисты спорят о свободном и несвободном ПО.  Тема эта древняя и, казалось бы, все участвующие в споре стороны давно определились с лагерем, за который они “топят».

И так бы все и продолжалось, если бы в 2022 году картинка радикально не поменялась. Такие привычные и понятные продукты ушли из России, оставив многих перед необходимостью искать альтернативы. На встречах с заказчиками я начал снова все чаще слышать старые вопросы: «А объясните мне, что такого плохого в OpenSource?» и «Почему вы мне рекомендуете платное, если есть прекрасная бесплатная альтернатива?». Если на этом месте сразу захотелось прекратить читать и нажать на крестик, я дам быстрые ответы: между Open Source и проприетарным ПО гораздо больше общего, чем принято считать, а выбор по принципу «платное ПО или нет» – абсолютно неверная стратегия.

Если вы еще читаете, то давайте разбираться.

Привет, постоянные и не очень читатели!

Недавно на Хабре вышел лонгрид «Поймай меня, если сможешь [часть 1]: облако на Huawei Cloud Stack — что это, как используют и лицензирование», в котором я рассказал про платформу Huawei Cloud Stack (HCS) — как она устроена и почему крупные компании вообще смотрят в её сторону, там же про архитектуру, лицензирование и многое другое.

Но платформа HCS больше, чем сумма её частей: первый лонгрид (при всех моих стараниях) всё равно получился лишь аннотацией к Сильмариллиону. Той теории достаточно для поверхностного знакомства, теперь же обсудим подготовку к миграции: аудит инфраструктуры, разберёмся с RPO и RTO, посмотрим на совместимость виртуальных машин и образов, а самое главное — обсудим стратегии миграции по методологии AWS, которые можно применить не только к HCS, но и к любому другому облаку.

Привет, Хабр. Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для Terraform. В предыдущей части мы честно попробовали воспользоваться опенсорс-провайдером Terraform для oVirt и получили неоднозначные результаты (на самом деле вполне однозначные).  

Эта статья посвящена анализу провала проекта terraform-provider-ovirt. Посмотрим на принятые решения, поищем первопричину, оценим, как надо и как не надо делать, и выработаем основные концептуальные решения перед реализацией своего провайдера. 

Эта статья может быть полезна всем, кому предстоит написание своего Terraform-провайдера. Работа с унаследованным API, попытки натянуть одну модель управления ресурсами на абсолютно другую и необходимость предусматривать гораздо больше, чем изначально вложено в систему — все это погубило terraform-provider-ovirt и всего этого следует опасаться любому разработчику подобного решения. 

Практически все современные системы управления инфраструктурой опираются на один и тот же фундаментальный механизм — сохранённое состояние (persistent state).

Terraform хранит состояние в .tfstate, Crossplane использует Kubernetes API как систему записи, GitOps-решения строят дополнительные слои поверх Kubernetes. Архитектурные различия между этими инструментами огромны, но их объединяет одна идея: между конфигурацией и реальной инфраструктурой существует некоторое долговременное представление мира, которое считается авторитетным.

Исторически это было вполне разумно. Когда Terraform появился, облачные API были значительно медленнее, инфраструктура хуже наблюдалась, а полный обход ресурсов занимал ощутимое время. Поддерживать локальный снимок состояния было выгоднее, чем каждый раз заново опрашивать провайдера.

Проблема в том, что со временем этот снимок превратился из оптимизации в архитектурный фундамент. Вокруг него со временем выросла целая экосистема: удалённые хранилища состояния, механизмы блокировки, импорт ресурсов, синхронизация состояния с инфраструктурой, обнаружение дрейфа конфигурации, миграции состояния и другие инструменты, необходимые для поддержания согласованности между сохранённым представлением системы и её фактическим состоянием.

В какой-то момент возникает вопрос: а обязателен ли вообще persistent state как архитектурный элемент? Можно ли построить систему, которая будет работать напрямую с реальной инфраструктурой, не поддерживая отдельный долговременный слой состояния?

Штатная ситуация оказалась задачей со звёздочкой: кластер кинул алерт о том, что заканчивается сеть подов, но ни одно решение «из методички» не подходило, а вытаскивать кластер из прода было нельзя.

В статье расскажу, как мы не просто расширили подсеть подов, но сделали это на работающем кластере и не потеряли при этом данные. Что важно — трюк сработает на любом дистрибутиве Kubernetes и CNI.

Если у вас приватные репозитории на GitHub и команда, которая регулярно упирается в лимит времени GitHub Actions, эта статья сэкономит вам пару недель экспериментов. Рассказываем, как мы подняли self-hosted раннеры в Docker, настроили их репликацию через Docker Compose и почему в итоге пришли к Docker-in-Docker. Разобрали по шагам эволюцию решения от Bare Metal раннеров до докеризованной конфигурации. Репозиторий с настройкой находится в открытом доступе.

У вас есть сервер. Он числится на балансе. За ним закреплён Иванов. Иванов уволился год назад. Где сервер – никто не знает.

Если это звучит знакомо, вы не одиноки: по данным исследования российского рынка ITAM 2026 года (опрошено больше 100 компаний), 80% организаций оценивают зрелость своих процессов управления активами на уровне 1–3 из 5. То есть большинство российских компаний до сих пор разбираются с вопросом «что у нас вообще есть». До «где это стоит» и «сколько стоит» добрались единицы.

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

Когда-то давно, конвертеры среды (медиаконвертеры) были довольно простыми устройствами, и если вам нужно было подключить два медных гигабитных коммутатора по оптоволокну, нужно было купить два гигабитных медиаконвертера.

Если же нужно было подключить что-то имеющее только 100 мегабитный порт, то нужно было купить 100 мегабитные медиаконвертеры.

Потом появились медиаконвертеры с преобразованием скорости. Можно было бы порадоваться-стало удобно, но тут есть одно фундаментальное различие между ними, и оно очень важное.

Изначально медиаконвертер — это конвертер среды передачи, то есть он преобразует электрический сигнал в оптический и наоборот. Разумеется, там не все так просто, но главное, это уровень L1 в модели OSI.

Но так работает только если у вас и медный и оптический порты, работают с одинаковой скоростью.

Как только вам нужно иметь разные скорости, вам понадобится как минимум буфер.

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

Чем это плохо спросите вы? да в общем для медиаконвертера плохо по целому ряду причин.

По сути, если вы соединяете через такие медиаконвертеры, например два хороших, дорогих коммутатора (скажем Huawei), вы между ними ставите два неуправляемых коммутатора. 

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

Привет! Я Владимир Карагиоз, работаю техническим лидером по развитию гибридных облачных решений в Cloud.ru и увлекаюсь популярными в 90-х годах рабочими станциями Sun SPARCstation 5. У меня есть 30-летняя машина, которую я пытаюсь привести в чувство. Я уже вылечил детскую болезнь, связанную с севшей батарейкой модуля памяти, и подготовил машину к установке операционной системы — об этом рассказал в первой части истории. В этой статье поставим на машину Solaris 2.6 и начнем завозить уют для пользователя, привыкшего к комфорту современного Linux.