Intercom, Mühendis Sohbetleri sunar

Size ürünlerimiz, özellikleri ve bizi heyecanlandıran lansmanları anlattık. Şimdi sizi perde arkasına götürüyoruz ve bunu gerçekleştiren insanların çalışmalarını tanıtıyoruz.

Yıllar boyunca, podcast'lerimizde çok yol kat ettik. Her hafta size Inside Intercom ile ürün yönetimi, tasarım, destek ve pazarlama dünyasına dair bir fikir veriyoruz; sektör liderlerinin Ölçek ile işlerini büyütmek için CX'i nasıl kullandığını keşfedin; ve size Intercom'un kurucu ortağı Des Traynor ve Intercom Ürün Kıdemli Başkan Yardımcısı Paul Adams'ın harika ürünlerin nasıl oluşturulacağına dair en son düşüncelerini paylaştıkları dünyasını gösteriyor.

Ve şimdi tamamen farklı bir şey. Intercom'da mühendislikle ilgili her şey hakkında dahili bir podcast olan Engineer Chats'i ilk kez yayınlıyoruz. Daha önce yedi yılı aşkın bir süredir Intercom'da Kıdemli Ürün Mühendisi olan Jamie Osler'in ev sahipliğinde, artık sopayı almak ve sohbetleri sürdürmek Baş Sistem Mühendisi Brian Scanlan'a kalmış.

Bu hafta Jamie ve Brian'ın yanı sıra şunları da duyacaksınız:

• Mike Stewart, Intercom'da eski Kıdemli Baş Mühendis
• Patrick O'Doherty, Intercom'da eski Kıdemli Güvenlik Mühendisi ve şimdi Oso'da mühendis
• Intercom kurucu ortağı Ciaran Lee
• Intercom'un Ar-Ge'yi destekleyen Kıdemli Danışmanı Meena Polich

Belirsizliği giderme sürecinden ve şimdiye kadar yaşadığımız en kötü kesintiden hız ve hukuk ve mühendislik ekiplerinin birlikte nasıl daha iyi çalışabileceğine olan takıntımıza kadar, Mühendis Sohbetleri size Intercom'daki mühendislik sürecinin arkasına bir göz atacak.

Zamanınız kısıtlıysa, işte birkaç hızlı paket:

• Belirsizliği giderme veya her problemde geniş bir çözüm alanını daraltma süreci, sadece belirsiz projeler için iyi değildir. Mühendislikte ve hatta ürün yönetiminde tüm inşaat süreci için kullanılabilir.
• Algoritmaların ve sistemlerin özü veri modelleridir. Bir sistem için teknik bir tasarımla uğraşırken, her zaman önce veri modellerini anladığınızdan emin olun.
• Altyapıdaki otomasyon oldukça ciddi hatalara yol açabilir. Ve bu sorunlar hiç kimse için eğlenceli olmasa da, diğer kör noktaları aramak ve daha sağlam bir sistem oluşturmak için bunları kullanabilirsiniz.
• Varsayılan çalışma temponuz çalıştırmak olmalıdır - önemli olan startup'ların hızdan ödün vermemesidir. Önümüzdeki çeyrek yerine bu hafta bir şey yapabilirseniz, üzerine atlayın.
• Hukuk ekibi, Ar-Ge'yi yavaşlatmak için orada değil. Önceliği, şirket büyüdükçe ve karmaşıklık arttıkça, bunu yasaların sınırları içinde yapmaya devam etmesini sağlamaktır.

Tartışmamızdan hoşlanıyorsanız, podcast'imizin diğer bölümlerine göz atın. iTunes, Spotify'da takip edebilir veya seçtiğiniz oynatıcıdaki RSS beslemesini alabilirsiniz. Aşağıda bölümün hafifçe düzenlenmiş bir transkripti var.

Liam Geraghty: Merhaba, Inside Intercom'a hoş geldiniz. Ben Liam Geraghty. Düzenli bir dinleyiciyseniz, ürün yönetimi, tasarım, yeni başlayanlar ve pazarlama dünyasından yapımcılar ve uygulayıcılarla röportaj yaptığımızı bileceksiniz. Ayrıca, Intercom'un kurucu ortağı Des Traynor ve Intercom Üründen Sorumlu Kıdemli Başkan Yardımcısı Paul Adams'ın başarılı ürünlerin ölçekli olarak nasıl oluşturulacağına ilişkin en son düşüncelerini tartıştıkları Intercom on Product adlı iki podcast'imiz daha var - Intercom'a Göre Ölçeklendirme - burada işletmelerin nasıl olduğunu keşfediyoruz. müşteri ilişkileri yoluyla büyümeyi yönlendirmek.

Yaptığımızı kesinlikle bilmediğiniz bir podcast, Mühendis Sohbetleri adlı bir podcast'tir ve bunun nedeni, Intercom'da dahili bir podcast olmasıdır. Burada eski bir Kıdemli Ürün Mühendisi olan Jamie Osler tarafından ağırlandı. Her bölümde Jamie, mühendislikle ilgili çeşitli konularda çeşitli farklı insanlarla konuşmak için oturdu.

Bugün size Intercom'da mühendislikle ilgili her şeye sonik bir pencere getiriyoruz. Şimdiye kadar yaşadığımız en kötü kesinti hikayesinden hukuk ve mühendislik ekiplerinin birlikte nasıl daha iyi çalışabileceğine kadar gösteriden en iyi parçaları aldık. İlk olarak, belirsizliği giderme: anlamı veya yorumu daha açık veya kesin hale getirmek için benzer şeyler ve anlamlar arasında ayrım yapma eylemi veya süreci. Intercom'da eski Kıdemli Baş Mühendis olan Mike Stewart, Ekim 2020'de Jamie ile bu kelime ve iş yerinde neden bu kadar çok kullandığı hakkında konuşmak için oturdu. İşte Jamie.

Baştan aşağı anlam ayrımı

Jamie Osler: Biraz belirsiz ve başarının ne anlama geldiği ve ona en iyi nasıl yaklaşılacağı konusunda çok iyi tanımlanmamış bir projeye yaklaşırken harika sonuçlarla yaptığınızı gördüğüm bir şey, bazen belirsizliği giderme olarak adlandırdığınız şeydir. Bunu söylerken ne demek istediğini bize söyler misin?

Mike Stewart: Evet. Belirsizliği giderme. Intercom'a gelmeden önce hiç kullanmadığım bir kelime bu ve buraya geldiğimden beri çok fazla kullandım. Muhtemelen daha önceki yerlerde kullanmalıydım ama çok güzel bir kelime. Sadece yünlü projeler veya belirsiz projeler için bile değil. Neredeyse bunun, mühendisliğin ötesine geçen ve PM'lerin bir şeyleri çözmek için yaptığı birçok şeye giden tüm inşa sürecimizin bir parçası olarak çok genel bir fiil olduğunu düşünüyorum.

“Geniş bir çözüm alanınız var… Kanıtlara, kararlara ve çağrılara dayalı olarak bunu çözme süreci”

Proje öncesi duruma geri dönerseniz, açıkçası ekiplerimiz var, sahiplik alanları var ve etraflarında yol haritaları buluyorlar, değil mi? Ekip, tüm pazarlama / etkileşim / giden / yüzey alanımızdan sorumludur ve bunun içinde başarılı olmanın sahibidir. Bu belirsiz bir problem. Bunun içinde nerede oturduğumuzu ve yapabileceğimiz tüm şeyleri ve bunları nasıl yapabileceğimizi bulma ve daraltma - belki yüzde yüz değil - ve daha sıkı ve daha sıkı hale getirmek için bu çözüm alanını kapatma süreci. Etkileşim alanı içinde yapabileceğiniz tüm şeyler içinde, bunlar en önemli olduğunu düşündüğümüz, müşterilerin en çok aradıkları, en yüksek yatırım getirisi - bu bir belirsizlik giderme sürecidir. Geniş bir çözüm alanınız var, o çözüm alanı içinde gidebileceğiniz birçok farklı yer içinde nereye gitmeniz gerektiği konusunda bir belirsizliğiniz var ve bu, kanıtlara, kararlara ve çağrılara dayalı olarak onu sarma sürecidir.

Bunu bir mühendislik projesinde oynattığımda, birkaç aşamada aynı şey oluyor. Uygulamalar oluşturabileceğiniz ve bunları bir haberciye gömebileceğiniz, halka açık bir platforma sahip yeni bir haberci oluşturmaya karar verdiğimizde, bunun ne anlama geldiğine dair tüm çözüm alanı, alabileceği tüm farklı şekiller, nasıl tezahür edebileceği, ve nasıl inşa edebileceğinizi. Düşündüğünüz belirsizliğin "Belirli bir arayüze sahip bir iFrame yerleştirmek istediğimizi biliyoruz, geliştiriciler ileri geri hareket ediyor ve sonra, nasıl yapacağız?" bunu gerçekten uygula, teknoloji tasarla ve bunu yapmak için kodları yaz?” Bunlar daha da yakınlaştırılmış seviyelerdir. Hala orada belirsizlik üzerinde çalışıyorsunuz. Bu nedenle, belirsizliğin giderilmesinin tüm ürün geliştirme sürecinde olduğunu düşünüyorum.

"Neredeyse bunu, bir galaksideki bir nokta olarak ta dünyaya ve insan ölçeğinde ve mikro ölçekte tüm yol boyunca yakınlaştırmadan dünyaya giden evrenin videolarından biri olarak düşünüyorum."

Jamie Osler: Bunu da gerçekten daralttınız. Belki bunu biraz netleştirebilirsin.

Liam Geraghty: Mike, belirsizliği giderme sürecini görselleştirme konusunda harika bir yola sahip.

Mike Stewart: Evet. Neredeyse bunu, galaksideki bir nokta olarak dünyaya yakınlaştırmaktan, insan ölçeğine ve mikro ölçeğe kadar uzanan, farklı büyüklük derecelerinde evrenin videolarından biri olarak düşünüyorum. Bu seviyelerin her birinde ilginç bir yapı var ve aynı şekilde, her şey daha fazla tanımlandıkça yakınlaştırma seviyelerinin her birinde ilginç bir belirsizlik olduğunu düşünüyorum.

Diyelim ki kod yazarken ve “Hey, koddaki kavramlarım nelerdir ve bu kodu nasıl yapılandırmalıyım?” diye düşünürken teknikler farklıdır. "Hey, bunu nasıl tasarlamalıyım?" ve veri modelleri ve hareketli parçalar nelerdir ve yol haritasına karşı çözüm nedir? Tüm belirsizliği ortadan kaldırdığı için onu çok soyutlıyorum. Neye saldırdığınız ve hangi yakınlaştırma düzeyinde çok dikkatli olmak kafamdaki en önemli ilkedir. Ve bu, mühendislerin çok doğal olarak, bir şeyin nasıl inşa edileceğini bulmanın daha derin yakınlaştırma seviyelerine çekilebildiği yerdir, çünkü bu genellikle daha rahat veya kırılması daha kolay bir şeydir.

Veri modelleri ile bir olmak

Liam Geraghty: Tüm bunları somut bir örnekle ilişkilendirmek için Jamie bunu sunuyor.

Jamie Osler: Faturalama sisteminin Zuora'ya nasıl veri gönderdiğine ve bu durumun ikisi arasında nasıl senkronize edilmesini sağlamaya çalıştığına bakarken, mevcut sistemin bunu nasıl yaptığını anlamamız gerekiyordu, böylece bu tür bir sonuç elde edebildik. mevcut sistemin belirsizliğini ortadan kaldırmak ve onu temel fikir ve ilkelerine ayırmak ve bunlardan hangilerinin ileriye dönük alakalı olduğunu görmek. Bunun bir parçası olarak, Zuora'nın zaman içinde oran planı verileri modellemesinin nasıl çalıştığını araştıran bir belge yazdınız. Ve bence bu, pek çok insanın o seviyede girmeyeceği bir şeydi. Bunun faydalı bir şey olacağını düşünmene ne sebep oldu? Ve bu soruşturmayı ne zaman yapacağını, ne zaman yapmayacağını ne zaman biliyorsun?

Mike Stewart: Evet, kesinlikle. Daha önce bahsettiğimiz yakınlaştırma seviyeleri açısından, bu benim için tam da o yüksek seviyeli, teknoloji tasarımlı yakınlaştırma seviyesinde. Özetlemek gerekirse, faturalandırmada, "Hey, bu iki sisteme sahip olduğumuzu oldukça kesin olarak anlıyoruz. Kendi Rails uygulamamız ve bu harici Zuora sistemimiz var. Biliyoruz ki, en azından geleceğin iyi bir kısmı için bu iki sisteme sahip olacağız. Bu kısıtlamayı değiştirmeyeceğiz. İkisi üzerine çok şey inşa ettik, bu yüzden taşınmak mümkün değil. İki sistemin senkronize olmasına ihtiyacımız var ve onların birbiriyle anlaşmasını sağlamamız gerekiyor ve bizim bu sistemlerin birbiriyle uyumlu olmamasından kaynaklanan tüm bu problemlerin ortadan kalkması gerekiyor. Görevin bu olduğunu anladık.

“Veri modelinden bağımsız bir algoritma geliştiremezsiniz. Sistemler ve ürün özellikleri hakkında konuşmaya başladığınızda da aynı şeyin geçerli olduğunu düşünüyorum”

Ve sonra, bunu başarmanın yolu hangi teknik çözümle ilgiliydi? Teknikler açısından, teknoloji tasarımı ve bu üst düzey teknik tasarım veya sistem tasarımı aşamasını düşündüğümde, neredeyse her zaman yaptığım şey modellere gitmek. Anlamaya çalışabileceğiniz çok fazla yüzey alanı var. Önemli olan pek çok şey var, örneğin, kod yapınız nasıl, etrafta neler dolaşıyor ve hangi çalışanlarınız var ve ne yapmaya çalışıyor? Ancak sistemdeki temel kavramlar, temel kavramlar neredeyse her zaman gerçek veritabanındaki veri modelleriyle aynıdır; veritabanınızdaki şemaları veya üçüncü tarafınızdaki genel şema veya her neyse. Bunlar, dahil olan veri modellerindeki temel kavramlardır. Ve bazı ünlü bilgisayar bilimcisi - hangisi olduğu hakkında hiçbir fikrim yok - kesinlikle algoritmaların özünün veri modelleri olduğu hissini dile getirdi. Veri modelinden bağımsız bir algoritma geliştiremezsiniz. Sistemler ve ürün özellikleri hakkında konuşmaya başladığınızda da aynı şeyin geçerli olduğunu düşünüyorum. Veri modelleri, herhangi bir tasarımın temelidir.

Bu durumda, faturalandırmaya geldiğimizde yaptığımız ilk şey, kendi veri modellerimizi anlamak oldu. Çünkü senin ve benim için Jamie, oraya inmek vahşi batı gibiydi. Intercom'un çoğu gibi, bunun içini hiç görmemiştik, cesur bir yeni sınırdı. O halde, her şeyden önce şunu anlamamız gerekiyordu, "Hey, kendi sistemimize dahil olan tüm bu tablolar ne halt ediyor?" San Francisco'daki önceki ekibin yardımıyla bu anlayışa nispeten hızlı bir şekilde ulaştık ve bu zihinsel modeli oluşturduk.

“Veri modellerini tam olarak anlamadığım sürece teknik bir tasarımla ilerlemekten asla rahat değilim”

Ardından, neredeyse çok geç saldırmaya başladığımızı düşündüğüm eksik olan bir sonraki büyük parça, "Haydi, içine kazdığımız sistem olan Zuora'nın veri modelini gerçekten anlayalım." oldu. Bahsettiğiniz çaba, sanırım temelde konsolu çalıştırdığım, Zuora'daki veri modellerini manuel olarak dürttüğüm, bir şeyi değiştirdiğim, ne olduğunu görmek için bazı komutları çalıştırdığım ve bir tür araştırma yaptığım bir hafta kadardı. veri modelini anlamak için kara kutu stili. Ve bunu anlamanın sonunda şunu söyleyebiliriz, "Hey, bu büyük model yığını var. Gerçekten önemli olanlar burada, tam yaprakta. Verilerin bağırsaklarını depolayan oran planı, ücret segmentleri veya başka bir şey gibiler.” Ve temel kavramları ve veri modellerini doğru bir şekilde anladıktan sonra inşa etmeye başlayabilir, bir sistem tasarlamaya başlayabilirsiniz. Ve bu özellikle, temel işi bir dizi veri modelini güvenilir bir şekilde karıştırmak ve onu başka bir veri modelinde anlamsal olarak eşdeğer şeye çevirmek olan bunun gibi çoğaltma sistemlerinden bahsettiğimizde doğrudur.

Asıl sorunuz, gözden kaçırmamak, bunu ne zaman yapmanız gerektiğini nereden biliyorsunuz? Benim için bu gerçekten basit bir şey. Veri modellerini tam olarak anlamadığım sürece teknik bir tasarımla ilerlemekten asla rahat değilim. Ve size daha sonraları bu prensibi derinlemesine takip etmemekle canımın yandığı bir yeri anlatacağım, Salesforce'a geldiğimde, Salesforce'un büyük, büyük bir dünya olduğu konusunda temel kavramlar ve veri modelleri hakkında biraz bilgi sahibi oldum. Yani zaman baskısı çok fazlaydı. Ve veri modellerini anlamak için Zuora için yaptığımla aynı derinliğe inmedim. Ve bence aynı şey takımdaki herkes için de geçerliydi. Aynı düzeyde veri modeli derinliğine ulaşamadık. Ve bunun sonuçlarını iyi bir şey inşa ettiğimizde hissediyoruz, ancak bir yıl sonra, bu veri modelleriyle daha fazla bağlamdan sonra, "Hey, ilk seferinde onları doğru anlamadık. Salesforce ile kendi sistemimiz arasındaki çeviriyi doğru bir şekilde eşleştiremedik ve bu bilgi eksikliğini gidermek için yapacak daha çok işimiz var.”

Jamie Osler: Bu çok faydalı. Projelerin belirsizliğini giderme yönteminiz hakkında harika bir sohbetti.

Mike Stewart: Umarım harika bir sohbet olmuştur Jamie ve umarım burada faydalı içerikler bulmuşuzdur.

Jamie Osler: Hashtag içeriği.

Şanlı bir şekilde kötü bir kesintinin parlak tarafı

Liam Geraghty: Bu yılın başlarında, Facebook, WhatsApp veya Instagram kullanıcısıysanız, Ekim ayındaki kesintiyi hiç şüphesiz hatırlayacaksınız. Bu, Facebook'un tarihindeki en uzun küresel kesintiydi. Her şey, sonunda hatalı bir yapılandırma değişikliğine geldi. Bu nedenle, kesintiler hiç kimse için eğlenceli değil. Onlardan özellikle hoşlanmayan biri, Intercom Baş Sistem Mühendisi Brian Scanlan'dır.

Brian Scanlan: Kesintilerden nefret ederim, bu yüzden kariyerimi onlarla savaşmaya adadım.

Liam Geraghty: Brian, Kasım 2020'de Jamie ile onlar hakkında sohbet etmek için oturdu.

Brian Scanlan: Kesintileri sevmemin, onlara çekilmemin veya zamanımı bunlara harcamamın bir nedeni, şu ana kadar kariyerim için oldukça iyi olması. Ve bunun nedeni, onunla ilgilenmeye, onları yönetmeye, onları düşünmeye, onların bir parçası olmaya ve onları takip etmeye karar vermemdi.

Liam Geraghty: Brian, Intercom'daki bazı dikkate değer kesintileri hatırladı.

"Elasticsearch'ün boş olduğunu fark ettiğimde bir çöp kutusunda hasta olmak istediğimi hatırlıyorum. 'Ah, bu çok kötü' dedim.

Brian Scanlan: Kesinti sırasında orada olmamama rağmen, dahil olduğum en travmatik kesintilerden biri, Ocak 2019'daki büyük Elasticsearch kesintisiydi.

Liam Geraghty: Orada bulunan biri, o zamanlar burada kıdemli bir güvenlik mühendisi olan Patrick O'Doherty'ydi.

Patrick O'Doherty: Elasticsearch'ün boş olduğunu fark ettiğimde çöp kutusunda hasta olmak istediğimi hatırlıyorum. "Ah, bu çok kötü" dedim.

Brian Scanlan: Bu özellikle muhteşemdi. Orada değildim çünkü 40. doğum günümde bazı arkadaşlarımla içki içiyordum. Cuma akşamı gibiydi. Ve bir Cuma günü kodu üretime göndermekten korkmadığımız için, o Cuma akşamı VPC AWS'mize bir alt ağ ekleyen bir çekme talebini onayladım.

Jamie Osler: İçecekler arasında mı?

Brian Scanlan: Hayır, aslında yoldaydı. O zamanlar ayıktım. Bu alt ağ Amazon içindeki ağımıza eklenmeye çalışıldığında, yazdığımız otomasyon… AWS içindeki düşük seviyeli altyapımızı yönetmek için Terraform adlı bir araç kullanıyoruz ve bir sürü ekip modülümüz vardı – düşünün AWS içindeki bir dizi altyapıyı, uygulanmasını istediğimiz tüm ayarlar ve şeylerle denemek ve basitleştirmek için yazdığımız yeniden kullanılabilir kod olarak.

“O noktada, konfigürasyon uygulandığında, ağımızı tamamen yok etti veya çevrimdışına aldı”

Ve böylece, bu otomasyon, eklenmesini istediğimiz alt ağın açıklamasını çok özenle aldı. Ancak uygulama anında, çakışan bir IP alt ağı olduğu veya daha doğrusu yapılandırılmakta olan alt ağ zaten var olan bir alt ağ ile çakıştığı için AWS'nin API'leri bunu reddetti. Ve bu noktada, Terraform başvuru süreci bir nevi vazgeçti. Durdu. Hangi, bir sürü durumda, yapılacak tamamen makul bir şey. Ancak ne yazık ki, Terraform modülümüzü uygulama şeklimiz, bir alt ağda bulunan yönlendirme tabloları hakkındaki tüm bilgileri kaldırıyor ve tüm bu alt ağları yapılandırırken onları tekrar ekliyordu. Yani, aslında, bir ağın internete ve diğer ağlara nasıl ulaşacağını bilen tüm yolları kaldırmıştı, ki bu oldukça önemli. Yani o noktada konfigürasyon uygulandığında ağımızı tamamen yok etmiş veya devre dışı bırakmıştı. Bu sadece başlangıç.

Jamie Osler: Yani, bu kötü, değil mi? Bu iyi değil.

Brian Scanlan: Evet. Bu, Intercom'u tamamen çevrimdışı duruma getirdi. Ve sonra, geri dönebileceğimiz noktaya gelmemiz biraz zaman aldı. Biz derken, ben değil. Bu sırada içkilerimin tadını çıkarıyordum. Böylece ekip, Terraform tedarik altyapımıza girmenin ve konfigürasyon değişikliğine geri dönmenin bir yolunu buldu.

"Dünyada neler olduğunu ve bu verilerin nereye gittiğini bulmak da çok uzun zaman aldı. Burada sekiz saatlik bir kesintiden bahsediyoruz”

Ama ne yazık ki, bu arada başka bir otomasyon devreye girdi. Bu sefer, AWS'ye ait olan bazı otomasyonlar. Elasticsearch ana bilgisayarlarımızı yönetmek için Chef'in yönetilen bir sürümü olan OpsWorks adlı bu teknolojiyi kullanıyoruz. Ana bilgisayar düzeyindeki yapılandırmamızda varsayılan olarak etkinleştirdiğimiz yerleşik otomatik iyileştirme adlı bu işlevselliğe sahipti. OpsWorks arka ucu ana bilgisayarlarla iletişim kurulamıyorsa, OpsWorks'ün iş akışı sistemi, orada bir şeylerin yanlış gittiğini düşündüğü için söz konusu ana bilgisayarı otomatik olarak iyileştirmeye çalışırdı. İşletim sistemi çöktü, belki hafızası tükendi – kötü bir şey oldu, hadi deneyelim ve düzeltelim. Bu OpsWorks kontrol düzlemi, ana bilgisayarları değiştirerek tüm altyapımızı düzeltmeye karar verdi.

Ne yazık ki, Elasticsearch'ü çalıştırıyorduk ve hala geçici depolama olarak bilinen şeyi yapıyoruz. Bu, ana bilgisayar tabanlı depolamadır - verilerinizi bazı üçüncü taraf sistemlerde veya ana bilgisayar dışındaki bir sistemden depolayan sihirli bir bulut tabanlı sistem kullanmıyoruz. Sadece fiziksel bir ana bilgisayarda. Ve fiziksel ana bilgisayar yok edilirse, veriler gider. Ve böylece, her bir Elasticsearch ana bilgisayarına olan buydu. Her bir Elasticsearch kümesi, her bir veri parçasını kaybetti, bu oldukça kötü çünkü Elasticsearch'ün üzerine çok miktarda Intercom inşa edildi. Birincil veri deposu değil. Kullanıcılarımız için örneğin DynamoDB gibi bir veri deposuna veri yazma ve ardından arama için bu verileri Elasticsearch'e kopyalama eğilimindeyiz. Ve onu geri yükleyebiliriz, ancak tüm bu verileri yedeklemeler yoluyla geri alma ve önceki yedeklemelerimizden bu yana tüm değişiklikleri yeniden yönlendirmek zorunda kalma süreci uzun, uzun, uzun zaman aldı. Ayrıca, dünyada neler olduğunu ve bu verilerin nereye gittiğini anlamak da çok uzun zaman aldı. Burada sekiz saatlik bir kesintiden bahsediyoruz.

“Biz sadece 'Pekala, şimdi bu iki sorunu biliyoruz, hadi bunları düzeltelim' demedik. Gittik ve tuhaf durumlarda bizi ısırabilecek başka tür otomasyon alanları aradık”

Bu büyük bir olaydı çünkü Cuma günü geç saatlerde oldu, işleri eski haline döndürmek için çok sayıda insan gerekti. Elasticsearch kümelerimizi yeniden sürmek veya yeniden doldurmak ve sıfırdan yapmak zorunda olduğumuz için bu sorunları biliyorduk. Kendi otomasyonumuzdaki ve AWS'deki otomasyondaki bazı tehlikelerden haberdar değildik.

Bu ilginçti çünkü bunu takip ederek, "Pekala, şimdi bu iki sorunu biliyoruz, hadi bunları düzeltelim" demedik. Gittik ve tuhaf durumlarda bizi ısırabilecek başka tür otomasyon alanları aradık. Böylece, farklı durumlardan Elasticsearch kümelerini geri yükleyebilmek için gerçekten iyi olmak için pek çok şey yaptık, geride kaldığımızda veya benzer felaket tipi durumlarla karşılaştığımızda farklı zamanlarda verileri Elasticsearch kümelerimize yeniden yönlendirebildik. Ve genel olarak, bu fevkalade kötü kesintiden çok şey öğrendik ve sonraki süreç aslında oldukça iyiydi, öğrendiklerimiz ve bu bilgiyi nasıl yaydığımız.

Patrick O'Doherty: Kim olduğunu hatırlayamıyorum ama yaklaşık bir saat sonra biri bana bu olaya neden olduğum için teşekkür etti çünkü onlar "Vay canına, gerçekten burada ağaçtan çok fazla şey salladın. Bu gerçekten eğlenceli bir olay tepkisi olacak” dedi. Temelde özü buydu. Sanki, "Vay canına. Burada bir şeyler kazıyoruz.” Ve öyleydi. Terraform kullanımımız ve araçların bize zarar verebileceğinin bilincindeyken, araçları nasıl kullandığımıza ilişkin genel olgunluğumuz. Elektrikli aletlere saygı gösterin. Altyapı gibi, elektrikli aletler de tehlikelidir. Hızlı hareket edebilirler ve sizi gafil avlayabilirler ve sanırım o gün dersimizi aldık.

Brian Scanlan: Bunun dışında bir Inside Intercom konuşması da duydum. Ayrıca doğum günümde barda olduğum için olayda ben yoktum. Harikaydı. Mükemmel bir olaydı.

ışık hızında

Liam Geraghty: Aralık 2020'de, asla unutamayacağımız bir Noel, Intercom kurucu ortağı Ciaran Lee hız ve Ciaran'ın neden hızlı hareket etmeyi umursadığı hakkında konuşmak için Jamie'ye katıldı.

Ciaran Lee: Son derece sabırsız bir insanım. Bu bir şey. Bir şeyi hızlı veya yavaş yapabiliyorsam, kişisel olarak hızlı yapmayı tercih ederim. Intercom, 10 yıl sonra ortaya çıkan eski bir şirket gibi görünebilir, ancak dürüst olmak gerekirse, daha yeni başladığımıza inanıyorum. Yapacak çok işimiz var. Çok iddialıyız. Nasıl olmak istediğimizin bir resmini görebiliriz, internet işi olan herkesin müşterileriyle konuşmak için kullanabileceği bu hepsi bir arada araç. Ve biz orada sadece yüzeyi çiziyoruz.

Aradığım havalı bir şirket olan Stripe'den gerçekten sevdiğim bir şey, Patrick McKenzie'nin varsayılan işletim kadanslarını çalışacak şekilde ayarladıklarını açıkladığı harika bir blog yazısıydı. Rahatsız edici derecede hızlı hareket etmeyi varsayılan olarak yapıyorlar ve her zaman altı ay yerine bu hafta daha hızlı yapıp yapamayacağımızı soruyorlar. Ve ben şahsen bundan gerçekten hoşlanıyorum. Bu tür bir tutum bize gerçekten çok iyi hizmet etti. Ve bence her zaman düşünmek eğlenceli bir şey. Daha hızlı gidebilir misin?

"Bir çeyrekte yüzde yüz kullanılabilirliğe ulaşırsak güzel, ama belki de kendimize 'Hey, yeterince riskli değil miyiz?' diye sormalıyız."

Jamie Osler: Hızlı gitmeyi şirketiniz için kritik hale getirirseniz ve bu her zaman yaptığınız bir şeyse, daha az kırılma eğiliminde olursunuz.

Ciaran Lee: Evet. Hızlı hareket edin ve işleri kabul edilebilir parametreler dahilinde kırın. Kesintiler olması sorun değil. Hataların olması sorun değil - açıkçası, diğerlerinden daha az olmasını istediğiniz belirli hata kategorileri, ancak kullanılabilirlik bütçelerimiz var. Çeyrekte yüzde yüz kullanılabilirliğe ulaşırsak güzel olur ama belki de kendimize şunu sormalıyız, “Hey, yeterince riskli değil miyiz? Daha hızlı hareket etmek için biraz daha risk alabilir miyiz?” Spektrumun bilinçli bir noktasında olmalısınız. Ve elbette büyük bir sorumluluğumuz var. Çok sayıda müşterimiz var, işi Gelen Kutumuzu kullanmak olan, her gün müşterileriyle konuşmak olan yüz binlerce insan giriş yapıyor. Eşyalarını çok hızlı hareket ederek kırmak ya da artık kullanmayı bilemeyecekleri kadar hızlı değiştirmek gibi olamayız. Bu yanlış olur. Kısıtlamalarımız var, ancak bu kısıtlamalar içinde kesinlikle olabildiğince hızlı hareket etmeliyiz.

Hukukun devreye girdiği yer

Liam Geraghty: Ve bu bölümde olabildiğince hızlı ilerliyoruz. Sıradaki, Intercom, Kıdemli Danışman, Meena Polich. Meena, ürün ve mühendislik odaklı hukuk ekibimizdedir. Ocak 2021'de Meena ve Jamie, hukuk ve mühendislik ekiplerinin birlikte nasıl çalışabileceğini tartıştı.

“Kimseyi yavaşlatmadan sorumlu bir şekilde gitmemiz gereken yere ulaşmak için şirket ve tüm müşterilerimizle birlikte adım adım yürüyoruz”

Meena Polich: Ürünü anlamak bizim için gerçekten önemli. Ne sattığımızı gerçekten anlamazsak, hangi düzenlemelerin bizi etkileyeceği veya hangi yasalara uymamız gerektiği konusunda şirkete nasıl danışmanlık yapabiliriz? Çok temel bir düzeyde, stratejik bir bakış açısından, sadece şimdi ne sattığımızı değil, aynı zamanda ne satmak istediğimizi ve kendimizi nasıl konumlandırmak ve büyümek istediğimizi de anlamamız gerekiyor. Bu şekilde, yasal bir perspektiften göz kulak olmamız gereken şeylerin projeksiyonlarını oluşturmaya başlayabiliriz. Ve sadece, kimseyi yavaşlatmadan sorumlu bir şekilde gitmemiz gereken yere ulaşmak için şirket ve tüm müşterilerimizle birlikte burada olduğumuzdan emin olmak. Daha taktik bir yaklaşımla, şirket değerlerini ve ürününü anlamak, müşterilerle ve hatta satıcılarla pazarlık yapmak için son derece yararlıdır. Ne yapmaya çalıştığımızı anladığımda beni çok daha iyi bir konuma getiriyor. Daha sonra bayilerimize "Bunu yapmaya çalıştığımız için, bunu yapabilmeniz için size ihtiyacımız var" diye açıklayabilirim.

Tersine, müşterilerle müzakere ederken, çoğu zaman, masanın diğer tarafındaki insanlar, benden daha az olmasa da teknik olan diğer avukatlar veya satın alma acenteleridir. Ve böylece, avukat olarak ürünün ne yaptığını açıklayabilmek, "Bak, yasal risk yönetimi perspektifinden endişelerinizin ne olduğunu biliyorum, ancak işte platform gerçekte nasıl çalışıyor. Ürünün pratikte gerçekte nasıl çalıştığı aşağıda açıklanmıştır. İşte bu yüzden endişelendiğiniz bu riski ortadan kaldırmayacaktır. Endişe ettiğiniz riski tetiklemeyecek. ”

“Birinci önceliğim, Ar-Ge'nin, kaydettiğimiz inanılmaz ilerlemeyi raydan çıkarmak için burada olmadığımı anlamasına yardımcı olmaktır”

Jamie Osler: Sanırım bu her iki şekilde de işe yarıyor, değil mi? Ar-Ge, ilgili alanların nerede olabileceğine ilişkin üst düzey yasal genel bakışın türünü daha iyi anlıyorsa, istemeden riskli olabilecek veya bu yasaları ihlal edecek şeyler yapmaktan veya ürünler inşa etmekten kaçınmalarına yardımcı olur.

Meena Polich: Evet, kesinlikle. Ar-Ge ile hukuki ilişki kurarken de en çok alınması gereken veya üzerinde durulmaya çalışılan şey budur. İlk önceliğim, Ar-Ge'ye, kaydettiğimiz inanılmaz ilerlemeyi raydan çıkarmak için burada olmadığımı ve ekibim, mükemmel ürünlerle pazara gitmeye devam etmemizi engellemek için burada olmadığımı anlamasına yardımcı olmaktır. Ekibimiz, büyüdükçe ve şirketteki her bireyin yaptığı her şeyi takip etmek zorlaştıkça, bunu etik olarak yapmaya devam ettiğimizden ve bunu yasaların sınırları içinde yapmaya devam ettiğimizden emin olmak için burada. Ve yapabildiğimizde, bu riski yönetmeye çalışıyoruz.

Tasarıma uyumun bu kadar önemli olmasının nedenlerinden biri de budur. Uyumluluk gerekliliklerini veya uyumluluk beklentilerini göz önünde bulundurursak ve bunlara yönelik tasarımlar yaparsak, çoğu zaman yaptığımız tasarım değişiklikleri kârlılığımıza gerçekten fayda sağlayacak şeyler olacaktır. Kaynak tahsisi açısından bir başlangıç ​​maliyeti olabilir, ancak uzun vadede ve hatta süper uzun vadede bile değil – çoğu durumda, bu özelliğin çıkarılmasından sonraki altı ay ila bir yıl içinde – inanılmaz bir fayda göreceğiz. Gelir artışı ve yarattığımız olası satış türleri ve bize güvenecekleri için müşterilerin ilgisini çekme açısından.

Liam Geraghty: Engineer Chats'i yaratan Jamie Osler'a, yeni ev sahibi Brian Scanlan'a ve dahili sohbetlerini harici olarak yapmamıza izin veren tüm konuklara teşekkür ederim. Bugünkü gösteriyi beğendiyseniz, neden bize bir inceleme bırakmıyorsunuz ya da sosyal medyada bizi alkışlamayasınız. Ne düşündüğünüzü görmeyi ve duymayı seviyoruz. Bugünlük bu kadar. Önümüzdeki hafta Inside Intercom'un başka bir bölümüyle geri döneceğiz.