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

Каждый, кто хоть раз устанавливал Linux вручную, знает этот ритуал: загрузиться с Live‑образа, запустить fdisk или parted, создать таблицу разделов, отформатировать их в btrfs/ext4, создать субтома, а затем вручную примонтировать всё это в /mnt.

Конечно, такой подход можно использовать и при установке NixOs. Но вопрос — зачем?

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

В этой статье мы этим вопросом и займёмся, а поможет нам в этом известная утилита disko. Мы напишем чистый декларативный конфигурационный файл в ДВУХ вариантах:

OpenTelemetry постепенно становится универсальным пылесосом для телеметрии. Осталось только научить его аккуратно засасывать всё то наследие, которое приложения десятилетиями складывали в файлы. В этом переводе статьи разбирается как использовать filelog receiver на практике — от простого чтения JSON‑логов до продакшен‑сценариев с настройкой производительности. Ещё больше полезных материалов я публикую у себя в авторском телеграм‑канале Мониторим ИТ. Всегда рад новым подписчикам.

Даже в эпоху облачных приложений и распределенного трейсинга обычные файлы логов остаются одним из самых ценных источников достоверной информации в любой системе. От корпоративных приложений и пакетных заданий до NGINX, баз данных и локальной инфраструктуры — критически важная диагностическая информация по‑прежнему записывается на диск.

Получатель filelog в OpenTelemetry Collector позволяет интегрировать эти логи в современный конвейер наблюдаемости. Он непрерывно отслеживает файлы, анализирует их содержимое и преобразует необработанный текст в структурированные записи логов OpenTelemetry.

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

Прежде чем углубляться: если вы контролируете приложения, записывающие эти логи, наилучшим решением будет настроить их на вывод структурированных JSON‑логов, размещённых в одной строке. Чтобы получатель filelog в этом случае стал простым и удобным уровнем приема данных.

Значительная часть этой статьи посвящена ситуациям, когда такой вариант невозможен. В подобных случаях получатель filelog предоставляет мощные инструменты для анализа, структурирования и обогащения любых получаемых логов, превращая их в полноценные данные наблюдаемости.

Начнём!

Рука промахивается на Ctrl+Shift+W — и окно с полусотней вкладок закрывается без вопросов. Единственное, что заставляет Яндекс Браузер переспросить, — активная загрузка. Так что теперь systemd кормит мой браузер загрузкой, которая не кончается никогда: 0,4 МБ памяти, 64 КБ на диске, один байт по loopback раз в пять минут. Как я до этого дошёл, почему не спасают настройки и расширения и как тесты чуть не убили то, что защищали, — под катом.

Разбираем сетевые драйверы Docker — bridge, host, overlay, macvlan, ipvlan — DNS, порты и плагины: от основ до продвинутых сценариев.

У каждого, кто работает с Kubernetes, рано или поздно возникает потребность «посмотреть на кластер глазами»: кто с кем связан, почему под в CrashLoopBackOff, что изменилось за ночь, какие сертификаты истекают. Вариантов обычно два — Kubernetes Dashboard (слишком бедный) или Lens / Headlamp (десктопное приложение или тяжёлый стек с зависимостями). А kubectl-специалисты откапывают причины инцидентов в простынях YAML, где сигнал тонет в managedFields и status.conditions.

Radar — open-source UI для Kubernetes от Skyhook (YC W23). Один бинарник на Go, без регистрации и аккаунта, бесплатный навсегда. Топология кластера, браузер ресурсов, timeline событий, менеджер Helm-релизов, GitOps для FluxCD, карта трафика, аудит безопасности, анализ impact'а перед апгрейдом K8s и даже встроенный MCP-сервер, чтобы ИИ-агенты могли смотреть кластер глазами Radar вместо сырого kubectl.

В этой статье мы развернём Radar в Yandex Managed Kubernetes через Helm — с ingress-nginx и доменом из публичного IP — и разберём все основные экраны. Разворачиваемый инстанс — общий для команды разработчиков, поэтому конфигурация строго read-only: все write-права выключены, ИИ-агенты подключаются к read-only MCP.

Разбираемся с мониторингом и observability, metrics, logs и traces, time series, labels, scrape, TSDB, PromQL и alerting rules.

Разберём, как Prometheus получает метрики через /metrics, чем target отличается от endpoint и job, зачем нужны exporters, а также почему запуск Node Exporter в Docker требует доступа к ресурсам Linux-хоста.

UFW показывает DENY, а контейнер отвечает снаружи за 130 миллисекунд. Разбираю на стенде, почему файрвол тут ни при чём, почему популярный совет с правилом в DOCKER-USER не работает, и что об этом написано в документации Docker.

Началось всё с довольно простой задачи. Мне понадобилось установить приложение из Microsoft Store, но для моего региона оно оказалось недоступно.

Гуглить способы обхода мне было лень, поэтому я отдал задачу ChatGPT вместе с установщиком. В результате регион Windows был временно изменён, приложение установилось.

Сам способ, конечно, не новый. Регион Windows можно поменять вручную в настройках, поставить приложение и вернуть обратно. Но после этого я подумал: если метод давно известный и с такой проблемой явно сталкиваюсь не только я, почему бы это не автоматизировать?

Так появился WinStoreRegion — небольшая утилита для Windows. На момент публикации актуальная версия — 0.1.0.

Все, кто работал с k8s, знают: что такое CNI, разбираются как его подключить и даже поверхностно могут понимать какой из предлагаемых на «рынке» интерфейсов лучше подходит под определенный кейс. Но между поверхностными абстракциями и пониманием того, что фактически происходит с пакетом пропасть. Пока кластер функционирует стабильно эта пропасть не мешает. Она стреляет, когда начинается полтергейст: пакеты теряются между нодами, latency скачет через раз, NetworkPolicy «отказывается работать», но по всем кажущимся метрикам все зеленое.

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

Всё началось с желания организовать и автоматизировать работу с Terraform, впоследствии с Terragrunt, выстроить управляемый процесс, централизовать, настроить понятный RBAC, в общем, сделать так, «чтобы было красиво». Было сделано несколько подходов, и были рассмотрены разные варианты. Отправной точкой стало структурирование кода, его декомпозиция и рефакторинг, и постепенно дошло до автоматизации самого процесса применения (или просто plan/apply). К этому моменту основная часть кода сконцентрировалась в монорепозитории в self-hosted GitLab, общая и повторяемая логика отделилась во внутренние приватные модули, а сам код вырос в объёмах: более 4 000 .tf файлов, не учитывая внешних и внутренних модулей, более 900 проектов (каталогов), более 30 000 ресурсов, более 30 уникальных провайдеров Terraform. Конечно, все эти условия в той или иной степени повлияли на конечный выбор.

В этой статье расскажу, как мы перешли от ручного управления Terraform и Terragrunt к автоматизированному процессу на базе Atlantis, какие альтернативы рассматривали, почему выбрали именно Atlantis и с какими неочевидными особенностями столкнулись при его эксплуатации.

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

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

Привет, Хабр! На связи – редакция 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.