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

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

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

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

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

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

В статье рассматривается shrink кластера Greengage DB с использованием ggrebalance: архитектура утилиты, FSM-подход, безопасное перераспределение данных через INSERT, сравнение с CTAS, поддержка rollback и результаты тестов производительности.

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

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

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

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

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

Вынос со скандалом Bcachefs из mainline‑ядра Linux в конце 2025 года (начиная с релиза 6.18) проект не похоронил. Напротив, это явно подстегнуло мейнтейнера к жесткой дисциплине. Спустя 7 месяцев проект перешел на DKMS‑модель и официально снял статус experimental.

Развернул тестовую ВМ в Proxmox, чтобы посмотреть на эксплуатационный UX: как ставится, как ведет себя при отказе дисков и стоит ли тащить в homelab или прод.

Дисклеймер. Это синтетические тесты, а не академический бенчмарк (на виртуалке поверх ZFS тестировать скорость — такое себе). Цель — проверить работу базовых функций, диагностику и поведение при аварии.

Что важнее при выборе СУБД: выручка разработчика или реальные возможности продукта?

На российском рынке долгое время ответ фактически сводился к рейтингам продаж. Но ситуация постепенно меняется. Исследование ЛАНИТ стало одной из первых попыток сравнить отечественные СУБД не по финансовым показателям, а по техническим характеристикам — от совместимости и миграции до безопасности и администрирования.

Однако при внимательном изучении результатов возникли вопросы ....

Привет, Хабр!

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

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

Почти каждый, кто админит 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 до нужного региона, и на этом задача считается решённой. На практике решённой она не считается — просто проблема переезжает в то место, где её не видно.

Всем привет, меня зовут Вячеслав, я Team Lead SRE в Купере. Рассказ в этой статье пойдет о том, как мы внедряли SLO, чего достигли и какие лайфхаки нашли по дороге.

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

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

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

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

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

За последние годы я несколько раз видел одну и ту же картину в небольших и средних компаниях. Для приложений поднимают S3-совместимое хранилище. Для людей — отдельный файловый сервис или сетевые шары. LDAP/OIDC живёт отдельно. Бэкапы — третий контур. Мониторинг — четвёртый. Всё работает, пока не приходит внутренний аудит или новый филиал с формулировкой: «нам нужен корпоративный диск с SSO, журналом и данными только у нас».

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

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