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

С мая 2026 года электронная почта в домене @tut.by заблокирована. Для тысяч компаний и ИП в Беларуси это означает, что канал рабочей переписки потерян, а восстановление доступа в сервисы внезапно перестало работать. 

Мы в поддержке платёжного сервиса ExpressPay столкнулись с этим на конкретном кейсе. У клиента перестали приходить уведомления. Система отправляла письма на корпоративный ящик, а до получателя они не доходили. Человек неделю думал, что у него «сломалась интеграция», хотя сломался домен почты. Это типовая картина: первым ломается не то, что замечаешь сразу, а то, что работает в фоне — уведомления, чеки, подтверждения.

Разбираем причины, контекст с Указом №60 и пошаговую миграцию на собственный домен.

Привет, Хабр! Импортозамещение инфраструктурного стека 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. 

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

Привет! Я — Саша Басун, инженер направления пользовательских ИТ-сервисов в «Петрович-Тех». Сегодня я пришёл к вам с историей о том, как вывод значения ключа из реестра Windows может упростить обработку заявок в отделе технической поддержки.

Если коротко: помощь со стороны нашей техподдержки нередко начиналась с мема «Давайте поможем Даше найти Internet-ID на рабочем столе». Тут нет-нет, да все стадии от гнева до принятия пройти придётся. В итоге после заявки, которая пришла уже мне, родилось маленькое, но изящное решение на C#. 

Если у вас российский номер, my.telegram.org с VPN выдаёт ERROR при создании приложения, а без VPN вообще не открывается. Антифрод сверяет страну номера и страну IP - и они не сходятся. Разбираю, почему обход через VPN - тупик, при чём тут DNS, и как получить api_id и api_hash одной строкой в файле hosts за 5 минут, без покупки номеров телефона других стран.

Виртуализация должна была упростить пользовательский опыт в больших и гео‑распределенных компаниях и снять нагрузку с ИТ‑служб. Но на практике оказалось, что перенос рабочего места в дата‑центр решает одни проблемы и одновременно создаёт другие.

Это особенно проявилось на фоне «бума» российского VDI в 2022 году. VDI отлично справляется с офисными приложениями, неплохо живёт с web‑сценариями и требует особого подхода к CAD‑ и мультимедийным нагрузкам. Но самый парадоксальный эффект проявляется в организации видеоконференцсвязи (ВКС).

Разберёмся, почему видеосвязь требует особых подходов к оптимизации, без которых цифровое рабочее место остаётся только наполовину виртуальным, какие есть российские ВКС и что делать их поставщикам, чтобы не ломался UX.

С момента выхода PiKVM в 2017 году рынок IP KVM стал активно развиваться. Я протестировал почти все из этих устройств и готов дать объективную оценку каждому.

Для удалённого управления компьютером из любой точки LAN вы можете использовать инструменты вроде Remote Desktop, Screen Sharing или VNC. И если у вас нет собственной VPN, то полноценный удалённый доступ вам помогут обеспечить RealVNC или Raspberry Pi Connect, либо можете сами настроить сеть через Tailscale или Pangolin. Всё это прекрасные решения, как и SSH, если вам не требуется графический интерфейс.

Но бывают ситуации, когда вы не хотите запускать на ПК программу для удалённого управления. К примеру, когда я удалённо выполняю бенчмарки, мне не нужно, чтобы функция совместного использования экрана отнимала ресурсы системы. Или представьте, что у вас есть компьютер, к которому вам необходимо иметь возможность удалённо подключиться в любой ситуации. В таком сценарии, если этот ПК вдруг зависнет или по какой-то причине отключится, SSH и Screen Sharing уже не помогут.

И здесь на сцену выходит технология IP KVM. В передовые серверные решения она встраивается по умолчанию (к примеру, в HP iLO, Dell iDRAC или IPMI), но не у всех есть доступ к серверным материнским платам. И даже если он есть, BMC (Baseboard Management Controller) может оказаться сильно устаревшим, или же вы можете решить подключиться с использованием установленного GPU, а не встроенной VGA-графики.

Привет! Меня зовут Максим Черотайкин, я инженер 1С в Selectel. Практически каждая компания использует 1С, когда ей нужно автоматизировать учет и бизнес-процессы, а также вовремя сдавать отчетность. Платформу можно запустить на разных операционных системах: Windows, macOS и других. Однако многие специалисты избегают Linux, потому что в нем нет графической оболочки и он кажется сложным для работы. В статье хочу убедить вас, что на самом деле это просто. Для этого мы установим 1С на сервер Linux в облаке своими руками.

И так, вы в Telegram Web и вы запускаете безобидное на первый взгляд Mini App, сворачиваете его или просто переключаетесь на соседний приватный чат, чтобы продолжить переписку. Казалось бы, контексты изолированы, фрейм приложения неактивен, и вы в полной безопасности. Но так ли это на самом деле?