Є ідея гри чи геймінг-сервісу? Реєструйся на онлайн-хакатон 7.08! Призовий фонд — $3000
×Закрыть

Менеджмент highload проектов

Highload?

Что вообще такое highload (или высоконагруженные) проекты? Нет какого-то определенного порога, переходя через который проект становится высоконагруженным. Это скорее составное свойство, в которое входят несколько типичных характеристик:

  • Много функционала. Это может быть большой набор модулей, как на порталах или соц. сетях. Это также может быть одно специфической направление, но очень глубокое (например, youtube.com или twitter). Второе встречается чаще.
  • Постоянный рост. Неуспешные проекты не бывают высоконагруженными. Для того, чтобы стать highload нужен рост, постоянный и уверенный.
  • У Вас есть потребность масштабироваться. Это самый важный момент. И это не означает, что у Вас должны быть десятки миллионов просмотров страниц каждый день. Все дело в аппаратном обеспечении и необходимости масштабироваться. Если у Вас стоит один сервер за миллион долларов, который сможет обеспечить Вам десятикратный рост, то до этого момента Ваш проект не высоконагруженный. И наоборот.

Управление высоконагруженным проектом очень не похоже на управление обычным проектом. Почему?

  • Вам нужны специалисты экстра класса (как минимум очень хорошие специалисты). Таких найти трудно, даже за хорошие деньги. Рынок повернут так, что обычно именно они выбирают на какой проект пойти, а не наоборот.
  • Сравнительно большие бюджеты на аппаратное обеспечение и его администрирование
  • Стоимость ошибки очень большая. Как технической, так и стратегической
  • Пройдя порог высокой нагрузки, каждая новая функция проходит жесткую модерацию на предмет потенциальной угрозы производительности продукта
  • Постоянная работа над оптимизацией, вынимание подводных камней и избавление от бутылочных горлышек

Команда

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

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

Глава разработки

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

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

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

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

Минимизируйте и приоритезируйте

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

Типичная работа над новой задачей на highload проекте выглядит так:

  1. У нас появляется новая крупная задача
  2. Мы детально обсуждаем ее, расставляем приоритеты. Делаем взвешенную оценку важности каждого компонента новой функции для бизнеса и для продукта
  3. После этого думаем, что можно выкинуть из задачи — без чего можно начать, попробовать, протестировать эту функцию. При правильном подходе этот процесс позволяет сократить первоначальный объем работ в 2...3 раза.
  4. Приступаем к работе над задачей

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

Рефакторинг

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

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

Настройтесь на динамику

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

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

LinkedIn

14 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Владимир, спасибо... Учтем Ваши суровые замечания, только менеджера учить «что делать с кодом» мы не будем:)

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

Так, у мене був досвід роботи на такому проекті. В нашому проекті цьому приділялося дуже багато уваги, так як були жорсткі обмеження в договорі з клієнтами на рівень наданих послуг (SLA) — ми входили на вже зайнятий ринок і не могли пропонувати послугу гіршу ніж у вже існуючих конкурентів. Відповідно, після першої проблеми з навантаженням була проведена процедура розслідування (investigation), типова для американських менеджерів, і були введені процедури які запобігають появі таких проблем. Якщо у вас проблеми повторюються знову і знову, вам потрібно замінити вашого менеджера на більш компетентного (без жартів) або відправити його на семінар чи курси.

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

Я так розумію, що під словом “рефакторинг” ви розумієте значно більше, ніж в тому слові є. Суть рефакторингу, в оригінальному значенні, — це реорганізація коду без побічних ефектів.Я так розумію, що менеджер має на увазі — “треба щось робити з цим кодом, але я не знаю що — поміняй щось у коді, може стане краще”. Я думаю, що потрібно замінити менеджера на більш компетентного.

Не совсем понимаю какое отношение имеет датацентр к вопросу “справляется с нагрузками” — с нагрузками справляется система.

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

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

Я не зрозумів. Особливо не зрозумів: “то в этом виноват... тот, кто его выбирал”. Рішення, які були правильні в одних умовах (напр. 10Гб трафіку в місяць) будуть неправильні в інших умовах (10ПБ в місяць), і тому потрібно шукати проблеми, а не шукати хто “в этом виноват”.

Владимир, спасибо!

Робота на великому по трафіку проекті (кілька терабайт трафіку в день), це — активний пошук можливих проблем (напр. закритий тікет має містити розділ “можливі проблеми” та пропозиції по їх упередженню чи вирішенню); планування — планування змін, тестування, релізів, навантаження, перездів, замін, і т.д.; фільтрація змін — dev -> testing -> staging -> production; версіонування — поки нова функціональність розробляється і тестується, стара версія того самого коду підтримується паралельно поки не буде оголошена застарілою.

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

Дитячий садок. Рефакторинг — це зміна коду без зміни функціональності. Якщо в результаті рефакторингу у вас щось у функціональності міняється, то комусь треба за це відірвати яйця. Ви напевно мали на увазі оптимізацію коду?

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

Якщо тести показують, що через місяць датацентр А не справлятиметься з піковими навантаженнями, що приведе до збільшення часу обробки запитів, то необхідно провести аналіз варіантів вирішення проблеми — збільшення кількості серверів, оптимальніше використання вільних ресурсів (напр. використання європейського датацентру для обробки частини американського трафіку поки не будуть введені в стрій нові потужності). Код пишеться і відлагоджується довго — навіть тривіальна зміна може пройти весь цикл за 1−2 місяці, і немає ніякої гарантії що вдасться викинути частину коду, тому ставити в залежність роботу датацентру від можливого успіху програмістів ніяк не можна.

Не совсем понимаю какое отношение имеет датацентр к вопросу “справляется с нагрузками” — с нагрузками справляется система. Если датацентр не обеспечивает нужную пропускную способность, то в этом виноват уж никак не датацентр, а тот, кто его выбирал. Вы все правильно написали, но люди, которые принимают эти решения — это не саппорт датацентра, а Ваша команда.

Робота на великому по трафіку проекті (кілька терабайт трафіку в день), це — активний пошук можливих проблем (напр. закритий тікет має містити розділ «можливі проблеми» та пропозиції по їх упередженню чи вирішенню); планування — планування змін, тестування, релізів, навантаження, перездів, замін, і т.д.; фільтрація змін — dev -> testing -> staging -> production; версіонування — поки нова функціональність розробляється і тестується, стара версія того самого коду підтримується паралельно поки не буде оголошена застарілою.В статті якісь неправильні пріоритети.> В одно суровое утро к Вам приходит глава разработки и говорит: «привет, нам нужен рефакторинг такого-то модуля или мы не справимся с нагрузкой»...Дитячий садок. Рефакторинг — це зміна коду без зміни функціональності. Якщо в результаті рефакторингу у вас щось у функціональності міняється, то комусь треба за це відірвати яйця. Ви напевно мали на увазі оптимізацію коду? Якщо тести показують, що через місяць датацентр А не справлятиметься з піковими навантаженнями, що приведе до збільшення часу обробки запитів, то необхідно провести аналіз варіантів вирішення проблеми — збільшення кількості серверів, оптимальніше використання вільних ресурсів (напр. використання європейського датацентру для обробки частини американського трафіку поки не будуть введені в стрій нові потужності). Код пишеться і відлагоджується довго — навіть тривіальна зміна може пройти весь цикл за 1−2 місяці, і немає ніякої гарантії що вдасться викинути частину коду, тому ставити в залежність роботу датацентру від можливого успіху програмістів ніяк не можна.

Не хватает конкретики в каждом примере: рефакторинг — это хорошо, команда — это очень важно и т.п. Неправда ли, общие фразы?

+1. Какие-то отвлеченные философские рассуждения...

Все равно все пойдет не по плану

С этого и надо было начинать:)

у меня только один вопрос, почему «highload проектов»? по-моему это хорошие паттерны управления проектами вообще. единственным исключением может быть краткосрочные проекты, но ИМХО и их нужно делать хорошо., а статья таки хорошая, жду продолжения.

Я попытался донести правильную практику его проведения — понемногу и постоянно, а не все сразу

Фаулер вообще считает, что рефакторинг должен стать таким же рутинным, как и TDD. Но TDD пока не стало стандартом де-факто: -)

“доносить это до исполнителей”

слово “доносити” несе негативний віддтінок, я би вжив яку іншу фразу

+много за «доносить до команды свои приоритеты». В нашем прокте это был один из самых больших затыков.

Какой именно вид рефакторинга вас в таком проекте напрягает больше всего?

Меня не напрягает рефакторинг, совсем наоборот. Я попытался донести правильную практику его проведения — понемногу и постоянно, а не все сразу.

Какой именно вид рефакторинга вас в таком проекте напрягает больше всего?

Очень часто существуют определенные скрытые, не понятные для Вас зависимости внутри системы. Такие вещи трудно объяснить и попытки донести это до нетехнических людей обычно напоминают неубедительный бред

эти слова должны быть отлиты в золоте на первой странице сайта

Не хватает конкретики в каждом примере: рефакторинг — это хорошо, команда — это очень важно и т.п. Неправда ли, общие фразы? Есть такой прекрасный сайт http://highscalability.com/, где постоянно разбираются кейсы конкретных систем. Хотелось бы прочитать о чем-то подобном (только на личном опыте или опыте каких-то наших команд, а не в переводе).

Спасибо! Если Вас интересует техническая составляющая, рекомендую блог: http://highload.com.ua. А в этой статье я попытался выделить самые важные компоненты в работе. Понимание того, что важно, а что нет — это уже 50% успеха. Дальше планирую писать о более специфических вопросах.

Не хватает конкретики в каждом примере: рефакторинг — это хорошо, команда — это очень важно и т.п. Неправда ли, общие фразы? Есть такой прекрасный сайт http://highscalability.com/, где постоянно разбираются кейсы конкретных систем. Хотелось бы прочитать о чем-то подобном (только на личном опыте или опыте каких-то наших команд, а не в переводе).

Подписаться на комментарии