Какие методы использовались для достижения оптимизации процесса закрытия операционного дня

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

Был ли у вас реальный опыт с тяжёлыми пакетными процессами в финтехе и можете ли вы объяснить, куда уходило время. Операционный день в банке закрывается строго: пока он не закрыт, следующий не начать, а ошибка стоит денег. Следом спрашивают, как вы убедились, что ускорение не сломало сверку и что повторный запуск не задвоит проводки.

Как отвечать

Каркас строится на вашем опыте: сколько длилось закрытие, какое было окно, что оказалось узким местом и какими замерами это нашли. Опорные техники на Go:

• профилирование до правок: pprof по CPU и памяти, трассировка этапов через OpenTelemetry, EXPLAIN ANALYZE для тяжёлых запросов. Без замеров непонятно, что ускорять;
• параллелизм с ограничением: работа режется на независимые куски, например по счетам или филиалам, и идёт через пул воркеров на errgroup с SetLimit, чтобы не выбрать весь пул соединений к базе;
• пакетная работа с базой: вставка через COPY (в pgx это CopyFrom), батчи вместо запроса на каждую строку, keyset-пагинация вместо OFFSET, короткие транзакции вместо одной на весь процесс;
• идемпотентность и рестарт с точки остановки: каждый шаг помечает обработанные куски, повторный запуск продолжает работу, а не начинает её заново и не дублирует проводки;
• перенос работы на день: агрегаты и остатки считаются инкрементально по мере поступления операций, а на закрытии остаётся досчитать хвост и сверить итоги.

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

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

Отвечают про Agile, созвоны и «улучшили коммуникацию». Вопрос технический, интервьюер ждёт узкие места и способы их снять.

Предлагают «запустить по горутине на каждый счёт». Без ограничения конкурентности это исчерпание соединений, блокировки в базе и падение по памяти.

Называют проценты ускорения, но не могут объяснить, за счёт чего они получены и как проверили корректность после изменений. Сверка итогов со старой версией процесса на тех же данных обязательна.