У комплекса из 6 продуктов есть 2400 страниц на 11 сайтах разных команд, и пользователи не понимают, к какому продукту относится задача; спроектируйте информационную архитектуру для консолидации за 9 месяцев.

Я бы организовал комплекс вокруг общих пользовательских задач, сохранив контекст продукта в структурированных метаданных. - Инвентаризация фиксирует владельца, аудиторию, задачу, продукт, состояние жизненного цикла, трафик и группу дублей для всех 2400 страниц. - Целевая карта использует страницы задач, фильтры по продуктам и одну каноническую страницу, если процессы в продуктах совпадают. - Запись решения по информационной архитектуре определяет правила URL, хлебных крошек, навигации и межпродуктовых ссылок до начала миграции. - Я проверяю модель на 200 самых посещаемых страницах и требую 80% успешного поиска задач до планирования остальных волн.

Определите контентную модель для 1800 страниц о 4 облачных продуктах, 3 персонах и 6 локалях, если записи Contentful должны за 12 месяцев начать обслуживать веб и встроенную справку.

Я бы отделил устойчивую семантику контента от обоих каналов доставки. - Основные типы включают концепцию, задачу, справку, устранение неполадок, примечание к релизу и переиспользуемое уведомление с обязательными полями аудитории, продукта, версии и локали. - Связи соединяют предварительные условия, следующие шаги, объекты API и варианты продукта без копирования целых страниц в записи Contentful. - Реестр схем называет владельцев полей, правила валидации, допустимые значения и порядок обратно совместимых изменений для веба и встроенной справки. - Я проверяю модель на 120 репрезентативных страницах и отклоняю её, если более 10% требуют неструктурированных обходных полей.

Портал для разработчиков на 3200 страниц использует 700 несогласованных ярлыков от 8 команд; спроектируйте таксономию, которая за 2 квартала должна повысить долю успешных поисковых сессий с 58% до 75%.

Я бы заменил локальные ярлыки управляемой фасетной таксономией на основе языка пользователей и поисковых данных. - Логи запросов, термины поддержки и карточная сортировка определяют контролируемые значения для продукта, задачи, языка, фреймворка, версии API и уровня опыта. - Карта синонимов обрабатывает старые и разговорные термины, а в навигации, метаданных и результатах поиска показывается один предпочтительный ярлык. - Владельцы таксономии рассматривают новые термины через заявку с определением, областью действия, псевдонимами и списком затронутых страниц. - Сначала я размечаю 1000 главных страниц и сравниваю нулевые результаты, использование фильтров и успешные сессии с базовыми 58%.

Двенадцать команд разработки владеют 2600 страницами, но у центральной команды из 4 технических писателей SLA ревью составляет 5 дней; спроектируйте федеративную модель владения без узкого места в лице писателей.

Я бы закрепил ответственность за продуктовыми командами, а центральное ревью оставил для общего и высокорискового контента. - CODEOWNERS связывает каталоги с владельцем от разработки и куратором документации, при этом ни одна страница не может остаться без владельца. - Матрица рисков направляет материалы об аутентификации, оплате, безопасности и нескольких продуктах к писателям, а обычные релизные обновления проходят автоматические проверки и ревью коллег. - Каждая команда получает отчёты о свежести, битых ссылках и просроченных ревью своих страниц вместо общей очереди на уборку. - Регламент устанавливает центральный SLA в 5 дней, срок ответа команды в 2 дня и квартальный аудит владельцев всех 2600 страниц.

Перестройте 1500 страниц о 5 продуктах по модели Diátaxis за 6 месяцев, пока 9 команд продолжают выпускать обновления каждую неделю; какие архитектурные и переходные артефакты вы определите?

Я бы использовал Diátaxis как модель намерений, а не как четыре изолированные папки. - Рубрика классификации различает учебные материалы, практические руководства, справку и объяснения по намерению пользователя, исходному состоянию и результату. - Таблица соответствия назначает каждой странице действие: оставить, разделить, объединить, переписать или удалить, а также целевой тип и владельца. - Навигация поддерживает переходы между типами, например от обучения к задаче и справке, не требуя от пользователя знания модели. - Пилот на 150 страницах должен показать согласованность классификации выше 85% и успешное выполнение задач до начала шести ежемесячных волн.

Поиск по 4800 страницам о 8 продуктах в 7 локалях выдаёт неправильную версию в 18% сессий; спроектируйте индекс, метаданные и управление релевантностью для SLA поиска 99,9%.

Я бы сделал продукт, версию, локаль и состояние жизненного цикла основными сигналами поиска. - Индекс хранит канонический ID, продукт, локаль, диапазон версий, тип контента, свежесть, права и URL замены для каждого документа. - Маршрутизация запросов повышает вес текущего продукта и локали, исключает снятые страницы и показывает фильтры версий вместо скрытого угадывания. - Тесты релевантности охватывают 200 важных запросов с ожидаемыми результатами в первой тройке и выполняются перед каждым изменением конфигурации. - Панели отслеживают задержку, долю нулевых результатов, клики по неверной версии и свежесть индекса относительно SLA 99,9% по локалям.

Спланируйте перенос 3500 страниц Confluence из 14 пространств в единый портал разработчиков за 10 месяцев и $180 000 с сохранением 12 000 входящих ссылок.

Я бы переносил проверенные группы контента, а не копировал все 14 пространств в новую оболочку. - Инвентаризация фиксирует владельца, трафик, дату проверки, вложения, ограничения доступа, группы дублей и входящие ссылки для всех 3500 страниц. - Реестр решений назначает действия: оставить, объединить, переписать, архивировать или удалить, а для удаления посещаемых страниц требует одобрения владельца продукта. - Автоматические конвертеры обрабатывают стандартные страницы, а бюджет резервирует ручную работу с макросами, диаграммами, закрытым контентом и 12 000 перенаправлений. - Десять ежемесячных волн проходят проверки ссылок, отображения, прав и владельцев до перевода каждого исходного пространства в режим чтения.

Административный продукт с 900 страницами обслуживает операторов, аудиторов и разработчиков из 5 команд; спроектируйте навигацию для 30 регулярных задач без дублирования страниц по ролям.

Я бы построил единую архитектуру задач с ролевыми точками входа и условными деталями только там, где права меняют процедуру. - Матрица задач и ролей определяет 30 процессов, общие шаги, различия прав и необходимые доказательства для каждой персоны. - Глобальная навигация следует задачам продукта, а ролевые стартовые страницы подбирают нужные задачи без создания альтернативных канонических копий. - Общие процедуры используют переиспользуемые шаги и явные ролевые условия вместо почти одинаковых страниц для оператора и аудитора. - Древовидные тесты с 15 участниками каждой роли должны дать не менее 80% успешных первых кликов до выпуска структуры из 900 страниц.

Спроектируйте метаданные жизненного цикла для 2200 страниц о 7 продуктах, где у 22% нет владельца, а регуляторные страницы требуют ежегодной проверки и исправления за 30 дней.

Я бы сделал владельца и состояние проверки обязательными данными публикации, а не необязательными ярлыками. - Обязательные поля включают ответственную команду, эксперта, продукт, версию, интервал ревью, дату последней проверки, класс риска и страницу-преемника. - Регуляторный контент получает интервал 365 дней, предупреждения за 60 дней и автоматическую эскалацию при открытии 30-дневного срока исправления. - Страницы без владельца попадают в 45-дневную очередь назначения и не получают функциональных обновлений, пока директор продукта не примет ответственность. - Панель жизненного цикла еженедельно выгружает в Jira страницы без владельца, просроченные, истекающие и снятые страницы по продуктам.

После поглощения объедините портал на 1100 страниц и портал на 1700 страниц с пересекающимися продуктами в 4 локалях за 8 месяцев; определите план канонизации и миграции.

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

Спроектируйте платформу Docusaurus для 2800 страниц, 10 продуктов, 6 локалей и 14 команд авторов с GitHub Actions, где обратная связь по pull request должна приходить менее чем за 10 минут.

Я бы отделил общий код платформы от продуктового контента и дал всем один предсказуемый процесс внесения изменений. - Версионированные пакеты контента содержат документацию продуктов, а общий пакет темы управляет навигацией, поисковыми метаданными, доступностью и локалями. - GitHub Actions проверяет изменённые файлы, стиль, ссылки, схемы и затронутые сборки в pull request, а после слияния запускает полную матрицу. - Кэши зависимостей и контента учитывают lock-файл, локаль, продукт и версию генератора, чтобы несвязанные изменения не сбрасывали все 2800 страниц. - SLO платформы задают p95 обратной связи по превью менее 10 минут, доступность production 99,9% и владельцев каждого показателя.

Спроектируйте систему Sphinx для 1600 страниц о Python-библиотеках в 12 пакетах и 3 поддерживаемых версиях, где справка API генерируется ночью, а релизы публикуются за 20 минут.

Я бы собирал каждый пакет независимо и объединял версионированные результаты через общую конфигурацию Sphinx. - Проекты пакетов владеют исходниками RST или MyST и входами autodoc, а единый пакет расширений управляет темой, перенаправлениями, предупреждениями и выбором версии. - Ночная генерация справки сравнивает публичные символы с прошлым артефактом и открывает задачу на ревью добавлений, удалений и изменений сигнатур. - Релизные процессы собирают только изменённые пакеты, затем объединяют и проверяют полный манифест версий перед публикацией. - Бюджет в 20 минут делится между подготовкой окружения, сборкой пакетов, проверкой ссылок и развёртыванием, а замеры хранятся 90 дней.

Выберите модель monorepo или multirepo для 3000 страниц, которыми владеют 18 команд разработки и платформенная группа из 5 писателей, при 40 продуктовых релизах в неделю.

Я бы оставил связанный с релизами контент в репозиториях продуктов, а общий пользовательский опыт и артефакты управления вынес в центральный репозиторий. - Изменения API, примеры и примечания к релизам остаются рядом с кодом, чтобы 40 еженедельных релизов атомарно обновляли реализацию и документацию. - Общие учебные материалы, навигация, тема, правила Vale и контентные схемы живут централизованно и поставляются продуктовым репозиториям как версионированные пакеты. - Федеративный манифест предоставляет единому порталу канонические URL, владельцев, локали и входы сборки без копирования исходников. - Запись архитектурного решения сравнивает доступ авторов, атомарность изменений, обновление зависимостей, обнаружение и стоимость восстановления до внедрения.

Спроектируйте превью pull request для портала на 2100 страниц в 6 локалях, где 120 авторам нужны закрытые ссылки за 8 минут, а превью удаляются через 14 дней.

Я бы создавал изолированные превью с контролем доступа из точного коммита pull request. - Затронутые продукты и локали определяются по графу зависимостей, а изменение общей темы запускает полную матрицу портала. - Каждое превью получает неизменяемый URL, вход через корпоративного провайдера идентификации и видимый баннер с коммитом, веткой и сроком удаления. - Проверки GitHub публикуют статус сборки, ссылки на изменённые страницы, артефакты визуального сравнения и закрытый URL превью за 8 минут. - Плановая задача через 14 дней удаляет хранилище и записи развёртывания и сверяет потерянные ресурсы с месячным бюджетом.

Определите архитектуру развёртывания портала на 4500 страниц о 9 продуктах в 7 локалях, с SLA доступности 99,95% и целью отката за 15 минут.

Я бы публиковал неизменяемые артефакты сайта через атомарное переключение трафика. - CI создаёт подписанный манифест с коммитом, версией генератора, пакетами локалей, контрольными суммами, перенаправлениями и версией поискового индекса. - Staging проверяет маршруты, ссылки, доступность, заголовки и 100 критичных путей на точном production-артефакте. - Развёртывание загружает новую версию в отдельный origin и меняет указатель CDN только после успешных проверок во всех локалях. - Два предыдущих артефакта и индекса сохраняются готовыми к развёртыванию, поэтому откат укладывается в 15 минут без пересборки.

Определите проверки качества GitHub Actions для 2700 страниц от 16 команд, с бюджетом pull request в 12 минут и менее 1% ложных блокировок в месяц.

Я бы разделил проверки по риску и сначала запускал самые дешёвые детерминированные барьеры. - Каждое изменение получает проверки схемы, Markdown, Vale, внутренних ссылок, секретов и владельцев только для затронутых файлов. - Примеры кода, внешние ссылки, доступность и полные сборки локалей запускаются при изменении их зависимостей или по расписанию. - У блокирующего правила должны быть владелец, обоснование, тестовые фикстуры, измеряемая доля ложных блокировок и временное исключение со сроком. - Панель отслеживает p50 и p95 длительности, время в очереди, сбои по правилам, исключения и ложные блокировки относительно целей 12 минут и 1%.

Спроектируйте права репозитория для 1900 страниц от 13 команд, включая документацию по безопасности и оплате с двумя обязательными одобрениями и доступ подрядчиков на 90 дней.

Я бы обеспечил минимально необходимые права через пути репозитория, группы идентификации и проверки политики слияния. - CODEOWNERS направляет запросы продуктовым владельцам для обычных путей, но сам по себе не может обеспечить два отдельных одобрения; для путей безопасности и оплаты обязательная проверка политики через GitHub App или бота подтверждает одно одобрение не от автора со стороны доменной команды и одно со стороны команды документации. - Защита ветки запрещает прямую отправку и требует проверку политики одобрений и проверку CI, которая подтверждает подписи и происхождение релизных артефактов до слияния; сама защита ветки подписи не проверяет. - Подрядчики входят в ограниченные группы с автоматическим истечением через 90 дней и не получают закрытые исходники или production-ключи развёртывания. - Квартальный аудит сравнивает права в репозитории, CI, хостинге и хранилище секретов и фиксирует исключения с владельцами и датами окончания.

Планируемая платформа должна собирать 5000 страниц в 8 локалях менее чем за 15 минут при фиксированном месячном бюджете CI $6000; спроектируйте производительность сборки до миграции.

Я бы создал модель сборки по зависимостям и измеримый бюджет производительности до импорта всего контента. - Эталонный корпус представляет размеры страниц, диаграммы, генерируемую справку, глубину навигации и все 8 локалей на объёмах 500, 2500 и 5000 страниц. - Зависимости контента, темы, схем API и локалей определяют затронутые сборки вместо полного пересоздания каждого результата. - Воспроизводимые кэши покрывают зависимости, разобранный контент, артефакты API, изображения и сегменты поиска с явными ключами сброса. - Нагрузочные тесты должны удержать p95 полной сборки ниже 15 минут и прогноз вычислений ниже $6000 до одобрения миграции.

Определите наблюдаемость платформы на 3600 страниц для 6 продуктов и 5 локалей, где SLA публикации и свежести поиска 99,9% отчитываются перед 15 командами.

Я бы отслеживал каждый исходный коммит через сборку, развёртывание, индекс и пользовательскую проверку. - Запись развёртывания связывает коммит, запуск процесса, манифест артефакта, число маршрутов, локаль, версию CDN и поколение поискового индекса. - Метрики охватывают время очереди, длительность сборки, этап сбоя, возраст развёртывания, доступность маршрутов, отставание индекса и успех превью по продуктам. - Синтетические проверки каждые 5 минут проверяют 60 критичных страниц, переключатели локалей и версий и результаты поиска. - Командные панели и месячные отчёты SLO показывают владельцев, расход бюджета ошибок и нерешённые дефекты платформы без пользовательских данных.

Выберите Docusaurus или Sphinx для портала на 2300 страниц с руководствами React, справкой Python SDK и 6 локалями при бюджете миграции $120 000 и сроке 7 месяцев.

Я бы провёл взвешенный прототип, потому что ни один генератор не превосходит другой во всём смешанном корпусе. - Карта оценки учитывает извлечение Python API, поддержку React-компонентов, локализацию, версии, интеграцию поиска, доступность, навыки авторов и стоимость сопровождения. - Каждый инструмент собирает один срез из 120 страниц с авторскими руководствами, генерируемой справкой SDK, диаграммами, перенаправлениями и двумя локалями. - Прототип измеряет время сборки, труд авторов, разработку расширений, качество результата, поверхность обновлений и стоимость владения за 5 лет. - Запись решения выбирает лучший подтверждённый результат и удерживает миграцию в пределах $120 000 и 7 месяцев.

Вопросы на собеседовании: Технический писатель

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Старший технический писатель.

Смотреть пример резюме: Технический писатель →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

designinformation-architecture

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

Инвентаризация фиксирует владельца, аудиторию, задачу, продукт, состояние жизненного цикла, трафик и группу дублей для всех 2400 страниц.
Целевая карта использует страницы задач, фильтры по продуктам и одну каноническую страницу, если процессы в продуктах совпадают.
Запись решения по информационной архитектуре определяет правила URL, хлебных крошек, навигации и межпродуктовых ссылок до начала миграции.
Я проверяю модель на 200 самых посещаемых страницах и требую 80% успешного поиска задач до планирования остальных волн.

Зачем это спрашивают: Интервьюер оценивает, умеет ли кандидат превратить разрозненный комплекс продуктов в проверяемую информационную архитектуру на основе метаданных.

discoverycontent-modelingcontentful

Я бы отделил устойчивую семантику контента от обоих каналов доставки.

Основные типы включают концепцию, задачу, справку, устранение неполадок, примечание к релизу и переиспользуемое уведомление с обязательными полями аудитории, продукта, версии и локали.
Связи соединяют предварительные условия, следующие шаги, объекты API и варианты продукта без копирования целых страниц в записи Contentful.
Реестр схем называет владельцев полей, правила валидации, допустимые значения и порядок обратно совместимых изменений для веба и встроенной справки.
Я проверяю модель на 120 репрезентативных страницах и отклоняю её, если более 10% требуют неструктурированных обходных полей.

Зачем это спрашивают: Интервьюер проверяет проектирование контентной модели для нескольких продуктов, персон, локалей и каналов публикации.

content-taxonomydesignsessions

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

Логи запросов, термины поддержки и карточная сортировка определяют контролируемые значения для продукта, задачи, языка, фреймворка, версии API и уровня опыта.
Карта синонимов обрабатывает старые и разговорные термины, а в навигации, метаданных и результатах поиска показывается один предпочтительный ярлык.
Владельцы таксономии рассматривают новые термины через заявку с определением, областью действия, псевдонимами и списком затронутых страниц.
Сначала я размечаю 1000 главных страниц и сравниваю нулевые результаты, использование фильтров и успешные сессии с базовыми 58%.

Зачем это спрашивают: Интервьюер оценивает таксономию как управляемую систему поиска, привязанную к измеримому результату.

trackingdesignownership

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

CODEOWNERS связывает каталоги с владельцем от разработки и куратором документации, при этом ни одна страница не может остаться без владельца.
Матрица рисков направляет материалы об аутентификации, оплате, безопасности и нескольких продуктах к писателям, а обычные релизные обновления проходят автоматические проверки и ревью коллег.
Каждая команда получает отчёты о свежести, битых ссылках и просроченных ревью своих страниц вместо общей очереди на уборку.
Регламент устанавливает центральный SLA в 5 дней, срок ответа команды в 2 дня и квартальный аудит владельцев всех 2600 страниц.

Зачем это спрашивают: Интервьюер проверяет, распределяет ли управление ответственность и защищает ли дефицитную экспертную пропускную способность.

diataxisarchitectureartifacts

Я бы использовал Diátaxis как модель намерений, а не как четыре изолированные папки.

Рубрика классификации различает учебные материалы, практические руководства, справку и объяснения по намерению пользователя, исходному состоянию и результату.
Таблица соответствия назначает каждой странице действие: оставить, разделить, объединить, переписать или удалить, а также целевой тип и владельца.
Навигация поддерживает переходы между типами, например от обучения к задаче и справке, не требуя от пользователя знания модели.
Пилот на 150 страницах должен показать согласованность классификации выше 85% и успешное выполнение задач до начала шести ежемесячных волн.

Зачем это спрашивают: Интервьюер оценивает практическое внедрение Diátaxis через правила классификации, пользовательские пути и данные миграции.

indexesdesignsessions

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

Индекс хранит канонический ID, продукт, локаль, диапазон версий, тип контента, свежесть, права и URL замены для каждого документа.
Маршрутизация запросов повышает вес текущего продукта и локали, исключает снятые страницы и показывает фильтры версий вместо скрытого угадывания.
Тесты релевантности охватывают 200 важных запросов с ожидаемыми результатами в первой тройке и выполняются перед каждым изменением конфигурации.
Панели отслеживают задержку, долю нулевых результатов, клики по неверной версии и свежесть индекса относительно SLA 99,9% по локалям.

Зачем это спрашивают: Интервьюер проверяет архитектуру поиска, тестирование релевантности и эксплуатационный контроль крупного версионированного корпуса.

migrations

Я бы переносил проверенные группы контента, а не копировал все 14 пространств в новую оболочку.

Инвентаризация фиксирует владельца, трафик, дату проверки, вложения, ограничения доступа, группы дублей и входящие ссылки для всех 3500 страниц.
Реестр решений назначает действия: оставить, объединить, переписать, архивировать или удалить, а для удаления посещаемых страниц требует одобрения владельца продукта.
Автоматические конвертеры обрабатывают стандартные страницы, а бюджет резервирует ручную работу с макросами, диаграммами, закрытым контентом и 12 000 перенаправлений.
Десять ежемесячных волн проходят проверки ссылок, отображения, прав и владельцев до перевода каждого исходного пространства в режим чтения.

Зачем это спрашивают: Интервьюер оценивает планирование миграции через решения по контенту, границы автоматизации, перенаправления, бюджет и критерии приёмки.

design

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

Матрица задач и ролей определяет 30 процессов, общие шаги, различия прав и необходимые доказательства для каждой персоны.
Глобальная навигация следует задачам продукта, а ролевые стартовые страницы подбирают нужные задачи без создания альтернативных канонических копий.
Общие процедуры используют переиспользуемые шаги и явные ролевые условия вместо почти одинаковых страниц для оператора и аудитора.
Древовидные тесты с 15 участниками каждой роли должны дать не менее 80% успешных первых кликов до выпуска структуры из 900 страниц.

Зачем это спрашивают: Интервьюер проверяет, может ли ролевой поиск сочетаться с каноническим и переиспользуемым контентом.

content-lifecycledesign

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

Обязательные поля включают ответственную команду, эксперта, продукт, версию, интервал ревью, дату последней проверки, класс риска и страницу-преемника.
Регуляторный контент получает интервал 365 дней, предупреждения за 60 дней и автоматическую эскалацию при открытии 30-дневного срока исправления.
Страницы без владельца попадают в 45-дневную очередь назначения и не получают функциональных обновлений, пока директор продукта не примет ответственность.
Панель жизненного цикла еженедельно выгружает в Jira страницы без владельца, просроченные, истекающие и снятые страницы по продуктам.

Зачем это спрашивают: Интервьюер оценивает архитектуру жизненного цикла контента с обязательным владением и ревью по уровню риска.

migrations

Я бы создал единую карту канонических тем до переноса любого портала.

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

Зачем это спрашивают: Интервьюер проверяет, сводится ли контент после поглощения через данные и явные канонические решения, а не массовый перенос.

ci-cddocusaurusgithub-actions

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

Версионированные пакеты контента содержат документацию продуктов, а общий пакет темы управляет навигацией, поисковыми метаданными, доступностью и локалями.
GitHub Actions проверяет изменённые файлы, стиль, ссылки, схемы и затронутые сборки в pull request, а после слияния запускает полную матрицу.
Кэши зависимостей и контента учитывают lock-файл, локаль, продукт и версию генератора, чтобы несвязанные изменения не сбрасывали все 2800 страниц.
SLO платформы задают p95 обратной связи по превью менее 10 минут, доступность production 99,9% и владельцев каждого показателя.

Зачем это спрашивают: Интервьюер оценивает масштабируемую архитектуру Docusaurus с ясными границами, инкрементальным CI и SLO платформы.

system-designdesignapi

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

Проекты пакетов владеют исходниками RST или MyST и входами autodoc, а единый пакет расширений управляет темой, перенаправлениями, предупреждениями и выбором версии.
Ночная генерация справки сравнивает публичные символы с прошлым артефактом и открывает задачу на ревью добавлений, удалений и изменений сигнатур.
Релизные процессы собирают только изменённые пакеты, затем объединяют и проверяют полный манифест версий перед публикацией.
Бюджет в 20 минут делится между подготовкой окружения, сборкой пакетов, проверкой ссылок и развёртыванием, а замеры хранятся 90 дней.

Зачем это спрашивают: Интервьюер проверяет модульную архитектуру Sphinx, управление генерируемой справкой, версиями и ограниченным временем релиза.

monorepo

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

Изменения API, примеры и примечания к релизам остаются рядом с кодом, чтобы 40 еженедельных релизов атомарно обновляли реализацию и документацию.
Общие учебные материалы, навигация, тема, правила Vale и контентные схемы живут централизованно и поставляются продуктовым репозиториям как версионированные пакеты.
Федеративный манифест предоставляет единому порталу канонические URL, владельцев, локали и входы сборки без копирования исходников.
Запись архитектурного решения сравнивает доступ авторов, атомарность изменений, обновление зависимостей, обнаружение и стоимость восстановления до внедрения.

Зачем это спрашивают: Интервьюер оценивает топологию репозиториев как компромисс между связью с релизом и общим платформенным управлением.

design

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

Затронутые продукты и локали определяются по графу зависимостей, а изменение общей темы запускает полную матрицу портала.
Каждое превью получает неизменяемый URL, вход через корпоративного провайдера идентификации и видимый баннер с коммитом, веткой и сроком удаления.
Проверки GitHub публикуют статус сборки, ссылки на изменённые страницы, артефакты визуального сравнения и закрытый URL превью за 8 минут.
Плановая задача через 14 дней удаляет хранилище и записи развёртывания и сверяет потерянные ресурсы с месячным бюджетом.

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

deploymentrollbackarchitecture

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

CI создаёт подписанный манифест с коммитом, версией генератора, пакетами локалей, контрольными суммами, перенаправлениями и версией поискового индекса.
Staging проверяет маршруты, ссылки, доступность, заголовки и 100 критичных путей на точном production-артефакте.
Развёртывание загружает новую версию в отдельный origin и меняет указатель CDN только после успешных проверок во всех локалях.
Два предыдущих артефакта и индекса сохраняются готовыми к развёртыванию, поэтому откат укладывается в 15 минут без пересборки.

Зачем это спрашивают: Интервьюер оценивает надёжную статическую доставку через неизменяемые артефакты, предпроизводственные проверки, атомарное переключение и быстрый откат.

ci-cdgithub-actionsquality-gates

Я бы разделил проверки по риску и сначала запускал самые дешёвые детерминированные барьеры.

Каждое изменение получает проверки схемы, Markdown, Vale, внутренних ссылок, секретов и владельцев только для затронутых файлов.
Примеры кода, внешние ссылки, доступность и полные сборки локалей запускаются при изменении их зависимостей или по расписанию.
У блокирующего правила должны быть владелец, обоснование, тестовые фикстуры, измеряемая доля ложных блокировок и временное исключение со сроком.
Панель отслеживает p50 и p95 длительности, время в очереди, сбои по правилам, исключения и ложные блокировки относительно целей 12 минут и 1%.

Зачем это спрашивают: Интервьюер проверяет, являются ли проверки качества быстрыми, риск-ориентированными, измеримыми и управляемыми.

design

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

CODEOWNERS направляет запросы продуктовым владельцам для обычных путей, но сам по себе не может обеспечить два отдельных одобрения; для путей безопасности и оплаты обязательная проверка политики через GitHub App или бота подтверждает одно одобрение не от автора со стороны доменной команды и одно со стороны команды документации.
Защита ветки запрещает прямую отправку и требует проверку политики одобрений и проверку CI, которая подтверждает подписи и происхождение релизных артефактов до слияния; сама защита ветки подписи не проверяет.
Подрядчики входят в ограниченные группы с автоматическим истечением через 90 дней и не получают закрытые исходники или production-ключи развёртывания.
Квартальный аудит сравнивает права в репозитории, CI, хостинге и хранилище секретов и фиксирует исключения с владельцами и датами окончания.

Зачем это спрашивают: Интервьюер оценивает архитектуру прав с учётом чувствительности контента, одобрений, временного доступа и полномочий на развёртывание.

migrationsdesignperformance

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

Эталонный корпус представляет размеры страниц, диаграммы, генерируемую справку, глубину навигации и все 8 локалей на объёмах 500, 2500 и 5000 страниц.
Зависимости контента, темы, схем API и локалей определяют затронутые сборки вместо полного пересоздания каждого результата.
Воспроизводимые кэши покрывают зависимости, разобранный контент, артефакты API, изображения и сегменты поиска с явными ключами сброса.
Нагрузочные тесты должны удержать p95 полной сборки ниже 15 минут и прогноз вычислений ниже $6000 до одобрения миграции.

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

observability

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

Запись развёртывания связывает коммит, запуск процесса, манифест артефакта, число маршрутов, локаль, версию CDN и поколение поискового индекса.
Метрики охватывают время очереди, длительность сборки, этап сбоя, возраст развёртывания, доступность маршрутов, отставание индекса и успех превью по продуктам.
Синтетические проверки каждые 5 минут проверяют 60 критичных страниц, переключатели локалей и версий и результаты поиска.
Командные панели и месячные отчёты SLO показывают владельцев, расход бюджета ошибок и нерешённые дефекты платформы без пользовательских данных.

Зачем это спрашивают: Интервьюер оценивает сквозную трассируемость платформы и отчётность SLO, а не только логи сборки.

docusaurussphinxmigrations

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

Карта оценки учитывает извлечение Python API, поддержку React-компонентов, локализацию, версии, интеграцию поиска, доступность, навыки авторов и стоимость сопровождения.
Каждый инструмент собирает один срез из 120 страниц с авторскими руководствами, генерируемой справкой SDK, диаграммами, перенаправлениями и двумя локалями.
Прототип измеряет время сборки, труд авторов, разработку расширений, качество результата, поверхность обновлений и стоимость владения за 5 лет.
Запись решения выбирает лучший подтверждённый результат и удерживает миграцию в пределах $120 000 и 7 месяцев.

Зачем это спрашивают: Интервьюер проверяет выбор инструмента через репрезентативный прототип и полную стоимость владения, а не личные предпочтения.

Закрытые вопросы

21
Спроектируйте программу документации OpenAPI для 28 REST-сервисов, 1400 справочных страниц и 11 команд разработки, где обновления справки публикуются в течение 24 часов после слияния схемы.
restopenapidocumentation
22
Спроектируйте документацию AsyncAPI для 16 доменов событий, 900 страниц и 7 команд-производителей, включая примеры Kafka и трёхмесячный переход версий схем.
documentationschemakafka
23
Создайте единую модель документации разработчиков для 5 SDK, 1200 страниц и квартальных релизов, где примеры Java, Python, JavaScript, Go и .NET отстают по функциям не более чем на один релиз.
javascriptpython
24
Планируется, что 55% портала API на 2000 страниц будет генерироваться из OpenAPI и исходников SDK; определите границу между генерируемым и авторским контентом до шестимесячной перестройки.
openapi
25
Спроектируйте документацию версий API для 36 сервисов, 1800 страниц и 4 поддерживаемых версий при ежемесячных релизах и обещании совместимости на 12 месяцев.
versioningapi-versioningdesign
26
Определите систему устаревания для 24 публичных API, которыми пользуются 6000 разработчиков, с уведомлением за 12 месяцев, 3 релизными циклами SDK и 1100 затронутыми страницами.
content-deprecationsystem-designapi
27
Спроектируйте тестирование 2400 фрагментов кода для 6 SDK и 3 поддерживаемых версий API, где результаты pull request приходят менее чем за 20 минут, а полное покрытие запускается ночью.
coveragecode-sample-testingapi
28
Спланируйте руководство по миграции с API v2 на v3 для 1300 страниц, 4 SDK и 2500 клиентских приложений, если поддержка v2 закончится через 9 месяцев.
migration-guidesapimigrations
29
Перестройте онбординг портала разработчиков на 750 страниц для 3 API и 4 SDK, чтобы за квартал сократить медианное время первого успешного вызова с 42 до 15 минут.
onboardingapi
30
Создайте синхронизацию релизов для 20 сервисов, 5 SDK и 1600 страниц для разработчиков, если разработка выпускается дважды в неделю, а SLA публикации документации составляет 24 часа.
documentation
31
Спроектируйте информационную модель DITA для 4000 страниц о 7 аппаратных продуктах, 12 вариантах и 6 локалях в Oxygen с миграцией за 18 месяцев.
ditaoxygen-xmlmigrations
32
Настройте процесс Oxygen XML для 2500 тем DITA, 30 авторов и 8 продуктовых команд, с ревью менее чем за 5 рабочих дней и нулём невалидных тем при публикации.
configditaoxygen-xml
33
Спроектируйте проект MadCap Flare для 1700 справочных тем, 5 настольных продуктов, 3 релизных веток и результатов PDF и веб при годовом бюджете инструментов $90 000.
madcap-flare
34
Создайте модель переиспользования компонентов для 3100 тем о 9 продуктах, где 28% текста дублируется, а 6 командам нужны независимые графики релизов.
components
35
Спроектируйте условную публикацию 2200 тем для 8 редакций продукта, 4 операционных систем и 6 локалей, не допуская попадания неподдерживаемых инструкций к клиентам.
system-designdesign
36
Спроектируйте архитектуру локализации 4600 тем в 8 локалях с ежемесячными релизами, переводом через 10 рабочих дней после английского и годовым бюджетом $420 000.
designlocalization
37
Организуйте терминологию на 3800 страницах о 10 продуктах в 7 локалях после аудита, который нашёл 420 конкурирующих терминов для 140 понятий; создайте управляемый глоссарий за 4 месяца.
terminology-managementforms
38
Определите управление исходниками для 650 диаграмм на 2900 страницах о 6 продуктах, если редактируемый исходник должен обновляться в течение 3 дней.
39
Спроектируйте управление 1200 скриншотами и 180 видео на 3400 страницах о 5 продуктах в 6 локалях при годовом производственном бюджете $75 000.
design
40
Задайте архитектуру доступности для 5000 страниц, 900 диаграмм и 220 видео в 7 локалях с целью WCAG 2.2 AA за 12 месяцев.
documentation-accessibilitywcaga11y
41
Создайте стайлгайд для 2700 страниц от 85 авторов из 9 команд в 6 локалях, с внедрением за 6 месяцев и не более чем 20 обязательными правилами.
style-guides
42
Определите критерии готовности документации для 14 продуктовых команд, выпускающих 35 функций в квартал в комплекс из 3200 страниц, если одобрение релиза требуется за 2 дня до запуска.
documentation
43
Спроектируйте SLA ревью для 2100 страниц и 12 команд, если писатели получают 160 pull request в месяц, включая обычную цель 48 часов и блокирующую запуск цель 4 часа.
code-reviewdesignpull-requests
44
Создайте показатель качества документации для 4200 страниц о 8 продуктах, объединив аналитику и аудиты так, чтобы высокий трафик не скрывал неточности; выпустите первый базовый замер за 90 дней.
documentation
45
Встройте документацию в дорожные карты 10 продуктовых команд, управляющих 2800 страницами и 60 плановыми релизами за 2 квартала, если доступно только 6 писателей.
roadmapdocumentation
46
Создайте политику снятия контента для 3600 страниц о 9 продуктах, где 540 старых страниц должны уйти за 6 месяцев при покрытии перенаправлений выше 99%.
content-deprecationcoverage
47
Поддержка обрабатывает 18 000 обращений в месяц, связанных с базой знаний на 2500 страниц; спроектируйте шестимесячную программу документации с целью 15% подтверждённого предотвращения обращений по 5 продуктам.
documentationdesign
48
Спроектируйте программу наставничества для 6 писателей, поддерживающих 3000 страниц и 11 команд, если 2 новичка должны принять продуктовую область за 90 дней.
mentoringdesign
49
Предлагаемая перестройка платформы документации стоит $360 000 для 12 команд, которые поддерживают 4800 страниц; Finance требует окупаемости за 18 месяцев, а ручная подготовка релизов, локализация и исправления по обращениям Support занимают 6400 часов сотрудников в год. Обоснуйте инвестиции и предложите поэтапную архитектуру.
documentationlocalizationarchitecture
50
Создайте управление документационным массивом из 5000 страниц о 12 продуктах от 20 команд в 8 локалях, с квартальным советом и годовым бюджетом программы $900 000.
documentation
51
В релизе API переименовали заголовки аутентификации, из-за чего устарели 240 страниц, а за 2 часа 18 клиентов создали 63 обращения о неудачном входе; вы откатите API, исправите только главные страницы или остановите раскатку?
authapirollback
52
В руководстве по миграции базы для 320 корпоративных администраторов шаги указаны в неверном порядке, 27 уже начали работу, а 6 сред недоступны; вы отзовёте руководство, добавите исправление в текст или поручите поддержке разбирать каждый случай?
databasemigrationsmigration-guides
53
Документация вебхуков всё ещё обещает повторы каждые 10 секунд, хотя продукт перешёл на экспоненциальные повторы в течение 24 часов, и 41 партнёр создал дубли заказов; вы откатите документацию, поведение или опишете новый контракт?
documentationwebhooksresilience
54
В Python SDK метод create_user переименовали в create_users, но 96 примеров и 14 руководств используют старый вызов, а пакет скачали 38 000 раз; вы отзовёте пакет, добавите alias или исправите только документацию?
tutorialspython
55
Product хочет выпустить релиз через 3 часа, Engineering утром изменила 7 процессов на 180 страницах, а проверены только 45 страниц; вы задержите релиз, опубликуете частичную документацию или отмените проверку?
56
В beta-руководстве по OAuth 74 командам рекомендовали хранить клиентский секрет в браузерных приложениях, а 11 этих секретов появились в публичных репозиториях; вы тихо исправите текст, отзовёте beta или смените все данные доступа?
oauthsecrets
57
В enum API изначально было 4 значения, затем добавили ещё 12, всего стало 16; сгенерированный справочник верно показывает все 16, но 68 написанных вручную страниц допускают только первые 4. Вы удалите текст, сгенерируете его или сохраните оба варианта?
reference-docsapi
58
Документация лимитов обещает 1 000 запросов в минуту, production теперь ограничивает 300, а у 9 крупных клиентов доля ответов 429 превысила 22%; вы вернёте старый лимит, объявите новый или создадите временные исключения?
documentationerror-handling
59
В релизе CLI удалили 3 флага из 46 руководств по автоматизации, из-за чего сломались 1 700 ночных задач до публикации release notes; вы вернёте флаги, срочно обновите документацию или попросите пользователей переписать скрипты?
60
Релиз 9.4 откатили через 52 минуты, но поиск и кэшированные страницы всё ещё направляют 26 000 посетителей в день на 130 процедур версии 9.4; вы очистите весь релизный контент, сохраните историю или перенаправите на 9.3?
caching
61
Портал документации отвечает 503 уже 47 минут во время запуска продукта и затронул 82 000 посещений; вы переключитесь на статическое зеркало, подождёте поставщика или отправите пользователей в кэш поиска?
documentationcachingprocurement
62
Сборка документации выросла с 9 до 46 минут после добавления 24 000 сгенерированных страниц API, и 31% pull request сливаются без preview; вы купите более мощные runners, разделите сайт или сократите генерацию?
code-reviewapipull-requests
63
После переиндексации доля запросов без результатов выросла с 7% до 29% на 1,4 миллиона поисков, а клики по API-справочнику упали на 38%; вы вернёте старый индекс, будете править ranking в production или подождёте обхода?
indexesqueriesapi
64
После перестройки URL сломались 18 600 входящих ссылок, органический трафик упал на 44%, а 2 300 статей поддержки используют старые пути; вы откатите структуру, добавите редиректы или будете постепенно править ссылки?
65
Изменение прав открыло 6 внутренних runbook для 3 400 внешних пользователей на 19 минут, включая приватные hostnames без данных доступа; вы отключите портал, скроете страницы или смените инфраструктурные адреса?
runbooks
66
Генератор OpenAPI тихо дал сбой и опубликовал справочник только для 312 из 740 endpoints, а руководства ссылаются на отсутствующие операции; вы откатите, оставите частичный справочник или восстановите предыдущий контракт?
endpointsopenapigenerators
67
При миграции monorepo переместили 9 200 страниц и 37 пакетов, но 16% межпакетных ссылок сломаны, а preview для авторов занимает 28 минут; вы откатите, заморозите правки или исправите на месте?
monoreporollbackmigrations
68
Скомпрометированная зависимость темы документации внедрила cryptominer в 4% сессий на 3 часа, а у пакета 11 транзитивных зависимостей; вы исправите тему, откатите сайт или отключите все скрипты?
documentationdependenciessessions
69
Preview-среды не создаются для 43% из 86 pull request документации из-за исчерпанной квоты хостинга; вы уберёте preview, увеличите квоту или переведёте всех на один staging?
code-reviewdocumentationpull-requests
70
Один регион CDN отдаёт документацию на 3 релиза старее для 17% трафика Азиатско-Тихоокеанского региона, что привело к 290 сессиям с неверными процедурами; вы отключите регион, очистите всё глобально или дождётесь истечения кэша?
documentationcachingsessions
71
Аудит нашёл 1 480 дублирующихся страниц в 6 продуктовых областях, а противоречивые страницы настройки создают 31% обращений онбординга; вы объедините по трафику, удалите старые или поручите командам чистить свои области?
onboarding
72
Граф ссылок выявил 620 orphan-страниц, 190 всё ещё получают прямой трафик, а 74 содержат актуальные compliance-инструкции; вы удалите все, добавите в навигацию или архивируете?
73
У 40% из 3 600 страниц нет активного владельца, 280 связаны с сервисами, которые изменят в этом квартале, а Engineering отказывается брать всё сразу; вы заморозите страницы, назначите писателей или эскалируете директорам?
escalationownership
74
Через 6 месяцев после запуска стайлгайда его используют только 3 из 14 команд, Vale находит 12 400 нарушений, а писатели тратят 90 часов в месяц на споры; вы заблокируете все правила, переобучите команды или упростите гайд?
style-guidesvale
75
Очередь review документации достигла 430 pull request, медианный возраст 19 дней, а 38 релизов продукта ждут; вы снизите требования, наймёте подрядчиков или разделите очередь по риску?
backlogdocumentationcode-review
76
Команда выполнила квартальную цель 200 страниц, разделив 48 руководств на 236 коротких страниц, но выполнение задач упало с 78% до 61%; вы сохраните цель, отмените дробление или замените метрику?
monitoring
77
После 3 приобретений появилось 11 терминов для одного объекта аккаунта на 2 700 страницах, а доля переформулировок поиска достигла 34%; вы немедленно назначите один термин, сохраните бренды или создадите alias?
78
Sales отправил 96 срочных запросов на документацию за месяц, но аналитика показывает, что только 8 влияют на активные сделки, а 22 дублируют страницы; вы примете срочность, отклоните очередь или введёте intake-модель?
documentationdata-structures
79
Проект очистки архивировал 900 малопосещаемых страниц и поднял freshness с 72% до 94% за счёт меньшего знаменателя, но поддержка использует 140 архивных страниц; вы отметите успех, вернёте страницы или переопределите метрику?
80
Два эксперта держат 67 review, медианный ответ занимает 16 дней, а релизы обходят документацию после 5 дней; вы добавите писателей, уберёте экспертное согласование или перестроите владение review?
documentationownership
81
Ошибка условной публикации DITA показывает enterprise-шаги настройки в 14 локалях, и 6 800 community-пользователей видят неработающие команды; вы снимете все локали, исправите условия или оставите только английский?
dita
82
Проект single-source сократил 1 900 topics до 620, но 23% переиспользуемых предупреждений неверны хотя бы для одного из 8 продуктов; вы отмените reuse, добавите условия или разрешите продуктовые fork?
83
Рефакторинг key space DITA сломал 4 300 cross-references в 9 локализованных руководствах за две недели до производства; вы откатите ключи, исправите ссылки вручную или отложите руководства?
reference-docsrefactoringdita
84
Ошибка fallback локали отдаёт инструкции на английском семимесячной давности для отсутствующих строк в 12 локалях и затрагивает 18% страниц обновления; вы отключите fallback, заблокируете локали или покажете смешанный, но текущий контент?
85
Редизайн сделал устаревшими 760 скриншотов в 20 локалях, но их полная замена задержит запуск на 3 недели; вы выпустите старые изображения, удалите их или задержите продукт?
86
Архитектурная диаграмма в 6 локалях всё ещё показывает выведенную из эксплуатации очередь, и 14 клиентов скопировали её в свои проекты; вы удалите диаграммы, выпустите исправление или вернёте старую архитектуру?
designdata-structures
87
Аудит доступности в 8 локалях отметил 1 240 изображений для проверки текстовых альтернатив и нашёл 310 недоступных с клавиатуры вкладок кода; вы заблокируете релизы, сгенерируете alt-текст или исправите по трафику?
documentation-accessibilityalt-textkeyboard-accessibility
88
Условная PDF-сборка пропустила обязательные предупреждения в 5 из 16 локалей из-за разного перевода одной переменной; вы остановите все поставки, выпустите исправные локали или вставите английское предупреждение?
89
Импорт translation memory распространил неверное предупреждение о разрушительной команде на 3 600 сегментов в 10 локалях, а 84 страницы уже опубликованы; вы откатите память, исправите страницы или остановите локализацию?
localizationmemoryrollback
90
Web, PDF и встроенная помощь генерируются из одного источника, но 22% из 1 100 topics показывают разные prerequisites в 6 локалях; вы разделите источники, нормализуете условия или примете различия каналов?
normalization
91
Roadmap продукта финансирует 4 growth-функции, но не работу над 520 устаревшими enterprise-страницами, которые создают 38% эскалаций поддержки; вы примете roadmap, потребуете задержать функцию или предложите ограниченное исправление?
roadmapescalation
92
Внешний аудит через 12 дней, у 46 из 180 контролируемых процедур нет доказательств согласования, а Operations просит поставить подписи задним числом; вы отложите аудит, восстановите доказательства или согласитесь?
forms
93
Поставщик документационной системы прекратит поддержку через 90 дней, миграция включает 28 000 topics и 16 локалей, а замена не поддерживает DITA keyrefs; вы продлите контракт на год, мигрируете сейчас или запустите обе системы?
documentationmigrationsprocurement
94
Engineering отвергает documentation release gate, потому что он добавляет 11 минут к 260 еженедельным сборкам, но 7 из 10 последних инцидентов связаны с незадокументированными breaking changes; вы уберёте его, оставите blocking или перестроите?
incidentsdocumentationversioning
95
Product, Support и Documentation ведут отдельные календари запусков, и в прошлом квартале 17 из 32 релизов дошли до клиентов до готовности документации или поддержки, создав 410 предотвратимых обращений; вы централизуете владение, добавите встречи или создадите единую модель готовности?
documentationownershiphealth-checks
96
Младший технический писатель публикует пример аутентификации с токеном администратора, хотя ошибку не заметили 2 рецензента; страницу посмотрели 9 000 раз. Вы отстраните автора от материалов по безопасности, признаете это системным сбоем или ограничитесь отзывом токена?
authtokens
97
Review работ писателя среднего уровня в среднем содержит 96 комментариев и 4 раунда на 12 pull request, задерживая релизы на 8 дней; вы снизите требования, передадите работу или выстроите раннее наставничество?
mentoringcode-reviewpull-requests
98
Четыре инженера создают 70% внутренней документации, но на их 210 страницах читатели ошибаются в 17% задач, а авторы считают редакционный review слишком медленным; вы отберёте авторство, введёте обязательный review или обучите их?
99
Legal требует disclaimer на 900 слов на 46 страницах онбординга, Product прогнозирует падение completion на 12%, а аудит через 9 дней; вы примете текст, спрячете за ссылкой или предложите layered disclosure?
onboarding
100
Новый писатель закрывает 55 обращений за месяц, но 18 открываются снова из-за слабых доказательств, а другой закрывает 24 без повторов; вы вознаградите объём, замедлите первого или измените обучение и метрики команды?
monitoring

Вопросы

7Спланируйте перенос 3500 страниц Confluence из 14 пространств в единый портал разработчиков за 10 месяцев и $180 000 с сохранением 12 000 входящих ссылок.

13Выберите модель monorepo или multirepo для 3000 страниц, которыми владеют 18 команд разработки и платформенная группа из 5 писателей, при 40 продуктовых релизах в неделю.

14Спроектируйте превью pull request для портала на 2100 страниц в 6 локалях, где 120 авторам нужны закрытые ссылки за 8 минут, а превью удаляются через 14 дней.

15Определите архитектуру развёртывания портала на 4500 страниц о 9 продуктах в 7 локалях, с SLA доступности 99,95% и целью отката за 15 минут.

16Определите проверки качества GitHub Actions для 2700 страниц от 16 команд, с бюджетом pull request в 12 минут и менее 1% ложных блокировок в месяц.

19Определите наблюдаемость платформы на 3600 страниц для 6 продуктов и 5 локалей, где SLA публикации и свежести поиска 99,9% отчитываются перед 15 командами.

20Выберите Docusaurus или Sphinx для портала на 2300 страниц с руководствами React, справкой Python SDK и 6 локалями при бюджете миграции $120 000 и сроке 7 месяцев.

Закрытые вопросы