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

Привет! Я Даниил, DevOps-инженер в KTS.

Недавно я поработал со Stackland. Концепция облачноподобной платформы с кучей коробочных сервисов на своем железе в закрытом контуре давно была любопытна нам (и нашим заказчикам), так что пройти мимо готового решения от Яндекса было бы преступлением. По горячим следам я решил написать эту статью, чтобы поделиться опытом развертывания Stackland на голом железе. Так что ниже вас ждет скорее не обзор, а туториал.

Коротко о том, как это было: сначала я подготовил L2-сеть, бастион с NAT, DNS и NTP, три сервера, образ Stackland и YAML-конфиги. Затем запустил sladm install и через час получил консоль, готовый мониторинг с визуализацией в Grafana и возможность по кнопке в UI поднять managed PostgreSQL, Kafka, ClickHouse и другие сервисы.

Подробнее о том, как это было, рассказываю ниже.

Grafana показывала, что горит, Mattermost доставлял уведомления, но после смены дежурного приходилось заново выяснять, кто занимается проблемой и когда ждать результат. Рассказываю, как мы собрали поверх них рабочее место с владельцами, ETA, общей историей, группировкой каскадных алертов, инцидентами и postmortem — без отдельной базы данных и без передачи управления состоянием LLM.

10 июля мы выпустили Monq 9.2.0. Если описать релиз одной фразой: пороги получили собственное рабочее пространство, научились учитывать расписание, автоматически находить свою КЕ в CMDB и хранить прогноз собственного состояния. Для работы на больших объёмах хранение порогов перенесено из PostgreSQL в ClickHouse, а связанный конвейер сервисов переработан.

Перед вами обзор обновления отечественной observability платформы зонтичного мониторинга от вендора. Тут не будет обещаний «предсказать любую аварию» и общих слов про AIOps. Разберём точную механику, новые фичи, работу дежурной смены, нюансы обновления и честную границу между тем, что уже работает в 9.2, и адаптивными порогами, которые появятся в 9.3.

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

Часто первое, что хочется сделать при неполадках в кластере, — уменьшить его и надеяться, что всё решится само. Получается, большой кластер = куча проблем?

Автор статьи решил зайти максимально далеко: поднять Kubernetes-кластер с миллионом узлов и посмотреть, что будет.

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

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

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

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

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

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

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

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

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

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

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

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

Что на самом деле защищает наши данные? Снапшоты, которые создаются за секунды и позволяют мгновенно откатиться к предыдущему состоянию? Регулярные резервные копии, которые хранятся на отдельном хранилище? Или репликация, которая обеспечивает непрерывность работы даже при сбое площадки?

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

В этой статье расскажем, почему снапшот — это вообще не бэкап, почему репликация не заменяет резервное копирование, какие требования предъявляются к современной системе защиты данных, и покажем, как эти принципы реализованы в связке VMmanager и RuBackup.

Короткая история про то, как штатная замена ноды оставила 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, ни про потерю данных. Как раз эту дырку мы и полезли закрывать.

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

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

SRE‑инженер Mindbox рассказывает, как DevOps‑команда столкнулась с неконтролируемым запуском хаос‑тестов, когда проводила плановые проверки с помощью Chaos Mesh. Что запускало «зомби‑тесты», какие пробовали решения и на чем в итоге остановились — делимся в статье.

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

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

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

Если CREATE INDEX CONCURRENTLY или REINDEX INDEX CONCURRENTLY завершается с ошибкой, Postgres оставляет после себя невалидный индекс. Многие инженеры считают такие индексы безобидными заготовками, которые просто ждут удаления. В конце концов, планировщик ведь не использует их в запросах, верно?

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

В этой статье мы на реальных примерах рассмотрим скрытые издержки невалидных индексов, о которых должен знать каждый администратор Postgres.

Когда приходишь на аудит СУБД к разным компаниям, картина удивительно похожа: одни и те же проблемы, одни и те же причины. Меня зовут Андрей, я 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 в свободное от основной работы время.