Пòuск:
Извините, вы уже голосовали за эту статью!
0
0 голосов
Ø
0 голосов
↓
Жалоба:
Статья добавлена 5 ноября 2012, в понедельник, в 23:43. С того момента...
2430 |
просмотров |
| 0 | добавлений в избранное |
| 0 | комментариев |
Представлена в разделах:
Top 5 àвтора:
Главная загадка Sphinx или как устроен поисковик.
Тема:
Хабрахабр, The Pirate Bay, avito.ru, Craigslist, Tumblr,Dailymotion — что у них общего? Оказывается все они используют один и тот же поисковый движок — Sphinx.
Этот продукт с исходным кодом разрабатывается командой талантливых ребят из разных городов и стран, однако началось все в городе Воронеже. Как устроен поиск и чем замечательны песни Depeche Mode, как зарабатывать на бесплатном продукте и как работать с людьми, не видя их лиц, — обо всем этом читателям расскажет создатель SphinxАндрей Аксенов.
300 миллионов поисковых запросов в сутки — ровно столько обращений к поиску приходится выдерживатьSphinx'y на крупнейшем в США ресурсе бесплатных объявлений Craigslist. Это самый большой известный нам пример использования нашего движка по количеству обрабатываемых запросов.
Из искры разгорелось что-то. Впрочем, как обычно — жизнь всегда большая череда случайностей. У меня был никому не интересный сайтик с коллекцией из 130 тысяч текстов песен, на котором не было поиска. Последний факт особенно возмущал, потому что когда по радио ты слышал какую-то песню, то улавливал пару-тройку слов, которые разбирал с пятнадцатого прослушивания, — но поискать по этим словам текст песни не было возможности. Я посмотрел, какие годные решения существуют для этого, — на тот момент таких не оказалось.
Передо мной стояли жесткие ограничения по железу. Сайт подпольным образом хостился у местного провайдера, в жестко ограниченном виртуальном частном сервере (jail в терминологии FreeBSD). В 128 Мб памяти и 200-300 Мб на диске нужно было уместить и базу, и поиск, и фронтенд, и все прочее.
Я попробовал использовать для этого mnoGoSearch — один из древнейших движков, написанных на C++. Он изначально предназначался для индексации веб-страниц, и механизм индексации базы у него был (в те годы) крайне дурацкий. Он делал кучу лишних запросов к базе и зверски тормозил на одном только этом. Плюс формат индекса на тот момент был просто адский. Индексировать базу было практически невозможно. Сто мегабайт индексировалось 24 часа — это же курам на смех!
Выхода не было, и я принялся хардкорно патчить mnoGoSearch. Оптимизировал использование диска временными файлами, оптимизировал выборку данных из базы.
В конце концов пришел к такому состоянию, что «патчу» больше не нужен и сам mnoGoSearch:).
Было важное требование: все должно было помещаться в определенные жесткие лимиты. То есть делаем вид, что мы — жуткие control freaks, контролируем вообще все. Прогнозируем, сколько памяти сожрем. Если сказано, что буфер памяти под индексацию должен быть восемь мегабайт, то ровно восемь мегабайт и должно быть — и мы из кожи вылезем, чтобы не использовать больше. Понятно что все это пришлось оптимизировать, чтобы втиснуться в лимиты, обусловленные физически — железом.
Еще один ключевой момент —с ранжированием тоже нужно было что-то делать. Ведь все песни состоят примерно из одинаковых семи слов — я, ты, он, она, вместе целая страна, я люблю тебя, ты люби меня. Плюс предлоги в разнообразных комбинациях.
Мой любимый пример из той эпохи — название песни Depeche Mode «I feel you». Просто классика. Каждое из этих слов встречается более чем в половине всей коллекции песен.
За счет этого стандартный статистический алгоритм ранжирования такую песню, в которой есть точная цитата — идеальное соответствие поисковой фразе, но повторяется она не часто, заранжирует глубоко вниз. То есть идеальное соответствие запросу окажется на самом дне выдачи. Зато песня, в которой все три слова повторяются очень уж много раз, окажется на самом верху.
Еще одно ключевое дизайн-решение заключалось в том, что близкие совпадения фраз нужно вытягивать вверх. Ранжировать выше, чем просто россыпь слов по документу. Это подсказал простой здравый смысл, когда я решал свои личные задачи. Я хотел, чтобы точная цитата из песни была вверху, и была там гарантированно. Стандартный, статистический метод ранжирования мне этого не давал — он смотрел только на частоты, но не смотрел на позиции слов.
Так появился новый поиск, который... несколько лет пролежал в столе. Я использовал его для личных целей, раздавал друзьям и знакомым, по их запросам вносил какие-то правки.
Один из таких пользователей оказался очень активным молодым человеком. Его зовут Петр Зайцев, он хорошо известен в узких кругах как основатель компании Percona, но в тот момент еще работал в MySQL. Он фактически заставил меня выйти из тени, сделать сайт, начать светиться на конференциях. В общем, рассказал мне о том, что проект по большому счету вышел годный, людям нужный, и практически принудил меня его выложить. За что ему большое спасибо, он сыграл немалую роль.
Благодаря ему я начал пилить Sphinx для проектов большего масштаба. Тут важно понимать одно дело, когда индексируешь сто мегабайт на личном сайте или пол гигабайта сообщений форума на «Тупичке»(oper.ru).
И совсем другой вопрос, когда тебе запиливают 50 Гб в 50 миллионах сообщений из блогов, которые откуда-то накраулили.
Десять лет назад 99% поисковиков были написаны исходя из следующего предположения: клиент хочет купить готовый набор скриптов, которые позволяли бы прицепить поиск на свой сайт. И чтобы робот дальше сделал за него все — обошел сайт, все документы выкачал, сложил в полнотекстовый индекс.
Sphinx не про это. Он не будет за тебя ходить по сайтам, он чисто про поиск. Предполагается, что данные у тебя уже есть, и откуда ты их взял — из базы данных или откуда-то еще, — уже не важно. Может быть, ты за меня сходил по интернету и накачал документы. Зато я умею их проиндексировать и быстро по ним искать.
С масштабированием тоже полный порядок. У нас есть две части: часть, которую я все еще считаю простой, и часть, которая куда сложнее. Когда нужно разложить данные на много серверов, возникают две проблемы. Как разложить и потом собрать их вместе?
Разложить— в нашей модели проблем нет. На один сервер положил конфигурацию, на которой написано «этот сервер тянет документы с номерами от 1 до 1 ООО ООО». На второй сервер положил конфигурацию от 1 ООО ООО до 2 ООО ООО. Все, задача индексации решена. Конечно, у тебя возникает зоопарк конфигов на разных серверах — их возможно как-то автоматизировать или положить под контроль версий... но это понятные и легкие технические трудности. А вот если бы поисковая система понятия не имела о слиянии результатов поиска, тебе пришлось бы в приложении писать массу идиотского кода: а давайте сходим ко всем серверам, соберем с каждого отклик, вместе их сольем, пересортируем по нужному условию сортировки... Из десяти серверов два не ответили? Давайте сходим опять. Естественно, это сделано в Sphinx,ведь мы должны помогать пользователю делать поиск, а не головную боль ему создавать. В какой-то момент это было хорошим отличием Sphinx от «врагов» типа Apache Solr (он тогда вообще не распределялся на несколько серверов).
КАК УСТРОЕН ПОИСК?
Последние несколько лекций на эту тему я начинал со слов: «Кто читал Библию, тот умеет делать поиск». Есть такая штука в массе разных изданий Библии, называется конкорданс: в самом конце для каждого слова за исключением предлогов и междометий, написано как минимум, на какой странице оно находится, а как максимум — дана и более точная позиционная информация (например, в каком стихе встречается). Это отличная ментальная модель поискового индекса. Он именно так и устроен.
Приведу пример: берем текст и строим так называемый инвертированный индекс. Что это такое? Это большой сортированный по алфавиту словарь, где для каждого слова прописан список документов, в которых оно встречается. Можно реализовать его даже
вручную в Microsoft Word! После этого мы достаточно быстро сумеем бинарным поиском найти нужное слово, прочитать эту строчку, где через запятую записан список номеров документов, и вот — мы их нашли. Это и есть модель примитивного полнотекстового поиска.
Однако нужно хранить не только номера документов, но еще и позиции слов в них. Позицию при этом можно записывать по-разному. То есть это может быть не просто номер слова от начала документа, но также номер поля, номер зоны. Для веб-поиска возможны еще атрибуты: скажем, не подкрашено ли слово жирным шрифтом или красным цветом. В случае с языками с развитой морфологией (типа русского) может оказаться неплохой идеей также указать и форму слова.
Потом возникает и чисто технический вопрос — не будешь же ты, в самом деле, вордовый документ читать? Данные нужно сохранить бинарно, хорошо пожать, чтобы они жрали поменьше места, а поиск работал быстрее. Получается вот такая структура данных.
Есть также два принципиально конфликтующих параметра: скорость и качество. Требование «нужно максимально быстро отдать результат» — это одно. А качество поиска — это уже другое требование. Качество поиска — это штука, которой серьезно на данный момент занимаются только веб-поисковики. Google, Yandex и так далее. Нам, конечно, тоже хочется этим заниматься, но силенок пока не очень хватает.
Что нужно, чтобы сделать мегаскорость? Грубо говоря — максимально ловко пожать список документов, так чтобы можно было максимально быстро его разжать, прочитать и выплюнуть в программу. Все. Это одно требование. А второе требование, противоречащее этому первому, — не просто «найти» документы, но отранжировать, переставить их наиболее качественно.
Представь, что тебе нужно не просто максимально быстро обработать этот список, но обработать его осмысленно. Нужно выплюнуть не 3000 результатов поиска в произвольном порядке (или, например, в порядке возрастающего идентификатора документа), а в том порядке, какой пользователь считает релевантным. Отдельный фокус здесь заключается в том, что нет единого понятия релевантности.
Для одной и той же пары «запрос и документы» разные люди могут сказать разное. Когда лично я ищу слово «sphinx», меня, скорее всего, интересует мой собственный вебсайт. А если я «руссо туристо облико морале» и я захожу на страницу Google с египетского IP-адреса, то вряд ли меня волнует поисковый сервер. Вероятнее всего, мне нужно узнать, когда ближайший тур на песчаном багги до этого самого сфинкса отходит из моего отеля.
Казалось бы — один и тот же документ, один запрос, но для двух разных людей они имеют очень разный вес. Запрос может быть одинаковым, но так называемая информационная потребность — разная. Поэтому товарищам, у которых эта информация есть (то есть веб- гигантам вроде Google или Яндекс), приходится угадывать информационную потребность пользователя по всяким другим сигналам — IP-адресу, языку в браузере, истории поисков истории показа объявлений, просмотрам сайтов и так далее. В той мере, в какой они до таких данных могут дотянуться, конечно.
ПОСЛЕДНИЕ НЕСКОЛЬКО ЛЕКЦИЙ ОБ УСТРОЙСТВЕ ПОИСКА Я НАЧИНАЛ СО СЛОВ: «КТО ЧИТАЛ БИБЛИЮ, ТОТ УМЕЕТ ДЕЛАТЬ ПОИСК»
ФОРМУЛА ВМ25
Качество поиска, если говорить, очень упрощая, — это усредненная степень счастья каждого отдельного пользователя. В идеале: я коряво формулирую свою информационную потребность, а поисковая машина «делает магию» — угадывает по всем явным и не очень сигналам, какой же именно документ мне дико нужен, и возвращает именно его. Таких сигналов приходится анализировать довольно много. Но Open Sourceпоисковики обычно анализируют крайне мало.
Некоторое время назад у меня вообще была присказка — мол, типичный Open Source поисковик (да и не только Open Source) для ранжирования использует всего один фактор. Общепринятую статистическую функцию ВМ25, которая смотрит на частоты слов в коллекции (настолько они частые или редкие) и на частоты слов в конкретном документе.
Формулу ВМ25 придумали где-то в 80-х, а в начале 2000-х довольно тривиальным образом расширили, чтобы уметь взвешивать документы о многих полях и назначать этим полям разный вес.
Но есть проблема: ВМ25 вообще не смотрит на взаимные позиции слов. То есть три слова, как угодно размазанные по документу, и три слова, которые стоят рядом и образуют точную
фразу, не отличаются вообще никак. И десять лет назад это не устраивало даже меня.
Думаю, даже большинство коммерческих поисковиков использует ее до сих пор. Несмотря на полное игнорирование позиций, формула достаточно качественная. Тем не менее в коммерческих проектах неустанно работают над новыми технологиями, заодно продвигая науку. Если незатейливую реализацию ВМ25 сравнить с теми сложными формулами ранжирования которые там крутятся, естественно, она даст худшие результаты. Но она достаточно неплоха.
По сути, ВМ25 — это сумма частоты слова (TF), умноженной на IDF — относительную частоту слова в коллекции, для каждого слова в запросе. Это опять на пальцах, потому что на самом деле там запрятано еще несколько передаточных коэффициентов, которые демпфируют, сглаживают частоты и смотрят на длину документа. Скажем, у тебя есть документ, в котором слово встретилось один раз, и есть другой документ, где оно встретилось сто раз. Зато какое-то другое, в десять раз более редкое слово, встретилось там чаще. Если просто перемножать такие метрики — будет плохо. Слишком большое количество вхождений более плохого (менее редкого) слова сильно заспамит результат. Поэтому TF засовывается под логарифм.
Что за TF, IDF? IDF значит inverse document frequency, обратная частота документа — метрика того, насколько слово редкое. Если оно максимально редкое — встречается всего раз на всю коллекцию, то метрика максимизируется и стремится к единице. Если наоборот — встречается в каждом документе, метрика минимизируется и стремится к нулю. Чем реже слово, тем лучше его IDF. Когда всего один документ на всю твою коллекцию из миллиона или миллиарда — это хорошо. Есть еще одна тупая метрика — TF (termfrequency). Частота слов в текущем документе, который ты обрабатываешь То есть сколько вхождений этого слова вообще есть. Просто посчитать.
Но давай разберем, как работает запрос из двух слов. Что он должен делать, чтобы исполниться и отранжировать результаты, при помощи классической частотной функции ВМ25? Это работает так: берем список документов по одному слову. Он отсортирован по возрастанию номера документа. Берем второй список. Бежим по обоим спискам одновременно и выбираем те документы, у которых номер совпал. Просто пересекаем два списка. Получаем третий список — это все документы в которых есть два наших ключевых слова. Осталось их отранжировать. То есть посчитать ту или иную функцию ранжирования, например ВМ25.
Как это сделать?
Для этого нужно заранее, в момент построения индекса, рядом с каждым номером документа, в списке документов (на который из словаря есть указатель), положить не только номер, но и число вхождений этого слова в этот документ, TF. А в самом словарике положить не только слово и указатель на список документов, но еще и сравнительную частоту этого слова во всей коллекции, IDF.
Для этого нужно заранее, в момент построения индекса, рядом с каждым номером документа, в списке документов (на который из словаря есть указатель), положить не только номер, но и число вхождений этого слова в этот документ, TF. А в самом словарике положить не только слово и указатель на список документов, но еще и сравнительную частоту этого слова во всей коллекции, IDF.
Она тоже рассчитывается в момент индексации текста. Мы читаем с диска вдвое больше данных, когда бежим по двум спискам и пересекаем их. При пересечении мы не смотрим на TF (частоты), но после того, как у документов совпали номера, — у нас и частоты есть. У нас есть TF — из списка документов, и есть IDF — из словарика. Мы просто перемножаем их, складываем и все. Задача решена.
Берем запрос и считаем такое число: сколько слов мы можем оставить в запросе, чтобы выходить на отдельно взятый документ Понятно, что единицу мы насчитаем всегда — хоть одно слово должно совпасть. А если у нас два слова стоят в запросе рядом и абсолютно такая же цитата встречается в документе, значит наш фактор близости равен двум. Или, формально, длина наибольшей общей подпоследовательности равна двум. Соответственно, чем больше это число, тем выше в выдаче будет стоять документ. Максимизируется степень близости тогда, когда в документе есть точное совпадение для нашего запроса. Дефолтная формула ранжирования до сих пор такая, но с тех пор ситуация у нас еще немного улучшилась и будет улучшаться дальше.
Фактор близости работает немного сложнее, чем ВМ25. Чтобы его посчитать, не отделаешься пред рассчитанным числом слов. Тут нужно не просто хранить список документов, но хранить тот факт, что в документе номер 123 слово «Вася» встретилось в позициях 10, 20 и 30. А слово «Петров» в этом же документе встретилось в позициях 11,48 и 92. И нужно не только выяснить, что пара номеров 123 и 123 совпала для слов «Вася» и «Петров» и поэтому оба слова есть в документе номер 123 и он удовлетворяет запросу «Вася Петров». Еще после этого нужно пробежаться по всем позициям первого и второго слова в этом документе и посмотреть — о, а в этом месте они у нас стояли рядом. Ништяк. Это же совпадение фразы. Давайте этот факт у себя отметим и используем при ранжировании как одну из переменных. В литературе это называется факторами или сигналами.
В принципе, все текстовые факторы при ранжировании опираются на это. Они всегда рассчитываются по позициям и прочей привязанной информации. Если слово было написано жирным —теоретически поисковик может это использовать. Мы не используем, но теоретически — сделать можно.
Для ранжирования существует ряд факторов. Две категории — текстовые и вне текстовые. Текстовые — мы обнюхиваем позиции и привязанную к ним информацию и по этим позициям делаем всякие выводы. На самом деле — считаем всякие статистические штучки Типа что такое TF? Это просто сумма числа позиций. Что такое IDF? Это тоже статистическая штука, но только заранее посчитанная по всей коллекции. Можно еще всякий смешной фарш смотреть — на близость смотреть, что LCS (Longest Common Subsequence) хороший. Можно и более умные факторы придумать, которые смотрят на близость слов. Все, что связано с текстом запроса и документа, в конечном итоге сводится к разнообразным методам обнюхивания позиций и прочей метаинформации, которую мы сохранили.
Но еще есть вне текстовые факторы. Тот же page rank, который у всех на слуху. Что это такое? Это фактор, не имеющий ни малейшего отношения к тексту запроса и документа. Это некий коэффициент, который показывает, насколько хорошо на этот сайт и на эту страницу ссылаются извне. Просто некий факт, который привязан к номеру документа, к этому номеру 123 в списках для слов «Вася» и к той же самой единичке, что привязана к слову «Петров».
Упорядочивание результатов может опираться на посчитанную релевантность, а может на более сложные факторы. К примеру сначала на новостном сайте идут все результаты за последний год, какими бы плохими сточки зрения релевантности они ни были, а после — все, что старше года, сортируется по релевантности. Вполне корректный и разумный метод упорядочивания результатов, пользователям может нравиться.
У нас в Sphinx в один прекрасный момент еще появилась такая штука — считалка выражений. Можно написать произвольное арифметическое выражение, и она его посчитает. Она довольно быстрая по замерам — местами в десятки раз быстрее той, что встроена в MySQL. И возникла следующая чудная идея — прикрутить ее тоже к ранжированию. Я написал специально скриптуемый ранкер, такую функцию ранжирования, которая считает несколько всяких факторов по тексту запроса и документа и дает тебе произвольно их смешать в твоей собственной формуле. С его помощью можно тестировать собственные формулы ранжирования, описывая их прямо в поисковых запросах.
Формула ранжирования, которую можно таким образом описать, — это комбинация нескольких факторов, «кубиков». Один из факторов — это бессмертная ВМ25 — как без нее? Можно и просто учитывать количество совпавших слов в каждом конкретном поле, другие частотные факторы, типа минимальной и максимальнойIDF. Есть и еще более хитрые факторы, типа позиции первого наилучшего совпадения в данном поле, или там максимума числа слова, совпавших в скользящем окне заданной ширины. Мы сами придумали считать примерно с пол десятка факторов, и еще часть запросили пользователи Итого сейчас там где-то 12 разных, местами довольно странных факторов, и со временем будет только больше, — и вот их можно как угодно скомбинировать и построить из них свою собственную, сколь угодно сложную формулу ранжирования.
ЗАРАБОТАТЬ НА OPEN SOURCE
Очень сложно оценить количество внедрений нашего движка. В случае с Open Source продуктом этого никогда не знаешь. Можно приблизительно ориентироваться по числу закачек, считать пропорции и так далее. Сейчас я оцениваю количество установок в десятки или даже сотни тысяч. Разумеется, не каждая закачка в итоге превращается в установку, но, думаю, десять тысяч разных сайтов мы уже точно пробили. Сто тысяч? Может быть. Миллион? Вряд ли.
Был эпизод, когда я узнал, что Sphinx используется на The Pirate Вау. Это, конечно, антиреклама с точки зрения корпоративных пользователей, но факт показательный. С каким-то апдейтом мы сломали что-то неочевидное внутри Sphinx, и один из этой банды написал нам. То есть я вступил в переписку с каким-то человеком и только на пятом e-mail обратил внимание на домен, с которого он пишет. Так и узнал.
К счастью или к несчастью, почти все торрент-сайты мира используют Sphinx. The Pirate Вау вот использует. Mininova, пока ее не засудили и не закрыли, крутилась на нем. RuTracker тоже, говорят. Никогооттуда лично не знаю, но «птички» летают.
Кстати, Craigslist, который впереди всех по количеству поисковых запросов, — не самый большой по объему индексируемых данных. Есть ряд проектов типа BoardReader, Social Radar и еще некоторых, которые индексируют с помощью Sphinx более 20 миллиардов документов каждый. Думаю, суммарно все проекты, использующие Sphinx, уже перевалили за 100 миллиардов документов и за 1 миллиард запросов в день. Так что мы миллиардеры!
У крупного проекта масса потребностей. И я не удивлюсь, если внутри Google, Facebook и Yahoo! используетсяSphinx. Понятно, что не для поиска на «морде», но для какой-то мелкой задачи, вроде поиска по багтрекеру вот этой конкретной группы — почему нет, решение работает, и все хорошо.
ЗАРАБОТАТЬ НА OPEN SOURCE
Sphinx, видимо, был достаточно неплох даже на начальной стадии, так что свою умеренную популярность он снискал сразу. Определенный интерес и легкий трафик были изначально Не было такого, что я выложил его, а потом в течение трех лет смотрел: «о, сегодня ко мне один человек за день зашел, а завтра — гигантский прорыв, уже трое!»
О деньгах речи сначала и не шло. Поначалу мотивация была проста — давайте выложим, ведь MySQLвыложил, и мы выложим, вдруг что-то получится. А потом, через какое-то не очень большое время, Sphinxдействительно начал приносить деньги.
Сейчас у нас три основных источника дохода. Это лицензирование, заказы на разработку фич от клиентов и консалтинг.
Первые деньги появились, когда Петр Зайцев показал Sphinx клиенту и тому очень понравилось, но понадобилась дополнительная функция. Речь шла о языке запросов.
До этого Sphinx умел искать все слова сразу или хотя бы одно слово в документе. Были так называемые режимы матчинга, до сих пор в движке и API прослеживаемые. То есть Sphinx искал все слова из запроса, любое слово, фразу и... кажется, все. А клиенту нужно было кое-что посложнее и поинтереснее чтобы с булевыми операторами, с произвольной вложенностью скобок и так далее. Вот это была первая большая коммерческая разработка. Конечно, помимо этого им еще потребовалось много разного, но язык запросов стал одной из самых крупных и заметных фич. В Open Source версию это, конечно, вошло тоже.
С тех пор так и повелось: клиент говорит — очень хочется иметь такую-то фичу. И хочется ее побыстрее, а не когда вы ее там сделаете сами по себе. Ну, мы и делаем, чего уж:).
Для меня это были первые существенные деньги, но они пришли не за консалтинг по настройке, а за разработку. И до сих пор значительную часть денег наша компания зарабатывает не на консалтинге, а на разработке.
А вообще список подобных «бесплатных», внутренних фич-реквестов у меня и сейчас на 200 позиций как минимум. Там все — от крохотных затычек до больших, интересных кусков функционала.
За лицензирование платят клиенты, которые встраивают Sphinx и не хотят открывать свои исходники.Дело в том, что вся наша кодовая база доступна под лицензией GPL, поэтому даже коммерческому проекту пришлось бы публиковать изменения под этой же лицензией. Это не всем удобно.
Давайте сравним MySQL с Oracle и Red Hat с Microsoft. Сразу понятно, что если цель —
заработать максимальное количество бабла, лучше не стартовать Open Source проект вовсе Не известен пока еще ни один Open Source проект, который жил бы сильно лучше коммерческих аналогов в той же нише. Тем не менее какие-то доходы с этого у нас есть, сделки довольно разнообразны, это интересно, и для нас это была единственная реально доступная модель на старте.
РАСПРЕДЕЛЕННАЯ КОМАНДА
Исторически сложилось так, что у нас распределенная команда. Если бы я сразу нанял всех нужных людей в городе-герое Воронеже и всем было бы удобно ходить в офис, то у нас сейчас был бы мегаофис разработки в Воронеже. Ну и, очевидно, отдельный офис продаж в США. Но сложилось иначе. Каждого нового подручного мы нанимали в новом городе.
Мы изначально росли органически, без накачки инвестиционными деньгами. Вот потихоньку выросли до десятка человек и собираемся расти еще. Но я пока не чувствую необходимости брать инвестиции, чтобы акселерировать рост бизнеса. Ну знаете, если по-русски, у меня нет ситуаций вроде: «упс, третий месяц нечем платить зарплату».
География у нас обширная: Воронеж, Краснодар, Новосибирск, Сиэтл, Бойсе. Еще Питер и, кажется, Саранск. Я, по-моему, кого- то забыл... точно, у меня где-то записано очень длинное название румынского города, где у нас сидит европейский консультант!
Сейчас у нас четыре с половиной разработчика и два сейлза (оба в США). Почему четыре с половиной? Есть четыре матерых и сильных разработчика и один, скажем так, стажер — но лично мне-то приходится заниматься совсем не только разработкой. Так что людей-то выходит пять, потому что со мной, но разработчиков четыре с половиной получается, потому что регулярно без меня.
Общаемся электронно — e-mail, Skype и IRC на ежедневной основе. Понятно, что если кого-то где-то нет, а он срочно нужен — сотовый телефон никто не отменял, и мы будем дозваниваться и искать. Но такое требуется редко.
Людей мы постоянно ищем. С этим, как и везде в IT, вообще настоящая беда. Open Source в этом никак не помогает, скорее даже вредит. У меня есть теория, что люди думают: батюшки-светы! — какие-то сложные C++ коды, какой-то человек-программист говорит на конференциях зажигательные но непонятные слова, еще удаленная работа, как это вообще... да их там, наверное, палкой бьют, за руку к батарее приковывают и вообще у них наверняка офиса нету! И пугаются даже резюме прислать. Такая теория. На самом деле у нас все куда более приятно и демократично, не говоря уж об интернационале — думаю, Адам, Адриан, Алексей, Антон, Глория, Евгений, Илья, Ричард и Станислав подтвердят.
Я ПОКА НЕ ЧУВСТВУЮ НЕОБХОДИМОСТИ БРАТЬ ИНВЕСТИЦИИ.У МЕНЯ НЕТ СИТУАЦИЙ ВРОДЕ: «УПС, ТРЕТИЙ МЕСЯЦ НЕЧЕМ ПЛАТИТЬ ЗАРПЛАТУ»Хакер
11(166)2012
Источник: IT-шникам
В тèму:
