Доклад Алексея Рыбака, зам. главы разработки Badoo, на РИФ+КИБ 2013. Секция Комиссии по веб-разработке РАЭК «Организация эффективного производства интернет-проектов».

1. Эволюция разработки в Badoo
Рыбак Алексей
зам. главы разработки Badoo

2. Привет
Это ещё один рассказ о том, как
развивалась разработка в большом проекте
Кризисы роста: области ответственности,
производственные цепочки
Поделить/переделать, сохранив ценности и
пульс
2

3. Badoo - это:
Социальная сеть для встречи с новыми людьми
177М пользователей, ~30M MAU, ~10M DAU
Крупнейшие страны: Испания, Италия, Франция, Бразилия,
США
2 офиса разработки: Москва и Лондон
Миллионы строк кода, тысячи серверов
Стандартный стэк: Linux, NGINX, PHP, MySQL, Memcached,
C/C++
120 инженеров
3

4. Продуктовая интернет-компания
Программа в единственном экземпляре
Менее остро стоят вопросы совместимости
ПО и железа
Можно всё подбирать под себя и
подкручивать на ходу
4

5. Ценности продуктового стартапа
Быстрый либо мёртвый
Экспериментируем, скорость в ущерб
качеству
24х7, “легкий” саппорт
5

6. От стартапа к продуктовой
компании
Бизнес-инварианты
Лёгкий саппорт: разделение
ответственности, инфраструктурные
проекты
Максимально быстрый цикл разработки при
сохранении качества: производственные
цепочки
Проследим, как менялась разработка и
сохранялись инварианты
6

7. Кризисы роста
Кризис I: саппорт (10 – 20 чел, 2007)
Кризис II: дробление и новые роли в
организации (20 – 50 чел, 2009)
Кризис III: качество (QA) и перестройка
производственных цепочек (50 – 100+ чел,
2011)
7

8. Саппорт
Время программистов = время разработки продукта +
время на саппорт
Саппорт в широком смысле
− Поиск и мониторинг медленных/ненадежных мест
− Переделка архитектуры
− Инструменты для поддержки (мониторинг, деплой,
управление кластерами ...)
− Инструменты для разработки (автоматизация, ядро ...)
8

9. Саппорт: отдельную команду не строим
Пахнет “штрафбатом”
Вовлеченность и мотивация сотрудников
Твой софт – твой крест
− Ты накосячил – ты и правь
− Нагрузка вырастет в “стопицот” раз, вокруг всё миллион
раз упадет, наш (твой!) софт должен это пережить
− Пусть будут ошибки – давай быстро поправим, просто не
тупи и делай
9

10. Кризис I: саппорт (2007)
Отдельное направление: производительность,
надежность, мониторинг
Фейл: общие ресурсы
Фикс:
− A-team + C/C++ = Platform (инфраструктурные
проекты)
− Рост группы сисадминов/эксплуатации
10

11. Кризис II: дробление (2009?)
Оставить быстрым цикл разработки
Поделить команды функционально
Производственная цепочка по-прежнему
тривиальна: фигак-фигак, в продакшн!
Строим продуктовую команду
Не меняем сильно процессы, боимся сбить
ритм
11

12. Кризис II: дробление
Фейл: как “не пошёл” скрам
Функциональное дробление без перестройки
производственных цепочек
С/С++, Фичи, биллинг, A-team, мобильная разработка, бэк-
офис, антиспам/почта
Проблемы: лиды, перераспределение зон
Фейл: позиции “магов”
Проблема: качество
Рекрутинг и HR, системный ревью зп
12

13. Кризис III: качество (2011)
Перестройка производственных цепочек
Отдел качества, release engineering
Девелоперская инфраструктура: площадка,
continuous integration, управление релизами,
прочая автоматизация
Перестройка без остановки разработки продукта:
A-team
Параллельно: строим QA/RE
13

14. Сейчас: статусы задач (фичи)
 PRD <-> нет вопросов у программистов
 Задача разбита по компонентам (микрокоманды)
 Если нужно железо – есть сроки
 Сопутствующие задачи (BI, мониторинг)
 Код и тесты написаны, тесты прошли на девеле, ревью
 QA passed
 Переводы готовы (40 языков, ~10 основных)
 RE: тесты на стейджинге, деплой
 Деплой может быть поэтапным: на части пользователей -> метрики ->
везде
14

15. Кризис III: перестройка процессов
Подготовка в 2011, плотно - лишь в 2012 году
Деплой по фичам: svn -> git, “шоты” (фича) и
“билды” (релизы)
Девелоперская площадка: полная эмуляция 2х ДЦ
и базовых компонент
Утилиты деплоя и автоматизации, интеграция с
JIRA, доработка staging-инфраструктуры
Версионирование переводов
15

16. Кризис III: перестройка процессов
Строгий flow в JIRA + автоматизация
Unit-тесты: 15000 тестов за 3 минуты
Selenium-тесты: 200 тестов за 20 минут
2 релиза в день: утром и после обеда
Стогие стандарты кодирования, заголовки
(модуль-команда-человек), покрытие кода
A-team -> передача сисадминам и релиз-
инженерам
16

17. Выводы (1)
 Методологии не очень существенны
 Без фанатизма и сектантства. Waterfall?
Пускай. Не-agile? И что?
 Backlogs, burn down charts, stand-up
meetings
17

18. Выводы (2)
Инфраструктурные проекты неизбежны
Технический долг: время разработки
продукта -> отдельная команда. A-team у
нас – не DevOps
Без QA можно обойтись, и долго. Качество
на этапе релиза vs качество в “продакшене”
(ошибки, мониторинг)
18

19. Выводы (3)
Если QA неизбежен (число людей): чем
раньше строить QA – тем лучше
Перестройка цепочек – наиболее
болезненные процессы, с отдельной
командой - лучше
19

20. Спасибо!
Ваши вопросы, пожалуйста!
 a.rybak@corp.badoo.com
 http://habrahabr.ru/company/badoo
 http://facebook.com/BadooMoscow
 http://twitter.com/BadooDev
20