Как написать высоконагруженный, многофункциональный проект вдвоём? Что делать, если нет денег и времени, а открываться нужно? Под катом немного интересной информации из личного опыта.
Идея разработать проект, облегчающий жизнь при ведении интернет-сайтов, пришла в голову небольшой компании из Минска. Команда у нас небольшая, но амбициозная, поэтому было принято решение разрабатывать столь масштабный проект вдвоем.
Так как дни веб-мастера тяжелы и неказисты, то на реализацию было заявлено много функционала, а именно:
В общем, надо было написать «Dominder» (от англ. domain + reminder).
Полезный, интересный, перспективный проект, но вот незадача — мало времени и ресурсов. Разработчиков целых два (второй только через 3 месяца после начала разработки подключился).
Заказали за бугром крутой, импортный дизайн. Писать решили на Ruby on Rails, в качестве основной БД выступила PostgreSQL.
Начали искать компромиссы и технические решения, благодаря которым реализацию с текущими материальными ужимками можно воплотить в жизнь.
На качество реализации frontend-арешили забить времени потратили меньше, чем хотелось бы. Будем его потихоньку допиливать — главное, чтобы клиентов ничего не напрягало.
Т.к. времени нет, то тот или иной способ реализации выбирается исходя из параметров:
Порой, скрипя зубами, приходится писать тот или иной кусок кода, лишь потому, что так быстрее. Криво, некрасиво, но эффективно и гибко.
Параллельно с разработкой велся пиар продукта. Как это происходило.
Выстраивается 2 «потока планирования»: разработки и пиара. Они должны наполняться равномерно исходя из текущих потребностей проекта и возможностей на его текущую реализацию. Например, если готов какой-то функциональный кусок проекта — он сразу же тестировался, обкатывался и популяризировался. Либо, если текущее количество пользователей меньше прогнозируемого — то сначала разрабатывались красивые фенечки для клиентов (например, демо аккаунт), а уже второстепенным шла оптимизация текущих алгоритмов. И наоборот, если клиенты начали приходить валом — всё бросали и начинали сурово кодить. Получались своеобразные качели, но по-другому, по-моему, никак.
Whois информация о всех доменах доступна через публичные страницы, которые постоянно, беспощадно индексируют боты поисковиков. Страницы были закэшированы, а домены, которые не относятся к текущим клиентам, вынесены на отдельный сервер (так называемый вертикальный шардинг).
Ввиду того, что историю пингов нужно хранить бесконечно долго — все записи жмутся в «архивы» согласно алгоритму отображения в графиках.
Использование собственного самописного прокси-сервера, для вытягивания whois от регистраторов. Некоторые из них поначалу просто банили ip из-за очень частых обращений. В итоге удалось получать информацию для полумиллиона доменов в день. Не предел, но на доработку просто не было времени.
Всё, к чему нужен быстрый, частый доступ, беспощадно пихается в NoSql.
После запуска проекта встал вопрос о привлечении пользователей.
Тот же мониторинг сайтов на Западе уже давно популярен и им пользуются миллионы. А вот объяснить нашему, советскому человеку, что проще, выгоднее и удобнее заплатить несколько долларов в месяц и иметь возможность сразу узнать, что что-то произошло с сайтом, оказалось довольно трудной задачей. Многие так и не поняли, что мониторинг сайтов (да и другие наши услуги) – это как страховка. Хорошо, если ничего не случилось. А если произойдёт?
Для тестов мы добавили 140 белорусских сайтов. В итоге оказалось, что порядка 40% сайтов хотя бы раз в неделю перестаёт быть доступным (на срок от 5 минут до нескольких часов). А некоторые сайты просто дико колбасятся и явно теряют своих клиентов.
Конечно, в России есть такой грозный конкурент, как Яндекс.Метрика (и у меня довольно часто спрашивают, в чём наши отличия). Но Метрика, бывает, не сразу присылает уведомления (бывает, запаздывают на несколько минут), нет возможности проверки доступности сайтов из разных стран, не гарантирует мониторинг в некоторых случаях и необходимо устанавливать дополнительный код на свои сайты.
Имея ограниченные ресурсы после открытия нашего проекта, мы стали действовать своими силами по всем фронтам: e-mail маркетинг, партнёрская программа, партнёры в виде хостинг-компаний и веб-студий и т.д.
В итоге после всех ужимок и прыжков мы открылись и начали получать первый профит, при этом испытывая ребяческую радость от каждого вновь зарегистрированного пользователя.
Идея разработать проект, облегчающий жизнь при ведении интернет-сайтов, пришла в голову небольшой компании из Минска. Команда у нас небольшая, но амбициозная, поэтому было принято решение разрабатывать столь масштабный проект вдвоем.
Так как дни веб-мастера тяжелы и неказисты, то на реализацию было заявлено много функционала, а именно:
- проект должен тянуть каждую неделю whois информацию по всем существующим доменам (планируется более 300 млн.)
- хранить у себя всю whois информацию по всем доменам вместе с историей изменений;
- уведомлять об окончании срока регистрации доменов и хостинга;
- осуществлять мониторинг сайтов минимум раз в 3 минуты и минимум из 6-ти стран (красиво отображать время, коды ответов и графики с этим всем делом по каждой стране);
- проверять сайт на наличие в чёрных списках, а также на присутствие вредоносной гадости;
- управлять финансами с добавлением транзакций затрат/прибыли по сайтам (опять же, с графиками);
- управлять заметками, с возможностью добавления меток и прикрепления файлов;
- уведомлять клиентов посредством e-mail и sms, согласно пользовательским настройкам;
- прикрутить интересную партнёрскую программу со скидочными купонами и ссылками;
В общем, надо было написать «Dominder» (от англ. domain + reminder).
Полезный, интересный, перспективный проект, но вот незадача — мало времени и ресурсов. Разработчиков целых два (второй только через 3 месяца после начала разработки подключился).
Заказали за бугром крутой, импортный дизайн. Писать решили на Ruby on Rails, в качестве основной БД выступила PostgreSQL.
Начали искать компромиссы и технические решения, благодаря которым реализацию с текущими материальными ужимками можно воплотить в жизнь.
Решение номер Раз
На качество реализации frontend-а
Решение номер Два
Т.к. времени нет, то тот или иной способ реализации выбирается исходя из параметров:
- временные затраты;
- scalability;
- (текущее количество пользователей в системе) реализация должна держать.
Порой, скрипя зубами, приходится писать тот или иной кусок кода, лишь потому, что так быстрее. Криво, некрасиво, но эффективно и гибко.
Решение номер Три
Параллельно с разработкой велся пиар продукта. Как это происходило.
Выстраивается 2 «потока планирования»: разработки и пиара. Они должны наполняться равномерно исходя из текущих потребностей проекта и возможностей на его текущую реализацию. Например, если готов какой-то функциональный кусок проекта — он сразу же тестировался, обкатывался и популяризировался. Либо, если текущее количество пользователей меньше прогнозируемого — то сначала разрабатывались красивые фенечки для клиентов (например, демо аккаунт), а уже второстепенным шла оптимизация текущих алгоритмов. И наоборот, если клиенты начали приходить валом — всё бросали и начинали сурово кодить. Получались своеобразные качели, но по-другому, по-моему, никак.
Решение номер Четыре
Whois информация о всех доменах доступна через публичные страницы, которые постоянно, беспощадно индексируют боты поисковиков. Страницы были закэшированы, а домены, которые не относятся к текущим клиентам, вынесены на отдельный сервер (так называемый вертикальный шардинг).
Решение номер Пять
Ввиду того, что историю пингов нужно хранить бесконечно долго — все записи жмутся в «архивы» согласно алгоритму отображения в графиках.
Решение номер Шесть
Использование собственного самописного прокси-сервера, для вытягивания whois от регистраторов. Некоторые из них поначалу просто банили ip из-за очень частых обращений. В итоге удалось получать информацию для полумиллиона доменов в день. Не предел, но на доработку просто не было времени.
Решение номер Семь
Всё, к чему нужен быстрый, частый доступ, беспощадно пихается в NoSql.
После запуска проекта встал вопрос о привлечении пользователей.
Тот же мониторинг сайтов на Западе уже давно популярен и им пользуются миллионы. А вот объяснить нашему, советскому человеку, что проще, выгоднее и удобнее заплатить несколько долларов в месяц и иметь возможность сразу узнать, что что-то произошло с сайтом, оказалось довольно трудной задачей. Многие так и не поняли, что мониторинг сайтов (да и другие наши услуги) – это как страховка. Хорошо, если ничего не случилось. А если произойдёт?
Для тестов мы добавили 140 белорусских сайтов. В итоге оказалось, что порядка 40% сайтов хотя бы раз в неделю перестаёт быть доступным (на срок от 5 минут до нескольких часов). А некоторые сайты просто дико колбасятся и явно теряют своих клиентов.
Конечно, в России есть такой грозный конкурент, как Яндекс.Метрика (и у меня довольно часто спрашивают, в чём наши отличия). Но Метрика, бывает, не сразу присылает уведомления (бывает, запаздывают на несколько минут), нет возможности проверки доступности сайтов из разных стран, не гарантирует мониторинг в некоторых случаях и необходимо устанавливать дополнительный код на свои сайты.
Имея ограниченные ресурсы после открытия нашего проекта, мы стали действовать своими силами по всем фронтам: e-mail маркетинг, партнёрская программа, партнёры в виде хостинг-компаний и веб-студий и т.д.
В итоге после всех ужимок и прыжков мы открылись и начали получать первый профит, при этом испытывая ребяческую радость от каждого вновь зарегистрированного пользователя.