Когда случается беда: устранение неполадок в производстве

Том Гранот и я сам имели привилегию Влада Михалчи онлайн-компания уже некоторое время. В результате мы решили провести совместный семинар, рассказав о многих вещах, которые мы узнали в процессе. Этот воркшоп будет довольно неформальным, разовым, просто куча парней будет болтать и хвастаться тем, что мы можем сделать с инструментами.

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

Эта проблема

Прежде чем мы начнем, я хотел бы поговорить о производстве и роли разработчиков в производственной среде. Как хакер я часто делаю все. Это нормально для небольшой компании, но по мере роста компании мы добавляем процессы.

Производство не сгорит так сильно. Благодаря постановке, контролю качества, CI/CD и DevOps, которые обуздывают таких людей, как я…

Так что все это у нас на месте. Мы прошли QA, постановку и все идеально. Верно?

Ну… Не совсем так.

Конечно. Современные технологии DevOps значительно изменили качество производства, мониторинг и производительность. Без сомнения. Но ошибки неизбежны. Те, что проскальзывают, являются худшими типами паразитов. Их трудно обнаружить, и часто они возникают только в масштабах.

Некоторые проблемы, такие как проблемы с производительностью, заметны только в производственной среде по сравнению с производственной базой данных. Промежуточные среды или среды разработки не могут полностью воспроизвести современные сложные развертывания. Инфраструктура как код (IaC) очень помогает в этом, но даже с такими решениями производство находится в другом масштабе.

Это единственное место, которое ДЕЙСТВИТЕЛЬНО важно

Все, что не является производством, предназначено для облегчения производства. Вот и все. У нас могут быть самые лучшие и обширные тесты. Со 100% покрытием для нашей локальной среды. Но когда наша система работает в продакшене, поведение меняется. Мы не можем контролировать это полностью.

Рефлекторная реакция — «больше испытаний». Я часто это вижу. Если бы только у нас был тест для этого... Решение состоит в том, чтобы каким-то образом подумать о каждой возможной ошибке, которую мы можем сделать, и построить тест для этого. Это безумно. Если мы знаем ошибку, мы можем просто избежать ее. Идея о том, что у другого члена команды будет такое понимание, снова неверна. Люди совершают подобные ошибки, и пока мы можем устранить некоторые ошибки таким образом. Больше тестов создает больше проблем… CI/CD становится НАМНОГО медленнее и приводит к увеличению времени развертывания в рабочей среде.

Это означает, что когда у нас действительно есть производственная ошибка. Исправление займет гораздо больше времени из-за избыточных тестов. Это означает, что весь процесс обеспечения качества КИ, который нам необходимо пройти, займет больше времени. Это также означает, что нам нужно будет больше тратить на ресурсы CI…

Логирование

Ведение журнала решает некоторые проблемы. Это важная часть любой серверной инфраструктуры. Но проблемы похожи на те, с которыми мы сталкиваемся при тестировании.

Мы не знаем, что будет важно, когда будем писать лог. Затем в производстве мы можем обнаружить, что он отсутствует. Переполнение — огромная проблема в противоположном направлении. Оно может:

• Снести производительность и кэширование

• Нести огромные затраты из-за хранения журнала

• Затруднить отладку из-за сложностей с многословием

Возможно, в нем все еще отсутствует нужная нам информация…

Недавно я разместил сообщение в ветке Reddit, где также присутствовал этот комментарий:

«Команда в моей компании случайно потеряла \~100 000 в Azure Log Analytics в течение нескольких дней. Они установили детализацию ведения журнала на непроверенный до сих пор уровень, а также добавили несколько дополнительных реплик. Когда они объявили о своей ошибке в Slack, я узнал, что да, существует такая вещь, как слишком много логов». — полная ветка [здесь] (https://www.reddit.com/r/devops/comments/udgohy/there_is_no_such_thing_as_too_much_logging_or_is/).

Опять же, регистрация великолепна. Но это не решает основной проблемы.

Ловкость

Наша команда разработчиков должна быть быстрой и отзывчивой. Нам нужно быстро реагировать на проблемы. Конечно, нам нужно попытаться предотвратить их в первую очередь… Но, как и в большинстве вещей в жизни, здесь тоже действует закон убывающей отдачи. Существуют ограничения на тесты, журналы и т. д.

Для этого нам нужно быстро полностью понять ошибку. Прохождение процесса воспроизведения чего-либо локально на основе догадок в лучшем случае проблематично. Нам нужен способ наблюдать за проблемой.

Это не ново. Существует множество решений для решения проблем в производстве, например. Инструменты APM дают нам бесценную информацию о нашей производительности в производственной среде. Они не заменяют профайлеров. Они предоставляют одну важную информацию: насколько быстро работает приложение, которое используют наши клиенты!

Но большинство этих инструментов ориентированы на DevOps. Это имеет смысл. DevOps — это люди, ответственные за производство, поэтому, естественно, инструменты мониторинга были созданы для них. Но DevOps не должен нести ответственность за исправление ошибок НИОКР или даже за их понимание… Здесь есть разрыв.

Введите наблюдательность разработчика

Наблюдаемость разработчиков — это столп наблюдаемости, ориентированный на разработчиков, а не на DevOps. С помощью инструментов в этой области мы можем мгновенно получать обратную связь, адаптированную к нашим потребностям, и уменьшать отток клиентов при обнаружении проблемы. До этих инструментов, если в продакшене не существовало лога и мы не понимали проблему… Нам приходилось переделывать наш продукт с «больше логов» и скрещивать пальцы…

На практике и в мастерской…

Я немного опередил себя в объяснении проблемы дольше, чем объясню решение. Я склонен думать, что это потому, что решение становится чертовски очевидным, как только мы его «получим». В основном это вопрос деталей.

Как известно: дьявол кроется в деталях…

Инструменты наблюдения за разработчиком могут быть хорошо знакомы разработчикам, которые привыкли работать с отладчиками и IDE. Но они все же довольно разные. Одним из примеров являются точки останова.

Теперь это снимки

Мы все знаем это упражнение. Установите точку останова в коде, который не работает, и переходите, пока не найдете проблему. Это настолько укоренилось в нашем процессе, что мы вообще редко останавливаемся, чтобы подумать об этом.

Но если мы сделаем это в производственной среде, сервер застрянет, ожидая, когда мы перешагнем через него. Это может повлиять на всех пользователей на сервере, и я даже не буду обсуждать последствия для безопасности/стабильности (с таким же успехом вы можете взять молоток и снести сервер. Это так плохо).

Снимки делают все, что делает точка останова. Они могут быть условными, как условная точка останова. Они содержат трассировку стека, и вы можете щелкать элементы в стеке. Каждый кадр включает в себя значение переменных в этом конкретном кадре. Но вот в чем дело: они не останавливаются.

Таким образом, у вас нет возможности «перешагнуть». Эта часть неизбежна, поскольку мы не останавливаемся. Вам нужно переосмыслить процесс отладки ошибок.

currentTimeMillis()

Я люблю профилировщиков. Но когда мне нужно действительно понять стоимость метода, я обращаюсь к моему старому проверенному вызову currentTimeMillis(). Другого способа получить точные/согласованные показатели производительности для небольших блоков кода просто не существует.

Но как я уже говорил. Производство там, где оно есть. Я не могу просто вставить микроизмерения по всему коду и просмотреть их позже.

Таким образом, инструменты наблюдения разработчиков добавили возможность измерять вещи. Подсчитайте, сколько раз была достигнута строка кода. Или буквально выполните измерение tictoc, которое эквивалентно подходу currentTimeMillis().

Увидимся там

«Только когда отлив утихнет, вы обнаружите, кто плавал голышом». - Уоррен Баффет

Я люблю эту цитату. Мы должны быть готовы в любое время. Нам нужно действовать быстро и быть готовыми к худшему. Но нам также нужна практичность. Мы не оригинальны, есть распространенные ошибки, с которыми мы сталкиваемся направо и налево. Мы можем заметить их быстрее, но ошибки не являются оригинальными.

На семинаре мы сосредоточимся на некоторых наиболее распространенных ошибках и продемонстрируем, как мы можем отслеживать их с помощью наблюдения разработчика. Мы приведем реальные примеры неудач и проблем, с которыми мы сталкивались в прошлом и в рамках нашей работы. Я очень взволнован этим и надеюсь увидеть вас всех [там] (https://go.lightrun.com/production-troubelshooting-masterclass)!

Также опубликовано [Здесь] (https://talktotheduck.dev/when-disaster-strikes-production-troubleshooting)