Charity Majors, Honeycomb’un CTO’su ve Kurucu Ortağı – Röportaj Serisi

Charity, Honeycomb’da Honeycomb‘da kazanılan deneyimlere sahip bir operasyon mühendisi ve kazara startup kurucusudur. Daha önce Parse, Facebook (META ) ve Linden Lab’de altyapı ve geliştirici araçları üzerinde çalışmış ve her zaman veritabanlarını yönetmekle ilgilenmiştir. O’Reilly’nin Database Reliability Engineering kitabının ortak yazarıdır ve özgür konuşma, özgür yazılım ve tek malt viskiden hoşlanmaktadır.

Facebook’ta (Şimdi Meta) 2 yıldan fazla bir süredir Üretim Mühendisliği Müdürü olarak çalıştınız, bu dönemden bazı vurgularınız nelerdi ve bu deneyimden elde ettiğiniz bazı ana çıkarımlar nelerdir?

Parse üzerinde çalıştım, bu, mobil uygulamalar için bir arka uçtu, Heroku’nun mobil uygulamalar için olanı gibi. Büyük bir şirketde çalışmakla hiç ilgilenmedim, ancak Facebook tarafından satın alındık. Diğer kuruculara verdiğim tavsiyelerden biri, satın alınacak olursanız, bir yönetici sponsorunuz olsun ve stratejik uyumu düşünün. Facebook, Instagram’ı satın aldı, Parse’i satın almadan önce ve Instagram satın alma işlemi nispeten başarılıydı, çünkü stratejik uyuma sahiptiler ve güçlü bir sponsora sahiptiler.

Facebook’ta kolay bir zaman geçirmedim, ancak orada geçirdiğim süreye çok memnunum; öğrenmek zorunda olduğum organizasyonel yapı, yönetim, strateji vb. dersleri aldım. Ayrıca bana, VCs’nin ilgisini çekecek bir pedigree verdi, none of whom had given me the time of day until that point. I’m a little cranky about this, but I’ll still take it.

Honeycomb’u başlatma hikayesini paylaşabilir misiniz?

Kesinlikle. Mimariden bakıldığında, Parse zamanından önceydi – mikro hizmetleri kullanıyorduk, büyük bir şekilde paylaşılan veri katmanına sahiptik ve bir platform olarak bir milyondan fazla mobil uygulamaya hizmet veriyorduk, çok karmaşık çoklu kiracılık sorunları vardı. Müşterilerimiz geliştiricilerdi ve sürekli olarak yazıp yeni kod parçacıkları ve sorgular yüklemekteler, deyim yerindeyse “değişken kalite” – ve biz sadece hepsini kabul etmek ve çalışır halde tutmak zorundaydık.

Birçok değişikliğin öncüsüydük. Mimariler genellikle çok basittir ve öngörülebilir şekillerde tekrar tekrar başarısız olurlar. Genellikle bir web katmanı, bir uygulama ve bir veritabanına sahip olursunuz ve çoğu karmaşıklık uygulamanızın kodunda bağlanmıştır. Bu nedenle, bu başarısızlıkları izlemek için izleme kontrolleri yazarsınız ve metrics ve izleme verileriniz için statik paneller oluşturursunuz.

Son 10 yılda endüstri, mimari karmaşıklığında bir patlama gördü. Monolitleri patlattık, şimdi birkaç hizmetten binlerce uygulama mikro hizmetine sahip olabilirsiniz. Çok dilli dayanıklılık normaldir; artık “veritabanı” değil, birçok farklı depolama türüne ve ayrıca yatay bölünme, önbellek katmanları, db-mikro hizmet, kuyruklama ve daha fazlasına sahip olursunuz. Bunun üzerine sunucu tarafında barındırılan konteynırlar, üçüncü taraf hizmetleri ve platformlar, sunucusuz kod, blok depolama ve daha fazlasını eklersiniz.

Önceki zorluk, kodunuzu hatalarını bulmaktı; şimdi zor olan, kodunuzu nerede hatalarını bulacağınızı bilmektir. Artık her sayfalandığınızda, her seferinde farklı bir şey olduğu ve belki de bir daha asla görmeyeceğiniz bir şey olduğu daha olasıdır.

Bu, Parse’de ve Facebook’ta olduğumuz durumdu. Her gün tüm platform çöküyordu ve her seferinde farklı bir şeydi; bir uygulama iTunes’ta ilk 10’a çıkıyordu, bir geliştirici kötü bir sorgu yüklemişti.

Bu sorunları sıfırdan debug etmek delice zor. Günlükler ve metriklere sahip olduğunuzda,基本 olarak ne aradığınızı bilmeden bulamazsınız. Ancak bazı veri kümelerini Facebook’taki Scuba adlı bir araçla beslemeye başladığımızda, bu sorunları sıfırdan tanımlamak ve çözmek için harcanan zaman, saatlerden dakika veya saniyelere düştü. Artık bir mühendislik problemi değildi, bir destek problemiydi. Sadece her zaman cevaba giden ekmeğin izini takip edebilirsiniz.

Bu akıl almaz bir şeydi. Bu büyük belirsizlik ve emek kaynağı, mutsuz müşteriler ve 2 am pages just … gitti. Facebook’tan ayrıldığımız zaman, sadece yazılımla nasıl etkileşimde bulunduğumuzun ne kadar değiştiğini fark ettik.

Ama o zaman, gerçekten bu bir niş çözüm olacağını düşündük – ki bu, diğer büyük çoklu kiracı platformlarının karşılaşabileceği bir soruyu çözdü. Ancak neredeyse bir yıl boyunca inşa ettikten sonra, oh wow, bu aslında herkesin sorunu haline geliyor.

Okuyucuların tanımadığı için, bir gözlemleme platformunun ne olduğunu ve geleneksel izleme ve metriklere nasıl farklılaştığını açıklayabilir misiniz?

Geleneksel izleme famously üç sütuna sahiptir: metriklere, günlüklere ve izlere. Genellikle birçok aracı satın almanız gerekir: günlük, izleme, APM, RUM, paneller, görselleştirme vb. Her biri farklı bir kullanım durumu için optimize edilmiştir. Bir mühendis olarak, bu araçların ortasında anlamaya çalışırsınız. Panellerde görsel desenleri ararsınız, günlüklerden izlere ve geri ID’leri kopyalar ve yapıştırmaya çalışırsınız. Bu çok tepkiseldir ve parça parçadır ve genellikle bu araçlara bir problem olduğunda başvurursunuz – bunlar kodunuzu çalıştırmanıza ve hataları bulmanıza yardımcı olmak için tasarlanmıştır.

Modern gözlemleme, tek bir gerçeklik kaynağına sahiptir; keyfi genişlikte yapılandırılmış günlük olayları. Bu olaylardan metriklere, panellere ve günlüklere ulaşabilirsiniz. Zamana göre görselleştirebilir, bir iz olarak zoomlayabilir ve bireysel isteklere zoomlayabilirsiniz. Her şey bağlantılı olduğu için, aracın arasında atlamanıza gerek yoktur, tahmin etmenize veya sezginize güvenmenize gerek yoktur. Modern gözlemleme, sadece sistemlerinizi çalıştırmanızla ilgili değil, aynı zamanda kodunuzu geliştirmenizle ilgilidir. Bu, güçlü, sıkı geri bildirim döngülerini oluşturmanıza olanak tanıyan bir alt yapıdır, böylece kullanıcılarınıza hızla, güvenle ve sorunları kullanıcılarınızdan önce bulmanıza yardımcı olur.

Gözlemlemenin mühendislik ortamlarında tek bir gerçeklik kaynağı sunduğuna inanıyorsunuz. Bu vizyona AI nasıl entegre edilir ve bu bağlamda faydaları ve zorlukları nelerdir?

Gözlemleme, gözlerinizi yola çıkmadan önce takmanız gibidir. Test-driven development (TDD) 2000’lerin başlarında yazılımları devrimleştirdi, ancak TDD, sistemlerimizdeki karmaşıklık arttıkça yazılımımızdaki değil, etkinliğini kaybetmeye başladı. Artık TDD’nin faydalarını elde etmek istiyorsanız, aslında kodu enstrümantasyon yaparak ve üretim sırasında gözlemleme yaparak gözlemleme sürüklenen geliştirme (ODD) yapmanız gerekir, burada kodu enstrümantasyon yaparak hızlıca dağıtırsınız ve sonra üretimdeki kodu enstrümantasyonunuzun merceğinden bakarak “beklediğim gibi yapıyor mu ve başka bir şey garip görünüyor mu?” diye sorarsınız.

Testler alone, kodunuzun yapması gereken şeyi yaptığını doğrulamak için yeterli değildir. Bunu ancak üretim ortamında, gerçek kullanıcılarla ve gerçek altyapıyla izleyerek öğrenebilirsiniz.

Bu tür bir geliştirme – üretim hızlı geri bildirim döngülerini içeren – aslında testlere ve daha yavaş dağıtım döngülerine güvenmekten çok daha hızlı, kolay ve basittir. Bir kez geliştiriciler bu şekilde çalıştıktan sonra, eski yavaş yolu yapmaya isteksiz olurlar.

AI beni heyecanlandırıyor, çünkü LLM’lerle geliştirme yaptığınızda, üretimde geliştirme yapmanız gerekir. Kodunuzu üretimde doğrulayarak ve geriye doğru çalışarak testler oluşturabilirsiniz. LLM’lerle desteklenen yazılımların, birkaç yıl içinde MySQL veya Postgres ile desteklenen yazılımlarla aynı ortak bir beceri olacağını düşünüyorum ve umuyorum ki bu, mühendisleri daha iyi bir yaşam tarzına sürükleyecektir.

AI devrimi nedeniyle artan teknik borcunuzla ilgili endişeler dile getirdiniz. AI’nin getirebileceği teknik borç türlerini ve Honeycomb’un bu borçları yönetmede veya hafifletmede nasıl yardımcı olabileceğini açıklar mısınız?

Hem teknik borcu hem de belki daha da önemli olan organizasyonel borcu endişe verici buluyorum. En kötü teknik borç türlerinden biri, kimsenin anlamadığı yazılımdır. Bu, yazılımla çalışmak, uzatmak, hataları düzeltmek veya-debug etmek zorunda olduğunuz anlamına gelir, çünkü kimse onu anlamaz.

Ve eğer kimsenin anlamadığı kodu üretime koyarsanız, gelecekteki teknik sorunların devasa bir buzdağının altına giriyorsunuz. İyi kod, okunması ve anlaşılması kolay olarak yazılır. Kuralları, kalıpları, tutarlı isimlendirmeyi ve modülleştirmeyi kullanır. Kodun kalitesi, insanlarla etkileşime girmesinin ne kadar kolay olduğuyla ayrılmaz bir şekilde bağlantılıdır. Kodu anlaşılmaz olarak yazarsanız, kodunuzu anlamak için çok çalışmanız gerekir.

Eğer kimsenin anlamadığı kodu üretime koyarsanız, Honeycomb yardımcı olamaz. Ancak temiz, yinelemeli yazılım göndermekle ilgileniyorsanız, enstrümantasyon ve gözlemleme bu çaba için mutlak olarak gereklidir. Enstrümantasyon, belgelendirme artı gerçek zamanlı durum raporlamasıdır. Enstrümantasyon, yazılımlarınızın beklediğiniz gibi davrandığını ve kullanıcılarınızın beklediği gibi davrandığını gerçekten doğrulamanın tek yoludur.

Honeycomb, AI’yi mühendislik ekiplerinin verimliliğini ve etkinliğini artırmak için nasıl kullanıyor?

Mühendislerimiz AI’yi içerde çok kullanıyor, özellikle CoPilot. Daha junior mühendislerimiz, her gün soruları cevaplamak ve yazılımları anlamalarına yardımcı olmak için ChatGPT’yi kullanıyor. Daha senior mühendislerimiz, çok sıkıcı veya can sıkıcı yazılması gereken yazılımları üretmek için harika olduğunu söylüyor, örneğin büyük bir YAML dosyasını doldurmak gibi. Ayrıca, genellikle kullanmadığınız dillerde veya API belgelerinden kod parçacıkları oluşturmak için faydalıdır.

Ancak AI’nin kod üretmesine izin verdiğiniz her seferinde, satır satır olarak doğrulamak zorundasınız, çünkü AI kesinlikle düzenli olarak saçmalık üretecektir.

AI destekli özelliklerinizin, örneğin sorgu asistanınızın veya Slack entegrasyonunuzun, takım işbirliğini nasıl geliştirdiğini örneklerle açıklayabilir misiniz?

Evet, tabii ki. Sorgu asistanımız harika bir örnektir. Sorgu oluşturucuları kullanmak karmaşıktır ve zor, hatta güçlü kullanıcılar için bile. Yüzlerce veya binlerce boyutunuz varsa, en değerli olanların adlarını her zaman hatırlayamazsınız. Ve güçlü kullanıcılar bile belirli grafik türlerini oluşturmanın ayrıntılarını unutabilir.

Bu nedenle sorgu asistanımız, doğal dil kullanarak sorularınızı sormanıza olanak tanır. Örneğin, “en yavaş uç noktalar nelerdir?” veya “son dağıtımdan sonra ne oldu?” ve bir sorgu oluşturur ve size bırakır. Most people find it difficult to compose a new query from scratch and easy to tweak an existing one, so it gives you a leg up.

Honeycomb, olayların daha hızlı çözülmesini vaat ediyor. Günlüklerin, metriklere ve izlerin birleşik bir veri türüne entegrasyonunun, daha hızlı hata ayıklama ve sorun çözümü nasıl yardımcı olduğunu açıklayabilir misiniz?

Her şey bağlantılıdır. Tahmin etmeye gerek yoktur. Panellerin aynı şekil olduğunu veya metriklere ve günlüklere dayalı zaman damgalarına göre spike’lerin aynı olduğunu tahmin etmek yerine, veri bağlantılıdır. Tahmin etmenize gerek yoktur, sadece sorabilirsiniz.

Veri, bağlam tarafından değerli hale getirilir. Son jenerasyon araçlar, yazma zamanında tüm bağlamı uzaklaştırmak için çalışır; bir kez bağlamı attığınızda, onu geri alamazsınız.

Ayrıca, günlüklerle ve metriklere sahip olduğunuzda, ne aradığınızı bilmeden bulamazsınız. Modern gözlemleme için bu doğru değildir. Hiçbir şey bilmenize gerek yoktur, aramanıza gerek yoktur.

Zengin bağlamsal verileri depoladığınızda, bunlarla mucizeler gibi şeyler yapabilirsiniz. BubbleUp adlı bir aracımız var, herhangi bir şeyi garip veya ilginç bulduğunuzda bir balon çizebilir ve biz, balon içindeki boyutları dışındaki boyutlarla, baz çizgisiyle, sıralayabilir ve farklılaştırabiliriz. Böylece, “bu balon garip” diyorsunuz ve biz size, “şu şekillerde farklı” diyoruz. Debugging’in çok büyük bir kısmı, “şu şey ilgimi çekiyor, ama neden?” sorusuna cevap vermeye geliyor. Bir Android cihazı, belirli bir derleme kimliği, belirli bir dil paketi, belirli bir bölge, belirli bir uygulama kimliği ve büyük bir yük ile gelen istekler nedeniyle farklı olduğunu anlarsınız.

Sadece birleşik veri değil, aynı zamanda yüksek kardinalite verilerini nasıl kolayca işlediğimiz de önemlidir, örneğin benzersiz kimlikler, alışveriş sepeti kimlikleri, uygulama kimlikleri, ilk/son isimler vb. Son jenerasyon araçlar, bu zengin verileri işleyemez, bu gerçekten inanılmaz, çünkü zengin, yüksek kardinalite verileri en değerli ve tanımlayıcı verilerdir.

Gözlemlemenin geliştirilmesi, daha iyi iş sonuçlarına nasıl yansır?

Bu, önceki jenerasyondan yeni jenerasyona gözlemleme araçlarına geçişin diğer büyük değişikliklerinden biridir. Geçmişte, sistemler, uygulamalar ve iş verileri farklı araçlara ayrılmıştı. Bu saçmadır – modern sistemler hakkında sormak istediğiniz her ilginç soru, hepsinin öğelerini içerir.

Gözlemleme, sadece hatalar, down time, veya outages ile ilgili değil. Doğru şeylerle çalıştığınızı, kullanıcılarınızın iyi bir deneyim yaşadığını, iş hedeflerinize ulaştığınızı sağlamakla ilgili. Değer oluşturmakla ilgili, sadece işletmekle değil. Nereye gidiyorsanız göremezseniz, hızlı hareket edemezsiniz ve rotanızı nhanh chóng düzeltmeniz mümkün değildir. Kullanıcılarınızın yazılımlarınızla ne yaptığını görebileceğiniz kadar çok görünürlükiniz varsa, mühendis olarak daha iyi ve daha güçlü olursunuz.

Gözlemlemenin geleceğini, özellikle AI gelişmeleri açısından, nereye gittiğini düşünüyorsunuz?

Gözlemleme, ekiplerin sıkı, hızlı geri bildirim döngülerini oluşturmasına olanak tanır, böylece üretimde, güvenle ve hızlıca geliştirebilir, zaman ve enerji harcamazsınız.

İş sonuçları ve teknolojik yöntemler arasındaki noktaları bağlamakla ilgili.

Ve yazılımla世界daki anlayış ve yönetilebilirlik standartlarına ourselves hesabına tutmakla ilgili.

Gözlemleme açısından, veri işlem hattında daha sofistike seviyelerde görüleceğiz – makine öğrenimi ve gelişmiş örnekleme tekniklerini kullanarak, değerli ile maliyet arasında denge kurmak, önemli olaylar ve önemli olaylar için mümkün olduğunca fazla ayrıntı saklamak ve geri kalanının özetlerini ucuz bir şekilde depolamak.

AI satıcıları, yazılımlarınızı sizden daha iyi anladıkları veya verilerinizi işleyerek insanların hangi eylemleri yapması gerektiğini söyleyebilecekleri konusunda çok fazla iddia ediyorlar. Gördüğüm her şey, bu iddiaların pahalı bir hayal olduğunu gösteriyor. Yanlış pozitifler çok pahalıdır. Sistemlerinizi ve verilerinizi anlamanın yerine geçebilecek bir şey yoktur. AI, mühendislerinize yardımcı olabilir! Ancak mühendislerinizi değiştiremez.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular Honeycomb‘u ziyaret edebilir.