Лишь бы юзер был доволен
Зелёный пайплайн ещё не означает, что деплой прошёл как надо. В 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 влияет на задержки, где искать удалённые обращения к памяти и когда привязка к узлу помогает, а когда только мешает.
Привет! Мы в шаге от выпуска новой версии нашей игры. Число изменений в сервисах и инфраструктуре выросло кратно, все хотят уложиться в дедлайны. Каналы с алертами напоминают Красное море, а в канале поддержки всем не терпится узнать, почему упал билд, — и, конечно, немедленно его починить.
С диагностикой нам уже помогает агент из первой и второй частей — но это только полдела. Дальше начинается самое муторное: инженер должен понять, где именно нужно внести изменения, оценить, сможет ли он сделать их сам или тут нужен разработчик, найти нужный репозиторий среди десятков похожих, внести правку, прогнать её через PR и ревью. В релизный кранч эти «ещё пятнадцать минут» на каждое обращение складываются в часы, а переключение контекста добивает остатки концентрации. Знакомо? У нас это выглядело так: агент за две минуты выдаёт диагноз «в workflow не передаётся input окружения», а потом инженер ещё полчаса ищет, в каком из реюзабельных workflow это чинить.
Именно поэтому мы решили пойти дальше и дать возможность просто сказать: