По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Какое будущее ждет нас в контакт центрах с точки зрения кастомер сервис (клиентского сервиса)? Как компании создают новые пространства для коммуникации со своими потребителями? Будем говорить про чат боты - будущее клиентского сервиса.
На цифрах, кейсах, исследованиях, в том числе социальных, постараюсь рассказать о том, почему в контакт центрах будущего, живых операторов будет меньше, а VoIP (классические телефоны) и CTI (интеграция компьютерных приложений и телефонии) отойдет на второй план.
Посмотреть доклад
Чат - боты это определенно хайповая история, несмотря на то, что сам хайп сейчас немного поугас. Компании абсолютно разного уровня внедряют чат - ботов: от больших банков, где чат бот органично вписывается в ИТ экосистему и помогает сократить косты на операторов и снизить их загрузку на рутинные операции до маленьких компаний, e-commerce или туристических фирм, где смысл чат - бота скорее сводится к тому, чтобы показать уровень технологичности на ряду с более "аналоговыми" конкурентами.
Посмотрим на крупных игроков IT рынка, которые уже бороздят просторы ML/AI в поиске способа доставить счастье своим пользователям, среди них как Zero UI решения, которые вовсе не имеют привычного интерфейса, так и уже вполне рабочие чат боты:
Алиса - умный помощник от Яндекс. Это мозги, которые живут почти во многих приложениях Яндекса и в хардварных устройствах. Кстати, по данным Яндекса, в приложении поиска доля голосовых запросов на октябрь 2018 года была 20%.
Помимо пользовательских сценариев, Алиса сможет решать конкретные бизнес задачи по клиентскому обслуживанию клиентов вашего контакт центра, как автоматизированном режиме, так и в режиме диалога с оператором. Это реализуется с помощью платформы Яндекс.Диалоги - легкий способ связать жителя экосистемы Яндекса с вашим бизнесом, так сказать, не отходя от кассы. Кстати, количество активных пользователей алисы в месяц (MAU) 35 млн. - подумайте, сколько из них ваших потенциальных или текущих клиентов.
Про Amazon и их разработки. Вы наверное слышали про виртуальный ассистент Alexa. Внутри алексы используются алгоритмы Amazon Lex
А так как Amazon научился монетизировать свои технологии как никто другой, то они продают Amazon Lex в видео фреймворка (интерфейса) для создания приложений - как голосовых так и текстовых, в которых используются алгоритмы понимания естественных языков (NLU), и распознавания речи ASR. О первых я расскажу подробнее в конце статьи.
Фреймворк, как заявляют ребята с Амазона, в контексте контакт центров классно подходит для рутинных операций - смена пароля, баланс, встреча с представителем компании и некоторые другие.
Бот помощник Олег от банка Тинькоф. Бот помогает управлять кредиткой или дебетовой картой или заказать финансовые документы, снижая нагрузку на живых операторов и помогает закрыть пользовательские сценарии, купить билеты в кино и забронировать столик в ресторане.
Тут можно отметить 2 самых очевидных пункта, которые дает бот:
Ретеншн (вовлеченность) пользователей. Экосистема с элементами фана повышает вовлеченность к бренду и втягивает пользователей в экосистему. Билеты в кино, скидки, столики, переводы, а еще и голосом с ботом, который может ответить что то смешное или даже грубое, что насмешит друзей и спровоцирует цепочку рассылки диалога друзьям. Из этого вытекает следующий пункт:
Виральность - распространяемость контента. На старте бот Тинькоф отвечал пользователям весьма неоднозначно. Например, на старте, попросив "сотку" у банка вы рисковали получить неплохую ответочку:
Этот ответ массово распространился по социальным сетям. Это и есть та самая виральность.
Вообще много мнений и обсуждений, касаемо чат ботов: начиная от того, что рынок еще не готов и сама технология бесполезна, заканчивая тем, что люди не любят общаться с чат ботами. Если два первых барьера мы с вами обсудили, то про второй я хочу поговорить немного подробнее.
Блок про поколение Z - почему он в соц. сетях и не любит голос
Впервые в истории, в 2011 в UK заметили, что объем телефонных звонков упал на 10%. При более детальном анализе было обнаружено, что максимально влияющая на падение показателя когорта пользователей - это люди 16 - 24 лет, которые предпочитают текстовую коммуникацию.
К обеспокоенности провайдеров, масла в огонь подлил государственный медиарегулятор Ofcom (управление по коммуникациям), отчитавшись - 96% британцев в возрасте 16 - 24 используют текстовые сообщения каждый день.
Итак, кто эта группа - 16 -24? Условно говоря, это люди рожденные после 1995 по 2012 года, и поздние Z - рожденные после 2000.
Частично, тенденции к цифровизации и ухода в онлайн начали проявляться и у Миллениалов или, как принято их называть Поколение Y. Это люди рожденные с 1981 и до 1996 года.
Несколько факторов, которые характеризуют поколение Z:
Поколение Z очень целеустремленны. как пишут в исследованиях, это, "most success oriented". Взросление в процессе рецессии, войны, террористических атак, трудные времена на территории РФ. Зачастую, им приходилось наблюдать за борьбой родителей в трудные времена. Масла в огонь подливали миллениалы, полностью зацикленные на карьере.
Настроение на успех на выходе дает следующий пункт, пусть и сомнительный - многозадачность.
Многозадачность. Поколение Z чувствует себя спокойнее, выполняя несколько задач одновременно. Запостить фотографию в инстаграм, написать друзьям, почитать новости на медузе, сделать фильтра в снэпчате, погонять слова в скаенге. Мы не говорим об эффективности подобных активностей (которая по моему мнению, околонулевая), мы говорим про сам посыл.
Тут и возникает важный нюанс - в контексте решения многозадачности, Z, решая свои вопросы с компанией, у которой они берут услугу, предпочтут отправить сообщение в бот в телеграмме или в приложении и ждать ответа, чем висеть на телефоне, холде, ждать ответа оператора и просто говорить голосом.
Но это не главная причина. Важнейшей является то, что поколение Z нативно вросло в digital.
Нативно в digital. Z находятся в цифровом пространстве полностью. Мессаджинг (текстинг), мемы, фотографии, лайки, обсуждения, снэпчаты - среда, в которой они существуют. И в ней, телефонному звонку, да и голосовой коммуникации в целом остается все меньше и меньше места.
Соответственно, Z ожидают, что диджитал будет окружать их везде - решить проблемы с банком, заказать услугу, купить товар или еду, путешествия и прочее. Не давая им возможности обратиться в диджитал, мы рискуем потерять эту аудиторию.
Существует множество других характеристик, которые прямо или косвенно влияют на стремление Z к цифре:
Конфиденциальность - Z очень ценят свою конфиденциальность. Представьте Z, который едет в полном автобусе, звонит в контакт центр, где его просят назвать кодовое слово? Кажется, он будет слегка сконфужен
Z легко принимают новое
Вот такие они, эти ребята в гучи, суприм и кроссовках на высокой платформе. Давайте закрепим и посмотрим, что об этом думают большие компании.
Пруфы того, что это важно
В феврале 2018 года в Токио консалтинговая компания Гартнер отчиталась - к 2020 году 25% всех клиентских итераций будут происходить через VCA (virtual customer assistant), если переводить дословно - виртуальных клиентских помощников, или чат ботов, в контексте моего доклада и контакт - центра.
Джин Альварез, вице - президент в Гартнер отчитался, что более чем половина крупного энтерпрайза уже начали инвестировать и исследовать виртуальных помощников, в разрезе решения стандартных вопросов с последующей эскалацией сложных на агента. Вот цитата Джина (Gene Alvarez):
"As more customers engage on digital channels, VCAs are being implemented for handling customer requests on websites, mobile apps, consumer messaging apps and social networks"
Перевод:
С погружением клиентов в цифровые каналы коммуникации, все больше VCA (виртуальные клиентские помощники) внедряются для обработки клиентских запросов на сайтах, мобильных приложениях, мессенджерах и соц. сетях"
Это важно, так как мы обсудили ранее, для подрастающего платежеспособного поколения Z - цифровые каналы это нативные вещи.
Помимо прочего, важная цифра: организации, использующие VCA, в среднем, смогли сократить количество звонков, операторских чатов и писем на 70% и срезали косты на телефонию в среднем на 33%. В отчете так же было отмечено увеличение общего уровня удовлетворенности клиентов. Я не стану добавлять это в статью, так как Гартнер поленился рассказать, какие метрики для этого они посчитали и как измерили.
Дальше. Ребята из Juniper Research еще в 2017 году говорили, что чат - боты - гейм чейнджер для банков и здравоохранения.
Джунипер прогнозирует, что количество клиентских взаимодействий с чат-ботами в здравоохранении увеличится с 12% до 75% к 2022 году, а в банковском секторе достигнет 90% к этому времени.
Автор исследования Лоурен Фои (Lauren Foye) объясняет:
"We believe that healthcare and banking providers using bots can expect average time savings of just over 4 minutes per enquiry, equating to average cost savings in the range of $0.50-$0.70 per interaction. As Artificial Intelligence advances, reducing reliance on human representatives undoubtedly spells job losses."
Перевод:
Мы считаем, что банки и компании в области здравоохранения, используя чат- боты могут сэкономить более 4 минут на один клиентский запрос. Это примерно 50 - 70 центов за одну итерацию.
4 минуты на обращении что примерно ровняется $0.5 - $0.7. Лоурен пугает нас тем, что развитие AI (искусственного интеллекта) так или иначе приведет к потере работы многими людьми. Спасибо Лоурен, тебя это тоже коснется.
Кстати, про искусственный интеллект. А точнее про одно из его направлений NLP (Natural Language Processing), или говоря по русски, обработку естественного языка.
Про natural language processing (NLP). Обработка естественного языка
Кратко пробежимся по технологии, которая драйвит эту отрасль. NLP - обработка естественного языка. Это направление породила одна проблема: компьютеры прекрасно справляются со структурированными данными, таблицами, приведенными к единообразию датасетами, но мы с вами общаемся не методами структурами, а словами. Тут и появилась идея научить машины понимать живой человеческий язык.
В рамках решения этой задачи, как и в любой другой задаче машинного обучения, принято разбивать задачу на последовательность подзадач. Это называется пайплайн, он же конвейер процессов, которые необходимо выполнить. Давайте попробуем кратко разобраться на примере текста, взятого из википедии про Лондон:
London is the capital and most populous city of England and the United Kingdom. Standing on the River Thames in the south east of the island of Great Britain, London has been a major settlement for two millennia. It was founded by the Romans, who named it Londinium.
Тут есть несколько сегментов полезной информации про Лондон, где он находится и кем основан.
1. Дробим на предложения
Первый этап пайплайна - дробим текст на предложения. Самое простое - по знакам препинания. Но современные алгоритмы используют более хитрые способы. Вот что у нас получилось:
London is the capital and most populous city of England and the United Kingdom.
Standing on the River Thames in the south east of the island of Great Britain, London has been a major settlement for two millennia.
It was founded by the Romans, who named it Londinium.
Три отдельных смысловых блока. Отлично.
2. Токенизация
Оно же выделение слов. Так как мы уже разбили текст на предложения, берем первое и дробим - алгоритм прост - разбиение по пробелам или знакам препинания
"London", "is", "the", "capital", "and", "most", "populous", "city", "of", "England", "and", "the", "United", "Kingdom", "."
3. Части речи
Теперь смотрим на каждое слово отдельно и понимаем, что это - существительное, глагол, прилагательное или еще что то. Готовые фреймоврки обучены на на миллионах слов и учитывают слова стоящие рядом, для повышения точности определения.
Получаем:
London - имя собственное
is - глагол
the - артикль
capital - существительное
and - союз
most - наречие
populous - прилагательное
4. Лемматизация
Лемматизация (англ. lemmatization) - приведение словоформы к ее первоначальной словарной форме (лемме). По факту, это отсечение окончаний и использование основой формы.
Например, в русском языке словарной формой считается:
существительные - именительный падеж, единственное число (руками - рука)
глаголы - инфинитивная форма (искали - искать)
прилагательные - единственное число, именительный падеж, мужской род (телекоммуникационными - телекоммуникационный)
В NLP лемматизация обычно выполняется простым поиском форм в таблице. Вот что мы получаем:
London - имя собственное (уже начальная форма)
is - глагол (превращается в be)
the - артикль (уже начальная форма)
capital - существительное (уже начальная форма)
and - союз (уже начальная форма)
most - наречие (уже начальная форма)
populous - прилагательное (уже начальная форма)
5. Стоп слова
В нашем примере мы рассматриваем англоязычный фрагмент текста. Поэтому, из него нужно убрать слова, которые создают избыточный шум - артикли, например "and", "the", "a". Обычно, это делается по готовым таблицам.
Снова смотрим на наше предложение:
London - имя собственное (уже начальная форма)
is - глагол (превращается в be)
the - артикль (уже начальная форма)
capital - существительное (уже начальная форма)
and - союз (уже начальная форма)
most - наречие (уже начальная форма)
populous - прилагательное (уже начальная форма)
6. Парсинг зависимостей
Следующим шагом нам важно понять взаимосвязь слов в предложении. Нужно понять, кто является родителем для каждого из токенов (слов) и установить тип взаимосвязи: субъект предложения, свойство, логическая связь, определение и так далее.
В результате мы получаем уже почти готовое дерево связей. Логическим продолжением этого шага является группировка токенов по признакам взаимосвязи.
Было:
London - имя собственное (уже начальная форма)
is - глагол (превращается в be)
the - артикль (уже начальная форма)
capital - существительное (уже начальная форма)
and - союз (уже начальная форма)
most - наречие (уже начальная форма)
populous - прилагательное (уже начальная форма)
Стало:
London
is
the capital
and
most populous city
7. Распознавание именованных сущностей (Named Entity Recognition, NER)
Двигаясь по пайплайну мы подходим к самому интересному, на мой взгляд, шагу - распознавание смысла слов. Вы уже заметили, что в нашем предложении встречаются географические сущности, такие как "London", "England" и "United Kingdom". На этом этапе пайплайна мы пониманием что это географический объект и определяем это, наполняя наш текст смыслом. NER алгоритмы хорошо работают с такими объектами как:
имена людей;
названия компаний;
географические обозначения (и физические, и политические);
продукты;
даты и время;
денежные суммы;
события.
Тут важно отметить, что хорошая NER система это не только словари. Они так же просматривают контекст предложения и окружение каждого конкретного токена. Адекватный NER должен уметь отличить американскую актрису Дакоту Фаннинг от штата Дакота на севере США
8. Разрешение кореференции
Если быть кратким, то это решение вопроса с местоимениями, которые во всем тексте означают тот или иной объект. Вернемся к нашему изначальному тексту, который мы разбивали на предложения
London is the capital and most populous city of England and the United Kingdom. Standing on the River Thames in the south east of the island of Great Britain, London has been a major settlement for two millennia. It was founded by the Romans, who named it Londinium.
Обратите внимание на "It was founded by the Romans, who named it Londinium." Это было основано римлянами. Это? Что это?
Вот и задача для для алгоритмов связать, что Это в данном контексте - это = Лондон.
9. Итог. Полный пайплайн NLP
Итак, подытожим. Чтобы получать смыслы из речи человека текст проходит мощную обработку в конвейере NLP. Помимо прочего, NLP можно юзать и в голосовых технологиях, преобразуя речь в текст в рамках ASR механизмов и снова пропуская через пайплайн NLP.
Суммарно, чтобы читать между строк и получать смысла информация перемалывается через эти 9 шагов (где то их может быть меньше, а где то в другом порядке, например):
Дробим на предложения
Токенизация
Части речи
Лемматизация
Стоп слова
Парсинг зависимостей
Группировка токенов (существительных)
Распознавание именованных сущностей (Named Entity Recognition, NER)
Разрешение кореференции
Кто делает?
Продуктов много. Есть как тривиальные инструменты создания блок - схем (статичных алгоритмов обработки запросов), так и интерфейсы с продвинутым NLP, о котором мы поговорили ранее, есть энтерпрайзные решения, есть и решения для SMB. Не делая рекламы, поговорим про бесплатные решения. Rasa.com
RASA.com
Ребята дают бесплатный фреймворк для быстрого старта. Есть энтерпрайз коммерческие тарифы, которые дадут SLA и не комьюнити бэйзд гарантии. У ребят 0.5 млн загрузок по миру, 3.5 активных участников комьюнити.
Схематично парни из раса.ком обозначили принципы работы их чат бота как на картинке:
Можно попробовать абсолютно бесплатно, дав плечо фреймворку в свои данные.
Итоги
С развитием машинного обучения цифровое будущее становится все ближе и ближе. На руку прогрессу и развитию роботизации в клиентском сервисе играют поколенческие факторы, общие характеристики нового поколения, тренды и даже политическая обстановка. Будьте первыми, будьте актуальными, будьте технологичными и свежими.
Прочитайте материал про реактивное и упреждающее распределение достижимости в сетях.
Есть много случаев, когда более эффективно или в соответствии с конкретными ограничениями политики для плоскости управления изучать информацию о достижимости и топологии с другой плоскости управления, а не с помощью механизмов, описанных до этого момента в этой серии статей. Вот некоторые примеры:
Две организации должны соединить свои сети, но ни одна из них не хочет позволить другой контролировать политику и работу своих плоскостей управления;
Крупная организация состоит из множества бизнес-единиц, каждая из которых имеет возможность управлять собственной внутренней сетью в зависимости от местных условий и требований приложений.
Организация должна каким-то образом позволить двум плоскостям управления взаимодействовать при переходе от одной к другой.
Причины, по которым одна плоскость управления может получать информацию о доступности от другой, почти безграничны. Учитывая это требование, многие сетевые устройства позволяют операторам перераспределять информацию между плоскостями управления. При перераспределении достижимости возникают две проблемы, связанные с плоскостью управления: как обрабатывать метрики и как предотвращать петли маршрутизации.
Примечание. Перераспределение можно рассматривать как экспорт маршрутов из одного протокола в другой. На самом деле импорт/экспорт и перераспределение часто используются для обозначения одного и того же, либо разными поставщиками, либо даже в разных ситуациях одним и тем же поставщиком.
Перераспределение и метрики
Взаимосвязь между свойствами связи, политиками и метриками определяются каждым протоколом плоскости управления независимо от других протоколов. Фактически, более описательная или более полезная метрическая система - это то, что иногда привлекает операторов к определенному протоколу плоскости управления. На рисунке 12 показаны два участка сети, в которых работают две разные управляющие плоскости, каждая из которых использует свой метод расчета метрик связей.
Протоколы X и Y в этой сети были настроены с использованием двух разных систем для назначения показателей. При развертывании протокола X администратор разделил 1000 на скорость соединения в гигабитах. При развертывании протокола Y администратор создал "таблицу показателей" на основе наилучшего предположения о каналах с самой высокой и самой низкой скоростью, которые они могут иметь в течение следующих 10-15 лет, и назначил метрики для различных скоростей каналов в этой таблице. Результат, как показывает рисунок, несовместимые показатели:
10G каналы в протоколе X имеют метрику 100, в то время как в протоколе Y они имеют метрику 20.
100G-каналы как в протоколе X, так и в протоколе Y имеют метрику 10.
Предполагая, что более низкая метрика предпочтительна, если метрики добавлены, канал [B, C, F] будет считаться более желательным путем, чем канал [B, D, G]. Однако, если учитывать пропускную способность, оба канала будут считаться одинаково желательными.
Если между этими двумя протоколами настроено перераспределение, как следует обрабатывать эти метрики? Есть три общих решения этой проблемы.
Администратор может назначить метрику в каждой точке перераспределения, которая передается как часть внутренней метрики протокола. Например, администратор может назначить метрику 5 для пункта назначения E на маршрутизаторе C при перераспределении из протокола X в Y. Этот пункт назначения, E, вводится в протокол Y с метрикой 5 маршрутизатором C. На маршрутизаторе F метрика для E будет от 25 для C. В G стоимость достижения E будет 35 по пути [F, C]. Желательность использования любой конкретной точки выхода для любого конкретного пункта назначения выбирается оператором при назначении этих ручных метрик.
Метрика "другого" протокола может быть принята как часть внутренней метрики протокола. Это не работает в случае, когда один протокол имеет более широкий диапазон доступных метрик, чем другой. Например, если протокол Y имеет максимальную метрику 63, метрики 10G из протокола X будут "выше максимума"; ситуация, которая вряд ли будет оптимальной. При отсутствии такого ограничения маршрутизатор C внедрит маршрут к E со стоимостью 100 в протокол Y. Стоимость достижения E на маршрутизаторе F составит 110; стоимость в G будет от 130 до [F, C].
Примечание. Здесь вы можете увидеть компромисс между состоянием плоскости управления и оптимальным использованием сети, это еще один пример компромисса сложности при проектировании реальных протоколов. Перенос внешней метрики в отдельное поле добавляет состояние плоскости управления, но позволяет более оптимально управлять трафиком через сеть. Назначение или использование внешней метрики снижает состояние плоскости управления, но за счет возможности оптимизации потока трафика.
Внешняя метрика может быть перенесена в отдельное поле, поэтому каждое сетевое устройство может отдельно определять лучший путь к каждому внешнему адресату. Это третье решение является наиболее широко используемым, поскольку оно обеспечивает наилучшую возможность управления трафиком между двумя сетями. В этом решении C вводит достижимость для E с внешней стоимостью 100. В F есть две метрики в объявлении, описывающие достижимость для E; внутренняя метрика для достижения точки перераспределения (или выхода) - 20, а метрика для достижения точки E во внешней сети - 100. В G внутренняя метрика для достижения точки выхода - 30, а внешняя метрика - 100.
Как реализация будет использовать оба этих показателя? Следует ли протоколу выбирать ближайшую точку выхода или, скорее, самую низкую внутреннюю метрику? Это позволит оптимизировать использование локальной сети и потенциально деоптимизировать использование сетевых ресурсов во внешней сети. Должен ли протокол выбирать точку выхода, ближайшую к внешнему назначению, или, скорее, самую низкую внешнюю метрику? Это позволит оптимизировать сетевые ресурсы во внешней сети, потенциально за счет деоптимизации использования сетевых ресурсов в локальной сети. Или протоколу следует попытаться каким-то образом объединить эти две метрики, чтобы максимально оптимизировать использование ресурсов в обеих сетях?
Некоторые протоколы предпочитают всегда оптимизировать локальные или внешние ресурсы, в то время как другие предоставляют операторам возможность конфигурации. Например, протокол может позволять переносить внешние метрики в виде метрик разных типов, при этом один тип считается большим, чем любая внутренняя метрика (следовательно, сначала предпочтение отдается самой низкой внутренней метрике и использование внешней метрики в качестве средства разрешения конфликтов), а другой тип - это когда внутренние и внешние метрики считаются эквивалентными (следовательно, добавляются внутренние и внешние метрики для принятия решения о пути).
Перераспределение и петли маршрутизации
В приведенном выше обсуждении вы могли заметить, что места назначения, перераспределенные с одного протокола на другой, всегда выглядят так, как будто они подключены к перераспределяющему маршрутизатору. По сути, перераспределение действует как форма резюмирования (что означает, что удаляется информация о топологии, а не информация о достижимости), как описано ранее в этой серии статей. Хотя этот момент не является критическим для показателей перераспределения, важно учитывать способность плоскости управления выбирать оптимальный путь. В некоторых конкретных случаях деоптимизация может привести к тому, что плоскость управления не сможет выбрать пути без петель. Рисунок 13 демонстрирует это.
Чтобы построить петлю маршрутизации в этой сети:
Маршрут к хосту A перераспределяется от протокола X к Y с вручную настроенной метрикой 1.
Маршрутизатор E предпочитает маршрут через C с общей метрикой (внутренней и внешней) 2.
Маршрутизатор D предпочитает маршрут через E с общей метрикой 3.
Маршрутизатор D перераспределяет маршрут к хосту A в протокол X с существующей метрикой 3.
Маршрутизатор B имеет два маршрута к A: один со стоимостью 10 (напрямую) и один с метрикой от 4 до D.
Маршрутизатор B выбирает путь через D, создавая петлю маршрутизации.
И так далее (цикл будет продолжаться, пока каждый протокол не достигнет своей максимальной метрики).
Этот пример немного растянут для создания цикла маршрутизации в тривиальной сети, но все циклы маршрутизации, вызванные перераспределением, схожи по своей структуре. В этом примере важно, что была потеряна не только топологическая информация (маршрут к A был суммирован, что, с точки зрения E, было непосредственно связано с C), но и метрическая информация (исходный маршрут со стоимостью 11 перераспределяется в протокол Y со стоимостью 1 в C). Существует ряд общих механизмов, используемых для предотвращения формирования этой петли маршрутизации.
Протокол маршрутизации всегда может предпочесть внутренние маршруты внешним. В этом случае, если B всегда предпочитает внутренний маршрут A внешнему пути через D, петля маршрутизации не образуется. Многие протоколы маршрутизации будут использовать предпочтение упорядочивания при установке маршрутов в локальную таблицу маршрутизации (или базу информации о маршрутизации, RIB), чтобы всегда отдавать предпочтение внутренним маршрутам над внешними. Причина этого предпочтения состоит в том, чтобы предотвратить образование петель маршрутизации этого типа.
Фильтры можно настроить так, чтобы отдельные пункты назначения не перераспределялись дважды. В этой сети маршрутизатор D может быть настроен для предотвращения перераспределения любого внешнего маршрута, полученного в протоколе Y, в протокол X. В ситуации, когда есть только два протокола (или сети) с перераспределенной между ними информацией плоскости управления, это может быть простым решением. В случаях, когда фильтры необходимо настраивать для каждого пункта назначения, управление фильтрами может стать трудоемким. Ошибки в настройке этих фильтров могут либо привести к тому, что некоторые пункты назначения станут недоступными (маршрутизация черных дыр), либо приведет к образованию петли, потенциально вызывающей сбой в плоскости управления.
Маршруты могут быть помечены при перераспределении, а затем отфильтрованы на основе этих тегов в других точках перераспределения. Например, когда маршрут к A перераспределяется в протокол Y в C, маршрут может быть административно помечен некоторым номером, например, 100, чтобы маршрут можно было легко идентифицировать. На маршрутизаторе D можно настроить фильтр для блокировки любого маршрута, помеченного тегом 100, предотвращая образование петли маршрутизации. Многие протоколы позволяют маршруту нести административный тег (иногда называемый сообществом или другим подобным именем), а затем фильтровать маршруты на основе этого тега.
Забыли рутовый пароль для входа в Ubuntu Linux? Не беда. Сейчас расскажем, как быстро восстановить доступ.
Упомянутый здесь метод работает для сброса пароля Ubuntu в VMware, двойной загрузки или одиночной установки. Все, что вам нужно, это немного терпения и выполнить пару команд. Вы сбросите пароль root в течение пары минут.
Если нужна другая сборка, то мы также рассказывали про восстановление пароля в CentOS и Debian
Сброс пароля Ubuntu из режима восстановления (recovery mode)
Шаг 1. Загрузитесь в режиме восстановления
Включите компьютер. Зайдите в меню Grub. Как правило, оно появляется автоматически, а если нет, то удерживайте клавишу Shift, пока не появится меню загрузки.
Если вы используете Oracle VirtualBox или VMWare, вы должны удерживать клавишу Shift при появлении логотипа Oracle или VMWare.
В меню grub выберите «Дополнительные параметры для Ubuntu» (Advanced Options for Ubuntu) :
Здесь вы увидите возможность перейти в режим восстановления (recovery mode) :
Выбрав его, вы сначала увидите темный экран и после непродолжительной загрузки окажитесь в меню восстановления.
Шаг 2. Переходим в командный интерпретатор суперпользователя
Теперь вам будут представлены различные варианты режима восстановления. Здесь вам нужно выбрать «Root Drop to root shell prompt» («Перейти в командный интерпретатор суперпользователя» по-русски) . Просто нажмите клавишу Enter, чтобы выбрать эту опцию.
После этого у вас внизу появится командная строка.
Шаг 3: Перемонтировать рут с правами записи
У вас должен быть доступ на запись к корневому разделу. По умолчанию он имеет доступ только для чтения. Используйте команду ниже, чтобы перемонтировать ее с правами записи:
mount -rw -o remount /
Шаг 4: Сбросьте имя пользователя или пароль
Здесь вам будет представлен root-доступ. Используйте следующую команду, чтобы получить список всех доступных пользователей:
ls /home
Из предыдущей команды выберите пользователя (username), для которого вы хотите сбросить пароль. Теперь используйте следующую команду для сброса пароля для выбранного пользователя (вместо username указываем имя нашего пользователя):
passwd username
У нас запросят новый пароль и подтверждение. Введите новый пароль дважды:
Enter new UNIX password:
Retype new UNIX password:
Готово! Вы только что успешно сбросили пароль. Теперь выйдите из командной строки root:
exit
Когда вы выйдете, вы вернетесь в меню режима восстановления. Выберите нормальный вариант загрузки - Resume.
Может появится предупреждение о совместимости графического режима, но не волнуйтесь. Полная перезагрузка решит проблему, если таковая имеется.
После перезагрузки вы сможете войти с новым паролем.
Альтернативный метод сброса пароля Ubuntu
Если по каким-либо причинам у вас возникли трудности с переходом в корневую оболочку и сменой пароля, вы можете попробовать выполнить следующие действия:
Перезагрузите компьютер. Удерживайте Shift, чтобы открыть экран grub (если он не работает автоматически). Нажмите E в приглашении grub для редактирования экрана grub.
Найдите строку, начинающуюся с linux, измените ro на rw и добавьте init=/bin/bash в конце этой строки.
Нажмите Ctrl-X, чтобы сохранить изменения и загрузиться. Теперь вы загружаетесь в ядро Linux с правами на чтение и запись, и вместо графического интерфейса пользователя вы будете использовать оболочку bash. Другими словами, ваша система будет загружаться в корневой пароль без пароля.
Введите команду passwd с вашим именем пользователя. Если вы не знаете имя пользователя, проверьте с помощью команды ls/home (как в первом методе).
Теперь установите новый пароль. После того, как вы установили новый пароль, выйдите из терминала. Просто введите reboot в терминал или используйте команду выключения.
shutdown -r now
Готово! Пароль изменен.
Возможные проблемы и их решение
Ошибка “Authentication token manipulation error”
При вводе нового пароля у вас может появиться сообщение об ошибке манипулирования токеном (Authentication token manipulation error):
passwd username
Enter new UNIX password:
Retype new UNIX password:
passwd: Authentication token manipulation error
passwd: password unchanged
Причиной этой ошибки является то, что файловая система монтируется только с доступом для чтения. Измените доступ и перемонтируйте файловую систему следующим образом:
mount -rw -o remount /
Нет пункта “recovery mode”
Если нет пункта recovery mode, то вам нужно выбрать строчку с вашей системой, нажать E и допишите в конец опций ядра слово single. Затем нужно нажать B чтобы загрузился тот же терминал с правами суперпользователя.
Ошибка “end Kernel panic”
Вы можете увидеть такой вывод:
end Kernel panic - not syncing: Attempted to kill init! exit code=0x0007f00
Убедитесь, что вы удалили опцию splash boot при редактировании пункта меню grub.
Ошибка “Failed to connect to bus”
При попытке перезагрузиться с помощью команды reboot вы можете получить:
Failed to connect to bus: No such file or directory
Failed to talk to init daemon.
Чтобы избавиться от этой ошибки перезагрузитесь так:
# exec /sbin/init