Черіті Меджорс, Технічний директор та співзасновник Honeycomb – Інтерв’ю Серія

Черіті – інженер з операцій та випадковий засновник стартапу в Honeycomb. До цього вона працювала в Parse, Facebook (META ) та Linden Lab над інфраструктурою та інструментами для розробників, і завжди опинялася на чолі баз даних. Вона є співавтором O’Reilly’s Database Reliability Engineering, і любить свободу слова, вільне програмне забезпечення та односолодовий скотч.

Ви були менеджером виробництва в 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, де ви інструменталізуєте по ходу справи, розгортаєте швидко, а потім дивитеся на свій код у виробництві через призму інструменталізації, яку ви тільки що написали, та питаєте себе: “Чи робить він те, що я очікував, і чи щось інше виглядає… дивним?”

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

Цей тип розробки – той, який включає виробництво у швидкі зворотні зв’язки – (дещо парадоксально) значно швидший, легший і простіший, ніж покладатися на тести та повільніші цикли розгортання. Як тільки розробники спробували працювати в такий спосіб, вони стали знаменито невільними повернутися до старого, повільного способу робити речі.

Що мене надихає в 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, де ви можете намалювати бульбашку навколо всього, що здається дивним або може бути цікавим, і ми обчислюємо всі виміри всередині бульбашки проти зовні, базової лінії, сортуємо та диференціюємо їх. Тому ви такі: “ця бульбашка дивна” і ми негайно кажемо вам: “вона відрізняється в таких-то способах”. Багато відладки полягає в тому, щоб знайти річ, про яку ви турботитеся, але чому ви турботитеся про неї? Коли ви можете негайно визначити, що це відрізняється через запити, що приходять з пристроїв Android, з цим певним ідентифікатором збірки, використовуючи цю мовну упаковку, в цьому регіоні, з цим ідентифікатором застосунку, з великим вантажем… зараз ви, ймовірно, знаєте точно, що не так і чому.

Це не тільки про єдиний тип даних – хоча це є великою частиною цього. Це також про те, як ми без зусиль обробляємо висококардинальні дані, такі як унікальні ідентифікатори, ідентифікатори 购物ного кошика, ідентифікатори застосунків, імена та прізвища, регіони, мови тощо. Попереднє покоління інструментів не може обробляти багаті дані, такі як ці, що є дещо неймовірним, коли ви думаєте про це, оскільки багаті, висококардинальні дані є найбільш цінними та ідентифікуючими даними всіх.

Як покращення спостережуваності перекладається у кращі бізнес-результати?

Це одна з інших великих зрушень від попереднього покоління до нового покоління інструментів спостережуваності. У минулому системи, застосунки та бізнес-дані були всі ізольовані від один одного в різні інструменти. Це абсурдно – кожне цікаве питання, яке ви хочете поставити щодо сучасних систем, має елементи всіх трьох.

Спостережуваність не тільки про помилки, або простої, або викиди. Це про те, щоб забезпечити, що ми працюємо над правильними речами, що наші користувачі мають великий досвід, що ми досягаємо бізнес-результатів, на які ми спрямовані. Це про побудову цінності, а не тільки експлуатацію. Якщо ви не можете бачити, куди ви йдете, ви не можете рухатися дуже швидко та не можете швидко виправляти курс. Чим більше видимості ви маєте щодо того, що ваші користувачі роблять з вашим кодом, тим кращим та сильнішим інженером ви можете бути.

Куди ви бачите майбутнє спостережуваності, особливо щодо розробок AI?

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

Це про те, щоб зв’язати точки між бізнес-результатами та технічними методами.

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

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

Виробники AI роблять багато завищених заяв про те, як вони можуть зрозуміти ваше програмне забезпечення краще, ніж ви, або про те, як вони можуть обробити дані та сказати вашим людям, які дії вони повинні виробляти. З усього, що я бачила, це є дорогим мрією. Помилкові позитиви дуже дорогі. Не існує заміни розуміння ваших систем та ваших даних. AI може допомогти вашим інженерам з цим! Але воно не може замінити ваших інженерів.

Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Honeycomb.