# Что находится при приёме чужой инфраструктуры

Прежде чем брать систему на обслуживание, мы её изучаем. Не ради формальности: подписать SLA на инфраструктуру, устройства которой не знаешь, — способ гарантированно нарваться. Ниже — реальный список находок по одной платформе. Она работала, пользователи были довольны, никто ничего не подозревал.

## Что смотрели

SaaS-платформа: кластер Kubernetes из десяти узлов, около двадцати пяти микросервисов, очереди, кеши, поиск, публичные фронты. Возраст — почти пять лет. Разработка своя, эксплуатацией занимались по остаточному принципу.

## Что нашли

**Версии, снятые с поддержки — всё сразу.** Kubernetes отставал на три года от конца поддержки, container runtime — тоже, ОС на узлах — тоже. Исправления безопасности не приходят ни на один слой. Обновление такого кластера — это не «накатить пакет», а отдельный проект с последовательным переходом через промежуточные версии и заменой системы на узлах.

**Нет запаса на отказ узла.** Шесть рабочих узлов, загруженных так, что падение любого добавляет остальным пятую часть нагрузки — на пиках это выход за сто процентов. Хуже: часть служебных компонентов прибита nodeSelector к конкретным узлам, и при отказе такого узла они просто не переедут никуда.

**Просроченный сертификат, который полгода пытался обновиться.** cert-manager повторял выпуск каждые двадцать минут — накопилось почти семьсот неудач подряд, и никто этого не видел: alert на срок действия сертификатов не был настроен.

**Сервис, который перезапускался каждые пять минут.** descheduler выселял его поды: podAntiAffinity и topologySpreadConstraints были заданы так, что расставить их без нарушений не получалось. Отдельные поды жили чуть больше минуты. Снаружи это выглядело как случайные ошибки на части запросов — их списывали на «иногда бывает».

**Кеш авторизации без резерва.** Один экземпляр, без реплики и с отключённым persistence. Его падение означало разлогин всех пользователей разом и шторм запросов в базу на холодном старте.

**Описание не совпадало с реальностью.** В манифестах Deployment одного из компонентов были прописаны образы, которых больше нет в registry: производитель удалил их. Любое обновление этого компонента положило бы его насовсем — образ остался только на одном узле из десяти.

**Память узла на 87 % при среднем в 55 %.** Тренд рос полгода. Ещё один всплеск — и узел уходит в swap или прилетает OOM killer.

**Пароли в открытом виде.** Доступы к базе, очередям и кешу лежали открытым текстом в манифестах вместо Secret'ов и внешнего хранилища секретов. Любой, у кого есть право читать манифесты, видел их целиком; они же попадали во все выгрузки состояния кластера.

![Выборка находок аудита и разделение исправлений на немедленные работы и проекты](/images/illustrations/part2/16-case-audit.webp)

## Что с этим делали

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

Главная ценность аудита не в списке, а в том, что после него разговор с заказчиком идёт предметно: вот риск, вот его цена, вот стоимость устранения. Дальше бизнес решает сам — но уже зная, за что платит и чем рискует.