SRE. Рецепты выживания в продакшене для инженера по надежности - Наталья Савенкова

Скачать книгу

align="center">

      38. Whitelist vs Blacklist

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

      Раньше уже была рекомендация “Катите фичу отключенной”, этот пункт расширяет тот совет – для фичей (и вообще любых штуковин в продакшене) удобно регулировать количество трафика не только с помощью включить/выключить, но и с помощью сегментирования. Например, сегментировать включение по региону, браузеру, каким-то кукам и тд.

      Таким образом, мы получаем схему:

      – накодить фичу

      – добавить к ней проверки включенности

      – выкатить релиз

      – через конфиг включить фичу на какой-то сегмент (использовать whitelist)

      – убедиться, что всё идет нормально

      – через конфиг включить фичу везде

      – в случае чего выключить фичу в каком-то сегменте (использовать blacklist)

      Кроме плавного регулирования нового трафика вы получите консистентный продакшн, и ваше поведение не будет “моргать” у пользователя в то время, пока релиз катится.

      Всегда приятнее контролируемо разрешать, чем запрещать вышедшее из-под контроля.

      39. Debug-mode

      Это вообще классика, на которую попадаются многие новички в веб-разработке. Совершенно нормально хотеть иметь какой-то способ, который позволяет через браузер получить информацию с бекенда. Например, использовать магический параметр в строке запроса, при упоминании которого в этом же браузере вы увидите желаемую информацию: переменные окружения, параметры запроса, параметры конфигурации и ещё много другого полезного. Что-то типа “https://mysite.com/?megadebug=1”.

      Или, может быть, вы хотите через get-параметр что-то включать!

      Подумайте пять раз об этом.

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

      Если решили оставить свой отладочный режим, то добавьте туда проверку авторизации, список разрешённых ip-адресов и чего-нибудь ещё, что посоветует СИБ (хотя, когда вы к ним придёте с такой идеей, то вполне можете нарваться на аудит системы и на тестирование знаний основ веб-безопасности). Ещё раз повторю, что это сомнительная идея.

      40. Вечная жизнь скриптов

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

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

Скачать книгу