Charity Majors, CTO & Co-Founder at Honeycomb – Интервью

Charity является инженером-оператором и случайным основателем стартапа в Honeycomb. До этого она работала в Parse, Facebook и Linden Lab над инфраструктурой и инструментами для разработчиков, и всегда оказывалась в роли руководителя баз данных. Она является соавтором книги O’Reilly’s Database Reliability Engineering, и любит свободу слова, свободное программное обеспечение и односолодовый виски.

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

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

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

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

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

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

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

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

Это было состояние, в котором мы находились в Parse, на Facebook. Каждый день вся платформа падала, и каждый раз это было что-то другое и новое; другое приложение, попавшее в топ-10 на iTunes, другой разработчик, загрузивший плохой запрос.

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

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

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

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

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

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

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

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

То, что меня возбуждает в 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.