Разработка SaaS-проекта глазами девелопера и менеджера

Часть первая, девелоперская

Как написать высоконагруженный, многофункциональный проект вдвоём? Что делать, если нет денег и времени, а открываться нужно? Под катом немного интересной информации из личного опыта.

Компания у нас небольшая (из города Минска), но гордая, поэтому было принято решение разрабатывать сервис, значительно упрощающий жизнь при ведении интернет-сайтов.

Так как дни веб-мастера тяжелы и неказисты, то на реализацию было заявлено много функционала, а именно:

• проект должен тянуть каждую неделю whois информацию по всем существующим доменам (планируется более 300 млн.)
• хранить у себя всю whois информацию по всем доменам вместе с историей изменений;
• уведомлять об окончании срока регистрации доменов и хостинга ^[1];
• осуществлять мониторинг сайтов минимум раз в 3 минуты и минимум из 6-ти стран (красиво отображать время, коды ответов и графики с этим всем делом по каждой стране);
• проверять сайт на наличие в чёрных списках, а также на присутствие вредоносной гадости;
• управлять финансами с добавлением транзакций затрат/прибыли по сайтам (опять же, с графиками);
• управлять заметками, с возможностью добавления меток и прикрепления файлов;
• уведомлять клиентов посредством e-mail и sms, согласно пользовательским настройкам;
• прикрутить интересную партнёрскую программу со скидочными купонами и ссылками;

В общем, нужно было написать Dominder ^[2]!
Полезный, интересный, перспективный проект, даже амбициозный, но вот незадача — мало времени и ресурсов. Разработчиков целых два (второй только через 3 месяца после начала разработки подключился).

Заказали за бугром крутой, импортный дизайн. Писать решили на Ruby on Rails, в качестве основной БД выступил PostgreSQL.

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

Решение номер Раз

На качество реализации frontend-а решили забить, слово рефакторинг он даже и не слышал, будем его потихоньку допиливать — главное, чтобы клиентов ничего не напрягало.

Решение номер Два

Т.к. времени нет, то тот или иной способ реализации выбирается исходя из параметров:

• временные затраты;
• масштабируемость;
• (текущее количество пользователей в системе) реализация должна держать.

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

Решение номер Три

Параллельно с разработкой велся пиар продукта. Как это происходило.
Выстраивается 2 «потока планирования»: разработки и пиара. Они должны наполняться равномерно исходя из текущих потребностей проекта и возможностей на его текущую реализацию. Например, если готов какой-то функциональный кусок проекта — он сразу же тестировался, обкатывался и популяризировался. Либо, если текущее количество пользователей меньше прогнозируемого — то сначала разрабатывались красивые фенечки для клиентов (например, демо аккаунт), а уже второстепенным шла оптимизация текущих алгоритмов. И наоборот, если клиенты начали приходить валом — всё бросали и начинали сурово кодить. Получались своеобразные качели, но по-другому, по-моему, никак.

Решение номер Четыре

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

Решение номер Пять

Ввиду того, что историю пингов нужно хранить бесконечно долго — все записи жмутся в «архивы» согласно алгоритму отображения в графиках.

Решение номер Шесть

Использование собственного самописного прокси-сервера, для вытягивания whois от регистраторов. Некоторые из них поначалу просто банили ip из-за очень частых обращений. В итоге удалось получать информацию для полумиллиона доменов в день. Не предел, но на доработку просто не было времени.

Решение номер Семь

Всё, к чему нужен быстрый, частый доступ, беспощадно пихается в NoSql.

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

Часть вторая, менеджерская

После запуска проекта встал вопрос о привлечении пользователей.
Тот же мониторинг сайтов на Западе уже давно популярен и им пользуются миллионы пользователей. А вот объяснить нашему, советскому пользователю, что проще, выгоднее и удобнее заплатить $5.50 в месяц и иметь возможность сразу узнать, что что-то произошло с сайтом, оказалось довольно трудной задачей. Многие так и не поняли, что мониторинг сайтов (да и другие наши услуги) – это как страховка. Хорошо, если ничего не случилось. А если произойдёт?

Мы для тестов добавили 140 белорусских сайтов, большинство из которых хостятся в Беларуси. В итоге оказалось, что порядка 40% сайтов хотя бы раз в неделю перестаёт быть доступным (на срок от 5 минут до нескольких часов). А некоторые сайты просто дико колбасятся и явно теряют своих клиентов.

Конечно, в России есть такой грозный конкурент, как Яндекс.Метрика (и у меня довольно часто спрашивают, в чём наши отличия). Но Метрика, бывает, не сразу присылает уведомления (бывает, запаздывают на час или два), не проверяет доступность сайтов из разных стран, не гарантирует мониторинг в некоторых случаях и необходимо устанавливать дополнительный код на свои сайты.

Имея ограниченные ресурсы после открытия нашего проекта, мы стали действовать своими силами по всем фронтам: e-mail маркетинг, партнёрская программа, партнёры в виде хостинг-компаний и веб-студий и т.д.

На сегодняшний день наши пользователи добавили в свои аккаунты примерно 114 тысяч доменов. Естественно, не все из них платные, но тем не менее. В день формируются и отправляются тысячи уведомлений.

За полгода бета-тестирования плохих отзывов о нас я не встретил (может потому, что мы в то время были бесплатным?). Некоторые блогеры и даже крупные порталы размещали обзоры нашего проекта на бесплатной основе.

Имея большой опыт работы с сайтами (8 лет и были времена, когда у меня было до полутысячи сайтов), могу сказать в итоге, что Dominder действительно полезен и автоматизирует многие процессы, сокращает время на поддержку своих сайтов и избавляет от головной боли во многих случаях.

Наш проект: ru.dominder.com/ ^[3]
Демо: ru.dominder.com/?demo ^[4]

Автор: YSPRO

Источник ^[5]