Comments 13
Цвета КДПВ напоминают логотип «самого большого в интернете архива „ничего“».
Плюс на проде к контексту отношение другое. Например, на тесте мы удаляли записи от имени пользователя не задумываясь. На проде сразу задались вопросом — а нужно ли удалять, а должен ли пользователь удалять? И скрыли весь функционал удаления.
Наличие ошибок «развертывания» при деплое в прод — это таки хороший показатель уровня пофигизма команды…
Ну и если уж упомянули фейсбук, то если его еще и попалят на «логировании» всего и вся, и потом просмотре этого всеми желающими (а дев тим — это не тот контингент, который должен иметь неограниченый доступ к сенсетив информации), то у него будут большие проблемы.
И таких проэктов, где подобные эксперименты прямо запрещены — их имеет место быть.
Ну и если уж упомянули фейсбук, то если его еще и попалят на «логировании» всего и вся, и потом просмотре этого всеми желающими (а дев тим — это не тот контингент, который должен иметь неограниченый доступ к сенсетив информации), то у него будут большие проблемы.
И таких проэктов, где подобные эксперименты прямо запрещены — их имеет место быть.
По поводу первого замечания: при отличии инфраструктуры и конфигурации prod от pre-prod даже отлаженный билд может иметь ошибки. Тут вопрос масштаба, полная копия окружения это не всегда возможно или не эфективно, и тогда риск отличия покрывается тестированием.
По поводу логирования «всего и вся»: конечно сенсетив информации у нас заинкрипчена, доступа у «всех желающих» к ней нет.
По поводу логирования «всего и вся»: конечно сенсетив информации у нас заинкрипчена, доступа у «всех желающих» к ней нет.
Не билд, а билд деплой скрипт.
Который обязан быть именно скриптом, а не «вот тут если упадет — вы мне маякните я все исправлю, а тут мы ой забыли чейто вкоммитить, щас минутку все будет, а тут есть настройки только для куэя, а для прода почему-то нет, как неудобно получилось, и вообще у вас билд система не правильная у нас локально все деплоилось!»
Сам билд может падать по миллиону причин, включая внезапно проведенные на проде «non significant» тех работы с совсем мало мало апдейтами сертификатов, или даже не на проде, а у конечных клиентов ИЕ обновился — и привет юаю )
Который обязан быть именно скриптом, а не «вот тут если упадет — вы мне маякните я все исправлю, а тут мы ой забыли чейто вкоммитить, щас минутку все будет, а тут есть настройки только для куэя, а для прода почему-то нет, как неудобно получилось, и вообще у вас билд система не правильная у нас локально все деплоилось!»
Сам билд может падать по миллиону причин, включая внезапно проведенные на проде «non significant» тех работы с совсем мало мало апдейтами сертификатов, или даже не на проде, а у конечных клиентов ИЕ обновился — и привет юаю )
Не сказал бы, что это «круто», а скорее дополнительная/крайняя мера в случае невозможности моделирования случаев с ошибками 3-party, интеграцией(которой нет на pre-проде).
По п.3 тестировать deploy на проде не лучшая идея, тестирование самого развертывание необходимо проворачивать на pre-проде, а на прод отправлять уже отлаженный билд. ИМХО
Во время штатной работы системы вероятность обнаружения ошибки пользователем(клиентом) куда выше нежели одним тестировщиком, который будет параллельно пользователям проводить проверки, в т.ч. регрессионные. Регресс до прода обязателен.
По п.3 тестировать deploy на проде не лучшая идея, тестирование самого развертывание необходимо проворачивать на pre-проде, а на прод отправлять уже отлаженный билд. ИМХО
Во время штатной работы системы вероятность обнаружения ошибки пользователем(клиентом) куда выше нежели одним тестировщиком, который будет параллельно пользователям проводить проверки, в т.ч. регрессионные. Регресс до прода обязателен.
Тестирование на проде даёт самый ценный (и дорогостоящий) фидбэк. Заказчику не приносят прибыль безупречность тестовых стендов. Стороне исполнителя следует понимать, что они крайне заинтересованы в прибыли заказчика и балансировке фидбэка с тестовых и продовых окружений.
Последние полтора года, на одном из наших значимых проектов, дополнительно на проде по крону гоняем основные сценарии функциональных автотестов: создание заказов при различных входных данных по методам оплаты/доставки и т.д., с их последующей отменой. И это действительно оправданно в виду немалого количества интеграций со сторонними сервисами, которые периодически могут нестабильно себя вести, что следует отлавливать (получаем уведомления о фейлах автотестов в телеграм/почту) и пинговать поддержку сторонних сервисов. Вдобавок, имеются особые итерации на проде, минующие тестовые окружения (импорт сотен тысяч продуктов и т.д.), что могут повлечь за собой нестабильность прода. Для понимания жизнеспособности боевого окружения, в довесок к графикам из мониторингов (zabbix / newrelic / т.д.), ориентируемся на результаты автотестов.
Последние полтора года, на одном из наших значимых проектов, дополнительно на проде по крону гоняем основные сценарии функциональных автотестов: создание заказов при различных входных данных по методам оплаты/доставки и т.д., с их последующей отменой. И это действительно оправданно в виду немалого количества интеграций со сторонними сервисами, которые периодически могут нестабильно себя вести, что следует отлавливать (получаем уведомления о фейлах автотестов в телеграм/почту) и пинговать поддержку сторонних сервисов. Вдобавок, имеются особые итерации на проде, минующие тестовые окружения (импорт сотен тысяч продуктов и т.д.), что могут повлечь за собой нестабильность прода. Для понимания жизнеспособности боевого окружения, в довесок к графикам из мониторингов (zabbix / newrelic / т.д.), ориентируемся на результаты автотестов.
и все сторонние сервисы адекватно обрабатывают тестовые даные? это ж сколько лет нужно убить на согласования )
Нужный-правильный вопрос. Со всеми сервисами договариваться не пришлось, сделали упор лишь на те, где деятельность «ботов» давала заметный вред:
1. Call-центр. Заказчик заинтересован в стабильности, поэтому смогли быстро решить вопрос с тем, чтобы операторы не тратили время на заказы, выполненные под определёнными наборами данных (фио/email), по которым можно понять, что заказ совершён не человеком, а дружелюбным ботом, на которого нет нужды куда-либо жаловаться.
2. Склады с остатками продуктов. Тут всё просто: после автоматизированной отмены соответствующего заказа (в течение нескольких минут после создания), остатки по продуктам автоматически возвращались на склады. Обычная отлаженная ситуация, т.к. нередки случаи отмены заказов со стороны обычных пользователей.
3. Аналитика. Дабы избежать перекосов в конверсии и прочих направлениях, пришлось поколдовать: в автотестах при взаимодействии со ссылками и адресной строкой, проверять env по ответу isProduction(), в случае успеха — дописывать в линк особый get-параметр перед тем, как взаимодействовать с ним. На редиректящие кнопки без линков забили, т.к. все необходимые кейсы уже перекрывались применяемыми фильтрами в аналитике.
4. Эквайринг. Заказчик пошёл навстречу. Создавали заказы с определённым набором входных данных, позволяющий производить оплату определённых продуктов по минимально допустимой цене (дебетовая карточка настоящая, и баланс на ней не бесконечен). Правда, в первые дни словили бан со стороны эквайринга, посчитавшего наши операции подозрительными, но в итоге всё обошлось: со своей стороны, они добавили нашу подсеть и ещё-не-помню-какой набор данных в белый лист, после чего продолжаем спокойно оплачивать заказы. Возврат платежей происходил примерно через 30–45, так что в начале на карту закинули сумму, позволяющую создавать заказы в течение ~2+ месяцев.
Примечание: да, помимо факта создания заказа, процесс оплаты тоже тестим, ибо бывали случаи недоступности оплаты по карте, и все следы вели к стороне эквайринга.
5. Рекламные акции. Причём от различных сервисов, с неочевидной логикой появления баннеров в модальных окнах. При этом механика появления почему-то расходилась с теми задокументированными сценариями, которые были переданы со стороны их поддержки. Но успех не заставил себя долго ждать: каждый сервис предоставил набор cookie, с которыми на нашем целевом сайте не триггерился вызов соответствующей рекламной кампании.
1. Call-центр. Заказчик заинтересован в стабильности, поэтому смогли быстро решить вопрос с тем, чтобы операторы не тратили время на заказы, выполненные под определёнными наборами данных (фио/email), по которым можно понять, что заказ совершён не человеком, а дружелюбным ботом, на которого нет нужды куда-либо жаловаться.
2. Склады с остатками продуктов. Тут всё просто: после автоматизированной отмены соответствующего заказа (в течение нескольких минут после создания), остатки по продуктам автоматически возвращались на склады. Обычная отлаженная ситуация, т.к. нередки случаи отмены заказов со стороны обычных пользователей.
3. Аналитика. Дабы избежать перекосов в конверсии и прочих направлениях, пришлось поколдовать: в автотестах при взаимодействии со ссылками и адресной строкой, проверять env по ответу isProduction(), в случае успеха — дописывать в линк особый get-параметр перед тем, как взаимодействовать с ним. На редиректящие кнопки без линков забили, т.к. все необходимые кейсы уже перекрывались применяемыми фильтрами в аналитике.
4. Эквайринг. Заказчик пошёл навстречу. Создавали заказы с определённым набором входных данных, позволяющий производить оплату определённых продуктов по минимально допустимой цене (дебетовая карточка настоящая, и баланс на ней не бесконечен). Правда, в первые дни словили бан со стороны эквайринга, посчитавшего наши операции подозрительными, но в итоге всё обошлось: со своей стороны, они добавили нашу подсеть и ещё-не-помню-какой набор данных в белый лист, после чего продолжаем спокойно оплачивать заказы. Возврат платежей происходил примерно через 30–45, так что в начале на карту закинули сумму, позволяющую создавать заказы в течение ~2+ месяцев.
Примечание: да, помимо факта создания заказа, процесс оплаты тоже тестим, ибо бывали случаи недоступности оплаты по карте, и все следы вели к стороне эквайринга.
5. Рекламные акции. Причём от различных сервисов, с неочевидной логикой появления баннеров в модальных окнах. При этом механика появления почему-то расходилась с теми задокументированными сценариями, которые были переданы со стороны их поддержки. Но успех не заставил себя долго ждать: каждый сервис предоставил набор cookie, с которыми на нашем целевом сайте не триггерился вызов соответствующей рекламной кампании.
В общем, у вас таки внешние сервисы «с человеческим лицом».
А когда в качестве побочного эффекта от твоего тестирования на проде, можно случайно продать ньюйорк, и не продовского енвайрентмента не то что б совсем нет, но тот что есть — он таки продовский но с «органиченными правами», а ограниченность прав заключается в инструкции «по этим менюшкам не кликать»…
То желание что-то проверять смутно перерастает в желание описать все что не проверено, и зарепортить это как известные риски, с перенаправлением дальнейших шагов на сторону 3rd party )
А когда в качестве побочного эффекта от твоего тестирования на проде, можно случайно продать ньюйорк, и не продовского енвайрентмента не то что б совсем нет, но тот что есть — он таки продовский но с «органиченными правами», а ограниченность прав заключается в инструкции «по этим менюшкам не кликать»…
То желание что-то проверять смутно перерастает в желание описать все что не проверено, и зарепортить это как известные риски, с перенаправлением дальнейших шагов на сторону 3rd party )
Интересное мнение и опыт, спасибо!
Мы в компании тоже сталкиваемся с подобными вопросами: большое количество интеграций со сторонними сервисами и итерации, минующие тестовые окружения (в основном по изменению настроек и импорт-экспорт данных). Это ещё один пункт, объясняющий необходимость проверок на проде.
Также мы идём к тому, чтобы в проверках на проде помогали автотесты.
Мы в компании тоже сталкиваемся с подобными вопросами: большое количество интеграций со сторонними сервисами и итерации, минующие тестовые окружения (в основном по изменению настроек и импорт-экспорт данных). Это ещё один пункт, объясняющий необходимость проверок на проде.
Также мы идём к тому, чтобы в проверках на проде помогали автотесты.
нагрузка на CPU выше нормы – оповещение админам и девамтак это должно было быть найдено еще на этапе нагрузочного тестирования.
Некоторые ошибки можно обнаружить только под продолжительным и реальным уровнем многозадачности и нагрузки. Это касается утечек памяти, стабильности, быстродействия и устойчивости системы. Например, у нас была ситуация, когда возникла проблема быстродействия системы из-за того, что две ресурсоемкие задачи выполнялись в один промежуток времени.опять же, должно быть выявлено еще на стадии НТ
Sign up to leave a comment.
QA на проде. Почему это круто