Что нужно делать для поддержки инфраструктуры

Что проверяют

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

Как отвечать

Разложите на направления:

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

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

Где спотыкаются

Перечисляют инструменты вместо задач. Список названий не отвечает на вопрос, и следом спрашивают что-то вроде «алерт сработал, ваши действия», где список уже не помогает.

Смешивают создание ресурсов и настройку узлов в одну строчку. Это разные слои с разными инструментами, и слепленные вместе они выдают человека, который ни то ни другое не настраивал сам.

Говорят про резервные копии, но не про восстановление. Вопрос «сколько времени займёт подъём базы и сколько данных потеряется» вскрывает это мгновенно: без цифр по времени и точке восстановления копия остаётся ритуалом.