Workflow — это контракт между людьми, выраженный шагами процесса.

Когда люди тратят слишком много времени на координацию — значит контракт неявный. Хороший workflow делает контракт явным, видимым и проверяемым. Этого достаточно, чтобы сэкономить десятки часов в месяц.

workflow.types

Три семейства workflow в технологической компании.

TYPE 01 · INBOUND

Входящие процессы

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

FORMATstate-machine

TYPE 02 · INTERNAL

Внутренние циклы

Поток разработки, релизный цикл, on-call ротация. Эти процессы должны быть видимы для всех участников.

FORMATkanban + checkpoints

TYPE 03 · OUTBOUND

Исходящие процессы

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

FORMATcalendar + sign-off

TYPE 04 · INCIDENT

Аварийные потоки

Отдельная категория, требующая отдельной документации. Цель — минимизировать время между обнаружением и реакцией.

FORMATrunbook + escalation

incident response

Шесть фаз обработки инцидента.

Detect

Сигнал получен.

Acknowledge

Принят дежурным.

Investigate

Гипотезы причин.

Mitigate

Купирование эффекта.

Resolve

Восстановление.

Postmortem

Разбор без обвинений.

// runbook · пример

Структура минимального runbook.

Каждый runbook оформлен по одному шаблону. Это даёт инженеру предсказуемый интерфейс в стрессовой ситуации.

# runbook: events-broker.lag-high

severity:    "P2 — degradation, no data loss"
owner:       "@team-events"
detection:   "lag > 5min for 3 consecutive checks"

# шаги диагностики (выполнить последовательно)
steps:
  1. "check brokers list"          → /ops/brokers
  2. "verify consumers heartbeat"   → /ops/consumers
  3. "inspect topic partitions"     → /ops/topics
  4. "if stuck consumer — restart"   → see playbook.r4

# эскалация — если P3 за 30 минут не разрешён
escalation:  "@on-call-lead → page architect"