Орфография, пунктуация и стилистика автора сохранены.

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

Главный принцип выливаний

Много лет назад на высшем уровне компании приняли решение: „Мы движемся очень быстро и иногда что-то ломаем. При этом не тратим время на классическую деятельность, как тестирование и строгий релиз-менеджмент.“

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

Самый главный график — bookings per minute. Время реакции на проблемы с ним: 3–4 минуты. После решения проблемы составляется формальный отчёт с разбором событий до минуты, и оценка пропавших букингов (по логам или оценка за прошую неделю).

На этом графике присутствуют различные паттерны: люди на спор отличают день недели[a], чётко видны сезоны, даже голы на чемпионате мира.

Потерянные букинги называются Innovation Costs — стоимость быстрого развития. Если отведённый на это бюджет превышается, СЕО пишет письмо «ребята, давайте поаккуратнее, тестируйте более консервативно», а когда несколько месяцев не выбирается — «что-то мы застаиваемся, давайте больше рисковать и пробовать новые штуки».

Тестирование: не получилось, и ладно

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

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

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

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

Source: bronevichok.ru