Наверх ▲

Эволюция разработки крупного интернет проекта

Ярослав Сергеев Ярослав Сергеев Исполнительный директор компании Wamba, ранее - php-разработчик, архитектор, тимлид, IT-директор и, наконец, CEO. Знает Wamba, как никто другой (речь идёт как о технической стороне проекта, так и о команде сотрудников).

Ярослав Сергеев: Здравствуйте, меня зовут Ярослав Сергеев. Сначала скажу пару слов, о чем будет доклад и почему я считаю, что вам стоит его послушать. В проекте "Mamba" я работаю в течение нескольких лет. Года 4 назад я пришел разработчиком в "Mamba". Постепенно я дорос до технического менеджмента, то есть собственно руководства командами разработчиков.

4 года назад "Mamba" была совсем другой и в плане структуры команды, и в плане масштабов самого проекта и динамики его развития. По мере того как "Mamba" росла, росла и ее команда. Постоянно находились какие-то "грабли", на которые мы наступали.

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

Итак, из чего состоит моя история? Начнем с действующих лиц.

  • Первые лица – это топ-менеджеры, акционеры компании. Это люди, которые задают вектор развития. Это люди, которые управляют стратегией, говорят, "в какую сторону копать".
  • Вторае группа участников – это проект-менеджеры. Это тактики, люди, которые определяют, "как именно надо копать". 
  • Технические менеджеры – это руководители команд разработчиков. Это, по сути, трафик-менеджеры ресурсов внутри компании.
  • Про разработчиков, я думаю, не стоит ничего рассказывать. 
  • Какие задачи мы выполняем? Конкретно "Mamba" – это один большой сервис. У нас нет множества разных проектов. Мы делаем сервисы внутри системы. Все наши проекты – это части одной большой системы.

В проекте "Mamba" все начиналось точно так же, как у всех, наверное. Схема подчинения выглядела таким образом. Все очень просто. Есть технический директор (CTO) и разработчики (Develop). В принципе, все очевидно. 

Так выглядит направление задач, которые решаются внутри системы. Топы формулируют, куда "копать". Проект-менеджеры решают, как "копать". Они идут к техническому директору и говорят: «У нас есть задачи. Их надо начинать выполнять. Дай нам, пожалуйста, разработчиков». Технический директор смотрит на приоритеты, советуется с проект-менеджерами по поводу того, кому что важнее и нужнее, и выделяет разработчиков.

Я думаю, такая система всем так или иначе знакома. Наверное, многие из вас работают именно по ней. Либо в качестве третьего, либо в качестве четвертого звена (персонажи с коробочками).

Чем это хорошо?

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

Будучи в курсе того, какие есть задачи и в каком порядке они решаются, технический директор может разрешать любые конфликты проект-менеджеров, которые случаются очень часто. Два человека приходят и говорят: «У каждого из нас очень важные задачи. Их нужно сделать завтра, а ресурсы есть только для одного человека». Технический директор может быть третейским судьей. Это профит. 

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

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

По своему опыту могу сказать: меня хватало, пока разработчиков было до десяти человек. Мой максимум 10-12 человек. После этого у меня мозг начинал "вскипать". Следить за всем становилось все сложнее и сложнее.

Узкое место этой системы очевидно. Если на замечательного и прекрасного Монтгомери Бернса упадет кирпич, то все будет очень сложно. Ладно, кирпич – это плохой вариант. Хороший вариант: этот человек уходит в отпуск. 

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

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

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

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

Существует еще и проблема роста. Возьмем "команду", состоящую из одного разработчика. Положим, он работает 8 часов в день. Действительно 8 часов сидит и работает. В этом случае он, грубо говоря, делает одну ошибку раз в две недели. Все люди, все ошибаются, а если работать по 8 часов в день, то понятно, что пропорция может быть другая. Примерно так по ощущениям. 

Теперь представим, что разработчиков у нас стало вот столько. Как это выглядит для бизнеса? Положим, есть один разработчик. Он делает одну ошибку, о которой я упоминал. Все думают: «Ну, ладно, нормально. Подумаешь, в системе ошибка один раз в две недели. Ничего страшного».

Вдруг начинает появляться по три ошибки в день. У бизнеса создается такое впечаление, что чем больше разработчиков мы берем, тем больше проблем. Хотя, на самом деле, пропорция абсолютно не изменилась. Картинки абсолютно одинаковые.

Человек из бизнес-отдела приходит к техническому директору и говорит: «Слушай, почему у нас так много ошибок? Все время что-то ломается... Плохих специалистов берем, что ли? Почему так получается?» 

С этим я боролся довольно долго. Покажите мне систему, в которой нет ошибок и ничего никогда не ломается! Но отчасти я ее победил.

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

Первая причина очевидна. Вряд ли стоит ее как-то комментировать.

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

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

У "Mamba" исторически была проблема с квалификацией проект-менеджеров. Думаю, это не какие-то специфичные для нас проблемы. Проект-менеджеры не очень любили писать ТЗ, что-то подробно расписывать и думать до того, как начали что-то делать. Им больше нравилось думать уже в процессе. 

Соответственно, проект-менеджер приходил к техническому директору и говорил: «Дай мне разработчика». Тот отвечал: «Он тебе зачем?» – «Я сервис хочу сделать». – «Какой сервис?» – «Я ему расскажу. Ты мне дай, а я ему расскажу все». Техническому директору приходилось каждый раз напоминать: «Нет, ты иди сначала напиши, а потом приходи, и я тебе дам разработчика».

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

Понятно, что это и разработчиков демотивирует, и ресурсы расходует не очень эффективно. Это относится и к четвертому пункту.

Далее. Тестирование. На самом деле, мне очень жалко, что на "HighLoad" исчезла секция «Тестирование». Она была на программном комитете, но нужного количества докладов не набралось. Конкретно мне очень интересна тема различных аспектов тестирования больших систем. Это еще одни "грабли", по которым мы в "Mamba" долго ходили и, наверное, ходим до сих пор. 

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

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

Эффективность мониторинга зависит от его наглядности и показательности. Да, ты видишь, что график "проседает". Если причина неизвестна, толку от графика мало. Или еще хуже: ты видишь график, а что он показывает, тебе не очень понятно. Такое бывает, когда, допустим, меняется специалист, работающий с этой системой. Ему сказали: «Смотри на график. Когда он "проседает", это плохо». График месяц не "проседал", а потом вдруг начал "проседать". Новый специалист понимает, что плохо, но не знает, что делать.

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

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

Матричная схема подчинения

Каким образом она выглядит? Разработчики – это все те же ребята с коробочками. Но теперь они подчиняются не одному человеку, а двум людям. Это руководители групп (Team Leads), вторые люди – это проект-менеджеры (PMs). Cтратегические задачи "спускаются" от топ-менеджеров двум главным руководителям. Это руководитель проектного офиса (Product Director) и тот же самый технический директор. У каждого из них в подчинении находятся руководители второго звена. У руководителя проектного офиса это проект-менеджеры, у технического директора – это руководители рабочих групп. 

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

У каждой из этих групп есть руководители. Team leads – это технические руководители, которые помогают техническому директору во всех вопросах технического менеджмента. 

Каким образом двигается задача? Задача спускается от топ-менеджеров одновременно руководителю проектного офиса и техническому директору. Руководитель офиса следит за тем, чтобы проект-менеджеры писали более или менее внятные технические задания. 

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

По сути, руководители групп в сумме выполняют всю ту работу, которую в линейной схеме делает технический директор. Они занимаются проверкой оценок, которые разработчики дают задачам. Разработчику показали ТЗ, он говорит: «Я буду два месяца делать». PM – не технарь, откуда он знает, два месяца там делать или две недели. Может, разработчик его обманывает. В этом состоит роль технического менеджера. 

Также требуется анализ технических заданий на предмет недостатков, которые там есть всегда. Они остаются даже после того, как технические менеджеры приняли ТЗ в работу. Это тоже непобедимая штука – невозможно проектировать сервисы "в голове" прямо до запятой. В процессе работы так или иначе возникают уточнения. Главное, чтобы переделок не было. Уточнения – это хорошо.

Какую еще проблему, помимо масштабируемости, решает эта схема?

В "Mamba" есть такое подразделение, как рекламный отдел (sales). С ними у меня всегда были проблемы следующего рода. 

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

Когда мы переходили на матричную схему подчинения, я им выделил отдельную рабочую команду и сказал: «Вот, у вас есть два человека, которые делают ваши сервисы. Если вы продаете кому-то нечто с запуском в течение недели, и таких проектов пять штук, вы сами думайте, как вы это будете разруливать. У вас ограниченный ресурс, вы сидите в своей клетке и сами несете ответственность». 

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

Какие сложности возникли при переходе на матричную схему?

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

Принцип деления

Была команда (положим, 20 человек). Их надо поделить на рабочие группы. Как их делить? «Я с Васей дружу. Мы два сильных разработчика. Мы хотим быть в одной рабочей группе». По-хорошему, в рабочей группе пропорция сильных и начинающих разработчиков должна быть примерно одинаковой, чтобы команда могла эффективно решать свои задачи. Когда приходится "растаскивать" людей, они начинают грустить по этому поводу.

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

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

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

Почему важно, чтобы люди, которые разрабатывают сервисы, и люди, которые их чинят, были разными?

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

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

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

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

Теперь снова вспоминаем о проблеме "упавшего кирпича". Я думаю, все с ней сталкивались. Беда начинается, когда супергуру ломает ногу на роликах (у нас такое тоже случалось) или на футболе. Или в отпуск уходит, или женится. Тогда все выглядит печально. Ребята, поддерживающие код, принимают жалобы у пользователей и вздыхают: «У нас 10 тысяч жалоб! Что же делать? Он доки-то не написал. Он на Канары уехал с женой». 

Если сервис разрабатывают и поддерживают разные люди, то о сервисе всегда знают как минимум два человека – тот, кто его делает, и тот, кто его чинит.

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

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

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

Тот ее прочитал и говорит: «Тут ничего непонятно. Тут непонятно, тут непонятно и вот там в двух местах непонятно. Дописывай». Разработчик дописывает, документ в итоге принимается. Он сам в этом заинтересован, потому что руководитель группы его "прессует": «Надо следующий сервис делать. Сдавай этот быстрее». 

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

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

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

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

Раздать проект-менеджерам всю команду целиком невозможно. Все равно общие ресурсы остаются. Грубо говоря, какой-нибудь клиентсайд делить очень сложно, да и не нужно. Тестирование тоже делить не очень нужно. Понятно, что в любых сервисах нужна верстка, нужен JavaScript, Flash иногда нужен. Естественно, все сервисы нужно тестировать. Вопросами разделения этих ресурсов все равно приходится заниматься. До конца команду не разделить.

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

Собственно, та самая проблема ответственности проект-менеджеров заключается в следующем. Теперь проект-менеджер за свои задачи отвечает сам. К примеру, к нему придет кто-нибудь из топ-менеджеров или руководитель офиса и скажет: «Слушай, ты обещал запустить сервис в следующем месяце. Почему ты его не запустил?» Он уже не скажет: «Мне ресурсов не дали. У меня нет программистов, я не могу ничего делать». 

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

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

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

Самое главное – много руководителей. Многие, когда приходят устраиваться на работу, спрашивают: «Какие у вас есть перспективы?». Ты говоришь: «Какие перспективы? Чего именно?» – «Для карьерного роста». Честно говоря, меня всегда настораживают такие люди, которые про карьерный рост спрашивают раньше профессионального. 

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

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

 

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

"Mamba" развертывается каждый день. Для многих это звучит достаточно бредово. Для меня тоже. Тем не менее. Мы планируем переходить на более редкие развертывания, но сейчас они происходят каждый день. Так было, наверное, последние года два. 

Каким образом можно развертываться каждый день и так, чтобы при этом система не падала?

Мой рассказ будет строиться на цикле нашего рабочего дня. Начну я где-то примерно с середины дня, потому что так будет логичнее. Хорошо, я рад, что это оказалось шуткой.

Оговорюсь: этот график касается тех людей, которые участвуют в развертывании. Понятно, что не вся команда и не все рабочие группы каждый день выполняют развертывание. Но примерно 10-15 % команды выполняют. Конкретно этот цикл касается тех, кто участвует в развертывании текущего дня, и тех, кто его технически делает. Развертывает все у нас руководитель техподдержки.

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

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

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

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

Утром мы приходим и смотрим, что получилось в результате ночных тестирований. Есть ли там отчеты, все ли там нормально работает. Бросаем последний взгляд на то, что у нас получилось и что мы будем выкладывать. Где-то с 12.00 до 12.30, грубо говоря, у нас идет развертывание. Далее идет время реакции – два часа. Техподдержка открывает много-много всяких разных графиков и смотрит на них. Это то, о чем я рассказывал: важно иметь мониторинг. Важно иметь много графиков и понимать, что на них отображается, и что делать, если на них вдруг что-то не так. 

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

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

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

На этом все.

Давайте я расскажу, о чем вы хотите спросить.

Вопросы и ответы

Вопрос из зала: Ярослав, у меня к тебе пара вопросов. В основном, про документацию. Вопрос номер раз. Правильно ли я понимаю, что у вас документация по системе имеется только по тем опциям, которые были сделаны после момента, когда вы начали писать документацию? Или вы сделали до?

Ярослав Сергеев: Нет, собственно документацию всегда пытались писать. Это нормальная схема, когда все знают, что надо писать документацию. Это круто. Все знают и даже иногда ее пишут. Но вопрос всегда в качестве. 

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

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

Вопрос из зала: "Кору" вы описали? Не только какой-то сервис, который видят пользователи, но и какие-то внутренние решения. По ним тоже есть документация?

Ярослав Сергеев: Естественно. Это документация в виде Entrance Guide. У нас есть пакет документов. Когда приходит новый человек, мы говорим: «Дружище, вот тебе много доков со всякими картинками и так далее. Читай». Там описаны та же самая "кора", типовые решения задач, что где как разложено, как что работает в общем виде. Это есть, это всегда читают  люди, когда приходят на работу. Это такая ключевая штука, которой не может не быть, на мой взгляд.

Вопрос из зала: Ясно. Тогда вопрос номер два. Пробовали ли вы как-то работать с техническими писателями? Чтобы написанием документов занимались не разработчики, а именно технические писатели. 

Ярослав Сергеев: Я знаю, что бывают такие схемы. Мы их не интегрировали. По сути, технический писатель – это что-то типа нашего руководителя группы, только он не занимается разработкой. Он "проксирует" менеджера и технаря, занимается сбором требований на сервис, пишет ТЗ за проект-менеджера, пишет проектную документацию. Когда разработчик все это запрограммирует, он расспрашивает его и пишет за него документацию. 

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

Вопрос из зала: Вроде все ясно. Спасибо.

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

Ярослав Сергеев: Есть.

Вопрос из зала: Какое отношение между разработчиками и поддерживающими?

Ярослав Сергеев: Смотря кого считать разработчиками.

Вопрос из зала: Тех, которые код пишут.

Ярослав Сергеев: Код все пишут. Давай расскажу подробнее. Как я говорил, у нас есть команда, которая занимается чисто разработкой новых сервисов. В нее на данный момент входит 8 человек, но мы ее будем расширять. Есть поддерживающие код специалисты, их на данный момент пятеро. 

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

Вопрос из зала: Да, я понимаю.

Ярослав Сергеев: Там и разработки, и поддержка внутри. Грубо говоря, биллеры занимаются и разработкой, и рефакторингом, и поддержкой биллинга целиком. Техподдержка и разработка занимаются именно ключевыми сервисами проекта "Mamba".

Вопрос из зала: Понятно. Грубо говоря, вы разделили разработку и поддержку там, где покрытие очень широкое. Там, где есть какая-то узкая специализация…

Ярослав Сергеев: Да, там все вместе.

Вопрос из зала: Хорошо. Второй вопрос. Развертывание каждый день. Делать это эффективно, как мне кажется, каждый день тяжело. Наверное, должен быть релиз-инженер, какая-то команда.

Ярослав Сергеев: У нас релиз-инженером работает начальник техподдержки.

Вопрос из зала: Я пытаюсь понять, сколько ресурсов тратится на то, чтобы обеспечить такой цикл каждый день. Почему не раз в два…

Ярослав Сергеев: Собственно, ресурсов требуется ровно столько, сколько людей хотят "развертываться" в этот день. Кто хочется "развертываться", в этом участвует. 

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

Ярослав Сергеев: Нет, мне так не кажется. Я хочу сделать более редкий цикл. Но и это будет, наверное, не раз в неделю.

Вопрос из зала: Я понял. Почему?

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

Вопрос из зала: Почему сразу не сделали, например, два релиза в неделю? Почему сразу каждый день?

Ярослав Сергеев: По-моему, очевидно. Это было эволюционно. Надо понимать одну вещь. До того, как я стал IT-директором, предыдущий технический директор был, скорее, менеджером. Он не был разработчиком. Он не лез в технологические вопросы. Когда я пришел в "Mamba", мы развертывались, наверное, раз в неделю. 

Приходили проект-менеджеры и говорили: «У нас ошибки, давайте будем два раза в неделю развертываться. Накапливается достаточно большой пул. Объем развертывания будет меньше». «Ну, ладно, давайте два раза». Таким образом, в течение пары-тройки лет это все пришло к развертываниям каждый день. Даже при той схеме, о которой я рассказал, большинство ошибок мы находим. Та проблема, когда есть один "косяк" в две недели, умноженный на 40 разработчиков, отчасти решается. Но только отчасти. Все-таки для повышения стабильности я хочу развертываться пореже. 

Но очень тяжело к этому приучить бизнес-составляющую. Те же самые рекламщики привыкли к тому, что мы, допустим, выложили рекламу Chrome на Mail.Ru. Mail.Ru вдруг это не понравилось. Они сказали, что они считают Chrome своим конкурентом. Нам надо срочно остановить рекламу и спецкампанию. Если мы разветываемся раз в неделю, это все будет висеть неделю.

Вопрос из зала: Можно "докладки" организовывать.

Ярослав Сергеев: Где граница между "докладкой" и "раскладкой"?

Вопрос из зала: Там могут быть разные циклы тестирования и прочего. Ладно, я понял. Хорошо. Спасибо.

Ярослав Сергеев: Да, я эту проблему хочу решать. Но не раз в неделю, наверное, будем "развертываться". 

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

Ярослав Сергеев: PHP-доки, конечно. Там есть "собиралка" этих PHP-доков. Выстраивается "дерево".

Вопрос из зала: То есть сначала документацию делаете, а потом с нее классы сразу, автоматически?

Ярослав Сергеев: Нет-нет-нет. 

Вопрос из зала: Подскажите, является ли у вас разработчиком руководитель группы?

Ярослав Сергеев: Да, является.

Вопрос из зала: "Code review" лежит на команде или только на руководителе группы?

Ярослав Сергеев: На руководителе группы. Он где-то примерно в равной степени занимается техническим менеджментом и программированием. 

Вопрос из зала: Ярослав, подскажите, пожалуйста, состав групп разработки всегда статичен? Или в зависимости от ситуации "на полях" ключевые разработчики могут переходить из одной группы в другую?

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

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

Вопрос из зала: Каково примерно минимальное и максимальное количество сотрудников в одной группе разработчиков?

Ярослав Сергеев: Минимальное – два. Максимальное – восемь. Где-то так.

Вопрос из зала: Меня зовут Павел. Как у вас организовано мотивирование сотрудников и набор в группу поддержки? У нас тоже есть группа поддержки, это очень острая проблема.

Ярослав Сергеев: Тоже есть проблема, что никто не хочет ошибки править? Мотивирование. Во-первых, через поддержку проходят все новички. Так или иначе, группа всегда наполнена людьми. Не так часто ко мне приходят люди, которых можно взять и посадить в какую-нибудь рабочую группу. Если среди вас такие люди есть, это прекрасно, приходите.

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

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

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

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

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

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

Вопрос из зала: Спасибо. 

Вопрос из зала: Добрый день! Меня ховут Глеб. Как вы разделяете задачи разработки и поддержки?

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

Но это бывает не только с разработкой и поддержкой. Это бывает и между другими рабочими группами. Раз – что-то сломалось, они говорят: «Пусть это техподдержка правит». – «Нет, это у вас сломалось, на русском все хорошо». Да, "третейский судья" в этом деле тоже нужен. 

Вопрос из зала: Задача в разработку или в поддержку уходит именно через технического директора, а не от прочих мененджеров?

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

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

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

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

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

Ярослав Сергеев: Я не очень понимаю, зачем это нужно. Не надо, чтобы все участвовали в разработке и в поддержке. Я объяснял, почему не надо. А если там циклы не укладываются в неделю по задачам? Кто-то месяц сидит и сервис делает, а мы взяли и поменяли всех местами. Что тогда делать?

Вопрос из зала: Можно пробовать разные варианты. То есть, вы не рассматривали такой вариант? Именно четко выделена команда на поддержку, и все?

Ярослав Сергеев: Да. Да.

Вопрос из зала: Понятно.

Ярослав Сергеев: Но это хорошо работает. Чтобы решать проблему, надо, чтобы проблема была. Все, наверное. Спасибо, господа.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Адам Кнапп (Adam Knapp)

Адам Кнапп (Adam Knapp)

Директор по развитию технологий облачного хранения в GoDaddy.com.

Рассказ о технологиях облачного хранения в GoDaddy.com, о проблемах, их решениях, также немного о процессах и управлении проектом.

Андрей Дзыня

Андрей Дзыня

Эксперт и тренер в области автоматизации тестирования ПО. Со-организатор сообщества автоматизаторов Automated-Testing.info. Ведущий инженер по автоматизации тестирования в компании Lohika Systems.

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

Михаил Якшин

Михаил Якшин

Координатор команды разработчиков кластерной части Openstat.

Доклад Михаила Якшина об управляемом code injection в Apache Hadoop в системе интернет-статистики Openstat.