Это специалист, который развернет необходимую для мониторинга инфраструктуру?
Я думаю, что тут как нигде работает принцип разделения на junior, middle и senior позции. Если мы берем senior позицию, то да. Исходя из моего опыта, я считаю, что в обязанности такого специалиста должны входить:
Сбор требований по системе: что, когда и зачем должно мониториться, какие метрики должны отслеживаться и какой результат выводиться.
Подобрать необходимый инструментарий под задачи.
Построить архитектуру будующего сервиса мониторинга.
Проектирование и реализация самого проекта.
Контейнеризация, создание пайплайнов и настройка CI/CD.
Сбор логов и метрик.
Реализация инструментов визуализации для метрик.
Настройка алертинга.
По поводу того, какие отклонения в метриках должны приводить к оповещению линии поддержки: обычно это должно согласововаться с заказчиком мониторинга.
По крайней мере так строится моя работа. Я получаю запрос от бизнеса на мониторинг одного из множества ресурсов и прохожу весь процесс от сбора требований до реализации дашборда с метриками на удобном ресурсе и поддержки.
Под лояльностью и открытостью я имел в виду больше понимающий подход к сотрудникам, ну и справедливости ради меня предупредили о работе в саппорте. Но вот где слукавили, так это в количестве этой самой работы :( В целом можно понять, что в небольшой компании процессы выстроены не лучшим образом, но как быть со вторым примером. Они буквально до последнего старались скрыть, что это сервисная команда, а в "команде" один человек... Это хорошо, что я решил узнать обо всем в конце технического, а если бы нет? Узнал бы на испытательном? Знаю много людей, которые не задают вопросы о компании, продукте и команде, стараясь устроиться на любое место. Думаю, их бы точно ждало разочарование. А ведь можно было изначально пригласить тех, ко был бы заинтересован в такой работе, а не скрывать все от соискателей до последнего... К примеру, в одно время с тем, когда меня приглашали на работу из первого кейса, меня приглашали работать в дочерке одной нефтяной компании над их новым приложением для малого бизнеса. HR еще на прескрине предупредил о том, что по факту я там буду первооткрывателем в тестировании, буду настраивать свои процессы, а позже собирать команду. На тот момент (год или полтора назад) я вполне оправданно считал, что такая работа мне не по плечу. Но оглядваясь назад, если бы я только знал, что меня ждет в другой компании, я бы согласился и не думал бы, даже не смотря на то, что это совершенно новый опыт и большая ответственность как для спеца с двухлетним опытом.
Согласен с вами полностью с тем, что хороший aqa должен бы и знать, как окружение натстроить, как развернуть тестовую бд для e2e, написать тестовую (именно тестовую) документацию, ну и валидировать баги. Упоминал в начале, что хороший специалист владеет смежными областями, но... К большому сожалению, когда я приходил в команду или задавал вопросы на собеседовании требовалось не просто настроить тестовое окружение или наладить процессы CI/CD (лично я думаю, что окружение ладно, но CI/CD точно должны быть вне зоны ответственности aqa). Зачастую, оказывалось что от CI/CD на проекте только название, сам выбирай инструменты, сам настраивай. С написанием документации тоже никаких проблем, но если только она тестовая. Множество статей, научных работ и книг определяют пул тестовой документации, и что-то ни в одной не находил "составление спецификации". Например, разработчик создав новую фичу отдавал на тест просто голую фичу, описания в одну строчку. Я спросил у лида, как мне тестить сие чудо? Он ответил, что нужно пойти к разрабу ,спросить как это работает и написать спецификацию... Чего, подумал я. Ладно поговорить с разрабом, по писать спецификацию? А для чего тогда у меня в команде человек с должностью "технический писатель" или "аналитик". На худой конец, почему этим разраб не удосужился заняться? Почему это зона моей ответственности? Зачем задачи саппортп попадают в qa (на одного бедного дежурного qa), если в проекте есть два человека, работающих в саппорте? Или они думают, что в qa работы маловато, тестить 12 продуктовых стендов, их мастеры, новые фичи и миграцию на постгресс (нашли время, конечно мигрировать). Это все конечно больше крик души... Но я вот думаю, что компаниям не стоити замалчивать такие вещи, когда их прямо на собесе спрашивают об этом. Лично я всегда так делаю. Более чем уверен, что найдется человек, которому будет искренне нравится такая работа, но это буду не я. Тем что они замалчивают подобные "мелочи", они тарят как мое, так и свое время. Ведь мог же найтись человек, который бы решал эти задачи быстрее и эффективнее ,чем тестировщик-аналитик, коим я и являюсь. Не раз предупредил компанию о своей сфере работы, инструментах и навыках, но видимо в погоне за "хорошим" кандидатом, они решили что можно мне и наврать в ответ на прямые вопросы... Не кажется ли вам, что это действительно проблема?
Чатики прям боль. В поддерже на мне было около 12 продуктовых и столько же мастер стендов. Бывало и такое, что приходилось рабодать на двух-трех одновременно, потому что баги на них могли блокировать работу и саппорта первой линии и тестировщиков, которые не на дежурстве. Спам там просто дикий, заглушил телегу на второй день. Еще и тестеры иногда решали проблемы там, а не в тестовом чате)
Information
Rating
Does not participate
Location
Грузия
Date of birth
Registered
Activity
Specialization
Test Automation Engineer, Quality Assurance Engineer
Принял к сведению :)
Вот ссылочка на github с этим проектом - https://github.com/Revastein/listenerExample
Удачи в изучении!)
Я думаю, что тут как нигде работает принцип разделения на junior, middle и senior позции. Если мы берем senior позицию, то да.
Исходя из моего опыта, я считаю, что в обязанности такого специалиста должны входить:
Сбор требований по системе: что, когда и зачем должно мониториться, какие метрики должны отслеживаться и какой результат выводиться.
Подобрать необходимый инструментарий под задачи.
Построить архитектуру будующего сервиса мониторинга.
Проектирование и реализация самого проекта.
Контейнеризация, создание пайплайнов и настройка CI/CD.
Сбор логов и метрик.
Реализация инструментов визуализации для метрик.
Настройка алертинга.
По поводу того, какие отклонения в метриках должны приводить к оповещению линии поддержки:
обычно это должно согласововаться с заказчиком мониторинга.
По крайней мере так строится моя работа. Я получаю запрос от бизнеса на мониторинг одного из множества ресурсов и прохожу весь процесс от сбора требований до реализации дашборда с метриками на удобном ресурсе и поддержки.
Можно отключить этот бар с помощью опции:
Опция работает с версии Chrome 76.0.**
Вообще, у этой опции есть свои интересные значения, которые могут пригодиться:
Под лояльностью и открытостью я имел в виду больше понимающий подход к сотрудникам, ну и справедливости ради меня предупредили о работе в саппорте. Но вот где слукавили, так это в количестве этой самой работы :( В целом можно понять, что в небольшой компании процессы выстроены не лучшим образом, но как быть со вторым примером. Они буквально до последнего старались скрыть, что это сервисная команда, а в "команде" один человек... Это хорошо, что я решил узнать обо всем в конце технического, а если бы нет? Узнал бы на испытательном? Знаю много людей, которые не задают вопросы о компании, продукте и команде, стараясь устроиться на любое место. Думаю, их бы точно ждало разочарование. А ведь можно было изначально пригласить тех, ко был бы заинтересован в такой работе, а не скрывать все от соискателей до последнего...
К примеру, в одно время с тем, когда меня приглашали на работу из первого кейса, меня приглашали работать в дочерке одной нефтяной компании над их новым приложением для малого бизнеса. HR еще на прескрине предупредил о том, что по факту я там буду первооткрывателем в тестировании, буду настраивать свои процессы, а позже собирать команду. На тот момент (год или полтора назад) я вполне оправданно считал, что такая работа мне не по плечу. Но оглядваясь назад, если бы я только знал, что меня ждет в другой компании, я бы согласился и не думал бы, даже не смотря на то, что это совершенно новый опыт и большая ответственность как для спеца с двухлетним опытом.
Согласен с вами полностью с тем, что хороший aqa должен бы и знать, как окружение натстроить, как развернуть тестовую бд для e2e, написать тестовую (именно тестовую) документацию, ну и валидировать баги. Упоминал в начале, что хороший специалист владеет смежными областями, но... К большому сожалению, когда я приходил в команду или задавал вопросы на собеседовании требовалось не просто настроить тестовое окружение или наладить процессы CI/CD (лично я думаю, что окружение ладно, но CI/CD точно должны быть вне зоны ответственности aqa). Зачастую, оказывалось что от CI/CD на проекте только название, сам выбирай инструменты, сам настраивай. С написанием документации тоже никаких проблем, но если только она тестовая. Множество статей, научных работ и книг определяют пул тестовой документации, и что-то ни в одной не находил "составление спецификации". Например, разработчик создав новую фичу отдавал на тест просто голую фичу, описания в одну строчку. Я спросил у лида, как мне тестить сие чудо? Он ответил, что нужно пойти к разрабу ,спросить как это работает и написать спецификацию... Чего, подумал я. Ладно поговорить с разрабом, по писать спецификацию? А для чего тогда у меня в команде человек с должностью "технический писатель" или "аналитик". На худой конец, почему этим разраб не удосужился заняться? Почему это зона моей ответственности? Зачем задачи саппортп попадают в qa (на одного бедного дежурного qa), если в проекте есть два человека, работающих в саппорте? Или они думают, что в qa работы маловато, тестить 12 продуктовых стендов, их мастеры, новые фичи и миграцию на постгресс (нашли время, конечно мигрировать). Это все конечно больше крик души... Но я вот думаю, что компаниям не стоити замалчивать такие вещи, когда их прямо на собесе спрашивают об этом. Лично я всегда так делаю. Более чем уверен, что найдется человек, которому будет искренне нравится такая работа, но это буду не я. Тем что они замалчивают подобные "мелочи", они тарят как мое, так и свое время. Ведь мог же найтись человек, который бы решал эти задачи быстрее и эффективнее ,чем тестировщик-аналитик, коим я и являюсь. Не раз предупредил компанию о своей сфере работы, инструментах и навыках, но видимо в погоне за "хорошим" кандидатом, они решили что можно мне и наврать в ответ на прямые вопросы... Не кажется ли вам, что это действительно проблема?
Чатики прям боль. В поддерже на мне было около 12 продуктовых и столько же мастер стендов. Бывало и такое, что приходилось рабодать на двух-трех одновременно, потому что баги на них могли блокировать работу и саппорта первой линии и тестировщиков, которые не на дежурстве. Спам там просто дикий, заглушил телегу на второй день. Еще и тестеры иногда решали проблемы там, а не в тестовом чате)