Разработчикам не нравятся технологии в компании и хочется что-то сделать на новом, крутом, современно языке и… И? ИИИ? Копнем историю. Полезно вспомнить, как все начиналось. Математика оказалась нужна людям далеко не из любопытства: государственная экспансия, строительство, военные технологии, бизнес — они одними из первых испытали глубокую жажду в быстрых и правильных вычислениях. Квадратные и кубические уравнения научились правильно решать лишь тогда, когда они оказались нужны… купцам и артиллеристам. Синусы и косинусы тоже придумали не из-за большого ума — с их помощью стало возможным строить… нормальные дома, которые не падают :-)

А логарифмы… там вообще интереснейшая история. Они оказались купцам (а за ним морякам и пиратам) и военным настолько нужны, что некоторые математики средневековья жизнь потратили лишь на составление их таблиц! Посмотрим в глаза героям — Джон Непер:

Предлагаем вашему вниманию материалы по мотивам выступления Александра Сербула на конференции BigData Conference. Я, как автор и докладчик, текст немного отредактировал и добавил современных мыслей и актуальных проблем, поэтому надеюсь пост принесет вам как дополнительные практические полезные знания в отрасли, так и пищу для размышлений — куда податься со своими знаниями. Итак — в бой!

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



Но, как говорили древние — это искушение!

Коллеги, оглянитесь вокруг!

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

Технология «отжима больших данных» грубо делится на два, очень очень разных пласта — инженерный и алгоритмический. В первом монолите программное обеспечение пока довольно сырое, бурно развивается, от чего у разработчиков, простыми словами, уже «едет крыша»: приходится разбираться в инструментах от «старого доброго» Hadoop с HDFS, активно используя Hive, Impala, Presto, Vertica и прочая и прочая… и, чтобы не отстать от конкурентов, ювелирно владеть секретами Apache Spark, сваянного на прекрасной лаконичной Scala.

Вы еще не сохраняете десятки миллионов событий в день? К вам еще не забегают менеджеры с кричащим вопросом — когда твой дорогущий кластер на «надцати» машинах посчитает агрегированную статистику по продажам за неделю (а в глазах читается: «чувак, ребята на php/python/ruby/go решают задачу за час, а ты со своей Бигдатой тянешь время днями, доколе?»)? Вы еще не вскидываетесь ночью в холодном поту от кошмара: «разверзлось небо и на вас, ваших коллег и весь нафиг город вывалилось огромная куча… Бигдаты и никто не знает, что с этим всем теперь делать»? :-)

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

Если это не о вас, тогда и не заходите под кат, ибо там — треш и жесткий технологический трепет…

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



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

Психология — интересная и иногда полезная наука. Многочисленные исследования показывают, что задержка в отображении веб-страницы дольше 300 мс заставляет пользователя отвлечься от веб-ресурса и задуматься: «что за хрень?». Поэтому УСКОРИВ веб-проект до психологически невоспринимаемых значений, можно ПРОСТО удерживать пользователей дольше. И именно поэтому бизнес готов тратиться на скорость: $80М — чтобы уменьшить latenсy всего на 1 мс.



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

Всем привет!

Уже слышали про Bigdata? Ну да, веб растет, данных становится больше и их нужно держать под контролем и периодически анализировать. Базы данных — лопаются под нагрузкой, реляционная теория не совсем справляется с задачей, нужно решение. Маркетинг активно давит сверху, а железо острыми углами — снизу и попахивает суицидом.

В этом посте постараюсь дать конкретные работающие рецепты и куски кода с краткими теоретическими выводами, как же обрабатывать >=терабайты в >=1000 потоков на PHP. Чтобы можно было взять и решить задачу, не теряя времени и не забивая голову теорией.

Однако, если вдруг стало подташнивать и закружилась голова, можно дальше не читать — а полюбоваться на прекрасных птичек и забыть о вышенаписанном. Но будьте на чеку, Bigdata может завтра взять и постучаться в дверь ;-)

Ну очень интересно было разобраться, как совершать видеозвонки через браузер внутри компании и насколько это полезно. Тем более, что skype — «прослушивается» и пересылаемые пароли парсятся роботами…

Вроде есть Google+ Hangouts и им нередко пользуются — но это все таки не WebRTC и проприетарная облачная технология. Кто знает — не просматривают ли наше совещание по бизнес-планированию коллеги из другой компании-конкурента с блокнотами и неподдельными улыбками на сияющих лицах?

В общем, согласитесь, тема своих, приватных надежных видеопереговоров внутри компании — актуальна как никогда. Многим это нужно, но как организовать-то? У нас — получилось. Это можно сделать достаточно просто, если знать как :-) (изучив десяток RFC, стандартов w3c и их реализаций и докопавшись до причин).

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

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

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

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

Вы пробовали заказать в Макдональдсе жаренного на орудийном шомполе поросенка с домашним вином и, на десерт, девушку рядом с вами за столиком, для приятной беседы во время трапезы? Даже не думали об этом?? Вот-вот — статья как раз об этом, о стереотипах программиста и лени, двигающей прогресс. А если серьезно — в статье мы напишем очень полезный многим высокопроизводительный сетевой сервер на PHP за пару часов. Я совершенно серьезно :-)

В последнее время все больше говорят про «NoSQL» — прямо «модный» тренд образовался. «Технологию» начинают активно использовать известные авторитетные компании, в т.ч. в высоконагруженных проектах с немалыми объемами данных — и кто-то восхищается, а кто-то обливает себя бензином и факелом выпрыгивает с 35 этажа с криком: "SQL ACID forever!"


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

Рассмотрим популярные способы распределения сотрудником собственного рабочего времени (в порядке возрастания «уровня профессиональной ответственности»):

1. Нужно заниматься «видимым» достижением конкретных целей. Если задачу нужно сделать за неделю, а я могу за день — я потяну время, ведь я получаю зарплату и так.
2. Мне не интересно развивать чужой бизнес.
3. Да, видно, что для достижения целей необходимо еще пол помыть и выполнить кучу рутины — но я сдвинусь, только если за это дадут премию.
4. Для достижения цели нужно выстроить бизнес-процесс, понятно как, я могу описать необходимые шаги и варианты — чтобы сотрудник моей квалификации смог в принципе достичь цели аналогично. Но тогда я буду не нужен и этим воспользуются коллеги-конкуренты :-)
5. Понятно, как выстроить/оптимизировать бизнес-процесс. Также можно описать шаги и научить их выполнять менее квалифицированным сотрудникам. Но тогда я буду не нужен и, что еще страшнее — поставленной мне задачей могут заняться слабо квалифицированные, но более амбициозные/рвущиеся по карьерной лестнице (за славой и деньгами, например Вася Пупкин).

Так стоит ли стараться делать больше, чем нужно, внедрять и улучать бизнес-процессы?

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

Всем привет!

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

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

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

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

Всем привет!

Сегодня поговорим на тему как «профессионально сэкономить» деньги при использовании облачных сервисов Amazon Web Services при размещении веб-решений, адаптированных для России. Мы активно используем сервисы данного облачного провайдера для проектов компании почти 2 года и постоянно занимаемся оптимизацией расходов. Довольно странно, что важная тема оптимизации расходов на Amazon Web Services, очищенная от маркетингового булшита, как-то не особо представлена в сети. Постараюсь предметно поделиться опытом и обозначить явные выгоды и ошибки, которые следует учесть при проектировании веб-систем.

В последнее время в облачных средах и хостингах все чаще стали попадаться «виртуальные» жесткие диски. Техническая служба хостера может заверять, что «виртуальный» диск — быстрый, как десяток рейдов 10 (рейд 100 ;-) ) и держит сотни, а то и тысячи IOPS – однако MySQL заметно для клиентов тормозит. А как это доказать хостеру?

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

В статье я проиллюстрирую простую методику нахождения «точки опрокидывания» производительности виртуального жесткого диска, с использованием доступных в дистрибутивах инструментов – sysbench и iostat. Также мы измерим «точку опрокидывания» известных своей тормознутостью виртуальных дисков EBS от Амазона – как обычных EBS, так и Provisioned IOPS EBS (1000 и 2000 IOPS).

Вы отвечаете за стабильность работы веб-проекта на PHP. Нагрузка постоянно растет, добавляются фичи, клиенты довольны. В один прекрасный день начинают появляться загадочные ошибки…

Ошибки серверного софта

… которые программисты не знают как исправить, т.к. «ломается» серверный софт, например связка apache-PHP — а клиент получает в ответ на запрос страницу о регламентных работах. Веб-разработчик часто не обладает глубокими знаниями в программировании на C в unix/linux, а сисадмин нередко, к сожалению, глубже bash в систему не погружается. Настоящий хардкор :-)

Нестабильная работа серверных скриптов

Нередко, определенные страницы веб-проекта начинают сходить с ума. Например выполняться по 15 минут и выяснить, чем же они занимаются, непросто. В прошлом посте на данную тему я описал одну из методик определения, чем занимается PHP-скрипт на боевом сервере, но чувствуется, что нужен более мощный инструмент.

На практике я часто встречаю проекты, которые сталкиваются с подобным классом ошибок «серверного софта», и в команде не всегда знают, что делать. В логе apache часто появляются сообщения о нарушении сегментации (segmentation fault), клиенты получают страницу об ошибке, а веб-разработчик с сисадмином ломают себе голову, играются с разными версиями PHP/apache/прекомпилятора, собирают PHP из исходников с разными опциями снова и снова, пишут о багах, а им доказывают, что это баги не PHP, а их кода и так до бесконечности…

В статье я хочу рассказать как можно просто и быстро найти причину, почему PHP рассыпался на боевом сервере и устранить ее — не погружаясь в прекрасный мир системного программирования на C для unix :-) От вас потребуется желание и одна чашечка кофе.

Всем привет!

В последнее время наметился интересный тренд — быстрое «распухание» веб-проектов до бесконечности. Объем данных многих популярных сайтов растет все быстрее и быстрее, их нужно куда-то девать, при этом эффективно бэкапить (весело будет, если файлы на 500Т потеряются :-) ), и конечно супербыстро раздавать клиентам, чтобы все их могли качать, качать, качать… на высокой скорости.

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

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

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

Всем привет!

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

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