на каком языке написан nginx

nginx

nginx (англ. engine x ) (по-русски произносится как э́нджин-и́кс [4] [5] ) — веб-сервер и почтовый прокси-сервер, работающий на Unix-подобных операционных системах (тестировалась сборка и работа на FreeBSD, OpenBSD, Linux, Solaris, Mac OS X, AIX и HP-UX). Начиная с версии 0.7.52 появилась бинарная сборка под Microsoft Windows.

Содержание

Основные функции

nginx — простой, быстрый и надёжный сервер, не перегруженный функциями. Применение nginx целесообразно прежде всего для статических веб-сайтов и как прокси-сервера перед динамическими сайтами. [источник не указан 151 день]

HTTP-сервер

SMTP/IMAP/POP3-прокси сервер

Архитектура

В nginx рабочие процессы обслуживают одновременно множество соединений, мультиплексируя их вызовами операционной системы select, epoll (Linux) и kqueue (FreeBSD). Рабочие процессы выполняют цикл обработки событий от дескрипторов (см. Событийно-ориентированное программирование). Полученные от клиента данные разбираются с помощью конечного автомата. Разобранный запрос последовательно обрабатывается цепочкой модулей, задаваемой конфигурацией. Ответ клиенту формируется в буферах, которые хранят данные либо в памяти, либо указывают на отрезок файла. Буферы объединяются в цепочки, определяющие последовательность, в которой данные будут переданы клиенту. Если операционная система поддерживает эффективные операции ввода-вывода, такие как writev и sendfile, то nginx применяет их по возможности.

Конфигурация HTTP-сервера nginx разделяется на виртуальные серверы (директива server). Виртуальные серверы разделяются на location’ы (location). Для виртуального сервера возможно задать адреса и порты, на которых будут приниматься соединения, а также имена, которые могут включать * для обозначения произвольной последовательности в первой и последней части, либо задаваться регулярным выражением.

location’ы могут задаваться точным URI, частью URI, либо регулярным выражением. location’ы могут быть сконфигурированы для обслуживания запросов из статического файла, проксирования на fastcgi/memcached сервер.

Для эффективного управления памятью nginx использует пулы. Пул — это последовательность предварительно выделенных блоков динамической памяти. Длина блока варьируется от 1 до 16 килобайт. Изначально под пул выделяется только один блок. Блок разделяется на занятую область и незанятую. Выделение мелких объектов выполняется путём продвижения указателя на незанятую область с учётом выравнивания. Если незанятой области во всех блоках не хватает для выделения нового объекта, то выделяется новый блок. Если размер выделяемого объекта превышает значение константы NGX_MAX_ALLOC_FROM_POOL, либо длину блока, то он полностью выделяется из кучи.

Таким образом, мелкие объекты выделяются очень быстро и имеют накладные расходы только на выравнивание.

nginx содержит модуль географической классификации клиентов по IP-адресу. В его основу входит база данных соответствия IP-адресов географическому региону, представленная в виде Radix tree (сжатое префиксное дерево или сжатый бор) в оперативной памяти. nginx предварительно распределяет первые несколько уровней дерева, таким образом, чтобы они занимали ровно 1 страницу памяти. Это гарантирует, что при поиске IP-адреса для первых нескольких узлов при трансляции адреса всегда найдётся запись в TLB.

Популярность

Безопасность

Источник

На каком языке находятся файлы nginx conf?

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

например, возможно ли для меня иметь unless состоянии?

3 ответов

Итак, я новичок в nginx, и у меня был тот же вопрос. Оказывается, синтаксис языка, как упоминалось выше, является как пользовательским, так и на самом деле довольно простым. Синтаксис захвачен в разделе в документах NGINX и повторяется здесь для удобства:

nginx состоит из модулей, которые управляются директивами указано в файле конфигурации. Директивы подразделяются на простые директивы и директивы блока. Простая директива состоит из имя и параметры, разделенные пробелами и заканчивающиеся точкой с запятой (;). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после набора дополнительных инструкции, окруженные фигурными скобками (< и >). Если директива block может есть другие директивы внутри фигурных скобок, это называется контекстом (примеры: события, http, сервер и местоположение).

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

остальная часть строки после знака # считается комментарием.

в итоге: все в конфигурационном файле NGINX является директива который может ссылаться на переменная. Все директивы в алфавитном порядке здесь и все переменные перечислены в алфавитном порядке здесь. Конфигурация NGINX управляется модули что каждый реализует определенную часть функциональности, и каждый модуль вклад директивы и переменные, которые становятся доступными для использования в конфиге. Вот и все.

надеюсь, что это помогает!

файлы nginx conf пишутся на их собственном языке или синтаксисе. Я включил некоторые основы ниже. Это мои личные заметки, взятые из Освоение Nginx

основной формат

основной файл разбит на разделы

Глобальные параметры

Не определен в стандарте описано выше формат, он не имеет <> категории общий раздел. Он помещается в верхней части конфигурации файл

важные глобальные параметры

user-пользователь и группа, которые запускаются рабочими процессами. Если группа опущена, это равно тому, что пользователь использовал

error_log-расположение error_logs. быть перезаписанным в директивах. Второй парам указывает уровень отладки журнала (доступен только при настройке мод отладки при компиляции), info, notice, warn, error, crit, alert и emerg.

pid-файл, в котором записан идентификатор основного процесса, перезаписывающий скомпилированный по умолчанию.

использование include files может использоваться в любом месте файла конфигурации

включить /opt/local/etc/nginx / mime.типы;

в пути может появиться подстановочный знак, соответствующий нескольким файлам: включить /opt / local/etc/nginx/vhost/*.conf;

файл конфигурации можно легко проверить, вызвав NGINX следующим образом: nginx-t-c

раздел Http будет наиболее часто используемым разделом.

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

Источник

Интервью с создателем NGINX Игорем Сысоевым

— Игорь, расскажите, как строилось ваше образование, как пришли к программированию и вообще увлеклись компьютерами?
Я родился в Казахстане в маленьком городке. Когда мне было около года, моего отца (он военный) перевели в Алма-Ату, и я жил там до 18 лет. В 1987 году я закончил школу и поехал поступать в МВТУ имени Баумана, однако с первого раза поступить не удалось, и я вернулся назад в Алма-Ату, где устроился работать лаборантом в филиал Института повышения квалификации Министерства геологии СССР. Там были старые компьютеры «Искра-226», на них я и начал что-то программировать на Бейсике. А еще в то время в журнале «Радио» была опубликована серия статей, как собрать собственный компьютер «Радио-86РК», и благодаря их чтению у меня сложилось достаточно неплохое представление, как компьютер устроен и как он работает. А первый опыт работы с компьютерами был чуть раньше: в старших классах я ходил во Дворец пионеров, и там поставили компьютеры Yamaha КУВТ (стандарта MSX). Помню, когда набирал первую программку, перепутал единицу с буквой I. В общем, она у меня не работала из-за таких вещей.

— А помните свою первую программу, которой пользовались другие люди?
Моя первая крупная и отчуждаемая программа — это антивирус «AV», который я написал в 1989–1990 годах. Написан он был полностью на ассемблере, объем ассемблерного кода был где-то порядка 100 КБ. Программа умела находить несколько вирусов, имея зашитую внутрь программы базу с несколькими сигнатурами известных тогда в СССР вирусов, которых было от силы штук десять: вирусы «Марихуана», «София», «Вена» и еще несколько, не помню их названий. Вот это и была моя первая программа, которую я распространял в бинарниках — исходников я тогда не раздавал. В итоге она разошлась по стране, была установлена даже на нескольких заводах. Была и обратная связь: люди по почте слали письма с вирусами, записанными на дискеты. Какое-то время я поддерживал данный антивирус, но в итоге году в 1992-м я уже потерял интерес к этой теме, и программа умерла.
В 1994 году я закончил институт, а за год до этого начал работать системным администратором в одной компании, которая была связана с торговлей нефтепродуктами. Там я проработал почти 7 лет, после чего в апреле 2000 года я решил уйти. Тогда как раз сдулся NASDAQ, лопнул «пузырь дот-комов», и как раз в этот момент я решил уйти в Интернет. Полгода я проработал в интернет-мазагине XXL.RU, после чего, как сейчас помню, 13 ноября 2000 года я пришел работать в Рамблер.

— Чем вы занимались в Рамблере?
Я работал системным администратором. Однако кроме непосредственной работы сисадмина я снова начал в свободное время писать программы. Надо отметить, что в мои должностные обязанности программирование не входило, но поскольку были время и тяга, то первое, чем я занялся, — адаптировал патч для сжатия ответов Apache. К сожалению, на тот момент имя mod_gzip было уже занято, поэтому я назвал свой вариант mod_deflate, работал он с Apache 1.3.
Потом меня попросили разобраться с модулем mod_proxy. Я его посмотрел и решил, что проще написать все с нуля, чем адаптировать там какие-то вещи. Таким образом появился модуль mod_accel — модуль и набор патчей для Apache для реверсного проксирования. Это все тоже было весной 2001 года.
— То есть все эти модули вы делали для Рамблера, одновременно выкладывая в паблик?
— В основном, да. Mod_deflate на самом деле пришел из патча, который писал Дмитрий Хрусталев, работая в РБК. То есть этот патч был взят за основу, там моего кода, может, половина только.
Осенью 2001 года у меня появилась идея написать более легкий и производительный веб-сервер, чем Apache. На тот момент были уже другие похожие серверы, но все они не умели проксировать, они отдавали только статику. Был у них еще один общий недостаток – они работали в одном процессе, и, соответственно, отмасштабировать их, допустим, на двухпроцессорной машине было нереально.
На тот момент у меня уже был достаточно неплохой опыт работы с Apache — и как у системного администратора, и как у программиста. Два написанных модуля прибавили мне знаний: приходилось смотреть исходники Apache и понимать, как там все устроено. Поэтому очень многие вещи в nginx перекочевали из Apache идеологически. Не код, а именно идеология, весь код nginx был написан с нуля.
Однако не все мне нравилось в Apache: например, там очень легко можно сделать такую конфигурацию, которую будет крайне сложно поддерживать. То есть сайт растет, добавляется какая-то новая функциональность, и в конце концов работать с сайтом становится невозможно. Нужно что-то добавить, и ты сидишь, думаешь: «А что у меня сломается от того, что я добавлю?» В nginx я попытался этих вещей избежать. В общем, где-то весной 2002 я начал разрабатывать nginx.

— Быстро ли о ваших разработках узнали внешние по отношению к Рамблеру люди? Как эволюционировал проект?
В 2003 году про мои разработки прознали снаружи Рамблера, и, более того, nginx начал использоваться на нескольких сайтах. Первым был эстонский сайт знакомств Rate.ee, который и сейчас существует. Это, кстати, самый высоконагруженный сайт Эстонии. Потом nginx начал использоваться на mamba.ru и на zvuki.ru, где раздавал MP3.
В начале 2004 года Рамблер запускал сервис foto.rambler.ru, и один из коллег, Олег Бунин, попросил меня доделать в nginx функциональность проксирования запросов, чтобы начать полноценно использовать его в том числе на фотосервисе Рамблера. До этого момента проект был достаточно академическим, я его постепенно писал, но это могло никогда ничем не кончиться, то есть в продакшн его, может быть, нигде и не поставили бы. В общем, получилось так, что я срочно доделал и проксирование. И где-то в начале 2004 года появилась версия с проксированием, а сервис foto.rambler.ru заработал на базе nginx.
4 октября 2004 года, в очередную годовщину запуска первого космического спутника, я выпустил первую публичную версию: 0.1.0.

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

— Так что, никакого продвижения вообще не было, получается, продукт сам себя сделал?
С моей стороны никакого специального пиара не было. Хотя есть такое мнение, что лучший пиар — это просто хороший продукт. То есть весь рост обуславливался тем, что nginx «просто работал», и люди рассказывали о своем положительном опыте знакомым админам, те — своим знакомым, и так по принципу сарафанного радио. Популярность nginx, на мой взгляд, связана с несколькими вещами. Во-первых, это эффективный и бесплатный софт, который позволяет существенно экономить аппаратные ресурсы и денежные средства, во-вторых, он в принципе неплохо работает.

— Но есть же аналоги, lighttpd тот же самый, например.
На самом деле есть еще пара причин: получилась довольно интересная комбинация жизненно важных фич для создания эффективной веб-инфстраструктуры, которые я добавлял постепенно и которые сделали nginx таким незаменимым инструментом. При этом nginx не перегружен ненужными фичами и остается очень компактной разработкой. Кроме того, модульность nginx позволила многим компаниям и сторонним разработчикам строить свои расширения на базе ядра nginx. Можно сказать, что nginx давно стал в своем роде веб-платформой.
По поводу lighttpd (lighty). Когда-то он был более распространен, чем nginx, и более известен в мире. Его автор — немец Ян Кнешке (Jan Kneschke). Разница в популярности была связана с тем, что Россия — непонятная страна с балалайкой и медведем, снегом, а тут Европа. Опять же, и с английским у него лучше было, в том числе и с английской документацией. Кстати, благодаря lighttpd обрел второе дыхание протокол FastCGI. До 2000–2001 годов это была экзотика, все использовали интерпретаторы, которые были внутри Apache: PHP, Perl, Python. А поскольку в lighttpd исполнять внутри процесса PHP-код нереально, то решением стал FastCGI. И именно благодаря lighttpd FastCGI обрел вторую жизнь. Хотя еще в 2000 году люди говорили: «Зачем, что это такое — FastCGI? У нас есть mod_php, и там все прекрасно работает».

— Какие главные кейсы использования nginx вы видите сейчас?
Основное использование на нагруженных сайтах — это проксирование. При этом nginx установлен в качестве фронт-энда и проксирует приложения на бек-эндах по HTTP либо по FastCGI или WSGI. При этом стандартным подходом является использование в связке с Apache — например, на моем предыдущем месте работы nginx долгое время работал именно так, только пару лет назад переключились на использование FastCGI. Кстати, в этом случае в статистике отображается, что появляется nginx, пропадает Apache. Хотя на самом деле используется и то и другое: просто nginx является одним из компонентов прокси-системы, видимым снаружи.

— Объясните наглядно, зачем вообще проксировать запросы?
Почему, собственно, люди используют Apache с nginx? Казалось бы, зачем тут лишнее звено, которое будет мешать. Apache хорошо и легко использовать там, где нужно выполнение какого-то приложения, например, с помощью mod_php. Вот теперь представьте себе, что этот PHP способен генерировать 100 ответов в секунду, а каждый ответ имеет размер, условно, 100 КБ. Не все клиенты используют быстрые соединения: 10 лет назад были модемные клиенты, сейчас очень распространен мобильный Интернет, у кого-то просто плохой провайдер или медленный тариф. И вот у нас есть ответ объемом 100 КБ и эффективная скорость к клиенту, например, 80 Кб/с (10 КБ/с). Значит, этот ответ будет передаваться клиенту 10 секунд. В результате все это время, пока клиент медленно скачивает ответ, Apache вместе с PHP «жрет» 10–20 МБ памяти на одного клиента. И вместо того, чтобы заниматься тем, что Apache может делать быстро, он ждет, пока медленные клиенты загрузят ответы. На все это расходуется очень много памяти, да и процессор тоже. Когда мы ставим nginx между клиентами и Apache, то все начинает работать эффективнее: nginx максимально быстро принимает на себя весь ответ, освобождая Apache, и потом уже медленно отдает его клиентам, не расходуя много памяти. Много памяти или процессора nginx не расходует, потому что используется другая архитектура веб-сервера — неблокируемая, основанная на асинхронной обработке событий, что позволяет обрабатывать многие тысячи соединений в рамках одного процесса (в отличие от Apache, где каждое соединение обрабатывается отдельным процессом или тредом. — Прим. ред.).
Ну и плюс к этому мы можем с бек-энда вынести все статические файлы, это простая вещь, с которой nginx может справиться очень легко и максимально эффективно — таких статических файлов nginx может отдавать одновременно десятки тысяч в секунду, если память позволяет, и если позволяет сетевое соединение с сервером.

— Давайте вернемся к типовым сценариям.
Итак, первый сценарий — это когда мы просто занимаемся акселерированием, может быть, даже одного-единственного сайта. У нас был Apache, мы поставили перед ним nginx и — бах! — случилось чудо. Люди реально ставят и удивляются, а потом пишут на «Хабр» о том, что «надо же, как клево». Второй вариант — это тоже проксирование, но у нас много бек-эндов, то есть мы можем эффективно масштабировать горизонтально всю систему при условии, что само приложение это позволяет. Таким образом, nginx выступает в роли балансировщика нагрузки. Одним из недостатков текущей реализации является отсутствие нескольких политик балансировки, но люди пользуются, это работает, а функционал мы будем добавлять. Что еще? Еще сценарий, например, такой: многим людям почему-то Apache не нравится. Хотят, чтобы на сервере был только nginx, не хотят ставить Apache. В этом случае все скрипты у них работают через FastCGI для PHP или WSGI для Python.
Например, WordPress.com — они давным-давно начали использовать nginx в качестве балансировщика, а веб-сервером у них выступал коммерческий LiteSpeed. В этом году они уже полностью мигрировали на nginx, теперь у них PHP работает в режиме FastCGI.
Другой стандартный вариант использования — когда nginx просто отдает всю статику, допустим, MP3, FLV-, MPEG4-видео, картинки.

— Давайте немного поговорим про безопасность. Были ли за время существования nginx какие-либо серьезные уязвимости?
Уязвимости были разные, но проблем с тем, чтобы с их помощью получить удаленный доступ, код выполнить — такого не было. Можно было ронять рабочие процессы, но вот именно исполнить код — таких уязвимостей не было. Смотрите, обычно эксплоит рассчитан на что? Мы чего-то записали в сервер, ему это дело упало на стек. Сервер работает, делает возврат и попадает на этот код. Соответственно, чтобы эксплоит заработал, надо знать, где стек будет у этого процесса. Как правило, когда есть какой-нибудь пакет Debian/Ubuntu, есть бинарник, можно воспроизвести у себя аварийную ситуацию, попытаться найти, где находится этот стек и таким образом сделать эксплоит. Как стали с этим бороться? Стали рандомизировать адресное пространство — в современной винде, например, это так работает.

— ASLR?
Да, верно. Это рандомизация. У нас стек был тут, а теперь стал вот тут. И, соответственно, мы не можем предугадать, то есть мы взяли пакет, а понять, где у него теперь стек, не получится. У nginx в этом плане проще, потому что на стеке данных, которые читаются от клиентов, практически нет. Можно пересчитать по пальцам несколько случаев, где это используется, но в этих местах код довольно надежен. Данные, получаемые от клиентов, nginx размещает «в куче», выделяя память malloc’ом.
Соответственно, если туда записать где-то чуть побольше, то мы не попадем на указатель стека. Вот эта рандомизация в nginx присутствовала с самого начала. В общем, написать рабочий эксплоит если и можно, то очень сложно. Кроме того, процессы, которые занимаются обработкой запросов, не работают от «рута».
Security-advisory были, их можно посмотреть на сайте. Я считаю, что на все эти сообщения об ошибках нужно реагировать адекватно, спокойно и профессионально. Например, скрывать факт бага, когда все уже опубликовано, говорить типа «Что? Ничего не было, все хорошо» — это просто-напросто подрывает доверие к проекту.

— Сколько человек занималось раньше и занимается сейчас разработкой, развитием проекта?
Долгое время занимался я один, практически весь код я написал в одиночку. Года четыре назад мне стал все больше помогать Максим Дунин. Кроме нас двоих еще по мере развития продукта люди присылали патчи. Причем часто присылают просто письма с текстовым описанием проблем или пожелания. Мне говорят: «Есть ошибка, решить можно ее вот так». Просто словами. Мы это делаем по мере сил.
Еще у нас сейчас есть отдельный человек — Руслан Ермилов, который сейчас занимается документацией. Он выполняет несколько задач: это перевод текущей русской документации на английский язык, актуализация сведений и адаптация документации, чтобы она была понятна и однозначна для людей, впервые ее читающих. Частая проблема, когда автор пишет документацию, у него в голове есть определенный контекст, и он отталкивается от него. Думает, что вот это само собой разумеется, а в итоге упускает много деталей. С этим мы как раз активно боремся: Руслан смотрит на nginx «со стороны», свежим взглядом, поэтому способен писать так, чтобы всем все было понятно. Кроме того, у Руслана огромный опыт участия в разработке и документировании сложных программных проектов.

— Предлагаю перейти к вопросам, связанным с компанией Nginx, Inc. и с тем, как вы вообще пришли к созданию бизнеса.
Сейчас все расскажу. Итак, наверное, году в 2008-м пришло мне первое письмо от инвестора, я уже не помню даже, кто это был. В общем, за последние два года таких писем было около десятка. Люди хотели что-то сделать с nginx, сделать компанию. Но я отказывался, поскольку я в целом не особо бизнесмен. Но в конце концов я стал понимать, что что-то делать нужно, иначе я просто не смогу дальше в одиночку развивать проект, уже не хватало сил на все. Довольно много времени ушло на то, чтобы осмыслить, как и с кем я хотел бы сделать компанию «вокруг» nginx. Вообще, я очень редко меняю направление жизни: например, до Рамблера я семь лет работал в одной компании, в Рамблере я тоже проработал десять лет. Перемены для меня тяжелы. Но, тем не менее, к весне этого года я все-таки окончательно решил основать компанию, которая бы помогла дальнейшему развитию проекта. Отчасти на этот шаг меня вдохновил Сергей Белоусов, создатель Parallels и фонда Runa Capital. Мы с ним несколько раз неформально общались, и в итоге я постепенно стал значительно ближе к идее создать компанию.

— Сергей умеет убеждать, да?
Сергей вообще очень интересный человек, с ним всегда увлекательно обсуждать дела и не только, он очень энергичный человек. Сергей также довольно властный руководитель – я думаю, он влияет на очень многие решения в своих компаниях, это владелец, который любит контролировать происходящее, непосредственно участвовать в бизнесе.
Вообще, процесс переговоров с инвесторами, подписание условий сделки, куча всего — это вещь тяжелая, потому что, во-первых, очень много скучных деталей, огромное количество бумаги на английском языке, юридической, ее на русском-то языке читать тяжело, а по-английски — тем более. Обговаривание всего, опять же, согласование всех вещей: мы хотим то-то, они хотят то-то. Психологически это тяжело. Зато потом, если инвесторы понимают твой бизнес, все становится значительно легче.

— Интересно: вы работали в Рамблере и трудились над nginx. У Рамблера не было никаких прав? Это такой тонкий вопрос. Как удалось сохранить права на проект?
Да, это довольно тонкий вопрос. Он, конечно, интересует не только вас, и мы довольно основательно его проработали. В России законодательство устроено так, что компании принадлежит то, что сделано в рамках трудовых обязанностей либо по отдельному договору. То есть должен быть договор с человеком, где было бы сказано: нужно разработать программный продукт. В Рамблере я работал системным администратором, разработкой занимался в свободное время, продукт с самого начала выпускался под лицензией BSD, как открытое программное обеспечение. В Рамблере nginx начал применяться уже тогда, когда основной функционал был готов. Более того, даже первое применение nginx было не в Рамблере, а на сайтах Rate.ee и zvuki.ru.

— Кто еще у вас работает в компании Nginx?
Еще у нас работает Сергей Будневич — системный администратор, он занимается поддержкой инфраструктуры компании. Инфраструктура у нас не очень большая, но она есть. У нас есть списки рассылки, у нас есть почтовый сервер, автоматическая сборка, тестирование пекеджей, трэкинг ошибок и др. Сергей нам с этим очень помогает. Мы сейчас собираемся готовить пакеты еще для нескольких Linux-дистрибутивов: CentOS, Ubuntu. Сергей занят автоматизацией разнообразных процессов, связанных с разработкой, тестированием и сопровождением. Есть еще два человека: один человек занимается маркетингом — Андрей Алексеев, а Максим Коновалов — вообще начальник всего, он делает так, что компания работает.

— А как официально называется ваша должность в компании?
Формально я — технический директор. Я не умею руководить людьми, я больше фокусируюсь на архитектуре будущих продуктов и передаче разработки «в команду». Довольно тяжело делегировать работу, однако компания создавалась как раз с целью улучшить разработку и продукт, поэтому сейчас я пытаюсь себя этому научить. Коллеги занимаются организационными вопросами, общением с клиентами, маркетингом, отношениями с партнерами, документацией, наймом персонала и др. Разных сложностей у нас много, научиться общаться на разных уровнях — это бывает не так легко. На самом деле мы все участвуем во всех делах компании, поскольку компания не такая большая, а дел много.

— Делегировать было сложно, потому что казалось, что все плохо делают, проще самому?
Ну да, подход такой, что я лучше это сам сделаю, потому что это будет лучше, или потому что долго объяснять, что нужно делать, или психологически тяжело сказать: «Сделай вот это». Лично мне делегировать полномочия было тяжело по ряду причин. Сейчас, как технический директор, я в основном отвечаю за архитектуру и качество разработки.

— Игорь, большое вам спасибо за интервью! Видно, что вы все-таки научились делегировать: со всеми нашими бизнес-вопросами вы нас отправили к Максиму Коновалову.
Кстати, это первое интервью, которое я даю. Согласился только из-за того, что создали компанию. Буквально весной меня попросили люди из другого ИТ-издания, я сказал им: «Извините, я не люблю, не хочу и не умею».

— Еще раз спасибо! Максим, в переговорах с инвесторами вы представляли какой-то формализованный бизнес-план? На чем вы вообще планируете зарабатывать деньги?
В основном фонды инвестировали в nginx как в очень перспективный продукт. Детальный бизнес-план, конечно, был важен, но американские инвесторы подходят к вопросу инвестиций, базируясь не только и не столько на бизнес-плане, где будет написано, что мы заработаем за год столько-то с точностью до десятков центов. Важно было то, что nginx сейчас очень популярен, это уже готовый, существующий продукт.
По поводу того, что у нас за идеи для зарабатывания денег: мы хотим, прежде всего, добиться правильного баланса между бесплатным и платным функционалом. Мы хотим сделать то, что не совсем удалось в прошлом целому ряду компаний. Есть несколько примеров бизнеса на базе разработок open source, где компании не смогли удержать нужный баланс, пришлось закрывать какие-то фичи в самом продукте, просить за них какие-то нелепые деньги, это всех расстроило, и продукты перестали развиваться.

— То есть вы хотите сделать отдельный коммерческий продукт и найти баланс между открытым продуктом и коммерческим?
Мы не хотим делать отдельный коммерческий продукт, мы хотим делать коммерческие надстройки над основным продуктом open source. Он будет развиваться, будут появляться фичи, которые требуются сообществу. Деньги, которые мы получили, помогут нам поставить все производство продукта на новый уровень. Сейчас Игорь уже не в одиночку работает над кодом, строится командная разработка. Мы принимаем на работу людей в России, инженерная команда в Москве останется.
Соответственно, фокус на продукте open source — он очень сильный и будет оставаться таким.
В то же время, мы знаем, что есть клиенты, большие компании, средние компании, даже маленькие компании, которые долгое время используют nginx. Они построили на этом бизнес и благодарны нам. Когда мы встречаемся, то слышим что-то вроде: «Отличный, замечательный продукт — спасибо вам большое! Но нам не хватает того-то и того-то. Можете ли вы это сделать — мы вам готовы платить?» Из таких разговоров у нас постепенно складывается цепочка того, что мы могли бы продавать, не огорчая при этом сторонников продукта free open source и не подрывая доверия к проекту в целом. Т. е. мы собираем подобные запросы и сравниваем их с пожеланиями, которые поступают от сообщества пользователей. Мы смотрим, где есть пересечения, и если понимаем, что какой-то функционал на самом деле необходим всем, а не какой-то отдельной компании, мы это реализуем в бесплатной версии продукта.
Есть даже компании, которые говорят: «Давайте мы вам заплатим за все эти фичи, чтобы они быстрее появились в продукте. Мы хотим, чтобы все попало в open source, мы не хотим, чтобы фича была эксклюзивная и/или платная». Это называется sponsored development.

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

— То есть у вас фокус именно на продукте. Не будете отдельно продавать услуги, например, по внедрению, консалтингу?
Дело в том, что компания маленькая, она будет оставаться маленькой — расти до компании в несколько сотен человек мы не хотим. Мы активно работаем с партнерами, с системными интеграторами, с вендорами софта и железа, активно ищем каналы для работы через партнеров. Консультации будут осуществляться частично через партнеров, частично через нас. К сожалению, услуги консалтинга и технической поддержки всем пользователям мы сами, непосредственно, предоставлять не сможем.

— А что ждет обычных пользователей в ближайшее время, планируете какие-то новые фичи?
Из истории изменений в коде за последние три месяца, из списка релизов, которые мы выпустили, видно, что с момента образования компании мы серьезно активизировали процесс разработки и внесения исправлений. Мы интегрировали достаточно много и доработок, и новых опций. Добавили, к примеру, стриминг MP4, о котором Игоря спрашивали несколько лет. Работа идет, функционал развивается.

— Я правильно понимаю, что Игорь Сысоев — главный акционер компании, а остальная, меньшая, доля принадлежит инвесторам?
Да, Игорь — основной акционер, всего же учредителей компании трое, и есть, естественно, инвесторы как владельцы, группа инвесторов — они совместно владеют какой-то частью. Кстати, сам процесс получения денег от инвесторов технически выглядит очень просто — выпускаются ценные бумаги по соответствующему законодательству, инвесторы их покупают за какую-то сумму. Сумма переходит к вам, вы ее используете на развитие компании. Именно так все у нас и устроено.

Журнал Хакер, Декабрь (12) 155.

Источник