Чарити Мэйджорс, Технический директор и сооснователь Honeycomb – Интервью

Чарити – инженер по эксплуатации и случайный основатель стартапа в Honeycomb. До этого она работала в Parse, Facebook (META ) и Linden Lab над инфраструктурой и инструментами для разработчиков, и всегда оказывалась в роли руководителя баз данных. Она является соавтором книги “Инженерия надежности баз данных” от O’Reilly, и любит свободу слова, свободное программное обеспечение и односолодовый виски.

Вы были менеджером по производственной инженерии в Facebook (теперь Meta) более 2 лет, какие были ваши основные достижения в этот период и какие ключевые выводы вы сделали из этого опыта?

Я работала над Parse, который был бэкендом для мобильных приложений, примерно как Heroku для мобильных. Мне никогда не интересно было работать в большой компании, но мы были приобретены Facebook. Одним из моих ключевых выводов было то, что приобретения очень сложны, даже в самых лучших обстоятельствах. Совет, который я всегда даю другим основателям, заключается в том, что если вы собираетесь быть приобретены, убедитесь, что у вас есть спонсор-исполнитель, и подумайте тщательно о том, есть ли у вас стратегическое соответствие. Facebook приобрел Instagram незадолго до приобретения Parse, и приобретение Instagram было далеко не идеальным, но оно было в конечном итоге очень успешным, потому что они имели стратегическое соответствие и сильного спонсора.

Я не имела легкого времени в Facebook, но я очень благодарна за время, которое я провела там; я не знаю, смогла бы я начать компанию без уроков, которые я выучила об организационной структуре, управлении, стратегии и т. д. Это также дало мне репутацию, которая сделала меня привлекательной для венчурных капиталистов, ни один из которых не дал мне времени суток до той поры. Я немного раздражена этим, но я все равно возьму это.

Можете ли вы рассказать историю о запуске Honeycomb?

Определенно. С архитектурной точки зрения, Parse был впереди своего времени – мы использовали микросервисы до того, как они стали модными, у нас был сильно шардированный слой данных, и как платформа, обслуживающая более миллиона мобильных приложений, у нас были очень сложные проблемы многопользовательской среды. Наши клиенты были разработчиками, и они постоянно писали и загружали произвольные фрагменты кода и новые запросы, скажем так, “различного качества” – и нам просто приходилось все это принять и сделать так, чтобы все работало, каким-то образом.

Мы были на переднем крае целого ряда изменений, которые с тех пор стали мейнстримом. Раньше большинство архитектур было довольно простым, и они терпели неудачи повторно в предсказуемых способах. У вас обычно был веб-слой, приложение и база данных, и большая часть сложности была связана с вашим кодом приложения. Итак, вы писали проверки мониторинга, чтобы отслеживать эти неудачи, и строили статические панели для ваших метрик и данных мониторинга.

Эта отрасль пережила взрыв архитектурной сложности за последние 10 лет. Мы разрушили монолит, поэтому теперь у вас есть от нескольких сервисов до тысяч микросервисов. Полиглотная постоянная память является нормой; вместо “базы данных” теперь нормально иметь множество разных типов хранилищ, а также горизонтальное шардирование, слои кэширования, базу данных на микросервис, очереди и многое другое. Кроме того, у вас есть контейнеры, размещенные на сервере, третьи сервисы и платформы, серверный код, блоковое хранилище и многое другое.

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

Отладка этих проблем с нуля невероятно сложна. С помощью логов и метрик вам基本но приходится знать, что вы ищете, прежде чем вы сможете найти это. Но мы начали подпитывать некоторые наборы данных в инструмент Facebook под названием Scuba, который позволял нам нарезать и рубить на произвольных измерениях и высококачественных данных в реальном времени, и количество времени, которое нам потребовалось для выявления и решения этих проблем с нуля, упало как камень, как с часов до… минут? секунд? Это даже не было инженерной проблемой; это была проблема поддержки. Вы могли просто следовать по следу хлебных крошек к ответу каждый раз, клик-клик-клик.

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

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

Для читателей, которые незнакомы, что конкретно такое платформа наблюдаемости и как она отличается от традиционного мониторинга и метрик?

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

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

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

Наблюдаемость как надеть очки перед тем, как отправиться в путь по шоссе. Разработка, управляемая тестами (TDD), революционизировала программное обеспечение в начале 2000-х годов, но TDD теряет свою эффективность, когда сложность находится в наших системах, а не только в программном обеспечении. Все чаще, если вы хотите получить преимущества, связанные с TDD, вам фактически нужно инструментировать ваш код и выполнять что-то подобное наблюдаемости, управляемой разработкой, или ODD, где вы инструментируете по мере продвижения, быстро развертываете, а затем смотрите на ваш код в производстве через призму инструментирования, которое вы только что написали, и спрашиваете себя: “делает ли он то, что я ожидаю, и выглядит ли все еще… странно?”

Тесты одни недостаточны, чтобы подтвердить, что ваш код делает то, что он должен делать. Вы не знаете этого, пока не посмотрите на него в производстве, с реальными пользователями на реальной инфраструктуре.

Такой тип разработки – который включает производство в быстрые обратные связи – (somewhat counterintuitively) намного быстрее, проще и легче, чем полагаться на тесты и медленные циклы развертывания. Как только разработчики попробовали работать таким образом, они знаменито неохотно возвращаются к старому, медленному способу делать вещи.

Что меня возбуждает в AI, так это то, что, когда вы разрабатываете с помощью LLM, вам нужно разрабатывать в производстве. Единственный способ, которым вы можете получить набор тестов, – это сначала проверить ваш код в производстве и работать в обратном направлении. Я думаю, что написание программного обеспечения, поддерживаемого LLM, будет таким же распространенным навыком, как написание программного обеспечения, поддерживаемого MySQL или Postgres, в течение нескольких лет, и моя надежда заключается в том, что это вынуждает инженеров идти в лучшую жизнь.

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

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

И если вы помещаете код в производство, который никто не понимает, есть очень хорошая вероятность, что он не был написан, чтобы быть понятным. Хороший код написан, чтобы быть легко читаемым и понятным и расширяемым. Он использует конвенции и шаблоны, использует последовательные имена и модуляризацию, он балансирует DRY и другие соображения. Качество кода неотделимо от того, насколько легко людям взаимодействовать с ним. Если мы просто начнем бросать код в производство, потому что он компилируется или проходит тесты, мы создаем огромный айсберг будущих технических проблем для себя.

Если вы решили отправить код, который никто не понимает, Honeycomb не может помочь с этим. Но если вы заботитесь о том, чтобы отправить чистое, итерируемое программное обеспечение, инструментирование и наблюдаемость абсолютно необходимы для этого усилия. Инструментирование – это как документация плюс отчет о состоянии в реальном времени. Инструментирование – единственный способ, которым вы можете действительно подтвердить, что ваше программное обеспечение делает то, что вы ожидаете, и ведет себя так, как ваши пользователи ожидают.

Как Honeycomb использует AI, чтобы улучшить эффективность и результативность инженерных команд?

Наши инженеры используют AI много внутри, особенно CoPilot. Наши более младшие инженеры сообщают, что они используют ChatGPT каждый день, чтобы ответить на вопросы и помочь им понять программное обеспечение, которое они строят. Наши более старшие инженеры говорят, что это велико для генерации программного обеспечения, которое было бы очень утомительным или раздражающим написать, например, когда у вас есть巨альный YAML-файл, который нужно заполнить. Это также полезно для генерации фрагментов кода на языках, которые вы обычно не используете, или из документации API. Например, вы можете сгенерировать некоторые действительно великие, пригодные для использования примеры вещей, используя SDK и API AWS, поскольку они были обучены на репозиториях, которые имеют реальное использование этого кода.

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

Можете ли вы предоставить примеры того, как функции, управляемые AI, такие как ваш помощник запросов или интеграция с Slack, улучшают командную работу?

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

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

Honeycomb обещает более быстрое решение инцидентов. Можете ли вы описать, как интеграция логов, метрик и трассировок в единую тип данных помогает в более быстрой отладке и решении проблем?

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

Данные становятся ценными благодаря контексту. Последнее поколение инструментов работало путем удаления всего контекста на этапе записи; как только вы удалили контекст, вы никогда не сможете его вернуть.

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

Когда вы храните эти богатые контекстные данные, вы можете делать с ними вещи, которые кажутся магией. У нас есть инструмент под названием BubbleUp, где вы можете нарисовать пузырь вокруг всего, что вы думаете, является странным или может быть интересным, и мы вычисляем все измерения внутри пузыря по сравнению с внешним, базовым, сортируем и дифференцируем их. Итак, вы как бы “этот пузырь странный” и мы сразу же говорим вам, “он отличается в xyz способах”. Так много отладки сводится к “вот вещь, которую я заботлюсь, но почему я заботлюсь об этом?” Когда вы можете сразу же определить, что это отличается, потому что эти запросы исходят из устройств Android, с этим конкретным идентификатором сборки, используя этот языковой пакет, в этом регионе, с этим идентификатором приложения, с большим полезным грузом… к тому времени вы, вероятно, знаете точно, что не так и почему.

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

Как улучшение наблюдаемости переводится в лучшие бизнес-результаты?

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

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

Куда вы видите будущее наблюдаемости, особенно в отношении разработок AI?

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

Это о том, чтобы соединить точки между бизнес-результатами и технологическими методами.

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

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

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

Спасибо за отличное интервью, читатели, которые хотят узнать больше, должны посетить Honeycomb.