Вопросы на собеседовании: Платформенный инженер

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

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

Хороший платформенный API выражает намерение разработчика, возвращает наблюдаемый статус и скрывает детали провайдера, не скрывая важных ограничений.

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

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

• Для модуля создания базы данных я могу отслеживать долю успешных запусков через самообслуживание, медианное время получения базы и число обращений в поддержку на 20 созданных баз.
• Перед изменением контракта я поговорю с двумя или тремя командами-потребителями и опубликую короткий план сохранения совместимости.
• Запросы за границами возможности становятся основанием для точки расширения или явного отказа от функции, а не поводом автоматически расширять объём работ.

Я использую Component для развёртываемых сервисов, API и Resource для их контрактов и зависимостей, а затем связываю их с System, Domain, Group и User.

• Владельцем сущности должна быть реальная Group с маршрутом дежурства или поддержки, а не произвольное имя команды.
• Связи providesApi, consumesApi, dependsOn и partOf позволяют оценивать влияние без копирования списков зависимостей в описание.
• Я делаю lifecycle и границы систем достаточно простыми, чтобы владельцы сервисов поддерживали их обычными запросами на слияние.

Locations указывают источники метаданных, processors преобразуют или проверяют сущности, а annotations добавляют ссылки для конкретных интеграций.

• Я храню catalog-info.yaml рядом с сервисом, чтобы изменения метаданных проходили ту же проверку, что и код.
• Аннотация GitHub связывает плагины с репозиторием, а аннотации TechDocs и Kubernetes подключают документацию и представление работающей нагрузки.
• Собственные processors должны приводить к единому виду только устойчивые соглашения компании и явно сообщать об отклонённых сущностях, а не молча исправлять неверные метаданные.

Я делаю шаблон тонким слоем оркестрации, который собирает намерение, вызывает протестированные actions и оставляет созданный сервис в проверяемом состоянии.

• Параметры запрашивают владельца, систему, среду выполнения, класс данных и размер, а имена репозитория и пространства имён формируются единообразно.
• Actions могут создать репозиторий, отрендерить каркас, зарегистрировать сущность каталога и открыть запрос на слияние с GitOps-конфигурацией и явными выходными данными каждого шага.
• Итоговая страница даёт ссылки на репозиторий, запрос развёртывания, документацию и инструкцию по откату или очистке при сбое позднего шага.

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

• Клиентский плагин не должен получать облачные учетные данные; серверный плагин выполняет авторизованные вызовы и возвращает только нужные данные.
• Правила доступа используют владение в каталоге и членство в группах, чтобы пользователь не мог управлять ресурсом другой команды заменой URL.
• Я определяю состояния загрузки, отсутствия данных, запрета и отказа зависимости, потому что внутренние API доступны не всегда.

Я храню документацию в репозитории владельца, собираю её в CI и показываю свежесть и владельца в каталоге.

• Шаблон сервиса создаёт минимальную структуру MkDocs с локальным запуском, деплоем, зависимостями и контактом поддержки.
• Публикация из CI не требует выдавать Backstage широкие права на репозитории и создаёт тот же артефакт, который разработчики проверяют локально.
• Карточка оценки может отмечать отсутствующие или устаревшие инструкции эксплуатации, но содержимое определяет команда-владелец и проверяет его вместе с кодом.

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

• Проверка готовности к production может подтверждать владельца, ссылку на SLO, requests ресурсов и одобренный процесс развёртывания по достоверным источникам.
• Проверки должны отличать неизвестный результат от провала, чтобы сбой интеграции не сделал все сервисы несоответствующими.
• Сначала я показываю карточка оценки командам без публичного рейтинга и измеряю исправления, прежде чем рассматривать блокировку релиза.

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

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

Я версионирую каждый потребляемый контракт и отделяю версию создания шаблона от версий поддерживаемых модулей и процессов.

• Новые репозитории фиксируют выпущенный набор шаблона, например 2.3, а переиспользуемые процессы и Terraform-модули ссылаются на явную основную или дополнительную версию.
• Журнал изменений отмечает обязательные миграции, а тесты совместимости рендерят характерные фикстуры сервисов на предлагаемой версии.
• Предыдущая основная версия поддерживается заявленный срок, а потребители обновляются автоматическими запросами на слияние, не скрытым изменением.

Я считаю сгенерированные интерфейсы, входные параметры процессов, метки, пути файлов и выходные параметры модулей контрактами, даже если они не оформлены как API.

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

Я делаю поддерживаемый путь проще собственной инфраструктуры, но оставляю явную точку расширения для требований, которые путь не может безопасно выразить.

• Команда может передать ограниченный overlay или выбрать одобренный расширенный модуль, не создавая ответвление всего шаблона.
• Исключение фиксирует владельца, причину, риск и дату пересмотра, чтобы временное отклонение не стало невидимой постоянной платформой.
• Я ежеквартально просматриваю повторяющиеся исключения; три похожих запроса обычно означают недостающую возможность платформы, а не сопротивление пользователей.

Подключение должно установить идентичность, владение, доставку, границы среды выполнения и показатели поддержки до первого развёртывания в production.

• Процесс создаёт репозиторий и сущность каталога с группой-владельцем, системой, lifecycle и маршрутом связи.
• Он создаёт пространство имён или границу аккаунта, идентичность рабочей нагрузки с минимальными правами, конфигурацию развёртывания и наблюдаемый статус.
• Для завершения нужны успешное тестовое развёртывание, ссылки на панель и SLO, а также описанный путь удаления заброшенного сервиса.

Я делаю передачу владения и вывод из эксплуатации отдельными процессами каталога с одобрением текущего и принимающего владельцев.

• Передача обновляет связь Group в каталоге, права репозитория, предупреждения, cost метки и привязки идентичность рабочей нагрузки одним проверяемым набором изменений.
• Статус вывода блокирует новые релизы в production до удаления ресурсов и перечисляет зависимости, которые должны подтвердить отключение.
• Окончательная очистка проверяет нулевой трафик, сохраняет требуемые аудит-данные и удаляет записи каталога и инфраструктуры без бесхозных затрат.

Я использую пространства имён как основную административную границу и дополняю их RBAC, квотами, сетевыми политиками и admission controls.

• Каждая команда получает отдельные пространства имён для production и непродуктивных окружений со стабильными метками владельца, стоимости, политик и наблюдаемости.
• Namespace сам по себе не является жесткой границей безопасности, поэтому для недоверенных нагрузок могут понадобиться отдельные кластеры или аккаунты.
• Возможность подключения создаёт весь набор политик одинаково, вместо того чтобы каждая команда собирала его вручную.

Я выдаю группам права в соответствии с ролью в каждом пространстве имён, а каждой нагрузке даю отдельный ServiceAccount с более узкими правами во время выполнения.

• Разработчики могут читать нагрузки и журналы в production, но развёртывают через GitOps, а дежурная группа получает ограниченный по времени диагностический доступ.
• RoleBindings ссылаются на централизованно управляемые Roles, чтобы общие права один раз проходили проверку и переиспользовались одинаково.
• Я тестирую разрешённые и запрещённые действия через authorization checks, потому что широкие права с wildcard для verbs и resources легко пропустить на проверку.

ResourceQuota ограничивает суммарное потребление пространства имён, а LimitRange задаёт значения по умолчанию или границы requests и limits отдельных объектов.

• Квота может разрешать команде суммарно 20 CPU и 40 ГиБ памяти, не давая одному пространству имён занять кластер.
• LimitRange может задавать каждому контейнеру 100 millicores и 256 МиБ, чтобы отсутствие request не ломало планирование и учёт затрат.
• Я настраиваю их вместе и показываю текущее использование в портале, потому что невидимая нехватка квоты приводит к непонятным отказам развёртывания.

Я начинаю с запрета входящего и исходящего трафика по умолчанию, затем явно разрешаю DNS, входной трафик, нужные зависимости и точки подключения наблюдаемости.

• Selectors используют стабильные метки пространства имён и нагрузки, управляемые платформой, а не имена Pod или изменяемые метки релиза.
• Правила исходящего трафика учитывают DNS и внешние точки подключения, иначе безопасная на вид политика ломает обнаружение сервисов или проверку сертификатов.
• Шаблон включает тесты связности, чтобы команда до production видела, какой контракт заблокирован.

Pod Security Admission применяет общие профили безопасности нагрузок, а admission policy отвечает за требования и исключения конкретной организации.

• Я помечаю пространства имён приложений профилем restricted и перед включением enforce использую режим warn или audit.
• Правило Gatekeeper или Kyverno может требовать одобренный registry, requests ресурсов или метки идентичности рабочей нагрузки, которых нет в Pod Security.
• Исключения ограничиваются пространством имён, имеют владельца и срок действия, а не становятся глобальным обходом для одной несовместимой нагрузки.