On-Call — Pitch

Проблема

Никто не учит тому, что случается в продакшене

Туториалы объясняют как написать сервис. Курсы учат теории CAP-теоремы. Но cascade failure в 3 ночи — этому учит только опыт.

Нет хорошего способа понять поведение распределённой системы под нагрузкой пока она не сломается у тебя в продакшене. On-Call это меняет.

■ API Gateway ✓ healthy

│

■ Order Service ⚠ lag: 840ms

│ │

■ NATS Queue ⚠ 18k/30k msgs

│

■ Notification ✕ DOWN

SLA: 94.2% ████████████░░

Timer: 02:18 remaining

Концепция

Ты внутри живой системы

Tron-стиль город сверху. Здания — это сервисы. Между ними текут потоки данных как световые трассы.

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

Tap-to-move Реальные метрики Cascade failure

Прогрессия

От монолита до Chaos Engineering

АКТ 01

Монолит

Connection pool, memory leak, slow query. Учишься читать логи и метрики.

tutorial

АКТ 02

Микросервисы

Cascade failure, queue lag, retry storm. Система распределена — проблемы тоже.

intermediate

АКТ 03

Несколько инстансов

Load balancer, unhealthy instance, race condition. Масштабирование создаёт новые проблемы.

advanced

АКТ 04

Kubernetes

OOMKilled, CrashLoopBackOff, неправильные resource limits. Автохилинг не всегда помогает.

expert

АКТ 05

Chaos Engineering

Sandbox. Строишь систему сам, настраиваешь circuit breakers — потом Chaos Monkey рвёт.

endgame

Механики

Геймплей который обучает

⏱

SLA таймер

Цель раунда — удержать SLA выше порога пока тикает таймер. Не "найди и почини", а "выживи".

🔥

Cascade failure

Проблемы распространяются по графу зависимостей в реальном времени пока ты бежишь к сервису.

🔧

Инструменты

Logs, Metrics, Trace, Heap Dump, Restart, Rollback, Circuit Breaker. Открываются по мере прогрессии.

🎲

Chaos Monkey

Акт 1 — заскриптованные события. Акт 3 — полный рандом. Каждый раунд уникален.

⚡

Retry storm

Сломанный сервис вызывает retry у upstream — нагрузка растёт, cascade ускоряется. Положительная обратная связь.

📊

Реальная симуляция

RPS, connection pool, queue lag, cache warmup — формулы основаны на реальном поведении систем.

Аудитория

Каждый разработчик чувствует эту боль

"Я знаю теорию circuit breaker. Но почему именно сейчас каскад — я не понимаю."

— Junior Backend Developer

"Хочу показать команде что значит on-call до того как они окажутся в нём первый раз."

— Tech Lead

"Прошёл три курса по микросервисам. Ни один не объяснил что делать когда всё горит."

— Middle Developer

"Это то что я хотел бы иметь когда только начинал работать с распределёнными системами."

— Senior SRE

Конкурентное преимущество

Почему On-Call

Нет прямых конкурентов

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

Аутентичный контент

Автор — Senior Backend Developer с реальным опытом NATS, gRPC, circuit breakers, cascade failures. Не геймдизайнер который изучал распределённые системы, а инженер который делает игру.

Симуляция как отдельный продукт

Движок симуляции отказов — это самостоятельная ценность. Веб-версия, CLI инструмент, обучающая платформа для команд — всё это расширения одного ядра.

Название которое продаёт себя само

"On-Call" — это триггер. Любой разработчик читает это слово и уже чувствует эмоцию. Маркетинг встроен в название.

Технологии

Стек разработки

Слой	Технология	Почему
Игровой движок	Unity 2D URP	2D lights для Tron-эффектов, Android билд из коробки
Игровая логика	C#	Нативный язык Unity, хорошая экосистема
Симуляция	C# (.dll)	Отдельная библиотека без зависимостей от Unity, покрывается xUnit тестами
Платформа	Android	Tap-управление, большая аудитория разработчиков
Визуал	Tron / Cyberpunk 2D	Emission materials, 2D lights, particle system для потоков данных