Как прогнозируется время обработки файла

Что проверяют

Умеете ли вы оценивать производительность по измерениям, а не по формуле из головы. Вопрос поведенческий: ждут случай из вашей практики, например прогресс загрузки или SLA на обработку выгрузок, и спросят, насколько точным оказался прогноз.

Как отвечать

Расскажите историю по схеме: что обрабатывали, как измеряли, как считали оценку, что показала практика. Цифры должны быть ваши. Если такой задачи не было, скажите об этом и разберите, как сделали бы. Технический каркас на Go:

• прогресс: размер файла берётся из os.Stat, чтение оборачивается в свой io.Reader, который считает байты атомарным счётчиком. Прогресс равен доле прочитанного от размера;
• ETA во время работы: оставшиеся байты делятся на скорость, сглаженную экспоненциальным средним. Мгновенная скорость скачет, и оценка прыгает от минуты к часу;
• прогноз до запуска: по истории обработок. Длительность пишется гистограммой в Prometheus с меткой формата, затем строится регрессия времени на размер. Отдавать лучше p50 и p95, а не среднее;
• пропускная способность: бенчмарк на testing.B с b.SetBytes, тогда go test -bench показывает МБ/с, и видно, линейна ли зависимость от размера;
• нелинейности: сортировка внутри файла даёт O(n log n), у сжатого файла распакованный размер заранее неизвестен, параллельные воркеры делят диск и сеть.

Честный вывод обычно такой: для типовых файлов оценка работает, а для редких форматов вы показываете диапазон, а не точное время.

Где спотыкаются

Берут константу вида «100 мс на мегабайт» без замера. Скорость зависит от диска, формата, содержимого и соседей по машине, и такая формула ошибается в разы.

Считают ETA по мгновенной скорости или по первым секундам. В начале прогреваются кеши и устанавливаются соединения, поэтому ранняя оценка сильно врёт.

Путают единицы и типы: делят на 1e6, хотя размер считали через 1024 × 1024, или приводят к time.Duration до умножения и теряют дробную часть.