🎙Спрашиваем Алексея:

❓Лёша, ты Lead Software Developer в Salmon, ты больше 10 лет в профессии, и у тебя есть опыт разработки и фронтенда, и бэкенда. Расскажи, пожалуйста, подробнее о своём опыте и о своём пути в IT?

💬 Осознанный путь я начинал как Python-разработчик и на фронтенде в то время использовал только vanilla-технологии. Тогда я работал в чём-то вроде НИИ и пришлось ещё поработать с Qt, C++, OpenCV, настраивать полнотекстовый поиск в чате. В какой-то момент дали задачу переписать приложение с Angular на Vue, и это перевернуло моё понимание фронтенда, показалось очень интересным, и я стал уходить в это направление. Перешёл в Rambler, где переводил приложение с XSLT на React и получил классный опыт о том, как надо следить и катить продукт, которым пользуются миллионы пользователей. Потом поработал в X5 в команде внутреннего финансового продукта как full-stack и много вынес по работе с финансовыми данными, базами данных и огромными объёмами данных. И в итоге сейчас работаю в Salmon, где уже начал работать с Next.js и очень критичными требованиями к надёжности систем и сервисов.

❓Твой доклад о надёжности и отказоустойчивости сервисов. Самые ценные уроки обычно приходят после факапа. Можешь рассказать про инцидент, после которого вы с командой что-то серьёзно поменяли в архитектуре или процессах — без имён и подробностей, только урок?

💬 Самый показательный пример того, как важно быть не «исполнителем задач», а «решателем проблем», у меня такой: пришла задача — надо сделать выгрузку финансового отчёта в Excel. Думаю: ну тут просто делаем запрос в БД, раскидываем в документ, отдаём пользователю. Делаю, проверяю локально — всё ок, деплой, всё хорошо, деплой в прод... К нам приходят финансисты и говорят, что у нас всё плохо, ничего не работает. Начинаем проверять и понимаем: оказывается, на проде намного больше данных, и при выгрузке миллионов строк в Excel мы падаем по памяти. Начали быстро делать что-то вокруг этого и обрабатывать в стримах с батчевой отдачей, но это было медленно и пользователям приходилось долго ждать, оставаясь на странице. В итоге мы полностью поменяли флоу работы с отчётами: сделали обработку через очереди RabbitMQ и отдельный сервис формирования отчётов. Пользователь просто запрашивал отчёт, а мы уведомляли о том, что как только сформируем — пришлём ссылку на скачивание на почту или пуш о готовности, — таким образом не заставляя пользователей ждать. Конечно, сделали ещё логи и мониторинг на критичные части системы.

❓Что посоветуешь почитать / посмотреть / послушать по теме отказоустойчивости, SRE, производительности?

💬 Конечно же, «книгу с кабанчиком» — для понимания построения систем. Очень советую просто погуглить «как устроена архитектура X», где X — это название любого сервиса: Netflix, YouTube и пр. Во-первых, это часто можно встретить в секции System Design на собеседовании, во-вторых, там можно посмотреть, какие подходы используют сервисы для надёжности и отказоустойчивости. Для меня самым ценным ресурсом было общение и работа с DevOps-инженерами и архитекторами.

Ищите Алексея в LinkedIn и приходите 4 июля! Будем общаться и холиварить. 😎