Какая была эксплуатация на проекте?

Эксплуатация на проекте

Под "эксплуатацией" имеется в виду фаза ПОСЛЕ вывода продукта в production, когда система работает и нужно её поддерживать. Это критичный этап, который часто недооценивают. Вот мой опыт:

1. Что включает эксплуатация

Post-Launch Activities:

• Мониторинг ошибок (Sentry, logs)
• Исправление критичных багов
• Поддержка пользователей (hotline)
• Сбор feedback от пользователей
• Анализ метрик и KPI
• Планирование улучшений (v1.1, v1.2)

SLA (Service Level Agreement) — обещание:

• 99.5% uptime (max 3.6 часа downtime в месяц)
• Критичный баг: fix в течение 2 часов
• Major баг: fix в течение 8 часов
• Minor баг: fix в течение недели

2. Первые дни после запуска (неделя 1)

День 1-2: "Honeymoon" период

Люди только начинают использовать систему:

• Мало трафика
• Нет реальных данных
• Баги которые мы пропустили становятся видны

Что я делаю:

• Сижу в Slack и смотрю feedback пользователей
• Проверяю Sentry на ошибки
• Проверяю logs на странные pattern
• Общаюсь с QA и разработчиками
• Если критичный баг → собираю чрезвычайное совещание

Пример: баг с платежами

Пользователи начали жаловаться что платежи не проходят. Я:

1. Связался с разработчиком backend
2. Посмотрели logs и увидели что webhook от платежной системы не парсится
3. Это был баг в обработке JSON (мы забыли handle один формат ответа)
4. Разработчик фиксит 30 минут
5. Мы пересоздали платежи для затронутых пользователей
6. Я написал post-mortem (что произошло, почему, как избежать)

День 3-7: Стабилизация

• Трафик растет
• Новые баги появляются
• Пользователи берут новые пути которые мы не предусмотрели

Мои задачи:

• Бриф для support team (как отвечать на вопросы)
• Создание FAQ на основе вопросов пользователей
• Обновление требований на основе feedback
• Приоритизация багов

3. Как я приоритизирую баги

P0 (Critical) — фиксим немедленно:

• Система упала (500 errors)
• Потеря данных
• Безопасность скомпрометирована
• SLA: fix в 1-2 часа

P1 (High) — фиксим в этот день:

• Функционал полностью не работает
• Пользователь не может сделать основное действие
• Бизнес impact: high
• SLA: fix в 4-8 часов

P2 (Medium) — фиксим на следующей неделе:

• Функционал работает но некорректно
• Есть workaround для пользователя
• Бизнес impact: medium
• SLA: fix в течение недели

P3 (Low) — фиксим когда будет время:

• Косметические проблемы
• Nice to have улучшения
• Бизнес impact: low
• SLA: fix в течение месяца

Пример мой приоритизации:

Баг: кнопка "Share" не работает на мобильных

Мой анализ:
- Что сломалось? Share functionality на мобильных
- Сколько людей затронуто? ~40% (мобильные юзеры)
- Есть ли workaround? Да, на десктопе работает
- Бизнес impact? Medium (но важная феча)
- Когда нужно? В течение дня

Решение: P1, фиксим сегодня

4. Управление feedback пользователей

Где мы собираем feedback:

In-app surveys (survey widget)

• После завершения действия: "Помог ли вам это?"
• Если No → тут же спрашиваем почему
• Собираем в Google Sheets для анализа

Email: support@company.com

• Люди пишут если что-то сломалось или неудобно
• Support team форвардит мне
• Я анализирую паттерны (если 5 человек пожаловались на то же — это trend)

Slack: #feedback канал

• Пользователи могут напрямую писать
• Я следу за этим каналом
• Реагирую обычно в течение часа

Support ticket system

• Более структурированное управление
• Трекинг статуса
• Историю коммуникации

Анализ feedback:

Каждую неделю я:

1. Собираю все feedback
2. Категоризирую (UI, Performance, Feature request, Bug)
3. Считаю频率 (сколько раз упоминается каждая проблема)
4. Пишу summary для PM
5. Рекомендую что сделать

Пример:

Feedback этой недели (20 responses):
- UI confusing: 8 упоминаний (40%)
  → Пользователи не находят feature X
  → Recommendation: улучшить navigation

- Performance slow: 7 упоминаний (35%)
  → Загрузка таблицы 5+ секунд
  → Recommendation: оптимизировать query

- Feature request: 5 упоминаний (25%)
  → Люди хотят экспорт в Excel
  → Recommendation: добавить в backlog v1.1

5. Метрики и мониторинг

Что я смотрю каждый день:

System Metrics (в Datadog):

• API response time: < 500ms (p95)
• Error rate: < 0.1%
• Database queries: < 200ms
• Uptime: > 99.5%

Если что-то красное → следу за разработкой fix.

Business Metrics (в Google Analytics):

• Daily active users (DAU)
• Conversion rate (% users who complete action)
• Feature adoption (% users using feature X)
• Churn rate (% users who stopped using)

User Experience Metrics (в survey):

• NPS (Net Promoter Score) — на шкале 0-10, сколько вы рекомендуете?
• Customer satisfaction (CSAT) — 1-5 scale
• Task completion rate — % пользователей кто смог сделать что хотел

Пример дашборда:

┌─────────────────────────────────────┐
│ Current Status (Live Dashboard)      │
├─────────────────────────────────────┤
│ Uptime: 99.8% ↓ (usually 99.9%)    │
│ Response time: 320ms ✓              │
│ Error rate: 0.05% ✓                 │
│ DAU: 5,234 ↑ +12% vs last week     │
│ Conversion: 8.3% → 9.1% ↑           │
│ NPS: 42 (target: 50+)              │
│ Tickets: 3 open (all P2/P3)        │
└─────────────────────────────────────┘

Я проверяю это каждое утро перед daily standup.

6. Post-Launch Review (неделя 2)

Встреча со всей командой (2 часа):

Часть 1: What Went Well (45 min)

• Что прошло хорошо?
• Что нам помогло?
• Кто сделал хорошую работу?

Примеры:

• "Мы заранее создали runbook для incident, это сильно помогло"
• "QA тестирование было thorough, поймали 90% багов перед launch"

Часть 2: What Went Wrong (45 min)

• Какие баги были?
• Почему их пропустили?
• Как избежать в следующий раз?

Примеры:

• "Мы не учли edge case когда пользователь быстро кликает кнопку дважды" → Solution: добавить debounce → Testing: добавить тест на быстрые клики

• "Webhook от платежной системы не парсился" → Solution: лучше читать документацию платежки → Testing: добавить unit tests для разных форматов

Часть 3: Action Items (30 min)

• Что мы будем делать по-другому?
• Кто за что отвечает?
• Когда сделать?

Примеры:

• Улучшить documentation (PM ответственный, deadline: неделя)
• Добавить monitoring alerts (DevOps, deadline: 3 дня)
• Создать playbook для support (я, deadline: 5 дней)

7. Плантерм: вторая и третья недели

Неделя 2: Bug Fixes Sprint

• Разработка + QA работают на исправлении reported багов
• Я координирую приоритеты
• Сбираю feedback по-прежнему
• Пишу улучшения требований (v1.1)

Неделя 3: Стабилизация

• Баги почти все закрыты
• Система стабильна
• Начинаем планировать v1.1
• Фокус на метриках (DAU растет? Conversion растет?)

8. Управление инцидентами (если что-то сломалось)

Критичный incident: система упала

Шаг 1: Обнаружение (0-2 минуты)

• Мониторинг alerts: "Error rate > 1%"
• Slack notification в #incidents
• На пользователей приходят жалобы

Шаг 2: Сбор team (2-5 минут)

• Я создаю Zoom conference
• Приглашаю: lead разработчика, DevOps, PM
• Создаю incident document в Google Docs (что произошло, timeline, action)

Шаг 3: Diagnosis (5-30 минут)

• DevOps смотрит логи и infra
• Разработчик смотрит код
• Я координирую и задаю вопросы

Шаг 4: Fix (зависит от проблемы)

• Если code bug → разработчик быстро пфиксит
• Если infra issue → DevOps решит (restart service, scale up, etc)
• Я жду пока fix будет готов

Шаг 5: Verification (5 минут)

• Проверяем что система работает
• Смотрим error rate — должен упасть
• Проверяем несколько юзер flows

Шаг 6: Communication (continuous)

• Я пишу в Slack что произошло
• Обновляю статус статус-пейж (statuspage.io)
• Пишу email пользователям (если был downtime)
• Пишу в соц. сети (честность важна)

Шаг 7: Post-Mortem (в течение 24 часов)

• Встреча с командой
• Разбираем что произошло
• Пишу post-mortem документ
• Планируем как избежать в будущем

Пример post-mortem:

Incident: Database query timeout causing 500 errors

Timeline:
14:05 - Пользователь запросил большой report
14:06 - Query заехал (N+1 problem)
14:07 - Database слоу, другие queries тоже заехали
14:08 - API response time > 30sec, users получают timeout
14:10 - Alert сработал, я её получил
14:12 - Собрали команду
14:20 - Разработчик нашел баг в коде
14:25 - Быстрый fix развёрнут
14:28 - System стабилен

Root Cause: В query был N+1 bug (запрашивали данные в loop)
Why not caught: Не было теста с large dataset
Fix: Добавить query optimization, добавить load test
Owner: Backend lead, deadline: 3 дня
Follow-up: Review все queries на подобные проблемы

9. Долгоёмные улучшения (v1.1)

На основе feedback и метрик я создаю список улучшений:

Из feedback:

• "Search is slow" → Need to add indexing
• "I want to export to Excel" → Feature request
• "Mobile UI is confusing" → UX improvement

Из метрик:

• Feature X имеет 2% adoption → либо фича не нужна, либо нужна better onboarding
• Conversion rate стал ниже → что-то отогнало пользователей?
• Churn rate выросла → проблема с retention

Приоритизация:

• High impact + Low effort = делаем сразу
• High impact + High effort = планируем
• Low impact = может быть не делаем

10. Lessons Learned

Ошибки которые я делал:

1. Плохо подготовился support team

   • Пользователи писали "эта кнопка неработает" но support не знал как помочь
   • Теперь: я создаю knowledge base, тренирую team перед launch

2. Не было playbook для инцидентов

   • Когда система упала, все панировали
   • Теперь: у нас есть чек-лист и Zoom link

3. Не смотрел метрики

   • Я думал что все happy, но data showed что 40% пользователей ушли
   • Теперь: смотрю метрики каждый день

4. Игнорировал negative feedback

   • Я хотел верить что продукт хороший
   • Теперь: negative feedback это золото, нужно слушать

Итог

Эксплуатация — это не конец проекта, это начало. Product dies if we don't take care of it post-launch. Моя роль — быть ушами и глазами для team, собирать signal от пользователей и превращать это в улучшения.