Вы тратите впустую большую часть времени, которое тратите на тестирование.
И я принимаю это. Вы предпочитаете тестировать все в за кулисами, потому что это дает вам чувство контроля. Большинство инженеров просто содрогаются от мысли о тестировании в продакшене. Но я думаю, что это потому, что они считают, что это или/или. Это не так.
Вы можете тестировать до развертывания столько, сколько захотите. А затем можно тестировать в проде столько, сколько сможете. Фокус в том, когда переключаться.
Наверняка вы не тестируете в производстве достаточно рано.
А Uber тестирует, и вот почему это так интересно.
Но, во-первых, зачем вообще нужно тестирование в продакшене? Разве мы не можем просто попытаться написать код настолько корректно, насколько это возможно в безопасной среде, а не рисковать реальными деньгами и реальным воздействием на реальных пользователей?
Можно. Но если вы делаете свою работу правильно, у вас быстро закончатся ошибки, которые можно найти в такой среде. Самые простые. Если вы их еще не нашли.
Смотрите, системы, которые вы обслуживаете, и которые обслуживает большинство из нас, существуют уже несколько лет. Некоторые — даже десятилетия. Это потому, что программное обеспечение не похоже на другие механизмы. Большинство машин со временем ломаются и разрушаются. Но программное обеспечение — это всего лишь информация: если она правильная, то так и остается. Аппаратное обеспечение нуждается в замене, но правильное программное обеспечение, работающее на нем, продолжает работать.
Программное обеспечение, если вы делаете свою работу правильно, со временем становится все лучше.
Какой удивительный механизм.
Вы, наверное, с презрением называете эти системы legacy, потому что со временем поддерживать программное обеспечение становится все сложнее. Но есть причина, по которой legacy программное обеспечение страшно менять. Мы хотим, чтобы оно продолжало делать то, что делает сейчас.
Быстрее переписать с нуля на новой технологии: как приложение Uber переписывали на Swift
Эта история о переписывании приложения Uber на Swift читается как настоящий детектив.
Ненавидьте его сколько угодно, но устаревшее программное обеспечение работает, даже когда оно внутри в состоит из полного хаоса.
Существует практически один способ создания высококачественного программного обеспечения. Используйте его и исправляйте все ошибки, которые сможете в нем найти. Со временем легкие ошибки исчезнут.
В отличие от человеческого тела, старое программное обеспечение очень здоровое. И если это единственный способ производить качественное программное обеспечение, то единственные болезни, которые вы найдете, будут экзотическими.
Платежные системы — это самая экстремальная версия этого. Перемещение денег всегда было наиболее очевидной сферой применения компьютеров в бизнесе. Поэтому программное обеспечение для работы с деньгами существует уже давно.
Именно с таким программным обеспечением приходится иметь дело Uber или любому другому торговцу. Что меня восхищает, так это то, что Uber делает это так, что многие инженеры содрогнутся.
Uber тестирует свои платежные системы в продакшене. И в этой статье я расскажу вам, как они это делают и почему это отличная идея.
Я Альваро Дюран, и это The Payments Engineer Playbook. Посмотрите пять минут в YouTube, и вы найдете тонны обучающих материалов, в которых рассказывается о системном дизайне платежных систем, которые помогут вам пройти собеседование. Но мало что научит вас создавать это критически важное программное обеспечение для реальных пользователей и реальных денег.
Я знаю это потому, что создал и поддерживаю системы, которые обрабатывают около 100,000 платежей в день. И мне довелось наблюдать за интересными разговорами о том, что работает и что не работает в платежных системах за закрытыми дверями.
В The Payments Engineer Playbook мы исследуем технологии, с помощью которых осуществляется перевод денег. Для этого мы отрезаем один кусочек и извлекаем из него практику.
Если вы не хотите тестировать платежи в продакшене, единственный выход — использовать staging среду.
А что нужно сделать, чтобы создать хорошую среду? Две вещи.
Во-первых, необходимо скопировать все производственные данные. Это дорого и является безрассудным нарушением конфиденциальности и безопасности, но это выполнимо. Во-вторых, вы должны эмулировать все действия пользователей. Staging должен стать правдоподобной версией ваших производственных систем.
Это напоминает мне потемкинскую деревню.
Стендовые среды не так полезны, как вы думаете. Нереально пытаться создать сложные копии реального мира. Ваши тесты будут настолько хороши, насколько вы способны скопировать его.
Мне очень нравится, как выразилась Черити Мейджорс: «стеджинг — это просто большая записная книжка». Только продакшн — это продакшн.
На самом деле, платежные провайдеры делают многое только в своих средах-песочницах. Как только вы начнете копать глубже, вы заметите большой разрыв между тем, как ведет себя песочница, и всеми сюрпризами, которые готовит для вас продакшн.
Но урок заключается не в том, чтобы требовать от провайдера платежей лучшего использования тестовых «песочниц». Они не станут этого делать, потому что для них это не имеет никакого значения.
Вместо этого урок должен быть таким: тестируйте свои платежные системы в «песочнице» в течение разумного количества времени. И ни секундой больше.
Именно так поступает Uber.
Uber перерос идею о том, что дефекты могут быть полностью устранены на этапе тестирования.
Вместо того чтобы напрягаться по поводу идеального релиза, Uber внедрил инструменты для раннего обнаружения производственных сбоев и быстрого и простого отката к заведомо безопасному состоянию.
Эти инструменты соответствуют трем ключевым концепциям: развертывание с ориентацией на бизнес-показатели, тщательный выбор региона первого развертывания и постепенное развертывание.
Развертывание с учетом бизнес-метрик
До того как начать The Pragmatic Engineer, Гергели Орош работал инженерным менеджером в Uber Money. В 2018 году он выступил с докладом о том, как Uber внедряет новые методы оплаты.
Для Ороша создание и внедрение нового метода оплаты — это две стороны одной медали.
Тестирование в песочнице — это то, что вы делаете на ранних этапах, потому что это ускоряет разработку. Но как только появляется возможность, вы переходите к реальным платежам с помощью реальных карт.
И для этого очень важны правильные инструменты отладки.
Орош упоминает внутренние инструменты Uber, Cerberus и Deputy, которые отвечают за две важные задачи при тестировании в производстве
- Выполнение запросов к реальным системам прозрачным способом
- Направление ответов в собственную систему
Но для меня самым важным моментом в его выступлении является следующее:
Для Uber каждое развертывание — это эксперимент.
Орош имеет в виду, что Uber осознает, что никто не знает, как на самом деле пройдет развертывание. Каждое развертывание — это предположение, и ваша задача — сделать из него выводы.
Поэтому каждое развертывание — это гипотеза о том, как будут выглядеть определенные бизнес-показатели с момента запуска.
Какие показатели измерять и какие мониторы для этого устанавливать, зависит от конкретной компании. Но метод оплаты, который не помогает вашей компании зарабатывать больше или тратить меньше, — это напрасные усилия.
Тщательно выбирайте регион первого внедрения
Не буду называть имен, но некоторые крупные успешные единороги в этом городе до сих пор разворачивают все свои Java WAR-файлы в продакшн сразу. Сразу. И они славятся тем, что они падают. Я понятия не имею, почему — Черити Мейджорс, Проектирование больших систем, когда вы не Google или Facebook
Бразильцы всегда первыми узнают о новинках от Facebook*.
Так задумано. Одно из следствий фразы «каждое внедрение — это эксперимент» заключается в том, что вы должны смягчить любые потенциальные проблемы, подвергая их воздействию как можно меньшее, но все еще значительное подмножество пользователей. Только если вы не видите ничего плохого, вы подвергаете его воздействию большее число пользователей.
Первый экспериментальный регион — это то, что можно сделать на начальном этапе. Способ сдержать влияние потенциальных ошибок.
Когда Uber внедрял Google Pay, они решили сосредоточить свой мониторинг на Португалии.
Это была страна:
- Маленькая, но не крошечная: Постепенное развертывание на 100% трафика страны было бы уже значительным числом.
- Находится в близком временном регионе к месту расположения команды (Амстердам): Это делало мониторинг в реальном времени очень удобным для них.
- С репрезентативными пользователями: Большинство португальцев платят в Uber через поток авторизации, как и почти все в мире.
- Где зависимость от провайдера сведена к минимуму: В Португалии старый Android Pay практически не был распространен.
Выбор первого экспериментального региона может сотворить чудеса, если вы принимаете платежи по всему миру.
Канареечные развертывания
При правильном подходе «канареечные» развертывания делают откат более частым, а не менее.
Как канарейки в угольной шахте, развертывание для подмножества пользователей должно выполняться часто. Вы предполагаете, что в тот момент, когда что-то будет выглядеть не очень хорошо, вы быстро откатитесь назад.
Ни одна стратегия развертывания не сделает каждое отдельное развертывание более безопасным. Что дают вам канареечные развертывания, так это возможность обменять множественные сбои в SEV-1 на несколько в SEV-3 и SEV-4.
И знаете что? Именно это произошло с Uber, когда они внедряли Google Pay. Поначалу цифры не сходились!
Осторожное внедрение в Португалии было разумным решением. Это позволило выявить ошибки в Google Pay.
Наш процент отказов был огромным. И мы сначала просто сказали: «Ну что, мы тупые? Мы что-то упустили?». Но нет, все оказалось в порядке. Казалось, что ошибок нет.
Поэтому мы поискали все это в Google. Сначала мы откатились назад и поговорили с Google. И, знаете, оказалось, что были некоторые проблемы на их стороне, и были некоторые проблемы на нашей стороне, и мы, конечно, все исправили. Но это заняло довольно много времени — Гергели Орош, Интеграция платежей в Uber: изучение кейса
Как вы собираетесь искать ошибки в Google Pay в тестовой среде?
Никак. Просто не сможете.
И вот что меня восхищает. С одной стороны, у вас есть инженеры, которые принимают всевозможные меры предосторожности перед запуском, потому что платежи — это то, что вы никогда не должны ломать.
А с другой стороны, есть компании вроде Uber, которые принимают всевозможные меры предосторожности после запуска, потому что понимают, что игра заключается в устойчивости, а не в том, чтобы никогда ни в чем не ошибаться.
Именно этот урок я извлек из того, как работает Uber. Тестирование перед запуском — это хорошо, но отдача резко снижается.
В какой-то момент лучше проверить свою работу на реальных пользователях и реальных деньгах.
Это напоминает мне алгоритмическую торговлю. Вы можете разработать стратегию, которая будет отлично работать, используя данные бэктестов, в условиях отсутствия ставок. Но реальный тест — это реальная вещь с реальными ставками. Ничто другое с ним не сравнится.
Вы должны думать о развертывании как об эксперименте. Только продакшен — это продакшен. Все остальное — это прелюдия.
Ну вот и все, на этом статья закончена.