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

Меня зовут Андрей Зотов. Я незрячий, работаю техником и системным администратором. По работе мне нужны загрузочные флешки: запустить установщик, посмотреть состояние диска, забрать файлы с компьютера, на котором не загружается основная система.

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

Так появилась FlashOS. Я хотел загружаться с одной флешки, слышать названия образов и выбирать нужный с клавиатуры. А новый образ добавлять обычным копированием файла. Сейчас к этому добавились диагностика и несколько инструментов для обслуживания компьютера. Проект уже лежит на GitHub; дальше расскажу, как он устроен, что умеет и где пока остаются ограничения.

Привет! Я Сергей Житинский, основатель Git in Sky. Мы занимаемся эксплуатацией и технической поддержкой ИТ-инфраструктуры. Agent-Ops — проект открытой отраслевой методологии совместной работы инженеров и ИИ-агентов. Мы начали разрабатывать его весной этого года и сейчас выложили первый кандидат версии 0.4.0 на GitHub и GitVerse. Одновременно, на конференции IT Elements 2026 мы договорились о совместной работе с инженерами из 2х других компаний, они стали у нас maintainers. Поэтому сегодня Agent-Ops - это не инициатива только одной компании, а совместной работа нескольких. Надеюсь, количество единомышленников будет увеличиваться. Приглашаем контрибуторов развивать этот проект вместе с нами.

Я ожидаю масштабных изменений в ИТ-отрасли, поэтому решил лично заняться этой работой внутри Git in Sky, а наши подходы и предложения вынести на обсуждение профессионального сообщества. Меняется сама организация работы: кто исследует проблему, на каком основании предлагает решение, кто разрешает изменение и кто отвечает, если оно привело к аварии.

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

Я ожидаю масштабных изменений в ИТ-отрасли, поэтому решил лично заняться этой работой внутри Git in Sky, а наши подходы и предложения вынести на обсуждение профессионального сообщества. Меняется сама организация работы: кто исследует проблему, на каком основании предлагает решение, кто разрешает изменение и кто отвечает, если оно привело к аварии.

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

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

Привет! Это Скутин Антон. Я работаю в «Петрович-Тех» руководителем отдела обеспечения доступности ИТ-сервисов. Моя предыдущая статья была про ITIL. В этот раз я решил рассказать о том, как построить наблюдаемость, когда нет ни CMDB, ни oncall.

Эту тему я рассказывал на Observability Conf, коллеги завалили вопросами, поэтому решил поделиться здесь, подключайтесь в комментарии — обсудим!

Хабр, привет!

На связи Алина Байрамова, аналитик-исследователь угроз кибербезопасности R-Vision. 

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

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

В этой статье разберем три публичных PoC для Dirty Frag: два варианта эксплуатации CVE-2026-43284  через ESP/XFRM и один для CVE-2026-43500 через RxRPC.

Посмотрим, какие системные вызовы выполняют эксплойты, какие следы остаются в событиях Linux и какие признаки можно использовать для обнаружения эксплуатации. В результате соберем детекты для разных вариантов Dirty Frag и сравним, какие признаки остаются стабильными между реализациями PoC.

В первом квартале 2026 года 17,7% проданных серверных процессоров были на ARM. AWS уже выпускает пятое поколение Graviton, Google предлагает Axion не только в виртуалках, но и на bare metal, Microsoft разворачивает Cobalt 200, а Oracle использует AmpereOne. При этом индустрия уже дважды хоронила эту архитектуру — в 2013 и в 2018 году. Под катом расскажу, кто лежит на кладбище ARM, почему третий заход оказался успешнее и готов ли ваш стек к переезду.

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

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

В этой статье расскажем, что такое IPMI-мониторинг серверов и рассмотрим принцип его работы. Также посмотрим, как настроить IPMI-мониторинг для выделенных серверов в Selectel.

На разборе учебной рассылки мне показали письмо, отправленное от адреса компании ей же самой. Оно дошло во «Входящие». Без пометок, без папки «Спам», с правильным именем отправителя в списке писем.

Первое, что я подумал, - что-то не настроено. Полез в DNS: SPF на месте, ключ DKIM опубликован, подписи ставятся. Запись DMARC тоже нашлась. Всё, что положено, - есть.

Оказалось, что настроено всё правильно и работает как задумано. Просто задумано не то, что от этого ждут, - а в записи DMARC стояло значение, которое ничего не запрещает.

Это вторая часть разбора ошибок конфигурации MS SQL Server под 1С. Первая часть — про планирование и развёртывание: профили нагрузки, дисковая подсистема, баланс ресурсов, инсталляция и виртуализация, здесь первая часть. Там же была описана типичная история дефолтного развёртывания сервера на прод или «как не надо».

Побудившая меня написать всё это предыстория такова: сервером СУБД под 1С обычно занимается системный администратор в паре с 1С‑разработчиком или франчом, уровень СУБД теряется где‑то между их компетенциями. Первая часть была про то, как этот разрыв закладывает проблемы при развёртывании. Вторая (эта) — про то, как этот же разрыв в компетенциях мешает найти причину, когда система уже тормозит «и всё висит, и прод лежит».

Напомню и про два профиля настроек для СУБД из первой части: первый — тяжёлая ERP с одной большой базой, второй — стопка из сотни бухгалтерских баз на одном инстансе. Настройки, о которых пойдёт речь ниже, зависят от профиля использования так же, как зависела схема размещения данных из предыдущей части. К концу статьи станет видно, из чего складывается ответ на вопрос «почему тормозит», и что железо в этом ответе часто ни при чём.

Все звонки начинаются как под копирку

«База висит». «Окна не открываются». «К вечеру всё тормозит так, что документ не провести». Жалобы на сервер 1С звучат одинаково в рознице, в производстве и в бухгалтерии, но причины под одинаковыми симптомами всякий раз оказываются разными. Посмотреть, какие типы ожиданий превалируют на сервере, найти тяжёлые запросы, указать в каких местах и что можно поправить. За каждым этим шагом стоит достаточно узкая компетенция администратора баз данных, отдельная профессия — DBA. Разработчики этим навыком, как правило, не владеют, у них другая специализация, отсюда следствие: код, который прекрасно работает на тесте, в проде начинает работать очень тяжело. На тесте нет ни боевых объёмов, ни конкуренции за строки, ни сотни пользователей, проводящих документы одновременно. В проде есть всё и сразу.

Сайзинг RAM и vCPU для локальной языковой модели начинается с конкретных весов и профиля запросов. Исходные требования self-hosted LLM включают длину входа и ответа, конкурентность, рантайм и схему offload. Расчёт по размеру весов и формуле KV-кэша даёт стартовую конфигурацию, а прогретый тест показывает реальное потребление памяти и точку, где CPU перестаёт помогать.

Что, если добавить виртуальной машине процессоров — и она станет работать медленнее? В сильно переподписанных серверах это не мысленный эксперимент, а повседневность. Новый механизм ядра Linux — steal governor — предлагает решать проблему с другого конца: не раздавать ВМ больше ресурсов, а научить её добровольно ужиматься.

Многие из нас когда-то проводили десятки, а то и сотни часов на публичных серверах Counter-Strike разных версий: от 1.6 до Global Offensive. Всех их объединяла атмосфера уникального хаоса, кастомных плагинов, новых знакомств и полуночных разговоров. Но с ростом киберспорта культура публичных серверов стала постепенно уходить на второй план. Молодёжь больше играет в соревновательные режимы — FaceIT или Premier.

С выходом CS2 и переходом на новый движок Source 2 ситуация стала ещё сложнее: старые плагины перестали работать, а инструменты для пользовательских серверов пришлось адаптировать. Постепенно разработчики освоили создание пользовательского контента для новой версии, и публичные серверы снова начали появляться.

В этой статье разберём, как создать собственный сервер Counter-Strike 2 на VPS, установить плагины, настроить карту и добавить на неё собственный контент.

Claude Code не привязан к api.anthropic.com: это обычный клиент, и куда он ходит, задаётся двумя переменными. Разбираю, что именно нужно ему от эндпоинта, три способа подключения (shell, settings.json, apiKeyHelper), как проверить curl-ом до запуска и что означают типовые ошибки — 401, 403 с HTML, «auth may not work as expected» и внезапный 404 на haiku. Без названий сервисов, только механика.

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

Большинство разговоров о сетевой безопасности крутятся вокруг систем, которые стоят на пути трафика и должны принять решение здесь и сейчас: NGFW, WAF, IDS. Но есть и другой класс систем — те, что работают не с самим трафиком, а с его зеркальной копией, и потому могут анализировать происходящее сколько угодно долго. Эта статья — про то, что удаётся увидеть NTA/NDR-системам именно благодаря этому запасу времени: от восстановления цепочки атаки шифровальщика по сохранённым метаданным до обнаружения ботнета, для которого ещё не существовало сигнатуры.

В новом релизе Ideco NGFW Novum мы собрали функции, которые обычно приходится искать в разных слоях инфраструктуры: видимость AI-сервисов, развитую динамическую маршрутизацию, QoS и строгую аутентификацию. Разберем задачи, которые релиз закрывает в больших распределенных сетях, ЦОД, на перегруженном WAN-канале и в регулируемом контуре.

AI уже в сети, даже если его ещё нет в реестре ИБ

Shadow AI начинается с обычного рабочего действия: сотрудник открывает чат-бот (а уже наверное и разворачивает агент), разработчик подключает API-модели, аналитик загружает таблицу в ассистент, а инженер запускает локальный inference-сервис для эксперимента. У каждого действия может быть разумная цель, но у ИБ нет ответа на базовый вопрос: какие AI-инструменты реально используются в сети?

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

Это не только вопрос дисциплины. AI-агент внутри сети может быть развернут злоумышленниками для быстрого закрепления в инфраструктуре. Или небезопасно настроенный и используемый агент может в будущем «заразиться» и перейти на «темную сторону силы».

Запретить все AI-сайты целиком – простой, но слабый ответ. Он не отделяет утверждённый корпоративный сервис от личного аккаунта, не помогает понять реальный спрос и подталкивает пользователей искать обходы. До политики нужен инвентаризационный слой: сначала увидеть сервисы, затем классифицировать риск, определить допустимые сценарии и только после этого применять ограничения.

Кроме того, из-за официальной недоступности в России многих AI-сервисов, в рунете широкое распространение получили сервисы-прокси и агрегаторы AI-моделей, самостоятельно составлять и поддерживать их списки – неблагодарная работа.

Объём неиспользуемых ресурсов не уменьшается (хотя вроде как должен), а узлы бесконечно ротируются. Это нормально для автоскейлера или пора что-то чинить?

В статье — детально о механизме консолидации в Karpenter, а главное — можно (и нужно) ли как-то его исправлять.

Раз в неделю падает один и тот же сервис. Админ его перезапускает, пользователи возвращаются к работе, инцидент закрывают. Через несколько месяцев авария превращается рутину, и так продолжается годами. Управление проблемами — problem management — начинается в тот момент, когда кто-то все-таки спрашивает: «Почему это повторяется?». Для сервисного провайдера это логичное продолжение управления инцидентами. Обычно мы сами инициируем разбор, как только серия однотипных происшествий перестает выглядеть случайностью.  Но если ты аутсорсер, то найти root cause — это только полдела. Дальше нужно понять, что с ней делать. Причина может оказаться в продукте вендора, легаси заказчика или системе другого подрядчика — то есть там, где инженер внешней техподдержки не может просто взять и исправить ее. Но и тогда можно попробовать договориться и исправить ее. Об этом сегодня и пойдет речь. 

Меня зовут Наталия Сляднева и я руковожу Центром экспертизы по комплексному сервису К2Тех. Под катом — два расследования с разными финалами и третий случай, в котором проблему осознанно не стали решать. Иногда это самый рациональный вариант.

Сайт на 1С-Битрикс может месяцами работать вроде нормально, пока подключения к базе подбираются к 95%, диск незаметно заполняется логами, бэкап давно не запускался, а в логах копится одна и та же ошибка, на которую никто не смотрит.

Разбираем пять инфраструктурных причин, из-за которых Битрикс-проекты тормозят и падают: база данных, диск, PHP и веб-сервер, резервные копии, мониторинг. В каждом разделе есть простая проверка, которую можно провести у себя за 10 минут.

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

У нас получилось немного иначе.

При подключении нового пилотного контура PostgreSQL к Zabbix выяснилось, что Mamonsu успешно работает с базой данных и собирает метрики, но не может передать их на сервер мониторинга, если тот принимает от узла только защищённые соединения с TLS PSK.

Можно было изменить настройки Zabbix или построить обходную схему вокруг штатного zabbix_sender. Вместо этого мы решили доработать сам Mamonsu. В результате появилась поддержка TLS PSK и сертификатов с сохранением совместимости как со старыми серверными версиями Python, так и с современными версиями Python, где PSK уже поддерживается стандартным модулем ssl.

Доработку проверили на пилотном контуре, после чего отправили разработчикам Mamonsu в upstream.