«Эта статья участвовала в мероприятии Haowen Convocation Order, щелкните, чтобы просмотреть:Двойные заявки на внутреннюю и внешнюю стороны, призовой фонд в 20 000 юаней ждет вас, чтобы бросить вызов!"
Управляемое чтение: поисковая система Baidu — старейшая и крупнейшая система Baidu, и ее использование укоренилось в повседневной жизни каждого человека. На рынке существует интересная практика: многие люди проверяют, свободна ли их сеть, открывая поиск Baidu. Эта практика показывает, что поисковая система Baidu является представителем «стабильной» в сознании каждого, и это действительно так. Почему у поисковой системы Baidu такая высокая доступность? Какие технологии используются за кулисами? Предыдущие технические статьи редко вводятся. Эта статья основана на самой знакомой поисковой системе Baidu и знакомит с прекрасными методами, используемыми в ее управлении удобством использования при «анализе проблем стабильности».Используя историю в качестве подсказки, она знакомит со сложной ситуацией и критической ситуацией в процессе анализа проблемы стабильности. , Путь, путь инноваций. Я надеюсь вдохновить читателей и вызвать резонанс и обсуждение единомышленников.
Полный текст составляет 7741 слов, а расчетное время чтения — 17 минут.
Глава 1 Дилемма
Если в крупномасштабной микросервисной системе сбоев не происходит, то это должно быть связано с удачей. Но никогда не ждите, что неудач не будет, неудачи должны быть нормой. Базовая абстракция шаблона, используемая от возникновения ошибки до ее устранения, выглядит следующим образом.
Управление доступностью в основном улучшается с этих трех точек зрения: 1. Повышение устойчивости системы, 2. Улучшение методов стоп-лосса, повышение эффективности стоп-лосса и ускорение эффективности стоп-лосса, 3. Ускорение позиционирования причины и эффективности устранения.
Каждый из вышеперечисленных 3 пунктов является темой.Из-за ограничений по объему эта статья начинается только с [3].
Найти и устранить причину сбоя поисковой системы Baidu довольно сложно, и это может быть самой сложной задачей для всей компании. Трудности выражаются в следующих аспектах.
Чрезвычайно сложные системы и чрезвычайно строгие требования к доступности
Поисковая система Baidu разделена на две части: онлайн и оффлайн. Автономная система каждый день сканирует ресурсы всего Интернета, строит индексную библиотеку и формирует три важных данных: инвертированные, позитивные и абстрактные. Затем, на основе этих данных, онлайн-система получает запрос пользователя и находит нужный ему контент с чрезвычайно высокой скоростью. Как показано ниже.
Поисковая система Baidu чрезвычайно велика. Давайте почувствуем его размер с помощью нескольких цифр:
Ресурсная занятость поисковой системы Baidu эквивалентна сотням тысяч машин.Система распределена в N крупных регионах на юге и севере.Система поисковых микросервисов включает в себя сотни сервисов, а объем содержащихся данных достигает десятков петабайт Количество раз достигало сотен тысяч, а количество ежедневных сбоев достигало сотен.В исследованиях и разработках поисковой системы участвовали сотни людей, и система ежедневно сталкивалась с миллиардами поисковых запросов пользователей.
Несмотря на то, что система очень большая, Baidu предъявляет очень строгие требования к доступности. Доступность поисковой системы Baidu составляет более 5 девяток. что это за понятие? Если измерять время, в течение которого услуга может быть предоставлена, то при наличии 5 девяток система недоступна только более 5 минут в году, а при наличии 6 девяток время недоступности в году составляет всего около полминуты. Таким образом, можно сказать, что поиск Baidu не перестает служить.
Когда запрос попадает в поисковую систему Baidu, он должен пройти обработку десятков тысяч узлов. На рисунке ниже показана небольшая часть всех узлов, с которыми сталкивается запрос, что составляет примерно несколько тысячных от полного набора узлов, с которыми он столкнулся. При таком сложном пути вероятность того, что все узлы в норме, крайне мала, а аномалия — это норма.
Сложная система означает, что сбор и анализ данных на месте разлома представляет собой масштабный проект.
Различные типы проблем со стабильностью
Поисковая система Baidu всегда придерживалась пятизначной формулы «полный», «новый», «быстрый», «квази» и «стабильный». Ежедневные сбои в основном отражаются в аспектах «быстро» и «стабильно», которые можно условно разделить на три категории:
-
Ошибка потери PV: несвоевременное и правильное возвращение результатов запроса пользователям является наиболее серьезной ошибкой.
-
Сбой эффекта поиска: ожидаемая веб-страница не отображается в результатах поиска или занимает недопустимую позицию в результатах поиска; скорость отклика страницы результатов поиска низкая.
-
Сбой мощности: по различным внешним или внутренним причинам избыточность, необходимая для высокой доступности системы, не может быть гарантирована, и даже сбои и простои, вызванные превышением уровня воды в емкости критической точки, не прогнозируются, не предупреждаются и не ремонтируются в время.
За этими различными проблемами в разных областях неизменной остается необходимость сбора и обработки данных и автоматического абстрагирования опыта ручного анализа.
Глава 2. Знакомство, локализация: сломать игру
До 2014 года локализация и устранение причин неисправности конкурировали с данными.В то время было в основном два типа данных, которые можно было использовать. Один — онлайн-лог поискового сервиса (логирование), другой — какой-то разрозненный мониторинг (метрики). Эти два типа данных, с одной стороны, недостаточно детализированы, эффективность использования низка, трассировка проблем заходит в тупик, с другой стороны, их использование сильно зависит от ручного труда и низка степень автоматизации. . Чтобы проиллюстрировать на примере.
Анализ проблемы отбраковки сначала регулярно сканирует онлайн-сервис с помощью сценария, развернутого на машине центрального управления, для сбора журналов каждого модуля отдельного PV и отображает их на платформе анализа отбраковки (эта платформа уже была относительно мощным средством отбраковки). инструмент анализа причин в то время) страницу, как показано на рисунке, а затем вручную прочитать захваченный текст журнала для анализа. Хотя этот процесс имеет определенные возможности автоматизации, объем сбора PV невелик, объем данных недостаточен, и многие причины отклонения не могут быть точно обнаружены; отображение плитки данных должно полагаться на чтение опытными студентами, а эффективность анализа чрезвычайно высока. низкий.
С точки зрения тупиковых путей отслеживания проблем и эффективности отслеживания проблем первое кажется более актуальным. Отслеживание проблем без тупиков требует сбора большего количества наблюдаемых данных. Если он находится в непроизводственной среде, эти данные легко получить.Хотя будет потеря скорости запросов, это можно допустить в непроизводственной среде.Однако цена этой потери скорости недоступна в производственная среда. Под руководством теоретического краеугольного камня «Dapper, крупномасштабная инфраструктура трассировки распределенных систем» мы построили систему kepler 1.0, которая на основе выборки запросов создает цепочки вызовов и частичные аннотации (KV цепочек без вызовов во время обработки запросов) , данные). В то же время, на основе решения prometheus с открытым исходным кодом в отрасли, мы улучшаем нашу систему метрик. Сразу же после выхода в сеть они имеют огромную прикладную ценность, открывая простор воображению для построения и применения наблюдаемости поисковой системы.
2.1 Введение в кеплер 1.0
Архитектура системы показана на рисунке ниже.
Поэтапная миссия: kepler 1.0 заключается в улучшении наблюдаемости поисковой системы.Основываясь на зрелом решении с открытым исходным кодом в сочетании с компонентами компании для построения от 0 до 1, он может быстро заполнить пробел в наблюдаемости и имеет процесс обработки запросов, основанный на queryID.Цепочка вызовов и возможность маршрутизации журналов экземпляра сервиса.
Введено: несложно найти по архитектуре kepler1.0, это полная ссылка на zipkin с точки зрения пути данных, архитектуры хранения и т.д.
Локализация: когда zipkin был представлен, SDK для сбора данных поддерживает только C++, чтобы удовлетворить требования к наблюдаемости для модулей, отличных от C++, принимая во внимание стоимость многоязычного обслуживания SDK и навязчивость трассировки, используется резидентный процесс для сбора выходных форматов через журналы и данные трассировки, совместимые с C++ SDK, то есть модуль сбора журналов на рисунке.
2.2 Предварительное изучение общей схемы сбора метрик
Архитектура системы показана на рисунке ниже.
Поэтапная миссия: примерно в 2015 году поиск начал изучать технологию контейнерного колокейшна крупномасштабных кластеров онлайн-сервисов.В это время система мониторинга в компании слабо поддерживала агрегацию многомерных показателей, а традиционные мощности метод управления, основанный на машинно-габаритных показателях, уже не мог удовлетворить требования контейнеров, удовлетворить потребности смешанных офисных сценариев.
Представлено: зрелое решение для метрик в отрасли с открытым исходным кодом представлено в совмещенном кластере поисковых онлайн-сервисов, а также реализован контейнерный экспортер индексов, соответствующий протоколу prometheus.Опираясь на гибкий интерфейс запроса многомерного индекса prometheus и богатые возможности визуализации grafana, бизнес онлайн-поиска был построен Базовая система данных, от которой зависит управление мощностью совместно расположенных кластеров.
Локализация: индикатор контейнера prometheus-exporter глубоко связан с поисковой онлайн-системой PaaS, а метаинформация службы выводится в виде метки prometheus, которая реализует возможности индексирования и агрегирования метаинформации контейнера и отвечает потребностям управление мощностями в сценарии совместного размещения в контейнерах. Объединение метрик и метаинформации PaaS является главным достижением предварительного изучения облачной системы метрик.
2.3 Первоначальный эффект от применения
Сценарий 1: Отказ, проблемы с эффектом
Периодические болевые точки: ручной анализ в значительной степени зависит от журналов, а некоторые конкретные запросы точно извлекаются из массивных цепочек вызовов и данных журналов.Эффективность сканирования журналов онлайн-машин через ssh очень низкая, а домашние онлайн-сервисы переполнены, что приводит к к стабильности сексуальный риск.
Решение. Для решения проблемы отклонения обычной случайной выборки и воспроизводимых эффектов включена принудительная выборка, а цепочка вызовов и журналы запрашиваются напрямую с платформы через queryID для ручного анализа, что в основном соответствует требованиям трассировки на данном этапе.
Сценарий 2: Проблемы со скоростью
Периодические болевые точки: есть только лог-данные, нет четких временных меток цепочки вызовов, цепочка вызовов, инициированных запросом, длинная и имеет большую степень разветвления, логи разбросаны широко и сложны собирать. Восстановить весь процесс отсчета времени по журналу практически невозможно. Это приводит к оптимизации черного ящика для скорости.
Решение: Точная метка времени цепочки вызовов завершена, что позволяет восстановить полное время запроса. Через цепочку вызовов можно найти точки оптимизации, такие как трудоемкий этап длинного хвоста на уровне программы или экземпляр горячей точки на уровне планирования.На основе этого проекты улучшения, такие как асинхронность соединения TCP и блокировка бизнес-обратных вызовов выпуск операции инкубируется и реализуется.
Сценарий 3: Проблемы с емкостью
Периодические болевые точки: отсутствие многомерной индикаторной информации (отсутствие индикаторов-контейнеров, разрыв между индикаторами и PaaS-системами), отсутствие эффективных средств агрегации, обработки, комбинирования, сравнения, майнинга и визуализации.
Решение. Была создана поисковая онлайн-система сбора многомерных индексных данных на уровне контейнера, которая предоставила важный базовый источник выходных данных для контейнерных приложений управления емкостью и сделала шаг к облачному исследованию индексной системы. На следующем рисунке — скриншот функции аудита потребления через индикатор контейнера после выхода проекта в онлайн.
Глава 3 Инновации: раскрытие ценности приложений
Хотя kepler 1.0 и prometheus открыли двери для построения наблюдаемости, трудно получить большую потребительскую ценность при низких затратах из-за ограниченных возможностей.
3.1 Мощность источника
Реализация на основе решения с открытым исходным кодом не может соответствовать поисковому сервису и масштабу трафика по стоимости ресурсов, задержке получения, охвату данных и т. д., что влияет на тщательность решения проблемы стабильности, особенно в поисковом эффекте. текущие результаты поиска являются ненормальными, и ожидается, что ключевые результаты не будут отозваны на уровне индексной библиотеки.
Решение проблемы стабильности всегда является отправной точкой и конечной точкой построения наблюдаемости, а бескомпромиссное построение данных всегда было главным приоритетом. С 2016 года поиск ведет к инновациям в области наблюдаемости и доводит их до крайности, обеспечивая практические решения всех видов проблем.
3.2 Полная коллекция
Поскольку масштаб поисковой системы слишком велик, kepler 1.0 может поддерживать только частоту дискретизации до 10%, в реальных условиях возникает противоречие между затратами ресурсов и тщательностью решения задач.
(1) Большинство недостатков поисковой системы связано с гранулярностью запросов. Многие случаи не могут стабильно воспроизводиться, но необходимо проанализировать причины ненормальных результатов поиска конкретного запроса в истории. Разочаровывает тот факт, что только резервные копии журналов могут удовлетворить требованиям по возврату данных любого исторического запроса в то время, но столкнулись с проблемой высокой стоимости сбора; кроме того, многие запросы не попали в выборку kepler 1.0, а ее подробные отслеживание данных не делал Если его не стимулировать, нет возможности запустить анализ. Почти все учащиеся хотят иметь возможность просматривать информацию об отслеживании и регистрации конкретного запроса в истории.
(2) Служба внутреннего хранения компании имеет низкую производительность и низкую ремонтопригодность.Стоимость ресурсов, необходимых для решения вышеуказанных проблем за счет увеличения частоты дискретизации, огромна, что не может быть удовлетворено на практике.
Для этого противоречия в отрасли в то время не было хорошего решения. Поэтому мы реализовали систему kepler2.0 с помощью технологических инноваций. С точки зрения реализации, система разделяет трассировку и регистрацию данных и обеспечивает максимальную оптимизацию для каждой функции данных за счет единой ответственности Стоимость заключается в очень низких накладных расходах ресурсов и очень небольшом увеличении затрат времени в обмен на отслеживание полного запроса. , А возможности ведения журналов, ежедневные десятки петабайт журналов и десятки триллионов цепочек вызовов можно проверить за считанные секунды. Решите большинство проблем, с которыми столкнулись при устранении неполадок.
3.2.1 Полный индекс журнала
Во-первых, мы вводим полный индекс журнала, который соответствует модулю индекса журнала на рисунке выше.
Журналы службы поиска будут сохраняться на онлайн-машине в течение длительного периода времени.Предыдущие решения были ориентированы на вывод исходного лога в обходную систему.Однако игнорировалось, что онлайн-кластер, естественно, является готовым бесплатное место для хранения исходного журнала. Поэтому мы предложили ряд инновационных решений, а основную концепцию дизайна можно сформулировать одним предложением: индексация на месте.
В Beidou индекс лога определяется четверкой, которую мы называем локацией, состоящей из 4 полей: ip (машина, на которой находится лог) + inode (файл, где находится лог) + смещение (местоположение). смещение, где находится бревно) + длина (находится бревно) длина). Эти четыре поля имеют общий размер 20 байт и связаны только с количеством журналов, а не с их длиной, что позволяет реализовать недорогое индексирование массивных журналов. После того, как расположение собрано модулем индексатора журнала (развернутым на компьютере онлайн-сервиса поиска), исходный журнал индексируется, и индекс сохраняется на диске контейнера, в котором находится журнал.
Логический формат индекса журнала, хранящегося локально в Beidou, показан на следующем рисунке.
При запросе отправьте инод, смещение и длину на машину, где находится индексный ip (то есть машину, где находится исходный лог).Через модуль чтения логов на машине инод, смещение и длину может быть запросом с фиксированной точкой со сложностью времени O (1).Возврат исходного текста журнала позволяет избежать процесса сканирования файла, снижает ненужное потребление ресурсов процессора и ввода-вывода и снижает влияние запроса журнала на стабильность службы производства окружающая обстановка.
При этом, помимо поддержки индекса местоположения, мы также поддерживаем гибкую индексацию, например, в качестве вторичных индексов используются поля с бизнес-значениями, такие как поисковые термины и идентификаторы пользователей, что удобно для сценария, когда queryID не может быть полученный во время отслеживания проблем.Что касается того, как используется индекс, в дополнение к запросу журнала мы также создаем архитектуру потоковой обработки с помощью отправки индекса для поддержки требований приложения для потокового анализа журнала.
Вот еще вопрос: при запросе лога запроса все равно нужно транслировать запрос запроса на все инстансы? Ответ - нет. Мы оптимизировали процесс запроса следующим образом: с помощью полной цепочки вызовов callgraph, описанной ниже, чтобы определить, в каких экземплярах находится журнал запросов, чтобы добиться отправки с фиксированной точкой и избежать широковещательной рассылки.
3.2.2 Полная цепочка вызовов
В схеме, предоставленной dapper paper, есть два типа данных: цепочка вызовов и аннотация. После повторного изучения мы обнаружили, что сущностью аннотаций является логирование, которое может быть выражено логированием; а цепочка вызовов может не только удовлетворять потребности анализа проблем, но также легко создается и сжимается благодаря аккуратности и согласованности. формат данных, чтобы достичь высокого уровня ресурсов.Экономичное использование. Поэтому система callgraph (красная часть на диаграмме архитектуры kepler2.0) возникла с самыми простыми и чистыми данными. Основная задача полной цепочки вызовов состоит в том, чтобы хранить и эффективно запрашивать данные цепочки вызовов для всех запросов с разумными затратами ресурсов.
В логической модели трассировки базовым элементом цепочки вызовов является span, а span состоит из 4 частей: span_id родительского узла, span_id текущего узла, ip&port дочерних узлов, к которым обращается этот узел. , а также временные метки начала и окончания.
Основная технологическая инновация полной цепочки вызовов заключается в двух пунктах: (1) самостоятельно разработанный алгоритм генерации деривации span_id, (2) индивидуальный алгоритм сжатия в сочетании с характеристиками данных. По сравнению с kepler1.0 достигается оптимизация накладных расходов на хранение на 60%. Эти две техники описаны ниже.
3.2.2.1 Алгоритм генерации вывода span_id
Описание: На рисунке ниже есть два спана 0 и 1. Каждый спан состоит из двух частей: клиентской и серверной части.Каждый бокс — это данные, фактически записываемые в хранилище системы трассировки.
Слева: алгоритм случайных чисел kepler1.0. Чтобы клиент и сервер спана могли соединяться вместе и восстанавливать отношения родитель-потомок между несколькими спанами, серверная сторона всех спанов должна сохранять parent_span_id. Таким образом, два интервала фактически должны записать 4 части данных в хранилище.
Справа: алгоритм вывода kepler2.0, span_id начинается с корневого узла с 0, каждый раз, когда вызывается нижестоящий экземпляр, ip нижестоящего экземпляра накапливается как его span_id и передается нижестоящему, а нижестоящий экземпляр рекурсивно продолжает накапливаться на этот span_id, так что гарантируется, что span_id всех вызовов запроса уникален. Экземпляру нужно только сохранить свой собственный span_id и нисходящий IP-адрес, и он может восстановить клиентскую и серверную части диапазона в соответствии с алгоритмом. Видно, что нужно записать только 2 части данных, и parent_span_id не нужно хранить в данных, поэтому пространство для хранения сохраняется, таким образом реализуя возможность сбора полной цепочки вызовов.
Цепочка вызовов от ip1:port1 до ip2:port на рисунке справа имитирует сценарий многократного доступа к одному и тому же экземпляру ip2:port2, который широко используется в службах поиска (например, запрос в службе уровня слияния будет запрашивать один и тот же порядок Экземпляр службы дважды; восходящий запрашивает исключение нисходящего потока, чтобы повторить попытку к тому же экземпляру на уровне планирования и т. д.), алгоритм деривации может гарантировать уникальность сгенерированного span_id в запросе, тем самым гарантируя целостность данных цепочки вызовов.
3.2.2.2 Сжатие данных
В сочетании с характеристиками данных комплексно используются различные алгоритмы сжатия.
(1) Бизнес-уровень: индивидуальное сжатие в сочетании с характеристиками бизнес-данных, а не безмозглое сжатие с использованием общих алгоритмов.
(a) отметка времени: используйте разницу относительно базы и алгоритма pfordelta. Временная метка нескольких дочерних узлов службы разветвления сжимается, и сохраняются только первая временная метка запуска и смещение относительно временной метки. Если взять в качестве примера распространенные сценарии с высокой степенью разветвления и малой задержкой при поиске в онлайн-сервисах, сохранение смещения экономит 70 % по сравнению с прямым сохранением двух меток времени.
(b) ip: ip службы поиска в интрасети — это сетевой сегмент 10.0.0.0/24, поэтому сохраняются только последние 3 байта ip, 10 первых байтов опускаются, и каждый ip сохраняет 25%.
(2) уровень protobuf: protobuf используется в окончательном постоянном хранилище данных на бизнес-уровне, а функция сериализации protobuf гибко используется для экономии памяти.
(a) varint: переменная длина заменяет исходную 64-битную фиксированную длину для сжатия и сохранения всех целых чисел и обеспечивает отсутствие потерь памяти для данных менее 64 бит, таких как IP-адрес, порт и смещение метки времени.
(b) упакованный повтор: ip и timestamp являются повторяющимися типами, и нужно сохранить номер поля только один раз. Упакованный не включен по умолчанию, что приводит к тому, что номер поля сохраняется один раз для каждого повторяющегося поля, что приводит к большим потерям. Взяв в качестве примера разветвленную ссылку со средним коэффициентом разветвления 40, включение упаковки может сэкономить 25% дискового пространства (40-байтовое число полей).
Наконец, логический формат (вверху) и физический формат (внизу) диапазона таковы:
3.2.3 Преимущества сценариев применения
3.2.3.1 Путешествие во времени: не ожидается, что ключевой результат любого конкретного запроса в истории вызовет проблему на уровне индексной библиотеки.
Поскольку библиотека индексов слоя отзыва является крупнейшим сервисным кластером для поиска, kepler 1.0 поддерживает только частоту дискретизации 0,1% в сервисе библиотеки индексов, что затрудняет отслеживание проблем с эффектом, вызванных определенным типом библиотеки и сбоем фрагментации индексная библиотека. Полная коллекция цепочки вызовов может лучше решить эту дилемму.
Реальный случай: поисковый запрос ПК = Ханчжоу не показывает результаты энциклопедии Baidu. Сначала используйте инструмент для запроса 9-го фрагмента базы данных A, где находится URL-адрес результата, а затем используйте полную цепочку вызовов, чтобы проверить, что запрос теряется во всех запросах к базе данных A. 9-й сегмент (сегмент был отклонен политикой планирования, поскольку время ожидания истекло после повторной попытки), далее найдите все реплики этого сегмента и не сможете предоставлять услуги. После восстановления службы ожидаемый результат вспоминается нормально.
3.2.3.2 Цепной анализ: служба с отслеживанием состояния приводит к проблеме «неправильного поведения вспомогательного транспортного средства»
Анализ сложности проблем с эффектом службы с отслеживанием состояния: Возьмем в качестве примера наиболее распространенную службу кэширования. Если кеша нет, вы можете найти причину исключения через цепочку вызовов и войти в журнал через queryID ненормального эффекта. Однако очевидно, что система онлайн-поиска не может не иметь кеша, и обычно данные кеша будут дополняться асинхронным механизмом обновления. цепочка вызовов и журнал не могут быть использованы для конечного местоположения проблемы.Проанализируйте цепочку вызовов и журнал предыдущего запроса, который записывает в кеш во временном ряду, и мы называем его «разрушителем».
Ограничения kepler1.0: Алгоритм выборки kepler1.0 представляет собой выборку со случайной пропорцией.Выполнение двух запросов «разрушитель» и «жертва» является независимым событием, потому что «разрушитель» приходит первым, когда «жертва» находится в состоянии При воздействии эффекта больше невозможно обратить время для запуска прежней выборки, что приводит к прерыванию цепочки трассировки двух запросов в измерении «последовательность», и трассировка также вызывает проблемы. .
Метод взлома kepler2.0: на основе реализации «вертикальной ассоциации» (полная цепочка вызовов и информация журнала в процессе обработки запроса) с помощью полной цепочки вызовов строится возможность «горизонтальной ассоциации», которая поддерживает несколько связанных требований отслеживания, связанных с запросом. При записи кеша TraceId текущего запроса записывается в результат кеша, а идентификатор запроса в результате кеша можно использовать для поиска «нарушителя спокойствия» путем чтения запроса в кеше. С помощью функции полной цепочки вызовов вы можете проанализировать и найти причину, по которой «нарушитель спокойствия» записывает грязный кеш. Кроме того, пользовательский интерфейс специально разработан для простоты использования отслеживания временных рядов.Например, отображается queryID кеша, записанный в журнале, и щелкнув это поле, можно напрямую перейти к цепочке вызовов соответствующего запроса и страница запроса журнала.
резюме
Вышеупомянутое окончательное построение данных решает тупик отслеживания проблем.В настоящее время эффективность анализа проблем становится основным противоречием.В следующей части мы покажем вам, как Baidu Search может абстрагироваться от ручного анализа для реализации автоматического и интеллектуальные проблемы с неисправностями, чтобы гарантировать стабильность поиска Baidu. Продолжение следует, следите за новостями...
Авторы этого номера | ZhenZhen; LiDuo; XuZhiMing
Предложения о работе:
Обратите внимание на одноименную публичную учетную запись Baidu Geek, сказал: введите внутренний толчок, чтобы присоединиться к отделу архитектуры поиска, мы с нетерпением ждем вашего присоединения!
Рекомендуемое чтение:
｜Кодирование сообщества для выявления практики атак черных и серых продуктов
｜PornNet: сеть идентификации контента порновидео
---------- END ----------
Байду Гик говорит
Официальный технический общедоступный аккаунт Baidu доступен онлайн!
Технические галантереи · Отраслевая информация · Интернет-салон · Отраслевая конференция
Информация о найме · Внутренняя информация · Технические книги · Периферийные устройства Baidu
Приглашаем студентов обратить внимание