Comments 17
Ваня такое встречал редко. Так редко делают, потому что обычно вся связка сервисов находится в какой-то внутренней сети, в которую нет доступа снаружи, и использовать там 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).
Но хочется обратить внимание на один момент, с точки зрения процесса обеспечения качества:
Он решил не скидывать эту непонятную ошибку разработчикам, а получить доступ по ssh на сервер и разобраться, в чём там дело. Знаний в области такого рода дебага проблем у него было мало, но он очень хотел научиться, поэтому вооружился поисковиками, логикой и пошёл локализовывать баг
Я бы проверил с другой машины, с другой сети (и все там что надо*), и если проблема на лицо, сперва зарепортил, а потом бы только занимался самообразованием.
* — По уму, для определенных типов ошибок должен быть протокол действий, необходимых чтобы зафиксировать сбой
И вообще, доступность сервисов и серверов должна проверяется автоматизацией (мониторинг там всякий и пр.), и все проблемы сразу идут разрабам на почту или автоматически заводятся тикеты. Ну или хотя бы к этому стремиться. Это достойная цель для QA, сделать так, чтобы проблемы обнаруживались быстрее. С графиками которые можно потом менеджерам представить мол «вот и вот, хостинг гуано, надо переезжать в облака, тыры-пыры.»
Не знаю, какого бы ранга ты QA не был, не нужно тратить свое время и делать работу системного инженера. Ведь пока ты там занимаешься самообразованием — об ошибке никто еще ничего не знает. Это как при автомобильной аварии, сначала звоним в скорую, а потом оказываем первую помощь*. Чаще, системные инженеры все равно круче и опытнее. То что знания надо расширять, конечно, не спорю, но не в ущерб «пациенту».
* — И то, самый полезный совет при оказании ПП: «Не уверен — лучше не трогай.»
P.S.
И молодым тестировщикам на заметку, на тему «не нахожу общий язык с разработчиками» — будете заниматься не своим делом, будете пытаться «блеснуть знаниями», не подружитесь никогда.
Во-первых, сразу скажу, что я не имел ввиду ситуацию, когда проблема на проде. В этом случае, естественно, дебагом должны заниматься девопсы/разработчики, как люди, лучше всего знающие инфраструктуру и ПО. Речь в статье шла скорее о ситуации, когда проблема возникает при тестировании какой-то новой фичи, и ситуации, описанные в статье, сильно искуственные. Доступность сервисов определённо должна проверяться автоматизацией.
Во-вторых, я считаю, что тестировщик всё-таки должен «блистать знаниями» в разумных пределах. Пример: отдают сервис на тестирование, тестировщик запускает тест, получает в ответ 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"
Ещё Ване может потребоваться утилита iptables в некоторых случаях. А когда Ваня совсем отчается, вспомнит про SELinux.
Ну а чтоб дойти до SELinux, надо и правда совсем отчаяться))
P.S. Ну и главное не фанатеть, иногда лучше спросить
PSS Если для тестирования требует богатый опыт использования strace, то лучше подумать о рефакторинге такого чуда.
Про рефакторинг чуда, которое только через strace раздебажишь, согласен :) Но всякое бывает)) Поэтому и написал статью, чтобы показать, что даже если ничего не понятно, можно попробовать расковырять это утилитами.
Ещё бэкенд может использовать язык наподобие Rust, выдающий навязчивые хинты при игноре возвращаемого значения и, как результат, заставляющий разработчика писать код вывода ошибки пользователю как наиболее простецкий способ, в расчёте на то, что он никогда не выполнится. А по факту выполнившись внезапно один раз из ста он позволяет легче лёгкого локализовать баг.
Как Иван ошибку в бэкенде локализовывал