Едет он релиз что это
Телекс Релиз
Скорее всего, Вы уже не раз встречались с понятием “Телекс релиз” (Telex Release). Этот термин особенно часто используется в морских контейнерных перевозках. В данной статье мы рассмотрим определение, условия использования и историю возникновения данной дефиниции. Постараемся объяснить, что такое телекс…
Скорее всего, Вы уже не раз встречались с понятием “Телекс релиз” (Telex Release). Этот термин особенно часто используется в морских контейнерных перевозках. В данной статье мы рассмотрим определение, условия использования и историю возникновения данной дефиниции. Постараемся объяснить, что такое телекс релиз коносамента простыми словами на доступном широкому кругу языке.
В некоторых случаях, отправитель или экспортер может сдать оригиналы коносамента агенту в порту отправления. Далее линия передает в порт назначения инструкцию о том, что груз может быть выдан получателю. При этом получатель не должен предоставлять оригиналы коносамента в порту выгрузки.
Можно сказать, что телекс релиз является обычным сообщением, содержащим вышеописанную инструкцию. Это сообщение передается между офисами линии в портах отправления и назначения.
Отправитель или экспортер обычно запрашивают у линии телекс релиз коносамента в следующих случаях.
По правилам телекс релиз может быть оформлен только если коносамент выпущен как прямой (Straight B/L).
Термин TELEX происходит от акронима выражения TELegraph EXchange service (сервис телеграфного обмена). Таким образом, сообщение, отправляемое при помощи телеграфной сети, называется Telex message. Этот вид связи был сильно распространен до 80х годов. Ему на смену пришли более современные факсимильные машины.
Таким образом, распоряжение о выпуске груза, передаваемое из порта отправления в порт назначения, называется телекс релизом. Так как в прошлом такие инструкции передавались с помощью телеграфной сети.
В настоящее время обмен информацией происходит с помощью электронной почты или в информационных системах перевозчика. Но название закрепилось, так как довольно длительный период именно использование телеграфной сети позволяло быстро передать информацию на большие расстояния.
Управлять релизом просто: правила и этапы release management
Релиз является одним из самых важных и ожидаемых событий в жизненном цикле продукта. Приготовления к релизу могут занимать много усилий и времени, участия всей команды и заинтересованных сторон. Хорошо, если выпуск продукта или его версии проходит гладко и становится настоящим праздником. Но бывает иначе. Что из себя представляет эффективный релиз-менеджмент и как менеджерам продукта научиться его секретам?
Релиз связан с запуском нового продукта/сервиса/услуги или набором новых функций, изменений, которые становятся доступны клиентам или пользователям и обеспечивают новую продуктовую ценность.
Часто релиз состоит из ряда решений по устранению проблем и улучшений предоставляемых услуг, может включать изменения в ПО. На самом деле, это довольно значимое событие как для внутренних команд, так и для целевой аудитории.
Управление релизами помогает командам планировать свою работу и видеть конечный результат, а для клиентов это, своего рода, гарантия качества и получения новой ценности.
Хорошо подготовленный релиз — это не только предоставление доступа к новым техническим возможностям продукта. Это конечная дата, когда ваша команда может предоставить новый пользовательский опыт, поддержать и развить взаимодействие с ним.
Релизы должны включать все дополнительные задачи и активности, такие, например, как обновления на официальном сайте и в социальных сетях, обучение команды поддержки, обновление всех маркетинговых материалов и т. д.
Основная цель управления релизом — создавать, тестировать и доставлять новые возможности, которые будут удовлетворять все продуктовые требования и намеченные цели.
Продуктовым командам стоит тщательно планировать релизы, поскольку они являются новым предложением, которое ожидают клиенты.
Что включает процесс управления релизом?
Понимание процесса управления выпуском продукта может отличаться у разработчиков и нетехнических специалистов. Важно учитывать все аспекты релиза и прислушиваться к мнению каждого члена команды.
Процесс управления релизом может включать следующие этапы:
В управлении релизом продукта могут участвовать практически все члены команды.
Product manager и Project Manager
Менеджеры продуктов и менеджеры проектов несут основную ответственность за релиз. Функционал product manager project и manager отличается, но миссия у них одна — выпустить продукт и представить его клиентам в идеальном виде.
Разбработчики
Команда разработки — это ключевые игроки в управлении релизом, поскольку они участвуют в большинстве процессов в жизненном цикле продукта. Они оценивают изначальные затраты и время, определяют основные требования, создают документацию и разрабатывают функциональность. Они принимают главные решения о том, что можно сделать и что не нужно, а также сколько времени это займет.
Маркетинг
Маркетологи всегда должны “держать руку на пульсе” и быть в курсе того, чем живут конкуренты. В управлении релизом им важно тесно отрудничать с sales-менеджерами для получения новых и удержания существующих клиентов.
Тестировщики
Тестировщики работают вместе с разработчиками. Их задача — тестировать результаты исследований и разработки, основываясь на установленных критериях. Продукт не придет к релизу, пока не будут учтены все замечания и критерии прохождения тестирований.
Служба поддержки
Support-команда или отдельный специалист поддержки первыми получают сообщения, елси что-то пошло не так. Они должны понимать и знать все о релизе и должны быть должным образом подготовлены на всех уровнях еще на стадии планирования.
Помимо этих основных ролей, к управлению релизом могут привлекаться и другие специалисты: отдела закупок, финансисты, sales, биллинг, system engineering и др.
Почему нужно внедрять процесса управления релизам?
Что такое Release Notes в процессе управления релизом?
Release Notes — это примечания к версии продукта, в которых описываются изменения между выпускаемой и предыдущей версиями этого продукта. Такой документ может составляться для пользователей и для внутренних команд: тестировщиков, маркетологов, службы поддержки.
Когда используются примечания к релизу?
Примечания к релизу распространяются вместе с продуктами. Иногда — когда продукты все еще находятся в разработке или тестировании. Документ может быть доставлен клиентам при выпуске обновления (для продуктов, которые уже были использованы клиентами).
Вы можете найти различные варианты написания Release Notes, поскольку для этого документа нет единого стандарта или формата. В разных компаниях менеджеры продуктов, тестировщики и разработчики, которые обычно ответственны за написание примечаний, обычно используют свои собственные шаблоны.
Вот как выглядит страница с примечаниями к релизу у Firefox:
Как писать примечания к релизу?
Содержание документа зависит от типа релиза. Вот пример основных пунктов:
Заключение
Управление релизом во многих компаниях становится отдельным самостоятельным процессом, который сообщает заказчику дату выпуска продукта и основные этапы его развития. Заказчик участвует в приоритизации и вовлечен в определение содержания релиза.
Процесс позволяет менеджерам продуктов и команде своевременно оценить загрузку и управлять объемом работ, доставлять изменения в срок. Управление релизами позволяет собирать собственную статистику, с которой удобнее в дальнейшем обосновывать запросы на дополнительные ресурсы.
Если вы хотите детальнее разобраться в теме release management и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)
Шпаргалка по расшифровке имен видеофайлов
Как то стало интересно что значат разные буковки/цифарки через точку в названиях видеофайлов.
Пост — результаты гугления, обобщения, структуризации и некоторой правки орфографии.
Возможно, кому то пригодится. Я, например, перестал связываться с TC.
Изображение
CAMRip (CAM, «экранка», «тряпка»)
Иногда ошибочно помечают как Screen (SCR). Видео и звук записывают на камеру в зале кинотеатра. Изображение иногда может быть снятым под углом к экрану, дрожать, в некоторых фильмах видны головы других кинозрителей и т.д. Качество звука бывает разное, возможны помехи типа смеха публики. Обычно самое плохое и самое первое качество, которое можно найти после официального релиза фильма.
Telesync (TS)
В идеале записывается с экрана профессиональной (цифровой) камерой, установленной на штатив в пустом кинотеатре либо в кабине оператора. Качество видео намного лучше, чем в CAMRip. Звук записывается напрямую с проектора или другого отдельного выхода, например гнезда для наушников в кресле. Таким образом, звук получается очень хороший и без помех, как правило в режиме стерео. Много TS — это в действительности CAMRip, у которых перепутали название.
Telecine (TC, «рулон»)
Копия снимается с киноленты c помощью специального оборудования (фильм-сканера) либо записывается со специального проектора с выходами для аудио и видео. Качество зависит от применяемого оборудования — от хорошего до неотличимого от DVD, звук отличный. Иногда бывают проблемы с естественностью цветов («желтизна» картинки).
Super Telesync (SuperTS, Super-TS, «оцифровка»)
Это TS (изредка ТС), прогнанный через компьютер — фильм осветлен, выровнен, убраны посторонние шумы изображения и звука и т.п. Качество зачастую неплохое, но зависит от создателя.
DVD-Rip (DVDRip)
Рип с оригинального DVD, зачастую сжатая в MPEG4 для уменьшения размера фильма. В основном встречаются DVDRip объемом 650-700 Мб и 1,3-1,5Гб. Качество — очень хорошее, хотя зависит от мастерства создателя («риппера»). Иногда версии c лучшим качеством обозначают как SuperDVD, HQ DVD.
DVD5 (DVD-5)
Копия (несжатая) с оригинального DVD. Объем — 4-4,5 Гб.
DVD9 (DVD-9)
Копия (несжатая) с двухслойного оригинального DVD. Объем — 7-9 Гб.
R5
DVD-Rip с диска, распространяемого в пределах СНГ (а такие диски выходят раньше, чем в других странах) с оригинальной (т.е. английской) звуковой дорожкой, взятой из других источников.
Как вариант — Telecine (TC, «рулон»).
DVD-Screener (DVDScr, DVDScreener) (SCR)
Копия c «promotional» DVD (диск для кинокритиков, рекламная версия или бета). Качество — как DVDRip, но картинка обычно «испорчена» водяными знаками, предупреждающими надписями и черно-белыми вставками («пропадающая цветность»).
SCREENER (SCR) или VHS-SCREENER (VHSScr)
То же самое что и DVDScr, только с видео кассеты. Копия c «promotional» VHS (кассета для кинокритиков, рекламная версия или бета). Качество изображения сравнимо с очень хорошим VHS, но картинка обычно «испорчена» водяными знаками, предупреждающими надписями и черно-белыми вставками («пропадающая цветность»). Звук неплохой, обычно стерео или Dolby Surround.
PDTV-Rip (PDTVRip)
Pure Digital Television Rip — рип с «чистого» цифрового телевидения. Обозначение показывает, что при кодировании не было преобразования с аналогового сигнала в цифровой. Под общим обозначением PDTV-Rip может скрываться SAT-Rip, DVB-RIP, IPTV-RIP. Источником может служить спутниковый канал (DVB-S), некодированое наземное цифровое вещание DVB-T, иногда IP-телевидение и другой канал цифрового вещания, в котором не применяются (или успешно обходятся) специальные методы, препятствующие прямой записи цифрового потока. Чаще всего присутствует логотип канала.
TV-Rip (TVRip)
Материал записан с телевизионного сигнала, обычно кабельного (но попадаются и с простой антенны). Почти все телесериалы первично раздаются именно в этом или SATRip формате. Качество зависит от оборудования, программного обеспечения и умения рипующего.
Transport Stream
Необработанный (сырой) аудио-видео поток, взятый напрямую с цифрового телевидения.
SAT-Rip (SATRip)
Аналогично TVRip. Материал записан со спутникового видео (как правило, это цифровое MPEG2 видео). Качество зависит от провайдера, канала и качества рипа. Обычно такой Rip лишь немного уступает DVDRip (хотя есть исключения). Чаще всего присутствует логотип канала.
DSRip
То же что и SAT-Rip (SATRip).
IPTV-Rip (IPTVRip)
Аналогично SATRip. Материал записан с цифрового IP-телевидения (как правило это цифровое MPEG2 или MPEG4 видео). Обычно такой рип лишь немного уступает DVDRip. Чаще всего присутствует логотип канала. Появился сравнительно недавно.
WEB-DL и WEB-DL 720p
Рипы полученные с трансляций через Интернет с магазина iTunes Store. Основная особенность — повышенное качество (наравне с BDRip’ами), нет логотипов телеканалов и присутствуют финальные титры.
iTunes Digital Copy
Видео, полученное из интернет-магазина Apple по коду, указанному на упаковке лицензионного DVD или BD или находящееся непосредственно на диске.
DVB-Rip (DVBRip, DVB-T Rip)
Аналогично SATRip. Материал записан наземного цифрового телевещания (как правило это цифровое MPEG2 видео, изредка — MPEG4). Качество зависит от провайдера, канала и качества рипа. Обычно такой Rip лишь немного уступает DVDRip (хотя есть исключения). Чаще всего присутствует логотип канала.
HDTV-Rip (HDTVRip)
Рип с HDTV фильма (1920×1080, 1280×720), который часто делается с разрешением обычного (неHDTV) рипа (иногда с оригинальным разрешением). Качество зачастую лучше DVDRip. Под общим названием HDTV-Rip встречаются рипы с BD-Rip, HDDVD-Rip, цифровых спутниковых и кабельных операторов, вещающих в HDTV. В описании зачастую встречаются обозначения 720p, 1080p, 1080i, 1280p (см. ниже.)
BD-Rip (BDRip, BRRip, BR-Rip)
Рип с Blu-Ray DVD диска (от 25 Гб на слой). Относится к HDTV. У настоящих BDRip фильмов качество намного лучше DVDRip. Объем файла — Объем файла – от 2 до 9,5 Гб. Часто сразу в обозначении указывают и размер картинки. Например, BDRip.720p BDRip.1080p. Иногда встречаются рипы с DVD с увеличеной картинкой и неверным обозначением BDRip.
HD-DVD-Rip (HDDVDRip, HDDVD-Rip, HDDVD)
Рип с HD DVD диска (от 15 Гб на слой). Относится к HDTV. В связи с фактически проигрышем HD-DVD в войне форматов Blu-Ray VS HD-DVD, количество таких рипов будет незначительно.
HDDVD-Remux
Пересобранные потоки оригинального HDDVD без меню в контейнер, как правило, TS или MKV.
Видео идентично оригиналу. Никаких потерь в качестве.
BluRay-Remux
Пересобранные потоки оригинального BlyRay диска без меню в контейнер, как правило, TS или MKV.
Видео идентично оригиналу. Никаких потерь в качестве.
Laserdisc-RIP (LDRip)
Аналогично DVDRip. Эта версия делается из Laserdisc. Встречается довольно редко, в основном старые фильмы.
VHS-Rip (VHSRip)
Источник материала кассета формата VHS, обычно довольно среднего качества.
DTheater-Rip
Оцифровка кассеты высокой четкости. Качество видео достаточно высокое. Может присутствовать шум и нечеткость картинки.
AVC (Advanced Video Coding)
Лицензируемый стандарт сжатия видео (H.264 он же MPEG-4 Part 10), предназначенный для достижения высокой степени сжатия видеопотока при сохранении высокого качества.
720p, 1080p, 1080i, 1280p и т.д. — обозначения встречаются в HDTV-фильмах и рипах.
Цифра — разрешение картинки по вертикали при соотношении сторон 16:9. К примеру — 720p — 1280×720
i (interlaced scan) — чересстрочная развертка, изображение формируется из двух полукадров (как в обычном телевидении). При этом уменьшается поток (следовательно и размер файла), но в движении видно т.н. «эффект гребенки» на границе цветов. Частота 50 или 60 полукадров в секунду
p (progressive scan) — прогрессивная развертка, кадр передается и формируется целиком, при этом картинка в движении не искажается. Недостаток progressive — увеличенный в два раз поток по сравнению с interlaced. Вследствие — больший размер файла или меньшая частота кадров.
Соотношение сторон
Fullscreen (FS)
Релиз в полноэкранном режиме, разрешение видео 3:4. Часто Fullscreen делают из Widescreen-версии методом Pan and Scan (PS), обрезая часть кадра по бокам.
Widescreen (WS)
Один из изначальных вариантов записи широкоэкранного видео на DVD (другой — Letterbox) — анаморфированный (изображение, обычно 16:9, растянуто на весь кадр 4:3 — в итоге качество лучше).
Letterbox
Один из изначальных вариантов записи широкоэкранного видео на DVD (другой — Widescreen (WS)) — изображение, обычно 16:9, не растянуто на весь кадр, а оставлены черные полоски сверху и снизу.
Pan and Scan (PS)
Метод преобразования widescreen (WS) видео в полноэкранный режим fullscreen (FS). При этом обрезается часть кадра справа и слева.
WATERMARKED
Маленькие логотипы TV-канала или релизера.
Особенности фильма
Director’s Cut (DC)
Режиссерская версия — специальная редакция фильма, представляющая фильм с точки зрения режиссера, а не подредактированная согласно требованиям заказчиков, прокатчиков, студии, кинокритиков и т.д.
Workprint (WP)
Это так называемая «Бета-версия» фильма. Особо интересная для ценителей фильмов. Обычно выходит в формате VCD намного раньше до начала показа в кинотеатрах мира. Из-за того, что это предварительная версия фильма, качество материала может быть как отличным, так и очень низким. Часто могут отсутствовать некоторые сцены, компьютерные спецэффекты. Однако в Workprint могут также быть сцены, которые в окончательной версии вырежут. Узнать такие версии можно по таймеру вверху или внизу экрана (он нужен для последующего монтажа окончательной версии).
LIMITED
Фильм был показан ограниченном количестве кинотеатров. Обычно не более 250-500.
Special Edition (SE)
Специальная версия фильма. Ярким примером может служить отреставрированная версия «Звездных войн» с добавлением на материал 70-х годов компьютерной графики, анимации, 3D-моделей.
Straight To Video (STV)
Фильм сразу вышел на DVD/кассете минуя кинотеатры. Качество — соответственно DVDrip или VHSrip.
Особенности релиза
DUPE
Второй релиз того же фильма другой релизной группой (обычно краденный у первой)
PROPER
Повторный релиз фильма (иногда другой группой) в связи с плохим качеством предыдущего.
RECODE
Релиз, переделанный в другой формат или заново кодированный
RERIP
Новый рип фильма
Dubbed
Из фильма убран оригинальный звук. Например взяли дорожку из русского кинотеатра и наложили на американский релиз.
Mic.Dubbed
Тоже самое как и Dubbed, только звук был записан микрофоном в кинотеатре.
Line.Dubbed
Тоже самое как и Dubbed, только в этом случае звук был взят из «кресла» или «проектора» (Line).
D — дублированный (дубляж)
L1 — любительский одноголосый перевод
L2 — любительский двухголосый перевод
L — любительский многоголосый перевод
O — оригинал (в русских фильмах)
P1 — профессиональный одноголосый перевод (зачастую авторский)
P2 — профессиональный двухголосый перевод
P — профессиональный многоголосый перевод
Стоит заметить, что буква P в названии фильма может также обозначать профессиональный двухголосый перевод, равно как и L — любительский двухголосый, так как многие релиз группы не делят перевод на многоголосый и двухголосый.
Альтернативный вариант
AVO — (Author Voice Over) — Авторский
SVO (1VO) — (Single Voice Over) — Одноголосый
DVO (2VO) — (Double Voice Over) — Двухголосый (или «мальчик — девочка»)
MVO — (Multi Voice Over) — Многоголосый (три и более)
DUB — (Dublicated) — Дубляж
SUB — (Subtitle) — Субтитры
Дублированный перевод (Дубляж) — это когда в фильме актеры говорят на языке, который вы понимаете, и когда абсолютно не слышно языка оригинала, при этом все остальные звуки должны сохраняться и должен сохраняться липсинг (lipsync — синхронизация движения губ), т.е. у зрителя должно создаваться впечатление, что актер говорит на родном зрителю языке.
Полный дубляж фильма — это технически сложный процесс и считается «высшим пилотажем» в озвучке фильма. Осуществляется профессионалами на киностудиях. Для того, что-бы дублировать фильм все записанные звуки и голоса должны быть разъединены, чтобы заменив голоса, затем свести общий звук.
Многоголосый закадровый перевод (может быть профессиональным или любительским) — это когда оригинальная речь фильма приглушается (одновременно приглушаются немного и другие звуки) и поверх накладываются голоса нескольких актеров (профессиональный) или не актеров (любительский), но оригинальная звуковая дорожка всё равно немного слышна.
Двухголосый закадровый перевод – закадровый перевод, но в отличии от многоголосого – фильм переводит два дублера, мужчина и женщина.
Одноголосый закадровый перевод – перевод, где всех актеров озвучивает один и тот же дублер (обычно мужчина). Такие переводы особенно знакомы всем любителям кино на видеокассетах 80-90х годов. Образцы голосов переводчиков.
Синхронный перевод – это перевод речи оратора с отставанием в 2-3 секунды,
Из одноголосых переводов отличился — Дмитрий Пучков он же «Гоблин». При этом различается два направления переводов «Божья искра» и «Полный Пэ». Перевод закадровый, в один голос (голос Гоблина соответственно).
Студия «Полный Пэ» – правильные переводы Гоблина. Отличаются адекватностью и максимальным соответствием оригинальному тексту фильма. Нецензурная брань, если таковая имеет место быть в оригинале, переводится как нецензурная брань. Если брани в оригинале нет, значит и в переводе брани нет.
Студия «Божья искра» — смешные переводы Гоблина. Пародии на отечественные кино-переводы в исполнении Гоблина. В лучших традициях доморощенных «переводчиков», чьи голоса звучат за кадром, Гоблин несёт полную ахинею, в корне меняя диалоги и сюжет фильма.
Субтитры
Subbed
Фильм с субтитрами.
Hardsub
Субтитры внедрены в видео-поток.
Softsub
Субтитры идут отдельным файлом/потоком, и рендерятся самим плейером.
Как катать релизы несколько раз в день и спать спокойно. Доклад Яндекса
Высокие темпы разработки сопряжены с рисками, влияющими на отказоустойчивость и стабильность — особенно если хочется экспериментировать и пробовать разное. Разработчик Маркета Мария Кузнецова рассказала о релизном цикле своей команды от и до, а также о мониторингах и других вещах, позволяющих обновлять сервис со скоростью три релиза в день.
— Всем привет! Я представляю бэкенд-разработку курьерской платформы. Поговорить хочу о том, как нам удается, с одной стороны, двигаться быстро, а, с другой стороны, не потонуть в ворохе и потоке проблем и ошибок.
(. ) Сейчас у нас в среднем выкатывается по три релиза в день.
Стек технологий, которые мы используем типичен для Java-приложений Маркета. Мы используем 11-ю Java, Spring, PostgreSQL для хранения данных, Liquibase для накатывания миграций и Quartz для регулярных Cron-задач. Конечно, у нас реализовано много интеграций с внутренними сервисами.
Начать я хочу с того, как у нас устроен процесс релиза.
1. Релизы
С самого начала проекта мы живем в парадигме trunk-based development. Чтобы код попал в продакшен, нужно поставить пул-реквест и пройти код-ревью. Причем в пул-реквесте запускаются также и прикоммитные проверки, в первую очередь это юнит-тесты и функциональные тесты.
Среды у нас сейчас только две — продакшен и тестинг. Когда код-ревью пройдено и код попал в trunk, запускается вот такой релизный пайплайн.
Дальше я покажу все шаги подробнее.
Начинается сборка релиза. На этапе сборки релиза опять прогоняются тесты. Про то, как мы пишем тесты, говорил Андрей, и в нашей команде мы разделяем этот подход. Релиз собрался, и дальше начинается сам процесс его выкатки. На слайде представлены сразу два шага — процесс попадания в тестинг и шаг проверки.
Все сервисы Маркета, за очень редким исключением, имеют минимум два инстанса, минимум один в каждом дата-центре. Раскатка релиза происходит поэтапно. Вначале один инстанс, или процент, если инстансов много, потом все остальные. Если вначале что-то идет не так, выкатка дальше не пойдет, релиз останавливается и нужно идти разбираться.
Всё, релиз раскатили. Идёт шаг проверки. По сути мы заменили ручной регресс тестирования на интеграционные тесты, но также добавили нагрузочные тесты. Самое главное: на каждом шаге мы пытаемся выявить проблему и не допустить, чтобы плохой код попал в продакшен.
Конечно, у нас есть ограничения при выкатке релиза. Парадигма trunk-based development диктует то, что не должно быть долго живущих feature branches, и получается так, что в trunk может оказаться незаконченная функциональность.
Никто не отменял обратную совместимость между соседними релизами. Но тут нам немножко попроще. Наши пользователи — курьеры, мы поддерживаем для них мобильное приложение. И можем курьерам форсированно обновлять версию мобильного приложения, поэтому обратную совместимость нам тоже нужно поддерживать ограниченное время. Оно задается тем, сколько мобильных приложений мы сейчас поддерживаем. Обычно только два последних, все остальные невалидны.
При чем здесь кот Шредингера? Часто новая функциональность в продакшене должна и работать, и не работать одновременно: для каких-то пользователей должна быть включена, а для других все должно работать по-старому. Можно было бы, конечно, поднять отдельный инстанс, бэкенд с новой функциональностью, пустить туда какую-то часть пользователей, а остальных оставить на старых.
Но такой подход звучит дорого.
2. Feature toggles
Поэтому мы пришли к тому, что стали использовать feature toggles. Toggles с английского переводится как переключатель, и это в точности описывает его предназначение.
Можно выкатить код и пока не использовать его в продашкене, например, ждать поддержки фронтенда или же дальше его реализовывать.
Нам очень важно уметь включать-выключать функциональность по отмашке от коллег. Поэтому свой toggles мы сложили в базу.
Поскольку функциональность не всегда нужно сразу включать на всех пользователей, сделали feature toggles на пользователя и тоже положили их в базу. Так мы можем точечно включать функциональность, и это дает возможность провести эксперименты. Например, мы делали новую функциональность под кодовым названием «Звонки». Это напоминание курьеру о том, что у него скоро доставка. (. ) Такая функциональность сильно перестраивала процесс работы курьера, и нам было важно проверить, как процесс летит в реальном времени, в реальной жизни.
По первым результатам эксперимента мы поняли, что после звонка курьеру некуда записать комментарии от пользователя. Поэтому срочно добавили комментарии и возможность работы с ними. И дальше уже пользователей в эксперимент добавляли только с этой функциональностью. С помощью feature toggles у нас сделана выкатка на процент пользователей. Мы храним версию и требуем от курьера, чтобы у него была установлена именно она. В противном случае просим его обновиться.
Конечно, у такого подхода есть минусы. Toggles скапливаются, и здесь ничего не остается, кроме как их убирать. Также увеличивается сложность тестов, потому что проверять свой код нужно во всех режимах работы toggles. Кроме того, toggles лежат в базе, поэтому получается лишний поход в БД. Здесь ничего не остается, кроме как поставить кэш. Какие плюсы мы за это получаем?
Мы получаем возможность спокойно жить в парадигме trunk based development. Также можем проводить точечные эксперименты на пользователях.
Я уже приводила пример со звонками. Мы поддерживаем не просто изменение кода — зачастую это изменение бизнес-процессов. Нам нужно проверять еще и то, насколько готов офлайн, как хорошо мы донесли это до курьеров, что мы от них хотим.
Мобильное приложение обычно тоже раскатывается не сразу на всех пользователей, а вначале на какой-то процент из них. И мы можем получить такую ситуацию, что в зависимости от пользователя бэкенд должен иметь разную логику. Это не только изменения в API, но и именно изменения в бизнес-логике. Toggles нам тоже помогают решить такую задачу.
Остался вопрос про деградацию. Мы обслуживаем офлайн-процесс, и в случае любых проблем с ПО нам нужно сделать так, чтобы самая важная часть функциональности работала. Чтобы курьеры могли выдать посылку, выбить чек и понять, куда ехать дальше.
А вот если, например, у нас возникли проблемы с фото посылки, можно отключить эту функциональность, разобраться с проблемой, устранить ее и включить обратно.
Выкатили релиз, включили функциональность. Казалось бы, наша работа закончена, можно расслабиться. Но нет, начинается самое интересное. Мы должны понимать, что происходит в продакшене прямо сейчас, и находить проблемы раньше, чем они начнут мешать нашим пользователям.
3. Метрики и мониторинги
Поэтому дальше я хочу поговорить о метриках и мониторингах. Сразу скажу: в этой части мы не будем обсуждать, какие системы сбора и визуализации метрик использовать. Для этого есть опенсорс-решения. У себя для сбора метрик мы используем Graphite и, как и для мониторингов, внутреннюю систему.
Какую информацию мы собираем? На слайд я выписала формальное определение метрик и мониторинга.
Но предлагаю рассмотреть, что это такое, на примере.
Метрика обычно представляется как график, он описывает какой-то параметр нашей системы. А мониторинг — это событие, превышение заданного ранее порога и какое-то действие, которое необходимо предпринять при превышении порога.
Какие могут быть действия? Конечно, самое важное — уведомить ответственных: написать в мессенджер или позвонить. Реже — запустить процесс откатки последнего релиза. У себя в проекте мы такой вариант не используем. Еще есть вариант мониторинга, который мы называем «загорается лампочка». Произошло интересующее нас событие, и оно отобразилось в интерфейсе мониторинга. Дальше тоже происходит действие — уведомить ответственных или еще что-то.
Мы говорим про Java-приложение, а оно должно быть где-то запущено, будь то контейнеры или железные машины. Ресурсы и в том, и в другом случае для нас конечны, нам нужно понимать, как мы их используем. Наши приложения мы запускаем во внутреннем облаке, облако нам предоставляет всю подобную информацию. Информацию о ресурсах стоит собирать не только на контейнерах, где живет ваше приложение, но и там, где работает ваше хранилище.
На слайде пример, как нам в базе перестало хватать CPU.
Окей, у нас Java-приложение, и, конечно, стоит собирать информацию о состоянии JVM.
Мы используем Spring, поэтому для решения такой задачи хорошо подходит библиотека Spring Boot Actuator. Она добавляет endpoint в ваше приложение, и к этому endpoint можно обратиться по http и получить необходимую информацию о памяти или что-то еще. Окей, приложение запущено. Дальше оно вообще работает или нет? Что с ним происходит? Можно отправлять запросы в это приложение или нет?
Такие вещи нужно понимать не только нам, но и балансеру. Для этого мы добавляем в приложение контроллер с двумя методами — Ping и Monitoring. Рассмотрим вначале Ping. Он отвечает на вопросы, живо ли приложение, можно ли отправлять на него запросы. И отвечает он это в первую очередь не нам, но балансеру. Но мы же используем этот метод для мониторинга того, живо приложение или нет.
Метод Monitoring дает нам возможность получать сообщения о неполадках в системе. Например, не удалось загрузить знания, с которыми работает приложение, или не удалось их обновить. Или же процесс по распределению заказов между курьерами закончился ошибкой.
Мониторинги строятся на системе статусов и приоритетов между ними. Событие мониторинга в минимальном варианте описывается именем, временем, до которого действует мониторинг, но и статусом. По истечении этого времени мониторинг считается пройденным, погашенным и переходит в статус «ok».
Получается такой простейший интерфейс мониторинга. Добавить или обновить событие и вернуть текущее состояние мониторинга в оговоренном формате.
У нас есть клиент — мобильное приложение, нужно понимать, как качественно мы отвечаем клиенту и какая вообще нагрузка на нас идет. Поэтому стоит собирать RPS, тайминги и пятисотки.
Как мерить RPS, понятно из названия. Стоит отметить, что хорошо смотреть как общий RPS по приложению, так и по отдельным методам API. А вот с двумя остальными — с таймингами и пятисотками — все не так понятно. В каждый момент времени может быть много запросов и, соответственно, много времен ответов. Всю эту информацию нужно агрегировать. Для этого хорошо подходят перцентили. Этот термин пришел к нам из статистики.
Чтобы рассказать, что это такое, на слайде есть нижний график, на нем выделена точка в 400 мс. Это график 99 перцентиля какого-то метода из нашего API. Что значат эти 400 мс? Что в этот момент 99% запросов отрабатывали не хуже 400 мс.
Остались пятисотки. Не стоит мерить просто количество пятисоток, потому что не будет понятен масштаб. Стоит мерить долю или процент. Но собирать можно не только пятисотые коды ответа, но и любые другие коды, которые вам могут быть интересны.
Как мы собираем RPS, тайминги и пятисотки? Когда запрос оказался у нас в инфраструктуру, он попадает на L7 balancer. А дальше он не сразу попадает в приложение, перед этим есть nginx.
А вот уже из nginx он попадает в приложение. У nginx есть access.log, в который можно собирать всю необходимую информацию. Это коды ответа, время ответа и сам запрос.
Часто, когда возникают проблемы с временем ответа или пятисотки, стоит посмотреть, что в это время было с хранилищем.
У нас PostgreSQL, поэтому мы именно его мониторим и смотрим. Мы строим все эти графики не сами — они нам предоставляются облаком, в котором развернута наша база. Что у нас есть? Количество запросов, транзакций, лаг репликации, среднее время транзакции и так далее. На самом деле на этих графиках представлен факап, который у нас произошел.
Вообще-то мы работаем с реальным процессом, и он нам тоже диктует, на что нам нужно посмотреть. Регистрацию нежелательных событий мы уже рассматривали, для этого хорошо подходит метод Monitoring, он был ранее.
Осталась статистика по хранилищу. Хранилище вообще может многое рассказать о состоянии нашей системы. Можно считать показатели: как, например, количество заказов за день, так и просто попадание в интервал доставки. Можно искать противоречия статусной модели. Так мы отслеживаем чеки, с которыми возникли проблемы.
Но далеко не всегда на такие мониторинги должна реагировать разработка. Очень часто на них вначале нужна реакция бизнеса. Вообще задача получения статистики по хранилищу выходит однотипной. Нужно сходить в базу, рассчитать статистику, а результат записать в key-value-лог. Поэтому мы сделали обертку для таких задач.
Сложили в базу такую тройку: уникальный ключ для метрики, сам запрос, в котором можно эту метрику посчитать, и Cron-выражение, когда считать. То есть в базе получилась тройка: ключ — запрос — cron expression. А над всей этой тройкой сделали Cron-задачу, которая достает ее из хранилища и добавляет к общему пулу Cron-задач. Дальше эта задача выполняется.
Итого, что мы получаем?