Intercom menghadirkan Obrolan Insinyur

Kami telah memberi tahu Anda semua tentang produk dan fitur kami serta peluncuran yang kami sukai. Sekarang, kami membawa Anda ke belakang layar dan memperkenalkan Anda pada karya orang-orang yang mewujudkannya.

Selama bertahun-tahun, kami telah membahas banyak hal tentang podcast kami. Setiap minggu, kami memberi Anda wawasan tentang dunia manajemen produk, desain, dukungan, dan pemasaran dengan Inside Intercom; jelajahi bagaimana para pemimpin industri menggunakan CX untuk mengembangkan bisnis mereka dengan Scale; dan menunjukkan kepada Anda dunia salah satu pendiri Intercom Des Traynor dan SVP Produk Intercom, Paul Adams, saat mereka berbagi pemikiran terbaru tentang cara membuat produk hebat.

Dan sekarang untuk sesuatu yang sama sekali berbeda. Untuk pertama kalinya, kami merilis Engineer Chats , podcast internal di sini di Intercom tentang semua hal yang berhubungan dengan engineering. Sebelumnya dipandu oleh Jamie Osler, Insinyur Produk Senior di Intercom selama lebih dari tujuh tahun, sekarang tergantung pada Insinyur Sistem Utama Brian Scanlan untuk mengambil tongkat dan melanjutkan obrolan.

Minggu ini, selain Jamie dan Brian, Anda juga akan mendengar dari:

• Mike Stewart, mantan Senior Principal Engineer di Intercom
• Patrick O'Doherty, mantan Insinyur Keamanan Senior di Intercom dan sekarang seorang insinyur di Oso
• Pendiri Interkom, Ciaran Lee
• Meena Polich, Penasihat Senior Intercom yang mendukung R&D

Dari proses disambiguasi dan pemadaman terburuk yang pernah kami alami hingga obsesi kami dengan kecepatan dan bagaimana tim hukum dan teknik dapat bekerja sama dengan lebih baik, Obrolan Insinyur akan memberi Anda gambaran di balik proses teknik di Intercom.

Jika Anda kekurangan waktu, berikut adalah beberapa takeaways cepat:

• Disambiguasi, atau proses mempersempit ruang solusi yang luas di setiap masalah, tidak hanya bagus untuk proyek yang ambigu. Ini dapat digunakan untuk seluruh proses pembangunan di bidang teknik dan bahkan manajemen produk.
• Inti dari algoritma dan sistem adalah model data. Saat menangani desain teknis untuk suatu sistem, pastikan Anda selalu memahami model data terlebih dahulu.
• Otomatisasi dalam infrastruktur dapat menyebabkan kesalahan yang cukup serius. Dan sementara masalah ini tidak menyenangkan bagi siapa pun, Anda dapat menggunakannya untuk mencari titik buta lainnya dan membangun sistem yang lebih kuat.
• Irama operasi default Anda harus dijalankan – penting bagi para pemula untuk tidak berkompromi pada kecepatan. Jika Anda dapat melakukan sesuatu minggu ini alih-alih kuartal berikutnya, lakukanlah.
• Tim hukum tidak ada di sana untuk memperlambat R&D. Prioritas mereka adalah memastikan bahwa, seiring dengan pertumbuhan dan kompleksitas perusahaan, perusahaan terus melakukannya dalam batas-batas hukum.

Jika Anda menikmati diskusi kami, lihat lebih banyak episode podcast kami. Anda dapat mengikuti di iTunes, Spotify atau mengambil umpan RSS di pemutar pilihan Anda. Berikut ini adalah transkrip episode yang diedit dengan ringan.

Liam Geraghty: Hai, dan selamat datang di Inside Intercom. Saya Liam Geraghty. Jika Anda adalah pendengar tetap, Anda akan tahu bahwa kami mewawancarai pembuat dan pelaku dari dunia manajemen produk, desain, startup, dan pemasaran. Kami juga memiliki dua podcast lainnya – Intercom on Product, di mana salah satu pendiri Intercom Des Traynor dan SVP of Product Intercom, Paul Adams, mendiskusikan pemikiran terbaru mereka tentang cara membangun produk yang sukses dalam skala besar dan Scale by Intercom – di mana kami mengeksplorasi bagaimana bisnis mendorong pertumbuhan melalui hubungan pelanggan.

Satu podcast yang Anda pasti tidak tahu kami buat adalah yang disebut sebagai Engineer Chats , dan itu karena podcast internal di Intercom. Acara ini diselenggarakan oleh Jamie Osler, mantan Insinyur Produk Senior di sini. Di setiap episode, Jamie duduk untuk berbicara dengan berbagai orang yang berbeda tentang berbagai topik berbeda yang berkaitan dengan teknik.

Hari ini, kami membawakan Anda jendela sonik ke semua hal rekayasa di Intercom. Kami telah mengambil bagian terbaik dari pertunjukan, dari kisah pemadaman terburuk yang pernah kami alami hingga bagaimana tim hukum dan teknik dapat bekerja sama dengan lebih baik. Pertama, disambiguasi: tindakan atau proses membedakan antara hal-hal yang serupa dan makna untuk membuat makna atau interpretasi lebih jelas atau pasti. Mike Stewart, mantan Insinyur Utama Senior di Intercom, duduk untuk berbicara dengan Jamie pada Oktober 2020 tentang kata itu dan mengapa dia sering menggunakannya di tempat kerja. Ini Jamie.

Disambiguasi sampai ke bawah

Jamie Osler: Sesuatu yang saya lihat Anda lakukan dengan hasil yang luar biasa ketika mendekati proyek yang sedikit kaku dan tidak terdefinisi dengan baik dalam hal apa arti kesuksesan dan cara terbaik untuk mendekatinya adalah apa yang kadang-kadang Anda sebut sebagai disambiguasi. Bisakah Anda memberi tahu kami apa yang Anda maksud ketika Anda mengatakan itu?

Mike Stewart: Ya. Disambiguasi. Itu adalah kata yang tidak pernah saya gunakan sebelum saya datang ke Intercom, dan saya telah menggunakannya begitu banyak sejak saya tiba di sini. Saya mungkin seharusnya menggunakannya di tempat sebelumnya, tetapi itu adalah kata yang bagus. Bahkan bukan hanya untuk proyek-proyek yang tidak jelas atau proyek-proyek yang ambigu. Saya hampir berpikir ini adalah kata kerja yang sangat umum sebagai bagian dari seluruh proses pembangunan kami yang melewati teknik dan menjadi banyak hal yang dilakukan PM untuk mencari tahu.

“Anda memiliki ruang solusi yang luas… ini adalah proses penyelesaiannya berdasarkan bukti dan keputusan serta panggilan”

Jika Anda kembali ke keadaan pra-proyek, jelas kami memiliki tim, mereka memiliki area kepemilikan, dan mereka menemukan peta jalan di sekitar mereka, bukan? Tim bertanggung jawab atas seluruh area pemasaran / keterlibatan / outbound / permukaan kami, dan mereka sendiri yang berhasil di dalamnya. Itu adalah masalah yang ambigu. Proses mencari tahu di mana kita duduk di dalamnya dan semua hal yang bisa kita lakukan dan cara kita bisa melakukannya dan mempersempit – mungkin tidak seratus persen mencari tahu – dan menutup ruang solusi itu untuk mendapatkan solusi yang lebih ketat dan pandangan yang lebih ketat tentang, dalam semua hal yang dapat Anda lakukan dalam ruang keterlibatan, ini adalah yang menurut kami paling penting, yang paling dicari pelanggan, pengembalian investasi tertinggi – itu adalah proses disambiguasi. Anda memiliki ruang solusi yang luas, ambiguitas tentang ke mana Anda harus pergi dalam banyak tempat berbeda yang dapat Anda tuju dalam ruang solusi itu, dan ini adalah proses penyelesaiannya berdasarkan bukti, keputusan, dan panggilan.

Ketika saya memainkannya pada proyek rekayasa, ada hal yang sama beberapa tahap di dalam pipa. Setelah kami memutuskan untuk membangun messenger baru dengan platform publik tempat Anda dapat membuat aplikasi dan menyematkannya di messenger, ada seluruh ruang solusi dari apa artinya, semua bentuk berbeda yang dapat diambil, bagaimana hal itu dapat terwujud, dan bagaimana Anda bisa membangunnya. Disambiguasi hingga Anda mencapai titik di mana ambiguitas yang Anda pikirkan adalah seperti, “Kami tahu kami ingin menyematkan iFrame yang memiliki antarmuka tertentu, pengembang bergerak maju mundur, lalu, bagaimana kami benar-benar mengimplementasikannya, merancang teknologinya, dan menulis kode untuk melakukannya?” Itu adalah level yang lebih diperbesar. Anda masih bekerja melalui ambiguitas di sana. Jadi, saya pikir disambiguasi ada di seluruh proses pengembangan produk.

“Saya hampir menganggap ini sebagai salah satu video alam semesta yang mulai dari zoom hingga ke bumi sebagai titik di galaksi dan hingga skala manusia dan skala mikro”

Jamie Osler: Anda benar-benar mempersempitnya juga. Mungkin Anda bisa memperjelasnya sedikit.

Liam Geraghty: Mike memiliki cara yang bagus untuk memvisualisasikan proses disambiguasi.

Mike Stewart: Ya. Saya hampir menganggap ini sebagai salah satu video alam semesta pada urutan besarnya yang berbeda, mulai dari memperbesar sampai ke bumi sebagai titik di galaksi dan sampai ke skala manusia dan skala mikro. Ada struktur yang menarik di masing-masing level tersebut, dan dengan cara yang sama, saya pikir ada ambiguitas yang menarik di setiap level zoom karena segala sesuatunya semakin jelas.

Tekniknya berbeda ketika Anda, katakanlah, menulis kode dan mencari tahu, "Hei, apa konsep saya dalam kode, dan bagaimana saya harus menyusun kode ini?" versus ketika Anda mencari tahu, "Hei, bagaimana saya harus mendesain ini secara teknis?" dan apa model data dan bagian yang bergerak versus apa solusi versus peta jalan? Saya mengabstraksikannya sangat jauh karena semuanya disambiguasi. Sangat berhati-hati tentang apa yang Anda serang dan pada tingkat zoom berapa adalah prinsip terpenting di kepala saya. Dan di situlah para insinyur secara alami dapat tersedot ke tingkat disambiguasi yang lebih dalam, untuk mencari tahu bagaimana membangun sesuatu, karena itu adalah sesuatu yang seringkali lebih nyaman atau lebih mudah dipecahkan.

Menjadi satu dengan model data

Liam Geraghty: Untuk menghubungkan semua ini dengan contoh nyata, Jamie menyajikan yang satu ini.

Jamie Osler: Ketika kami melihat bagaimana sistem penagihan mengirim data ke Zuora dan bagaimana mencoba untuk memastikan bahwa keadaan disinkronkan antara keduanya, kami harus memiliki pemahaman tentang bagaimana sistem saat ini melakukannya sehingga kami bisa mendapatkan semacam itu disambiguasi dari sistem saat ini dan memecahnya menjadi ide dan prinsip inti dan melihat mana yang relevan di masa depan. Sebagai bagian dari itu, Anda menulis sebuah dokumen yang mengeksplorasi cara kerja pemodelan data rencana tarif Zuora dari waktu ke waktu. Dan saya pikir itu adalah sesuatu yang tidak akan digali banyak orang pada level itu. Apa yang memicu Anda untuk berpikir bahwa itu akan menjadi hal yang berguna untuk dilakukan? Dan kapan Anda tahu kapan harus melakukan investigasi itu, kapan tidak?

Mike Stewart: Ya, tentu saja. Dalam hal tingkat zoom yang kita bicarakan sebelumnya, ini, bagi saya, tepat di tingkat zoom desain teknologi tingkat tinggi itu. Untuk rekap, dalam penagihan, kami berada di titik di mana, “Hei, kami sangat memahami bahwa kami memiliki dua sistem ini. Kami memiliki aplikasi Rails kami sendiri, dan kami memiliki sistem Zuora eksternal ini. Kita tahu bahwa, setidaknya, untuk sebagian besar masa depan, kita akan memiliki dua sistem ini. Kami tidak akan mengubah batasan itu. Kami memiliki banyak hal yang dibangun di atas keduanya, jadi tidak layak untuk pindah. Kita perlu memiliki dua sistem yang sinkron, dan kita harus membuat mereka setuju satu sama lain, dan semua masalah ini yang berasal dari kita yang tidak dapat membuat mereka setuju satu sama lain, kita perlu itu untuk pergi. Kami agak mengerti bahwa itu adalah misinya.

“Anda tidak dapat merancang algoritme yang tidak bergantung pada model data. Dan saya pikir hal yang sama berlaku ketika Anda mulai berbicara tentang sistem dan fitur produk”

Dan kemudian, itu adalah solusi teknis apa cara untuk mencapai itu? Dalam hal teknik, ketika saya berpikir tentang desain teknologi dan fase desain teknologi atau desain sistem tingkat tinggi ini, apa yang hampir selalu saya lakukan adalah pergi ke model. Ada banyak area permukaan yang bisa Anda coba pahami. Ada banyak hal yang penting, seperti, bagaimana struktur kode Anda, apa yang bergerak, dan pekerja apa yang Anda miliki, dan apa yang coba lakukan? Tetapi konsep dasar, konsep inti dalam sistem, hampir selalu sama dengan model data dalam database yang sebenarnya; skema mereka di database Anda atau skema publik di pihak ketiga Anda, atau apa pun itu. Mereka adalah konsep inti dalam model data yang terlibat. Dan beberapa ilmuwan komputer terkenal – saya tidak tahu yang mana – secara pasti menyatakan sentimen bahwa inti dari algoritma adalah model data. Anda tidak dapat merancang algoritma yang tidak bergantung pada model data. Dan saya pikir hal yang sama berlaku ketika Anda mulai berbicara tentang sistem dan fitur produk. Model data adalah dasar dari desain apa pun.

Jadi, dalam situasi ini, hal pertama yang kami lakukan saat tiba di penagihan adalah memahami model data kami sendiri. Karena bagimu dan aku, Jamie, mendarat di sana seperti barat yang liar. Seperti kebanyakan Intercom, kami belum pernah melihat bagian dalamnya, ini adalah perbatasan baru yang berani. Jadi, pertama-tama, kita harus memahami, "Hei, apa semua tabel ini terlibat dalam sistem kita sendiri?" Kami mendapatkan pemahaman itu dengan relatif cepat dengan bantuan tim sebelumnya di San Francisco dan membangun model mental itu.

“Saya tidak pernah nyaman bergerak maju dengan desain teknis kecuali saya sepenuhnya memahami model data”

Kemudian, bagian utama berikutnya yang saya pikir hampir terlambat untuk kita serang adalah, “Mari kita benar-benar memahami model data Zuora, sistem yang sedang kita gali.” Upaya yang Anda bicarakan, saya pikir itu mungkin hanya sekitar satu minggu di mana saya pada dasarnya menyalakan konsol, secara manual menyodok model data di Zuora, mengubah sesuatu, menjalankan beberapa perintah untuk melihat apa yang terjadi, dan menjelajahi semacam gaya kotak hitam untuk memahami model data. Dan pada akhir pemahaman itu, kita dapat mengatakan bahwa, “Hei, ada banyak model. Yang benar-benar penting ada di bawah sini, tepat di daun. Mereka seperti rencana tarif, segmen biaya, atau semacamnya, yang menyimpan isi data.” Dan setelah Anda memahami konsep inti dan model data dengan benar, maka Anda dapat mulai membangun, Anda dapat mulai mendesain sistem. Dan itu terutama benar ketika kita berbicara tentang sistem replikasi seperti ini, yang tugas dasarnya adalah mengacak satu set model data dan menerjemahkannya ke dalam hal yang setara secara semantik di set model data lainnya.

Pertanyaan awal Anda, untuk tidak melupakannya, adalah bagaimana Anda tahu kapan Anda harus melakukannya? Bagi saya, itu adalah hal yang sangat sederhana. Saya tidak pernah nyaman bergerak maju dengan desain teknis kecuali saya sepenuhnya memahami model data. Dan saya akan memberi tahu Anda satu tempat di mana saya terbakar karena tidak mengikuti prinsip itu secara mendalam nanti, datang ke Salesforce, saya memiliki beberapa pemahaman tentang konsep inti dan model data bahwa Salesforce adalah dunia yang besar dan besar. Jadi, ada banyak tekanan waktu. Dan saya tidak memiliki pemahaman yang sama tentang model data seperti yang saya lakukan untuk Zuora. Dan saya pikir hal yang sama berlaku untuk semua orang di tim. Kami tidak mencapai tingkat kedalaman model data yang sama. Dan kami merasakan hasilnya karena kami membangun sesuatu yang bagus, tetapi setahun kemudian, setelah lebih banyak konteks dengan model data ini, kami menyadari, “Hei, kami tidak memahaminya dengan benar untuk pertama kalinya. Kami tidak memetakan dengan benar terjemahan antara Salesforce dan sistem kami sendiri, dan kami memiliki lebih banyak pekerjaan yang harus dilakukan untuk memperbaiki kurangnya pengetahuan tersebut.”

Jamie Osler: Itu sangat berguna. Itu adalah obrolan yang bagus tentang cara Anda mendisambiguasi proyek.

Mike Stewart: Saya harap ini obrolan yang menyenangkan, Jamie, dan saya harap kami mendapatkan konten yang bermanfaat di sini.

Jamie Osler: Konten hastag.

Sisi terang dari pemadaman yang sangat buruk

Liam Geraghty: Awal tahun ini, jika Anda adalah pengguna Facebook, WhatsApp, atau Instagram, Anda pasti akan mengingat pemadaman di bulan Oktober. Itu adalah pemadaman global terpanjang Facebook dalam sejarahnya. Semuanya bermuara pada perubahan konfigurasi yang salah pada akhirnya. Jadi, pemadaman tidak menyenangkan bagi siapa pun. Seseorang yang sangat tidak menyukai mereka adalah Insinyur Sistem Utama Interkom, Brian Scanlan.

Brian Scanlan: Saya benci pemadaman, itulah sebabnya saya mendedikasikan karir saya untuk melawannya.

Liam Geraghty: Brian duduk untuk mengobrol dengan Jamie tentang mereka pada November 2020.

Brian Scanlan: Sebagian alasan mengapa saya menyukai pemadaman, mengapa saya tertarik pada mereka, atau saya menghabiskan waktu saya untuk mereka adalah karena sejauh ini cukup bagus untuk karir saya. Dan itu karena saya memutuskan untuk tertarik padanya, terlibat dalam menjalankannya, memikirkannya, menjadi bagian darinya, dan menindaklanjutinya.

Liam Geraghty: Brian mengingat beberapa pemadaman penting di Intercom.

“Saya ingat ingin sakit di tempat sampah ketika saya menyadari bahwa Elasticsearch kosong. Saya seperti, 'Oh, ini sangat buruk'”

Brian Scanlan: Salah satu pemadaman paling traumatis yang pernah saya alami, meskipun saya sebenarnya tidak ada di sana selama pemadaman, adalah pemadaman Elasticsearch yang hebat pada Januari 2019.

Liam Geraghty: Seseorang yang ada di sana adalah Patrick O'Doherty, seorang insinyur keamanan senior di sini pada saat itu.

Patrick O'Doherty: Saya ingat ingin sakit di tempat sampah ketika saya menyadari bahwa Elasticsearch kosong. Saya seperti, "Oh, ini sangat buruk."

Brian Scanlan: Ini adalah salah satu yang sangat spektakuler. Saya tidak ada di sana karena saya berada di pesta ulang tahun ke-40 saya dengan beberapa teman. Itu seperti Jumat malam. Dan karena kami tidak takut dengan kode pengiriman ke produksi pada hari Jumat, saya menyetujui permintaan tarik untuk menambahkan subnet ke VPC AWS kami pada Jumat malam itu.

Jamie Osler: Di sela-sela minuman?

Brian Scanlan: Tidak, sebenarnya sedang dalam perjalanan. Aku sedang sadar saat itu. Ketika subnet itu dicoba untuk ditambahkan ke jaringan kami di dalam Amazon, otomatisasi yang kami tulis di… Kami menggunakan alat yang disebut Terraform untuk mengelola infrastruktur tingkat rendah kami di dalam AWS, dan kami memiliki banyak modul tim – pikirkan itu sebagai kode yang dapat digunakan kembali yang kami tulis untuk mencoba dan menyederhanakan banyak infrastruktur di dalam AWS dengan semua pengaturan dan hal-hal yang ingin kami terapkan.

“Pada saat itu, ketika konfigurasi diterapkan, itu benar-benar menghancurkan atau membuat jaringan kami offline”

Jadi, otomatisasi ini dengan sangat teliti mengambil deskripsi subnet yang ingin kita tambahkan. Tetapi pada saat aplikasi, API AWS menolaknya karena ada subnet IP yang tumpang tindih, atau lebih tepatnya, subnet yang dikonfigurasi tumpang tindih dengan yang sudah ada. Jadi, pada saat itu, proses aplikasi Terraform menyerah begitu saja. Itu berhenti. Yang, dalam banyak kasus, adalah hal yang benar-benar masuk akal untuk dilakukan. Namun sayangnya, cara kami mengimplementasikan modul Terraform berarti menghapus semua informasi tentang tabel perutean yang ada di subnet dan menambahkannya kembali saat mengonfigurasi semua subnet ini. Jadi, pada dasarnya, itu telah menghapus semua rute, yang merupakan cara jaringan mengetahui cara menuju ke internet dan jaringan lain, yang cukup penting. Jadi, pada saat itu, ketika konfigurasi diterapkan, itu benar-benar menghancurkan atau membuat jaringan kami offline. Itu baru permulaan.

Jamie Osler: Maksud saya, itu buruk, bukan? Itu tidak baik.

Brian Scanlan: Ya. Jadi, itu membuat Intercom sepenuhnya offline. Dan kemudian, butuh beberapa saat untuk sampai ke titik di mana kita bisa memutar kembali. Dengan kita, maksud saya, bukan saya. Saya menikmati minuman saya saat ini. Jadi, tim menemukan cara untuk masuk ke infrastruktur penyediaan Terraform kami dan kembali ke perubahan konfigurasi.

“Mencari tahu apa yang sebenarnya terjadi dan ke mana data itu pergi juga membutuhkan waktu yang sangat lama. Kami berbicara tentang pemadaman delapan jam di sini ”

Namun sayangnya, sementara itu, otomatisasi lain mulai masuk. Kali ini, beberapa otomatisasi yang dimiliki oleh AWS. Kami menggunakan teknologi yang disebut OpsWorks, yang merupakan versi Chef yang dikelola, untuk mengelola host Elasticsearch kami. Itu memiliki fungsi yang disebut penyembuhan otomatis yang kami aktifkan secara default ke dalam konfigurasi tingkat host kami. Dan jika host tidak dapat dihubungi oleh backend OpsWorks, sistem alur kerja OpsWorks akan mencoba memulihkan host yang bersangkutan secara otomatis karena dianggap ada yang tidak beres di sana. OS sedang down, mungkin kehabisan memori – sesuatu yang buruk telah terjadi, jadi mari kita coba dan perbaiki. Jadi, bidang kontrol OpsWorks ini memutuskan untuk memperbaiki seluruh infrastruktur kami dengan mengganti host.

Sayangnya, kami telah menjalankan Elasticsearch dan masih melakukan apa yang dikenal sebagai penyimpanan sementara. Itu penyimpanan berbasis host – kami tidak menggunakan sistem berbasis cloud ajaib yang menyimpan data Anda di beberapa sistem pihak ketiga atau dari sistem di luar host. Itu hanya pada host fisik. Dan jika host fisik dihancurkan, datanya hilang. Jadi, itulah yang terjadi pada setiap host Elasticsearch. Setiap cluster Elasticsearch kehilangan setiap bagian data, yang sangat buruk karena sejumlah besar Intercom dibangun di atas Elasticsearch. Ini bukan penyimpanan data utama. Kami cenderung menulis data ke satu penyimpanan data, seperti, misalnya, DynamoDB untuk pengguna kami, dan kemudian menyalin data tersebut ke Elasticsearch untuk mencari. Dan kami dapat memulihkannya, tetapi proses mendapatkan kembali semua data itu melalui pencadangan dan harus mengatur ulang semua perubahan karena pencadangan kami sebelumnya membutuhkan waktu yang sangat lama. Juga, mencari tahu apa yang sebenarnya terjadi dan ke mana data itu pergi juga membutuhkan waktu yang sangat lama. Kita berbicara tentang pemadaman delapan jam di sini.

“Kami tidak hanya pergi, 'Nah, sekarang kita tahu tentang dua masalah ini, mari kita perbaiki itu.' Kami pergi dan mencari jenis area otomatisasi lain yang dapat menggigit kami dalam situasi yang aneh”

Ini adalah masalah besar karena itu terjadi pada Jumat malam, butuh banyak orang untuk membuat semuanya kembali stabil. Kami agak tahu tentang masalah ini, harus melakukan redrive atau mengisi ulang cluster dan goresan Elasticsearch kami. Kami tidak tahu tentang beberapa bahaya laten dalam otomatisasi kami sendiri dan beberapa otomatisasi di AWS.

Itu menarik karena, menindaklanjuti ini, kami tidak hanya pergi, "Nah, sekarang kita tahu tentang dua masalah ini, mari kita perbaiki." Kami pergi dan mencari area otomatisasi lain yang dapat menggigit kami dalam situasi yang aneh. Jadi, kami akhirnya melakukan banyak hal untuk benar-benar mahir dalam memulihkan klaster Elasticsearch dari status yang berbeda, mampu mengarahkan ulang data pada waktu yang berbeda ke dalam klaster Elasticsearch kami jika kami pernah tertinggal atau memiliki situasi tipe bencana yang serupa. Dan, Anda tahu, secara keseluruhan, kami belajar banyak dari pemadaman yang sangat buruk ini, dan prosesnya sebenarnya cukup bagus setelahnya, apa yang kami pelajari dan bagaimana kami menyebarkan informasi itu.

Patrick O'Doherty: Saya tidak ingat siapa itu, tetapi sekitar satu jam kemudian, seseorang berterima kasih kepada saya karena menyebabkan insiden ini karena mereka seperti, “Wow, Anda benar-benar mengguncang banyak barang dari pohon di sini. Ini akan menjadi respon insiden yang sangat menyenangkan”. Itu pada dasarnya intinya. Itu seperti, “Oh, wow. Kami sedang menggali barang-barang di sini. ” Dan itu adalah. Penggunaan Terraform kami dan kedewasaan umum kami terhadap cara kami menggunakan alat sambil tetap sadar bahwa alat juga dapat merugikan kami. Hormati alat-alat listrik. Seperti infrastruktur, perkakas listrik juga berbahaya. Mereka dapat bergerak cepat dan mengejutkan Anda, dan saya pikir kami belajar pelajaran kami hari itu.

Brian Scanlan: Saya juga mendapat seperti pembicaraan Inside Intercom tentang ini. Juga, saya tidak berada di tempat kejadian karena saya berada di pub untuk ulang tahun saya. Itu bagus. Itu adalah kejadian yang sempurna.

Dengan kecepatan cahaya

Liam Geraghty: Pada bulan Desember 2020, Natal yang saya yakin tidak akan pernah kita lupakan, salah satu pendiri Intercom, Ciaran Lee, bergabung dengan Jamie untuk berbicara tentang kecepatan dan mengapa Ciaran peduli untuk bergerak cepat.

Ciaran Lee: Saya orang yang sangat tidak sabaran. Itu satu hal. Jika saya dapat melakukan sesuatu dengan cepat atau melakukannya dengan lambat, saya pribadi lebih suka melakukannya dengan cepat. Intercom mungkin tampak seperti perusahaan lama yang akan datang dalam 10 tahun, tetapi sejujurnya saya percaya bahwa kami baru saja memulai. Kami memiliki begitu banyak yang harus dilakukan. Kami sangat ambisius. Kita dapat melihat gambaran tentang apa yang kita inginkan, alat serba guna yang dapat digunakan setiap orang dengan bisnis internet untuk berbicara dengan pelanggan mereka. Dan kami hanya menggores permukaan di sana.

Satu hal yang sangat saya sukai dari Stripe, perusahaan keren yang saya cari, adalah posting blog yang bagus oleh Patrick McKenzie di mana dia menjelaskan bahwa mereka mengatur irama operasi default mereka untuk dijalankan. Mereka default untuk bergerak cepat tidak nyaman, selalu bertanya apakah kita bisa melakukan sesuatu lebih cepat minggu ini, bukan enam bulan dari sekarang. Dan saya sangat menyukainya secara pribadi. Sikap seperti itu telah membantu kami dengan sangat baik. Dan saya pikir itu hal yang menyenangkan untuk selalu dipikirkan. Bisakah kamu pergi lebih cepat?

“Ini keren jika kita mencapai ketersediaan seratus persen pada seperempat, tapi mungkin kita harus bertanya pada diri sendiri, 'Hei, apakah kita tidak cukup berisiko?'”

Jamie Osler: Jika Anda membuat tindakan cepat menjadi penting bagi perusahaan Anda, dan itu adalah sesuatu yang Anda lakukan sepanjang waktu, Anda cenderung kurang istirahat.

Ciaran Lee: Ya. Bergerak cepat dan hancurkan barang-barang dalam parameter yang dapat diterima. Tidak apa-apa untuk memiliki pemadaman. Tidak apa-apa untuk memiliki bug – tentu saja, kategori bug tertentu yang ingin Anda miliki lebih sedikit daripada yang lain, tetapi kami memiliki anggaran ketersediaan. Itu keren jika kita mencapai ketersediaan seratus persen pada seperempat, tetapi mungkin kita harus bertanya pada diri sendiri, “Hei, apakah kita tidak cukup berisiko? Bisakah kita mengambil sedikit lebih banyak risiko untuk bergerak lebih cepat?” Anda harus berada pada titik yang disengaja dalam spektrum. Dan yang pasti, kita punya tanggung jawab yang besar. Kami memiliki banyak pelanggan, ratusan ribu orang masuk yang tugasnya menggunakan Kotak Masuk kami, untuk berbicara dengan pelanggan mereka setiap hari. Kita tidak bisa seperti merusak barang-barang mereka dengan bergerak terlalu cepat atau mengubahnya begitu cepat sehingga mereka bahkan tidak tahu cara menggunakannya lagi. Itu salah. Kami memiliki kendala, tetapi dalam kendala itu, kami harus benar-benar bergerak secepat yang kami bisa.

Di mana hukum masuk?

Liam Geraghty: Dan kami bergerak secepat mungkin melalui episode ini. Selanjutnya, Interkom, Penasihat Senior, Meena Polich. Meena berada di tim hukum kami dengan fokus pada produk dan teknik. Pada Januari 2021, Meena dan Jamie membahas bagaimana tim hukum dan teknik dapat bekerja sama.

“Kami di sini seperti berbaris sejajar dengan perusahaan dan semua klien kami untuk mencapai tujuan yang kami tuju secara bertanggung jawab tanpa memperlambat siapa pun”

Meena Polich: Sangat penting bagi kami untuk memahami produk. Bagaimana mungkin kita bisa menasihati perusahaan tentang peraturan apa yang akan berdampak pada kita atau hukum apa yang harus kita ikuti jika kita tidak benar-benar memahami apa yang kita jual? Pada tingkat yang sangat mendasar, dari sudut pandang strategis, kita perlu memahami tidak hanya apa yang kita jual sekarang, tetapi juga apa yang ingin kita jual dan bagaimana kita ingin memposisikan diri dan tumbuh. Dengan cara itu, kita dapat mulai membangun proyeksi hal-hal yang perlu kita perhatikan dari perspektif hukum. Dan hanya memastikan kami berada di sini seperti berbaris sejajar dengan perusahaan dan semua klien kami untuk mencapai tujuan yang kami tuju secara bertanggung jawab tanpa memperlambat siapa pun. Dari pendekatan yang lebih taktis, memahami nilai-nilai perusahaan dan produk sangat membantu untuk bernegosiasi dengan pelanggan dan bahkan vendor. Ini menempatkan saya pada posisi yang jauh lebih baik ketika saya memahami apa yang kami coba lakukan. Dan kemudian, saya dapat menjelaskan kepada vendor kami, "Karena kami mencoba melakukan ini, kami membutuhkan Anda untuk dapat melakukan ini."

Sebaliknya, ketika saya bernegosiasi dengan pelanggan, sering kali, orang-orang di seberang meja adalah pengacara atau agen pengadaan lain, yang sama teknisnya, jika tidak kurang dari saya. Jadi, dapat menjelaskan apa yang dilakukan produk seperti yang dikatakan pengacara, “Dengar, saya tahu apa kekhawatiran Anda dari perspektif manajemen risiko hukum, tetapi inilah cara kerja platform sebenarnya. Inilah cara produk benar-benar bekerja dalam praktiknya. Dan itulah mengapa itu tidak akan menunjukkan risiko yang Anda khawatirkan ini. Itu tidak akan memicu risiko yang Anda khawatirkan.”

“Prioritas pertama saya adalah membantu R&D memahami bahwa saya tidak di sini untuk menggagalkan kemajuan luar biasa yang kami buat”

Jamie Osler: Saya kira ini bekerja dua arah, kan? Jika R&D memiliki pemahaman yang lebih baik tentang jenis tinjauan hukum tingkat tinggi tentang di mana area yang menjadi perhatian mungkin, ini membantu mereka menghindari melakukan hal-hal atau membangun produk yang berisiko atau melanggar undang-undang tersebut secara tidak sengaja.

Meena Polich: Ya, tentu saja. Dan itulah yang paling penting untuk diambil atau coba difokuskan saat membangun hubungan hukum dengan R&D. Prioritas pertama saya adalah membantu R&D memahami bahwa saya tidak di sini untuk menggagalkan kemajuan luar biasa yang kami buat, dan tim saya tidak ada di sini untuk menghentikan kami dari terus pergi ke pasar dengan produk unggulan. Tim kami ada di sini untuk memastikan bahwa, saat kami tumbuh dan semakin sulit untuk mengawasi semua yang dilakukan setiap individu di perusahaan, kami terus melakukannya secara etis dan kami terus melakukannya dalam batas-batas hukum. Dan ketika kami bisa, kami mencoba mengelola risiko itu.

Itulah salah satu alasan mengapa kepatuhan dengan desain sangat penting. Jika kami mengingat persyaratan kepatuhan atau ekspektasi kepatuhan dan kami merancangnya, sering kali, perubahan desain yang kami buat akan menjadi hal-hal yang benar-benar menguntungkan keuntungan kami. Mungkin ada biaya awal dalam hal alokasi sumber daya, tetapi dalam jangka panjang, dan bahkan tidak dalam jangka panjang – dalam banyak kasus, dalam waktu enam bulan hingga satu tahun setelah fitur tersebut dikeluarkan – kita akan melihat manfaat yang luar biasa dalam hal pertumbuhan pendapatan dan jenis prospek yang kami hasilkan serta daya tarik pelanggan karena mereka akan mempercayai kami.

Liam Geraghty: Terima kasih saya kepada Jamie Osler, yang menciptakan Engineer Chats , host baru Brian Scanlan, dan kepada semua tamu hari ini yang dengan baik hati mengizinkan kami menempatkan obrolan internal mereka menjadi eksternal. Jika Anda menikmati pertunjukan hari ini, mengapa tidak memberi kami ulasan atau memberi tahu kami di media sosial. Kami senang melihat dan mendengar apa yang Anda pikirkan. Itu saja untuk hari ini. Kami akan kembali minggu depan dengan episode Inside Intercom lainnya.