Проверка работы Димы_в3

1. Проверка практических другого студента

ПРОВЕРКА ПРАКТИЧЕСКИХ
ДРУГОГО СТУДЕНТА
БОЛДЫРЕВ НИКИТА ПРОВЕРЯЛ ЕРМАКОВА ДМИТРИЯ
М4200С

2. Краткое описание исходного SLA

КРАТКОЕ ОПИСАНИЕ ИСХОДНОГО SLA
SLA охватывает:
• Ключевые метрики: uptime, API latency, sync latency, crash-free
rate, MTTA/MTTR, data durability, security incidents.
• Процесс принятия решений: от приоритизации (WSJF) до реакции
на «чёрных лебедей».
• Координацию ролей: PO, Team Lead, разработчики, QA, Support.
• Финансовую и операционную оценку: TCO, ROI, Run vs Grow.

3. Перегибы, недочёты, риски

ПЕРЕГИБЫ, НЕДОЧЁТЫ, РИСКИ
1. Недостаточная формализация классификации инцидентов
Инциденты описаны текстово, без формальной классификации по приоритетам. Без уровней P0–P3 невозможно задать SLA на время реакции и восстановления, что делает SLA юридически и операционно
непригодным. Нужно ввести таблицу приоритетов с фиксированными таймингами реакции и восстановления
2. Отсутствие регламента обновления SLA
Указаны uptime, latency, crash-free rate, но нет формул и окон измерения:
за какой период,
по каким платформам,
из какого источника данных.
Для каждой метрики добавить: формулу, период измерения и источник данных.
3. Некоторые метрики не полностью измеримы
Есть рассуждения про архитектурные улучшения и принятие решений, но нет runbook или rollback-критериев. В кризисной ситуации SLA не подсказывает, что делать, а лишь фиксирует последствия. Нужно
зафиксировать условия rollback и ответственного за принятие решения.
4. Нет разделения метрик по типам пользователей
Все метрики одинаковы для всех пользователей, хотя в ПР5 прямо сказано: «Базовое хранилище остаётся бесплатным, премиум-аккаунты получают приоритет в очереди задач».
5. В ПР3 (релиз 10): «Uptime ≥ 99.9%» без указания исключений (DDoS, сбои третьих сторон).

4. Оценка SLA в контексте «чёрных лебедей»

ОЦЕНКА SLA В КОНТЕКСТЕ «ЧЁРНЫХ
ЛЕБЕДЕЙ»
Что сработало:
Гибкость приоритетов: "Ключевые SLA по безопасности и синхронизации выполнены. Незначительные отклонения по менее критичным
метрикам зафиксированы и запланированы на последующие релизы".
Быстрая техническая реакция: "Введено ограничение на частоту sync-запросов", "Добавлен механизм «мягкого восстановления» при
конфликте".
Прозрачные зоны ответственности: Четкое распределение между Product Owner, Team Lead, разработчиками.
Что не сработало (или могло бы быть лучше):
Нет протокола коммуникации при аварии (например, статус-страница, уведомления пользователям, дежурный чат).
Нет «окна отката» (rollback window) - при баге в проде неясно, в течение какого времени допустим откат.
Отсутствие freeze period — изменения вносятся даже за неделю до релиза: "за неделю до релиза Х+1 руководство меняет приоритеты".
Нечеткие правила изменения SLA — в ПР4 команда "пересматривает SLA", но нет процедуры согласования и уведомления.
Зоны ответственности
• В целом прозрачны (PO → TL → команды), но нет формального SLA на коммуникации между ролями (например: «PO уведомляет TL в течение
15 мин при смене приоритета»).

5. Что бы я НЕ делал

ЧТО БЫ Я НЕ ДЕЛАЛ
Не вводил бы SLA-метрику без чёткого определения SLI.
Например: «Crash-free ≥98.5%» — но без указания:
• какая версия приложения (неверные замеры),
• какие ОС (может не запуститься),
• в каких сетевых условиях (500).
Не обещал бы uptime ≥99.9% без explicit-описания maintenance window и исключений (например: DDoS,
действия третьих лиц).
"Улучшение офлайн-режима(частичное)" и "Поиск и индексация(урезанный scope)" не имеют четких
критериев приемки, что противоречит требованию, что SLA должен быть понятен для нетехнарей.
В ПР4 команда меняет SLA ("SLA пересматриваются для критичных функций"), но нет процедуры
согласования и уведомления

6. Что бы я сделал по-другому

ЧТО БЫ Я СДЕЛАЛ ПО-ДРУГОМУ
1. Ввёл бы классификацию инцидентов (P1–P3) с чёткими SLI и ответственными.
2. Включил бы operational readiness checklist перед релизом:
1. Есть ли мониторинг?
2. Есть ли rollback-план?
3. Протестированы ли крайние сценарии?
3. Прописал бы правила «чёрного лебедя»:
1.
2.
3.
freeze period за 5 дней до релиза,
max 1 срочная задача от бизнеса в неделю до релиза,
обязательный risk-review с участием QA и Support.
4. Добавил бы SLO-бюджет ошибок, чтобы управлять балансом между скоростью и качеством.
5. "Изменения в SLA вступают в силу через 48 часов после согласования Product Owner и Team Lead, с обязательным
уведомлением всех команд за 24 часа".
6. Добавил бы глоссарий в начало документа

7. Вывод и оценка

ВЫВОД И ОЦЕНКА
Сильные стороны:
• Показана эволюция команды: "ранние релизы (1–3): хрупкая архитектура... поздние релизы (8–10): SLA достигались или
превышали плановые значения"
• Четкий финансовый анализ и trade-off решения
• Отличная техническая глубина и реалистичное описание проблем
Слабые стороны:
Отсутствие классификации инцидентов (P1/P2/P3) — нарушает требование: "Хватает ли приоритезации инцидентов?"
• Нет регламента изменения SLA — не выполнено ключевое требование: "SLA должен обновляться при изменении
архитектуры, зависимостей или внешних требований"
• Неопределенность формулировок — противоречит принципу: "SLA должен быть понятен для нетехнарей"
Итоговая оценка: 7.5 / 10