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

В первой части мы разобрались с архитектурой Apache Iceberg. Увидели, как иерархия метаданных позволяет находить нужную информацию без полного сканирования хранилища. Также стало понятно, почему Iceberg — это не вычислительный движок и не формат файлов, а табличная спецификация поверх объектного хранилища. 

Теперь настало время ответить на практический вопрос: как все эти метаданные связать в единую систему, чтобы несколько движков могли работать с одними и теми же таблицами без хаоса. Помимо теории развернем HMS в Docker, настроим PyIceberg и разберем внутреннюю анатомию файла metadata.json.

Привет! Я Денис, старший бэкенд-разработчик в Selectel. Надеюсь, материал будет полезен инженерам данных и архитекторам. Мы рассмотрим Hive Metastore, AWS Glue, REST Catalog и Nessie и расскажем как выбрать подходящий инструмент под специфику проекта.

Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны: какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.

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

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

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

Статья в первую очередь будет полезна разработчикам, интеграторам и архитекторам, которые работают с ESB, ETL и реляционными базами данных. Даже если вы не используете FESB, описанный подход с контрольной точкой и инкрементальной загрузкой можно адаптировать для других интеграционных платформ.

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

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

Я играю в STALCRAFT, ныне STALZONE. Там есть радио Grind FM — играет фоном, создаёт атмосферу. Проблема в том, что это радио находится в безопасной зоне и играет даже не на всю эту зону. И мне захотелось сделать так, чтобы во время вылазки можно было включить это радио и мочить мутантов.

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

До AVM виртуализацией управляла сторонняя платформа. Иногда она зависала и переставала принимать задачи. Нагрузку распределили между несколькими экземплярами платформы, но зависания продолжились. До вмешательства операции клиентов не шли.

В некотором царстве, в некотором государстве… Историю расскажу, как сказочку, из тех соображений, что в сказочника камней не кидают, аллергия на камни :) Ибо, ну что с него взять? Он же сказочник!

Так вот. Жила была компания, давненько это было, домен AD, w2k3 сервера, филиалы по области штук 15-20, в каждом по контроллеру домена для надежности, и объединялись они с головным офисом каналами ВПН. В некоторых ранних версиях даже через GSM-модемы.

И настали трудные времена, да так что пара филиалов задумали уйти к Шведам отпочковаться в самостоятельность. Или компанию разрывать начали за долги из-за взаимных неплатежей, я уже не помню. История покрылась патиной.

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

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

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

Сервер стал мощнее, а p99 внезапно вырос втрое — при свободной памяти и почти пустом CPU. В статье разбираем, как NUMA влияет на задержки, где искать удалённые обращения к памяти и когда привязка к узлу помогает, а когда только мешает.

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

С диагностикой нам уже помогает агент из первой и второй частей — но это только полдела. Дальше начинается самое муторное: инженер должен понять, где именно нужно внести изменения, оценить, сможет ли он сделать их сам или тут нужен разработчик, найти нужный репозиторий среди десятков похожих, внести правку, прогнать её через PR и ревью. В релизный кранч эти «ещё пятнадцать минут» на каждое обращение складываются в часы, а переключение контекста добивает остатки концентрации. Знакомо? У нас это выглядело так: агент за две минуты выдаёт диагноз «в workflow не передаётся input окружения», а потом инженер ещё полчаса ищет, в каком из реюзабельных workflow это чинить.

Именно поэтому мы решили пойти дальше и дать возможность просто сказать:

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

Во времена tar-архивов откатывались со скоростью переключения symlink. В современном мире деплой умеет то, что раньше и не снилось, — он научился изоляции, декларативности и воспроизводимости. Только про быстрый откат многие забыли. 

Полный self-hosted стек observability (Go-приложение + PostgreSQL + ClickHouse) живёт на VPS с 2 ядрами и 2 ГБ RAM. Но сначала стоковый ClickHouse занял 12 ГБ диска при 543 КБ полезных данных, держал 900 МБ памяти и мержил 11 миллионов строк каждые 30 секунд. Разбор с реальными замерами: куда всё ушло, какая гипотеза не подтвердилась, какая ошибка уронила прод и какие настройки в итоге вернули две трети памяти.

Привет, Хабр. Я Матвей Лихота, старший Go-разработчик и DevSecOps. Как это часто бывает с внутренними инструментами, идея этой утилиты появилась уже после того, как у нас упал прод. Во время хотфикса сотрудник забыл обновить в одном из двух сервисов версию библиотеки с контрактами и в результате в зависимостях осталась предыдущая версия. Перед слиянием код собирался и тесты проходили, но после деплоя сервис упал с ошибкой 500: новое поле в структуре запроса не появилось на сервере. Пришлось откатить изменения и даунтайм был ощутимый.

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

Тогда я решил, что теперь проверять актуальность зависимостей будет CI. Так и появился Dependency Validator.

Сервер отвечает с задержкой, сайт еле открывается, а причина нагрузки неочевидна. В статье разберём пошаговую диагностику Linux‑сервера: как проверить CPU, память и диск с помощью top, free, vmstat, iostat и iotop, найти процесс‑виновник и понять, куда копать дальше.

Высокий уровень observability в наше время — такое же необходимое условие для любого проекта, как и высокая доступность или производительность. Мы стараемся собрать и сохранить максимум метрик, чтобы понимать, в каком состоянии находится наша система и куда это состояние дрейфует. Собираем максимум логов, чтобы понимать, что происходило. Но даже когда логов и метрик настолько много, что для них собираются свои логи и метрики, иногда этого бывает недостаточно. Иногда нужно понимать не ЧТО и КОГДА, а ПОЧЕМУ.

В мире Kubernetes такой источник есть — events: именно они отвечают, почему под перезапустился, почему не смог подняться, почему не встал на ноду. Парадоксально, но эти чрезвычайно важные сведения довольно неудобно извлекать, а по умолчанию через час они уже исчезают. С этим обычно мирятся — ровно до утра, когда нужно объяснить, почему ночью упали сборки. Дальше история одного такого утра: начинается она с двух неудачных пайплайнов, заканчивается часовым окном нестабильности, задевшим 46 namespace'ов, и ни одной улики к моменту расследования в кластере уже не остаётся.

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

VPN шифрует содержимое трафика, но это не делает соединение невидимым для сети. IP‑адреса, handshake, размеры пакетов, тайминги и поведение потока могут использоваться для классификации даже без расшифровки данных. Разберемся, что видит DPI, как работают fingerprinting и active probing и какую роль в этой архитектуре играют VLESS, XHTTP и REALITY.

Первый тур голосования за доклады INFOSTART TECH EVENT 2026 завершен. После него сформировано около 30% программы конференции. Рассказываем, какие доклады уже прошли в программу, кто набрал больше всего голосов и что происходит дальше.

При отборе учитывались два фактора: голосование участников и экспертная оценка модераторов секций.

Кроме конкурсных заявок, в программу вошли доклады экспертов и модераторов:

Про асинхронный ввод-вывод в PostgreSQL за последний год написали многие:

Механизм появился в 18-й версии, в 19-й его докрутили и в релиз-нотах он числится среди главных улучшений производительности.

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

Всем привет! Меня зовут Андрей Лапкин. Около года назад я перешёл на роль архитектора ИТ-инфраструктуры в подразделении Эксплуатации музыкального сервиса Звук — и практически сразу мы запустили программу управления облачными расходами.

Облачная инфраструктура стримингового сервиса — это сотни виртуальных машин, десятки кластеров Kubernetes, объектные хранилища, базы данных, балансировщики. Ресурсы создаются под задачи, но далеко не всегда удаляются после их завершения. С ростом инфраструктуры вопрос «сколько стоит конкретный сервис?» потребовал системного ответа”.

За полгода систематической работы мы снизили ежемесячные расходы на инфраструктуру примерно на 22%. Для контекста: до старта программы счёт органически рос на 1–2% в месяц. Расскажу, как мы к этому пришли: какую методологию взяли за основу, какие принципы заложили в фундамент и как выглядит дорожная карта. Фокус статьи — на стратегии, процессах и культуре, а не на готовых шаблонах развёртывания.

Когда нужно прокачать конкретный навык, проще всего начать с практической задачи. В этом дайджесте собрали 39 открытых уроков августа для IT-специалистов: от asyncio, Kafka и PostgreSQL до системного дизайна, DevSecOps и локальных AI-моделей — с разбором инструментов и подходов, которые применяются в реальных проектах.