Всем привет!

Сегодня пост-продолжение рассказа Дмитрия Панкрашова (Python Backend Developer в Сбере, автор канала DevIO | IT | GameDev) про опыт проектирования и внедрения системы автоматизации.

Первая часть

Самое вкусное и интересное — технические ошибки. Именно они во многом определили для меня отношение к этому проекту, как к неудачному. С одной стороны, мне можно и посочувствовать. Что я знал и умел на тот момент? И указать на ошибки было, в общем‑то, некому. С другой стороны, наделавшись велосипедов, столкнувшись с последствиями принятых мной решений, я могу проще относиться к начинающим разработчикам, которые точно знают, как надо. Потому что помню, как сам таким был.

Ошибка 1️⃣- Хранить файлы в базе данных
Как вам идея? Почему‑то мне показалось, что нет особой разницы между хранением на диске и в базе. В базе даже поудобнее, сразу связи видно, а на диске — вдруг чего где потеряется или затрётся? Загружаемые файлы, конечно, были ограничены по размеру. Сначала это было ограничение в 100Мб, потом приняли решение ограничить размер одного файла до 1Мб, но не ограничивать количество файлов. И что же стали делать люди, которым нужно отправить 100-страничный скан рукописных тетрадей? Конечно же, паковать все в архивы, с разбиением на тома. 300 томов по 1Мб, да еще и загружать это полдня, стараясь не пропустить том, и не загрузить одно и то же два раза (потом же не откроется ничего). Гвозди из этих людей можно делать! Но вернемся к базам. Хранить файлы в базе — решение плохое, в том числе и потому, что файл будет вычитан куда? Правильно. В память. А убирается он кем? Правильно. Сборщиком мусора. В результате на ровном месте получили тормозной и падающий по непонятным причинам хайлоад. Вот надо оно было?

Ошибка 2️⃣- Не учитывать поток пользователей
Сколько RPS (запросов в секунду) выдержит ваш сервис? А как вы это посчитали? Я был ответил — не знаю, никак не считал. Придут пользователи — разберемся. Пользователи пошли — начались ошибки. Тратя время на борьбу с ними, я все никак не мог прийти к мысли — а ведь можно было взять статистику за предыдущие годы и посчитать распределение аттестуемых по месяцам! В RPS это, конечно, никак не пересчитывается, но понять, даже примерно, к чему готовиться, и проверить приложение под нагрузкой перед его релизом возможность все же была.

Ошибка 3️⃣- Не собирать ошибки и метрики производительности
Это сейчас я знаю, что такое Sentry, ELK, Jaeger и т. д., а в то время анализ ограничивался постулатом «раз не пишут, значит, и проблем нет». А если проблемы были — сначала нужно было ошибку воспроизвести, потом исправить, и потом воспроизвести еще раз, чтобы провалидировать ее исправление. А уж про метрики производительности говорить даже не буду. До сих пор никто не знает, сколько там операции с базой времени занимают.

Ошибка 4️⃣- Бэкапы
Классика. Ситуация: в 2 часа ночи вспомнил, что обещал с утра сделать фичу. Естественно, забыл про обещание напрочь. Выхода нет — надо делать, раз обещал. И что‑то в систему войти не получается, сейчас себе в базе пароль поменяю. UPDATE users set password = «mYp@$$w0rd»; Поменял, отлично, работаем. С утра звонок — люди не могут войти в систему. Ну я‑то вхожу, вот смотрите, набираю mYp@$$W0rd, и я внутри. И только потом дошло, что кто‑то забыл написать WHERE id = 123. Мем смешной, ситуация страшная, да. Но ничего страшного по итогу не случилось, все, кто хотел, сбросили себе пароль через почту, а меня попросили так больше не делать. А был бы бэкап — можно было бы восстановиться, пусть даже перенося пароли из другой БД скриптом.

Описанное выше — далеко не всё, но самое яркое и запоминающееся. В свое оправдание говорить ничего не буду, но опыт был полезным и позволил изменить свое отношение к работе — в частности, научиться рефлексировать и задаваться вопросом «а не делаю ли я сейчас какую‑то ерунду?».

➡️ Про ошибки коммуникации поговорим в следующем посте.

#expert