Вопросы на собеседовании: Системный администратор
100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior.
Смотреть пример резюме: Системный администратор →Тренировка флешкарточками
Интервальное повторение · Hunter Pass
Вопросы
Я сделаю каждый зал независимым доменом отказа и зарезервирую мощность N+1 за его пределами.
- Распределю каждый сервис из 3 узлов по 3 залам с отдельным питанием, ToR-коммутаторами и путями к хранилищу для каждого RHEL-хоста.
- Рассчитаю 2 оставшихся зала на 100% нагрузки при 70% CPU, поэтому штатное размещение не превысит 46% на зал.
- Приму только проект, где карта зависимостей и ежеквартальный тест изоляции подтверждают потерю 1 зала без потери общих DNS или идентификации.
Зачем это спрашивают: Интервьюер проверяет, охватывает ли резервирование связанные зависимости и достаточно ли оставшейся мощности.
Я размещу взаимозаменяемые Ubuntu-инстансы за 2 независимыми парами HAProxy и вынесу всё постоянное состояние наружу.
- Сессии сохраню в Redis, файлы в объектном хранилище и потребую, чтобы любая 1 из 4 зон безопасно теряла 100% мощности.
- При 250 запросах/с на хост и целевой загрузке 60% выделю 800 хостов, поскольку 120 000/(250×0,60)=800.
- Буду дренировать соединения 30 секунд и приму релиз, только если 5% канареек держат p99 ниже 200 мс с запасом 25%.
Зачем это спрашивают: Сильный ответ объединяет отсутствие локального состояния, отказоустойчивость, расчёт мощности и измеримые условия выкладки.
Я настрою 1 активного владельца VRRP и 1 резервного, меняя приоритет по готовности HAProxy.
- Узлу A дам приоритет 150, узлу B 140, включу unicast VRRP и штраф 20 пунктов при проблеме HAProxy.
- Установлю объявления раз в 500 мс, отключу preemption после возврата и отправлю 3 серии gratuitous ARP при переносе VIP.
- Оставлю 50% запаса соединений на узел и приму проект, если 20 тестов восстановят трафик за 3 секунды.
Зачем это спрашивают: Интервьюер ожидает корректное владение VRRP без опасного обратного переключения и нехватки мощности.
Я потребую 3 из 5 голосов Corosync и успешный STONITH до запуска ресурса Pacemaker на другом узле.
- Размещу 2 узла в помещении A, 2 в B и 1 в C, используя 2 независимые сети Corosync.
- Настрою IPMI-фенсинг через 2 линии питания с таймаутом 60 секунд, поскольку quorum не остановит изолированный пишущий узел.
- Разрешу сервис минимум при 3 голосах и приму фенсинг после 20 тестов отключения старого узла до promotion.
Зачем это спрашивают: Ответ должен отличать полномочия большинства от фенсинга, предотвращающего одновременную запись.
Я выберу active-passive, потому что 12 мс синхронной межплощадочной записи затронут все 8 000 записей/с.
- Оставлю 1 основную площадку и 1 тёплый резерв, применю асинхронную репликацию и ограничу lag уровнем RPO в 30 секунд.
- Перед promotion отключу старую основную площадку от питания и хранилища, принимая простой резерва ради отсутствия 2 пишущих владельцев.
- Рассчитаю каждую площадку на 100% нагрузки при 65% CPU и ежеквартально проверю RTO в 10 минут.
Зачем это спрашивают: Интервьюер оценивает согласованность, задержку, фенсинг и стоимость пассивной мощности.
Я разделю авторитетные зоны и рекурсивный резолвинг и разверну оба уровня во всех 4 площадках.
- Запущу по 2 резолвера Unbound на площадку с anycast или DHCP, отделив 8 кешей от авторитетных BIND-серверов.
- Назначу TTL 30 секунд только перемещаемым сервисам и 3 600 секунд стабильным хостам, выборочно балансируя нагрузку и скорость.
- Приму проект, если отказ 1 площадки сохранит 99,9% некешированных ответов быстрее 100 мс.
Зачем это спрашивают: Senior-проект разделяет роли DNS и выбирает TTL по измеримым требованиям к сходимости и нагрузке.
Я использую control plane Consul из 5 серверов и DNS-имена, скрывающие эфемерные адреса узлов.
- Размещу 5 серверов Consul в 3 доменах отказа, потребую 3 голоса и не включу агенты в голосование.
- Буду проверять readiness каждые 10 секунд и удалять регистрацию через 30 секунд, принимая краткую устарелость вместо flapping.
- Установлю кеш 5 секунд и приму 1 000 изменений/минуту при p99 ответа ниже 50 мс после отказа 1 voter.
Зачем это спрашивают: Интервьюер проверяет размещение quorum, семантику health-check, сходимость кеша и мощность control plane.
Я буду пересобирать версионируемые Packer-образы и заменять хосты, а не патчить 2 000 долгоживущих инстансов на месте.
- Зафиксирую digest базового RHEL и snapshot репозитория, подпишу каждый образ и сохраню 2 проверенные версии для отката.
- Проведу образ через кольца 1%, 10% и 25%, требуя 30 минут здоровья на каждом перед заменой флота.
- Приму образ после OpenSCAP, boot, systemd и тестов приложения, оставив 10% мощности для rolling-замены за 48 часов.
Зачем это спрашивают: Ответ должен показать воспроизводимые артефакты, поэтапную замену, доказательства безопасности и мощность для выкладки.
Я создам 36 удалённых state-корней по границам окружений и жизненных циклов вместо 1 глобального state.
- Сохраню все 36 state в версионируемом зашифрованном backend с блокировкой и дам каждой CI-идентичности доступ только к 1 state root.
- Запущу refresh-only plan каждые 6 часов и устраню drift через код, кроме явно разрешённого break-glass сроком 1 час.
- Приму разделение, если неудачный apply блокирует максимум 1 домен, а потребители используют меньше 10 стабильных outputs.
Зачем это спрашивают: Интервьюер проверяет, ограничивают ли границы state права и область воздействия без неконтролируемых связей.
Я получу dynamic inventory из CMDB и запущу закреплённые Ansible-окружения через региональные контроллеры.
- Закеширую inventory на 5 минут, сгруппирую по региону и сервису и прерву запуск при расхождении с CMDB более 2%.
- Использую 5 региональных контроллеров по 50 forks, сохраняя WAN-трафик локальным и ограничивая play 1 сервисной группой.
- Приму playbook после check mode и теста идемпотентности, где 2-й запуск меняет 0 ресурсов на 100 типовых хостах.
Зачем это спрашивают: Сильный ответ делает inventory авторитетным, выполнение ограниченным, а идемпотентность объективно проверяемой.
Для рискованного изменения я применю serial push-волны, а pull оставлю для обычной низкорисковой сходимости.
- Начну с 18 хостов, затем 180 и волн по 20%, выставив max_fail_percentage 2 и паузу 15 минут.
- Модулем Ansible sysctl обновлю running и persistent state без reboot и потребую, чтобы 2-й запуск показывал 0 изменений.
- Остановлю расширение при отказе health-check выше 1%; push контролирует волны, а pull раз в 30 минут позже снижает нагрузку контроллера.
Зачем это спрашивают: Интервьюер ждёт осознанный выбор push или pull, ограниченные волны и реальные проверки идемпотентности.
Я продвину подписанные snapshots репозиториев через 4 кольца, чтобы каждый хост получил одинаковый проверенный набор пакетов.
- Ежедневно зеркалирую upstream RHEL и Ubuntu, храню 3 immutable snapshot и отклоняю пакеты без GPG-подписи или SBOM-проверки.
- Обновлю 1%, 10%, 30%, затем 59% хостов с наблюдением 24 часа между кольцами и завершу за 14 дней.
- Приму кольцо при отказах сервиса ниже 0,5% и запасе мощности 15%, меняя скорость снижения риска на ограниченную область воздействия.
Зачем это спрашивают: Ответ связывает происхождение пакетов, детерминированные версии, расчёт выкладки и явные пороги безопасности.
Я отделю жёсткие требования от порядка запуска и не привяжу 900 сервисов к временной доступности сети.
- Добавлю RequiresMountsFor=/srv/data, а также Wants= и After=network-online.target, но приложение будет повторять Vault 120 секунд, а не зависеть от его порядка.
- Настрою Restart=on-failure, RestartSec=5 и StartLimitBurst=6 за 60 секунд, предотвращая массовый restart storm.
- Приму unit после 50 boot-тестов с томом до запуска и завершением в пределах 30-секундного TimeoutStopSec.
Зачем это спрашивают: Интервьюер проверяет точную семантику зависимостей systemd и ограниченное поведение внешних зависимостей.
Я размещу минимум по 2 writable Windows Server domain controller в каждом офисе и учту топологию sites.
- Запущу DNS и Global Catalog на всех 6 контроллерах, сопоставлю 3 AD Sites с подсетями и исключу зависимость от удалённой аутентификации.
- Осознанно распределю все 5 ролей FSMO между 2 центральными контроллерами; это переносимое владение, а не active-active резервирование.
- Приму проект, если потеря 1 офиса оставляет p95 входа ниже 2 секунд, а репликация сходится за 15 минут.
Зачем это спрашивают: Senior-ответ отличает резервирование контроллеров, локальность sites, DNS и владение ролями FSMO.
Я спроектирую 200 000 samples/s, потому что 2 000×1 500/15 равно 200 000 до запаса.
- Выделю по 2 одинаковых реплики Prometheus независимо на каждый региональный shard и рассчитаю каждую на 300 000 samples/s, добавив 50% запаса ingestion.
- Оставлю 15 дней локально, настрою remote write в Thanos и alert при WAL или ingestion выше 70% проверенной мощности.
- Приму платформу после 24-часового теста на 300 000 samples/s с p99 запроса ниже 2 секунд.
Зачем это спрашивают: Интервьюер оценивает расчёт sample rate, дублирование HA, retention и измеримый запас.
Я разделю сбор по регионам, продублирую каждый shard и применю Thanos для дедуплицированных глобальных запросов за 30 дней.
- Разверну по 2 реплики Prometheus в каждом из 5 регионов с external labels, чтобы 10 сборщиков переживали потерю 1 реплики.
- Буду отправлять blocks каждые 2 часа в объектное хранилище и хранить локально 24 часа, принимая задержку старых запросов.
- При отказе 1 WAN-канала локальные alerts должны считаться за 30 секунд, а глобальный p95 оставаться ниже 5 секунд.
Зачем это спрашивают: Проект должен сохранить локальный мониторинг и дать долговечную дедуплицированную глобальную видимость.
Я введу бюджеты labels до Grafana-дашбордов и направлю через Alertmanager только alerts, требующие действия.
- Ограничу exporter 2 000 активных series и запрещу labels вроде user_id, способные создать больше 10 000 значений.
- Severity 1 отправлю в PagerDuty за 60 секунд, severity 2 в очереди команд с группировкой по сервису на 5 минут.
- Приму rule только с 1 владельцем, 1 runbook и менее 5% ложных вызовов за 30 дней.
Зачем это спрашивают: Интервьюер ожидает конкретные ограничения стоимости cardinality и действенности alerts, а не больше дашбордов.
Я буду буферизовать логи на периферии, централизованно индексировать выбранные поля и распределю 240 ТБ за 30 дней по уровням.
- Запущу Vector на 4 000 хостах с дисковыми буферами 10 ГБ, защищая приложения при недоступности OpenSearch на 2 часа.
- Оставлю 7 дней на SSD в OpenSearch и 23 дня в объектном хранилище, принимая более медленный старый поиск.
- Ограничу индекс 50 полями на источник и приму проект, если replay 16 ТБ/день держит ingestion ниже 70% мощности.
Зачем это спрашивают: Сильный проект балансирует буферизацию, поисковое хранение, стоимость индекса и мощность повторной загрузки.
Я закодирую CIS Level 1 как политику OpenSCAP и оставлю SELinux enforcing с 3 отдельными доменами приложений.
- Автоматически применю 95% профиля CIS, а оставшиеся 5% оформлю как ограниченные исключения со сроком 90 дней.
- Создам политику из проверенных denials, сопоставлю 3 порта с app_port_t, помечу /srv/app как app_var_lib_t и запрещу широкие allow или permissive-домены.
- Приму хост при 98% compliance сканирования и 0 неожиданных AVC denial за 24-часовой тест нагрузки.
Зачем это спрашивают: Интервьюер проверяет измеримое применение baseline и узкую политику SELinux вместо отключения защиты.
Я разверну 2 enforcing-профиля AppArmor, дающих каждому демону только нужные файлы, capabilities и сетевое семейство.
- Демону A разрешу /srv/a/** r, 1 writable log path, network inet stream и capability net_bind_service; nftables откроет только TCP 443.
- Запущу профили в complain на 48 часов, проверю denials, затем переведу кольца 10%, 50% и 100% в enforce.
- Приму enforce при 0 неожиданных denials и росте p99 менее 2% на 20 000 запросов/с.
Зачем это спрашивают: Сильный ответ использует конкретные правила путей AppArmor и измеримое продвижение вместо общего обещания безопасности.
Закрытые вопросы
- 21
Как вы спроектируете сбор auditd для 3 500 Linux-хостов, ограничив нагрузку аудита уровнем 3% CPU?
designlinux - 22
Спроектируйте SSH- и PAM-доступ к 1 800 Linux-хостам для 60 администраторов с получением привилегий за 5 минут.
sshlinuxremote-access - 23
Как вы выдадите секреты 2 200 Linux-сервисам с ротацией за 24 часа и без статических credentials в образах?
secretslinux - 24
Спроектируйте сегментацию сети для 5 000 серверов в 4 зонах доверия, разрешив 300 документированных сервисных потоков.
design - 25
Как вы спроектируете LVM для хоста БД на 40 ТБ с maintenance snapshots на 2 часа и запасом роста 20%?
designstoragedatabase - 26
Выберите RAID для 12 дисков по 8 ТБ, если нужны 70 ТБ полезной ёмкости и устойчивость к любым 2 отказам дисков.
storage - 27
Спроектируйте файловую систему для 300 миллионов файлов по 8 КБ с 25 000 random IOPS и 30 ТБ полезной ёмкости.
designcapacitystorage - 28
Как вы спроектируете NFS для 1 200 Linux-клиентов с суммарным чтением 12 ГБ/с и доступностью 99,95%?
designavailabilityaggregation - 29
Спроектируйте распределённое хранилище на 5 ПБ raw в 60 Linux-узлах с допуском потери 1 стойки целиком.
distributeddesigncapacity - 30
Как вы реализуете backup 3-2-1 для 800 серверов с 600 ТБ данных и RPO 24 часа?
backupsdisaster-recoverybackup - 31
Рассчитайте backup-канал для передачи 24 ТБ за окно 8 часов с запасом throughput 25%.
backupsbackupthroughput - 32
Спроектируйте проверку backup для 200 критичных серверов с RPO 15 минут и RTO 2 часа.
designbackupsdisaster-recovery - 33
Как вы спроектируете warm-standby DR для 1 000 сервисов в 2 регионах с RPO 5 минут и RTO 30 минут?
designdisaster-recovery - 34
Спроектируйте quorum и репликацию для сервиса в 2 площадках, которому нужен 0 split brain и доступна 1 площадка witness.
designdistributed-systemsreplication - 35
Рассчитайте CPU для 2 400 хостов по 16 cores, пика 45%, роста 30% и потери 1 из 3 зон.
capacitycapacity-planning - 36
Рассчитайте RAM для 1 000 VM в среднем по 12 ГБ с ростом 20% и резервом 1 хоста на обслуживание в кластере из 20.
virtualization - 37
Рассчитайте хранилище для 600 ТБ данных с ростом 4 ТБ/нелю за 26 недель, 2 копиями всего и 20% свободного места.
- 38
Спроектируйте VMware-кластер для 600 VM в среднем по 4 vCPU на 12 хостах с допуском N+2 и пределом overcommit 4:1.
design - 39
Как вы спроектируете KVM-виртуализацию для 300 VM на 10 хостах с сетью 25 Гбит/с и резервом 1 хоста?
designvirtualization - 40
Спроектируйте Docker-изоляцию для 200 контейнеров на 20 Linux-хостах с целью 70% CPU.
dockercontainerslinux - 41
Как вы защитите 1 000 Docker-workloads, публикующих 80 сервисов и требующих 10 путей для записи?
docker - 42
Спроектируйте небольшой worker-уровень Kubernetes для 120 pods на 6 узлах с допуском отказа 1 узла.
designkubernetes - 43
Как вы предоставите Kubernetes storage для 40 stateful pods по 2 ТБ с RPO 15 минут и RTO 2 часа?
disaster-recoverykubernetes - 44
Спроектируйте Layer 4 balancing для 500 TCP-сервисов с 200 000 одновременных соединений в 3 зонах.
designload-balancingnetworking - 45
Как вы спроектируете routed management-сети для 3 000 хостов в 6 площадках с 2 независимыми WAN-путями?
designrouting - 46
Спроектируйте синхронизацию времени для 5 000 Linux- и Windows-хостов с точностью 50 мс в 5 площадках.
designlinux - 47
Как вы спроектируете централизованную Linux-идентификацию для 2 700 хостов и 8 000 пользователей с допуском отказа 1 площадки?
designlinux - 48
Спроектируйте lifecycle для 500 FreeBSD- и 2 500 Linux-хостов с 3 поддерживаемыми поколениями OS.
designlinux - 49
Как вы управляете конфигурацией 3 200 преимущественно Linux-хостов и 400 Windows-серверов с нестабильной связью?
configlinux - 50
Спроектируйте платформу на 3 000 хостов с HA, патчами, мониторингом, backup и security при цели 99,95%.
designbackupsbackup - 51
На 32-ядерном RHEL-хосте приложения load average вырос с 18 до 180, CPU загружен лишь на 35%, а 12 сервисов отвечают по таймауту. Как вы диагностируете и стабилизируете ситуацию?
- 52
На Ubuntu-хосте базы данных со 128 ГБ RAM память занята на 96%, swap на 42 ГБ, kswapd потребляет 70% CPU, а p99 запросов вырос с 80 мс до 4 секунд. Что вы сделаете?
databasequeriesmemory - 53
В 09:20 аутентификация отказала на 700 из 900 серверов, но CPU и память серверов приложений в норме. Как вы найдёте общий источник сбоя?
authmemory - 54
Ошибочный unit запускает 25 000 процессов на 64-ядерном хосте, PID заняты на 99%, а SSH едва может создать процесс. Как вернуть управление?
sshremote-accessconcurrency - 55
На 30 web-узлах load равен 60 при 16 ядрах, iowait составляет 55%, а задержка общего хранилища выросла с 4 до 220 мс. Какое решение вы примете?
incidentsincident-managementlatency - 56
Redis восстановился после 8 минут отказа, но 400 инстансов приложения одновременно повторили запросы и снова загрузили его CPU до 100%. Как разорвать цикл?
redisresiliencedependencies - 57
После обновления ядра 18% из 2 000 RHEL-хостов постоянно перезагружаются, а пять клиентских сервисов теряют quorum. Как восстановить флот?
distributed-systemskernel - 58
Корневая файловая система на 80 Ubuntu API-серверах заполнена на 100%, потому что один сервис пишет 6 ГБ логов в минуту. Каковы первые действия?
storageapi - 59
В почтовом spool на ext4 свободно 1,8 ТБ, но закончились inode, поэтому 12 000 сообщений нельзя поставить в очередь. Как восстановить сервис?
storagedata-structures - 60
PostgreSQL WAL заполняет том на 2 ТБ со скоростью 180 ГБ/час из-за replication slot, неактивного 11 часов. До заполнения базы осталось 25 минут. Что вы сделаете?
databasepostgresreplication - 61
Java-сервис удалил активный лог на 140 ГБ, но df показывает 98% заполнения, а du лишь 40%. Как вернуть место?
storage - 62
Debug-флаг заставил systemd-journald принимать 900 МБ/мин на 300 хостах, а центральное логирование отстаёт на 45 минут. Как локализовать ущерб?
logginglinuxsystem-design - 63
XFS data volume заполнен на 99%, в LVM свободно 800 ГБ, а запись остановится примерно через 40 минут. Как расширить его, не скрыв провал capacity planning?
capacitystoragecapacity-planning - 64
Backup repository заполнен на 97% во время weekly full, а 240 активных jobs могут занять последние 30 ТБ. Что вы остановите, а что сохраните?
backupsbackup - 65
После изменения DNS 35% клиентов получают SERVFAIL для внутреннего API, хотя прямые запросы к обоим authoritative BIND-серверам успешны. Как локализовать сбой?
dnsnetwork-servicesapi - 66
Трафик к сервису 10.40.0.0/16 перестал ходить из одного дата-центра после изменения route policy, но исходящие SYN уходят нормально. Что вы проверите?
routing - 67
API-запросы теряют 2,8% пакетов между двумя VLAN, а промежуточные узлы MTR показывают от 0% до 40%. Как найти реальную точку потерь?
troubleshootingapi - 68
После включения VPN-туннеля короткие SSH-команды работают, но передача файлов пакетами 1 500 байт зависает на 60% путей. Как обработать инцидент?
soft-skillsincidentsincident-management - 69
Linux NAT gateway перестаёт принимать новые соединения при 120 000 сессий, conntrack заполнен на 99%, а текущие сессии продолжают работать. Что вы сделаете?
gatewaynetworkingnetwork-services - 70
Два сервера отвечают за один production IP, ARP-записи меняются каждые 20 секунд, а половина запросов завершается ошибкой. Как восстановить сервис?
protocols - 71
LACP bond из четырёх линков остаётся up после деградации одного member, но некоторые flows теряют 6% пакетов. Как локализовать проблему?
troubleshooting - 72
Auditd показывает успешный root SSH login с неизвестного адреса 18 минут назад на production bastion. Что вы сделаете первым?
sshremote-access - 73
EDR обнаружил web shell на 14 из 600 Ubuntu web-серверов, причём все 14 используют одну версию image. Как вы отреагируете?
alerting - 74
Токен service account Terraform был доступен в публичном репозитории 47 минут и может менять 12 production subscriptions. Какова ваша последовательность?
tokensterraform - 75
Ночью 40 Linux-хостов загружают CPU до 100%, а неизвестный процесс из /tmp добывает криптовалюту. Как расследовать инцидент, не потеряв scope?
linuxconcurrency - 76
Частота переименования файлов резко выросла на 25 Windows-серверах, три backup share недоступны, есть подозрение на ransomware. Как сдержать атаку?
backupsbackup - 77
Новое правило sudo случайно дало passwordless root 1 200 developer accounts на 22 минуты. Как вы отреагируете?
passwordspermissionslinux - 78
Атакующий изменил 18 DNS-записей Active Directory и создал Domain Admin account. Два domain controller могут быть скомпрометированы. Где проходит граница восстановления?
dnsnetwork-services - 79
В RAID 5 из 12 дисков отказал один диск на 10 ТБ, rebuild займёт 31 час, а на втором диске появились read errors. Что вы сделаете?
storageestimation - 80
RAID 6 перестраивается после отказа одного диска, когда второй диск показывает 38 pending sectors. Сервис ещё работает. Каково ваше решение?
storage - 81
После сбоя питания mdadm RAID 1 с root загружается с одного member и помечает второй removed на 90 серверах. Как восстановить флот?
storage - 82
Задержка SAN выросла с 3 до 180 мс, multipath меняет пути 40 раз в минуту, а 70 виртуальных машин зависают. Как стабилизировать хранилище?
virtualizationlatency - 83
Ceph cluster достиг 91% raw usage во время восстановления 180 degraded placement groups, а клиентская задержка выросла втрое. Что вы сделаете?
latency - 84
XFS сообщает о повреждении metadata на томе 24 ТБ и перемонтируется read-only в пик трафика. Как восстановить его?
- 85
NFS filer переключился за 45 секунд, но 600 клиентов зависли со stale file handles, и jobs не продолжаются. Каков план восстановления?
recoveryproblem-solving - 86
После обновления RHEL 8 до RHEL 9 60 из 400 серверов попали в emergency shell, потому что root LVM volume не найден. Как откатить их?
storagerollback - 87
Во время миграции DNS на Windows Server доля ошибок запросов достигла 28% после того, как 2 000 клиентов получили новый resolver через DHCP. Как выполнить откат?
dnsnetwork-servicesqueries - 88
Миграция хранилища на 300 ТБ показывает 0,07% checksum mismatches после того, как приложения 35 минут писали в новый массив. Что вы сделаете?
migrations - 89
Миграция Ansible role меняет SSH configuration на 800 серверах, после чего 90 из них не принимают новые сессии. Как восстановить доступ?
configsshansible - 90
После обновления VMware tools и virtual hardware 40 из 250 VM теряют сеть при перезагрузке. Как выполнить откат?
rollback - 91
После обновления firmware storage controller на первом узле p99 I/O вырос с 8 до 95 мс, но vendor рекомендует завершить обновление всех четырёх узлов. Что вы решите?
procurement - 92
CPU demand растёт на 9% в месяц, 600 хостов уже достигают 72% в пик, а закупка занимает 90 дней. Что вы сделаете сейчас?
procurement - 93
Storage platform хранит 1,2 ПБ, растёт на 18 ТБ в неделю, заполнена на 78%, а новый проект добавит 160 ТБ через шесть недель. Как избежать заполнения кластера?
- 94
VMware cluster из 20 хостов достиг 88% RAM после добавления отделом продаж 120 VM, а потеря одного хоста потребует ballooning 900 ГБ. Как вы отреагируете?
- 95
Ежедневные backup теперь идут 11 часов при окне 8 часов, хотя линк 10 Гбит/с в среднем загружен лишь на 48%. Где искать и что менять?
backupsbackup - 96
Машинный зал допускает 140 кВт, работает на пике 126 кВт, а расширение на 20 серверов добавит 18 кВт. Как решить capacity-кризис?
soft-skillscapacitycapacity-planning - 97
Во время инцидента с inode junior-администратор удалил непроверенный spool-каталог, и исчезли 8 000 jobs. Как вы проведёте восстановление и разбор?
incidentsincident-managementdata-structures - 98
Middle-администратор предлагает отключить SELinux на 300 RHEL-серверах ради релиза через четыре часа. Как вы его направите и разблокируете релиз?
mentoringestimationhardening - 99
Новый on-call администратор получает 43 alerts за 20 минут и начинает перезапускать хосты без гипотезы. Как вы вмешаетесь и разовьёте его навык?
on-callalertinghypothesis-testing - 100
Сисадмин прислал Bash cleanup script, который будет запускаться от root на 2 500 хостах и удалять файлы старше семи дней. Как вы проверите его и подготовите автора к rollout?
mentoringscripting