Читать онлайн SRE. Рецепты выживания в продакшене для инженера по надежности бесплатно
Что внутри
С теплыми чувствами к моим коллегам из чата сарказма и котиков.
Здравствуй, читатель! Я Наташа и я инженер. Двадцать лет я работаю в IT, и мой путь начинался, как у многих инженеров того времени, с веб-мастера, а интернет тогда работал по телефонному проводу. Моя история опыта в индустрии крутится в основном вокруг бекенда и инфраструктуры.
На своей первой серьезной работе мы делали интернет-магазины, поэтому понятие надежности систем довольно быстро вошло в мою жизнь: если интернет-магазин не работает, то компания не может обслуживать заказы, а у его владельца прекращается поток денег. Для таких бизнесов IT-система – это в прямом смысле сердце. С тех пор мир поменялся очень круто и такое электронное сердце теперь есть, пожалуй, у всех.
В 2015 году я пришла работать разработчиком в крупную компанию и там стало очень быстро понятно: если у такой компании не работает ее главный сайт, то об этом сразу пишут в новостях. Это очень смешанные чувства: ответственность и гордость одновременно. В мире начал набирать популярность подход “Site Reliability Engineering”, в наш отдел в компании добавили админов, которые сели за соседний со мной стол… и надежность стала моим главным профессиональным интересом.
Что нужно знать о надежности:
– это не бесплатно
– это про готовность заниматься системой в любой момент
– это для педантичных
– это про постоянное извлечение уроков и изучение ошибок
Мир IT как будто меняется очень быстро, но фундаментально за 20 лет мало что изменилось: новые языки программирования каждый год, облачные технологии, serverless, zero-code, ML, базы данных и еще много всего нового, но внутри все те же сервера с процессорами, каналы связи, дата-центры и экскаваторы, которые неловким движением перерубают кабели в земле.
В этой книге собраны мои правила и рецепты, накопленные за все время работы инженером по надежности. Если для рецепта будет актуально, то буду добавлять в него что-то про деньги. В конце концов, мы делаем IT-систему для бизнеса, а бизнес всегда про деньги.
Рецепты в основном для крупных систем, но и для небольших тоже что-то будет полезно. Никакой логики в порядке глав тут нет. В книге много сленга и она рассчитана на инженеров с опытом работы.
В конце книги будет глава с пошаговым планом по созданию процесса "инцидент-менеджмент" в своей компании.
Основано на реальных событиях. Приятного чтения!
1. Сервис без вмешательства не переживает отключение части свитчей в дата-центре – это плохой сервис
Пришли к нам как-то сетевые инженеры из дата-центра и говорят: "нам нужно провести работы, для этого мы выключим пару свитчей, запланируйте у себя мероприятия". Обычно в таких ситуациях мы начинали какой-то трафик куда-то переключать, чтобы точно все хорошо прошло, а тут пообсуждали с коллегами и решили, что это неправильная ситуация и лучше мы посмотрим на последствия, а потом что-то улучшим. Всю систему оставили работать в обычном режиме, подготовились к "чему угодно" и стали наблюдать. Все прошло хорошо. С тех пор мы договорились, что на такие работы ничего сами трогать не будем, потому что система должна суметь сама.
Деньги: если система сама не сумела, то нужно оценить масштаб последствий для бизнеса, оценить варианты улучшения системы и принять решение об инвестициях в улучшение системы. Допустимо оставить как есть, если улучшения будут стоить неоправданно дорого.
2. Если какую-то процедуру делать страшно – делай ее чаще
У каждого инженера по надежности или администратора системы есть набор нелюбимых манипуляций в системе, которые делать страшно, но все равно иногда приходится. Я выработала для себя правило: если у меня есть такая процедура, то мне самой нужно ее просто регулярно повторять, чтобы она становилась привычной.
Почему это важно. У каждого из нас разная реакция на стресс: бей-беги-замри. Когда что-то сломалось, то запускается стресс. Когда нужно во время этого сломанного провести нелюбимую манипуляцию, то стресс увеличивается еще больше.
Как-то в моем хозяйстве была кластеризованная база данных. В работу базы вообще вмешиваться неуютно, но иногда (редко) надо было отключать некоторые из ее нод. Очень неприятная процедура. Я завела себе плановые работы раз в месяц по отключению нод: проверяла, что оно правильно работает, а заодно и повышала свой комфорт от процедуры.
3. Если мониторинг не пишет о проблемах – проверь, возможно он не работает вообще
На серверах лежат файлы, а у файлов есть права доступа. Мониторинг часто устроен так, что просто читает заданные файлы с логами.
Как-то мы переезжали с одних серверов на другие, и что-то пошло не так с правами доступа на файлы логов сервиса бекенда. В результате на некоторых серверах бекенд не мог писать свои логи. Нет логов – нет проблем. Мониторинг читал пустые файлы, не находил там никакой тревожной информации и всегда показывал "все в порядке". В это время на машинке оставался необновляемый код, а пользователь, попадающий запросами на эти сервера, видел вообще нечто очень странное. Нашли мы это случайно, к сожалению.
Отсюда следует: если мониторинг настроен по правилу "нет ошибок – нет проблем", то его стоит дополнить проверками, показывающими, что система действительно работает как задумано.
4. Регулярно проверяй все редко используемые аварийные средства доступа
В работе ответственного админа есть не только основные рабочие средства, но и резервные средства. Резервный интернет, резервный ноутбук, еще разные запасные способы, типа возможности залогиниться на сервер с телефона или загрузочной флешки.
Если запасными средствами не пользоваться, то рано или поздно они перестанут работать. Такова судьба запасных средств. Поэтому важно регулярно проверять, что эти запасные средства до сих пор функционируют и могут быть использованы в критической ситуации.
Например, можно сделать себе напоминание раз в две недели "проверить резервные средства" и там описать все, что нужно проверить: резервный интернет оплачен и работает, резервный ноутбук загружается и с него можно зайти во все необходимые системы и так далее.
5. Ходить на чужие разборы полезно
Во многих компаниях есть процесс публичного разбора крупных инцидентов (поломок). Это прекрасная практика, хотя и малоприятная для самих выступающих и участников инцидентов. Задача публичного разбора – сгенерировать с помощью большого числа инженеров меры предотвращения подобных поломок в будущем.
Если у вас в компании есть такое мероприятие – ходите туда и учитесь на кейсах своих коллег. Не надо ждать, когда случится инцидент именно у вас. Уникальных проблем по истине мало, а способов их предотвращения еще меньше. Изучайте, что случилось у коллег, анализируйте свою систему и выбирайте то, что разумно заранее реализовать в вашей системе.
Если такого процесса не существует, то подумайте о том, чтобы он появился. Вариант реализации такого процесса будет описан подробнее в последних главах этой книги.
6. Если результаты нагрузочного тестирования всегда одинаковые – это плохо
Если вы уже выкатываете релизы автоматически и в процессе выкатки есть стадия нагрузочного тестирования, то этот рецепт для вас.
В нашем релизном процессе был шаг выкатки на тестовый стенд, на который выкатывается сборка и нагружается трафиком. Чтобы не задерживать сильно релизный процесс, мы выставили довольно высокое стартовое значение нагрузки по принципу "ну, столько наш бекенд точно выдержит всегда". Затем система тестирования плавно увеличивала трафик. По мере повышения трафика стенд переставал отвечать на запросы, тестирование завершалось, а последнее успешное значение трафика принималось за результат нагрузочного тестирования. Если результат был допустим, то релиз выкатывался дальше в продакшн.
Долгое время наш результат тестирования был более менее стабильным. Потом добавили немного логики, потом еще немного, потом еще немного… А результат продолжал оставаться стабильным и релизы выкатывались в продакшн. Пока кто-то не пошел зачем-то посмотреть результаты тестирования своими глазами…
Что произошло на самом деле: по мере добавления новой функциональности и деградации производительности уровень допустимого трафика на стенд постепенно падал и упал ниже заданного стартового значения. В итоге, тестирование заканчивалось сразу же, как только начиналось, потому что стенд обслуживал несколько запросов и сразу же отваливался, а в результаты просто записывалось то самое стартовое значение. За это время производительность бекенда упала на 50%, но об этом никто не знал.
Как стоило бы сделать:
– начинать нагрузку трафиком с нулевого значения, но это сильно замедляет процесс релиза
– сделать параллельный процесс полного нагрузочного тестирования, чтобы не задерживать релизы
– считать тестирование успешным в случае, если финальное значение отличается от стартового
– считать долю успешных и неуспешных ответов от стенда
7. Регулярно проверяй всю редко используемую автоматику
Одним из основных принципов SRE является проактивное управление системами, что означает создание автоматических систем для защиты от инцидентов и поломок разного рода.
Вот несколько примеров таких автоматик:
– включение фильтрации трафика при срабатывании каких-то условий
– автоскейлинг ресурсов при росте нагрузки
– подключение кеширующих прокси
– отключение незначимых компонентов системы при пиковой нагрузке
– снижение скорости передачи данных
– увеличение времени ответа
– …
Список вариантов большой, но смысл понятен.
Что важно: речь идёт о автоматике, включающейся при некоторых условиях. Это означает в свою очередь, что это редкие ситуации. И это же означает, что механизмы должны работать безотказно. Как огнетушитель в вашем деревянном загородном доме с дровяной печью: если случится так, что он пригодится, то лучше будет, если он будет исправен.
Всю такую автоматику необходимо регулярно проверять! Сделайте себе расписание учений и протоколы проверки всех автоматик, на которые вы полагаетесь для обеспечения высокого качества своего сервиса в критических ситуациях.
В ходе этих регулярных проверок вы сможете обнаружить:
– Изъяны или слабые места до того, как они проявятся в результате реальных инцидентов.
– Изменения окружающей среды: по мере развития сервисов и инфраструктуры защитные механизмы могут потребовать корректировки или вообще перестать работать.
– Несоответствия требованиям аудита
– Неполадки в работе системы мониторинга и оповещений
– Отсутствие необходимых доступов
– … и ещё много всего.
Кроме того, участие в тестировании автоматики это хороший способ онбординга новичков в команде.
Каждая проверка – это возможность узнать больше о системе и о том, как она ведет себя в различных условиях, что в итоге приводит к совершенствованию защитных механизмов.
Деньги: тут крайне важно соблюдать баланс между “давайте подготовимся заранее к чему угодно и будем оберегать наш хрустальный дворец” и “ничего не делаем вообще”. Если вы не делаете систему жизнеобеспечения, не управляете ракетами и прочими критическими системами, то будет достаточно:
– проанализировать систему на предмет основных рисков
– оценить потери в результате реализации рисков
– спроектировать средства защиты
– оценить стоимость их реализации и поддержки
– применить здравый смысл и выбрать, куда потратить свои деньги
8. Рандомизируй учения
В прошлой главе было много слов про важность проверки систем и протоколы проверок. Назовём эти проверки учениями.
У любых учений есть один главный недостаток: они далеки от реальной катастрофы. И второй недостаток: они проводятся по протоколу.
К сожалению, если на учениях выявилась какая-то проблема у какого-то сервиса, то устранение этой проблемы означает только то, что сервис научился переживать сценарий учений. Это вовсе не значит, что если начать отключать что-то в другом порядке, то всё будет хорошо. И уж тем более не значит, что авария будет проходить по сценарию учений.
Вносите разнообразие в учения. Регулярно меняйте протоколы и форматы.
Изменение последовательности действий во время учений повышает шансы того, что отдельные люди и команды действительно понимают лежащие в основе принципы и готовы реагировать на неожиданные ситуации.
Вот несколько способов внести разнообразие:
– Использовать генератор случайных чисел, где это применимо
– Использовать временные вариации: менять время проведения учебных проверок, например, проводить их в разное время суток
– Вместо одного сценария, представить варианты, когда различные компоненты выходят из строя в разном порядке или возникают несколько проблем одновременно
– Замена ролей: менять членов команды ролями во время учений, это не только изменит динамику, но и покажет проблемы в навыках
– Изменение последовательности: менять порядок шагов в сценарии учений, чтобы увидеть, как участники адаптируются, смогут ли они по-прежнему эффективно решать возникающие проблемы, и как будет меняться поведение всей системы
9. Проектируй failover смолоду
Если у сервиса есть хоть какой-то шанс получить статус "должен работать примерно всегда", то лучше на это закладываться пораньше. Сами процессы стоит проектировать реентерабельными – рассчитанными на перезапуск, параллельный запуск и какой угодно другой запуск и работу. Лучше сразу предполагать, что любая часть проекта может выйти из строя, и резервировать её, если без неё нельзя обойтись. Во-первых, оно будет более-менее устойчивым, а во-вторых более горизонтально масштабируемым.
Сделайте визуальную схему всей системы и спроектируйте меры повышения надежности.
Деньги: резервирование системы увеличивает стоимость системы не в два раза, а существенно больше, так как для управления резервными схемами требуются инструменты координации.
Как и в случае с рецептом про автоматику, здесь стоит оценить последствия отказа конкретных компонентов, посчитать стоимость резервирования компонентов, а также стоимость систем координации. Только после этого принимать решение о создании резервирования.
10. Мониторинг трафика в диапазоне
Каждый раз, когда пользователь взаимодействует с приложением / веб-сайтом, отправляя данные или выполняя поиск, сервер получает запросы для обработки этих действий и предоставления информации. Это то, что мы в быту называем словом “трафик”.
Мониторинг трафика важен по нескольким причинам:
– ранняя диагностика проблем
– контроль за использованием ресурсов
– управление производительностью
– потребности в локальном масштабировании
– планирование будущего роста
– контроль затрат
Это не полный список причин.
Трафик может количественно меняться двумя способами: резко и плавно. Также трафик зависит от дня недели, времени года, времени суток, событий в мире и тп. Нет такого единственного абсолютного значения, отклонение от которого нужно считать проблемой, всегда есть диапазоны и колебания.
Для таких случаев используется комплексный мониторинг: по абсолютам и по тренду. У них разный принцип работы.
Мониторинг по абсолютному значению
Нужен мониторинг абсолютного значения сверху, а также снизу. Это может быть очень широкий диапазон, потому что верх определяют по максимуму в дни высокого трафика, а низ – по минимуму в дни низкого трафика. Необходимо изучить свою динамику трафика за достаточно большой период и на основании неё выбрать абсолютные значения.
Важно понимать, что если случится внезапный рост трафика в дни с обычно низким трафиком, то из-за ширины диапазона этого можно не увидеть, ведь значения останутся в зоне нормы. Для этого нужен другой мониторинг.
Мониторинг по тренду
Этот вид мониторинга предполагает некоторое накопление данных, и есть множество алгоритмов его работы: сравнение текущего уровня трафика с типичным уровнем для этого дня недели, накопление пятиминутных значений и сравнение их между собой.. здесь каждый сам выбирает нужный ему алгоритм, исходя из доступных технических средств и ситуации.
Важно понимать: если трафик растет достаточно медленно (в течение суток или недели, например), то мониторинг по тренду может не сработать – рост будет слишком плавный, также как плавным может быть и падение трафика. Здесь как раз поможет мониторинг по абсолютным значениям, который может сработать не так быстро, но лучше когда-то, чем никогда.
К сожалению, обычно мониторят только рост трафика, потому что боятся за нагрузку и работоспособность системы, но падение трафика не менее важно: нет трафика = нет пользователей. Нет пользователей = нет денег. Спад трафика может указывать на проблему с доступом пользователей, такую как проблемы с DNS, истек срок действия SSL-сертификатов или неработающая функциональность интерфейса, которая не позволяет пользователям выполнять запросы и решать свои задачи, выпуск новой версии и ещё целая куча разных причин. Но обычно падение трафика не говорит вообще ни о чём хорошем.
Поэтому рецепт такой: трендовый мониторинг делать для нахождения отклонений в типичном поведении, а пороговый мониторинг для крайних случаев, когда трендовый не способен определить отклонения. Мониторить не только рост трафика, но и падение.
11. Мониторинг среднего и min/max
В системах, где много серверов / узлов / нод (выберите любую единицу своей системы), невозможно мониторить каждую единицу. Поэтому для мониторинга значений делают агрегаты: перцентили, медианы и тп. То есть, некоторое среднее по больнице. Это разумный подход, но есть нюанс: обычно есть единичные отклонения, которые в агрегате будут не заметны.
Проблема может быть на одном хосте из сотни, но вы не узнаете об этом. «Но это же всего один хост» скажут многие. Какая разница – он может быть не «одним», а «первым» в череде выхода из строя целой группы. Это совершенно разные ситуации.
Для этого случая полезно иметь мониторинг хотя бы на минимальное значение и на максимальное значение, либо использовать 95ю, 99ю перцентиль и другие виды перцентилей.
Например, если вы мониторите среднее время ответа и используете его для управления масштабированием, то имейте ввиду: половина запросов будет работь дольше этого среднего. Тут возникает очень важный вопрос: а насколько дольше?
В общем, вот что нужно сделать для улучшения ситуации:
– разобраться с перцентилями: что это такое, о чем они говорят
– проанализировать различные значения перцентилей в своей системе
– решить, какую информацию вы хотите получать о системе
– выбрать правильные значения перцентилей для мониторинга
12. Не сажайте слона и моську в одну базу
Мир IT продолжает развиваться быстро. Более того, эта скорость набирает обороты. Чем быстрее вы покажете свою идею в виде продукта, тем больше шансов выиграть в гонке. Здесь менеджеры продукта в прямом смысле соревнуются с инженерами: кто же выиграет – скорость запуска или архитектура?
При появлении очередного проекта, который надо сделать быстро-быстро, первое приходящее в голову звучит так: "Хмм, у нас уже есть в продакшене монга-постгря-мускуль-чтоугодно, подселим новую базу для проекта туда!"
Не стоит так делать. А если делаете, то осознавайте последствия и риски. Получается связанность критических компонентов двух совершенно разных проектов. Пойдёте базу обновлять – накосячите и сломаете оба проекта. Придёт большой трафик обновления в один проект, база начнёт тормозить и сломает второй проект.
Вот ещё несколько очевидных проблем проблемы, связанных с такой практикой:
Когда несколько проектов обращаются к одной и той же базе данных, существует повышенный риск нарушения безопасности, так как все данные в базе данных, включая данные других проектов, могут быть скомпрометированы, если в одном проекте будут найдены уязвимости.
По мере роста числа проектов, использующих одну и ту же базу данных, становится сложнее масштабировать её для удовлетворения всех потребностей, так как сложно оптимизировать единую базу данных для противоречивых сценариев.
Управлять контролем доступа и разрешениями для нескольких проектов в рамках одной базы данных сложно, что создаёт новую головную боль при эксплуатации.
Возьмите себе за правило: один проект – одна база данных.
Деньги: С первого взгляда может казаться, что это лишняя работа и лишний расход средств. Помните, пытаясь сэкономить на таких решениях, вы берете эти деньги в кредит у себя будущего под высокий процент.
13. Расселяйте критичные сервисы и непредсказуемые сервисы
Представьте себе ситуацию, что у вас есть один бекенд. Например, он отвечает за оформление заказа на сайте, что является критической функциональностью вашего бизнеса. Нет заказов = нет денег. В какой-то момент времени вы приходите к отличной идее, что хочется получать немного больше информации о том, что делает клиент на сайте. Вы добавляете отправку событий со стороны клиента в свой бекенд. Это ведь такое красивое решение: запрос с клиента проходит через бекенд, обогащается там дополнительной информацией и записывается в специальную базу данных для сбора исторических данных. У вас уже есть опыт и вы учли предыдущий совет про раздельные базы данных.
Данные приходят, вы сделали на этих данных очень красивые дашборды о поведении пользователя… Но в один день что-то идёт не так и весь бекенд ломается от нагрузки, с которой вы ничего не можете сделать. Оказалось, что в последнем утреннем релизе фронтенда закралась очень маленькая ошибочка, в результате которой все загружаемые пользователями страницы начали отправлять десятикратное количество своих событий. И самое печальное, что они продолжают это делать, даже если пользователь не производит никаких действий. В прямом смысле вы сами себе сделали Ddos-атаку.
Эти критически важные сервисы – источник жизненной силы организации, и они должны работать непрерывно для обеспечения бизнеса. Сервисы с неконтролируемой нагрузкой требуют особого внимания для поддержания стабильности и производительности.
Отсюда следует правило: не смешивайте сервисы.
Дополнительные преимущества такого подхода:
Выделенные ресурсы для критически важных сервисов позволяют точно настроить их производительность, обеспечивая максимальную эффективность.
Для раздельных сервисов проще обеспечивать масштабирование.
Разделение сервисов повышает безопасность, ограничивая поверхность атаки и снижая риск для критически важных частей.
Техническое обслуживание и модернизация проводятся с минимальным воздействием на другие сервисы, что снижает количество простоев и сбоев.
Выделенные сервисы облегчают мониторинг и выявление проблем.
Деньги: этот подход позволяет гибко управлять затратами на обеспечение функционирования. Для критических сервисов разумно использовать динамическое выделение ресурсов и резервирование (если это допускает ваша архитектура). Для некритических сервисов это совершенно точно не нужно.
14. Exponential backoff
Ретраи (перезапросы) это такая сущность, которая способна сгладить шероховатости от целого ряда проблем, но при этом таит внутри себя шипы, которые при любом удобном случае добивают жертву, быстро уменьшая её страдания и любые попытки выжить.
Если у вас есть какой-то сервис, в который вы постоянно ходите с ретраями, пытаясь получить ответ – не надо его добивать, когда он уже сломался. Сломанный сервис вполне ясно говорит, что он не может обработать ваш запрос, и возвращает какую-то ошибку. Например, 500 или 503, или что-то еще начинающееся с цифры 5.
Это может быть в нескольких случаях:
– отвалился конкретно этот запрос по "какой-то причине"
– отвалился конкретно этот хост
– отвалился сервис целиком
– и еще масса других вариантов
В каких случаях ретрай сделает хорошо? Только в двух – отвалился конкретный хост с приложением, отвалилась сеть между вами и хостом. В других случаях вы будете ретраями прикладывать сервис больше и больше. Используйте exponential backoff (экспоненциальное откладывание) или любую другую методику, увеличивающую интервал между перезапросами. Таким образом, вы сначала потыкаетесь в несчастную жертву, но со временем дадите ей шанс восстать как феникс и удовлетворить ваши потребности.
С особенным вниманием этот совет стоит изучить разработчикам клиентских приложений… Что может быть лучше, чем ситуация, когда бекенд прилёг, а все клиенты начинают без перерыва пытаться всунуть ему всё новые и новые запросы? Самая интрига в том, что вы ничего не можете с ними сделать в моменте.
15. Учитесь деградировать заранее
Теперь немного про деградацию. Представьте себе, что ваши коллеги-маркетологи запустили рекламную акцию! С кем не бывает… Реклама, дающая новые заказы, это просто чудесно. Коллеги – классные ребята и всегда согласовывают с вами акции, к которым вы заранее готовитесь. Но что-то пошло не так и акция запустилась на сутки раньше, чем вы планировали добавить ресурсов в свою систему. Бекенд быстро сломался, в том числе из-за пользователей, беспрерывно нажимающих “обновить” в браузере. Деньги потрачены зря, вечеринку по поводу успешных продаж придётся отменить.
Совсем не сесть в калошу помогут средства деградации, которые надо сделать заранее. Если заранее не сделали, то сделайте после первого такого инцидента, когда вы задумались, что было бы неплохо иметь запасной парашют.
В случае прихода внезапного трафика у вас не будет никаких вариантов кроме: масштабировать и деградировать. Третий вариант – смириться и переждать – не рассматриваем.
Масштабировать сервис бывает довольно сложно. Сколько нужно будет времени, чтобы развернуть ещё ресурсов – кажется, это порядок минут в лучшем случае (и то, если вы заранее всё предусмотрели). Также важно оценить ваши возможности по оплате этих дополнительных ресурсов.
Деградацию предусмотреть достаточно легко. Это может быть автоматика или ручное управление. Автоматика работает быстро, но в ней могут быть ошибки случайного включения. Ручное управление – медленнее, но с вашим интеллектом и системой принятия решений.
Итак, к вам нагрянули пользователи. Причина вам неизвестна. Сколько это будет длиться – неизвестно. Нужно делать сразу всё: деградировать и масштабировать одновременно!
Деградация – это не "отвечаю через раз", это "отвечаю всегда, но не полной функциональность".
Желательно иметь несколько уровней деградации:
– всё плоховатенько – будем отключать эти малозаметные блоки, типа “сопутствующие товары” и “такие же как вы покупают”
– всё становится хуже – будем отключать функциональность по нарастающей важности, например “дата доставки” или “превью при наведении”
– все совсем плохо – отдаём статику типа “вот наши лучшие товары, на сайте технические работы”
Согласуйте со своим продакт-оунером сценарий деградации, напишите немного кода и сделайте выключатели, которые будете активировать по заранее согласованной с продакт-оунером последовательности. Он тоже хочет, чтобы сайт работал, пусть не в полную силу.
Деньги: заранее оцените ваши возможности по быстрому масштабированию сервиса в случае необходимости. Любое железо стоит деньги. Согласуйте это количество денег с тем, кто отвечает за финансы. А-то может легко получиться так, что вы очень элегантно обработаете рекламную акцию, получите заказы, но все заработанные деньги уйдут на оплату облачных квот.
16. Кэши и заглушки
Это продолжение темы про деградацию. Если у вас есть всякие реал-тайм данные, которые вы готовите на каждый запрос пользователя, имейте в виду: тот сервис, откуда вы их реал-тайм берете, обязательно перестанет работать. Если хотите жить красиво – имейте какой-то универсальный дефолтный вариант ответа. Если вы для каждого пользователя показываете "Такие же как вы покупали вот это", то в случае поломки начните показывать "Топ-5 покупок в нашем магазине". Это точно лучше, чем не показывать ничего.
Этот же способ можно использовать для режима осознанной деградации: если сервису тяжеловато, то переключитесь на показ данных из кешей в тех местах, где он уместен.
Состав этих кешей и заглушек необходимо согласовать с продакт-оунером.