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

Привет, Хабр! На связи – редакция ICL Services. В этом августе нам исполнилось 20 лет, и в честь этого мы завершаем наш спецпроект – триптих о людях, которые своими руками творили историю компании на протяжении 10+ лет. Они видели компанию на всех этапах развития — от аутсорсингового подразделения японской корпорации Fujitsu, Fujitsu Russia GDC, до самостоятельного игрока, адаптировавшегося на сложном российском рынке, с собственным видением, новыми крупными заказчиками и собственными ИТ-разработками.

Сегодня в фокусе нашего внимания — Иван Синёв, заместитель руководителя направления инфраструктурных услуг и решений, который пришел в компанию в 2012 году с позиции ЕN4 — самого высокого инженерного грейда. И до сих пор, будучи руководителем, остается инженером «до мозга костей». Путь Ивана — это история о том, как уфимский специалист попал в Казань по программе релокации, как выводил из кризиса проект европейского модного магната, как встречал убойный 2022 год с билетом в Сербию в один конец и строил инфраструктурный пресейл с нуля для российского рынка.

В прошлой статье мы рассказали, почему решили съехать с корпоративной почты Mail.Ru на свою инфраструктуру. Тогда мы обошлись без деталей — а зря, судя по комментариям. В этот раз разбираем всё по шагам: как разворачивали MailCow и какие нюансы есть.

Эта статья — техническое продолжение. Без макроэкономики, только руки, консоль и шишки.

P.S. в прошлой статье сообщество решило, что у нас работает школьник и все это настраивает, поэтому статья как раз написана с помощью этого школьного товарища. Не судите строго, все таки мы еще в школу ходим :)

Привет, Хабр! На связи Даша Косова, я продакт менеджер Рег.облака. Ситуация: на сервере закончилось место. Вы увеличиваете диск, выдыхаете, а через какое-то время все повторяется. Потом приходит время переносить сервер, и вместе с ним переезжают все накопленные файлы. Перенос растягивается на выходные, а трогать эту машину лишний раз уже никому не хочется. Место на диске к этому моменту далеко не единственная проблема.

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

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

Навигация по тексту:

Привет! Сразу признаюсь, я — гуманитарий. Уже лет двадцать работаю в IT, притворяясь своим среди хардкорных технарей. Людей, которые писали на Фортране и Бейсике, пережили диалап и вспоминают «3dfx» с лёгкой ностальгией. 

Мой максимум — навайбкодить какой‑нибудь скрипт для аналитики. Для гуманитариев это звучит страшно, потому что ничего не понятно. Для IT‑специалистов — страшно, потому что всё со мной понятно. 

Меня до сих пор не раскрыли только потому, что айтишники обычно смотрят в монитор, а не друг на друга. Зато наблюдать за ними невероятно интересно. Благодаря подлой гуманитарной сущности я смог оформить эти наблюдения в рассказ о жизни удивительного биологического вида Informaticus vulgaris, он же «айтишник обыкновенный». 

Рассказ буду вести от первого лица. Все совпадения случайны, как бы вы ни пытались доказать обратное.

Документация Яндекс 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 показывает другой. Какие-то подключения давно не используются, но продолжают числиться в документации. Какие-то, наоборот, работают много месяцев и нигде не описаны.

Хабр, привет! 30 июля во второй раз прошла инженерная конфа Kuber Community Day. 400 специалистов встретились в Москве, чтобы послушать о вызовах в Kubernetes, обменяться опытом, завести новые знакомства. Мероприятие объединило 26 спикеров в разных форматах: доклады, круглые столы, мастер-класс, научпоп и стендап. Еще конференция запомнилась экспериментальным форматом Arch Dating, в рамках которого с опытными менторами можно было обсудить технические и карьерные вопросы.

Под катом мы собрали подборку всех выступлений с Kuber Community Day'26. Скоро вернемся с новыми анонсами, первыми о них узнают участники K8s-сообщества.

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

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

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

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

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

98% успешных проверок в дашборде выглядят прекрасно. Ровно до момента, когда доходит: недостающие 2% это одна пара нод, один протокол, и так каждый день. Обновили CNI или ядро, и между двумя конкретными нодами начал теряться UDP, а агрегат всё ещё зелёный.

kconmon‑ng ставит агента на каждую ноду и гоняет TCP, UDP, ICMP, DNS и HTTP‑пробы между всеми парами каждые 5 секунд, а при сбое сам снимает MTR‑трейс, пока проблема ещё жива.

К версии 2.0.0 у проекта выросла веб‑консоль: матрица N×N, расследование с ранжированием причин без ML, машина времени для разбора ночных инцидентов и алертинг, который сводит правила в настоящий PrometheusRule. Под капотом всё тот же Prometheus.

Привет, Хабр! Это снова Евгений Шилкин и Степан Татауров, эксперты дивизиона инфраструктуры Группы Rubytech. В прошлой статье мы разобрали подходы к миграции, посмотрели, какие есть альтернативные решения, и обмолвились парой фраз про MIND Migrate Guest. 

В этой статье — практическая часть, проверим MIND в деле и протестируем его. Что из себя представляет процесс миграции с точки зрения алгоритма и чем он отличается от простого переноса между серверами? В процессе обнаружили несколько интересных находок. Давайте разбираться.

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

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

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

Эту проблему решает запуск приватной LLM в облачном Managed Kubernetes. Приватная модель гарантирует конфиденциальность и не отправляет данные во внешние сети, облако переводит капитальные затраты в гибкие операционные, а Kubernetes берет на себя отказоустойчивость и автоматическое масштабирование дорогих GPU-ресурсов. Материал будет полезен DevOps-, MLOps-инженерам и архитекторам, перед которыми стоит задача развернуть изолированную и надежную RAG-систему.

В этой статье рассмотрим, как можно задеплоить LLM в Managed Kubernetes на примере простой RAG-системы. Будем использовать LLM-роутер AIBrix, n8n и vLLM. Дополнительно понадобятся Envoy Gateway (как зависимость для AIBrix), cert-manager (выпустим сертификаты для домена n8n), Qdrant (хранилище для RAG системы) и PostgreSQL в качестве базы данных для n8n.

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

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

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

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

Разберём, откуда PostgreSQL берёт статистику, как ANALYZE её собирает и по каким признакам понять, что проблема действительно в оценках планировщика.

Задача:

Есть "коробка" с работающей 24/7 OmniOS. Со временем в "коробке" накопилось столько всего важного, что стоимость этой информации превысила стоимость самой "коробки". Наиболее вероятная угроза информации - это фатальный сбой файловой системы при сбоях электропитания. Нужно научить OmniOS "слушать" сообщения от ИБП и самостоятельно выключаться пока ИБП выдает напряжение.

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