SRE. Рецепты выживания в продакшене для инженера по надежности. Наталья Савенкова
align="center">
38. Whitelist vs Blacklist
Представим себе, что вы сделали крутую фичу и собрались катить релиз с этой фичей. Фича абсолютно прекрасная и логически продумана отлично. Как только вы её выкатите, то восторг пользователей будет неописуем. Итак, релиз катится, фича становится доступной пользователям. Трафик наливается, пользователи радуются, продакшн ломается. С этой истории можно начинать многие главы в этой книге.
Раньше уже была рекомендация “Катите фичу отключенной”, этот пункт расширяет тот совет – для фичей (и вообще любых штуковин в продакшене) удобно регулировать количество трафика не только с помощью включить/выключить, но и с помощью сегментирования. Например, сегментировать включение по региону, браузеру, каким-то кукам и тд.
Таким образом, мы получаем схему:
– накодить фичу
– добавить к ней проверки включенности
– выкатить релиз
– через конфиг включить фичу на какой-то сегмент (использовать whitelist)
– убедиться, что всё идет нормально
– через конфиг включить фичу везде
– в случае чего выключить фичу в каком-то сегменте (использовать blacklist)
Кроме плавного регулирования нового трафика вы получите консистентный продакшн, и ваше поведение не будет “моргать” у пользователя в то время, пока релиз катится.
Всегда приятнее контролируемо разрешать, чем запрещать вышедшее из-под контроля.
39. Debug-mode
Это вообще классика, на которую попадаются многие новички в веб-разработке. Совершенно нормально хотеть иметь какой-то способ, который позволяет через браузер получить информацию с бекенда. Например, использовать магический параметр в строке запроса, при упоминании которого в этом же браузере вы увидите желаемую информацию: переменные окружения, параметры запроса, параметры конфигурации и ещё много другого полезного. Что-то типа “https://mysite.com/?megadebug=1”.
Или, может быть, вы хотите через get-параметр что-то включать!
Подумайте пять раз об этом.
Какой бы рандомный аргумент вы не придумали, есть шанс, что школьники нащупают его своими сканерами и получат весь ваш отладочный вывод. Если вам кажется, что это маловероятно, то почитайте немного больше про fuzzing-тестирование.
Если решили оставить свой отладочный режим, то добавьте туда проверку авторизации, список разрешённых ip-адресов и чего-нибудь ещё, что посоветует СИБ (хотя, когда вы к ним придёте с такой идеей, то вполне можете нарваться на аудит системы и на тестирование знаний основ веб-безопасности). Ещё раз повторю, что это сомнительная идея.
40. Вечная жизнь скриптов
Браузер пользователя – это загробный мир. Всё, что когда-то выехало в продакшен и попало к пользователю в браузер, обретает вечную жизнь. Установленные на смартфон приложения также живут вечно.
Самое неприятное – это, пожалуй, скрипты, которые загрузившись единожды в браузере пользователя, делают какую-то периодическую работу. Как только пользователь загрузил вашу страницу, на которой работает скрипт, вы уже не контролируете