всё идет нормально
– через конфиг включить фичу везде
– в случае чего выключить фичу в каком-то сегменте (использовать blacklist)
Кроме плавного регулирования нового трафика вы получите консистентный продакшн, и ваше поведение не будет “моргать” у пользователя в то время, пока релиз катится.
Всегда приятнее контролируемо разрешать, чем запрещать вышедшее из-под контроля.
39. Debug-mode
Это вообще классика, на которую попадаются многие новички в веб-разработке. Совершенно нормально хотеть иметь какой-то способ, который позволяет через браузер получить информацию с бекенда. Например, использовать магический параметр в строке запроса, при упоминании которого в этом же браузере вы увидите желаемую информацию: переменные окружения, параметры запроса, параметры конфигурации и ещё много другого полезного. Что-то типа “https://mysite.com/?megadebug=1”.
Или, может быть, вы хотите через get-параметр что-то включать!
Подумайте пять раз об этом.
Какой бы рандомный аргумент вы не придумали, есть шанс, что школьники нащупают его своими сканерами и получат весь ваш отладочный вывод. Если вам кажется, что это маловероятно, то почитайте немного больше про fuzzing-тестирование.
Если решили оставить свой отладочный режим, то добавьте туда проверку авторизации, список разрешённых ip-адресов и чего-нибудь ещё, что посоветует СИБ (хотя, когда вы к ним придёте с такой идеей, то вполне можете нарваться на аудит системы и на тестирование знаний основ веб-безопасности). Ещё раз повторю, что это сомнительная идея.
40. Вечная жизнь скриптов
Браузер пользователя – это загробный мир. Всё, что когда-то выехало в продакшен и попало к пользователю в браузер, обретает вечную жизнь. Установленные на смартфон приложения также живут вечно.
Самое неприятное – это, пожалуй, скрипты, которые загрузившись единожды в браузере пользователя, делают какую-то периодическую работу. Как только пользователь загрузил вашу страницу, на которой работает скрипт, вы уже не контролируете его поведение, и всё, что там захардкожено (url, id, whatever) останется там навечно. У человека в браузере ваша страница может жить ГОДАМИ. Об этом просто нужно помнить ибо "жизнь такава и больше никакава".
41. Консистентность версий
В наше нелёгкое быстрое время мы очень ценим эффективность и срезание углов там, где их можно срезать. Я знаю, что многие при выкатывании релиза срезают углы тем, что катят новый код только на часть продакшена. Релиз часто дело небыстрое и вроде бы логично так делать. Это очень плохая идея.
Никогда НиКоГдА НИКОГДА не оставляйте разные версии вашего приложения в продакшене. Никогда. Никогда не катите релиз только на часть продакшена просто потому, что дальше нет необходимости. Катить следующий релиз, откатывать и производить какие-то манипуляции с продакшеном, очень вероятно, будет другой человек или вы будете делать это в режиме аварии ночью. Чтобы не бегать и не искать предыдущего катателя, выясняя, что здесь происходило, почему оно
