1.1.2 · блок 1
Жизненный цикл задачи: от идеи до поддержки
Жизненный цикл задачи: от идеи до поддержки
Зачем это нужно
В учебных заданиях дедлайн — это дата сдачи. В продуктовой разработке дедлайн — лишь одна точка на длинной дорожке: идея → планирование → разработка → релиз → эксплуатация. Если начать писать код до того, как задача «готова к работе», вы потратите время на уточнения. Если закрыть задачу до того, как она «действительно готова», в продакшене появится сырой функционал.
Definition of Ready (DoR) и Definition of Done (DoD) — два договора команды, которые защищают от хаоса. Этот урок объясняет полный путь задачи и то, что происходит, когда что-то идёт не так.
Основные идеи
Путь задачи от идеи до релиза:
1. Идея / гипотеза — «если мы добавим рекомендации, конверсия вырастет». Фиксируется PM, часто в виде Epic.
2. Уточнение и декомпозиция — Epic разбивается на Story и Task. Пишутся acceptance criteria.
3. DoR-check — команда проверяет: понятна ли цель, есть ли данные, согласованы ли метрики?
4. Разработка — код, модель, тесты. Задача движется по доске: To Do → In Progress → Code Review → QA.
5. DoD-check — перед закрытием: код в main, тесты зелёные, документация обновлена, мониторинг настроен.
6. Релиз — выкладка в продакшен по расписанию или по флагу (feature flag).
7. Поддержка — SRE/On-call следит за метриками; баги заводятся как новые Task.
Definition of Ready (DoR) — чеклист «можно брать в работу». Пример для ML-Story:
- Описана бизнес-метрика успеха.
- Есть доступ к данным (или явно указано, кто его предоставит).
- Acceptance criteria сформулированы и согласованы.
- Нет блокирующих зависимостей от других команд.
Definition of Done (DoD) — чеклист «задача завершена по-настоящему». Пример:
- PR смержен, CI прошёл.
- Unit-тесты и интеграционные тесты написаны.
- Runbook или README обновлены.
- Алерт на ключевую метрику настроен.
- PM/QA подтвердили приёмку.
DoR и DoD — *командные* соглашения. Их нельзя скопировать из учебника: команда формулирует их вместе и пересматривает раз в квартал.
Инциденты и postmortem. Инцидент — событие, когда сервис работает хуже, чем ожидается: падение, деградация latency, некорректные предсказания модели. Процесс:
1. Detection — алерт или сообщение пользователя.
2. Response — on-call инженер оценивает масштаб, при необходимости откатывает релиз.
3. Resolution — устранение первопричины.
4. Postmortem — разбор *без обвинений* (blameless): что случилось, почему, что изменим в процессах.
Postmortem пишут в Confluence. Хороший postmortem содержит timeline, root cause, action items с владельцами и сроками.
Как это выглядит на практике
Story в Jira: ML-142 «Добавить fallback при недоступности модели».
- DoR: Backend подтвердил, что API-gateway поддерживает routing; SRE согласовал SLA fallback (< 50 ms).
- Разработка: MLE пишет PR, QA проверяет сценарий «model service down → возвращается rule-based score».
- DoD: интеграционный тест в CI, runbook в Confluence обновлён, алерт «model_unavailable > 5 min» создан.
Через две недели алерт срабатывает: pod с моделью убит OOM-killer. On-call делает rollback, сервис восстанавливается за 8 минут. Postmortem фиксирует: не были заданы memory limits в Kubernetes manifest — action item для DevOps.
Что сделать после занятия
- [ ] Составьте DoR и DoD для учебного ML-проекта (минимум по 5 пунктов в каждом).
- [ ] Опишите на одной странице воображаемый postmortem: «модель стала предсказывать только один класс после релиза» — timeline + 3 action items.
- [ ] Найдите в Jira (или нарисуйте на бумаге) workflow с колонками — сопоставьте их с этапами жизненного цикла из урока.