Comments 17
Неплохо, спасибо.
Довольно интетерсно написано
Нестандартный формат подачи информации, очень приятно читать статью.
а что Ване делать, если нужно дебажить nginx с https трафиком (принимает https и отправляет дальше в https сервис)? :)
Ваня такое встречал редко. Так редко делают, потому что обычно вся связка сервисов находится в какой-то внутренней сети, в которую нет доступа снаружи, и использовать там HTTPS — это нормальный такой оверхед. Проще всего переконфигурить nginx, чтоб ходил по HTTP. Либо использовать ssldump, но Ваня не пользовался им.
Ага, совпадает с моим собственным мнением.
У нас была проблема как раз с тем, что через HTTP ходит нормально, а вот через HTTPS — нет (были настроены два server_name, скажем a_server_name и b_server_name и если первый запрос приходит к a_server_name, то все остальные запросы и к a_server_name и к b_server_name идут все равно через a_server_name).
У нас была проблема как раз с тем, что через HTTP ходит нормально, а вот через HTTPS — нет (были настроены два server_name, скажем a_server_name и b_server_name и если первый запрос приходит к a_server_name, то все остальные запросы и к a_server_name и к b_server_name идут все равно через a_server_name).
Полевой конспект полезный. Спасибо.
Но хочется обратить внимание на один момент, с точки зрения процесса обеспечения качества:
Я бы проверил с другой машины, с другой сети (и все там что надо*), и если проблема на лицо, сперва зарепортил, а потом бы только занимался самообразованием.
* — По уму, для определенных типов ошибок должен быть протокол действий, необходимых чтобы зафиксировать сбой
И вообще, доступность сервисов и серверов должна проверяется автоматизацией (мониторинг там всякий и пр.), и все проблемы сразу идут разрабам на почту или автоматически заводятся тикеты. Ну или хотя бы к этому стремиться. Это достойная цель для QA, сделать так, чтобы проблемы обнаруживались быстрее. С графиками которые можно потом менеджерам представить мол «вот и вот, хостинг гуано, надо переезжать в облака, тыры-пыры.»
Не знаю, какого бы ранга ты QA не был, не нужно тратить свое время и делать работу системного инженера. Ведь пока ты там занимаешься самообразованием — об ошибке никто еще ничего не знает. Это как при автомобильной аварии, сначала звоним в скорую, а потом оказываем первую помощь*. Чаще, системные инженеры все равно круче и опытнее. То что знания надо расширять, конечно, не спорю, но не в ущерб «пациенту».
* — И то, самый полезный совет при оказании ПП: «Не уверен — лучше не трогай.»
P.S.
И молодым тестировщикам на заметку, на тему «не нахожу общий язык с разработчиками» — будете заниматься не своим делом, будете пытаться «блеснуть знаниями», не подружитесь никогда.
Но хочется обратить внимание на один момент, с точки зрения процесса обеспечения качества:
Он решил не скидывать эту непонятную ошибку разработчикам, а получить доступ по ssh на сервер и разобраться, в чём там дело. Знаний в области такого рода дебага проблем у него было мало, но он очень хотел научиться, поэтому вооружился поисковиками, логикой и пошёл локализовывать баг
Я бы проверил с другой машины, с другой сети (и все там что надо*), и если проблема на лицо, сперва зарепортил, а потом бы только занимался самообразованием.
* — По уму, для определенных типов ошибок должен быть протокол действий, необходимых чтобы зафиксировать сбой
И вообще, доступность сервисов и серверов должна проверяется автоматизацией (мониторинг там всякий и пр.), и все проблемы сразу идут разрабам на почту или автоматически заводятся тикеты. Ну или хотя бы к этому стремиться. Это достойная цель для QA, сделать так, чтобы проблемы обнаруживались быстрее. С графиками которые можно потом менеджерам представить мол «вот и вот, хостинг гуано, надо переезжать в облака, тыры-пыры.»
Не знаю, какого бы ранга ты QA не был, не нужно тратить свое время и делать работу системного инженера. Ведь пока ты там занимаешься самообразованием — об ошибке никто еще ничего не знает. Это как при автомобильной аварии, сначала звоним в скорую, а потом оказываем первую помощь*. Чаще, системные инженеры все равно круче и опытнее. То что знания надо расширять, конечно, не спорю, но не в ущерб «пациенту».
* — И то, самый полезный совет при оказании ПП: «Не уверен — лучше не трогай.»
P.S.
И молодым тестировщикам на заметку, на тему «не нахожу общий язык с разработчиками» — будете заниматься не своим делом, будете пытаться «блеснуть знаниями», не подружитесь никогда.
Спасибо за комментарий!
Во-первых, сразу скажу, что я не имел ввиду ситуацию, когда проблема на проде. В этом случае, естественно, дебагом должны заниматься девопсы/разработчики, как люди, лучше всего знающие инфраструктуру и ПО. Речь в статье шла скорее о ситуации, когда проблема возникает при тестировании какой-то новой фичи, и ситуации, описанные в статье, сильно искуственные. Доступность сервисов определённо должна проверяться автоматизацией.
Во-вторых, я считаю, что тестировщик всё-таки должен «блистать знаниями» в разумных пределах. Пример: отдают сервис на тестирование, тестировщик запускает тест, получает в ответ Connection reset by peer. Дальше есть 2 варианта: либо тестировщик просто пишет разрабам «тут странная ошибка, воспроизводится тестом XXX, вот вам Reopen задачи», либо он понимает, что клиент получил TCP-пакет с RST, что сервис упал, пойдёт в лог и приложит к задаче стектрейс. Или, если сервис отложил core dump-файл, заюзает gdb на этот файл, сделает там bt и приложит трейс из дампа к задаче.
Оба варианта имеют право на жизнь, всё зависит от процесса и культуры разработки и тестирования в компании/отделе. Лично мне ближе второй :)
Во-первых, сразу скажу, что я не имел ввиду ситуацию, когда проблема на проде. В этом случае, естественно, дебагом должны заниматься девопсы/разработчики, как люди, лучше всего знающие инфраструктуру и ПО. Речь в статье шла скорее о ситуации, когда проблема возникает при тестировании какой-то новой фичи, и ситуации, описанные в статье, сильно искуственные. Доступность сервисов определённо должна проверяться автоматизацией.
Во-вторых, я считаю, что тестировщик всё-таки должен «блистать знаниями» в разумных пределах. Пример: отдают сервис на тестирование, тестировщик запускает тест, получает в ответ Connection reset by peer. Дальше есть 2 варианта: либо тестировщик просто пишет разрабам «тут странная ошибка, воспроизводится тестом XXX, вот вам Reopen задачи», либо он понимает, что клиент получил TCP-пакет с RST, что сервис упал, пойдёт в лог и приложит к задаче стектрейс. Или, если сервис отложил core dump-файл, заюзает gdb на этот файл, сделает там bt и приложит трейс из дампа к задаче.
Оба варианта имеют право на жизнь, всё зависит от процесса и культуры разработки и тестирования в компании/отделе. Лично мне ближе второй :)
Если Ваня уже на сервере, можно проверить, отвечает ли сервис без nginx, например:
curl http://127.0.0.1:8000/Так же, можно использовать команду nestat или ss, чтобы узнать какой порт по факту прослушивает процесс и прослушивает ли вообще:
netstat -tunapl | grep "python\|8000"Спасибо за комментарий! curl на localhost действительно может дать информации, а про ss я написал в конце без подробностей. netstat же уже устарел, хоть пользоваться им никто не запрещает :)
Ещё Ване может потребоваться утилита iptables в некоторых случаях. А когда Ваня совсем отчается, вспомнит про SELinux.
Про iptables я уже писал, поэтому тут не упоминал, да и это не совсем про дебаг.
Ну а чтоб дойти до SELinux, надо и правда совсем отчаяться))
Ну а чтоб дойти до SELinux, надо и правда совсем отчаяться))
Где вариант посмотри настройки (не только nginx, а самого приложение), посмотри код? Для решения многих проблем — это горазда проще, чем использовать strace
P.S. Ну и главное не фанатеть, иногда лучше спросить
PSS Если для тестирования требует богатый опыт использования strace, то лучше подумать о рефакторинге такого чуда.
P.S. Ну и главное не фанатеть, иногда лучше спросить
PSS Если для тестирования требует богатый опыт использования strace, то лучше подумать о рефакторинге такого чуда.
Хотелось рассмотреть именно back-box тестирование, а так да, изучение конфига и кода иногда помогает. Ну вот конкретно в моём примере как такового конфига и кода у приложения вообще не было (был, конечно, в либах питона).
Про рефакторинг чуда, которое только через strace раздебажишь, согласен :) Но всякое бывает)) Поэтому и написал статью, чтобы показать, что даже если ничего не понятно, можно попробовать расковырять это утилитами.
Про рефакторинг чуда, которое только через strace раздебажишь, согласен :) Но всякое бывает)) Поэтому и написал статью, чтобы показать, что даже если ничего не понятно, можно попробовать расковырять это утилитами.
Ещё бэкенд может использовать язык наподобие Rust, выдающий навязчивые хинты при игноре возвращаемого значения и, как результат, заставляющий разработчика писать код вывода ошибки пользователю как наиболее простецкий способ, в расчёте на то, что он никогда не выполнится. А по факту выполнившись внезапно один раз из ста он позволяет легче лёгкого локализовать баг.
Читал все это и постоянно отгонял назойливые мысли: а почему тестер имеет доступ на сервер, да еще и с правами рута (tcpdump без них не оживет)? Почему он развлекается чтением логов и просмотром трафика вместо того, чтобы отрепортить баг и перейти к следующей задаче?
Я ответил на похожий вопрос чуть выше: habr.com/ru/company/funcorp/blog/518248/#comment_22054408
Sign up to leave a comment.
Как Иван ошибку в бэкенде локализовывал