Почти три года назад мы запустили сервис для управления проектами, но без ошибок не обошлось. Делюсь опытом, чтобы на наши грабли больше никто не наступил.

Ошибка №1. Начали разрабатывать десктопное приложение на Electron

Electron – фреймворк с открытым исходным кодом для создания десктопных мультиплатформенных приложений с использованием языков JavaScript/HTML/CSS.

В 2018-2019 годах, когда мы начали разработку, экосистема Electron была достаточно маленькой, проект только начал обрастать комьюнити, библиотеками и Best Practice.

Столкнувшись с первыми трудностями сборки проекта в стеке Electron + Vue и победив их, мы думали, что сложнее проблем уже не будет. Но они начались при использовании нативных возможностей ОС.

Так как у нас трекер времени, нам нужно снимать экран, действия пользователя, сайты, на которых он сидит, и используемые приложения. Необходимо было дописывать модуль для трекинга самостоятельно на C++ и прибиндить его к Node.JS модулю.

Гайдов и мануалов по этому ещё не было, мы решили что не будем отказываться от этой функции, так как она была нашим конкурентным преимуществом на рынке и решили переписать все на C++ в связке с Qt. К счастью, удалось найти друга, который взялся за проект и реализовал его за пару месяцев.

Ошибка №2. Выбрали старые технологии

Изначально мы ориентировались на создание серьёзного проекта с интерактивными возможностями и полезными фичами. Выбрали стек технологий без полноценного современного фронтенда.

В прототипе мы использовали jQuery в связке с UI фреймворком Bootstrap 4. Как прототип сервис работал отлично, только показывать это миру было нельзя. Также такая тесная связка фронтенда с бэкендом сильно замедляла разработку продукта – мы тонули в багах и не успевали делать фичи.

Решили, что будем делать полноценный дизайн и искать в команду фронтендера. Жаль, конечно, эти 3 месяца работы над интерфейсом, но решение было принято ????

После jQuery и Bootstrap перешли на Vue.js – он нам показался удобным, текущая команда бэкендеров знала Vue, а мы могли спокойно провести собеседование на позицию фронтендера.

Ошибка №3. Не протестировали отчёты на большом объёме данных в PostgreSQL

Таблица логирования времени работы над задачей в таск-трекере строится из даты начала трекинга, даты окончания трекинга, активности пользователя, процесса прогресса и других сервисных полей. Мы не учли отрезки — данные, которые отправляются в систему с интервалом от 30 секунд до 5 минут.

На большом объёме данных агрегационные функции PostgreSQL показали себя достаточно плохо. Мы решили обработать их в Python, но это тоже не дало результата – запросы по-прежнему обрабатывались от 1-30 секунд в зависимости от объёма данных.

Проблему решили переходом на Clickhouse от Яндекса. Принципы построения таблиц отвечали нашему формату – удалось сократить время ответа с 30 секунд до 50 миллисекунд (если честно, я не знаю, как там это работает под капотом, сколько с командой не смотрели конференции и выступления по ClickHouse, ответ так и не получили, но результатом довольны). Визуально отчёт выглядит так:

А это код запроса после перехода (оказался кратно проще, если исчислять в количестве строчек кода):

Ошибка №4. Подходили к дизайну несистемно

Мы прошли 4 итерации дизайна, чтобы прийти к нынешнему внешнему виду сервиса. Сразу желаемого не добились, потому что мы не использовали системный подход. К работе мы привлекали веб-дизайнеров, которые до этого работали только с лендингами, маленькими сайтами и интернет-магазинами: им просто не хватало релевантного опыта.

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

По-прежнему не обходимся без ошибок при разработке новых интерфейсов — часто меняем и переделываем их на этапе проектирования, а при запуске отслеживаем фидбэк и оперативно исправляем недочёты. К фокус-группам и дополнительным исследованиям не обращаемся, A/B тесты не проводим.

Ошибка №5. Плохо настраивали мониторинг и слабо развивали инфраструктуру

С самого начала мы углубились в разработку и не уделили внимания инфраструктуре. Работал всего один сервер для всех сервисов: фронтенда, бэкенда, баз данных. Когда число клиентов выросло, мы столкнулись с проблемой масштабирования и поздно заметили проблемы с нехваткой мощностей сервера.

Раньше мы использовали только одну метрику — доступность сервера. Не проверяли нагрузку на него и оперативную память, поэтому время ответа доходило до 30 секунд (у нас так настроен таймаут). К тому же, 16 Гб оперативной памяти с задачей не справлялись.

Наша инфраструктура стоила приблизительно 500$ на Digital Ocean до февраля этого года, но в ближе к весне мы вынужденно переехали к другому хостеру. Долго присматривались к Selectel, который располагал SaaS-решениями для баз данных и удобного управления серверами, но дорого стоил.

Даже сделали сравнительную таблицу с ценами инфраструктуры Digital Ocean и Selectel при курсе доллара 90 на момент переезда.

Предложений лучше не нашли, решили, что нужно переезжать. Но сделать это качественно за две ночи нам одним было сложно: привлекли part-time dev-ops команду наших друзей. Благодаря им получилось перевезти инфраструктуру в Россию без затруднений.

Кроме того, мы настроили различные дашборды в графане для всех наших сервисов и серверов, а также подключили публичный BetterUptime и алертинг на инциденты. Выдали доступ юзерам для просмотра статуса, если появятся проблемы с Shtab. Теперь если что-то идет не так, команда знает об этом заранее.

Мораль

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

Сейчас мы стабильно работаем и периодически исправляем баги. Кстати, если поможете нам с поиском неточностей, будем рады: заходите к нам в Shtab.

Максим Стихарев

Технический директор Shtab