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

Вынос со скандалом 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 с помощью системы управления секретами и какие встроенные инструменты в этом помогают.

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

Многие знают, что 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, но там есть нюансы, о которых можно прочитать в одной из статей, опубликованной в корпоративном блоге Ринго на Хабре.

Tantor Postgres 18 - масштабный релиз СУБД, за которым стоят месяцы тестирования, сотни часов нагрузочных прогонов и десятки исправлений, о которых пользователь никогда не узнает просто потому, что они были найдены и устранены до выхода версии. Александр Симонов, руководитель направления развития 1С в "Тантор Лабс", рассказывает, как устроен процесс тестирования изнутри - почему одного эталонного прогона недостаточно, что делать, когда ванильный PostgreSQL 18 ломает собственные оптимизации, и как Tantor Postgres приближается к той планке, которую MS SQL Server держал годами.

Загрузка операционной системы — процесс многоступенчатый и разнообразный. Несколько лет назад я писал о процессе загрузки сервера x86 в режимах Legacy и UEFI, но акцент тогда был именно на «железной» части.

Пришло время сместить внимание на программную составляющую. Посмотрим, какие стадии преодолевает ядро Linux, что происходит, и какие «фишки» можно выполнить на старте системы.

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

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

Инфраструктура обычно ломается не в одном месте. За «просто поправить деплой» быстро подтягиваются лимиты Linux, настройки контейнеров, CI/CD, безопасность, маршрутизация, Kubernetes, базы данных и сети ЦОД. Чем больше сервисов и команд, тем важнее видеть не только отдельные инструменты, но и связи между ними.

В этом дайджесте собрали открытые уроки, статьи и курсы по Linux, Docker, Kubernetes, CI, PostgreSQL, сетям и безопасности. Подборка будет полезна тем, кто отвечает за стабильность сервисов и хочет системно закрывать инфраструктурные пробелы.

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