что такое delivery services в информатике
Delivery Manager — новая роль в мире Agile
До конца года осталось уже почти всего ничего, но всё же несколько новинок в курсах у нас будет. Один из таких новый курсов — «Agile Delivery Manager», который создала Марина Арефьева. По традиции подготовили для вас открытые уроки и интересные материалы. Сегодня познакомимся о виденье, что же такое Delivert Manager и с чем его едят.
Рич Льюис (Rich Lewis) — лучший, с кем я когда-либо работал. Когда я только встретил его, он был бизнес аналитиком и скрам-мастером небольшой команды. Он справлялся со своей работой, но явно был способен на большее. Я предложил ему должность Delivery Manager в программе, которой занимался в то время.
О роли Delivery Manager мы говорим не часто. Конечно, это не часть “семьи” Agile, где доминирует терминология Scrum. Владелец Продукта; Скрам-мастер; Все остальные с ярлыком “Разработчик”. Вот, пожалуй, и все.
Тем не менее, название должности — Delivery Manager, существует. Например, в The Government Digital Service (GDS) в Великобритании и все большем количестве компаний в США.
Зачем нужен Delivery Manager
Марти Каган (Marty Cagan) заметил тенденцию в США от Менеджера Проекта (Project Manager, кратко — PM) к Delivery Manager. Марти нравится этот тренд и новая роль по трем причинам:
Тем не менее, я назвал Рича Delivery Manager, не потому что мне не нравится термин “менеджер проектов”. Я не вижу особого конфликта между проектными менеджерами и Agile в целом/Agile-ролями. Также я не вижу особого смысла в ребрендинге менеджеров проектов. Я просто хочу показать людям в чем смысл Delivery Manager.
Чем занимается Delivery Manager
Если загуглить “Delivery Manager”, не стоит надеяться на много результатов. (На момент написания этой статьи в 2015 году.) Одним из первых будет материал британского Government Digital Service (GDS). В нем много интересного. Например, Марк Стэнли (Mark Stanley) описывает День из жизни Delivery Manager в GDS. Он пишет:
Delivery Manager защищает время команды, чтобы обеспечить непрерывную производительность. Время команды — драгоценное время.
В GDS также есть описание роли Delivery Manager. Основные обязанности в этой роли следующие:
Programme Manager и Delivery Manager
У меня была определенная потребность, когда я пригласил Рича на роль Delivery Manager. Суть в следующем:
Мои отношения с Ричем можно сравнить с отношениями Главного Исполнительного Директора (Chief Executive Officer, кратко — CEO) и Главного Операционного Директора (Chief Operating Officer, кратко — COO). Как CEO, я был внешним лицом команды. Во время удаленной работы я обсуждал с удаленными старшими стейкхолдерами стратегию, чтобы убедиться в досягаемости компенсаций, адекватности приоритетов. Как COO, работа Рича была направлена внутрь команды. Он помогал ей двигаться дальше. Я проверял корректность направления. Вместе мы делали владельцев продукта счастливыми.
Как всегда ждём ваши вопросы и комментарии, которые можно оставить тут или написать их напрямую Марине на открытом уроке.
Роль Service Delivery Manager (SDM) в Канбан-методе: как нанимать SDM
Меня часто спрашивают о роли Service Delivery Manager (SDM) в Канбан. Кто должен играть эту роль? Как можно ввести эту роль в организации? Где найти правильных людей на эту роль?
Для понимания, SDM – термин, который мы используем в Канбан-методе для общего обозначения широкого круга менеджеров, отвечающих за некие сервисы, производственные линии или проекты. В круг ответственности SDM входит управление и улучшение сервиса с точки зрения удовлетворенности его клиентов.
Существует большое количество профессиональных сервисов во многих компаниях и отраслях. Вследствие чего под ролью SDM понимаются совершенно разные виды и объемы работ, что проявляется в разнообразных обязанностях, навыках, уровнях иерархии и оплаты труда. Но ответственность SDM за некие сервисы является общей характеристикой во всем многообразии трактовок. Таким образом, сложился паттерн. И мы используем термин SDM, в качестве наименования такого паттерна.
Высоки шансы того, что подходящий на роль SDM человек уже работает в вашей компании. Возможно, вам понадобится признать эту ответственность неформально или в официальной форме, повысить его, изменить название его должности или нанять на эту позицию человека извне. В зависимости от организационной культуры и истории вашей компании эти опции могут проявиться в разных пропорциях.
Далее вы найдете руководство по основным шагам поиска правильных кандидатов на такую роль.
Не существует стандартного профиля вакансии, всегда нужно учитывать специфику работы
Профиль вакансии service delivery manager’а (SDM) будет сильно зависеть от контекста того, что поставляет тот или иной сервис. Рассмотрим на следующих примерах:
Таким образом, большая часть профиля вакансии SDM будет определяться природой самого сервиса. Соответствие специфике сервиса всегда будет являться ключевым условием выбора.
Лидерские навыки
Следующий важный фильтр для подбора – лидерские навыки. Почему вам нужен SDM? Возможно, потому что вам нужен кто-то, способный взять ответственность за сервис (ML2), сделать его лучше, даже еще лучше (ML3) и поддерживать развитие в таком ключе в течение длительного времени (ML4).
(Что означают эти сокращения ML2, ML3 и ML4? Это маркеры уровней зрелости, используемые в Модели зрелости Канбан (KMM). KMM определяет уровни зрелости таким образом, что организация на каждом уровне могла ответить вызовам бизнес-среды более высокого порядка, чем организации на менее высоких уровнях зрелости. KMM также предлагает дорожную карту повышения текущего уровня зрелости организации. Как это использовать в рамках Канбан-метода? Если коротко, то когда мы проектируем Канбан-систему внутри бизнеса, такая система хорошо покажет уровень зрелости самого бизнеса)
Итак, зрелость лидеров является ограничивающим фактором организационной зрелости. Вам понадобятся альтруистические качества, чтобы создать коллаборацию на протяжении всего потока работ, достичь единства понимания предназначения (Einheit) и принять ответственные решения в точках обязательств сервиса. Вы не захотите нанимать индивидуалиста первого уровня зрелости (ML1) или трайбалиста (лидера племени) второго уровня зрелости (ML2), чтобы такой кандидат не стал препятствием на пути к зрелости более высокого уровня.
Модель зрелости Канбан как руководство к действию
Модель зрелости Канбан (КММ) предоставляет определенный набор ориентиров и фильтров принятия решений. Далее приведены мои инструкции в очень краткой форме по каждому уровню.
Роль SDM не подходит к ML0 или ML1. Если Вам необходимо провести “цифровую трансформацию” на ML0 или ML1, позаботьтесь о том, чтобы случайно не уволить или принудительно сменить профессиональную идеинтичность тех людей, которые в дальнейшем понадобятся Вам в роли SDM.
Роль SDM появляется со второго уровня зрелости и выше.
Для ML2: SDM должен быть способен брать на себя ответственность за сервис, определить сервис, его входы и выходы в терминах клиента, преодолевать закостенелость оргструктуры, инерцию инструментов командного уровня, относящихся к ML1. Это то, что требуется от кандидата, способен ли он выполнить такую работу? Вы не сможете описать это прямо в профиле вакансии, но вам потребуется определенная тактика проведения собеседования, чтобы выявить степень соответствия кандидата.
Для ML3: обратите внимание на два больших способа проверки. Первый – переговоры по вопросу точки обязательств – насколько хорошо кандидаты общаются с клиентами? Второй – управление рисками и задержками поставки после принятия обязательств. Может ли ваш кандидат справиться с этим?
Для ML4: Вам понадобятся организационные петли обратной связи, соединяющие бизнес-результаты и операционные решения. Что потребует создания некоего социального полотна для донесения информации и некоторой степени математической утонченности. Люди по своей природе склонны только к одной из этих двух способностей. Узнайте, кого вы нанимаете
Знакомство с Content Delivery Network
Содержимое: что такое CDN? История возникновения. Зачем она нужна? Кому она нужна, а кому нет? Порог вхождения, стоимость, издержки. Основные технологии.
CDN — сокращение от content delivery network, то есть “сеть доставки контента”. Чаще всего это множество серверов с специализированным ПО, которые ускоряют доставку (“отдачу”) контента конечному пользователю. Сервера расположены по всему миру таким образом, чтобы время ответа посетителям сайта было минимальным. Под “контентом” чаще всего подразумевают видео и статические элементы веб-сайтов (не требующие выполнения кода на сервере или запросов в базу данных, такие как css/js), но к “контенту” относятся и совсем неожиданные вещи — например, игры в Стиме (использует CDN для отдачи игр), обновления для операционных систем и т.д.
Немного истории
Резкий рост Интернета в середине 90-х привёл к ситуации, что сервера тех лет не могли в одиночку выдержать нагрузку (много ли может отдать могучий двухпроцессорный сервер на базе Pentium Pro на частоте в 266 МГц с 128 мегабайтами памяти?). Лимит производительности серверов и потребность во всё большей и большей производительности породила ныне забытые слова: “ферма серверов”, “иерархическое кеширование”… Айтишный новояз удивительно чувствителен к возрасту — и слова вроде “servers farm” или “information superhighway” сейчас ассоциируются с тёплыми ламповыми CRT-мониторами, а не с прогрессом. В ходе разработки и внедрения разных решений была замечена одна важная особенность: есть два типа контента — статический и динамический.
Динамический контент формируется сервером в момент получения запроса сервером, чаще всего при активном участии базы данных. Если на странице снизу надпись “page was generated in 0.333 seconds” — это как раз пример динамического контента.
Статический контент на сервере находится в готовом виде — кто бы не прислал запрос, сервер будет отдавать одно и то же (с поправкой на возможные ACL). Важно, что содержимое при этом не меняется от запроса к запросу.
Статический и динамический контенты создают разный тип нагрузки на сервер. Когда раздаётся “динамика”, то важны процессор, IO (для базы данных) и сколько-то памяти. Когда раздаётся статика, процессор почти не важен, IO важно только для тех файлов, которые не кешированы, а основное требование — это скорость сети. Заставлять раздавать статику серверами, которые раздают динамику, можно, но это совмещение ролей, которое мешает друг другу. Особенно тяжело приходится в тот момент, когда IO от статики начинает мешаться с IO от динамики, а нагрузка на IRQ мешает выполнять скрипты динамики.
Ещё более важной деталью является то, что “динамический” обычно означает наличие “состояния” (сессии и связанных с ним данных), а статика — нет. Статику можно масштабировать горизонтально без сложных двухсторонних синхронизаций с центральным сервером. В случае с динамикой так не получится — нужна либо общая база данных, либо методы синхронизации и блокировок.
Средние и крупные компании начали раздавать статику и динамику с разных серверов, расположенных в разных местах планеты, уменьшая нагрузку на сайты с динамикой за счёт выноса с них статики на легко масштабируемые сервера. После чего сделать шаг до “аутсорса” раздачи статики было просто, и начали появляться компании, которые сделали раздачу статики основой (или хотя бы крупной составляющей) своего бизнеса.
О главном
10мс задержка), это не существенно. Но если речь про расстояния в континенты — то тут задержка в сотни миллисекунд (до 500-600!) начинает уже играть радикальную роль. А если же контент отдаётся с сервера, который в нескольких километрах от пользователя, то случается чудо! Австралия видит данные с сайта из США в единицы милисекунд, Китай из сайта из России, Франция с сайта из Бразилии. Без участия океанических кабелей.
Работает это и на меньшем масштабе: Например, Яндекс при помощи CDN в свое время знатно ускорил работу почты в регионах России, которым до Москвы по оптике топать и топать.
Ускорение доставки контента стало главной киллер-фичей CDN, а всё остальное (снижение нагрузки, её балансировка и т.д.) — стало второстепенным. Важным, но не критическим. В конце-концов, любую нагрузку можно завалить деньгами. Но никакими деньгами нельзя сделать так, чтобы без локальных точек присутствия сигнал из Перми доходил до Сан-Франциско за десятки миллисекунд.
При том, что экономия не является киллер-фичей, она тоже важна. CDN в некоторых ситуациях позволяет ощутимо экономить на трафике. Передать на другой континент файлы один раз, держать их там на локальном сервере и раздать через локальные линки дешевле, чем гонять тот же трафик десять тысяч раз через транс-атлантику. Чаще всего об экономии начинают думать в тот момент, когда это становится критичным (видеохостинги в первую очередь).
Однако, сервера по всему миру, система синхронизации контента и направления клиентов к ближайшим серверам и т.д. — всё это не бесплатно. Чаще всего CDN просят дополнительные деньги по сравнению с обычным трафиком аплинков, хотя для некоторых регионов может оказаться, что трафик CDN выгоднее, чем трафик аплинка (но это, скорее, говорит о том, что интернет в регионе не ахти).
Как это работает на практике?
Со стороны посетителя сайта: он заходит на сайт example.com, где ему отдают html-страницу. В этой html-странице все css, js, картинки и видео — указывают на сайт cdn.example.com — контент грузится оттуда. Когда браузер клиента обращается этот адрес, то благодаря магии BGP его запрос отправляется на ближайший узел присутствия. Сама магия BGP состоит в том, что провайдеру посетителя на IP-сеть, в которой находится cdn.example.com, присылается несколько анонсов от разных сетей (в которых есть точка присутствия), а маршрутизатор провайдера из них выбирает самый близкий. В результате, запрос уходит на ближайший сервер, который отвечает на него, и ответ уходит аналогично, тоже по короткому маршруту.
Кстати, она может быть тоже статической. По такому принципу работают, например, страницы на github.io — это чистый CDN, в нём всё раздаётся статикой.
Кому нужен CDN?
Тем, кому важно отдать статику быстро множеству посетителей, которые находятся далеко от серверов компании (ситуация ещё острее для компаний, у которых посетители раскиданы по большой территории, то есть даже перенос серверов “поближе” смысла не имеет — всё равно большинство окажется “далеко”).
Тем, у кого очень большой объём файлов — и стоимость трафика CDN оказывается ниже стоимости трафика, уходящего к аплинкам (у крупных сайтов обычно трафик стоит разных денег — локальный дешевле, “глобальный” дороже).
При определённой полосе, вынос статики на CDN оказывается выгоднее, чем апгрейд сетевого оборудования. Обычно статика занимает значительную часть полосы, и вместо апгрейда с 1G до 10G, или с 10G до 40G, куда дешевле выкинуть 80% трафика на CDN и оставаться на разумных по цене серверах.
Различия
Если с CDN всё понятно, то как насчёт их поставщиков? Компаний много, они различаются ценой, услугами и качеством.
Вот основные факторы, которые надо определить для себя при выборе поставщика:
1. Количество точек присутствия (Point of Presence)
Чем больше точек, тем лучше, однако… Oднако, зачем вам точки присутствия в Китае, если сайт русскоязычный? А количество точек присутствия в Австралии при выходе на американский рынок… При сравнении CDN следует учитывать число точек присутствия в интересующих странах и регионах. Просто заверений о большом числе точек присутствия и хорошей связности не достаточно — для информированного выбора нужно видеть список точек присутствия и сопоставлять их с потенциальной аудиторией сайта.
Сами точки присутствия так же не равнозначны — связность и пиринговые соглашения с локальными провайдерами очень важны. К сожалению, “иногородцу” оценить связность довольно сложно (нужно понимать расстановку сил на локальном провайдерском рынке), но, сравнивая предложения стоит уточнить о списке пиров каждого из кандидатов в самых важных точках присутствия.
3. SLA
Да, да, легендарный и необъятный Service Level Agreement. Перед тем, как радоваться длинной чреде девяток, уточните — это SLA для CDN “вообще” или для всех точек присутствия? Если в самой важной для вас локации ломается сервер и контент отдают “из соседней страны” это будет засчитываться за даунтайм по SLA? Ну и, основное, чем грозит несоблюдение SLA поставщику? Вам вернут копеечку от месячного платежа, или там есть солидные штрафные санкции?
Кстати, хоть продающий менеджер и будет сопротивляться, будет здорово, если вам покажут статистику отказов за предшествующее время. Отказы будут, и они бывают у всех (подсказка: если вам рассказывают про то, что у кого-то никогда не было аварий — либо это очень молодые, либо очень наглые) — весь вопрос в их длительности и частоте.
Очень важно обратить внимание на поддержку нужны протоколов и файлов. Узнайте, поддерживает ли выбранный вами провайдер потоковое воспроизведение флеш- и медиафайлов (RTMP, RTSP), если вы планируете доставлять именно такой контент.
Возможно, провайдер очень хорош во всем остальном, но, если он не поддерживает нужные вам технологии, вам это вряд ли понравится.
5. Технические нюансы
Технология переадресации: Это либо эникаст на уровне DNS, либо переадресация через редиректы. Эникаст, по понятным причинам, работает быстрее.
Аккуратность переадресации: К сожалению, этот показатель сам поставщик объективно оценить не сможет, хотя как раз этот показатель очень важен — какая часть целевой аудитории попадает на ближайший сервер. Часто говорят про ожидаемую задержку (так как фактическое расстояние никого не волнует, а всех волнует время прохождения пакетов — например, бывает так, что стык между двумя сетями перегружен и пакеты ходят медленно, в этой ситуации лучше сходить чуть дальше, но быстрее).
6. Аккаунтинг
Как именно поставщик берёт деньги? За мегабайты или за мегабиты в секунду? Есть ли минимальный коммит (“если раздалось меньше предусмотренного договором доплатить до минимума”), что происходит при оверкоммите (превышении лимита) — отключают/берут больше денег? Есть ли минимальный срок контракта? Есть ли вообще контракт (заключающийся между владельцем сайта и поставщиком CDN), или же это автоматический self-serving on-demand provisioning, то есть “закинул денег на счёт и получил панель управления”?
Начиная с каких объёмов имеет смысл думать о CDN?
Повторим мысль: если нужно быстро обслужить клиентов, то объём трафика уже не важен — важны точки присутствия поближе к целевой аудитории.
Если же значительной потребности в низкой latency нет, а CDN используется для облегчения нагрузки на сервера, то осмысленный объём трафика, с которым стоит начинать думать о CDN — это несколько терабайт в месяц.
Главный вопрос: сколько это стоит?
Краткий обзор рынка
Все компании делятся на две категории — работающие по существующим публичным тарифам и работающие на основании договорённостей. Вторые компании крайне сложно сравнивать, так как условия в них могут сильно различаться. Однако, “приватный” не означает “маленький” — у приватных компаний чаще всего очень крупные клиенты с огромными объёмами в сотни терабит (полосы), а на “мелюзгу” с десятком гигабит они не заморачиваются.
Вот список популярных CDN (чтобы никого не обижать, список отсортирован в случайном порядке):
Статья написана при поддержке наших коллег из компании UCDN, которые слишком скромны, чтобы включать себя в список выше.
Delivery Service
Delivery Service — это приложение, которое позволяет составить оптимальный маршрут для прохождения заданных точек с учетом их географического расположения и желаемого времени их посещения. Приложение может быть полезно курьерским и службам и им подобным.
Интерфейс
В левой панели задаются адреса мест доставки с желаемыми временными рамками их посещения, а также различные параметры для построения самогó маршрута. Левую панель можно скрыть, нажав на кнопку в форме стрелки, указывающей влево.
Основное пространство интерфейса занимает карта. Во время настройки маршрута на ней показываются выбранные контрольные точки, а после построения — весь маршрут. Возможные слои для картоосновы — это Gurtam Maps и OpenStreetMap (переключатель слоев находится в правом верхнем углу). Карту можно перетягивать при помощи левой кнопки мыши, а также масштабировать колесом прокрутки либо при помощи кнопок +/– в левом верхнем углу карты.
Нижняя панель полезна после построения маршрута. Она содержит подробные сведения по нему, а также кнопки для распечатки и сохранения маршрута.
Добавление адресов
Прежде чем добавить адрес, вверху левой панели необходимо указать источник адресов и маршрутизации (Gurtam/Yandex). Таким образом, определение адреса, а также расчет маршрута будет производиться при помощи указанного картографического сервиса.
Адреса можно указывать вручную с клавиатуры либо при помощи двойного клика по карте. Также в качестве адресов могут использоваться геозоны, созданные в основном интерфейсе системы мониторинга. Добавленные адреса обозначаются синим маркером на карте.
Для каждой точки можно указать желаемый день и интервал доставки, а также предполагаемую продолжительность нахождения в самóй точке. Эти данные важны для последующего построения маршрута и его оптимизации. Точки можно переименовывать.
Максимальное количество адресов, которое может быть добавлено, составляет 50. Адреса можно менять местами, перетаскивая их вверх и вниз. Для удаления адреса из списка нажмите крестик напротив него.
Параметры построения маршрута
Укажите предполагаемую среднюю скорость передвижения, что поможет программе произвести наиболее оптимальные расчеты.
Флаги “Закрепить первый адрес” и “Закрепить последний адрес” выставляются в том случае, если та или иная точка должна быть обязательно первой/последней в списке для посещения. Например, мы точно знаем, что отправным пунктом для курьера будет офис, затем он посетит несколько адресов доставки, и в итоге должен будет поставить автомобиль на стоянку. В таком случае мы вводим адрес офиса первым, а стоянки — последним, соответственно, и закрепляем данные точки. При необходимости можно закрепить только первый или только последний адрес.
Если отмечен флаг “Уложиться в расписание”, то при расчетах будут учитываться такие факторы как интервал доставки, а также длительность нахождения в месте доставки. Если не удается проложить маршрут согласно заданным параметрам, рекомендуется снять этот флаг и попробовать еще раз.
Флаг “Привязка к дорогам” целесообразно выставлять, если доставка происходит на автомобиле. В таком случае при расчете будет учитываться наличие дорог, направление движения по дорогам и т.п. Если флаг “Привязка к дорогам” не выставлен, то расстояние между точками рассчитывается по прямой.
После того как все параметры указаны, нажмите “Рассчитать”. Приложение произведет расчет на основании введенных данных.
Действия с готовым маршрутом
После расчета маршрута он отображается на карте, а в нижней панели появляется детализация — таблица с порядком и временем посещения точек, а также расстояние до каждой точки от предыдущей. Если нажать на адрес в данной таблице, то карта будет отцентрирована на соответствующей точке.
Эту таблицу можно распечатать, а сам маршрут сохранить в Wialon для последующего использования.
В любой момент можно добавить и убрать точки, изменить параметры для построения маршрута и сделать повторный расчет с учетом новых данных.
Copyright © 2002–2020 Gurtam 
delivery service
Смотреть что такое «delivery service» в других словарях:
delivery service — The delivery of small packages by messenger or delivery boy, which, under some circumstances, puts the proprietor in a classification of a common carrier. Portland v Western Union Tel. Co. 75 Or 37, 146 P 148 … Ballentine’s law dictionary
delivery service — служба доставки guard service служба охраны hauling service служба тяги term of service срок службы post service почтовая служба train service служба движения … English-Russian travelling dictionary
delivery service — /dɪ lɪv(ə)ri ˌsɜ:vɪs/ noun a transport service organised by a supplier or a shop to take goods to customers … Dictionary of banking and finance
delivery service — /dɪ lɪv(ə)ri ˌsɜ:vɪs/ noun the store will deliver goods to all parts of the town … Marketing dictionary in english
Delivery Service Partner — DSP Versionen (Delivery Service Partner Versionen) sind Software Versionen, die vollständig mit Handbuch und Datenträger ausgeliefert werden. Oft werden die Lizenzen von Microsoft Windows als DSP Version verkauft. Dabei handelt es sich um die… … Deutsch Wikipedia
Kiki’s Delivery Service — This article is about the anime film. For Eiko Kadono s original novel, see Kiki s Delivery Service (novel). Kiki s Delivery Service Theatrical poster … Wikipedia
Kiki’s Delivery Service (novel) — Majo no Takkyūbin Kiki s Delivery Service … Wikipedia
The Kurosagi Corpse Delivery Service — Infobox animanga/Header name = The Kurosagi Corpse Delivery Service caption = English version, Volume 1. ja name = 黒鷺死体宅配便 ja name trans = Kurosagi Shitai Takuhaibin genre = HorrorInfobox animanga/Manga title = author = Eiji Otsuka illustrator =… … Wikipedia
Angel Delivery Service — Infobox Album Name = Angel Delivery Service Type = studio album Artist = Emil Bulls Released = June 4, 2001 Recorded = Heartbeat Studio, Cologne, Germany Dierks Studio, Cologne, Germany Galaxy Studio, Belgium Genre = Nu metal, Rapcore Length = 54 … Wikipedia
city delivery service — Delivery by city carriers of mail addressed to residences and businesses within an area that has a population of at least 2,500 residents or more than 750 possible deliveries. The area must have paved or improved streets; street signs and house… … Glossary of postal terms
Kiki’s Delivery Service — Filmdaten Deutscher Titel: Kikis kleiner Lieferservice Originaltitel: 魔女の宅急便 (Majo no Takkyūbin) Produktionsland: Japan Erscheinungsjahr: 1989 Länge: 103 Minuten Originalsprache … Deutsch Wikipedia