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

Знакомая картина: вы написали микросервис, набросали Dockerfile из четырёх команд — и получили образ на 1,2 ГБ. В единичном случае не страшно, но этот гигабайт гоняется по сети десятки раз в день: при каждом коммите в CI, на preview-окружениях, при деплое в кластеры. В итоге — минуты ожидания пайплайнов, счета за трафик и хранение, плюс лишние системные пакеты с десятками CVE. Показываем на Node.js и Go, как ужать образ с 1,2 ГБ до 50 МБ через multi-stage — без единой строчки правок в коде.

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

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

Если вы запускаете Manticore Search на Linux, в качестве основного инструмента управления стоит выбрать systemd.

На текущий момент это общепринятая практика, хотя ранее существовали определённые ограничения. Да, Manticore Search мог работать под systemd, но интеграция обладала рядом функциональных ограничений. Архитектура демона основана на традиционных подходах Unix; systemd появился позже и хотел от службы совсем другого. Так что настройка работала, но не соответствовала современным требованиям к управлению службами.

Теперь Manticore Search поддерживает нативные уведомления systemd — это и есть главное изменение.

Почему это важно? Потому что устраняется ряд операционных проблем:

Ещё в 2022 году внедрялся Zabbix у заказчика, нужен он был для мониторинга нескольких MSSQL-серверов и был установлен на MySQL; с тех пор подключали к нему новые хосты, и начал он потихоньку умирать — всё-таки MySQL не для больших объёмов. Проблема миграции стала острой, а я как раз OceanBase последнее время занимаюсь очень активно.

Мне не удалось сразу уговорить заказчика на миграцию основного Zabbix на OceanBase, но была предложена миграция девелоперского Zabbix, который всё равно надо было переносить в целевой сегмент сети, и по результатам этой миграции уже будет принято решение о возможности миграции основного Zabbix, который на MySQL сейчас. Естественно, я согласился, хотя девелоперский Zabbix был на PG, но этот кейс даже более интересный. Мне будет очень интересно услышать отзывы или советы перед миграцией прома.

Итак, поехали.

Не расплываясь в этой статье про преимущества OceanBase, выделю только главное для Zabbix:

Привет, Хабр! Меня зовут Кирилл Кулаков, я занимаюсь развитием MLOps-платформы в Uzum Fintech.

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

И тут коллеги начали задавать вопросы «Почему мы не разворачиваем каждый компонент последовательно, настраивая все досконально?». Для меня это звучало как: «Ты сделал неправильно, сейчас будем разбирать твою работу и от половины откажемся». 

Мы строим MLOps-платформу под широкий спектр AI-задач и по ходу работы постоянно сталкиваемся с архитектурными вызовами и альтернативными решениями. 

В какой-то момент мы поняли: для одной и той же задачи мы можем собрать множество архитектурных вызовов, а потом тестировать такое же множество разных подходов. А время всё ещё не резиновое, как и силы команды. Так что мы сели и серьёзно обсудили наши методы развёртывания ИТ-платформ.

И потом я задумался, а на самом ли деле в разных компаниях и командах бывают настолько разные подходы к этому делу?

В статье предлагаю поисследовать эту тему вместе со мной.

Как дать админу доступ к виртуальным машинам на удалённом хосте без агента внутри гостевой ОС — на примере VirtualBox и Hyper-V. Один RDP-движок на оба гипервизора, три бага VirtualBox по дороге и таймаут, который переписал всю архитектуру.

Сеть может «лечь» не из‑за провайдера, не из‑за перегруженного сервера и не из‑за мистики в коммутаторе. Иногда достаточно одной L2-петли: кадры начинают ходить по кругу, broadcast‑трафик превращается в шторм, MAC‑адреса флапают, а пользователи внезапно теряют доступ к DHCP, шлюзам и внутренним сервисам.

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

Если вы работаете техническим инженером в отделе эксплуатации, то с вероятностью 99,9% вы знакомы с Prometheus и прекрасно разбираетесь в языке запросов promQL. Но даже в «родной и знакомой» сфере есть области, которые остаются вопросительными пятнами. Например, «Сравнение векторов»/«Сопоставление векторов». Это механизмы promQL, которые применяются не так часто, плохо документированы и неочевидны для понимания. Привет, Хабр! На связи Александр, руководитель кластера надёжности в компании ecom.tech, кластер надёжности занимается SRE, проводит тестирование нагрузкой и обеспечивает стек Observability. Этой статьей я постараюсь сделать вашу жизнь чуточку проще, на примерах объяснив нюансы непростой механики сопоставления.

2 июня мой мониторинг аптайма разом отрапортовал, что упало почти всё: 932 инцидента за 25 минут. Сайты были живы — все до единого. Виноваты дефолтный лимит файловых дескрипторов 1024 и «оптимизация», тихо размножившаяся в 60 раз. Разбираю по приборам: /proc, ss, EMFILE и почему docker compose restart не спасает.

Статья получилась большой: практик много, и каждая из них важна по-своему. Я собрал материал как набор best practices: не все пункты нужны каждому проекту, но почти каждый пункт однажды всплывает на ревью, при оптимизации медленного пайплайна, при разборе утечки секрета или после тяжелого инцидента.

Я старался писать для разных грейдов: от базовой гигиены вроде workflow:rules, cache, artifacts и needs до более продакшеновых тем вроде OIDC, Vault, CI_JOB_TOKEN, защищённых окружений, ревью-окружений, очередей слияния, BuildKit без root-прав, CI/CD-компонентов и усиления защиты раннеров.

Поэтому язык подачи здесь намеренно сухой, прямой и инженерный: без долгих заходов, без воды и без пересказа документации ради пересказа. Я хотел сделать не обзорную статью, а рабочую памятку, к которой можно вернуться при написании нового пайплайна, ревью .gitlab-ci.yml, переносе проекта в GitLab или наведении порядка в уже существующей CI/CD-платформе.

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

Оглавление:

1. Зачем вообще думать о GitLab CI/CD

2. Архитектура пайплайна и базовая YAML-гигиена

3. rules, workflow:rules и управление созданием пайплайна

4. DAG, needs, параллелизм, матрицы и быстрые пров...

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

Одиночный сервер «моргает» каждое утро в районе 06:xx на 10–30 секунд: сервис остановлен и тут же запущен, виновного в журнале будто нет, и даунтайм списывают то на сеть, то на GC. Кластер из трёх–пяти узлов, который спокойно переживает падение одного узла, в какой-то момент роняет себя сам: обновление с перезапуском прилетело на все узлы в одно утро — кворума не осталось.

Источник у обоих один: таймеры автообновлений с узким окном после шести утра плюс needrestart, который перезапускает не только обновлённый сервис, но и всё, что слинковано с обновившейся системной библиотекой (libssl3, libc6, zlib1g). Разберём, как подтвердить диагноз за две минуты и как развести узлы во времени — от drop-in к таймеру до координации через Ansible и PodDisruptionBudget.

Почти каждый, кто админит VDS/VPS, хоть раз перезагружал сервер при DDoS-атаках или при подозрительно резком росте трафика. Это не помогает, ну а что ещё делать… Для того, чтобы этого не было, в статье под катом разберу, что происходит при разных видах DDoS, как правильно их диагностировать и с помощью чего можно отличить атаку от органического роста. 

Сервер может состоять из нескольких десятков компонентов, закупленных в разное время по нескольким контрактам на гарантийное обслуживание. Инвентарный номер есть у сервера, а также может свой у каждого комплектующего копмонента. Когда горит диск – вы знаете, к кому звонить и по какому контракту?

Если не сразу – эта статья для вас.

Представьте парк из более чем 700 экземпляров СУБД. Классический сценарий: приходит оповещение о высокой нагрузке, администратор начинает вручную собирать метрики с десятков дашбордов в Prometheus/Grafana, анализировать журналы, ища ошибки и медленные запросы, пытаться сложить разрозненные данные в единую картину, сформулировать проблему и создать задачу на исправление.

На это уходит много ресурсов, а ценное время на реакцию уходит.

Наша команда решила автоматизировать этот цикл, создав систему, которая не просто собирает данные, но и анализирует их, генерирует контекст и сама запускает процессы по созданию заявки.

С вами Станислав Епишин и Константин Резник из команды «R4C.Support.Всадники апокалипсиса» в СберТехе. В этой статье покажем, как мы соединили Prometheus, Pipeliner (CI/CD-оркестратор, разработан в СберТехе, аналог Jenkins), TaskTracker (система управления задачами, разработана в СберТехе, аналог Jira) и GigaChat (продукт Сбера) через AI Hub API (анализ) в единый механизм.

Привет, Хабр! Меня зовут Дмитрий Гоголев, я занимаюсь развитием платформы управления виртуальной и облачной инфраструктурой Cloudlink и направлением частного облака Orion Private Cloud (OPC) в Orion soft. Многое в ИТ-инфраструктуре можно сделать своими руками. Чем больше вы занимаетесь этим, тем лучше понимаете, как это сделать… но иногда легче все-таки с автоматизацией. 

В большинстве случаев у DevOps уже есть набор инструментов автоматизации. Практически все используют Ansible и Terraform или их аналоги для создания окружений. Многие переходят на IaC. Проблемы начинаются в крупных, иногда распределенных инфраструктурах. При отсутствии централизованной платформы, которой могут пользоваться не только сами инженеры, приходится тратить значительное время на согласования, ручные операции и разбор инфраструктурных ограничений. При отсутствии единого каталога типовых сервисов, включающего ВМ, Kubernetes-кластеры, namespaces, хранилища, сети, шаблоны окружений, создание окружения может занимать дни или недели, потому что требует ручных согласований.

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

Сервис открывается, отвечает, всё работает — но цены в другой валюте, половина функций спрятана, а платёжный шаг падает с невнятной ошибкой. Через час выясняется, что выдача зависит от того, из какого региона пришёл запрос, а вы ходите из «неправильного». Знакомо всем, кто проверял локализацию продукта или подключался к региональному B2B‑порталу из другой страны.

Дальше обычно появляется VPN до нужного региона, и на этом задача считается решённой. На практике решённой она не считается — просто проблема переезжает в то место, где её не видно.

Привет, это снова Максим Королёв из Петрович-ТЕХ — сервисный менеджер, который автоматизирует всё, до чего дотянутся руки. Сегодня расскажу, как бот для дежурств научился не ждать команды, а действовать первым.

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

В первой статье «Дежурный» был одним из семейства Telegram-ботов для ITSM: сбой → Jira → канал, оформление за минуту вместо десяти. Во второй - когда Telegram падал в разгар аварии - я вынес логику в CORE и подключил MAX как второй мессенджер: одно ядро, два входа, паттерн reply_fn.

С тех пор бот перестал быть просто кнопкой «завести сбой», а постепенно превратился в SRE-помощника на смене. Теперь он автоматически заранее уведомляет о предстоящих регламентных работах, инициирует war room (чаты) для конкретного инцидента, по справочнику зовёт ответственных, заполняет поля в Jira и отдает статистику по сервисам - всё из мессенджера.

Дальше - о том, что я добавил, как это легло на архитектуру CORE и какие решения оказались рабочими, когда интеграций стало больше, чем кнопок в меню.

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

Меня зовут Даниил Рахновский, я ведущий архитектор в Orion soft. В этой статье мы поговорим о том, почему опасно доверять секреты контейнерам, рассмотрим, как упорядочить работу с секретами в Kubernetes с помощью системы управления секретами и какие встроенные инструменты в этом помогают.

В наше непростое время... Хотя, к чему все это? Все в курсе. Переходим к технической части.

Многие знают, что XRAY умеет получать запрос от клиента на один ip адрес, а отправлять ответ с другого ip адреса. Документации на этот счет в интернете крайне немного (ну или я не умею искать). Есть образцы базовых настроек в примерах на GitHub проекта XTLS и несколько упоминаний о существовании такой фишки в статьях на Хабре без подробностей реализации. Я же попробую описать здесь теорию и настройку разделения входящего и исходящего трафика подробно и с примерами.

Зачем все это нужно?

В рамках WWDC 2026, а если быть точнее, то в ролике What’s new in managing Apple devices, инженер Device Management team, Cyrus Daboo, заявляет о том, что "Declarative Device Management уже здесь" и используется в продакшене для управления парками корпоративных устройств Apple по всему миру.

Что касается классического MDM, то ранее компания Apple уже обозначала некоторые команды MDM как Deprecated, например, ScheduleOSUpdate, которая отвечает за установку обновлений macOS. Информацию об этой команде уже не найти на сайте Apple Developer | Device Management , но она все еще присутствует в репозитории Device management schema data for MDM на Github Apple. В следующей macOS 27 Golden Gate эта команда точно не будет работать, и без функционала DDM установить обновления "тихо и незаметно" не получится. В системе пока еще присутствует терминальная команда softwareupdate, но там есть нюансы, о которых можно прочитать в одной из статей, опубликованной в корпоративном блоге Ринго на Хабре.