Подготовка инфраструктуры Linux к инцидентам: обязательный минимум

• `atop` — фиксирует нагрузку на CPU, использование памяти, активность диска и сети, подсвечивает проблемные места различными цветами и позволяет быстро локализовать причину деградации системы;
• `strace` — трассировка системных вызовов процесса, показывающая, с какими запросами приложение обращается к ядру, — например, открытие файлов, сетевые операции, ожидание блокировок;
• `lsof` — перечисление открытых файлов, сетевых сокетов и других сущностей, связанных с конкретным процессом или пользователем;
• `perf` — инструмент низкоуровневого профилирования, работающий на уровне ядра Linux и использующий аппаратные счетчики производительности;
• `free` — сводка использования оперативной памяти и области подкачки;
• `vmstat` — статистика по виртуальной памяти, процессам, I/O и CPU;
• `pmap` — карта памяти конкретного процесса: какие области адресного пространства существуют и как они отображены;
• `smem` — учет разделяемой памяти. Показывает, сколько памяти реально использует процесс;
• `dig` — выполнение DNS-запросов и анализ ответов DNS-серверов;
• `tcpdump` — захват сетевых пакетов на указанном интерфейсе. Позволяет увидеть сетевые обращения на уровне пакетов;
• `mtr` — сочетание ping и traceroute;
• `ss` — современная замена netstat. Выводит информацию о сетевых сокетах и установленных соединениях;
• `tmux` — мультиплексор терминала;
• `screen` — альтернативный терминальный мультиплексор.

Типичный случай: процесс приложения внезапно нагружает CPU или перестает отвечать, а в логах нет признаков, по которым можно обнаружить проблему. Трассировка системных вызовов показывает, где именно висит процесс. Связка инструментов позволяет локализовать проблему до конкретного процесса и сегмента памяти.

Диск и блочный I/O

• `iotop` — дисковая активность, сгруппированная по процессам;
• `iostat` — метрики производительности дисков;
• `biolatency` — гистограммы задержек блочного I/O на уровне ядра;
• `biotop` — какие процессы генерируют блочный I/O в реальном времени.

Типичный сценарий: сервис периодически замедляется, а по CPU и памяти все вроде бы выглядит нормально. Штатный мониторинг снимает метрики раз в минуту и усредняет их, поэтому кратковременные пики не попадают в агрегированные данные.

Почему практика «поставлю, когда потребуется» не работает?

Когда недоступен внутренний репозиторий, вся инфраструктура одновременно теряет возможность ставить пакеты. Внешние репозитории закрыты политиками сетевого периметра. Ломается именно та подсистема, которая нужна для диагностики. При отказе DNS-сервиса становится сложнее установить dig, поскольку пакетному менеджеру также требуется DNS. То же самое происходит при отказах прокси-серверов или пограничных маршрутизаторов.

С контейнерами тоже проблемы: в образе нет пакетного менеджера или shell. В кластерах и контейнерах с включенными политиками безопасности подключение средств диагностики требует времени.

Особенности диагностики в Kubernetes

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

В случае с Kubernetes есть несколько рабочих инструментов, которые обычно применяются во время сбоев:

• Вспомогательные контейнеры. Параллельные контейнеры в составе пода, содержащие диагностические утилиты.
• Инструменты уровня кластера. kubectl debug, ksniff, stern, kubespy. Обеспечивают диагностику состояния подов, перехват сетевого трафика, агрегацию журналов по всем репликам сервиса.

Для диагностики Kubernetes-кластеров нужно иметь немало узкоспециализированных навыков. CNI-плагины, правила фильтрации на узлах, kube-proxy, сетевые политики — все это выходит за пределы классического Linux-администрирования. Поэтому нужно либо целевое обучение, либо отдельная позиция инженера по k8s.

Требования к навыкам инженеров

Необходимо не только иметь в наличии утилиты для диагностики, но и правильно их применять. Аудиты регулярно показывают разрыв: инструменты есть, а пользоваться ими толком никто не умеет.

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

1. Владение всеми утилитами, представленными в разделе «Минимально необходимый состав инструментов».
2. Диагностика сети: ARP, DNS, TCP-соединения, MTU, маршрутизация.
3. Понимание метрик памяти (VIRT, RES, SHR и др.) в top/htop.
4. Жизненный цикл процессов: сигналы, системные вызовы, состояния, в которых может находиться процесс.
5. Дисковая подсистема: особенности мониторинга и эксплуатации различных типов дисков: SSD, HDD. Общая информация об устройстве файловых систем.
6. Контейнерные абстракции: инструменты для траблшутинга контейнерных сред, описанные выше в статье.
7. Инструменты и утилиты для работы с тем ПО, которое работает на серверах. Например, PostgreSQL -> psql, MongoDB -> mongosh, Redis -> redis-cli и т. д.

Тренировки по устранению неполадок с сервисами — это важная и полезная практика.

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

Основная цель таких мероприятий — отработка навыков использования утилит, позволяющая понять, на какие метрики смотреть и какие параметры анализировать на практике.

Практики поддержания готовности

Комплексная подготовка к инцидентам в части Linux-инфраструктуры включает несколько взаимосвязанных направлений.

Подготовка базовых образов

Эталонный образ (golden image) — базовый образ операционной системы. Такой образ содержит необходимое программное обеспечение и настройки конфигурации и используется для развертывания остальных систем.

Перед нами стоит задача, чтобы с момента развертывания на хосте было оптимальное количество инструментов. Рекомендуемый объем 20–25 пакетов: диагностические утилиты, базовые и продвинутые средства работы со всеми подсистемами Linux. При этом все пакеты необходимо проверять на известные уязвимости. Готовый образ криптографически подписывается, размещается во внутреннем реестре и фиксируется как эталонный.

Централизованная установка ПО на все Linux-хосты компании

Установку утилит для диагностики необходимо распространить на все серверы, включая отечественные сертифицированные дистрибутивы (например, Astra Linux, RedOS, ALT Linux).

Сделать это можно, например, через Ansible, SaltStack или их аналоги, поскольку установка вручную зачастую приводит к расхождениям по версиям, да и в целом неэффективна по времени.

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

Контроль за использованием отдельных инструментов

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

Хорошая практика также предусматривает квартальный автоматизированный аудит, который закрывает сразу несколько проблем:

• наличие утилит из эталонного набора;
• соответствие установленных версий утвержденным;
• соответствие конфигурационных параметров эталонным значениям.

Понятная и обширная документация

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

Экономические последствия

Снижение MTTR — не просто абстрактная метрика, а вполне измеримый показатель, связанный с финансовыми потерями организации.

Стоимость любого инцидента складывается из времени недоступности сервиса и скорости его восстановления. Если при восстановлении системы инженер тратит 20–30 минут не на диагностику, а на подготовку среды, эти минуты целиком уходят в стоимость инцидента.

При расчете потерянных средств необходимо учитывать несколько пунктов:

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

К этому также можно добавить санкции надзорных органов и сорванные внутренние целевые показатели доступности.

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

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