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 був попередником свого часу – ми використовували мікросервіси до того, як вони стали популярними, у нас була сильно шардована шар даних, і як платформа, що обслуговує понад мільйон мобільних додатків, у нас були дуже складні проблеми багатокористувальності. Нашими клієнтами були розробники, і вони постійно писали та завантажували довільні кодові фрагменти та нові запити, які мали, скажімо, “різну якість” – і нам просто доводилося все це приймати та робити так, щоб все працювало.

Для читачів, які незнайомі, що саме таке спостережуваність платформи та як вона відрізняється від традиційного моніторингу та метрик?

Традиційний моніторинг відомий трьома стовпами: метрики, журнали та траси. Зазвичай вам потрібно купувати багато інструментів, щоб задовольнити свої потреби: журналювання, трасування, APM, RUM, панелі моніторингу, візуалізація тощо. Кожен з них оптимізований для певного випадку використання у певному форматі. Як інженер, ви сидите посередині цих інструментів, намагаючись зрозуміти все це.

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

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

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

Наші інженери багато використовують штучний інтелект внутрішньо, особливо CoPilot. Наші молодші інженери повідомляють, що вони використовують ChatGPT щодня, щоб відповісти на питання та допомогти їм зрозуміти програмне забезпечення, яке вони будують. Наші старші інженери кажуть, що це великий інструмент для генерації програмного забезпечення, яке було б дуже трудомістким або нудним для написання, наприклад, коли у вас є великий файл YAML, який потрібно заповнити. Це також корисно для генерації фрагментів коду мовами, які ви не зазвичай використовуєте, або з документації API.

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

Так, звичайно. Наш помічник запитів – це великий приклад. Використання інструментів для побудови запитів складне і важке, навіть для досвідчених користувачів. Якщо у вас є сотні або тисячі вимірів у вашій телеметрії, ви не завжди можете nhớти, які з них найцінніші. І навіть досвідчені користувачі забувають деталі того, як генерувати певні типи графіків.

Чи можете ви розповісти про те, як інтеграція журналів, метрик та трас у єдиний тип даних допомагає у швидшому вирішенні інцидентів?

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

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

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

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

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