Наталья Савенкова
SRE. Рецепты выживания в продакшене для инженера по надежности
28. Устраняйте возможность массовых операций
Если у вас есть инструмент манипуляций с вашим продакшеном типа командной строки или набора любимых скриптов, не оставляйте в них легкодоступную возможность выполнить действие сразу на всём продакшене. Если для запуска команды в консоли вы можете опционально указать некую группу серверов, а по умолчанию операция будет выполнена везде – у вас в руке граната. Вы обязательно ошибётесь и в важный момент забудете указать конкретный хост или группу, опечатаетесь в параметре и шарахнете команду на всё. А чтобы такого не происходило – не надо иметь такую возможность вообще либо нужно делать её чуть сложнее (с дополнительным подтвержением, например).
И самый главный совет: после запуска опасных массовых операций не покидайте рабочее место до тех пор, пока они не отработают и вы не убедитесь в полученном результате.
29. Правильно рассчитывайте запас мощности
Вернёмся немного к вопросам запаса мощностей. Любые простаивающие ресурсы это, без сомнений, затраты – вы за них платите, а никакой пользы они не приносят.
При этом какой-то запас мощности держать всё равно придётся. На что опираться при этих расчётах?
Для начала нужно описать свои сценарии: в каких случаях и какой объем нагрузки нужно выдерживать. Затем нужно оценить сценарий и продолжительность процедуры масшабирования. Если у вас масштабирование устроено по принципу “жмём кнопку, платим сколько угодно, через минуту получаем мощности”, то у вас нет этой проблемы.
Если ваше масштабирование устроено иначе, то запас какой-то иметь придётся, хотя бы на выживание во время масштабирования.
Что включить в расчеты:
– Неожиданный пользовательский трафик, который вы хотите выдерживать. Сюда же входят маркетинговые кампании.
– Выход из строя части инфраструктуры. У любого поставщика услуг есть какие-то гарантии, ознакомьтесь с ними.
– Сломанная часть продакшена в результате неудачного релиза. Здесь всё зависит от вашей процедуры релиза.
– Ещё какие-то особые локальные сценарии.
То есть, нужно понимать, как обслуживать высокий уровень трафика при частично потерянной инфраструктуре из-за провайдера и во время релиза. Вы можете сказать: “Если у нас не будет работать часть инфраструктуры или будет высокий трафик, мы не будем катить релиз”. Обязательно произойдет ситуация, когда это будет необходимо.
Нужно ли запасать мощности на случай DDoS? Я считаю, что в этом нет смысла – всё равно не хватит.
Деньги: любой запас стоит денег. Всю схему запаса нужно посчитать и согласовать с бизнесом: какой трафик в каком случае вы должны обслуживать, а какой не должны. Дальше выстраивать схему резервирования с учётом этой информации.
30. Считайте запас критического пути
Снова про запасы.
Обработка запроса пользователя состоит из трёх основных стадий:
– получение запроса по сети
– обработка бэкендом
– выдача ответа по сети
В стадии "обработка бэкендом" может скрываться бездна этапов: походы в базы данных, сотню других микро- и немикро- сервисов, кэши и тп. Возможно, вы уже молодец и сделали бенчмарк, где измеряете производительность компонентов в синтетической среде. Воспроизвести эквивалент продакшн-среды для бенчмарков это дорогостоящая и трудоёмкая задача – этим очень мало кто занимается.
Если вы делаете бенчмарки в синтетической среде с помощью заглушек, то вы ничего не знаете о производительности системы в реальности. Самым медленным или ограниченным звеном во всей цепи может быть что-то, чему вы вообще не придаёте значения.
Опишите свою схему обработки запроса, проанализируйте пропускную способность каждого компонента и стыки между ними, опишите критический путь выполнения запроса и оцените узкие места.
31. Заведите запасной мониторинг
Этот пункт немного параноидальный, но тоже взялся не просто так, а из очередного увлекательного опыта.
Мониторинг – это система наблюдения за жизненно важными показателям вашей системы. Вообще предполагается, что надежность системы мониторинга должна быть выше, чем у вашей системы.
На самом деле, мониторинг это такой же сервис, как и всё остальное. Ваш мониторинг может быть каким угодно интеллектуально восхитительным, предсказывать что угодно, анализировать зависимости и давать рекомендации дня, но какой от него прок, если он сломался и вы вообще не понимаете, что сейчас в продакшене происходит?
Выделите критические показатели вашего продакшена и сделайте резервный мониторинг – но не делайте такой же, какой уже есть, сделайте на каких-то других технологиях и в другой среде.
Если ваш первый мониторинг сломается в результате автоматического обновления, тогда останется хотя бы второй. Также заведите себе в календаре напоминание "проверить и актуализировать резервный мониторинг".
32. Умейте быстро отключить любой компонент
Был у нас как-то случай… В 00:00 на странице должен был начать отображаться один из блоков, содержащий карточки событий. Код был написан так, что в цикле “while (n < m)” подбирал события до тех пор, пока в ленту не наберётся необходимое количество событий. В один момент в кандидатах было в принципе меньше событий, чем должно было набраться в ленту. На такое, конечно же, никто не рассчитывал. Тут несложно догадаться, что было дальше… В 00:00 блок начал показываться, люди заходили на страницу, но не видели ничего, потому что обслуживающий бекенд уходил в бесконечный цикл. Балансер делал три попытки получить ответ от бекенда; таким образом, на один запрос пользователя три бекенда уходили в бесконечный цикл и уже не могли обслуживать другие запросы. Печаль. В итоге, это приводило к тому, что за небольшое время вообще все бекенды оказывались в бесконечном цикле и по сути ничего не работало. Понятное дело, что в этом случае нужно собирать новую версию и выкатывать её, но это вообще дело небыстрое, когда речь идёт о крупных системах.
Или вот другая история: один из источников данных начал отдавать сломанный json, на котором ломался парсер и всё падало.
Или вот ещё история: один из источников по ошибке начал отдавать такой объём данных в ответе, что в цепочке передачи данных переполнялся один из буферов и снова всё падало.
И вот ещё пример: в одном из блоков был оптимизирован алгоритм сортировки элементов с учетом весов, но когда все веса элементов оказались равными нулю, он начал уходить в бесконечный цикл.
Мораль такова: вообще не знаешь, что и где может произойти, поэтому подготовиться к этому невозможно.
Решение: умейте отключать компоненты в системе. Это намного быстрее, чем собрать и выкатить релиз. Достаточно найти место, которое всё ломает и выключить его, а потом спокойно заниматься решением проблемы, фиксами и релизами.
Для реализации такой штуки есть разные способы:
– админка, через которую вы можете управлять конфигами
– база данных, в которой лежит конфигурация (это удобно, но менее надёжно)
– система управления конфигами, типа Ansible
– файлик в хранилище файлов, который вы туда руками положили, а бекенд его скачивает иногда
– в конце концов, можно файлик закачать прям в контейнер, если нет ничего вообще
Не надо слишком усложнять, выбирайте подходящее для вашей ситуации решение.
33. Ставьте маленькие дефолты
Маленькая заметка о щедрости и здравомыслии.
Представьте себе, что в вашей системе есть какие-то настройки. Или, возможно, вы предоставляете систему другим, и в ней есть какие-то настройки.
Чтобы настройки настраивать, в них нужно писать какие-то значения. Чтобы писать разумные значения, нужно иметь представление о последствиях, что вообще бывает редко. Поэтому в основном люди оставляют значения по умолчанию (дефолты), а когда с ними что-то идёт не так, то идут разбираться, что это за настройки и какие значения там нужно выставлять. Значения по умолчанию для того и созданы – уменьшать когнитивную нагрузку на пользователя.
Возьмите себе за правило: не использовать безлимиты никогда, ставить минимально необходимые значения по умолчанию.
У этого подхода есть несколько позитивных эффектов. Во-первых, люди начинают немного погружаться в смысл настройки, когда им нужно поднять её значение. Начинают хотя бы стремиться к осознанному выбору нового значения. Во-вторых, чем чаще они его поднимают, тем больше задумываются о тенденции.
В-третьих, вы используете эффект привязки – особенность оценки неизвестных числовых значений человеком, из-за которой эта оценка смещается в сторону ранее воспринятых чисел.
Представьте себе, что в вашем продакшене создание контейнеров для новых сервисов происходит через UI, в котором нужно выбрать количество cpu, по умолчанию равное 16 cpu. В итоге у вас все многочисленные контейнеры в продакшене будет размером в 16 cpu, просто потому что никто не будет заниматься их уменьшением в ходе работы и тратить время на выбор более подходящего значения в момент создания, а люди просто будут считать, что контейнер в 16 cpu это вообще нормально и так должно быть.
Представьте себе другую ситуацию: по умолчанию размер контейнера равен 1 cpu. Тогда ваши контейнеры в продакшене будут ровно того размера, который им нужен, потому что люди будут со временем постепенно добавлять в них ресурсов. При этом, контейнер размером в 1 cpu будет считаться нормальным, а контейнеры с 16 cpu будут вызывать вопросы: это же в 16 раз больше, чем значение по умолчанию.
Понятное дело, что у всех разные системы и разные ситуации, но суть к этому моменту уже точно должна быть понятна.
34. Логируйте сквозной идентификатор запроса
Если вы серьёзные ребята, то у вас есть логи в системе. Логи либо уже есть, либо их ещё нет. Раз вы читаете эти книгу, то вы точно серьёзные.
Для чего используются логи? Чтобы в них смотреть, когда что-то пошло не так. Но какой в них толк, если по логам нельзя отследить весь маршрут запроса? Если вы можете отследить весь путь запроса, то когда-нибудь это сэкономит кучу времени. А ещё вокруг таких данных можно будет построить разные аналитические инструменты.
Возьмите всю доступную вам цепочку систем, через которые проходит запрос, и начните логировать во всех системах уникальный идентификатор запроса. Например, можно сгенерировать этот уникальный идентификатор в самом начале пути, а дальше передавать его в заголовках и записывать в логи на каждом этапе.
35. Соблюдайте рекомендации СИБ
СИБ – это какая-нибудь Служба Информационной Безопасности, которая есть в вашей компании, если она достаточно крупная. Никто точно не знает, чем они там занимаются, но эти ребята постоянно сильно заняты. Когда вы придёте к ним со словами “я хочу сделать свою систему более безопасной, выдайте мне ваш чек-лист, и я что-нибудь у себя улучшу”, вы станете сотрудником года в их глазах, а ваши белые крылья перестанут помещаться в коридоре.
Если такой службы у вас нет, то найдите какой-нибудь гайд в интернете типа “100 лучших советов по кибербез” и полистайте его.
Это совершенно очевидная рекомендация, но почему так никто не делает? Здесь работает такой же жизненный принцип, как с логами или бекапами – либо вы уже соблюдаете рекомендации СИБ, либо вы их ещё не соблюдаете.
Просто возьмите гайд по безопасности с рецептами и сделайте то, что там написано. Как бы вы не старались, всё равно у вас будут дыры, но их будет немного меньше.
P.S. Когда-то очень давно, ещё в начале моей карьеры в разработке, в журнале Хакер вышла статья с подробным разбором того, как был взломан один из сайтов, над которым я работала… Даже не знаю, что здесь сильнее – жажда славы или ощущение позора.
36. Доступность из внешнего мира
Почти все рецепты в этой книге крутятся вокруг backend-систем. У нас в бекенде всегда куча мониторинга на все случаи жизни, мы любим собирать много разной информации и рисовать из неё разноцветные графики. Но есть нюанс. График можно нарисовать из тех данных, которые к нам пришли вместе с запросом. Но если сервис недоступен снаружи, то не будет и запросов, которые могли бы принести нам информацию. Когда график количества запросов в секунду начинает внезапно показывать 0, то на это есть целый ряд причин: например, закончилось место в хранилище метрик. А если на графике не ноль, а просто “стало чуть меньше, чем было пять минут назад”? Да кто такое заметит вообще?! Тем более ночью.
Для этих случаев есть разные сервисы, которые проверяют работу вашей системы снаружи. Они могут это делать из разных стран, притворяться разными устройствами и так далее. Настройте внешние проверки доступности системы из популярных браузеров и важных для вас локаций. В один из солнечных дней вы вдруг узнаете, что работу вашего сервиса по ошибке заблокировали в какой-нибудь стране.
37. Аварийные и предупреждающие оповещения
Мониторинг не имеет смысла без оповещений для ситуаций, требующих внимания. Ни один нормальный человек не будет сидеть весь день и смотреть в экран на красивые разноцветные линии.
Разделите ваши оповещения на категории:
– полезно знать
– сломалось, нужно починить в рабочее время
– сломалось, нужно починить срочно
– всё совсем плохо
Для оповещений разной степени важности используйте разные каналы доставки. Если все сообщения вы шлёте в один канал, то со временем там наступит бардак и важное станет теряться.
“Полезно знать” нормально писать на почту.
Для “Починить в рабочее время” удобно создавать тикеты на починку.
В случае “Нужно починить срочно” стоит кому-то позвонить.
А если “Всё совсем плохо”, то стоит позвонить одновременно всем, кто обычно принимает участие в устранении катастроф.
Как инженер по надёжности я, конечно же, советую запланировать регулярные учения по проверке работоспособности каналов доставки критических оповещений.
38. Whitelist vs Blacklist
Представим себе, что вы сделали крутую фичу и собрались катить релиз с этой фичей. Фича абсолютно прекрасная и логически продумана отлично. Как только вы её выкатите, то восторг пользователей будет неописуем. Итак, релиз катится, фича становится доступной пользователям. Трафик наливается, пользователи радуются, продакшн ломается. С этой истории можно начинать многие главы в этой книге.
Раньше уже была рекомендация “Катите фичу отключенной”, этот пункт расширяет тот совет – для фичей (и вообще любых штуковин в продакшене) удобно регулировать количество трафика не только с помощью включить/выключить, но и с помощью сегментирования. Например, сегментировать включение по региону, браузеру, каким-то кукам и тд.
Таким образом, мы получаем схему:
– накодить фичу
– добавить к ней проверки включенности
–выкатить релиз
– через конфиг включить фичу на какой-то сегмент (использовать whitelist)
– убедиться, что всё идет нормально
– через конфиг включить фичу везде
– в случае чего выключить фичу в каком-то сегменте (использовать blacklist)
Кроме плавного регулирования нового трафика вы получите консистентный продакшн, и ваше поведение не будет “моргать” у пользователя в то время, пока релиз катится.
Всегда приятнее контролируемо разрешать, чем запрещать вышедшее из-под контроля.
39. Debug-mode
Это вообще классика, на которую попадаются многие новички в веб-разработке. Совершенно нормально хотеть иметь какой-то способ, который позволяет через браузер получить информацию с бекенда. Например, использовать магический параметр в строке запроса, при упоминании которого в этом же браузере вы увидите желаемую информацию: переменные окружения, параметры запроса, параметры конфигурации и ещё много другого полезного. Что-то типа “https://mysite.com/?megadebug=1”.
Или, может быть, вы хотите через get-параметр что-то включать!
Подумайте пять раз об этом.
Какой бы рандомный аргумент вы не придумали, есть шанс, что школьники нащупают его своими сканерами и получат весь ваш отладочный вывод. Если вам кажется, что это маловероятно, то почитайте немного больше про fuzzing-тестирование.
Если решили оставить свой отладочный режим, то добавьте туда проверку авторизации, список разрешённых ip-адресов и чего-нибудь ещё, что посоветует СИБ (хотя, когда вы к ним придёте с такой идеей, то вполне можете нарваться на аудит системы и на тестирование на знание основ веб-безопасности). Ещё раз повторю, что это сомнительная идея.
40. Вечная жизнь скриптов
Всё, что когда-то выехало в продакшен и попало к пользователю в браузер, обретает вечную жизнь. Установленные на смартфон приложения также живут вечно.
Самое неприятное – это, пожалуй, скрипты, которые загрузившись единожды в браузере пользователя, делают какую-то периодическую работу. Как только пользователь загрузил вашу страницу, на которой работает скрипт, вы уже не контролируете его поведение, и всё, что там захардкожено (url, id, whatever) останется там навечно. У человека в браузере ваша страница может жить ГОДАМИ. Об этом просто нужно помнить ибо жизнь такава и больше никакава.
41. Консистентность версий
В наше нелёгкое быстрое время мы очень ценим эффективность и срезание углов там, где их можно срезать. Я знаю, что многие при выкатывании релиза срезают углы тем, что катят новый код только на часть продакшена. Релиз часто дело небыстрое и вроде бы логично так делать. Это очень плохая идея.
Никогда НиКоГдА НИКОГДА не оставляйте разные версии вашего приложения в продакшене. Никогда. Никогда не катите релиз только на часть продакшена просто потому, что дальше нет необходимости. Катить следующий релиз, откатывать и производить какие-то манипуляции с продакшеном, очень вероятно, будет другой человек или вы будете делать это в режиме аварии ночью. Чтобы не бегать и не искать предыдущего катателя, выясняя, что здесь происходило, почему оно разное, почему надо часть продакшена откатывать на одну версию, а другую часть на другую версию, просто так не делайте.
42. Делайте бекап перед вмешательством
Начнём с баз данных.
Если у вас не какой-то экстремальный случай, то всегда делайте бекапы базы перед внесением в неё ручных изменений. Для базы в целом полезно иметь отстающую реплику, но это не всегда легко организовать и не всегда легко использовать. К тому же за неё нужно платить, она иногда ломается, за ней нужно укаживать и проверять её живость. Скорее всего, у вас её никогда не будет.
Так вот. Когда непременно что-то пойдёт не так в ходе вашего вмешательства, вам будет откуда восстановить самую свежую версию. Помню, однажды в спешке я промахнулась и удалила таблицу в базе. Восстанавливали три дня из разных источников информации. Вам не обязательно иметь такой опыт, чтобы начать пользоваться этим советом.
Бекапы конфигов. Это менее очевидная штука, но не менее ценная. Перед внесением изменений в конфигурационный файл, сохраните его версию рядышком. Например, используйте суффикс с датой и временем, типа mymagicconfig.20240512-1813. Это полезно не только для восстановления на прежнюю версию, но и для ретроспективы изменений.
43. Храните всё в VCS
VSC – Version Control System, система контроля версий.
Я начинала программировать ещё тогда, когда системы контроля версий были насколько плохими, что нужна была сила воли, чтобы ими пользоваться.
А сейчас я даже не могу предположить, что может остановить человека от их использования.
Скрипты всякие, настройки чего-то, конфиги и тп. Всё, что можно представить в виде файла, и что представляет собой хоть какую-то ценность, коммитьте в систему контроля версий. Во-первых, можно будет изучать историю; во-вторых, сложнее потерять; в-третьих, можно будет что-то автоматизировать.
Это настолько очевидный совет, что он даже не тянет на материал для этой книги. Но почему же до сих пор не все это делают и продолжают страдать?!
И, конечно же, конфиги с вашего продакшена тоже храните в системе контроля версий. Даже если у вас нет вообще ничего, код вы пишете прямо на сервере, и конфиги правите сразу там же, всё равно начните использовать vsc, чтобы сохранить свой труд.
44. Готовьте заранее план отхода
Если вам нужно сделать в продакшене что-то нетипичное и нерегламентированное, то потратьте немного больше времени на подготовку к этому событию и продумайте план возвращения всего изменённого в состояние “как было”.
На фразу “я всего лишь одну строчку поменяю” я всегда отвечаю: “объём изменений никак не связан с масштабом разрушений”. А уж сколько было историй про неверные изменения конфигов, которые неоткуда вернуть обратно… Или истории про изменения настроек сети, которые инженер производит через удалённое подключение с вполне понятными последствиями в виде полного отсутствия доступа к серверам.
Перед тем, как начать вносить изменения, задайте себе вопрос “А что будет, если…?” и напишите варианты, что может пойти не так и как к этому подготовиться. Вероятно, вам кажется, что это только добавит работы. Отчасти это так, но со временем такая подготовка войдёт в привычку и не будет требовать особых усилий.