гаджетыНовостиразработчиктехнология

Развитие аналитики на платформе данных

Стенограмма

Гил: Добро пожаловать в развивающуюся аналитику платформы данных. Меня зовут Бланка Гарсия Хиль. Я главный инженер BBC. Я собираюсь рассказать вам о мотивации этого выступления. На самом деле это история миграции на организационном уровне. Как иногда в командах инженеров миграция не воспринимается как положительная или вызывающая, потому что она рассматривается как способ поднять и перенести существующие технологии на новую платформу. В нашем случае мы пытаемся увидеть в этом положительные моменты и подумали, что это возможность начать все сначала. Мы задавались вопросом, что мы можем сделать по-другому на этот раз? Было много всего.

Контур

Во-первых, я собираюсь познакомить вас с BBC. Я могу удивить вас тем, чего вы не знали. Тогда почему платформа данных в такой организации? Затем мы рассмотрим архитектуру платформы микросервисов, которая управляет нашей аналитикой, и то, что мы разработали после реорганизации. Затем мы познакомимся с концепцией режима отказа, который используется в контексте наблюдаемости, и различных типов режимов отказа. Затем мы применим их к этой архитектуре, которую я представил ранее, и покажем вам, что мы смогли в нее спроектировать, применив извлеченные уроки. Затем, что произошло потом, а мы не смогли подготовиться или спрогнозировать их, и что мы сделали. Затем мы обобщим все, чему мы вместе научились.

Британская радиовещательная корпорация (BBC)

Перво-наперво, BBC. Если вы являетесь международной аудиторией, возможно, вы хорошо знакомы с нашими новостями, радиовещанием или нашим радио. BBC – это нечто большее. У нас очень популярный спортивный сайт, и мы транслируем спортивные трансляции в прямом эфире. У нас есть сервис нарезки ТВ под названием iPlayer для пользователей и аудитории в Великобритании. Теперь у нас также есть служба подкастинга под названием BBC Sounds. В прошлом году, когда все были дома, появились и другие услуги, которые занимали центральное место в умах наших пользователей. Это были службы вроде BBC Bitesize, которые всегда готовы помочь студентам сдать экзамены для сдачи национальных экзаменов, которые проводятся ежегодно. Он стал популярным, потому что мы добавили больше контента, чтобы помочь ученикам не отставать от уроков, которые им не хватало в школе, и пересматривать их каждый день. Я всегда добавляю сюда метеорологическую службу BBC, потому что, если вы похожи на меня и живете в Великобритании довольно долгое время, вы уже знаете, что мы просто любим говорить о погоде. Опять же, мы являемся глобальной вещательной компанией, но на самом деле мы находимся в Великобритании. Мы общественный вещатель. Это означает, что мы финансируемся за счет лицензионных сборов, которые оплачивает каждое домашнее хозяйство в Великобритании. В рамках нашей работы мы должны охватить самые разные аудитории, слои населения и сообщества, составляющие страны и регионы Великобритании. В рамках нашей миссии у нас есть три основных принципа: мы должны информировать, обучать и развлекать нашу аудиторию.

Платформа данных

Теперь о платформе данных. Зачем такой организации, как BBC, которая привыкла осуществлять почти одностороннее вещание, иметь платформу данных? Мы хотели сдвинуться с того места, где мы были, в место, где мы лучше понимаем нашу аудиторию. Это по разным причинам. Один из них – предложить всем то, что им нравится, а не только несколько, но и, возможно, расширить спектр услуг, о которых люди знают. В свою очередь, они максимально используют то, что BBC может им предложить. В конце концов, они платят нам лицензионный сбор. Кроме того, это помогает им осознать ценность денег, которые они нам платят.

Микросервисы плюс большие данные

С технической стороны, что это значит для команды платформы данных, в которой я работаю? Мы находимся в пространстве больших данных. Мы полностью в облаке. Мы на Амазонке. Мы разрабатываем архитектуры микросервисов для приема данных из различных источников. Один из этих источников, наш самый высокий масштаб – это данные аналитики. Это пример, которому мы будем следовать. Этот конвейер приема означает, что мы получаем миллиарды сообщений каждый день. Со временем эти сообщения накапливаются и хранятся в том, что мы называем озером данных. По сути, это просто облачное хранилище, где все данные прошли валидацию и прошли через цепочку обработки. Это озеро данных представляет собой исторический архив. Прямо сейчас мы уже находимся в петабайтном масштабе.

Наша архитектура микросервисов приема аналитики

Как выглядит архитектура, в которую мы перешли в наши дни? На первый взгляд может показаться, что на самом деле это выглядит довольно сложно. Мы будем разбирать это по крупицам и сосредоточимся на том, как мы работаем, и на том, что у нас есть, что помогло нам исследовать проблемы. Первая строка вверху – это цепочка приема и основные микросервисы, составляющие эту архитектуру. Если мы начнем с левой стороны, где у нас есть красный значок Amazon, который немного похож на ведро, у нас есть облачное хранилище на S3, куда мы получаем журналы приема. От нашего поставщика аналитики они доставляют нам файлы с регулярной частотой, и мы знаем, когда мы ожидаем эти файлы, и даже какие имена файлов должны быть. Каждый раз, когда файл попадает в это хранилище, запускается событие. Это событие сообщает следующему элементу системы, что получен новый файл, готовый к обработке. Это событие помещается в очередь. Многие события будут выстроены в эту очередь. Затем есть приложение Java, которое мы называем Job Submitter, которое будет читать каждое из этих событий, проверять имя файла, это то, что мы действительно ожидали получить. По сути, это очень минимальные вещи, которые он делает. Затем он переходит к следующему в цепочке.

На самом деле это не столько микросервис, сколько кластер MapReduce. Что он делает, так это то, что он может обрабатывать несколько файлов одновременно. Что он делает, так это то, что он фактически входит в содержимое каждого файла и проверяет его на соответствие модели. Мы делаем то, что мы называем проверкой на основе модели. Эта модель определяет, какие поля ожидаются в файле? Какие ценности принимаются? В противном случае он отклонит файл и уведомит нас. Он также сжимает данные, когда они записываются в следующую цепочку. Он также выполняет обогащения, которые, по сути, являются преобразованиями в некоторых из этих областей. Поля могут содержать местоположения. Они могут содержать почтовые индексы. Они могут содержать дату и время. Иногда формат, в котором они поступают, не самый полезный, поэтому они фактически трансформируются, а затем записываются. Затем эти файлы сохраняются в промежуточном озере данных. Мы называем это промежуточным только потому, что оно предназначено для использования в этой архитектуре микросервисов. Наши пользователи данных не имеют к этому доступа. Это все еще необработанный формат, хотя он был проверен. Это не самый оптимальный способ запроса и анализа.

Есть еще один процесс, называемый сводками данных. Что он делает, так это то, что он берет эти файлы и знает немного больше о данных и о предполагаемом использовании отчетов, информационных панелей или аналитиков данных. Он делает агрегаты и резюме. Затем эти агрегаты и сводки записываются в наше хранилище данных. Для этого мы используем Amazon Redshift. По сути, это большая база данных, и она действительно выполняет масштабные запросы. Затем исторический архив этих данных попадает в озеро данных. В Redshift мы сохраняем подмножество этих данных, потому что это обычно те варианты использования, которые у нас были. В BBC будут аналитики данных, специалисты по обработке данных, информационные панели и всевозможные пользователи, которые будут использовать эти данные для принятия решений и создания отчетов. Из этих данных также будут считываться алгоритмы машинного обучения. Теперь это стало основой BBC.

Когда мы обсуждали дизайн и структуру этого конвейера, для меня возник ключевой вопрос, на который я искал ответ. Для меня это были метрики, информационные панели, которые у нас есть, рассказывают мне все, что мне нужно знать? Поскольку мой опыт работы с предыдущей архитектурой показал, что работать с ней было довольно болезненно. Чтобы погрузиться в суть проблемы, потребовались годы. Иногда это расстраивало, потому что вы не могли найти данных, которые действительно рассказали бы вам, что происходит. Я также узнал на собственном опыте, а другие в команде на собственном опыте узнали, что не все ошибки обязательно должны быть в коде. В архитектурах микросервисов чем больше у вас микросервисов, тем больше трещин может появиться в вашей системе. Кроме того, поскольку эти микросервисы обычно не работают изолированно, наша архитектура связана с нашими поставщиками таким образом, что они отправляют нам файлы. Тогда в каждой точке, которую вы можете подключить к другой системе, есть еще одна потенциальная трещина. Когда вы проектируете, вы должны быть очень внимательными.

Режимы отказа – известные неизвестные

Теперь мы сосредоточимся на режимах отказа. Это термин, используемый для обозначения наблюдаемости. Существуют различные режимы отказа, и мы сначала объясним их. Первый – это так называемые известные неизвестные. Что это? Это сбои, которые мы можем предсказать: мы смотрим на систему или смотрим на какой-то график, думая, что здесь может произойти сбой. Вы можете предоставить им страховочную сетку или зарегистрировать ее. Вы можете отслеживать это в дашборде. Вы можете предупредить об этом. Это здорово, потому что вы знаете их заранее, поэтому они немного облегчают вашу жизнь, добавляя их в вашу систему. Затем есть еще один элемент сбоев, который, вероятно, произойдет со временем, о котором вы не узнаете. Принимая во внимание эти известные неизвестные, возникает вопрос, достаточно ли у вас информации на случай будущих неудач? Эти показатели дают вам все, что вам нужно? По нашему опыту, не совсем.

Неизвестные неизвестные

Есть еще один вид отказов, и они называются неизвестными неизвестными. Мы знаем, что каждая система в какой-то момент выйдет из строя, то есть каждая производственная система, которая обрабатывает некоторую нагрузку. Просто подумайте за пределами того опыта, который у вас есть, и вы поймете, что не можете все контролировать, вы не можете предсказать все неудачи. Как только вы это примете, у вас откроется новый образ мышления и новый способ решения проблем. Вопрос в том, есть ли у вас данные, есть ли у вас инструменты, которые позволят вам исследовать проблемы, которые еще не произошли?

Мне нравится показывать это изображение из сериала BBC, Шерлок. На нем изображены Шерлок и Ватсон. Шерлок очень часто говорит Ватсону, понимаете, но вы не наблюдаете. Я думаю, что это очень сильно связано с наблюдаемостью, что у вас будут метрики, у вас будут данные, но иногда вам все равно нужно будет учитывать эту неизвестную вещь или смотреть немного дальше. Что мне здесь нравится, так это то, что большинство людей сосредотачиваются на обоих мужчинах на переднем плане фотографии, но если вы посмотрите между ними, на самом деле есть скрытая фотография женщины на заднем плане.

Известные неизвестные, для которых мы создали

Давайте вернемся к архитектуре и известным неизвестным, из которых мы извлекли уроки и для которых мы разработали, когда проектировали архитектуру. Я суммировал их в этой таблице. Первым из них было то, что когда-то происходил большой взрыв, и мы просто теряли целый день обработки данных. Это было очень болезненно, потому что когда вы работаете в масштабе миллиардов, тогда сложнее выздоравливать, труднее исследовать. Все просто сложнее. В этом случае мы сказали, что должны уметь локализовать сбой. Каждый из микросервисов, созданных в архитектуре, если он выходит из строя или нам нужно исследовать, то мы должны исключить его из цепочки обработки, тогда это не повлияет на другие. Они могут действовать независимо. Это был огромный бонус.

Вторая проблема заключалась в том, что мы сталкиваемся с проблемами и обнаруживаем, что у нас просто недостаточно данных для их расследования. Мы смотрим журналы, смотрим на показатели, но мы не можем однозначно сказать, что вызвало сбой. В области данных есть термин, называемый хранилищем происхождения. По сути, это возможность отслеживать все данные, которые вы получаете, которые проходят через вашу систему и на различных этапах, которые она проходит, так что в случае чего вы можете войти в этот исторический архив событий, и посмотреть, в какой момент что-то не удалось.

Третий возвращается к провалу и возможности переиграть. В нашей новой архитектуре мы создали несколько утилит, которые помогают нам воспроизводить данные. Это происходит на разных этапах технологической цепочки и было чрезвычайно полезно и действительно облегчило нашу жизнь. Тогда четвертый – просто ответить на простой вопрос в распределенной системе, иногда это просто не так просто. Вы должны всегда сосредотачиваться, как узнать, что все работает? Вы действительно знаете, работает ли что-то? В этом случае у нас остались метрики, у нас остались дашборды. Хранилище родословных дало нам дополнительную детализацию, необходимую для ответа на этот вопрос на более подробном уровне.

Давайте перейдем к архитектуре и посмотрим, где вписываются эти четыре элемента. Первый – об устранении неисправности. Я выделил три основных микросервиса архитектуры, и каждый из них может выйти из строя независимо. Это само собой разумеющееся. Мы можем исследовать проблемы, мы можем развертывать их независимо. Это было огромно для разработки и испытаний. Второй – знать, в каком состоянии находятся данные цепочки обработки. Я показал номер два внизу. Вот где находится база данных о происхождении. Все наши микросервисы фактически записывают данные в это хранилище данных, чтобы мы могли отслеживать и проверять эти события. Номер три – это возможность воспроизводить данные. У нас есть утилита, которую мы называем resubmitter. Если мы хотим воспроизвести некоторые данные, мы их обрабатываем. По сути, мы просто добавляем событие в очередь, в котором указывается файл и путь, который нам нужно обработать. Есть приложение Java, которое просто помещает событие в начало цепочки обработки. Отдельно, в конце нашей цепочки обработки, где у нас есть сводные данные, это приложение Apache Airflow. Если вы знакомы с воздушным потоком Apache, он также имеет готовую функциональность, которая поможет вам повторно обрабатывать и воспроизводить данные. Мы тоже довольно часто этим пользуемся. Нам не пришлось ничего над этим строить. Затем четвертый – это возможность ответить на вопрос, действительно ли ваша система работает. Я не добавил сюда метрики и информационные панели. Не забывайте их, они вам все еще нужны. Затем база данных о происхождении делает основную вещь.

Неизвестные неизвестные, всплывшие со временем

Мы перейдем к неизвестному, неизвестному, и как вы можете подготовиться к этому. У нас возникли две основные проблемы. Во-первых, мы получали данные от стороннего поставщика. Хотя у этих данных и форматов данных была согласованная частота, мы все же обнаружили, что поступает много данных с опозданием, и что мы могли бы помочь, отслеживая отсутствующие данные. Кроме того, возможность информировать наших пользователей и наш бизнес, когда что-то идет не так, как ожидалось. В этом случае у нас было хранилище родословной, которое отслеживает события, а также то, какие данные отсутствуют. Мы сделали еще один шаг вперед и в конечном итоге автоматизировали его, чтобы сэкономить еще немного работы. Мы создали бессерверную функцию, написанную на Java. Что он делает, так это периодически запрашивает у хранилища данных lineage отсутствующие файлы. Если есть какие-либо отсутствующие файлы, он предупредит нас, но также он создаст заявку, откроет заявку на инцидент с нашим поставщиком и предоставит им точные данные, необходимые для начала расследования. Это было полезно для нас, а также для них.

Вторая вещь, которая возникает со временем, – это когда вы работаете с программными продуктами, всегда возникают соглашения об уровне обслуживания или SLA. Соглашения об уровне обслуживания – это, по сути, ожидание, согласованное с вашими заинтересованными сторонами в отношении обещанной доступности вашего сервиса, но также, когда происходят инциденты, в зависимости от различных уровней серьезности, каковы ваши обещания по их устранению? В нашем случае у нас есть это, как и у любого другого живого продукта, и у нас есть данные в хранилище происхождения. Иногда необходимость подключения к базе данных, знание и понимание модели данных в этой базе данных и возможность писать SQL уже сужают количество людей, которые могут понять эти данные.

В нашей команде был инженер, у которого была отличная идея. Он сказал, как насчет того, чтобы абстрагироваться от этого и создать утилиту командной строки, которая может отвечать на простые бизнес-вопросы? Вдохновленный интерфейсом командной строки Amazon, он написал утилиту на Python, чтобы иметь возможность ответить на вопрос о соглашении об уровне обслуживания. Эта утилита командной строки стала огромным успехом в нашей команде, до такой степени, что каждый подключенный инженер установит ее, и даже бизнес-аналитики будут использовать ее в какой-то момент. Он просто создает для нас отчеты, а затем позволяет очень легко получить доступ к этим данным, без необходимости помнить, как они связаны друг с другом и как все устроено внутри. Это действительно полезно. Вернемся к нашей архитектуре, откуда они держатся? Магазин происхождения внизу. Для нас это было ключевым моментом в борьбе с этими неизвестными неизвестными. Во-первых, бессерверное приложение, приложение Java, которое запрашивает и предупреждает об отсутствующих данных, а затем инструмент командной строки, который мне лично нравится, и я рекомендую вам изучить. В Python есть несколько фреймворков, которые делают вашу жизнь действительно простой.

Ключевые выводы

Ключевое обучение было вложено в общие инструменты. Это принесло нам много пользы, делясь знаниями в нашей команде. Раньше у нас было всего два или три человека, которые разбирались в архитектуре, могли разбираться в проблемах и сортировать их. Это не способ нести общую ответственность за вашу производственную систему. Кроме того, потому что, когда у вас есть разные архитектуры микросервисов, как у нас, мы можем иногда работать в других системах. Когда вам нужно вернуться в систему, над которой вы, возможно, не работали какое-то время, есть много деталей и контекста, которые ускользнули из вашей головы. Это помогает нам очень быстро получить ответы.

Тогда еще одна важная вещь – возможность воспроизвести данные. Всегда будут неудачи. Облегчите себе жизнь, автоматизируя это или создавая что-то, что позволяет делать это довольно быстро. Самым важным для меня было время, необходимое для сортировки и последующего устранения инцидентов. В те дни, когда у нас были большие временные сбои, это означало не только то, что мы потеряли данные за весь день, но и то, что у нас есть более миллиарда записей, которые нам пришлось изучить, чтобы понять, что происходит. Это было очень трудоемко, требовало много энергии. Иногда вы действительно не понимаете, что происходит, из-за огромного количества данных. В этом случае наличие хранилища родословных и проверка отдельных полей действительно помогли нам в этом. И, наконец, последнее – это возможность использовать эти данные для ответов на бизнес-вопросы и составления отчетов. Это вселило в нашу команду уверенность в работе, которую мы делаем. Это также дает деловую уверенность в том, что мы контролируем то, что можем контролировать.

Я хотел оставить вас с вопросом к себе. Я уверен, что многие из вас работали над разрабатываемыми программными продуктами. Если вы участвуете в очереди по вызову, у вас есть телефон, который предупреждает вас, когда дела идут плохо. Попытайтесь увидеть, есть ли у этих предупреждений закономерность? Есть ли что-то, что можно автоматизировать? Не могли бы вы разработать какой-нибудь инструментарий? Оцените влияние автоматизации, покажите это своему бизнесу и приведите аргументы в пользу этого. Потому что это не только убережет вас от того, что вас разбудят, но и, в свою очередь, сэкономит деньги для бизнеса. Есть над чем подумать. Это избавит вас от разочарования. Что, если бы вы могли изменить, вы бы разработали по-другому?

Вопросы и ответы

Беттс: Я хотел начать с того, что спросил Бланку о двух связанных проблемах, которые вы подняли, и я думаю, что с ними сталкивались все: есть люди, которые просто не имеют хороших знаний о системе, которые могут быть каким-то образом причастны к инциденту. Кроме того, когда вас возвращают, чтобы помочь в сортировке и устранении неполадок службы, над которой вы не работали какое-то время, она дает сбой, и вам придется заново с ней знакомиться. Что вы сделали, чтобы конкретно позаботиться об этих двух проблемах и распространить не только вот о проблеме, которая происходит, но также, вот потенциальное решение, вот что система может помочь вам сказать, что вы должны сделать, чтобы исправить это?

Гил: Для каждого продукта, который мы запускаем в производство, у нас обычно есть набор документов, которые мы составляем, и один из них называется runbooks. Модуль Runbook имеет определенную структуру. Он содержит такие вещи, как диаграммы архитектуры, кто является командой, которая владеет этим продуктом, с кем связаться, и ссылки на график поддержки. Кроме того, в системе есть известные проблемы, которые могут возникать время от времени, она содержит инструкции о том, как их исправить и как их отсортировать. Это почти как выгрузка этого контекста из нашего мозга в место, где у всех нас есть общее пространство. Мы также обновляем их с течением времени. Они невероятно полезны.

Беттс: Я видел, как пара людей уже спрашивала о хранилище родословных и идемпотентности для повтора. Не могли бы вы немного рассказать о магазине происхождения?

Гил: Магазин происхождения – это буквально хранилище событий. Это называется происхождением, потому что в пространстве данных происхождение – это объединение различных этапов ваших данных в пути к данным. Я показал каскад микросервисов. Причина, по которой родословная важна для нас, заключается в том, что, как я показал в конце нашего конвейера приема, существует хранилище данных. Что действительно интересно, так это то, что человек много раз будет запрашивать эти данные и пытаться разобраться в вещах. Они могут прийти к нам и сказать: «На самом деле, я пытаюсь проанализировать производительность видеопрограммы в iPlayer, и я не понимаю, почему эти данные показывают это. Возможно, это выглядит неправильно». Именно тогда мы неожиданно сталкиваемся с вопросом о том, как объяснить им, что это за необработанный файл с этими данными, и о различных этапах преобразования. Мы должны суметь вникнуть в это и присоединиться ко всем этим пунктам. Вот почему это называется родословной. В других системах, которые не являются платформами данных, у вас может быть только поток событий или трассировок. Это та же концепция. Это просто очень конкретный пример для платформы данных.

Беттс: Тогда, когда вам нужно воспроизвести эти события, как вы обеспечиваете идемпотентность, что вы не дублируете все, когда воспроизводите их?

Гил: На разных этапах есть разные стратегии. Я знаю, что в некоторых из них должна произойти некоторая очистка, прежде чем вы сможете фактически воспроизвести данные, потому что в противном случае вы создадите дубликаты. Вот почему, когда вы автоматизируете вещи, иногда мы думаем, что речь идет о том, чтобы, возможно, отбросить дополнительное событие, но на самом деле, если вы сядете и запишете этот процесс от начала до конца, вы поймете, что это еще не все. Что помогло нам понять, что на самом деле это были те модули Runbook, в которых у нас были пошаговые инструкции. Со временем они стали очень сложными. Это было похоже на то, что это нехорошо. Вы же не хотите, чтобы кто-то нервничал из-за таких подробных вещей.

Ставки: используете ли вы эти знания, чтобы сказать, что модуль Runbook стал слишком сложным, мы можем заставить систему помочь нам и упростить шаги, которые мы должны сделать, чтобы воспроизвести или просто полностью исключить ее.

Гил: Обычно да. Я думаю, что уже больше года мы также занимаемся тем, что мы называем проверками после инцидентов. Когда возникает проблема в производстве, когда мы проходим все испытания и исправления, люди, которые участвовали в ее решении, собираются вместе и проводят почти как ретроспективный анализ, чтобы попытаться узнать, что они сделали, что может быть можно было бы сделать по-другому, а что на самом деле можно было бы исправить надолго. Для проблем, которые могут быть разовыми, вы должны добавить их в модуль Runbook. Обычно вы не хотите, чтобы это происходило постоянно. На самом деле это запах чего-то, что требует автоматизации.

Беттс: Я думаю, что кто-то хотел конкретно, какую технологию вы использовали для магазина происхождения? Кафка? Это EventStore?

Гил: Для нас это не стриминг. Это просто реляционная база данных. Мы начали с чего-то очень простого, но вы можете строить сколько угодно. Это зависит от того, как часто и какие варианты использования вы собираетесь использовать. Для нас это стало местом, где мы могли просто хранить вещи. Я думаю, что в ретроспективе мы не ожидали, что мы будем использовать его так часто, или, может быть, в будущем у нас появятся подобные приложения для обработки в реальном времени. Это может быть что угодно.

Беттс: Я думаю, что типичным является то, что мы делаем эту маленькую вещь, и довольно скоро она становится довольно часто используемой частью системы.

Как платформа аналитики, которую вы создали, а также ее наблюдаемость, способствует совместному владению? У вас распределенная система, у всех команд есть свои проблемы, есть ли что-то, что помогает им всем увидеть, вот состояние системы, вот как мы все работаем вместе? Когда одна маленькая проблема возникает в одной части системы, она может иметь катастрофические последствия в другом месте?

Гил: Мы стараемся проводить регулярные сеансы обмена знаниями в нашей команде. Наша команда, работающая над платформой данных, – это, я думаю, около 25 человек, включая инженеров и представителей всех других дисциплин, которые нам нужны. Мы делимся на более мелкие группы или отряды. Иногда люди переключаются между отрядами, но для всех нас очень важно понимать, над чем работают другие отряды, потому что все очень взаимосвязано. Мы регулярно проводим демонстрации. Мы сотрудничаем не только между нашими командами, но и с нашими заинтересованными сторонами, потому что иногда у них могут быть потребности или они могут предлагать улучшения. В прошлом году мы сказали им, приходите и присоединяйтесь к нам на несколько недель, и мы построим его вместе с вами. Это было потрясающе, потому что мы многому у них научились, потому что они знатоки данных.

Беттс: Я думаю, что одна из тех вещей, которые мне нравятся, – это совместное владение командой. Описанный вами рабочий процесс очень четко подходит для конвейера данных, но некоторые из идей, о которых вы говорили, применимы к любому другому типу системы. Идея о том, что у вас есть неизвестные неизвестные в системе, вы явно добавили что-нибудь, чтобы помочь вам выявить их, когда они возникли, или все это было реакционным, что вы видели эту проблему, и тогда вам пришлось вернуться и найти решение.

Гил: Проблема с неизвестными неизвестными заключается в том, что вы можете собраться вместе с группой и просто подумать обо всех возможных неудачах, но, вероятно, не стоит тратить время на принятие мер по их устранению, пока вы не узнаете, произойдут ли они. Обычно команды выполняют эти упражнения на этапах проектирования, когда вы собираете в комнате несколько человек с разными углами опыта, разнообразие опыта очень важно для этого. Люди будут подсказывать, как что-то может потерпеть неудачу. Затем нужно составить этот список, а затем подумать на самом деле, какова вероятность того, что это произойдет? Затем вы начинаете расставлять приоритеты, но при этом снижать риски некоторых из них, потому что понимаете, что они очень маловероятны. Я думаю, это о том, чтобы помнить об этих вещах. Вы не сможете подготовиться ко всему, поэтому мы по-прежнему решаем ряд актуальных вопросов. Честно говоря, это часть процесса обучения.

Беттс: Вы упомянули реляционную базу данных, и я думаю, что люди склонны думать, что она неэффективна. Есть ли у вас какие-либо соображения по поводу пропускной способности, когда вы помещаете все данные в реляционную базу данных, или это нормально?

Гил: Для нас до сих пор все в порядке. Думаю, мы занимаемся производством уже более трех лет. Я узнал, что по мере изменения масштаба вашей проблемы меняется и способ ее решения, поэтому нам, возможно, придется это пересмотреть. Например, в прошлом году нам пришлось провести вторую миграцию нашей инфраструктуры для нашего хранилища данных, потому что оно стало настолько большим, что не отвечало потребностям, поэтому нам пришлось инвестировать в это. Это также может произойти в магазине родословной.

Беттс: Вначале вы сказали, что ставите перед собой цель упростить жизнь. Как найти компромисс между действительно простым, но в то же время полезным и необходимостью делать больше? Считаете ли вы, что достигли этого с помощью некоторых из предложенных вами решений?

Гил: Одна вещь, которая мне помогла, я думаю, сосредоточившись на простом, – это изучение вариантов использования. Каковы варианты использования бизнеса и ваших заинтересованных сторон? Знакомство с болевыми точками и начало работы с ними. Затем, со временем, вероятно, большинство вещей, о которых вы думали, перестали быть нужными. Кроме того, есть элемент, который, когда вы пишете в первый раз, первую реализацию, первую версию чего-либо, все может казаться очень простым, очень чистым. По мере того, как вы добавляете его, вы начинаете накапливать ужасный технический долг. По мере того, как вы продолжаете работать над этим, вы должны не только решать его, но и разговаривать со своими заинтересованными сторонами и со своим бизнесом о влиянии этого на команду, на продукт. Если у вас есть серьезное экономическое обоснование, пора заняться им.

Смотрите больше презентаций с расшифровками стенограмм

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button