Вопросы на собеседовании: Платформенный инженер
100 реальных вопросов с образцовыми ответами и пояснениями для уровня Staff Platform-инженер.
Смотреть пример резюме: Платформенный инженер →Тренировка флешкарточками
Интервальное повторение · Hunter Pass
Вопросы
Я сделал бы API платформы устойчивым контуром управления, а портал считал бы одним из заменяемых клиентов.
- Версионированные API сервисов и окружений валидируют запросы, сохраняют желаемое состояние и запускают асинхронные процессы с ключами идемпотентности.
- Backstage показывает каталог, шаблоны, статусы и документацию, а Git и облачные контроллеры остаются источниками данных для сверки состояния.
- Я измерял бы успешное провизионирование за 15 минут, доступность API и успех отката по тенантам, а не только доступность страниц портала.
Зачем это спрашивают: Вопрос проверяет, отделяет ли кандидат внутреннюю платформу разработчика как продукт от портала и проектирует ли платформу вокруг пути разработчика.
Все операции изменения состояния я оставил бы за документированным API платформы, а отображение и поиск отдал бы порталу.
- API отвечает за авторизацию, валидацию, идемпотентность, аудит и состояние процесса; плагины Backstage не вызывают облачные API напрямую.
- Портал отвечает за формы, поиск по каталогу, документацию и статусы, а интерфейс командной строки использует те же контракты API.
- Контрактные тесты и 12-месячная политика устаревания позволяют менять интерфейс, не ломая автоматизацию 80 команд.
Зачем это спрашивают: Сильный ответ сохраняет стабильные контракты автоматизации вместо привязки платформы к Backstage.
Я выпускал бы стандартный путь как версионированный продукт с автоматическим обновлением, а не перезаписывал один шаблон.
- Новые сервисы получают v2, а для репозиториев v1 создаются запросы на слияние с изменениями манифестов, конвейера и среды выполнения.
- Перед развёртыванием совместимость проверяется на типовых сервисах, а 10 канареечных сервисов должны пройти проверки развёртывания и доли ошибок за 7 дней.
- Дашборд показывает владельцев v1, блокеры и оставшиеся дни; исключения имеют владельца и срок действия.
Зачем это спрашивают: Вопрос проверяет управление жизненным циклом шаблонов и уже созданных сервисов.
Я дал бы типизированную точку расширения с явным владельцем вместо произвольного редактирования сгенерированной инфраструктуры.
- Команды запрашивают ограниченный сетевой профиль через API платформы, с проверками политик и указанным уровнем поддержки.
- Кастомные ресурсы живут в отдельном слое команды, поэтому обновления платформы их не перезаписывают.
- Я ежеквартально пересматривал бы 36 исключений: частые потребности входят в продукт, неактуальные исключения истекают.
Зачем это спрашивают: Вопрос проверяет, ограничена ли автономия понятными правилами безопасности, поддержки и жизненного цикла.
Я поддерживал бы обе версии контракта достаточно долго для безопасной миграции и показывал остаточный риск по владельцам.
- Телеметрия трафика находит каждого клиента, форму запросов и устаревшие поля до объявления срока.
- Адаптер совместимости и сгенерированная инструкция покрывают 60 дней, а для 19 заблокированных команд проводятся консультации.
- Удаление возможно после 14 дней без старых вызовов; временные исключения содержат владельца и конечную дату.
Зачем это спрашивают: Интервьюер оценивает вывод версии по данным, а не управление одним дедлайном.
Сначала я разделил бы неудачные пути по причинам, затем убрал бы самую большую точку трения вместо добавления функций в портал.
- Воронка сравнивает поиск в каталоге, запуск шаблона, первый успешный деплой и повторный деплой по командам и типам нагрузки.
- Я опросил бы 8 использующих и 8 не использующих платформу команд и устранил измеримый блокер, например ожидание согласования 45 минут.
- Изменение становится частью стандартного пути, только если 4-недельный пилот улучшит время до первого развёртывания и повторное использование.
Зачем это спрашивают: Вопрос проверяет управление платформой как измеримым продуктом для инженеров.
Я хранил бы распределенные описания сущностей в Git, централизованно проверяя схему и выполняя инкрементальную загрузку.
- Процессоры каталога валидируют систему, владельца, жизненный цикл и зависимости до слияния изменения.
- Вебхук обновляет измененные локации, а ежедневная полная сверка находит пропущенные события без сканирования при каждом запросе.
- Актуальность, сироты, задержка процессора и сущности без активного владельца становятся SLI платформы по доменам.
Зачем это спрашивают: Сильный ответ охватывает качество данных каталога и сверку, а не только установку портала.
Я изолировал бы зависимости плагинов и убрал медленные интеграции из пути браузерного запроса.
- Плагины обращаются к стабильным серверным API с тайм-аутами, кешем и предохранителями, а не опрашивают 15 систем со страницы.
- Ограничения размера пакета и синтетические тесты блокируют плагин, который поднимает p95 выше 2 секунд на типовых страницах.
- У каждого плагина есть владелец, уровень поддержки, область прав и путь удаления, чтобы ненужные интеграции не становились вечным долгом.
Зачем это спрашивают: Вопрос проверяет изоляцию производительности и жизненный цикл растущей экосистемы портала.
Я моделировал бы создание сервисов как идемпотентный процесс с устойчивым состоянием шагов и компенсирующей очисткой.
- Ключ запроса связывает репозиторий, идентификатор сервиса и окружение, поэтому повтор продолжает процесс, а не создает второй ресурс.
- Каждый шаг сохраняет внешний ID до продолжения, а сверка проверяет состояние Git, каталога, CI и облака.
- Ошибка показывает частичные ресурсы и безопасные действия повтора или очистки, удерживая дубли ниже 0,1%.
Зачем это спрашивают: Вопрос оценивает корректность распределенного процесса между системами без общей транзакции.
Для обычных доверенных нагрузок я использовал бы namespace, а отдельные кластеры давал бы там, где этого требует лимит 15 сервисов или граница безопасности.
- Тенанты namespace получают RBAC, запрет по умолчанию NetworkPolicy, ResourceQuota, контроль допуска Pod Security и отдельную идентификацию нагрузок.
- Регулируемые, привилегированные и шумные нагрузки уходят в отдельные кластеры, потому что namespace не изолирует ядро и контур управления.
- Политика размещения хранит причину, стоимость и критерий выхода, чтобы отдельные кластеры оставались явным уровнем сервиса.
Зачем это спрашивают: Вопрос проверяет, называет ли кандидат реальные границы изоляции и масштаб отказа.
Я сочетал бы границы идентификации, сети, контроля допуска и ресурсов, потому что один механизм Kubernetes не изолирует тенанта.
- RBAC в namespace и идентификация нагрузок запрещают доступ к API и облаку другого тенанта; запрет по умолчанию ограничивает межтенантный трафик.
- ResourceQuota и LimitRange ограничивают суммарные запросы и лимиты, а классы приоритета защищают сервисы платформы от давления тенантов.
- Контроль допуска запрещает доступ к узлу, привилегированные поды и неподтверждённые образы; тесты границ запускаются при каждом выпуске парка.
Зачем это спрашивают: Ответ должен различать изоляцию безопасности и справедливое распределение ресурсов.
Я считал бы кластеры заменяемыми элементами парка, управляемыми через версионированный API кластеров.
- Декларативный канал выпуска фиксирует совместимые версии Kubernetes, CNI, CSI, контроля допуска и наблюдаемости как один проверенный комплект.
- Обновления проходят 2 тестовых и 3 канареечных кластера, затем региональные волны с паузой при регрессии SLO нагрузки или платформы.
- Реестр отслеживает возраст версии, исключения и готовность к замене; кластеры у границы 9 месяцев не получают новых тенантов.
Зачем это спрашивают: Вопрос проверяет управление всем парком, а не запуск отдельных обновлений.
Я внедрял бы Cilium только вместе с проверенной моделью политик и доступной разработчику диагностикой потоков, а не ради eBPF.
- Канареечный кластер проверяет замену kube-proxy, облачную сеть, семантику NetworkPolicy и обновления под реальным трафиком.
- Hubble показывает потоки в рамках тенанта и связан с диагностикой деплоя, чтобы команда нашла запрещенный путь за 20 минут.
- Развёртывание останавливается при регрессии DNS, соединений или отказов политик, а старый тракт обработки трафика сохраняется до стабильности 10 кластеров.
Зачем это спрашивают: Вопрос оценивает внедрение CNI через влияние на разработчиков и безопасность развёртывания.
Я предложил бы сервисную сетку только путям, которым нужны единые mTLS или политики трафика, и доказал бы стоимость относительно бюджета 5 мс.
- Типовой тест измеряет задержку прокси, CPU, пересоздание соединений и поведение при отказе до развёртывания по парку.
- Настройки идентификации, повторов и тайм-аутов централизованно версионируются, а команды отвечают за идемпотентность приложения и бюджет задержки.
- Внедрение начинается с 20 сервисов и растет, только если накладные расходы p95 и частота инцидентов проходят гейты.
Зачем это спрашивают: Сильный ответ не делает сложность сервисной сетки дефолтом без измеримой пользы.
Я открыл бы типизированные ресурсы платформы, а Terraform запускал бы асинхронно за API.
- Запросы проходят проверку политик и владельца, создают неизменяемые записи запусков и возвращают статус вместо удержания HTTP-соединения.
- Состояние разделено по тенантам и доменам ресурсов; с каждым состоянием работает один процесс записи в очереди с короткоживущими облачными учётными данными.
- Сохраняются планы, результаты применения, данные о расхождениях и откате; p95 включает весь путь разработчика вместе с ожиданием в очереди.
Зачем это спрашивают: Вопрос проверяет безопасную оркестрацию Terraform, а не простую обёртку над terraform apply.
Я делил бы состояние по границе владения и жизненного цикла, избегая одного состояния на парк и одного состояния на каждый мелкий ресурс.
- Состояние команды и окружения ограничивает конкуренцию и масштаб отказа, а общие сети и идентификация имеют отдельных владельцев.
- Удалённое состояние использует версионирование, шифрование, блокировку и аудит восстановления; план строится заново после изменения состояния или конфигурации.
- Ожидание блокировки, размер состояния, длительность применения и число владельцев подсказывают разделение до лимита 10 команд.
Зачем это спрашивают: Вопрос проверяет компромиссы конкурентности и восстановления Terraform с заданной границей владения.
Я выбрал бы Crossplane для постоянно сверяемых повторно используемых продуктов, где семантика Kubernetes API соответствует модели владения.
- Композиция открывает небольшой контракт платформы и скрывает ресурсы провайдера, учётные данные и настройки политик от тенанта.
- Емкость контроллеров, ограничение частоты провайдера и задержка сверки проходят нагрузочный тест на 10 минут до широкого внедрения.
- Изменения баз данных с аккуратной одноразовой последовательностью могут остаться в Terraform, чтобы избежать конфликта постоянной сверки.
Зачем это спрашивают: Кандидат должен сопоставить модель управления с жизненным циклом ресурса, а не выбирать любимый инструмент.
До включения сверки я назначил бы один процесс записи для каждого ресурса.
- Инвентарь связывает ID ресурса, адрес состояния, ссылку Crossplane и владельца; неоднозначные ресурсы временно запрещены к изменению.
- Миграция импортирует ограниченную группу, проверяет отсутствие изменений, затем удаляет ее из старого контроллера до запуска Crossplane.
- Контроль допуска отклоняет ресурсы со старой меткой владения, а 14 дней без конфликтующих записей закрывают волну.
Зачем это спрашивают: Вопрос проверяет безопасную передачу ресурсов без двойного владения.
Я поддерживал бы Pulumi только через те же небольшие инфраструктурные контракты, а не как второй неограниченный стек.
- Команды могут писать одобренные компоненты на TypeScript, но идентификация, политики, состояние и аудит остаются у платформы.
- Пилот 3 команд за 8 недель сравнивает обращения, срок изменения и неудачные применения с Terraform.
- Если число операционных путей удваивается без измеримого выигрыша разработчиков, Terraform остается поддерживаемой реализацией.
Зачем это спрашивают: Вопрос оценивает ограниченную вариативность при конкретном лимите поддержки.
Я абстрагировал бы только общий контракт приложения, явно оставляя возможности конкретного провайдера.
- API платформы предлагает классы вычислений, идентификации, наблюдаемости и данных, а политика региона и резидентности встроена в контроль допуска.
- Нагрузки ЕС переключаются только между 2 одобренными регионами; тесты репликации и восстановления доказывают RTO 30 минут.
- Расширения провайдера остаются видимыми точками расширения, чтобы общий знаменатель не скрывал различия надежности.
Зачем это спрашивают: Многооблачность здесь оправдана названными ограничениями резидентности и восстановления, а не общей переносимостью.
Закрытые вопросы
- 21
Спроектируйте GitOps для 50 кластеров и 800 приложений так, чтобы ошибочное изменение достигало не более 2 кластеров.
gitopsdesigncluster - 22
Как постепенно выкатить изменение контроля допуска на 45 кластеров с бюджетом ошибочных отказов 0,5%?
reliabilityclustererror-budget - 23
Как разделить Argo CD для 1 000 приложений в 40 кластерах с изоляцией видимости тенантов?
gitopspartitioningcss - 24
Спроектируйте CI/CD как общий продукт для 2 500 инженеров, 30 000 заданий в день и доступности запуска заданий 99,9%.
designavailabilityci-cd - 25
Выберите изоляцию исполнителей для 150 команд и 20 недоверенных репозиториев при p95 запуска ниже 45 секунд.
- 26
Как рассчитать емкость CI для утреннего всплеска в 10 раз, с 200 до 2 000 заданий в очереди, при p95 ожидания до 3 минут?
capacitydata-structurescapacity-planning - 27
Спроектируйте хранение 25 ТБ артефактов в месяц, срок хранения 90 дней и восстановление быстрее 10 минут.
retentiondesignartifacts - 28
Как внедрить подтверждение происхождения, SBOM и подпись для 800 сервисов, блокируя менее 1% исправных выпусков?
supply-chain - 29
Спроектируйте обратную связь политики как код для 500 разработчиков, чтобы 95% нарушений решались без обращения в поддержку.
feedbackdesign - 30
Где проверять 35 инфраструктурных политик в CI, Terraform и Kubernetes, добавляя менее 30 секунд к обратной связи?
kubernetesterraformfeedback - 31
Как управлять 70 исключениями политик, если каждое может действовать не более 30 дней?
error-handling - 32
Спроектируйте идентификацию нагрузок для 600 сервисов в 25 кластерах с учётными данными сроком не более 1 часа.
designcluster - 33
Как ротировать 4 000 секретов каждые 30 дней, не перезапуская одновременно все 700 нагрузок?
secretsconfiguration - 34
Спроектируйте платформу наблюдаемости для 200 команд и 8 миллионов отсчётов в секунду с изоляцией запросов тенантов.
designobservabilityqueries - 35
Число активных рядов Prometheus должно оставаться ниже 20 миллионов для 500 сервисов; какие платформенные ограничения нужны?
monitoringdesign - 36
Как удержать приём логов ниже 120 ТБ в месяц для 600 сервисов, не скрывая сбои рабочей среды?
- 37
Спроектируйте выборку трассировок для 1 миллиона запросов в секунду, сохраняя 99% трассировок ошибок критических путей.
samplingdesign - 38
Определите SLI платформы для 1 500 разработчиков при цели 99,9% успешных первых деплоев за 15 минут.
deployment - 39
SLO пути деплоя 99,9% израсходовал 60% 30-дневного бюджета ошибок за 5 дней; какую политику выпуска вы примените?
designreliabilityslo - 40
Как учитывать SLO выделения ресурсов 12 минут, если облачные API занимают 8 минут задержки p95?
slolatencyapi - 41
Как сократить медианное время до первого развёртывания с 3 дней до 4 часов для 25 новых команд в квартал?
deployment - 42
Как измерить когнитивную нагрузку для 900 разработчиков, если изменение сервиса требует правки 14 конфигурационных файлов?
config - 43
Платформенная команда из 7 человек обрабатывает 320 обращений в месяц; как сократить ручную работу на 50% за 2 квартала?
reliabilityplatform-engineeringtoil - 44
Что кроме 5 современных метрик DORA, включая долю повторной работы после развёртывания, отслеживать для платформы на 60 команд и 2 000 развёртываний в неделю?
deploymentmonitoringworkloads - 45
Как проверить, повысит ли внедрение нового стандартного пути с 45% до 70% в 40 командах за 90 дней?
golden-pathdecision-making - 46
Спроектируйте отчёт о затратах для 150 команд и облачных затрат $900 000 в месяц, где общие расходы составляют 22% счета.
design - 47
Как повысить эффективность ресурсов на 25% для 500 сервисов, не поднимая задержку p99 выше 200 мс?
latency - 48
Спроектируйте DR для API платформы и контура управления GitOps с RTO 30 минут и RPO 5 минут в 2 регионах.
designdisaster-recoverycontrol-plane - 49
Как сохранить совместимость 350 сервисов во время 6-месячной миграции API платформы и Kubernetes CRD?
kubernetesapimigrations - 50
Какие 3 границы платформы вы стандартизируете первыми для 2 500 инженеров и 1 000 сервисов, если поддержку ведут 8 инженеров?
capacitycapacity-planning - 51
После релиза плагина 32 задержка p95 Backstage выросла с 1,4 до 9 секунд для 1 600 пользователей; что вы сделаете?
latencybackstage - 52
В каталоге устарели владельцы 280 из 12 000 сущностей, а за 7 дней 45 оповещений ушли командам, которые уже расформированы; как восстановиться?
ownershipalerting - 53
После выпуска индексатора 41 поиск Backstage перестал находить 68% из 12 000 сущностей каталога, и за 2 часа 310 разработчиков не смогли найти сервисы и инструкции; как восстановиться?
runbooksbackstageindexes - 54
После изменения схемы очереди v8 потерялись 63 асинхронных уведомления о завершении, и 41 разработчик видел зависшие запросы, хотя ресурсы по всем 41 запросам уже существовали; как восстановиться?
asynccallbacksdata-structures - 55
API платформы вернул 503 для 38% из 900 запросов провизионирования за 22 минуты, но Backstage оставался зеленым; как вести инцидент?
incidentsincident-managementapi - 56
Стандартный путь v4 повысил долю неудачных развёртываний с 1,2% до 17% для 74 из 310 сервисов за 35 минут; какое решение принять?
kubernetes-deploymentdeploymentworkloads - 57
Плагин Backstage показывал метаданные 12 тенантов 3 неавторизованным командам 46 минут; какие данные и меры нужны?
backstage - 58
Версия 9 общего процесса CI сломала сборки в 186 из 740 репозиториев за 28 минут; как восстановить выпуски разработчиков и изменить порядок развёртывания?
- 59
Общий исполнитель исполнял неизвестный код 11 минут и мог читать кеши 85 репозиториев; как его локализовать?
caching - 60
Контрольные суммы не совпали у 37 из 4 200 артефактов в регионе 2, и 9 деплоев их использовали; что делать?
deploymentartifactsreplication - 61
Исполнитель Terraform выбрал неверное рабочее пространство и неверный облачный аккаунт и применил 37 изменений в рабочей среде при обработке 1 запроса из тестовой среды; как локализовать последствия и восстановиться?
terraform - 62
Артефакт состояния или плана Terraform открыл 26 секретов в явном виде 14 инженерам на 52 минуты; как локализовать утечку и не допустить повторения?
terraformartifactssecrets - 63
Terraform провайдер 6.2 предлагает заменить 140 баз, хотя 6.1 не показывал изменений; какое решение по развёртыванию?
terraformdatabase - 64
Частота сверки Crossplane выросла с 80 до 9 000 запросов в минуту и 23 минуты вызывала ответы 429 облачного API; как стабилизировать систему?
iacapi - 65
Crossplane и Terraform меняли теги 96 ресурсов каждые 3 минуты, создав 1 800 событий аудита; как закончить конфликт?
terraformiac - 66
Argo CD показывает 210 приложений OutOfSync, но действующий манифест совпадает с Git у 198; как расследовать без массовой синхронизации?
gitgitops - 67
Изменение ApplicationSet вызвало 4 800 синхронизаций в 40 кластерах за 6 минут и перегрузило 9 серверов API; что делать?
control-planeclusterapi - 68
Ошибочное продвижение достигло 7 из 50 кластеров при лимите 2 и вызвало сбой 61 приложения; как исправить развёртывание?
designcluster - 69
p99 Kubernetes API вырос с 180 мс до 4,8 секунды в 3 общих кластерах, вызвав 32% ошибок запросов платформы; что проверять?
kubernetesclusterapi - 70
После изменения парка сбои DNS выросли с 0,02% до 8% для 420 сервисов, но 6 канареечных кластеров были здоровы; как реагировать?
dnsdeployment-strategiescluster - 71
Cilium IPAM исчерпал пулы адресов в 8 кластерах, из-за чего 620 подов разработчиков не планировались 27 минут; как восстановить путь развёртывания?
workloadsclusterdeployment - 72
Вебхук преобразования CRD завершается по тайм-ауту для 14% из 60 000 объектов во время перехода API; как избежать потери данных?
webhooksmigrations - 73
Обновление Kubernetes 1.35 подняло p95 запуска подов с 22 до 95 секунд в 4 из 30 кластеров; какое решение по развёртыванию?
workloadskubernetescluster - 74
Один тенант потребил 62% фактического CPU и поднял p99 выше 1 секунды у 47 сервисов в кластере на 90 тенантов; как его ограничить?
cluster - 75
Сертификаты 130 сервисов истекают за 9 часов, потому что ротация остановилась 2 дня назад; что делать?
- 76
Развёртывание NetworkPolicy заблокировало платежи от 23 сервисов на 11 минут, а Hubble показал 48 000 запрещённых соединений; как восстановиться?
network-policy - 77
Отказ 1 зоны сделал недоступными 36 сервисов платформы и заблокировал 240 развёртываний разработчиков, хотя у каждого сервиса было по 3 реплики; как исправить настройки топологии?
kubernetes-deploymentreplicationdeployment - 78
HPA увеличил 70 нагрузок с 2 до 10 реплик, но 430 подов оставались Pending 16 минут из-за непригодной для планирования ёмкости кластеров; как восстановить ёмкость парка?
capacityclusterreplication - 79
Политика повторов сервисной сетки утроила трафик до 1,8 миллиона запросов в секунду и подняла ошибки с 2% до 31%; что делать?
resilience - 80
Сбои mTLS достигли 12% для 260 сервисов после комплекта доверия v17, но 18 сервисов нельзя откатить; как восстановиться?
mtlsrollback - 81
Секрет, которым пользовались 74 нагрузки, попал в журналы CI на 26 минут и был просмотрен 19 раз; как реагировать?
secretsconfiguration - 82
Аудит нашел 3 800 Kubernetes Secrets, которые хранятся только как base64 в 25 кластерах; какую миграцию провести за 60 дней?
configurationkubernetescluster - 83
Поддельная подпись образа прошла в 6 рабочих кластеров, и образ выполнялся 17 минут в 14 подах; как локализовать инцидент цепочки поставки?
incidentsincident-managementcluster - 84
Коллекторы OpenTelemetry потеряли 28% спанов 95 сервисов во время 40-минутного всплеска; как вернуть достоверную телеметрию?
observability - 85
Шлюз remote write подтвердил приём 2,4 миллиарда отсчётов, но потерял 18% данных 46 тенантов во время 32-минутного отказа хранилища метрик; как вернуть доверие?
gatewaymonitoring - 86
Стоимость логов выросла с $180 000 до $510 000 за 1 месяц, а 67% новых данных ни разу не запрашивались; что изменить?
queries - 87
Глобальный SLO платформы остаётся зелёным, хотя за 6 часов неудачей завершились 38% первых развёртываний у 42 команд из ЕС; как изменить решение по инциденту и измерения?
incidentsincident-managementdeployment - 88
Облачный API идентификации вызвал 72% из 1 100 ошибок провизионирования за 31 минуту; как безопасно атрибутировать и смягчить зависимость?
dependenciesapi - 89
Перевод пулов CI и предпросмотров разработчиков на 80% прерываемых мощностей сэкономил $210 000 за 1 месяц, но прерывания отменили 1 900 заданий и 340 предпросмотров; что изменить?
capacitycapacity-planning - 90
Команда оспаривает $84 000 из отчёта о затратах $310 000 в месяц, потому что 27% составляет общая платформа наблюдаемости; как решить спор?
observability - 91
Региональный отказ длится 47 минут, превышая RTO платформы 30 минут, и 180 деплоев ждут; как восстановиться?
disaster-recoveryworkloadsdeployment - 92
Восстановление укладывается в RPO 5 минут, но теряет 37 статусов процессов и показывает 12 дублирующихся облачных аккаунтов; что менять?
disaster-recovery - 93
В TechDocs инструкция по восстановлению базы отставала от рабочей версии на 4 выпуска, из-за чего 26 команд провалили 41 самостоятельную проверку за 6 дней; как не допустить повторения?
runbooksdocumentationdatabase - 94
Правило 12 платформенной оценочной карты ошибочно признало соответствующими 73 сервиса с нарушениями и заблокировало выпуски 28 исправных сервисов за 3 часа; как исправить решения?
- 95
Откат 22 сервисов не удался: политика хранения удаляла рабочие образы через 30 дней, хотя записи о выпусках хранились 90 дней; как восстановиться?
rollbackartifactsretention - 96
Почему 37 просроченных исключений из политик остаются активными после кеширования старого пакета OPA на 19 часов агентами в 16 кластерах и как локализовать риск платформы?
policycachingcluster - 97
Переход на SDK платформы v3 ломает 6% из 420 сервисов из-за недокументированного тайм-аута; как вернуть совместимость?
migrationsresilience - 98
Подопечный подготовил плагин Backstage, который позволяет 1 обычному пользователю изменять все 600 сущностей каталога; как проверить решение и за 4 недели доказать авторизацию на уровне ресурса?
authbackstage - 99
Опытный коллега перечислил 12 действий без подтверждающих данных после 43-минутного сбоя CI, затронувшего 2 300 заданий; как помочь ему улучшить разбор?
mentoringincidentsincident-management - 100
Изменение стандартного пути подопечного сократило настройку с 6 часов до 50 минут, но повысило долю неудачных первых развёртываний с 3% до 11%; как направить решение?
deployment