Уронить прод что это значит
IT-понятия, которые помогут общаться с разработчиками
Ваш бизнес подрос, вам стало мало продаж в социальных сетях и вы решили создать собственный сайт или веб-сервис. Значит, пришло время научиться говорить с разработчиками. Собрали слова, которые позволят понять программистов.
Бэкенд
Серверная часть сайта, которая скрыта от глаз обычного пользователя. В бэкенде обрабатываются базы данных и пользовательские команды. Иными словами, бэкенд — логическое ядро сайта, которое отвечает за его стабильную работу.
Если сравнивать сайт с классическим рестораном, то бэкенд — это кухня, кладовка, винный погреб и другие помещения, которые недоступны обычным посетителям и без которых заведение попросту не сможет обслуживать клиентов.
Интерфейс
Часть сайта, которая видна посетелю. В него входят все способы ввода и вывода информации: меню сайта, кнопки для переключения страниц, поля для набора комментариев. Иными словами, интерфейс — всё, что можно увидеть на сайте и на что можно кликнуть.
Продолжая аналогию ресторана, можно сказать, что интерфейс — то, как выглядит зал ресторана, форма кресел и столовых приборов, а также внешний вид официантов.
Фронтенд
Код, запускающий работу интерфейса. Фронтенд привязывает к различным элементам платформы инструкции (скрипты) по их функционированию. Он отвечает за работу всего, что видно пользователю: кнопок, на которые можно нажать, форм верификации, ввод логина и пароля, анимации. Эта часть сайта собирает информацию, которую потом обрабатывает бэкенд. Если бэкенд используют администраторы ресурса, то фронтенд разрабатывают для пользователей.
В ресторане фронтенд — это обслуживающий персонал, с которым вы взаимодействуете: хостесс, которая подтверждает наличие свободного столика, и официант, принимающий заказ и рассказывающий, что вы не можете купить говяжий стейк в веганском заведении.
QA на проде. Почему это круто
Многие считают тестирование на production окружении вредной практикой: оно не помогает предотвратить попадание проблем к конечным пользователям, а больше констатирует их наличие. Кроме этого, тестировщик отрывается от стандартного рабочего процесса и методик, применяемых на тестовом окружении. Меня зовут Оля Михальчук, я QA-инженер в финтех-компании ID Finance. В этом посте я расскажу почему тестирование на проде может существенно помочь вашему проекту.
Зачем нужно QA на проде, если есть пре-продакшн окружение
В процессе разработки ПО всегда есть несколько окружений, на которых развёрнуто приложение. Среда, которой пользуются конечные пользователи, как вы знаете, называется production. Обычно предполагается, что тестирование нужно проводить на отдельном окружении, чаще на QA environment или Staging (пре-прод), чтобы предотвратить попадание ошибок к пользователям. Но есть такая методика, как QA на проде, которая отлично помогает решить задачи, которые на тестовом окружении решить физически невозможно.
В каких задачах помогает QA на проде
1. Проблема различия Staging и Production окружений.
Например, на нашем проекте пре-прод используется больше для функционального тестирования на сделанных вручную тестовых сценариях. Он не обладает техническими ресурсами, сравнимыми с продакшн средой. Также мы обычно не делаем полную синхронизацию конфигураций и БД с продакшн средой, что никак не мешает проводить функциональные тесты. Почему мы не копируем прод среду? Представьте, сколько ресурсов бы ушло, чтобы создать копию, допустим, Facebook, с такими же супермощными серверами, сервисами, базой данных и конфигурациями как на production. Это фактически как развернуть ещё одно такое же приложение.
Кроме того, при интеграции со сторонними сервисами вы всегда имеете разные настройки для тестового и боевого окружения (то же самое API). Я не утверждаю, что тестовая и staging среды бессмысленны. Просто нельзя на 100% гарантировать, что при успешном прохождении определённых тестов на одной среде сервисы не упадут на другой. Помочь в решении этой проблемы как раз и может дополнительное тестирование на production.
2. Реальные уровни многозадачности и нагрузки.
Некоторые ошибки можно обнаружить только под продолжительным и реальным уровнем многозадачности и нагрузки. Это касается утечек памяти, стабильности, быстродействия и устойчивости системы. Например, у нас была ситуация, когда возникла проблема быстродействия системы из-за того, что две ресурсоемкие задачи выполнялись в один промежуток времени. Разработчики оптимизировали работу задач, команда сделала тесты на пре-прод окружении, изменения доставили, затем сделали проверку на production.
3. Ошибки развёртывания
Из определения развёртывание (deployment) — это установка рабочей группой новой версии программного кода сервиса в инфраструктуру продакшна. Соответственно лучший способ увидеть ошибки развёртывания — это тестирование в процессе самого развёртывания.
4. Недостаток мониторинга на пре-проде
Один из лучших и незаменимых способов контроля того, что приложение работает так, как мы ожидаем – это ведение мониторинга по определённым метрикам. Например, из простых и наиболее критичных примеров: ведение мониторинга на количество регистраций новых пользователей в час, на конверсию от одного целевого действия к другому, на количество выданных кредитов. Конечно, такой мониторинг имеет смысл только на боевом окружении.
5. Возможность анализа сценариев использования системы, которые осуществляют конечные пользователи
Продакшн – кладезь тест-кейсов для тестировщика. При возможности у тестировщика видеть и обрабатывать сценарии, которыми пользуются конечные пользователи, тестировщик может выявить наиболее критичные сценарии, или выяснить причину появившегося дефекта, или обратить внимание на нетривиальные кейсы при тестировании на пре-проде.
6. Возможность ведения более достоверной статистики и метрик качества ПО.
Например, количество ошибок в логах приложения или компонента, баг-репорты и другая отчётность, которую может делать прод-тестировщик, более реально демонстрирует качество ПО по сравнению с теми же отчётами из тестового окружения.
7. Всегда лучше, если ошибку на проде заметит «свой» тестировщик, чем конечный пользователь.
Обычно после доставки задачи тестировщик делает базовые проверки новой или изменившейся функциональности на проде. Кроме того у нас в компании есть отдельно выделенный человек – тестировщик на проде. Хочу ещё раз отметить, что я не позиционирую QA на проде как замену тестированию на пре-продакшне, и, конечно предотвращать появление багов и проводить превентивные меры обязательно нужно. Но такое тестирование может стать отличной дополнительной техникой в процессе обеспечения качества на вашем проекте.
Полезные практики QA на production, которые эффективно работают у нас на проекте
1. Проверка доставленных задач с целью убедиться, что они хорошо задеплоились и работают на новом окружении.
Например, когда мы вводим интеграцию с новым партнёром, кроме тестов на пре-проде мы обязательно проверяем интеграцию после доставки, т.к существуют очень много настроек, зависящих от среды (API, урлы, компоненты). Также имеют место 3rd party issues – ошибки не на нашей стороне, а на стороне интегрируемых сервисов.
2. Логирование и аудит.
Хорошее логирование помогает разработчикам и тестировщикам заметить проблему ещё до того, как о ней догадается конечный пользователь, а также заметить места, нуждающиеся в оптимизации. Аудит действий и изменений позволяет всегда без проблем выяснить причины того или иного поведения. Например, если компонент кредитной политики не может выдать решение по кредиту, для анализа, почему это произошло, мы в первую очередь обращаемся к логам. Этот пункт касается как prodcution, так и pre-production сред.
3. Мониторинг и система оповещений
Как я упоминала выше, ведение мониторинга по определённым метрикам — один из лучших способов контроля того, что с нашим приложением всё «ok». Причём при возникновении какой-либо проблемы, надо обязательно слать об этом оповещение заинтересованным лицам (например, количество заявок по кредиту на 20% меньше ожидаемого – шлём оповещение IT и бизнес-отделам, нагрузка на CPU выше нормы – оповещение админам и девам). Нужно следить, чтобы оповещения о проблемах были своевременными и актуальными, а также реально указывали на проблему.
4. Регрессия и проверка стабильности
Классной практикой является периодическое прохождение регрессионных тестов, с целью убедиться, что нигде ничего не вышло из строя. Может помочь в каких-то узких и специфичных случаях, когда мониторинг не видит проблем.
5. Отчётность и ведение статистики
Как и в любом тестировании, отчётность и ведение статистики о результатах прод-тестирования делает процесс прозрачнее, качество ПО и причины возникновения дефектов более обозримыми.
Все ошибки невозможно выявить на пре-проде, поэтому они будут попадать в боевую среду. Если их обнаружат пользователи, это скажется на репутации компании и, в конечном счете, на потере денег. Тестирование на проде поможет это предотвратить.
Как выкатить обновление, если оно затрагивает все ваши сервисы
Обновления могут происходить каждый день, но иногда нужно выкатить фичу такого масштаба, что потенциальные ошибки поаффектят все ваши сервисы и пользователей. В статье расскажем, как сделать выкатку обновлений любой сложности в запланированный и анонсированный срок даунтайма без последствий для продакшен.
Что такое выкатка
Любой айтишник легко ответит, что такое выкатка: ставишь CI/CD, и автоматом все доставляется на прод.
Конечно, это верно. Сложность в том, что при современных инструментах автоматизации доставки кода теряется понимание самой выкатки. Как забываешь об эпичности изобретения колеса, глядя на современный транспорт. Все так автоматизировано, что выкатку часто проводят без осознания всей картины.
А вся картинка такова. Выкатка состоит из четырех больших аспектов:
Все эти аспекты необходимо учесть для успешной выкатки. Обычно оценивают только первый, в лучшем случае второй пункт, и тогда выкатка считается успешной.
Но третий и четвертый даже более важны. Какому пользователю понравится, если выкатка займет три часа вместо минуты? Или если на выкатке зааффектится что-то лишнее? Или даунтайм одного сервиса приведет к непредсказуемым последствиям?
Можно составить диаграмму Ганта или как-либо отобразить карту предстоящих событий для всей команды: сколько времени занимает каждое действие, что идет последовательно, что производится параллельно.
Пример диаграммы Ганта выкатки: из статьи о том, как команда платформы VK Cloud Solutions (бывш. MCS) выкатывала IAM (Identity and Access Management)
Хорошие практики для хорошей выкатки
Есть правила, которыми стоит руководствоваться, если вы выкатываете что-то сложное. Вообще говоря, их полезно соблюдать при любой выкатке. При этом чем выкатка сложнее, тем большую роль они играют.
Влияние выкатки на пользователей. Это первое, что надо понять: как выкатка может повлиять или повлияет на пользователей. Будет ли даунтайм? Если будет, то даунтайм чего? Как это отразится на пользователях? Какие возможны наилучшие и наихудшие сценарии? И закрывать риски. Например, заранее подготовить все, что можно подготовить прозрачно для пользователей. Или выкатывать фичу в то время, когда большинство пользователей не активны.
Четкий план. На каждом этапе нужно понимать все аспекты выкатки:
Репетиция сценариев. Проиграть сценарии до тех пор, пока не станут очевидны все этапы выкатки, а также риски на каждом из них. Если в чем-то есть сомнения, можно взять паузу и исследовать сомнительный этап отдельно.
Улучшения. Каждый этап можно и нужно улучшить, если это поможет нашим пользователям. Например, уменьшит даунтайм или уберет какие-то риски.
Тесты. Тестирование отката гораздо важнее, чем тестирование доставки кода. Нужно обязательно проверить, что в результате отката система вернется в первоначальное состояние, подтвердить это тестами.
Автоматизация. Все, что может быть автоматизировано, должно быть автоматизировано. Все, что не может быть автоматизировано, должно быть заранее написано на шпаргалке.
Результат. Нужно зафиксировать критерий успешности. Какой функционал должен быть доступен и в какое время? Если этого не происходит, запускайте план отката.
Действия команды. Самое главное — люди. Каждый должен быть в курсе, что делает, для чего и что от его действий зависит в процессе выкатки.
Если сказать одной фразой, то с хорошим планированием и проработкой можно что угодно выкатить без последствий для продакшен. Даже то, что аффектит все ваши сервисы.
Уронить прод что это значит
Смотреть что такое «прод» в других словарях:
прод. — прод. продовольствие продовольственный Словарь: С. Фадеев. Словарь сокращений современного русского языка. С. Пб.: Политехника, 1997. 527 с. прод. продукты продукция Словарь: С. Фадеев. Словарь сокращений современного русского языка. С. Пб.:… … Словарь сокращений и аббревиатур
прод… — (неол.). Сокращение, употр. в новых сложных словах в знач. продовольственный, напр. продмаг (продовольственный магазин), продработа, продналог и т.п. Толковый словарь Ушакова. Д.Н. Ушаков. 1935 1940 … Толковый словарь Ушакова
Прод. — прод. Начальная часть сложных слов, вносящая значение слова: продовольственный (продаттестат, продбаза, продмаг и т.п.). Толковый словарь Ефремовой. Т. Ф. Ефремова. 2000 … Современный толковый словарь русского языка Ефремовой
прод. — ПРОД. Первая часть сложных слов. Вносит зн. сл.: продовольственный. Продбаза, продналог, продпункт, продсклад, продтовары … Энциклопедический словарь
проділь — я, ч., розм. Те саме, що проділ I … Український тлумачний словник
прод… — Первая составная часть сложных и сложносокращенных слов, соответствующая по значению слову продовольственный, например: продмаг, продотряд, продналог, продпункт, продразверстка … Малый академический словарь
прод. — продовольственный; продольный … Русский орфографический словарь
проділ — I у, ч. Рівна лінія, що утворюється при розчісуванні волосся на два боки. •• У (на) про/діл на два боки з рівною лінією посередині (про зачесане волосся). II у, ч. Дроблена гречана або рисова крупа … Український тлумачний словник
продір — а, ч., зах. Голка без вушка … Український тлумачний словник
Что значит слово прода?
Многие из тех кто любит читать книги, пытаются узнать, что значит прода и как это переводится. Если речь идёт о литературе, то прода это продолжение. Получено данное слово путем простого сокращения. Ведь не слишком удобно постоянно писать на форумах и в группа длинное «продолжение», куда легче идёт простенькая «прода». Стоит отметить, что такое сокращение появилось неспроста. И сейчас мы узнаем, как это произошло.
Как появилось слово прода среди читателей?
Данный термин образовался тогда, когда в интернете стало можно выкладывать свое творчество большого формата.
Авторы быстро поняли, что выкладывать все и сразу — это неправильно. Ведь так надо долго копить материал. И узнать реакцию читателей заранее никак невозможно.
Поэтому писатели стали публиковать небольшие отрывки своих произведений, по мере написания или просто… по мере.
В итоге, они вечно писали продолжения, как бы продлевая уже начатое.
Что значит читатели требуют проду?
Читатели требуют проду, это значит, что им нужно продолжение того или иного произведения. Так часто бывает, когда автор заинтересовал многих людей своей книгой.
А затем у него произошел творческий кризис. В итоге, читатели начинают интересоваться, когда же будет дописана история. Или хотя бы, будет ли она вообще писаться дальше.
Это явление называется эффектом, когда читатели хотят проду.
Кстати, это является показателем качества автора. Так как заинтересовать сегодняшнюю публику надо ещё и уметь.
Как зарабатывают на публикации проды?
Очень просто. Многие сайты самиздата построены на том, что писатели получают там средства не за саму книгу вместе.
А за то, что просто публикуют продолжения. Например, на портале ЛитНет есть подписка.
Если у вас имеется определенный рейтинг, то вы можете закрыть свою книгу. И новые главы (проду) не будет видеть никто.
Но если человек заплатит определенную сумму, то он сможет смотреть обновления. Вот вам такой тип дохода.
На Автор Тудей есть возможность вообще получать за каждую проду (от 15 000 символов) по 10 рублей или более.
Это так называемый «выкуп глав». Но он тоже доступен тем писателям, у кого имеется рейтинг среди читателей.
Кстати, стоит отметить, что слово прода может переводиться в некоторых областях деятельности, как продажа чего-либо.
Но в рамках интернет литературы — это именно продолжение. По крайне мере, так происходит пока. Потом может быть и переименуют. Творчество — изменчивая вещь, как никак.