Всем привет!

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

Всем привет!
Хочу поделиться опытом организации резервного копирования файлов и MySQL/XtraDB в Amazon Web Services. Надеюсь, информация пригодится, особенно если вас «принудили» развернуть проекты в облаке, а время — ограничено :-)
Но прежде всего кратко пробежим технологии хранения данных, предлагаемые нам амазоном.

Всем привет!
Сегодня поговорим о техниках настройки резервного копирования файлов и MySQL/InnoDB/XtraDB в приложениях, развернутых в облаке, на примере Amazon Web Services.

В ходе разработки облачного сервиса Битрикс24 мы попробовали несколько схем резервного копирования, наткнулись на некоторые подводные камни архитектуры амазона и ограничения софта — однако все постепенно разложилось по полочкам и зажужжало :-)
Также внимательно рассмотрим вопрос инкрементального бэкапирования достаточно больших объемов данных (сотни гигабайт и больше), рейдов и конфигураций с InnoDB/XtraDB.
Но прежде всего в деталях разберемся в технологиях хранения данных, предлагаемых нам амазоном.

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

Добрый день, коллеги!

Condé Nast Digital Russia запустил мультимедийный проект для путешественников Condé Nast Traveller, который объединяет печатное издание, его цифровую версию, интернет-сайт и мобильное приложение. Проект стартовал 21 сентября 2011 года. В качестве веб-основы был выбран продукт компании 1С-Битрикс на веб-кластерной платформе, в качестве хостинг площадки, на основании наших рекомендаций — облако Amazon.

Веб-сайт www.cntraveller.ru содержит статьи о путешествиях и, главное, дает возможность оперативно найти информацию об отелях, ресторанах, местах для развлечений в разных странах мира, добавить на сайт собственные объекты, фотографии и отзывы, составить путеводитель для будущего путешествия. Все данные об объектах используются и приложением для iPhone «Condé Nast Traveller – Мои адреса», с помощью которого можно не только составить маршрут путешествия, но и, определив свое местоположение на карте, увидеть ближайшие адреса, рекомендованные редакцией журнала и посетителями сайта.

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

Коллеги, добрый день!

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

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

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

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

Вы — ProductOwner и отвечаете за группу веб-проектов. Когда сайты висят, недоступны или Клиентам выводится отладочная информация типа «Exception in object COrderController constructor… » — вам начинают звонить на мобильный, писать в твиттер и т.п.:

• топ-менеджер (или генеральный)
• коллеги, некоторые злорадствуя
• наши уважаемые Клиенты

Еще веселее, когда вас дергают… вечером за ужином, в иное время во время исполнения супружеских обязанностей, в отпуске :-)
Разберем популярные кейсы, ключевые принципы обеспечения доступности веб-проектов и попытаемся выстроить чеклист «Безмятежного отпуска».

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

Для начала вспомним отличия традиционной системы управления — репрессивной, от гуманной и творческой Agile модели.

Репрессивная модель управления

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

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



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

Давно подметил, что веб-проекты отличаются разными классами «свежести»…

Первой свежести

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

Для менеджера управлять развитием такого продукта, путем итераций + ТЗ, или путем работы в доверительном Scrum/Agile-режиме — приятно. Зазубрины некритичных рисков и фрагментальных сдвигов сроков сглаживаются общим ощущением надежности и жизнеспособности продукта. Менеджер горит идеями, богатеет фичами, а после регулярной реализации самых приоритетных задач получает дозу морального удовлетворения и оптимизма… и желает дальше работать в этой компании :-)

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

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

К сожалению, такие проекты/продукты встречаются… нечасто. Но — встречаются.

Второй свежести

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

Иногда в IT-компаниях или IT-подразделениях среди проектного менеджмента начинает появляться мнение, что разработчик после 25 лет — уже не тот (прим. автора — «не может быстро г… нокодить, а пишет медленно и аккуратно»), а программист после 30 — странное социальное явление, переросток (прим. автора — «сильно умный, придирается к требованиям»).

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

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

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

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

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

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

Конечно нет :-). Расскажу как выбрать эффективную стратегию, которая сохраняет профессиональную мотивацию и отлично прокачивает нас.

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

Разберем, какой оседлать собственное подразделение разработки и добиться успеха.

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

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

Вы понимаете, что происходит что-то странное, что проект «заболел», что можно было наверно этого избежать, если знать заранее…

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

Давайте подумаем, кому нужны гуманные методологии разработки? Команда, ответственность, храбрость, доверие…

Инвестор

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

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

Менеджер проекта

Ему нужно, чтобы проект:

а) Был довольно точно описан, согласован с Заказчиком и требования не менялись. Тогда его несложно оценить, распланировать этапы работ и водопадно выполнить.

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

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

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

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

Поехали.

Гибкие и «жесткие»

Есть гибкие методологии разработки (Agile), такие как Scrum, простые и постигаемые за пару дней. А есть «жесткие», увесистые, требующие многомесячного погружения, такие как RUP.

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

А чего бояться-то? Сумасшедшие бородатые специалисты говорят о процессах, артефактах, матрицах зависимости (Requirements Traceability Matrix) — а мы в рубахе, босиком, раз и… запрограммируем любой интернет-проект за 3 спринта! Ура, товарищи, к победе.

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