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

Иногда мне нужно быстро проверить свой VPS: посмотреть нагрузку, глянуть логи или перезапустить сервис. Каждый раз открывать ноутбук и подключаться по SSH ради пары команд было неудобно, поэтому я решил сделать Telegram‑бота. Сначала думал, что всё будет довольно просто: Telegram → SSH → сервер. Но по ходу разработки выяснилось, что само SSH‑подключение — как раз самая простая часть. В статье расскажу, с какими проблемами я столкнулся и как в итоге их решил.

Каждый раз управляя облаком, мы совершаем повторяющиеся действия: создаем сеть, виртуальную машину, настраиваем правила Firewall и NAT… Все это интересно и удобно первые несколько раз, а потом тебя начинает напрягать не самый отзывчивый интерфейс и кликов по UI набегают сотни, а то и тысячи в месяц. Но ведь можно же делегировать все эти рутинные приседания ИИ-агенту?

Да, именно так мы и сделали у себя в Облаке VMware, но спокойствие, в этой статье мы его вам продавать не будем. Здесь расскажем тем, кто администрирует свой дата-центр или облачный тенант на базе VMware, как прикрутить к нему Claude Code, Open Code или любого другого MCP-совместимого агента без написания собственной обертки над API. Ну и само собой, мы сделаем это так, чтобы разбушевавшийся агент не смог наворотить лишнего, даже если очень захочет.

Владелец интернет-магазина столкнулся с резким ростом нагрузки на сервер: CPU доходил до 98–100%, а количество платных обращений магазина к товарной платформе выросло примерно в 6–7 раз. Сначала происходящее выглядело как DDoS-атака. На практике основную проблему создавал распределённый автоматизированный HTTP-трафик: боты и парсеры обходили страницы магазина, нагружали сервер и косвенно вызывали обращения движка OT Box к OTAPI. В статье разбираю, как устроена эта цепочка, почему обычная защита от DDoS не всегда решает такую проблему и что изменилось после фильтрации трафика.

На одном из проектов нам потребовалось развернуть систему централизованной аутентификации и авторизации для 25 000 – 30 000 активных пользователей, территориально распределенных по всей стране. Такая специфика диктует жесткие требования к масштабируемости и надежности системы. Наш выбор пал на Keycloak как на популярное open-source решение.

Но одиночный сервер Keycloak физически не способен обеспечить необходимую пропускную способность и гарантировать SLA при таком объеме трафика. Кластеризация стала единственным жизнеспособным вариантом, так как она позволяет горизонтально масштабировать вычислительную мощность и обеспечивает отказоустойчивость.

В этой статье рассказываем про наш опыт развертывания кластера Keycloak на трех изолированных виртуальных машинах с Embedded Infinispan и JGroups. Расскажем, почему выбрали именно такую архитектуру, как настраивали, что сломалось при тестировании отказоустойчивости и как мы это чинили (включая баг, который нашли и исправили вместе с командой Keycloak).

Я архитектор и до сих пор отхожу от VMware: Kubernetes дался мне не сразу. Как выяснилось, я не один такой. С этим сталкиваются разработчики в нашей команде, которым нужно быстро освоить Kubernetes для повседневной работы. С этим же сталкиваются ИТ-специалисты широкого профиля у заказчиков: они десятилетиями эксплуатировали vSphere, а теперь уходят от него, потому что всё больше ПО поставляется в контейнерах.

Люди приходят к одному вопросу: с чего действительно начать изучение Kubernetes?

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

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

Команда VK Cloud перевела статью о том, как начать изучать Kubernetes без попыток сразу охватить всю экосистему: сначала разобраться в базовых принципах работы кластера, а затем переходить к специализированным инструментам и сценариям эксплуатации. Все схемы взяты из оригинала статьи по ссылке.

TL;DR: После миграции отказоустойчивого DHCP-сервера из «брони» QinQ-туннеля в «плоский» VLAN ответы от бэкап-ноды начали бесследно исчезать. Пакет физически покидал хост, но до адресата не доходил, при этом коммутаторы клялись, что их счетчики дропов равны нулю. 

Вооружившись tcpdump, тотальным port mirroring и дзен-терпением, мы раскрыли заговор: dhcp snooping молча уничтожал пакеты на уровне аппаратного ASIC. Самое пикантное: стек M-LAG с идентичной прошивкой вел себя радикально иначе, чем одиночный коммутатор в той же сети.

Добро пожаловать в мир сетевой магии, где порт 67 (six-seven) — это не просто абсурдный вирусный мем, а реальная причина, по которой инфраструктура вдруг решила сыграть в прятки.

Привет! Меня зовут Иванов Владимир, я системный администратор отдела выделенных серверов в Selectel. Статья будет полезна тем, кто сталкивался с ситуацией, когда пакет «в провод уходит, но не приходит», а сетевое оборудование клянется, что ничего не дропает.

Привет! Меня зовут Илья, я занимаюсь автоматизацией разработки аппаратного обеспечения в YADRO. Эта статья будет посвящена масштабированию работающего в Docker контейнере под рабочей нагрузкой инстанса Gitlab. По мере роста команды производительности Gitlab, развернутого в одном Docker‑контейнере, становится мало. И масштабирование работающего под рабочей нагрузкой Gitlab, скажем, на десять контейнеров может стать нетривиальной задачей. Далее я на нашем примере расскажу, как это разумно организовать.

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

Ответа не нашлось ни у кого, включая меня. Пошёл разбираться, и оказалось, что «диск зашифрован» и «данные защищены» - это два утверждения с разными условиями, и второе из первого не следует.

Машинное обучение для обнаружения угроз, AI-помощник администратора и контроль доступа к провайдерам нейросетей. Разберём, как NGFW-решения адаптируются к AI-изменениям ИТ-ландшафта. Что нового у российских и зарубежных вендоров, где заканчиваются возможности межсетевого экрана и какое место в AI-трансформации сетевой безопасности занимает Ideco.

За словами «AI в NGFW» скрываются разные технологии

Сравнивать межсетевые экраны нового поколения, NGFW (Next-Generation Firewall), по наличию «искусственного интеллекта» почти бессмысленно. Например, Cisco предлагает генеративного помощника в системе управления, а Ideco сочетает распознавание AI-сервисов с отдельной AI-аналитикой событий безопасности и конфигурации межсетевого экрана.

Поэтому вместо общего рейтинга «интеллектуальности» сравним четыре сценария:

Просто вы его так не назвали. Открытый стандарт EnvSpec Naming 1.0 — о том, что имя ресурса это модель доверия, а не удобство админа.

Стенд UAT с боевой выгрузкой — это prod по определению. Хост srv-msk-prod-db-tier1-old-02 не говорит машине ничего. Открытый стандарт EnvSpec Naming предлагает считать имя ресурса системой координат для ИБ, DevOps и инвентаризации.

Когда выбирают агент для телеметрии, обычно сравнивают поддержку протоколов, потребление CPU и удобство конфигурации. Я бы начал со следующего вопроса:

> Что произойдёт с данными, если хранилище перестанет отвечать на 30 минут, а потом вернётся обратно?

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

Меня зовут Антон Касимов, я работаю в Gals Software, веду авторский телеграм по наблюдаемости Мониторим ИТ, а в этой статье разберу семь популярных шипперов и коллекторов: OpenTelemetry Collector, Grafana Alloy, Vector, Fluent Bit, vlagent, vmagent и vtagent. Для каждого шиппера рассмотрю следующие вещи: батчинг, очередь, поведение при недоступности бэкэнда, ключевые настройки и минимальный пример конфигурации.

Это не синтетический рейтинг кто быстрее, выше, сильнее. У инструментов разная специализация и разные единицы измерения. Очередь в 1000 OTLP-запросов нельзя честно сравнить с очередью в 10 ГБ или с WAL длительностью восемь часов. В проектах я сам периодически сталкиваюсь с проблемой выбора, поэтому тема для меня достаточно животрепещуща. Возможно, она окажется такой и для вас.

Netstat давно считается устаревшим, ps aux может обрезать командные строки, а стандартный top придется донастраивать… Однако мы всё равно набираем эти три команды для проверки, потому что так было написано в учебниках. Под катом расскажу, что реально стоит использовать вместо классики, и где старое-доброе всё ещё уместно.

Привет, Хабр! На связи инженеры департамента информационных технологий iCore.

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

В этих условиях классическое ручное администрирование заходит в тупик. Появляются и копятся временные решения – «костыли», документация устаревает в момент написания, а расследование любого инцидента превращается в детектив с поиском того, кто и когда изменил конфиг в обход всех регламентов (они, кстати, тоже не успевают обновляться и соответствовать темпам роста).

24 сентября в 11:00 МСК проведем бесплатный вебинар о том, как контролировать фактическое использование лицензий 1С, находить свободный резерв и принимать обоснованные решения о закупках.

Программа вебинара и регистрация

Привет! Я Денис, старший бэкенд-разработчик в Selectel. В предыдущих частях мы познакомились с архитектурой Apache Iceberg, а также развернули и настроили каталог метаданных.

Итак, у нас есть данные в S3‑хранилище, аккуратно организованные средствами Iceberg, и каталог, который знает расположение актуальной версии каждой таблицы. Казалось бы, все готово. 

Однако при ручном просмотре S3-бакета ничего похожего на таблицу не обнаружится — видны лишь вложенные папки с Parquet-файлами и JSON-метаданными. Да, Iceberg и каталог решили задачу хранения и версионирования, но не ответили на вопрос, как читать эти данные с помощью SQL.

И вот возникает практическая задача: как аналитику или инженеру обратиться к Iceberg-таблице посредством SQL, не поднимая Spark-кластер и не перенося данные в отдельную СУБД?

Ситуация на российском рынке NGFW-решений меняется. Он стал прозрачнее, тестировать самостоятельно десятки решений больше не нужно. Мы сопоставили открытые сравнения NGFW, лабораторные испытания, оценки рынка и исследования пользовательского опыта, чтобы разобраться, какие выводы из них действительно можно сделать.

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

Какие исследования легли в основу метаанализа

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

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

Однако почти сразу я столкнулся с тем, что встроенной оперативки моего роутера (256 МБ) перестало хватать. Запустил AdGuard Home, telemt‑форк под OpenWRT, далее попробовал поднять v2ray со списками разрешенных серверов — и тут же OOM безжалостно начал убивать процессы.

Кажется, что можно было купить новый роутер, с большим количеством оперативки — но роутеры с 1Гб или более RAM сейчас стоят недешево. И тут меня посетила идея: «А что если взять старый смартфон в качестве сервера?».

В этом гайде я расскажу, как пройти путь от выбора и покупки б/у телефона на торговой площадке до рабочего мини-сервера под управлением PostmarketOS с Podman и запущенным на нём AdGuard Home. А также как я облажался в процессе этого пути, прилично ограничив возможности моего сервера.

От YAML-манифеста до работающих контейнеров: разбираемся, что Kubernetes делает после kubectl apply.

Как systemd превратил обычный скрипт перезапуска в бесконечный дедлок — почему мониторинг не заметил собственную смерть

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

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

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

Привет, Хабр! Миграция большого числа рабочих станций с Windows на Astra Linux — это не запуск установщика и не вечерняя переустановка ОС на одном компьютере. Это проект, в котором нужно провести инвентаризацию парка, проверить совместимость, согласовать сроки, сохранить данные, настроить доменную интеграцию, проконтролировать результат и разобрать ошибки. Вручную это потребует значительных ресурсов ИТ-служб.

Astra Migration — клиент-серверное решение, которое берёт эту работу на себя. Оно состоит из серверной части с веб-порталом, агента для Windows и компонентов для установки и первичной настройки целевой ОС. В статье хочу рассказать из каких частей состоит Astra Migration, как выглядит путь от установки серверной части до первой загрузки Astra Linux, что такое сценарии и волны миграции, зачем нужны блокеры и какие дополнительные детали раскрываются в решении.