Сообщить об ошибкеКороткий ответ
Ввожу классификацию запросов по типу и сложности (например, self-service через готовые дашборды, типовой ad-hoc запрос, глубокое исследование) с разными целевыми сроками (SLA) для каждого типа, основанными на исторических данных о фактическом времени выполнения, и честно сообщаю, что при текущей нагрузке что-то придётся либо не успевать, либо не делать.
Как это работает подробнее
единый SLA «на всё» невозможен при разнородных по сложности запросах; ошибка оценки обычно происходит потому, что лёгкие и тяжёлые запросы смешиваются в одной очереди с одинаковым ожиданием скорости ответа.
Что использовать на практике
- На практике: собираю исторические данные о фактическом времени выполнения запросов разных типов (используя, например, трекер задач), выделяю категории с заметно разным распределением трудозатрат, и для каждой категории даю SLA с указанием диапазона уверенности (например, «типовой ad-hoc отчёт — 2-3 рабочих дня при текущей загрузке»), а не точечное число. Параллельно инвестирую в self-service инструменты (готовые дашборды, документированные определения метрик), чтобы снизить долю запросов, требующих ручной работы аналитика.
- Пример: | Тип запроса | Медиана факт. времени (из трекера) | Предлагаемый SLA | |---|---|---| | Вопрос по существующему дашборду | 2 часа | в течение дня | | Типовой ad-hoc отчёт (новый срез по существующим данным) | 1.5 дня | 2-3 рабочих дня | | Глубокое исследование / новая метрика | 8 дней | 1-2 недели, по согласованию | Проверка: через квартал сравнить фактическое соблюдение SLA по категориям — систематическое нарушение SLA в одной категории сигнализирует, что либо оценка была нереалистичной, либо нагрузка в этой категории выросла и требует пересмотра ресурсов.
Подводные камни
- Частые ошибки: давать одинаковый оптимистичный SLA на все типы запросов, чтобы не расстраивать заказчиков, а затем регулярно его нарушать, что подрывает доверие сильнее, чем честно более длинный срок; не измерять фактическую нагрузку и давать оценки «на ощущение»; пытаться решить проблему нагрузки только более быстрой работой аналитиков, без инвестиции в self-service и приоритизацию.