Дизайн сайта с runbook сервиса

Дизайн runbook для auth-service

Этот официальный пример сайта OpenDesign представляет runbook сервиса идентификации Northwind как единый операционный справочник. Авторский заголовок — «auth-service», далее следуют владелец, версия, дата проверки и статус «TIER 0 · PRODUCTION-CRITICAL». Такое начало задаёт ответственность сервиса ещё до оповещений и команд.

Сводка сервиса называет выпуск, проверку и отзыв токенов сессий в вебе, мобильных приложениях и публичном API. Она также указывает хранилище паролей, регистрации TOTP/WebAuthn и модуль записи журнала аудита. Это помогает сориентироваться: ещё до выбора процедуры ответственный видит, какие клиентские и связанные с безопасностью обязанности относятся к сервису.

Поддерживаемые операционные задачи

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

Список зависимостей повторяет шаблон «название — состояние» для Postgres, Redis, KMS, SES и Pager. Четыре записи отмечены как исправные, а SES · transactional — как работающая с деградацией. Состояния, выровненные по правому краю, удобно просматривать, но это снимок демонстрационного дизайна, а не подтверждённые проверки состояния в реальном времени.

От оповещения к процедуре

Раздел оповещений устроен как четырёхколоночная поверхность для принятия решений: оповещение, серьёзность, значение и первое действие. Например, «auth.login_5xx_rate greater than 1%» сопоставлено с «SEV-1», объяснением о блокировке клиентов и рекомендацией проверить дашборды Postgres и Redis. Явный порог даёт ответственному триггер, а текст — интерпретацию; компромисс в том, что в реальном runbook демонстрационные значения всё равно нужно связать с подтверждённым источником мониторинга.

В разделе процедур меняется ритм: от компактных строк к крупным блокам с заголовком, примечанием об использовании, пояснением и панелью команд. «Deploy a new version» указывает, что поток blue/green и перед переключением ожидаются две последовательные проверки работоспособности. Видимая последовательность трафика «10% / 50% / 100%» показывает поэтапный выкат, а более крупный блок занимает больше места по вертикали ради безопасного чтения на уровне команд.

Команды и ограничения

Блоки процедур держат действие и предостережение рядом. Откат помечен для случая, когда доля ошибок после развёртывания превышает 1%, а в ротации ключей подписи сказано «Schedule with security; never solo». Процедура журнала аудита прямо связана с оповещением об очереди. Эти пары показывают удачное информационное решение: команда не считается достаточной сама по себе, а окружающее условие определяет, когда она уместна в рабочем процессе.

Последовательность инцидента и границы возможностей

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

Это пример сайта, созданный только как дизайн. Снятая страница показывает команды, статусы, имена и демонстрационные результаты, например «rolled back to v4.7.2 in 38 s», но не доказывает, что эти команды выполняются, сервисы подключены или показанные операционные результаты были измерены. При адаптации следует сохранять различие между документированными рекомендациями и проверенными данными времени выполнения.

1. Подтвердите вызов

   Дизайн начинается с /ack и пятиминутного окна реакции, задавая первое обязательство по координации.

2. Откройте канал инцидента

   Вторая карточка называет сервис и шаблон краткого заголовка для создания отдельного пространства реагирования.

3. Опубликуйте снимок статуса

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

4. Смягчите последствия и передайте дежурство

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