О чем мы расскажем:

— Почему мы решили перейти на LXC контейнеры?
— Как создать контейнер и запустить на нем хост на базе Битрикс?

Для кого это будет полезно:

Для всех, кто хочет попробовать новое решение, при этом используя меньше ресурсов.

О чем мы расскажем:
Как быстро развернуть общее хранилище для двух серверов на базе решений drbd+ocfs2.

Для кого это будет полезно:
Туториал станет полезен системным администраторам и всем, кто выбирает способ реализации хранилища или хотят попробовать решение.

От каких решений мы отказались и почему

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

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

• Ceph не понравился избыточной сложностью, которая может быть вредна на проектах с 2-4 серверами, особенно, если проект впоследствии обслуживают. Опять же, имеются серьезные ограничения по производительности, вынуждающие строить отдельные storage кластеры, как и с glusterfs.

• Использование одного nfs сервера для реализации общего хранилища вызывает вопросы в плане отказоустойчивости.

• s3 — отличное популярное решение для некоторого круга задач, но это и не файловая система, что сужает область применения.

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

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

Но что делать, когда ваш код “идеален”, все тяжелые запросы вынесены в фон, все, что можно, было закэшировано, а сервер все так же не дотягивает до нужных нам показателей SLA? Если есть возможность, то конечно можно докупить новых машин, распределить часть трафика и забыть о проблеме еще на некоторое время.

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

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

В этом году впервые начали внедрение ReactJS для интернет-магазина сети гипермаркетов Глобус. Проект интересен тем, что расширяет возможности платформы Битрикс и при этом сохраняет возможность генерации страниц для поисковиков и не захламляет дублированием кода и верстки. В этой статье рассказываем о том, как связать компоненты Битрикса с компонентами ReactJS при помощи модуля v8js для php и сохранить основную фронтовую часть сайта.

1. неСЭДы
Идея проекта qFlow пришла спонтанно, не было долгого анализа рынка на предмет потребностей и спроса, маркетинговых исследований и т.д. Просто возникло понимание, что большинство систем — CRM, ERP, трекеры и т.д. являются просто помощниками по сбору данных от пользователей, в которые зашиты свои, особенные бизнес процессы обработки и движения данных + свой инструментарий. Конечно, больше всего идея сервиса напоминала так называемые системы электронного документооборота и с самого начала аббревиатура СЭД ассоциировалась со словами ВНЕДРЕНИЕ, СОФТ, БЮРОКРАТИЯ и т.д.
Ну, как говорится, попытка не пытка. Набрал в поисковике СЭД, чередуя возможные ключевые слова, и обнаружил, что не ошибся. Наряду с определениями из словарей сразу появилась реклама с предложениями внедрить, приехать на семинар, статьи посвященные делопроизводству в России, консалтинг и отраслевые предложения. Я, как руководитель отдела компании, которую можно отнести к малому бизнесу (малым рабочим группам) сразу почувствовал себя чужеродным телом в этом сплоченном коллективе делопроизводственников.

Наверняка к вам на улице когда-нибудь приставали девушки или юноши с предложением ответить на самые разные вопросы — от «Что вы курите?» до «За кого вы собираетесь голосовать?».

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

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

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

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

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

Я предполагал, что похожая история должна произойти и в сегменте сайтов для малого и среднего бизнеса. Фантазируя про будущее, я предположил, что для небольшой компании не будет смысла заказывать полностью эксклюзивную разработку собственного сайта. Достаточно, будет сделать основу (шаблон), а для всех остальных задач использовать сторонние сервисы. Нет смысла делать свою ленту новостей, когда можно поставить ленту из ЖЖ или твиттера. Нет смысла делать свою регистрацию, если есть профили из соц.сетей. Глупо делать свой аудио или видео-плеер. Зачем заказывать собственную разработку интернет-магазина, если можно получить готовое решение, настроить его и просто поставить себе соответствующий скрипт, так же, как мы делаем это с youtube’ом?

На днях мы открыли qFlow.ru – новый SaaS-проект (пока в beta-версии) для легкого создания web-форм и настройки бизнес-процессов обработки полученных результатов.

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

Идея сервиса для создания web-форм не нова и в интернете можно найти много вариантов, но найти удобный и достаточно функциональный сервис не так уж и просто. Например, в документах гугл есть конструктор web-форм, но он на английском, а работа с результатами все же не так проста, как хотелось бы. Недавно открылся сервис wufoo.com – очень симпатичный и простой, но как у в гугле нет процессов и он на английском.

Редактирование результата

История команды интернет-магазина путешествий Gate-32, которая использует наш сервис qTrack для управления проектом.

Идея создания интернет-магазина путешествий Gate-32.ru была весьма тривиальна: «Как бы было здорово не мучаться с подбором тура, а, сидя на работе, выбрать все на сайте, оплатить картой и умчать к морю. Без перерывания интернета в поисках лучшей цены, без очередей в турагентстве, без всяких отмен броней и прочих сомнительных радостей». Так мы стали делать Gate-32. Причем ввязываясь в удивительный мир туризма, мы как бывшие сотрудники IT-компаний, не могли предположить, что туристический бизнес настолько стихиен, разрознен и неоднороден в подходе к автоматизации ключевых процессов.

В первые месяцы, автоматизация продаж казалась нам делом весьма банальным, т.к. электронная торговля не новость уже во всем мире, даже в Бангладеше или любимом всеми Гандурасе интернет-магазином мало кого удивишь. Но у нашей страны особый путь…

Всем привет,
Предлагаю обсудить одно из возможных решений проблемы 20/80, реально используемое в нашей компании.

Многим менеджерам проектов известен закон Парето (в общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата»), в нашем варианте «на последние 20% проекта требуется 80% ресурсов». Проще говоря, проект по настоящему начинают делать за 3 дня до открытия. В результате: аврал, срыв сроков, низкое качество, беготня, стресс и прочие удовольствия PM'a.

Частая ошибка – дать разработчикам ТЗ и ждать пока они все сделают, а потом начать проверять. Это работает, когда проект очень маленький. Значит, надо из одного большого проекта сделать несколько маленьких. Путем проб и ошибок для себя мы нашли решение, которое условно назвали «недельные итерации» (хотя это не итерации в полном смысле, когда каждая итерация это мини-проект, включающий все фазы, от анализа до внедрения) — задачи объединяются в итерацию так, чтобы они могли быть выполнены за неделю. Теперь самое важное — итерация должна быть сделана полностью и проверена.

Предлагаем посмотреть наш to-do лист и обсудить каким должен быть идеальный список дел. Из интересных возможностей — иерархическое представление, драг-н-дроп, цветовая раскраска и самое интересное — возможность обсуждать задачи из списка дел. Цель тестирования — логические и эргономические решения (а не только поиск багов верстки и кода, хотя они конечно же принимаются). Нам очень интересно мнение хабралюдей, как искушенных пользователей.



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

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

Наблюдая за разными старт-апами, я стал замечать, что каждый новый проект проходит 3 фазы развития: «эйфорический», «депрессивный» и «реалистичный»

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

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

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

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



Чтобы лучше понять суть новых возможностей, немного расскажу о концепции сервиса и уже имеющихся возможностях по работе с почтой. Очень часто, при управлении проектом, отношения с заказчиком (управление требованиями) живут отдельной жизнью (в почте) от управления выполнением задач (в трекере). Это приводит к дублированию и искажению информации, двойной работе и просто потери обращений от клиента и вопросов к нему. Поэтому, концепция qTrack заключается в объединении Заказчика и Исполнителя. И именно поэтому qTrack тесно интегрирован с почтой, позволяя участникам (особенно Заказчику) работать с сервисом используя свою обычную почту, даже не заходя в интерфейс qTrack.