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

Документация Яндекс 360 API на 20 августа 2026 года перечисляет 17 сервисов, и раздела о вебхуках или подписке на события среди них нет; аудит-лог организации документирует 26 типов событий — двенадцать почтовых и четырнадцать дисковых. Кадровых и оргструктурных событий не документировано ни одного. Разбираю, что из этого следует тем, кто строит провижининг: чем располагает UserService_List для поллинга, почему isDismissed нельзя записать и что документация обещает при создании пользователя с занятым логином.

Зелёный пайплайн ещё не означает, что деплой прошёл как надо. В Bash хватает ситуаций, где ошибка теряется, код возврата маскируется, а скрипт спокойно идёт дальше. Разберём типичные ловушки и способы сделать такие сценарии предсказуемее.

Разбираемся, что за зверь хранит весь ваш Kubernetes, учимся читать его ошибки и честно отвечаем на вопрос, можно ли ему доверять.

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

Компанию +Альянс основал я. Руковожу ею тоже я, а по существу занимаюсь одним: тем, чтобы кадровое решение доезжало до облачного офиса без человека посередине. Инструменты в тексте остаются безымянными, и наши, и сторонние: речь про требования к приёмнику входящих запросов. Яндекс 360 упомянут как платформа, на которой живут учётные записи, и как источник, который читатель откроет сам.

Сразу про слабое место текста. Всё, что сказано ниже про поведение движка автоматизации, — моя собственная фиксация ответов, а не публичный документ, на который можно дать ссылку. Проверить это можно только на стенде, поэтому такие утверждения я даю вместе с процедурой проверки. Зато про саму платформу есть открытая документация, и на неё я опираюсь дословно. Даты такие. Каталог триггеров и действий зафиксирован 30 июля 2026, история запусков 3 августа, контракт вебхука 20 августа, страницы документации Яндекс 360 API сверены тоже 20 августа 2026.

Привет, Хабр! В работе почти каждого, кто плотно сидит в Linux, есть один недостаток: одни и те же команды забываются с завидной регулярностью. Я, например, иногда по десять раз лезу в историю, чтобы уточнить - «так как в rsync директорию исключить, но структуру оставить?»

Можно, конечно, вести свои заметки. Можно - дрессировать Ctrl+R. А можно установить небольшую утилиту, которая будет жить в трее и выдавать нужную подсказку за полсекунды. Именно о такой утилите сегодня и расскажу - DevToolbox Cheats.

Любые серьёзные изменения инфраструктуры начинаются с одного вопроса: что именно у нас есть сейчас?

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

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

Документация существует, но её актуальность вызывает вопросы. В одном документе устройство называется одним образом, в другом — другим, а на самой стойке используется третье обозначение. В таблице порт отмечен как свободный, хотя в него включён рабочий линк. На схеме uplink уходит в один коммутатор, а LLDP показывает другой. Какие-то подключения давно не используются, но продолжают числиться в документации. Какие-то, наоборот, работают много месяцев и нигде не описаны.

CTE в PostgreSQL упрощают код, но могут снижать производительность. Разбираем 4 антипаттерна, примеры EXPLAIN ANALYZE и практические способы оптимизации.

В прошлой статье мы упоминали основные SQL‑антипаттерны, способные замедлять работу базы данных. Продолжаем тему — на этот раз про CTE. 

Common Table Expressions (CTE), или конструкции WITH, — привычный инструмент SQL-разработчика. Чем сложнее запрос, тем выше шанс встретить в нём WITH: код становится чище, а запутанная логика разбивается на понятные блоки. CTE используют как альтернативу вложенным запросам и временным таблицам. Однако за внешней простотой и читаемостью скрываются риски снижения производительности, которые не всегда удаётся предвидеть.

Такие запросы на первый взгляд выглядят правильными, но работают неэффективно, и проблема вылезает только в EXPLAIN ANALYZE (инструмент разбирали в прошлом гайде). Разберём четыре антипаттерна CTE, посмотрим планы выполнения и покажем, как переписать запрос. В конце — короткий чек-лист диагностики.

Эта статья может быть полезна начинающим разработчикам и аналитикам, которые уже полюбили синтаксис CTE, но хотят понять, что на самом деле происходит «под капотом» в PostgreSQL.

Мы (ну ладно, я) ждали этого больше десяти лет: в PostgreSQL 19 наконец-то завезли штатную онлайн-перепаковку таблиц. Команда REPACK в ядре и теперь больше никаких сторонних расширений и бесконечных согласований с ИБ. Да? Или нет? Эпоха pg_repack подошла к концу? Спойлер: не спешите удалять старые скрипты и утилиты. На моих тестах новая встроенная команда под нагрузкой заблокировала таблицу на три с лишним минуты, в то время как "старичок" pg_repack уложился в 0.6 секунды.

Выяснил: как устроен новый REPACK под капотом, почему он ломает привычный MVCC и в каких сценариях попытка использовать штатный инструмент на проде станет фатальной ошибкой.

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

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

Предлагается доработать ispmanager, а именно:

Читатель принёс мне в комментарии документ ФСТЭК как аргумент: длина пароля должна быть не менее 15 символов. Документ оказался настоящим, цифра в нём есть, но работает она не так, как её процитировали.

Заодно выяснилось, что «Рекомендации по защите сетевого периметра информационных (автоматизированных) систем» лежат на сайте регулятора с 10 марта, в них 35 пунктов, и разбора этого документа нигде нет.

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

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

Мониторинг шлёт тревогу, пользователи пишут, что «всё лежит», но SSH пускает на сервер. Значит, машина включена и 22-й порт доступен. О домене, портах 80 и 443, TLS, веб-сервере и приложении это пока ничего не говорит… Кажется, что нужно просто перезапустить nginx, но перезапуск стирает часть следов и может превратить частичную аварию в полную беду. Под катом расскажу, как пройти путь запроса сверху вниз и найти место, где он остановился.

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