Исповедь SQL-программиста
Я не делаю кнопки. Я не продаю продукты. Я пишу SQL-запросы, которые решают, кто сегодня молодец, а кто снова не уложился в SLA.
Утром — кофе и письмо от бизнес-аналитика:
«А можешь добавить в отчёт столбец, где видно, на сколько секунд просрочен KPI?» Мол, надо для совещания.
Потом — звонок в Teams:
«У нас в отделении N заявки висят больше часа, отчёт пишет SLA ‘OK’. Это как?» И я лезу в логи. Смотрю метки. Считаю разницу в секундах. Понимаю: они вручную перевели статус обратно. И теперь моя система не видит просрочку. Она слепа, как и должна быть. Она честна — но бизнес хочет гибкости.
Днём — очередной тикет:
«Слишком много SLA Missed. Можем не учитывать обеденное время?» - Нет, не можем. Система не обедает. Клиенту не объяснишь, что у вас ланч.
А вечером — ты сидишь, уже пустой, и правишь запрос с шестью JOIN'ами, чтобы рассчитать новый KPI для внутреннего департамента:
«Сколько заявок переданы между системами дольше 3 минут». Потому что где-то на встрече это назвали «узким горлышком».
А ты не споришь. Ты просто считаешь.
Я вижу всё:
- заявки, которые прошли за 4.59 — SLA OK
- и те, что ушли за 5.01 — SLA Fail Они почти одинаковы. Но отчёт не про «почти».
Мой любимый момент — пятница, 17:45:
«Надо к утру сравнить SLA по мобильному приложению и отделениям. Желательно с визуализацией». Желательно… А я уже сижу пятый день на одном запросе, в котором CTE внутри CTE, а количество строк в результирующей таблице превышает население города.
Но я продолжаю. Потому что знаю: каждая строка — это не просто заявка. Это чей-то платёж. Чей-то кредит. А KPI — это то, как мы с этим справляемся.
И да, иногда я срываюсь. Иногда мне снятся метки created_dttm и closed_dttm. Иногда я говорю «JOIN» в реальной жизни и ловлю взгляд коллеги через весь офис.
Но когда отчёт сошёлся, когда график зелёный, и никто не написал утром — я знаю: всё отработало.
А значит, я всё сделал правильно.