Якось я ніколи так і не розказував над чим я саме працював в bing і якими задачами там займався. Ось і прийшов цей момент 
У якості передмови хочу сказати що колись у мене був досвід роботи в стартапі де ми намагалися зробити щось нове в інтернет-пошуку (деталі – Як я працював в Luxoft’і). От після того у мене і виник інтерес до цієї області.
Відпрацювавши трошки більше 2 років в System Center над новим продуктом Service Manager я нарешті перейшов у bing (після випуску першої версії продукту).
Сам інтернет-пошук у дуже спрощеному вигляді можна представити як систему в яку з одного боку подаються вхідні дані (наприклад веб-сторінки), а з іншого приходять запити від користувачів. До речі те що я далі пишу не відображує те що відбувається насправді на 100%, а просто є спрощенним приближенням яке передає основну ідею.
Що стосується обробки даних, їх класифікації, категоризації, оцінювання та ранжування – це все великі і складні задачі пов’язані з математичними моделями та неймовірними обсягами даних. У такі команди потрібні люди зі спеціалізованими знаннями, наприклад машинне навчання, нейронні мережі, математичне моделювання, тощо. І специфіка задач там така що обробка даних може йти дуже довго (години, а іноді навіть і дні).
З іншого боку запит від користувача треба обробити якомога швидше і видати йому назад якомога релевантніші (тобто такі що найкраще відповідають на запит) дані.
Таку складну систему яка складається з сотеньо компонентів можна поділити на шари, наприклад: інтерфейс веб-сторінки, розуміння запитів, уточнення запитів, робота з провайдерами даних, тощо.
Можливо ви не знали, але за статистикою переважна, абсолютна більшість запитів користувачів містять у собі помилки, тому пошукові системи намагаються їх автоматично виправити. Крім того запит треба зрозуміти. Скажіма якщо я шукатиму по слову Seattle то мене (через те що я близько до нього) скоріше за все цікавить ситуація на дорозі, можливо карта і погода. А якщо те ж саме напише людина з іншого континенту то для неї скоріше за все варто показати дані з вікіпедії, фотографії, та положення Сіетла на карті світу, або навіть інформацію про авіа-рейси до Сіетла.
До речі все що я розказую стосується не лише bing, але і будь-якої пошукової системи загального призначення.
Чим більше ви слів напишите у запиті (при умові що слова разом мають сенс) тим більша імовірність отримати відповідь на питання на першій же сторінці результатів. Крім того усе вище сказане означає що в залежності від вашого місцезнаходження (а також інших речей як історія пошуків) користувачі бачать різні результати на один і той же запит.
Крім того треба розуміти що пошукові системи побудовано так що обслуговуючі їх комп’ютери знаходяться у різних дата-центрах і відповідно дані і програми там можуть бути різними. Усі найновіші зміни, покращення та експеременти як правило гравці на цьому ринку роблять доступними в першу чергу для США. А для України/Росії відставання легко може складати місяці, а то і роки. Ви спробуйте – поставте у своєму браузері локаль США і порівняйте результати.
Коротше після того як користувач через веб-сторінку ввів свій запит він перетворюється на сотні різних варіацій і доповнюється іншими даними (місцезнаходження, браузер, попередні запити,…) і спрямовується до компонентів які можуть обробити ці запити.
Тепер поговоримо про дані. Якщо ми візьмемо результати спортивних матчів чи ціни на акції які мають оновлюватися щохвилини (а бажано кожні кілька секунд), прогноз погоди який треба оновлювати кожні пару годин хоча б, та скажімо статті з енциклопедії як добре як оновлюються раз на пів-року то зрозуміємо що зберігати такі дані разом, або просто однаковим способом просто недоцільно. По-перше від типу даних залежить логіка їх обробки. Наприклад запит MSFT для компонента що працює з акціями просто означає що потрібні поточні дані для акцій Microsoft, а от для карт наприклад, чи фінансових новин вже треба вибирати за ішими принципами (скажімо найцитованіші новини).
Ну і відповідно харатер даних впливає на те як і де їх зберігають і як їх деплоять (тобто як вони потрапляють на комп’ютери що обслуговують запити).
Я працював в команді яка відповідала за роботу з провайдерами даних. Тобто грубо кажучи це був фреймворк для створення компонентів для спеціалізованих типів даних. Компоненти знаходяться логічно між графічним інтерфейсом (веб-сторінкою) і сховищами даних. Фреймоврк навав можливість унфікувати роботу з постачальниками даних, послати і обробити паралельні запити до даних, зібрати відповіді і надати їх веб-сторінці.
Практично все що користувач бачить в результатах пошуку проходило через код який писала моя команда. Там все складніше, є і інші канали отримання даних, але все ж таки більшість даних проходила “через нас”
Які ж основні технічні проблеми? По-перше, уся робота відбувається асинхронно і наш код не мав створювати ніяких затримок (тобто многопоточність і при цьому відсутність синхронізації). По-друге, накладні розходи мають бути мінімальними і користувачі нашого коду мають отримувати усю функціональність “безкошотвно”, тобто абсолютно на все у нашого коду є лічені мілісекунди. До того ж використання пам’яті по мінімуму (її і без нас є кому споживати), можливість програмного чи апаратного збою в будь-який момент і інші речі.
Через те що в процесі задіяні сотні тисяч комп’ютерів імовірність фатальної помлики (баг, апаратний збій, пошкодження даних, проблеми у мережі, …) дуже висока і фактично гарантована.
До того ж дослідження причин негараздів та ще весела задача – знайти які дані і звідки прийшли, куди вони пішли, що потім сталося… Отак і “розслідуєш” якийсь випадок з машини на машину. Наче і логи є, проблема лише в тому що їх реально терабайти.
Я вже не говорю про те що при оновлені компонента його ніхто не буде зупиняти що замінити на нову версію і тому потрібні механізми як це робити “на ходу” (поки поточні запити оброблюються старим компоненом усі нові мають оброблюватися новим). До цього ж додайте оновлення даних деякі з яких як я вище зауважив оновлюються дуже часто, а також те що це має відбуватися на мінімум тисячах машин одночасно. Коротше веселуха ще та.
Крім написання коду та дослідеження причині помилок (і їх виправлення) команди в bing займаються деплойментом (тобто оновлюють свої компоненти в дата-центрах при необхідності) та реагують на критичні випадки. В командах є концепція чергових (і так само і в google, facebook та інших сервісах-гігантах) від кожнох команди які в разі необхідності (по закону підлості це завжди трапляється в 4 ранку або у вихідні) мають підключитися та вирішити проблему. Мова звісно не йде про виправлення багів (для цього є робочий час), а скоріше про “зробити щоб цього не було”. Це в тому числі може буде і повернення до старої версії коду або даних.
Які скіли розвиваються на такій роботі? Многопоточне прогамування, профілювання та оптимізація, дебагінг (WinDbg) та особливо вміння дошукуватися до першопричини проблем.
Ну от, наче щось розказав і секретів не видав
Ще пости по темі:
Ось так її цінують.
Цей рік у нас було присвячено довгим дистанціям в тріатлоні (я перейшов на 70.3, Олена – на олімпійську дистанцію) і усього лише трьох стартів за 3 місяці вистачило щоб відчути що зникла мотивація не лише змагатися, але і тренуватися. І проблема не лише у фізичній втомі, а і в тому що насправді треба докладати зусилля ментальне щоб не пропустити тренування. Навіть мій улюблений біг у поміркованому темпі на довгі дистанції (читай медетативний біг) не викликає вже такого захвату як колись.
Дані з комп’ютера – 
