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

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

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

Стенд, о котором речь: девять дашбордов реальной платформы, синтетическая «розничная сеть», обновление раз в 30 секунд, вход без учётной записи.

KubeVirt или готовая платформа? Мы сравнили Deckhouse Virtualization Platform с «ванильной» версией по-честному: API-ресурсы, миграции, хранилища, сеть, безопасность. Получилась таблица на десяток с лишним отличий. 

Собрали в одной статье всё, что реализовали поверх KubeVirt, чтобы инженеры не тратили время на настройку и интеграцию: от sizing-политик до проброса USB в ВМ.

Медиана зарплаты DevOps-инженера в 2026 году держится в районе от 220 000 до 250 000 ₽, но разброс внутри одного грейда огромный: у Senior вилка идёт от 300 000 до 850 000 ₽.

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

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

Привет! Я Владимир Мокроусов, сисадмин в группе компаний «Синтека». Мы создаем софт для строительной отрасли и активно используем в работе ИИ-модели. 

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

Address Resolution Protocol или ARP появился еще в 1982 году, но до сих пор остается важной частью IPv4-сетей на базе Ethernet.

Представьте школьную перекличку на уроке физкультуры. Учитель называет фамилию, кто-то отзывается. В журнал ставится точка – ученик на месте.

ARP работает похожим образом. Хост спрашивает локальную сеть: «У кого адрес 192.168.1.1?» Кто-то отзывается «Я» и называет свой MAC. Источник запроса сохраняет пару IP-MAC в ARP-кэше и теперь знает, куда отправлять кадры.

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

Начнем с вопроса, который я часто слышу от студентов:

- зачем нужен ARP, если у каждого устройства есть IP-адрес?

У вас есть бэкапы? Хорошо, лёгкий вопрос. А когда вы в последний раз восстанавливали из них хотя бы один файл? Вот она неловкая пауза, понимаю… Между «бэкап есть» и «бэкап восстанавливается» находится пропасть, и в неё регулярно падают даже большие компании. Под катом две страшилки из реальной жизни и разбор того, как проверить свои бэкапы до того, как восстанавливать их придётся на боевом сервере.

У Яндекса есть публичная страница с 18 техническими мерами защиты Яндекс 360, и у части пунктов рядом с текстом стоит вкладка, где написано, каким методом API и с каким правом доступа эту меру проверить. Я прошёл её построчно и посчитал: вкладка «Проверка через API» есть у 10 пунктов из 18, вкладка «Настройка через API» — у 5.

Александр Жогов, основатель и руководитель компании +Альянс. И справка, и референс API открыты: весь счёт повторяется поиском по двум строкам в машинной выгрузке страницы, методику показываю целиком.

Когда ты пишешь собственный кодек удалённого рабочего стола, последнее, что хочется услышать от человека из конкурентов:

Недавно я рассказывал про Sheeternetes — оркестратор, у которого control plane живёт в таблицах. Здесь — про следующий логичный шаг: паттерн «оператор», применённый к самим таблицам. Настоящий полноценный Sheeternetes-оператор. Не скрипт внутри таблицы, а внешний контроллер, который приводит табличку к желаемому состоянию.

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

Сентябрь 1991 года. Студент из Хельсинки в халате выкладывает в новостную группу первый релиз своей операционной системы Linux и почти извиняясь пишет: «Большим не будет». Внутри – 10239 строк кода и ноль юристов. Спустя тридцать с лишним лет эта «небольшая» система стоит за 3 миллиардами смартфонов, 95% веб-серверов и Международной космической станцией.

Это история о том, как финский хобби-проект Линуса Торвальдса стал крупнейшей опенсорсной коллаборацией в истории.

В один из дней в лаборатории раздался звонок. Звонил представитель организации, оказывающей услуги системного администрирования. Его первым вопросом было: «А вы умеете работать с ZFS?». Разумеется, мы пояснили, что у нас есть некоторые наработки в рамках собственных исследований, а также стандартные средства DR‑лаборатории, такие как PC-3000, где поддержка ZFS предусмотрена как минимум на базовом уровне.

Ответив на парочку каверзных вопросов клиента об устройстве ZFS, мы через некоторое время получили два SSD Samsung 870 EVO ёмкостью 2 ТБ, которые были объединены в зеркальный RAID‑массив (Mirror). Изначально комментарии сводились к тому, что оба диска рабочие, но один выпал из массива. Основная проблема заключалась в том, что был случайно удалён один из важных Zvol (блочный объект ZFS, используемый для виртуальных дисков). Клиент пояснил, что хотел откатиться к прошлой версии uberblock’а и получить снимок, когда этот Zvol ещё не был удалён, но у него это не получилось. Резервная копия сохранилась, но она была сделана ещё в апреле этого года.

Приветствуем, Хабр.

У нас вышла долгожданная новинка, посвящённая методологии «SRE» — Site Reliability Engineering. Книга называется «SRE. Новый подход к управлению инфраструктурой». Написал эту книгу выдающийся инженер Павел Рудницкий, автор «Инфраструктурного блога», разработчик с 25-летним стажем, практиковавший DevOps, когда это ещё не было мейнстримом.

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

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

Хабр, привет! Есть такой тип проектов, которые начинаются со слов «а что если» и заканчиваются тем, что ты в три часа ночи объясняешь kubelet-у, что таблица — это его новый control plane. Так вышло и тут, всё родилось из субботней шутки в одном телеграм-канале по кубернетесу.

Правила игры простые: раз весь мир можно создать в эксельке, то пускай всё состояние кластера живёт внутри электронной таблицы. Не «метаданные в таблице», не «экспорт в CSV» — а буквально: Deployments, Nodes, Pods, Events — это вкладки Google Sheets (или листы Excel). Планировщик читает и пишет ячейки. kubectl-подобная утилита ходит в таблицу. И — вот это ключевое — на другом конце крутятся настоящие Docker-контейнеры. Таблица не симулирует кластер. Таблица и есть кластер.

Проект называется Sheeternetes. Это, конечно, шутка. Но шутка, которая компилируется, проходит тесты и переживает падение ноды.

Ниже — как это устроено, как это поднять у себя за пять минут, как оно работает на bare metal без интернета (в Excel и LibreOffice), как связать несколько таблиц-кластеров в федерацию с живой миграцией, почему контейнеры можно хранить прямо в ячейках, — и что это внезапно выросло в целый фонд с 30 проектами, стандартом контейнеров и системой сертификации.

После того как мой пет-проект случайно «выстрелил» на Reddit, я решил, что пора поделиться так же и своей кроссплатформенной библиотекой на C++20 для мониторинга железа, с нативной поддержкой Python.

Рассказываю историю создания hardware_monitor_cpp: как избавиться от лишних зависимостей, получить адекватную статистику swap-файла под Windows и macOS, упаковать все в удобное C++ API, а заодно получить готовую консольную утилиту с визуализацией графиков прямо в терминале.

Привет, Хабр! Меня зовут Максим Шуматбаев, я инженер технической поддержки в Arenadata. Эта статья — попытка собрать в одном месте внутренние механизмы Apache Kafka, которые задействованы при работе клиентских приложений. Цель простая: дать понимание, с которым типовые инциденты перестают выглядеть загадкой и разбираются за минуты, а не за дни.

«Это ТСПУ РКН, поделать ничего нельзя» — а проблема три месяца ждала в консоли сервера

Время расследования · 2 дня Причин найдено · 3 Команд для победы · 1

Клиент — онлайн-СМИ застройщика федерального уровня, несколько десятков публикаций в день, своя редакция. С июня сайт периодически становился недоступен. Подрядчик, который ведёт техподдержку, прислал такое сообщение:

Любой, кто ставил софт в Linux, набирал apt install или pacman -S. Внешне разница косметическая: одни команды длинные, другие короткие. Но за этими командами стоят две принципиально разные инженерные философии.

Почему pacman ощутимо быстрее, но при этом опаснее в руках новичка? Почему Arch категорически запрещает частичные обновления, а Debian их даже не замечает? И почему один менеджер задаёт вопросы про конфиги, а другой молча подкладывает .pacnew?

Разбираем, что происходит внутри при установке пакета: форматы архивов, базы данных, решатели зависимостей, скрипты и хуки. Погружаемся в устройство apt/dpkg и pacman/libalpm глубже, чем в большинстве туториалов.

Падает один шлюз - и дежурному прилетает пачка уведомлений: молчат хосты за ним, гаснет uptime-монитор, срабатывают метрические пороги, горит SLO. Событие одно, уведомлений десятки. Разбираю, как собрать такой каскад в одну карточку инцидента и почему наивная реализация ломается: почему группировать надо по верхнему упавшему предку, а не по прямому родителю; что делать, когда события приходят в обратном порядке; почему “молчит, потому что за него сказал корень” и “не эскалируется, потому что родитель лежит” - это два разных состояния, которые нельзя склеивать; и где в такой системе обязательно выбирать шум вместо тишины. С кодом обхода графа, схемой таблиц и списком граблей.

Про BiHA (встроенную отказоустойчивость Postgres Pro) написано немало, и почти всё написано вендором. Материалы честные и полезные, но все статьи написаны в одном продуктово-обзорном жанре: как устроено, из чего состоит, что умеет. Практической и эксплуатационной боли в них нет. Я решил зайти с другой, инженерной стороны, с замерами, аварийными сценариями и цифрами.

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