Browser Policy Manager (BPM) подходит к релизу 1.0.0. Это открытый инструмент для подготовки, проверки и экспорта профилей Firefox Enterprise. Он позволяет работать с одним профилем не только как с JSON-файлом, но и через библиотеку профилей, пошаговый редактор, каталог настроек, сравнение и редактор исходного policies.json.
В 0.9.5 появились четыре актуальных канала схем Firefox: Release 153, ESR 153.0, ESR 140.13 и ESR 115.38. Для поддерживаемых старых ESR BPM умеет предложить переход на ESR 153.0, построить предварительный просмотр преобразования и применить его только после явного подтверждения. Если план устарел, заблокирован или не проходит проверку, профиль не меняется.
У такого продукта документация не может быть приложением «когда-нибудь потом». Политика браузера влияет на обновления, расширения, приватность, учётные записи, сеть и поведение пользователей. Ошибка в настройке может означать не просто неудачный интерфейсный опыт: иногда она оставляет организацию без ожидаемого ограничения или без понятного способа восстановиться.
Поэтому вместе с продуктом я готовлю документационный портал. В релизе 0.9.5 он прошёл проверку шести локалей, воспроизводимости, поставки PDF, пакета и установки артефакта. Сам релиз сейчас имеет статус release candidate: после завершения ревью коммита и передачи в CI документация будет поставляться вместе с актуальной версией BPM.
Почему одной справки по policies.json недостаточно
У Firefox есть официальная справка по корпоративным политикам. Она необходима: именно там описаны синтаксис и смысл политики. Но в ежедневной работе администратора возникает другой набор вопросов:
какой канал схемы выбрать для конкретного парка браузеров;
где в BPM найти нужную настройку и как понять, откуда она взялась;
когда достаточно пошагового редактора, а когда нужен полный JSON;
как проверить импортированный файл до применения;
что означает предупреждение, как отменить рискованное действие и что делать при ошибке;
как связать профиль с CIS-рекомендациями, не выдавая автоматизацию за подтверждённое соответствие бенчмарку;
как встроить BPM в существующий процесс через API.
Ответы должны находиться рядом с действием, а не в устаревшей заметке в вики. И они должны оставаться синхронизированными с интерфейсом, схемами Firefox и контрактами API. В этом для меня и состоит задача продуктовой документации: не повторить исходный код и не переписать чужую справку, а помочь пройти конкретный путь без догадок.
Что входит в портал
Портал содержит четыре семейства руководств во всех шести языках интерфейса: английском, русском, немецком, упрощённом китайском, французском и испанском.
Руководство | Для каких задач |
|---|---|
Руководство пользователя | Библиотека профилей, сравнение, пошаговый редактор, полный каталог настроек, JSON-редактор, импорт, экспорт, проверка и восстановление после типичных ошибок. |
Руководство по политикам Firefox | Политики и управляемые предпочтения, примеры, различия Release и ESR, происхождение сведений и ограничения схем. |
Руководство по настройкам CIS | Сопоставления BPM с рекомендациями, пресеты, слои, порядок слияния, ручная проверка и границы автоматизации. |
Руководство администратора и DevOps | Развёртывание из исходного кода на Linux и Windows через WSL, эксплуатация, обновление, интеграция по API, диагностика и текущие границы production/HA/reverse proxy. |
В портал также входят локальный поиск, навигация, контекстные ссылки из приложения, проверенные скриншоты и PDF-поставки. Отдельно сохраняется FastAPI OpenAPI-интерфейс по адресу /docs: продуктовая документация не подменяет техническое описание API.
Важно, что это не набор пересказов. Например, справочник по политикам отделяет поведение Firefox от поведения BPM; раздел CIS отделяет доступные сопоставления от ручной проверки; руководство администратора прямо фиксирует то, что пока не поддерживается. Я предпочитаю такую документацию обещаниям «должно работать».
Как устроена документация
Исходники портала написаны в DITA. Это не самый модный формат, зато он хорошо подходит для документации с повторяющейся структурой, стабильными идентификаторами тем, несколькими локалями и строгой проверкой ссылок.
DITA-темы и карты шести локалей ↓ проверки содержания, терминологии, ссылок и полноты ↓ сборщик документации ↓ статический портал, манифест, карта UI-целей и поисковые индексы ↓ установленный артефакт → /help/ в BPM
Сборочные инструменты, исходные темы, тесты и временные результаты изолированы от работающего приложения. Рантайм BPM не тянет за собой Java, DITA-инструментарий или исходный корпус. Он читает только установленный статический артефакт и отдаёт его по /help/.
Это разделение решает сразу несколько задач. Сборка остаётся воспроизводимой и проверяемой отдельно от сервера. Неработающий или неподходящий артефакт не маскируется: пользователь увидит локализованное сообщение о том, что документация отсутствует, устарела, неполна или несовместима. При этом сама библиотека профилей продолжит работать.
Связь с основным интерфейсом не строится на вручную записанных URL. В артефакт входят манифест и карта UI-целей. По ним BPM получает локализованную домашнюю ссылку, контекстные ссылки для пяти основных рабочих поверхностей и точные ссылки на темы о политиках, CIS, проверке, импорте и экспорте. Если соответствующая цель отсутствует, интерфейс показывает понятное локализованное состояние вместо битой ссылки.
В шапке BPM есть переход к документации в текущем языке. Контекстная помощь открывается в новой вкладке и не мешает незавершённой работе с профилем. Это важная мелочь: инструкция полезна только тогда, когда её можно открыть, не потеряв состояние редактора.
Поиск: сначала предсказуемый и локальный
Поиск уже сейчас работает без сервера поиска, сети и телеметрии. При публикации формируются статические индексы для каждой локали. Индекс знает заголовки, разделы, ключевые слова, идентификаторы политик, API-операции, CIS-идентификаторы и псевдонимы терминов.
Ранжирование намеренно детерминированное: точное совпадение идентификатора или заголовка важнее расплывчатого совпадения в тексте. Есть ограниченная терпимость к опечаткам, но не бесконтрольный «умный» поиск. Это даёт две практические вещи: результат можно объяснить и проверить, а портал остаётся пригодным для автономного развёртывания.
Сложность здесь не только в поисковом алгоритме. policies.json, пути API и имена политик нельзя «переводить для удобства», а обычные слова в запросах переводятся и меняют форму. Поэтому правила нормализации, псевдонимы и тестовые запросы ведутся отдельно для каждой локали.
Где здесь ИИ и RAG
В релизе 0.9.5 RAG и генерация ответов не включены. Видимый в портале помощник честно сообщает, что находится в подготовке; он не запускает модель, не строит индекс, не выдаёт сгенерированные ответы, цитаты или результаты внешнего поиска. Обычный поиск от этого не зависит и остаётся доступен всегда.
Это сознательная граница, а не недоделанная кнопка. Для будущего локального помощника уже описаны требования к источникам, приватности, безопасности, ресурсам, изоляции процесса и состояниям доступности. План такой:
Брать знания только из разрешённого, проверенного документационного корпуса с привязкой к теме, якорю, локали и версии.
Делить корпус на проверяемые фрагменты, строить эмбеддинги и индекс только для совместимого набора параметров.
При изменении исходной темы, локали, версии, схемы фрагментов или модели перестраивать затронутые артефакты; неполный или смешанный набор не использовать.
Продвигать новый набор атомарно только после проверки хешей, покрытия локалей и ссылок на источники.
Не отвечать на фактический вопрос без подходящего доказательства в той же локали и без разрешимой ссылки на источник.
Модель не должна обучаться на документации или диалогах «по ходу работы». Будущее обновление RAG — это перестроение индекса, а не изменение весов модели. Загрузка модели или обращение к внешним источникам должны требовать явного действия пользователя; локальный поиск остаётся безопасным запасным вариантом при любой недоступности помощника.
Такой подход медленнее, чем добавить чат к готовой странице. Но для инструмента, который управляет политиками браузера, предпочтительнее помощник, который способен отказаться от ответа, чем уверенный текст без источника.
Шесть локалей: где оказалась настоящая сложность
Перевести шесть страниц — задача редакторская. Поддерживать шесть равноценных порталов — задача продуктовая.
У BPM языки — не резервные варианты. Для каждого из en, ru, de, zh-CN, fr и es-ES есть свои темы, карты навигации, строки поиска, подписи, альтернативный текст и скриншоты. Английская страница не должна появиться в другом языке как незаметная подстановка. Исключения допускаются только для заранее определённых технических идентификаторов, названий продукта, команд, путей и API-сокращений.
Самые трудные места были такими:
Смысловая полнота. Короткий перевод легко теряет условие, предупреждение, шаг восстановления или ограничение. Поэтому локализованные темы обязаны сохранять ту же структуру, решения, примеры, оговорки и пути выхода из ошибки, что и английский исходник.
Единая терминология с UI. Название кнопки в документации должно совпадать с названием кнопки в приложении. Источник истины для таких имён — исполняемые каталоги локализации BPM, а не память автора и не автоматический перевод.
Поиск в разных письменностях. Диакритика, склонение, пунктуация, CJK-сегментация и технические идентификаторы требуют разных правил нормализации. Поэтому для каждой локали есть проверяемые псевдонимы и наборы запросов.
Скриншоты. Картинка с английским интерфейсом не является иллюстрацией к русской или китайской инструкции. Для ключевых сценариев ведётся матрица из 36 проверенных локальных изображений: с подписью и альтернативным текстом в языке темы.
Макет и доступность. Немецкое составное слово, китайский интерфейс или длинный текст сообщения об ошибке могут сломать компактный элемент, который в английском выглядит нормально. Проверяются переключение языка, узкие и широкие экраны, клавиатурная навигация, фокус и текст состояний.
Эти требования поддерживаются не только договорённостью. Изменение документации проходит проверки полноты локалей, терминологии, видимого английского текста, ссылок, навигации, поиска, скриншотов и связей с интерфейсом. В финальной документационной проверке 0.9.5 прошёл 1 001 выбранный контракт. Число само по себе не доказывает удобство документации, но хорошо показывает, что локализация не оставлена на ручную надежду.
Что дальше
Документация в BPM — это часть механизма безопасной работы с политиками. Она объясняет, какой результат получится, где проходит граница автоматизации, как проверить действие и как вернуться к безопасному состоянию. Портал связан с интерфейсом, но не размывает его; локальный поиск полезен уже сейчас, но не выдаёт себя за ИИ; а будущая RAG-составляющая получит право отвечать только вместе с проверяемыми источниками и предсказуемыми границами.
Исходный код BPM доступен на GitHub. Справочник синтаксиса и поведения корпоративных политик Firefox поддерживает Mozilla в Firefox administrator reference. Если вы управляете Firefox в организации, особенно интересны отзывы о том, какие сценарии развёртывания, миграции, проверки и восстановления ещё нуждаются в отдельной инструкции.
