Кратко

  • Предлагаемый SLA относится к производительности и доступности систем. Он прямо исключает оценку Tools Team, а также график и планирование её работы.
  • UX-консультация охватывает интерфейсы, доступность, управление доступом, требования к клиентам и режимы Web, CLI, plugin, API, MCP и offline; параметры систем вынесены в параллельный процесс.
  • Публичная версионная квитанция может связать отзыв с сервисом, метрикой, исключениями, полномочием принять решение, владельцем реализации, приоритетом, сроком и последующей проверкой, сохранив раздельные состояния SLA и UX.

Одна дата не означает одно решение

17 сентября 2026 года IETF LLC запросила отзывы о двух сторонах IETF Tools. Обе консультации заканчиваются 12 октября. Ответ можно направить конфиденциально Board и Executive Director либо публично в tools-discuss. Общие каналы не объединяют предметы обсуждения.

SLA-документ посвящён наблюдаемому поведению систем. В нём предлагаются показатели доступности, времени ответа веб-сервисов, задержки почты и реакции на инциденты. Сервисы распределяются по уровням, частичная деградация получает вес, оговариваются исключения, ежемесячная отчётность и ежегодный пересмотр. Так режим «best efforts» должен превратиться в проверяемое ожидание от сервиса.

UX-документ рассматривает взаимодействие человека с инструментами. Он перечисляет Web, командную строку, плагины, API, Model Context Protocol и автономный режим, а также задаёт вопросы о доступности, аутентификации, требованиях к клиенту, устойчивых URL и персонализации. Производительность систем исключена именно потому, что ей посвящена соседняя консультация.

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

Что может измерить SLA

Проект недвусмысленно оставляет за рамками эффективность Tools Team и расписание или планирование её задач. Эти вопросы можно обсуждать отдельно, но выводить их из сервисной метрики нельзя.

Внутри своего периметра схема подробна. Автоматический мониторинг должен быть главным источником данных о доступности. Полный отказ имеет вес 1, серьёзная деградация — 0,5, небольшая — 0,25, косметическая проблема — ноль. Критическая инфраструктура отделяется от менее важных и сторонних сервисов. Веб-ответ измеряется на серверной стороне, без рендеринга клиента, пользовательской сети и определённых внешних зависимостей.

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

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

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

Что решает UX-процесс

Инструменты развивались органически, поэтому многие интерфейсные решения принимали разработчики. Для нового rfc-editor.org привлекались специалисты, однако общего формального механизма получения и учёта мнения сообщества раньше не было.

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

Но каждый вариант способен изменить эксплуатацию. Offline может потребовать синхронизации данных или поддерживаемых контейнеров. Аутентификация добавляет зависимость. API и MCP меняют нагрузку и обоснование ключей или лимитов. Такие последствия следует измерять после выбора, а не подменять ими выбор.

Версионная квитанция на каждом переходе

Community Engagement Policy IETF LLC уже требует отслеживать отзывы, учитывать их или объяснять отказ, а после решения уведомлять сообщество. Для двух параллельных консультаций это правило можно сделать сквозным и проверяемым.

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

Например, просьба о надёжном offline-доступе на встречах сначала требует UX-решения: принять, отклонить или отложить. Отдельная сервисная запись определит набор данных, точку синхронизации или образ контейнера, место измерения и внешние зависимости. Принятый сценарий ещё не означает достигнутый SLA; зелёный SLA не означает, что сценарий создан.

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

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

Источники