Системное администрирование *

Рано или поздно большинство зрелых проектов приходят к необходимости использовать как виртуальные машины, так и выделенные серверы. Это логично, поскольку под разные задачи требуются разные вычислительные ресурсы. Однако затем возникает проблема управления физическим оборудованием.

В этой статье подробно разберем концепцию, которая позволяет взаимодействовать с выделенными серверами так же легко, как с облачными. На практическом примере развернем гибридную инфраструктуру в разных дата-центрах исключительно средствами Terraform. Объединим разрозненные хосты в общую приватную сеть.

Привет! На связи Сергей, системный администратор в Selectel. Надеюсь, этот обзор будет полезен системным администраторам, DevOps-инженерам, архитекторам и всем, кто хочет избавиться от путаницы в процессах и управлять пулом гибридных вычислительных ресурсов через один инструмент.

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

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

В итоге значительную часть работы теперь можно выполнять вообще на удалёнке!

Полтора месяца моя рабочая машина умирала. Не BSOD, не перезагрузка — именно умирала: экран чёрный, вентиляторы на видеокарте выходят на сто процентов и так и остаются. Никакой реакции ни на что. Только кнопка Reset.

Сначала раз в неделю. Потом два. К середине июля — три раза за сутки.

Но хуже самих зависаний было другое: после них не оставалось ничего. Ни дампа, ни минидампа, ни BSOD, ни единой записи WHEA. В журнале — Event 41, Kernel-Power, «система была перезагружена, завершив работу некорректно», BugcheckCode = 0. Windows даже не успевала понять, что умерла.

Отлаживать нечего. Есть только труп и никаких улик.

Забегая вперёд: виновата оказалась не память, не драйвер и не блок питания, хотя я последовательно подозревал всех трёх. Виноват был PCIe Gen5. Лечится одним пунктом в BIOS. Полтора месяца страданий лечится одним пунктом в BIOS.

Жизнь диссидента-экспериментатора не сидит на месте, а копилка безумных находок пополняется быстрее, чем успеваешь про них написать. Продолжаем то, на чем остановились в прошлый раз - туннели через ICMP, DNS и serverless-функции это, конечно, хорошо, но вот вам еще три свежие находки: туннель через что угодно, что умеет хранить файлы, туннель через почтовый ящик, и реанимация древней технологии обхода через CDN и не только, которую почему-то все забыли.

Я сжёг на Hermes около 500 миллионов токенов. Это примерно $1000 при оплате моделей без подписок. Я дал агенту доступ к своей домашней лаборатории. Он написал несколько полезных скриптов. Настроил GPU passthrough и транскрибацию, но заодно ломал собственный gateway, ронял Caddy и регулярно игнорировал явно прописанные скиллы.

Это разбор реальной эксплуатации. Hermes иногда экономил мне время. Но слишком часто он проигрывал обычным скриптам и n8n. После полумиллиарда токенов Hermes оказался для меня дорогой игрушкой, а не рабочим инструментом.

Система блестит, дашборды красивые, а спросишь её что попроще — врёт. Потому что залили мёртвые данные и сократили углы на справочниках.

Рассказываю, как внедрял, где обжигался и что делаю теперь, чтоб не повторялось.

Короткая история про то, как штатная замена ноды оставила quorum-очереди с двумя членами вместо трёх, и почему cluster_status этого не показывает.

Стенд: OpenStack Caracal (2024.1), развёрнут kolla-ansible. RabbitMQ — кластер из трёх нод, quorum-очереди.

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

Этот материал — не глубокий разбор технологий с погружением в архитектурные детали, а скорее обзор эволюции подходов к построению технологического контура. Давайте обратимся к истории и вспомним, чего мы ждали от ИТ-инфраструктуры на разных этапах технологического развития. И почему сегодня выигрывают не самые несокрушимые, а самые «антихрупкие» системы.

Привет, Хабр. Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для Terraform. В предыдущей части мы поговорили о принципиальных причинах неудач и проблем открытого провайдера terraform-provider-ovirt, сделали выводы. Пятая статья цикла будет посвящена ключевым решениям, принятым в ходе разработки собственного закрытого провайдера инфраструктуры zVirt для Terraform. Эта статья может быть полезна всем, кому предстоит разработка провайдера под специфичный API, слабо совместимый с концепциями Terraform. Мы разберем основные архитектурные решения, обозначим сознательные концептуальные ограничения и приведем пример построения не самой тривиальной «системы поверх системы» для улучшения пользовательского опыта.

Прерываемые ноды в Managed Kubernetes появились ещё в феврале 2025 года, и Selectel анонсировал их отдельной статьёй в своём блоге — про экономию до 70% и про то, что «нода оперативно вернётся в кластер, а восстановление займёт не более минуты». Про поды, которые в этот момент на ноде работают, там не сказано ничего: ни про SIGTERM, ни про drain, ни про PDB, ни про потерю данных. Как раз эту дырку мы и полезли закрывать.

Коллеги, добрый день!

Я Станислав Калабин, инженер-архитектор компании Axel PRO. Моя ежедневная задача – воплощать строгие требования информационной безопасности (ИБ) в работающую сетевую инфраструктуру наших заказчиков.

Если раньше доверяли всему внутри периметра и защищали сеть с помощью мощного межсетевого экрана (Firewall) на границе, то сейчас эта модель устарела. Удаленная работа, облачные сервисы и распределенные офисы размывают границы сети. Современная атака начинается не со штурма МСЭ, а с фишингового письма сотруднику. Оказавшись внутри, злоумышленник пользуется абсолютным доверием. Ответом на эти угрозы стала архитектура Zero Trust – «никому ничего не доверяй». Её главные принципы – явная верификация каждого запроса, минимальные привилегии и готовность к инциденту.

В этой статье я расскажу о самом принципе Zero Trust и как современные NAC-системы, на примере платформы AxelNAC, решают задачи ИБ, минимизируя нагрузку на сетевых инженеров при внедрении.

Привет, Хабр! Эта статья — часть серии к 25-летию SpaceWeb. Раз в две недели берем спорный вопрос про будущее хостинга и инфраструктуры и зовем двух-трех экспертов, которые смотрят на него по-разному.

Сегодня спорим о том, способен ли ИИ придумать архитектурное решение, которого раньше не было. Виталий считает, что способен. Алексей отвечает, что система, которая кормится готовыми знаниями, ничего не изобретет с нуля.

Привет, Хабр! Меня зовут Артем Токарь, я младший инженер технической поддержки в К2 Кибербезопасность. Наша команда работает в составе Центра экспертизы по комплексному сервису К2Тех и занимается администрированием средств защиты информации. В том числе мы защищаем сайты заказчиков от веб‑атак — стоим на границе между приложениями и теми, кто к ним обращается.

Я расскажу, как мы искали способ бэкапить свой WAF так, чтобы не разориться на облаке и при потенциальном откате не потерять несколько дней ручной работы.

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

На конференции Advancing AI 2026 AMD представила шестое поколение серверных процессоров EPYC 9006 (Venice). Новая линейка построена на архитектуре Zen 6, выпускается по 2-нм техпроцессу TSMC и включает процессоры с числом ядер до 256. Кроме роста производительности, AMD сделала ставку на специализацию: новые CPU разделены на несколько семейств для облачной инфраструктуры, HPC и AI.

Разбираемся, что именно представила компания, чем новые EPYC отличаются от предыдущего поколения и какие процессоры войдут в новую линейку. И когда увидим их в России.

macOS — сертифицированная UNIX система (формально — UNIX 03), и большая часть того, что набираешь в терминале, ведет себя, как в любом BSD: ls, grep, ps, ssh — все на месте. Но рядом лежит второй слой команд, которого нет ни в одном дистрибутиве Linux и нет в POSIX: defaults, sysadminctl, mdfind, say, afplay. 

Часть из них выросла из архитектуры Darwin, часть — из графической и звуковой подсистем, а часть существует исключительно ради управления экосистемой Apple.

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

Когда приходишь на аудит СУБД к разным компаниям, картина удивительно похожа: одни и те же проблемы, одни и те же причины. Меня зовут Андрей, я DBA в группе поддержки системного ПО Центра экспертизы по комплексному сервису К2Тех, сертифицированный эксперт Postgres Pro. В этой статье представлен ТОП-10 ошибок, с которыми мы встречаемся чаще всего. Я разберу, чем они опасны, почему возникают, и как их можно решить. Скорее всего, многие пункты покажутся вам до боли знакомыми:

Управление десятками и сотнями Helm-релизов быстро перестает быть тривиальной задачей, особенно когда появляются зависимости между релизами, CRD, несколько окружений и своя логика деплоя. 

Меня зовут Владимир Фидунин, я работаю в команде мессенджера VK WorkSpace. В статье расскажу, как мы прошли путь от Puppet + Helm до Helmwave и почему в итоге он стал для нас универсальным инструментом управления Helm-релизами. 

Со временем у меня появилось несколько серверов: VPS, домашний NAS и ещё пара машин под разные задачи. Для подключения я использовал PuTTY. Он работает, но управлять несколькими серверами в нём неудобно. Сессии хранятся в реестре Windows, список хостов плоский, вкладок нет. Чтобы открыть два сервера, нужны два отдельных окна.

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

Мне не хотелось регистрироваться и загружать список своих серверов в облако ради обычного SSH‑подключения. Поэтому я начал делать собственный клиент - LucidSSH. Это не попытка собрать ещё один комбайн для системных администраторов. Мне нужен был простой локальный SSH‑клиент с несколькими дополнительными функциями: защитой от опасных команд и понятными объяснениями ошибок.

Я не занимаюсь администрированием каждый день. Поэтому делал программу прежде всего для таких же пользователей, как я: тех, кто впервые настраивает VPS, NAS, Raspberry Pi или небольшой домашний сервер. Разрабатываю LucidSSH в свободное от основной работы время.

Разработчикам регулярно требовались виртуальные машины, но self-service не существовал. Образ, ресурсы, сеть и доступы настраивала инфраструктурная команда. По отдельности операции были несложными, но в сумме пользователи ждали, а инженерное время уходило на повторяемую ручную работу.

Так появился внутренний dev cloud на KubeVirt. Разработчик сам создаёт VM из поддерживаемого шаблона, управляет lifecycle и портами, меняет ресурсы, смотрит Events, метрики и serial-консоль. Платформа сохраняет контроль над доступами, шаблонами, бюджетами команд и ёмкостью нод.

В статье показано как на базе KubeVirt получился цельный внутренний продукт с минимальными трудозатратами, в котором разработчик действует самостоятельно, а платформа сохраняет контроль над dev-контуром и блокирует создание VM сверх бюджета команды.

Откройте терминал и выполните cat /etc/hosts. Скорее всего, там лежит пара строк про localhost и, может быть, несколько ваших локальных записей… А когда‑то этот файл содержал адреса всех компьютеров интернета и обновлялся по телефонному звонку. Под катом расскажу, как весь интернет работал через один текстовый файл, кто его обновлял и куда он в итоге делся.