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

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

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

Проблематика хостинг-услуг

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

Итак, что же волнует пользователей хостинга? Доступность веб-сайта (надежность, отказоустойчивость), скорость работы, цена. Большинство при этом особое внимание может уделять цене, вынося её на первый план, как по объективным так и по субъективным причинам. И потому самая большая проблема, как для новичков, так и для продвинутых веб-мастеров — выбор тарифного плана.

Выбор тарифного плана

Этот выбор может оказывать значительное влияние на взаимоотношения между провайдером и вебмастером в ходе сотрудничества. И речь не о том, что у некоторых хостинг-провайдеров отношение лучше к тем, кто платит больше (воздержимся от дачи оценок таким случаям, статья не об этом), а о том, как легко допустить ошибку из-за неопытности и сэкономить лишнее, тем самым спровоцировав конфликтную ситуацию в дальнейшем, а она несомненно будет. Начинающие вебмастера зачастую искренне обижаются на провайдеров за письма о повышенной нагрузке, пишут гневные отзывы в Интернете. Через это проходил наверное каждый, в том числе и мы. Свято верят, что сайт, практически лишенный посещаемости, не может создать такой проблемы. И они правы! Потому как слишком не опытны и еще не могут знать, что система управления сайтом (CMS), отягощенная множеством модулей, да еще и не оптимально настроенная, может создавать значительное потребление. Либо потому как не догадываются, что провайдер с целью охвата большего количества потенциальных клиентов, мог создать слишком недорогой тарифный план, рассчитаный разве что на небольшую домашнюю страничку.

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

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

Выход?

На протяжении нескольких лет мы искали его. Мы обеспечили низкую цену на хостинг не за счет низкого лимита на ресурсы, оградили себя от спамеров и недобросовестных клиентов за счет ввода невыгодной для них системы тарификации, когда услугу выгодно заказывать исключительно на долгосрочный период, что лишено смысла в случае темных целей. Значительно повысили стабильность услуги без сложных технических решений, тысяча клиентов создавала не более 1 запроса в тех. отдел за сутки, минимизировали возможные конфликтные ситуации. Решения и результаты были подробно изложены в нашей статье от 2012-го года «Стабильный хостинг — миф или реальность?».

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

Ввод четкой тарификации потребления CPU / RAM / IOPS / BANDWIDTH, как на облачных сервисах, увы, не стал бы ответом и решением. Рядовых веб-мастеров не волнуют и не должны волновать эти параметры, их волнует только посещение их сайтов и их волшебная работа. Так почему не начать тарифицировать ресурсы исключительно в том, в чем измеряется доход вебмастеров, в посетителях?

Постановка задачи: ресурсы CPU / RAM / IOPS практически не ограничиваются, учитывается только трафик (посещаемость)

Результатом стала постановка задачи реализации принципиально нового хостинг-сервиса, которого не существовало на рынке ранее, где учитывается только посещаемость, фактически трафик, так как между этими параметрами есть четкий и понятный коэффициент. Для примера возьмем 100 ГБ трафика, много это или мало? Для визуализации в посетителях возьмем средний размер веб-страницы 700 КБ, количество просмотров — результат деления трафика на усредненный размер веб-страницы, к примеру для 100 ГБ трафика получаем 100*1024*1024/700 = 149 796,57 просмотров. Таким образом, если средний размер страниц Вашего веб-сайта будет меньше, к примеру составлять 200 КБ, а не 700, Вы можете получить гораздо больше просмотров — 100*1024*1024/200 = 524 288, и наоборот. Разумеется, что эти значения нужно воспринимать исключительно, как ориентировочные. Они не учитывают служебный трафик, трафик потребляемый поисковыми системами и паразитный трафик, который может появится и исчезнуть в любой момент.

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

Требования и проблемы

Отсутствие тарификации и явного ограничения CPU / RAM / IOPS предъявляет особые требования к оборудованию и архитектуре решения. Наша задача обеспечить максимально быструю и бесперебойную работу всех сайтов веб-хостинга. А это значит, что решение должно быть построено на основе нод с максимально возможной производительностью и при этом быть распределенным с целью повышения надежности, обеспечивать возможность масштабирования.

Так как современные многопроцессорные решения обладают колоссальной производительностью и способны удовлетворить нужды тысяч пользователей хостинга, размещаемых в пределах ноды, выставляются особые требования и к производительности массива под файловое хранилище, базы данных. Массивы SATA/SAS дисков оказываются просто непригодными, так как они не способны эффективно справляться с запросами тысяч абонентов — один диск способен обеспечить не более 70-210 операций чтения / записи в секунду (IOPS), чего может быть явно недостаточно даже в случае применения массива из 12 дисков.

Единственным правильным вариантом в данном случае будет построение решения исключительно на твердотельных (SSD) накопителях, обеспечивающих от 50 000 IOPS и более, что практически в 1000 раз превосходит обычные HDD по производительности. Еще несколько лет назад применение таких накопителей значительно увеличивало бюджет решения, стимулируя хостинг-провайдеров к созданию «костылей» в виде гибридных рейдов или кэширующих CDN-cерверов, когда ssd применяются для кеша или только для баз. И это называли SSD-хостингом, чем в принципе некоторые не гребуют и сейчас, вводя клиентов в заблуждение, чтоб максимально сэкономить средства. Да, накопители по-прежнему значительно дороже SATA, однако те преимущества которые они открывают, как в плане производительности, так и в плане надежности — неоспоримы.

Причем, как писал недавно amarao в своей статье «SSD + raid0 — не всё так просто», эти диски в массиве могут быть не эффективны по приросту производительности записи за счет различной латентности, в отличии от HDD — raid0 будет ожидать подтверждение от самого медленного диска в массиве. Соответственно диски лучше использовать независимо и достигать повышение производительности за счет скриптов, а не за счет raid.

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

Реализация

В целях повышения степени отказоустойчивости и обеспечения максимально низкой стоимости для абонентов мы решили отойти от присвоения отдельным нодами каких-то ролей. Для построения решения были использованы 4 х-процессорные платформы с десятиядерными процессорами Intel Deca-Core Xeon E7-4850 с возможностью установки до 1ТБ оперативной памяти и до 16 SSD накопителей. При этом, чтоб избежать эффекта «мегасервера», когда проблема с одним абонентом (повышенная нагрузка, атака), становиться причиной проблем в работе сайтов всех абонентов ноды, мы разбили ноду на несколько виртуальных машин, применив виртуализацию, при которой каждая из машин может использовать максимум доступных ресурсов, но не в ущерб работе остальных виртуальных машин. Это позволило повысить степень отказоустойчивости, так как теперь в случае серьезной проблемы с нагрузкой / атакой на какого-то из пользователей, ее могут ощутить только часть абонентов ноды (от 1/16 до 1/32 на наших нодах). Помимо прочего, программное обеспечение позволяет незамедлительно блокировать такого проблемного клиента и перенести его на отдельную виртуальную среду для решения проблемы, а в том случае, когда атака идет по IP-адресу, переместить всех его соседей.

Для этой цели каждую из нод мы подключили Интернет-каналом гарантированной пропускной способности в 10 Гбит / с с возможностью расширения, который не только позволяет обеспечить практически любой необходимый трафик для наших абонентов, но и оперативно мигрировать, как отдельных абонентов, так и целые виртуальные машины, оперативно создавать резервные копии в удаленные хранилища и разворачивать их. Уже описанная выше четкая взаимосвязь между генерируемым трафиком и потребляемыми вычислительными ресурсами позволила тарифицировать только трафик (посетителей), сделав тарификацию прозрачной и удобной, а выбор тарифного плана максимально простым и понятным.

Результаты

Со времени запуска нового хостинг-проекта (январь 2015-го года) мы не получили ни единого недовольного клиента, uptime равен 100% и в будущем, надеемся, что это значение будет близким к 100. Конечно прошло еще слишком мало времени, чтоб оценить все преимущества и недостатки решения, но пока что каких-либо существенных недостатков данного решения мы не видим. Возможно увидите Вы?

Для всех читателей habrahabr мы предоставляем уникальную возможность заказать услугу «Волшебный хостинг» cо скидкой 60%, использовав промокод (действительный до конца июня): HABRHM2015

http://www.ua-hosting.company/hosting — ждем Вашу критику и отзывы.

Что мы предлагаем?

— Вам доступна мощь минимум 4-х десятиядерных процессоров Intel Deca-Core Xeon E7-4850;
— мы уверены, что должны обеспечивать Вам возможность потреблять столько трафика, сколько необходимо, потому каждый из хостинг-серверов обладает Интернет-подключением пропускной способностью не менее 10 Гбит / с, с возможностью увеличения до 40 Гбит / с;
— в то время, как большинство серверов хостинга до сих пор применяют «медленные» жесткие диски SATA, обеспечивающие не более 50-140 операций чтения / записи в секунду (IOPS), мы строим решения исключительно на твердотельных накопителях SSD, которые обеспечивают 50 000 IOPS и более! До 1000 раз быстрее в сравнении с традиционным SATA-хостингом! Позвольте Вашим сайтам «летать»!

И в дополнение, при долгосрочном сотрудничестве — волшебные скидки, что делает цену доступной даже для сайта-визтки!

Какие ограничения?

— для выбранного Вами тарифного плана ограничивается только максимальное количество посетителей в месяц — трафик, тем не менее Вы можете приобрести столько трафика, сколько Вам необходимо, увеличить Ваш тарифный план до необходимого Вам предела;
— так как потребляемый трафик неразрывно связан с потребляемыми ресурсами CPU / RAM / IOPS — мы практически не применяем их ограничения, ведь благодаря производительному оборудованию потребление носит мгновенный характер, что позволяет использовать ресурс хостинг-серверов полноценно и более эффективно;
— на хостинг-сервере запрещено размещение проектов с целью конвертации медиафайлов, проксирования трафика или проведения сложных вычислений;
— запрещено размещение политических сайтов, сайтов, подверженных DDOS-атакам, а также ресурсов, которые могут быть заблокированы для пользователей из России;
— нормы пользования сетью, принятые рабочей группой OFISP, а также Договор-оферта, должны соблюдаться в полной мере.

ссылка на оригинал статьи http://geektimes.ru/post/251568/

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

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

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

Проблематика хостинг-услуг

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

Итак, что же волнует пользователей хостинга? Доступность веб-сайта (надежность, отказоустойчивость), скорость работы, цена. Большинство при этом особое внимание может уделять цене, вынося её на первый план, как по объективным так и по субъективным причинам. И потому самая большая проблема, как для новичков, так и для продвинутых веб-мастеров — выбор тарифного плана.

Выбор тарифного плана

Этот выбор может оказывать значительное влияние на взаимоотношения между провайдером и вебмастером в ходе сотрудничества. И речь не о том, что у некоторых хостинг-провайдеров отношение лучше к тем, кто платит больше (воздержимся от дачи оценок таким случаям, статья не об этом), а о том, как легко допустить ошибку из-за неопытности и сэкономить лишнее, тем самым спровоцировав конфликтную ситуацию в дальнейшем, а она несомненно будет. Начинающие вебмастера зачастую искренне обижаются на провайдеров за письма о повышенной нагрузке, пишут гневные отзывы в Интернете. Через это проходил наверное каждый, в том числе и мы. Свято верят, что сайт, практически лишенный посещаемости, не может создать такой проблемы. И они правы! Потому как слишком не опытны и еще не могут знать, что система управления сайтом (CMS), отягощенная множеством модулей, да еще и не оптимально настроенная, может создавать значительное потребление. Либо потому как не догадываются, что провайдер с целью охвата большего количества потенциальных клиентов, мог создать слишком недорогой тарифный план, рассчитаный разве что на небольшую домашнюю страничку.

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

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

Выход?

На протяжении нескольких лет мы искали его. Мы обеспечили низкую цену на хостинг не за счет низкого лимита на ресурсы, оградили себя от спамеров и недобросовестных клиентов за счет ввода невыгодной для них системы тарификации, когда услугу выгодно заказывать исключительно на долгосрочный период, что лишено смысла в случае темных целей. Значительно повысили стабильность услуги без сложных технических решений, тысяча клиентов создавала не более 1 запроса в тех. отдел за сутки, минимизировали возможные конфликтные ситуации. Решения и результаты были подробно изложены в нашей статье от 2012-го года «Стабильный хостинг — миф или реальность?».

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

Ввод четкой тарификации потребления CPU / RAM / IOPS / BANDWIDTH, как на облачных сервисах, увы, не стал бы ответом и решением. Рядовых веб-мастеров не волнуют и не должны волновать эти параметры, их волнует только посещение их сайтов и их волшебная работа. Так почему не начать тарифицировать ресурсы исключительно в том, в чем измеряется доход вебмастеров, в посетителях?

Постановка задачи: ресурсы CPU / RAM / IOPS практически не ограничиваются, учитывается только трафик (посещаемость)

Результатом стала постановка задачи реализации принципиально нового хостинг-сервиса, которого не существовало на рынке ранее, где учитывается только посещаемость, фактически трафик, так как между этими параметрами есть четкий и понятный коэффициент. Для примера возьмем 100 ГБ трафика, много это или мало? Для визуализации в посетителях возьмем средний размер веб-страницы 700 КБ, количество просмотров — результат деления трафика на усредненный размер веб-страницы, к примеру для 100 ГБ трафика получаем 100*1024*1024/700 = 149 796,57 просмотров. Таким образом, если средний размер страниц Вашего веб-сайта будет меньше, к примеру составлять 200 КБ, а не 700, Вы можете получить гораздо больше просмотров — 100*1024*1024/200 = 524 288, и наоборот. Разумеется, что эти значения нужно воспринимать исключительно, как ориентировочные. Они не учитывают служебный трафик, трафик потребляемый поисковыми системами и паразитный трафик, который может появится и исчезнуть в любой момент.

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

Требования и проблемы

Отсутствие тарификации и явного ограничения CPU / RAM / IOPS предъявляет особые требования к оборудованию и архитектуре решения. Наша задача обеспечить максимально быструю и бесперебойную работу всех сайтов веб-хостинга. А это значит, что решение должно быть построено на основе нод с максимально возможной производительностью и при этом быть распределенным с целью повышения надежности, обеспечивать возможность масштабирования.

Так как современные многопроцессорные решения обладают колоссальной производительностью и способны удовлетворить нужды тысяч пользователей хостинга, размещаемых в пределах ноды, выставляются особые требования и к производительности массива под файловое хранилище, базы данных. Массивы SATA/SAS дисков оказываются просто непригодными, так как они не способны эффективно справляться с запросами тысяч абонентов — один диск способен обеспечить не более 70-210 операций чтения / записи в секунду (IOPS), чего может быть явно недостаточно даже в случае применения массива из 12 дисков.

Единственным правильным вариантом в данном случае будет построение решения исключительно на твердотельных (SSD) накопителях, обеспечивающих от 70 000 IOPS и более, что практически в 1000 раз превосходит обычные HDD по производительности. Еще несколько лет назад применение таких накопителей значительно увеличивало бюджет решения, стимулируя хостинг-провайдеров к созданию «костылей» в виде гибридных рейдов или кэширующих CDN-cерверов, когда ssd применяются для кеша или только для баз. И это называли SSD-хостингом, чем в принципе некоторые не гребуют и сейчас, вводя клиентов в заблуждение, чтоб максимально сэкономить средства. Да, накопители по-прежнему значительно дороже SATA, однако те преимущества которые они открывают, как в плане производительности, так и в плане надежности — неоспоримы.

Причем, как писал недавно amarao в своей статье «SSD + raid0 — не всё так просто», эти диски в массиве могут быть не эффективны по приросту производительности записи за счет различной латентности, в отличии от HDD — raid0 будет ожидать подтверждение от самого медленного диска в массиве. Соответственно диски лучше использовать независимо и достигать повышение производительности за счет скриптов, а не за счет raid.

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

Реализация

В целях повышения степени отказоустойчивости и обеспечения максимально низкой стоимости для абонентов мы решили отойти от присвоения отдельным нодами каких-то ролей. Для построения решения были использованы 4 х-процессорные платформы с десятиядерными процессорами Intel Deca-Core Xeon E7-4850 с возможностью установки до 1ТБ оперативной памяти и до 16 SSD накопителей. При этом, чтоб избежать эффекта «мегасервера», когда проблема с одним абонентом (повышенная нагрузка, атака), становиться причиной проблем в работе сайтов всех абонентов ноды, мы разбили ноду на несколько виртуальных машин, применив виртуализацию, при которой каждая из машин может использовать максимум доступных ресурсов, но не в ущерб работе остальных виртуальных машин. Это позволило повысить степень отказоустойчивости, так как теперь в случае серьезной проблемы с нагрузкой / атакой на какого-то из пользователей, ее могут ощутить только часть абонентов ноды (от 1/16 до 1/32 на наших нодах). Помимо прочего, программное обеспечение позволяет незамедлительно блокировать такого проблемного клиента и перенести его на отдельную виртуальную среду для решения проблемы, а в том случае, когда атака идет по IP-адресу, переместить всех его соседей.

Для этой цели каждую из нод мы подключили Интернет-каналом гарантированной пропускной способности в 10 Гбит / с с возможностью расширения, который не только позволяет обеспечить практически любой необходимый трафик для наших абонентов, но и оперативно мигрировать, как отдельных абонентов, так и целые виртуальные машины, оперативно создавать резервные копии в удаленные хранилища и разворачивать их. Уже описанная выше четкая взаимосвязь между генерируемым трафиком и потребляемыми вычислительными ресурсами позволила тарифицировать только трафик (посетителей), сделав тарификацию прозрачной и удобной, а выбор тарифного плана максимально простым и понятным.

Результаты

Со времени запуска нового хостинг-проекта (январь 2015-го года) мы не получили ни единого недовольного клиента, uptime равен 100% и в будущем, надеемся, что это значение будет близким к 100. Конечно прошло еще слишком мало времени, чтоб оценить все преимущества и недостатки решения, но пока что каких-либо существенных недостатков данного решения мы не видим. Возможно увидите Вы?

Для всех читателей habrahabr мы предоставляем уникальную возможность заказать услугу «Волшебный хостинг» cо скидкой 60%, использовав промокод (действительный до конца июня): HABRHM2015

http://www.ua-hosting.company/hosting — ждем Вашу критику и отзывы.

Что мы предлагаем?

— Вам доступна мощь минимум 4-х десятиядерных процессоров Intel Deca-Core Xeon E7-4850;
— мы уверены, что должны обеспечивать Вам возможность потреблять столько трафика, сколько необходимо, потому каждый из хостинг-серверов обладает Интернет-подключением пропускной способностью не менее 10 Гбит / с, с возможностью увеличения до 40 Гбит / с;
— в то время, как большинство серверов хостинга до сих пор применяют «медленные» жесткие диски SATA, обеспечивающие не более 50-140 операций чтения / записи в секунду (IOPS), мы строим решения исключительно на твердотельных накопителях SSD, которые обеспечивают 50 000 IOPS и более! До 1000 раз быстрее в сравнении с традиционным SATA-хостингом! Позвольте Вашим сайтам «летать»!

И в дополнение, при долгосрочном сотрудничестве — волшебные скидки, что делает цену доступной даже для сайта-визтки!

Какие ограничения?

— для выбранного Вами тарифного плана ограничивается только максимальное количество посетителей в месяц — трафик, тем не менее Вы можете приобрести столько трафика, сколько Вам необходимо, увеличить Ваш тарифный план до необходимого Вам предела;
— так как потребляемый трафик неразрывно связан с потребляемыми ресурсами CPU / RAM / IOPS — мы практически не применяем их ограничения, ведь благодаря производительному оборудованию потребление носит мгновенный характер, что позволяет использовать ресурс хостинг-серверов полноценно и более эффективно;
— на хостинг-сервере запрещено размещение проектов с целью конвертации медиафайлов, проксирования трафика или проведения сложных вычислений;
— запрещено размещение политических сайтов, сайтов, подверженных DDOS-атакам, а также ресурсов, которые могут быть заблокированы для пользователей из России;
— нормы пользования сетью, принятые рабочей группой OFISP, а также Договор-оферта, должны соблюдаться в полной мере.

ссылка на оригинал статьи http://habrahabr.ru/post/253563/

Пролонгация

Денежная инфекция поражает воображение. © Павел Шарпп

2013 год. Пришло время оценить результаты работы за прошлый год. Сделано много — похвалиться нечем.
CEO прочитав какую-то из очередных «умных» книг (а может и посетив семинар) понял в чем у нас загвоздка. Появились понятия о капитализации, экзитах, опционах, акциях, бюджетах, прогнозах, гипотезах и об инвестиционных раундах.

Все проекты стали отдельными и независимыми от инкубатора. Компания предоставляла сервисные услуги по факту своим же проектам. Нововведение: Человекочасы и любые другие расходы индексируются в денежный эквивалент — все расходы закладываются в рейт. Затем выставляется invoice от «инкубаторского» отдела проекту, по которому он якобы должен был заплатить. По факту, деньги никуда никому не приходили, просто влияли на расчет капитализации каждого проекта.

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

Появляется дополнительный проект Конструктор Тулбаров. Очень талантливый маркетолог приметил данную нишу уже давно и предлагал заняться разработкой. Из расчетов и презентации: инвестиции минимальные, сфера знакомая, поэтому здесь есть реальные перспективы. У компании +1.

Постепенно меняется и сам CEO. Ушли те времена, когда работа была на первом плане, уезжая или отсутствуя никого не ставит в известность (а ведь на нем по прежнему завязаны все процессы, груз ответственности, так сказать).

Стек задач забит до верху, ожидая своего апрува, а выполненные задачи оставались без внимания.
Статусы напротив каждой задачи — «Waiting for approve»;
Напротив проектов — «Пролонгация».

На письма, которые он считал менее важными, дожидались ответа месяцами, а «неважные» и вовсе оставались без ответов (пример из неважных: необходимо заплатить за аренду офиса, просрочка налогов, апрув отпуска, покупка оборудования). Произошла смена приоритетов и верх взяли более приземленные вещи: заграница, отдых, недвижимость. «Мажорских» замашек не появилось, но отношение к сотрудникам поменялось. Если раньше сотрудники высказывали свое мнение и к нему как минимум прислушивались, а иногда принимали как мнение специалиста, то сейчас в лучшем случае «выслушивали». Рассеянность, забывчивость особенно в тех денежных моментах, где он был «должен». На слово данное или обещанное никто уже не полагался, все дублировали на почту: тему беседы, ее результаты, обоюдные договоренности, ответственность сторон и обещания. Старались описывать все в деталях, чтобы по максимум исключить возможные прения или отговорки " ты меня не так понял", «я не мог такое утверждать».

Каждый раз, когда CEO сталкивался с выбором, он был сделан не всегда в нужную сторону и частенько был продиктован неготовностью расстаться с «кровными». Например, выделение средств на рекламную компанию или закупку ссылочной массы для технически готового проекта — было проблематичным. Данные расходы не поощрялись и не считались необходимыми, ПМ’ам нужно было выгрызать каждый последующий валютный знак. Зато полная смена приоритетов, целей, подходов и полный «рестарт» разработки — быстро приводился в действие.

Все перевернулось вверх дном. Где не нужно было- присутствовала чрезмерная расточительность, а где это было реально необходимо — приходилось сталкиваться с непониманием и прижимистостью. Уже никого не удивляло, что кнопка рисуется 2 недели, а дизайн одного продукта разрабатывается по-новому по 4 кругу.

Ситуация похожа на дело принципа " ну уж нет, когда-то же оно должно заработать!"

Бытующая гипотеза «По всем известной статистике только 1-2 проекта из 10 в портфеле венчурного фонда могут стать успешными — поэтому лишь каждый 5 стартап, который привлек деньги, может действительно представлять из себя вполне устойчивый бизнес» — была опробована и почему-то не работала. Игры в стартаперов потихоньку заканчивались.

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

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

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

Юридические нагромождения: большое количество зарегистрированных зарубежных компаний под каждый проект. Сотрудники сталкивались с путаницей в собственных контактах, имейлах и вообще в придуманных ими легендах. Количество «масок» для внешнего рынка зашкаливали. Полная неразбериха с банковскими счетами, транзакциями и их назначениями, так как вперемешку с расходами компании были и личные расходы CEO. Часть сотрудников, работающих на организаторских должностях выполняли помимо своих основных рабочих обязанностей еще и секретарские функции.

Что имеется:

• Много теоретических знаний, мало практики
• Применение нескольких методик одновременно
• Смена приоритетов у CEO
• CEO не делегирует свои задачи ( по прежнему принимает все решения)
• Большое количество требуемой документации от ПМов
• «Самостоятельность» проектов ( отделение от компании «инкубатора»)
• Капитализированные проекты
• Попытки выхода на рынок существующих проектов
• Новый проект: конструктор Тулбаров
• Изменение отношения CEO к подчиненным
• Взаимные претензии и поиск виновных
• Чрезмерная «секьюрность»
• Отсутствие понимания происходящего у сотрудников
• Путаница в юридических и банковских делах
• Большой капитал
• Замечательная команда
• Неплохой уровень ЗП
• Накопленная усталость
• Отсутствие общей цели:
• Цель для ПМов — получить полномочия
• Цель для CEO -?

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

Стагнация

Чем туже затянут пояс, те больше он похож на петлю. © Валентин Домиль

Окончив новые курсы (бухгалтера, agile специалиста, руководителя проекта, бизнес-аналитика) CEO освоил еще пару новых методик, которые активно внедряет. Появляются дополнительные роли на проектах, право выбора руководящему составу. CEO cебя позиционирует как портфельного инвестора, пытаясь отойти от исполнительской деятельности.

Данный путь привел к следующему: вместо того, чтобы разгрузить руководителей, дать им возможность свободно дышать и отвечать за свои действия, вышло все по-другому. CEO не принимает участие в проекте, но! теперь каждый ПМ при следующей итерации (новый раунд инвестиций) должен был доказать «свою» рентабельность. Началась борьба за выживание.

ПМы погрязли в купе документов: бюджеты, планирование, варианты экзитов, несколько вариантов гипотез в порядке приоритетов. Все заполняли невообразимое количество документации, рисовали графики, «рисовали цифры»… да-да именно рисовали. Гипотезы предполагают, а факты располагают. Не имея не малейшего понятия, как что и где сконвертится, выгребали тонны чужих статистик, пытаясь их «натянуть» на свои проджи. Назначали митинги с CEO, для презентации и защиты своей " писанины", обязательной для последующего раунда инвестирования. Все не желаемые гипотезы отбрасывались, так и не будучи опробованными, бюджеты и планы существенно корректировались. «Руль дали, ключи забыли». По факту CEO по-прежнему был руководителем компании и каждого проектов отдельности, только теперь ответственность была уже не на нем. «Отделегировав» свои задачи бухгалтерам и сотрудникам отделов " инкубатора" не спешил наделять их какими-либо полномочиями.

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

Раунды инвестирования сначала были полугодовыми, затем краткосрочными 1-3 месяца. По окончанию которых ПМы, готовили документы, отсылали их и ждали заключения. Не смотря на тот факт, что многие гипотезы, просто не могли дать плоды за такой короткий срок, или не поддавались точной оценке. К примеру, запустили рекламную кампанию в соц. сетях, отписали на тематических форумах, регистрировались на биржах, купили на 100 у.е ссылочной массы; внимание вопрос: «в какое количество продаж сконвертился каждый из методов?», «Какое количество постов нужно отписать, чтобы получить прибыль в размере 200 у.е?»
CEO просматривал бумаги с сознанием дела, вносил коррективы и обучал ПМов высшей математике.

Митинги постоянно срывались, по причине плотной занятости CEO, что оттягивало работу еще на более длительный срок. В ожидании рассмотрения своего " дела" многие ПМы, делали многое наперед, своими силами. Сами поднимали сайты, чуть «подкодивали», в кредит договаривались с удаленщиками (если не удавалось получать инвестиции, платили из своего кармана).

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

Дизайн — если коротко, поезд ушел. Envato нарастили такой сервис, что уже ни доплыть- ни допрыгнуть. Предыдущие попытки руководителя проекта не увенчались успехом, по нескольким причинам: нет опыта, нет конкурентов (элементы новизны), отсутствовал метод " проб и ошибок", невозможность вести свой проект и самостоятельно принимать решения.

Биллинг — прошел ажиотаж от пройденного сложного этапа сертификации. Оказалось, что этот сертификат вообще никаким образом не помогает в работе с банками. Реальность была жестче, чем предполагалось. У всех хорошо зарекомендовавших себя банков, и большинства тех, кто занимается E-commerce давно уже есть своя процессинг компания. Отдельное Юр. лицо, которое «не имеет» ничего с банком или… они уже заключили договор с локальным процессингом… кто не владел денежными активами на собственную структуру. Вывод: все хотят, чтобы работали через их процессинг с их платежками. Новым игрокам здесь не место. Руководитель проекта приложил немало усилий и все-таки " впихнулся", а дальше… поиск клиентов. В рамках белого бизнеса условия у всех одинаковы, было несколько вариантов: привлечь знакомых/свои проекты или работать в минус. Особого желания в минус работать было, не забываем, что CEO по определению не рассматривал возможность работы с мелкими клиентами («не нашего полета птица»). Большие глыбы в наших услугах не нуждались, никаких проблем у них с открытием мерчантов не было. Процессим свои же проекты.

Хостинг — во главе данного проекта становится системный администратор проекта биллинг. Позитивные тенденции. Помимо своих внутренних проектов, удалось найти внешних партнеров. До уровня самоокупаемости еще далеко, так как основная часть инвестиций была в достаточно дорогостоящее железо. Отрицательный аспект — физическое оборудование амортизируется, капитализация проекта нет. В случаях выхода из кризисной точки в данном случае можно было что-то продать и вернуть часть инвестиций. CEO инвестирует с меньшей опаской, понимая специфику проекта и учитывая более реальные варианты выхода.

Peer-to-peer — здесь проблемы были с самого начала. Во главе проекта появляется, ранее упомянутый, MBA специалист. Справились только с софтовой частью, правдами и не правдами. Лицензирование — не потянули, коммерческая деятельность была невозможна. Искали другие возможности. Контент не мог быть на коммерческой основе априори. Однозначно сказался недостаток у руководителя какие-либо тех. знаний и архитектуры продукта. Замена руководителя проекта на технаря «старейшину» компании, тоже не принесло умопомрачающего успеха. По предыдущему опыту ему были знакомы серые методы продвижения, только они и заработали. Подписки? Крутили так и эдак, пробовали перепробовали. По белому зарабатывать не получалось. На любой оттенок серого Инвестор уже не соглашался. Деньги здесь все-таки были… BUSTED!

Псевдо предприниматели

При единении и малое растет, при раздоре и величайшее распадается. © Саллюстий

Гипотеза: причина неудач в организационных моментах.

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

Наступил этап реструктуризации и регламентов.

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

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

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

У CEO все же было глубокое убеждение того, что это и есть первопричина всех бед, но сам не спешил подавать собственный пример, всегда «задерживаясь», забывая о задачах/договоренностях/предстоящих встречах и тд. Гайки закручивались жестко и беспринципно.

Подняли всю документацию вплоть до 2010 года, рассчитали остатки «неотгулянного» отпуска и… поняли, что если всем сотрудникам дать возможность использовать свой остаток, то можно смело отпустить весь руководящий менеджмент месяца на 3, а это было недопустимо. Как следствие, лимит на количество дней в год. Поставили в известность всех сотрудников о новом порядке, чем вызвали бурю эмоций и негодований. Одни думали, что их это не касается и надеялись все-таки получить хоть и не отпуск, но денежную компенсацию так точно. Другие кусали локти, вспоминая о тех «утерянных возможностях», при этом пытаясь корректно донести мысль о несправедливости данной схемы — не нашли понимания со стороны CEO.

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

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

Второй пошел. Еще один архитектор (системный администратор), стоявший у истоков, посидев и подумав, принял решение уйти в бессрочный отпуск. Данный сотрудник — мастер по безопасности данных и на короткой ноге с такими понятиями, как encryption, high load. Скинул все свои обязанности на еще таких юных в этом деле ребят, выгрыз свое фин. вознаграждение, помахал рукой и больше никогда не вернулся обратно. Так произошло еще с рядом сотрудников.

Командный дух куда-то быстро испарялся. CEO подливал масла в огонь придумывая новые способы «экзекуции» и все более изощренные методики.

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

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

Как продвигать компанию, у которой нет ни единой истории успеха? Нет портфолио. Нужна волна славы, хотя бы одного из проектов. Отделы сформированные по наитию нуждались в экспертизе. Ждем. Тем временем, каждый ищет себе любое другое занятие в проектах, предлагая себя в качестве наемного сотрудника. В компании работают адекватные люди, понимающие, что деньги нужно заработать. Засиживаться и протирать штаны — не хотели, даже за деньги. Те, кто не нашел себе применения, расходятся кто-куда. Работа окончена. BUSTED!

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

«Игра в предпринимателей» начинается. Отменяются соц. пакеты, полностью аннулируются бонусы, остаются только штрафы. Руководители проектов, вынуждены занизить себе ЗП и без того утратившую былой блеск на рынке. ЗП является частью запланированного бюджета. Затянул с документами, не смог «додавить» инвестора — пеняй на себя, дальше сидишь без инвестиций и ЗП, ждешь своей очереди. Кому это нравится? Правильно никому!
Вопрос поставлен ребром. Все ПМы теперь становятся предпринимателями, поэтому они несут такие же риски остаться без денег, как и CEO. Кому не нравится — могут идти на выход.

Стоит ли говорить о настроении сотрудников всех проектов? Каждый сам за себя. Бросить свой проект, свое детище, достаточно непростое решение. Первое время все боролись за свое место под «затухающим» солнцем. Затем поняли, что дороги обратно нет. Ни один довод, ни один разговор с CEO не приносил результата. Все понимают, что они и так уже давно предприниматели потому, что самостоятельно научились многому: вкладывать свои деньги в «не свои» проекты, брали риски на себя без проблем, научились за минимум делать максимум.

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

Проект Биллинг — BUSTED!
Проект Хостинг — BUSTED!
Проект дизайн — BUSTED!
Проект тулбар — немного позже, но тоже BUSTED!

Все кто вкладывал свои личные деньги, недополучая прибыль, или же выступал со-инвестором, частично жертвуя свою ЗП, со скрипом и скрежетом вывели только вложенные деньги. Ни о каких %, ни конвертируемых долях, акциях, опционах даже и речи быть не могло.
Все уже давно и без них проиндексировано, перерасчитано, переподелено и потрачено, доли размылись или вообще многих давно «слили по пути». Под любым предлогом CEO оттягивал (иногда на несколько лет) даже сам момент выплаты положенного и уже «подтвержденного» платежа. Находилось много разных причин, изменений и фактов, которые эту сумму делали еще меньше и меньше! Куча excel’ек и формул по мнению CEO „подтверждали“ его правоту. Большая часть сотрудников расходится. CEO констатирует факт неудачи и утверждает, что весь менеджмент его «кинул», оставив без капли благодарности.

Заново

Здесь вообще всё просто так, кроме денег… К-ф ‘Брат-2’

А теперь время вспомнить про проект X. Гномики неплохо преуспели. По-прежнему успешно намывают уже не только золото, но и „алмазы“. Коротко с фин. ситуацией здесь было все просто замечательно.
Как результат, у CEO проявляются видимые признаки звездной болезни, безнаказанности и всевластия. Все это время он и так не очень-то себе и отказывал в покупках новых машин, домов и любых других материальных благ.

Персонал проекта X и „инкубатора“ практически не взаимодействовали. Естественно, что многие сотрудники „инкубатора“ даже не допускали мысли о том, что они не получают своих %, дивидендов и различного рода бонусов, совсем не потому, что они безграмотные и расточительные руководители,… в общем каждый сетовал на свои личные ошибки.

Вкратце о том, чего достиг этот проект: при посещении различного рода тематических мероприятий, сотрудник только называл компанию в которой работает, и сразу подписывал контракт с крупной компанией на несколько KKK, без каких-либо предварительных длительных переговоров.

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

Несколько сотрудников из „инкубатора“ переводят на этот проект. Во основном на обычные исполнительский должности, такие как суппорт клиентов.

Несложно догадаться, что на проекте X начались вводиться те же самые методологии, регламенты, правила и субординационная организация. Мотивировалось все тем, что в связи со своей занятостью CEO ранее не мог уделять данному проекту много времени и сейчас видит значительные недостатки, которые необходимо исправлять. Пока сам CEO еще не особо разбирался в процессах и что да как работает здесь, ПМы могли на митингах активно кивать головой в знак согласия, а тем временем делали так как им было нужно. Только благодаря этим действиям, опять моя субъективная точка зрения, этот проект успешно продолжал зарабатывать достаточно неплохие цифры с огромным количеством нулей. CEO делает попытки завязать все процессы на себе, что заняло какое-то время. Дело в том, что за его отсутствие, процессы были давно уже построены и сотрудники на проекте знали предметную область гораздо лучше самого CEO, именно поэтому его авторитет не сразу приобрел там вес, только после некоторых пертурбаций, задержек ЗП, нескольких штрафов, все поняли, что все-таки придется мириться с происходящим. Подчинились. Стали разрабатывать дополнительные админки, дорабатывать внутренние инструменты, переделывать статистики.

За несколько лет розовая мечта — работать в белую — так и не была реализована, поэтому CEO пытается отбелить и этот бизнес. Напомню, что все схема на которых базируется данный бизнес, априори не очень-то и белые. Бандлами вешали все подряд… как же такое можно отбелить? Правильно, нужно начать заново!

CEO увольняет всех „чернушников“ с проекта, предварительно снизив денежные обороты проекта до 20%, чем впоследствии воспользовался, как аргументом в пользу невыплаты %, дивидендов — опять старая история. Открываются новые юридические компании, количество сотрудников сокращается в 3 раза. Не буду долго мусолить здесь, просто скажу, что ничего не поменялось. Белое имя создали, успешно запустили, сделали красивую легенду, подключили тех же клиентов, что и были, только не упоминали, о том, что это все те же дрожжи и те же самые люди. По факту делали все то же, что и всегда… бот трафик, как-то не отбеливался, поэтому лепили серенькую чернуху.

Последний валютный пик пришелся на начало 2014 года, после чего настала череда заведомо прогнозируемых событий. CEO уже давно не ориентирован на заработок денег ( и понятно почему), отбеливание и внешняя красота- вот его цель. Проблема была только в том, что сотрудники зависели от оборотов и всячески пытались заработать денег, у CEO другие планы, зарабатывать будем позже- сейчас надо построить тот же проект только по другому. » Игры в солдатиков" и здесь прожили какое-то время. Пока заработок компании не упал до критической точки, а часть прибыли куда-то испарилась. Опять дележ. Опять никто ничего не получает. Опять уходят ключевые сотрудники, уже практически никого не осталось…

С конца 2014 года, CEO «едет» на прежних оборотах, которые ему накрутили менеджеры, а оставшиеся «успешно» занимаются разработкой админок и исследуют графики и регулярно высиживают длительные «scrum митинги».
Оставшиеся сотрудники не амбициозны и достаточно пассивны, на мой взгляд, поэтому ждать от них каких-то идей, или же умопомрачительных инициатив не приходится, так как у них интерес простой: работать пока платят. Такие сотрудники идеальны для исполнительской деятельности и тоже бесспорно нужны, но пока они подчиняются, ни о какой командной работе не стоит говорить. Нет амбиций — нет инноваций.

В итоге проект X постигнула почти та же участь, что и всех выше упомянутых, как только CEO переключился на него и стал там " управлять". По сей день уверенность в том, что его подвела команда. Без него ни один ничего не достигнет, так как нуждается в нем, только он (CEO) может дать всем этим людям возможность зарабатывать, научить их чему-то и привести их к успеху.

Эпилог

Нажить много денег — храбрость; сохранить их — мудрость, а умело расходовать — искусство. © Ауэрбах Бертольд

Данная история содержит в себе достаточно большое количество проб и ошибок.
Наглядный пример того, что даже в идеальном стечении обстоятельств можно все довести «до ручки».
Было все:

• Хорошая команда, которая занималась самопожертвованием в удовольствие.
• Общая цель.
• Достаточное количество знаний и опыта для реализации своих проектов. (как пример проект Хостинг1, который вовремя отделившись от компании определил свой успех).
• Огромный капитал.
• Умение экономить, достигать своих поставленных целей с минимальными потерями.
• Достаточно неплохие идеи для проектов, имеющие право на жизнь.

"… это жизнь. Ну было и было." © Смоки Мо

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

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

Сопутствующие проблемы:

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

Многие читатели могут задаться вопросом, а как вообще можно быть такими наивными и ждать, пока будет убегать последняя крыса с корабля. Не скрою, что у CEO есть замечательный навык, единственно правильно применимый, умение убеждать и манипулировать. За все время работы он отточил его до блеска. Это замечательный навык, но увы он был неверно направлен, на свою команду, и в добавок использован в корыстных целях — не пробрести, а " отжать", что в корне ведет исключительно к деструктиву и в таком ракурсе никак не применим в сфере IT.

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

Капитал. Не скрою, что потрачено было много. Как и было обещано в предыдущей части вот порядок сумм инвестиций ( прим. некоторые проекты не были затронуты, так как они по сути были производными или идентичными):

1. Проект peer-to-peer — 80K
2. Конструктор Тулбаров -90K
3. Проект Хостинг2 — 200K
4. Проект Маркетплейс — 80K
5. Проект indoor/outdoor рекламы — 160K
6. Проект Биллинг — 150K
7. Инкубатор — 150K
8. Поточные проекты — 220K

Эти суммы были инвестированы в течении 3 лет. Если ближе к реальности, то все эти проекты «кормил» наш старый добрый серый друг. Благодаря былой «серости» небольшая часть сотрудников смогла обеспечить себя далеко и на долго, все остальные за эти деньги приобрели бесценный опыт, могли конечно и подешевле, но тут уж как есть!

P.S На данный момент все ключевые уволившиеся сотрудники запустили свои проекты, каждый продолжает работу в своей нише. Все получили достаточно наглядный и красочный пример, и самый яркий опыт — историю «неуспеха». Некоторые из эти проектов, за такой малый срок, уже перестали быть «стартапами», а выросли в полноценные самостоятельные компании, без инвестиций и первоначального капитала, со стабильным заработком.
Мало кто из них использует какие-то наработки из предыдущей жизни — так как это было бесцельно потраченное время. Предпочитают делать с нуля, как считают нужным и подшучивают над былыми историями, искренне поражаясь факту: «как за такое время, с такой командой и с таким капиталом все можно было… упустить ».

Изречение напоследок:
Люди, считающие деньги способными все сделать, сами способны все сделать за деньги. ©
Пьер Буаст

ссылка на оригинал статьи http://megamozg.ru/post/16174/

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

1. Денег никто не даст

В IT полно инвестиций. Медиа любят писать про проекты, получившие венчурные деньги и построившие на них эффективную бизнес-систему. Но есть куча проектов, которые потратили массу усилий на поиск инвестиций – вместо реальной работы – и в итоге не смогли взлететь. Конечно, про такие проекты никто ничего не пишет. В результате у многих складывается впечатление, что поиск инвестиций – это простой, правильный и, в общем-то, основной путь развития проекта.

Я верю, что большинству проектов (особенно на ранней стадии) мысль поиска инвестиционных денег наносит колоссальный вред. В качестве лечения этой навязчивой идее я бы предложил использовать в качестве мантры тезис ДЕНЕГ НИКТО НЕ ДАСТ. Если хорошенько закрепить его в голове, он позволяет переключить усилия с написания презентаций и хождения по бесчисленным встречам на действительно важные вещи:

• Поиск бизнес-модели, которая потребует меньших денег;
• Работу над реальным value продукта;
• Поиск решения, как зарабатывать больше с помощью текущей деятельности.

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

В общем, только когда в голову начало закрадываться смутное осознание, что ДЕНЕГ НИКТО НЕ ДАСТ, дело начало реально двигаться. Пришлось за несколько месяцев найти способ удвоить заработок, подобрать подходящий участок, выплатить первый взнос и начать землеустроительные работы.

Справедливости ради, стоит сказать, что в результате всех этих усилий денег мне все-таки предложили, но на условиях, которые напрочь убили бы проект. Переговоры сразу с несколькими девелоперами закончились предложением объявить уже строящийся объект «поселком программистов» и обеспечить продажи за соответствующее вознаграждение.

2. Всегда пробивайте подрядчиков

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

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

Из этого можно сделать два вывода. Если работа, которую вы собираетесь делегировать, является блокером для всей последующей деятельности, нужно:

• Максимально тщательно промониторить выбранного подрядчика. При этом наличие крупного офиса и десятков сотрудников – не дает никакой гарантии. Единственным критерием может быть только количество негативных отзывов о его работе.
• Звонить им каждый день и требовать результат. Так можно очень быстро надоесть, зато создать дополнительный стимул поскорее закончить вашу работу, чтобы от вас отвязаться.

3. Держитесь подальше от нетипичных решений

У многих людей, которые еще не попробовали стройку на практике, в голове встречается распространенный баг. Они хотят жить в домике на дереве, в доме шестигранной формы, в купольном доме или (не дай Бог) в каком-нибудь пряничном домике или вообще доме-грибе. Если домик на дереве еще можно как-то объяснить эволюцией, то природа остальных проявлений совершенно необъяснима.

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

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

Мы тогда еще не обзавелись архитектором в команду и своей строительной компанией. Поэтому сами слегка «адаптировали» дизайн этих строений (т.н. кэмпинг-подов) к нашим потребностям – чтобы внутри был санузел и побольше места, нашли бригаду бодрых строителей и запустили разработку. Вот что получилось в итоге:

Я выслушал сотни остроумных комментариев по поводу внешнего вида получившегося строения. Будущие соседи и другие друзья, побывавшие в поселке, теперь троллят меня кэмпинг-подом, как только на их взгляд попадает что-нибудь полукруглое. «Ангар», «Ракушка» и «Бронетеплица» – самые безобидные из всех ярлыков, которые приклеивались к этому бедному зданию.

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

• Нестандартные поверхности плохо стыкуются друг с другом;
• Отделочные материалы во всех магазинах, оказывается, заточены только под ортогональные решения;
• Строители будут думать, что заказчик сошел с ума и с ходу забьют на качество;
• Все не до конца продуманные дизайнерские решения строители примут самостоятельно;
• Ошибки в дизайне гораздо сложнее спрогнозировать и они гораздо больнее бьют по облику результата, чем в случае с традиционными решениями;

В итоге опыт этой стройки полностью вылечил меня от тяги к необычной архитектуре. Мы все-таки планируем принципиально довести до победного конца историю с кэмпинг-подом – переделать его и добиться, чтобы он нормально выглядел. Просто это выливается немного в другие деньги, которые сейчас важнее в другом месте – у нас начинается стадия активного строительства домов и коммуникаций.

4. Технарям не место в дизайне

Мы с вами хорошо умеем делать так, чтобы «эта штука работала». Обычно это требует недюжинных способностей и здравого смысла – поэтому мы можем неплохо оценивать адекватность дизайна и даже давать неплохие советы насчет его улучшения. Но нам не стоит лезть в какие-то дизайн-вопросы целиком!

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

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

5. Твиттер!

Первый пост про поселок программистов за сутки прочитало больше 100 тысяч человек. Волну подхватили несколько региональных и федеральных СМИ, и получившийся суммарный отклик впечатлял. Следующие несколько постов было менее интересными, но трафик и количество фидбека все равно впечатляли. Казалось, что так будет всегда.

Однако, land-development и стройка – это не IT-индустрия. Как бы это не выводило из себя, здесь без больших денег все движется в черепашьем (по сравнению со стартапами) темпе. Свернув в самом начале не туда, мы потеряли кучу времени, подрастеряли интерес СМИ и подписчиков Хабра. Когда мы, наконец, вернулись на правильный путь и смогли об этом написать – сразу же получили бан на Хабре из-за изменившейся политики касательно публикации своих проектов. Когда, наконец, удалось вернуть доступ и администрация подарила нам стартап-аккаунт, все нетехнические посты Хабра перенесли на GeekTimes с гораздо меньшей аудиторией.

Я это вот к чему. Хабр – уникальный ресурс и многие стартапы получили путевку в жизнь исключительно благодаря блогу «Я пиарюсь», который помог создать первую волну трафика. Но рассчитывать только на Хабр сегодня нельзя. Его по-прежнему эффективно использовать для получения трафика, но весь этот трафик нужно обязательно фиксировать в Твиттере. Если бы мы так сделали в самом начале, у нас бы сейчас застраивался весь первый сектор, а не первая улица, как сейчас.

Текущий статус

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

На текущий момент к нам присоединилось 4 семьи из разных регионов РФ. Своеобразное облако тегов, характиризующее географию рождения участников, на текущий момент выглядит так: Питер², Муром², Бузулук¹, Киров¹, Тамбов ¹, Тольятти¹. Все 4 дома находятся на разных стадиях – в первом уже начинается отделка, четвертый пока на стадии проектирования. Часть ребят на время стройки переехала в Киров, и у нас постепенно формируется отличная тусовка будущих переселенцев. На лето запланировано еще несколько визитов гостей – потенциальных соседей из других городов. В общем, присоединяйтесь!

Как всегда, с нашей концепцией можно познакомиться на сайте – poselok-programmistov.ru, на новости подписаться в Твиттере – twitter.com/it_poselok, а за ходом стройки следить в Инстаграм – instagram.com/it_poselok

ссылка на оригинал статьи http://geektimes.ru/post/251566/

Хотел бы поведать свою историю об установке геокодера Nominatim на выделенный сервер. Изначально предполагалось, что эта задача займёт у меня около 5-7 часов, но не тут то было… Поэтому было решено написать статью c описанием разворачивания Nominatim на сервер до полной работоспособности сайта. Но обо всём по порядку.

Введение

Есть множество сервисов с геокодерами, не буду здесь их всех перечислить, отмечу, что на Хабре есть хорошие статьи по этому поводу: «Geocoding with PHP and the Google Maps API», а также «Яндекс Карты: Поиск произвольных объектов».

Для тех кто не в курсе: Geocoding — это процесс нахождения широты и долготы по введенному адресу.
Мой выбор пал именно на Nominatim, так как его можно развернуть на своём сервере и не ограничиваться количеством запросов, а также уже был опыт работы с OSM картами и хотелось бы его применить.

Документация

Сайт с уже работающей картой можно найти по ссылке: OpenStreetMap Nominatim
А вот и ссылка на примеры запросов: Wiki nominatim
Так же есть ссылка на установку Nominatim Installation. Но эта документация немного устарела, для установки именно по этой статье необходимо немного потанцевать с бубном. Всё ниже описанное, будет ссылаться на эту статью по установке, только без участия бубна.
А так же есть докер контейнер nominatim docker. По какой-то причине, скорее всего из-за устаревших пакетов установки, этот контейнер у меня таки не запустился.

Шаг 1: Создание виртуальной машины

За основу была взята машина из облака Microsoft Azure серии standart D2 с характеристиками: 2 cores, 7 GB RAM, 100 GB SSD. Именно на этой машине и будет производиться установка Nominatim. 100GB на самом деле — это больше чем нужно для моей задачи, так как карта Украины не настолько большая. После установки всех необходимых компонентов осталось свободных 70%.

Шаг 2: Установка необходимых пакетов

sudo apt-get update sudo apt-get -y install wget sudo apt-get -y install build-essential automake sudo apt-get -y install libxml2-dev sudo apt-get -y install libgeos-dev sudo apt-get -y install libpq-dev sudo apt-get -y install libbz2-dev sudo apt-get -y install libtool libproj-dev sudo apt-get -y install libgeos++-dev sudo apt-get -y install gcc proj-bin libgeos-c1 git osmosis sudo apt-get -y install php5 php-pear php5-pgsql php5-json sudo apt-get -y install bc sudo apt-get -y install postgresql-9.4 postgresql-9.4-postgis-2.1 postgresql-contrib-9.4 postgresql-server-dev-9.4 sudo apt-get -y install libboost-chrono1.55-dev libboost-thread1.55-dev libboost-filesystem1.55-dev sudo apt-get -y install python-software-properties && add-apt-repository -y ppa:kakrueger/openstreetmap && apt-get update && apt-get --no-install-recommends install -y osm2pgsql 

Шаг 3: Настройка

sudo -i pear install DB sudo -u username sudo mkdir -p /app/nominatim sudo -i useradd -m -p password1234 -d /app/nominatim nominatim chown nominatim: /app/nominatim cd /app/nominatim wget http://www.nominatim.org/release/Nominatim-2.4.0.tar.bz2 tar xvf Nominatim-2.4.0.tar.bz2 rm Nominatim-2.4.0.tar.bz2 mv Nominatim-2.4.0/* . rm Nominatim-2.4.0/ sudo -u nominatim ./autogen.sh ./configure && make 

Думаю, в этих строках команд не сложно разобраться. В случае если возникнет ошибка с получение прав доступа, установим права доступа на чтение и запуск на выполнение всем пользователям и группам chmod -R 755 /app. Хотелось бы отметить, что иногда возникала проблема при выполнении команды make. если у вас возникла эта проблема воспользуйтесь командой sudo make clean, а затем уже ./configure && make.

Шаг 4: PostgreSQL

Изначально, postgres настроен не для боевого сервера, так что надо его конфигурировать вот советы от wiki документации nominatim:

Ubuntu location /etc/postgresql/9.x/main/postgresql.conf
CentOS location /var/lib/pgsql/data/postgresql.conf

shared_buffers (4GB)
maintenance_work_mem (10GB)
work_mem (50MB)
effective_cache_size (24GB)
synchronous_commit = off
checkpoint_segments = 100
checkpoint_timeout = 10min
checkpoint_completion_target = 0.9
The numbers in brackets behind some parameters seem to work fine for 32GB RAM machine

sudo passwd postgres sudo usermod -a -G sudo postgres service postgresql start && pg_dropcluster --stop 9.4 main service postgresql start && pg_createcluster --start -e UTF-8 9.4 main  service postgresql start && sudo -u postgres psql postgres -tAc "SELECT 1 FROM pg_roles WHERE rolname='nominatim'" | grep -q 1 || sudo -u postgres createuser -s nominatim && sudo -u postgres psql postgres -tAc "SELECT 1 FROM pg_roles WHERE rolname='www-data'" | grep -q 1 || sudo -u postgres createuser -SDR www-data && sudo -u postgres psql postgres -c "DROP DATABASE IF EXISTS nominatim" 

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

Шаг 5: Загрузка и установка osm карт

В начале необходимо загрузить саму карту из сайта в формате *.pbf: OpenStreetMap Data Extracts. В качестве примера я загружаю карту Украины и переименовываю в data.pbf.

wget --output-document=data.pbf http://download.geofabrik.de/europe/ukraine-latest.osm.pbf chown nominatim: data.pbf touch local.php /app/nominatim/settings/local.php nano /app/nominatim/settings/local.php 

Последняя команда открывает файл конфигураций по установке nominatim. В файл local.php нужно ввести код который описан ниже.

<?php    // Paths    @define('CONST_Postgresql_Version', '9.4');    @define('CONST_Postgis_Version', '2.1');        // Website settings    @define('CONST_Website_BaseURL', 'http://geocoder.cloudapp.net/'); ?> 

В качестве BaseURL необходимо вписать адрес сайта, с которого будет запущен nominatim.

Теперь запускаем команду установки nominatim. Эта операция занимает довольно таки длительное время, например с картой Украины установка длилась около 7 часов. В силу того, что я выполнял все команды через ssh, и являюсь подверженным переменному отключению интернета, выполнение команды установки проводится в скрине.

screen service postgresql start && sudo -u nominatim -- ./utils/setup.php --osm-file /app/nominatim/data.pbf --all --threads 2 2>&1; sudo -u nominatim -- ./utils/setup.php --index --create-search-indices 

Для выхода из скрина нужно набрать комбинации Ctrl+A затем Ctrl+D. Команда screen -r возвращает обратно в скрин.

Теперь запустим сайт быстрым способом:

./utils/setup.php --create-website /var/www/html rm /var/www/html/index.html /etc/init.d/apache2 restart 

Я обошелся без настройки apache или работой с nginx, так как об этом вы с легкостью можете прочитать на Хабре в других статьях. Да и без настройки сайт прекрасно работает.

Тестируем сайт

В результате мы должны увидеть что-то подобное, как на моём скрине:

Проверим как работает api, сделав запрос:
http://geocoder.cloudapp.net/?format=json&addressdetails=1&q=Odessa&format=json&limit=1
Response:

[{"place_id":"1145869","licence":"Data © OpenStreetMap contributors, ODbL 1.0. http:\/\/www.openstreetmap.org\/copyright","osm_type":"relation","osm_id":"1413934","boundingbox":["46.342707","46.6291187","30.6114013","30.8313753"],"lat":"46.4858883","lon":"30.68365101101","display_name":"Одесса, Одесская область, Украина","class":"place","type":"city","importance":0.45,"icon":"http:\/\/geocoder.cloudapp.net\/images\/mapicons\/poi_place_city.p.20.png","address":{"city":"Одесса","county":"Одесса","state":"Одесская область","country":"Украина","country_code":"ua"}}] 

Выводы

В конце хотелось бы подметить, что для загрузки карты Земли нужно сервер по мощнее, чем серия D2, если вы не хотите *неделю ждать загрузки. Эту проблему так же можно решить с помощью временного масштабирования сервера до серии D14 (16 ядер, 112 ГБ памяти). А вот время выполнение запроса поиска очень радует: в среднем поиск по Украине занимает всего 300мс.

Надеюсь, данная статья поможет другим разработчикам потратить меньше времени на разворачивание Nominatim и понять, нужно ли вам это. Может стоит взять уже готовое и использовать?

Если у кого-то из хабросообщества будет необходимость в рабочем Docker контейнере с Nominatim, или другие идеи — пишите, всегда рад пообщаться.

ссылка на оригинал статьи http://habrahabr.ru/post/259667/