Domofon prezentuje czaty inżyniera

Opowiedzieliśmy Ci wszystko o naszych produktach i funkcjach oraz premierach, którymi jesteśmy podekscytowani. Teraz zabieramy Cię za kulisy i przedstawiamy pracę ludzi, którzy ją tworzą.

Przez lata w naszych podcastach omówiliśmy wiele rzeczy. Co tydzień dajemy Ci wgląd w świat zarządzania produktami, projektowania, wsparcia i marketingu dzięki Inside Intercom; zbadać, w jaki sposób liderzy branży wykorzystują CX do rozwijania swoich firm dzięki Scale; i pokażemy świat współzałożyciela Intercom, Des Traynor i Intercom SVP of Product, Paula Adamsa, którzy dzielą się swoimi najnowszymi przemyśleniami na temat tworzenia wspaniałych produktów.

A teraz coś z zupełnie innej beczki. Po raz pierwszy publikujemy Czaty inżyniera , wewnętrzny podcast tutaj w Intercom dotyczący wszystkich rzeczy związanych z inżynierią. Wcześniej prowadzony przez Jamiego Oslera, starszego inżyniera produktu w firmie Intercom przez ponad siedem lat, teraz główny inżynier systemowy Brian Scanlan przejmuje pałeczkę i prowadzi rozmowy.

W tym tygodniu oprócz Jamiego i Briana usłyszysz także od:

• Mike Stewart, były starszy główny inżynier w firmie Intercom
• Patrick O'Doherty, były starszy inżynier ds. bezpieczeństwa w Intercom, a obecnie inżynier w Oso
• Współzałożyciel interkomu Ciaran Lee
• Meena Polich, Starszy Doradca Intercomu wspierający badania i rozwój

Od procesu uściślania i najgorszego przestoju, jaki kiedykolwiek mieliśmy, po naszą obsesję na punkcie szybkości i tego, jak zespoły prawnicze i inżynierskie mogą lepiej współpracować, czaty inżynierów dadzą ci wgląd w proces inżynieryjny w Intercomie.

Jeśli masz mało czasu, oto kilka szybkich wskazówek:

• Ujednoznacznienie, czyli proces zawężania szerokiej przestrzeni rozwiązań w każdym problemie, jest dobry nie tylko w przypadku projektów niejednoznacznych. Może być stosowany do całego procesu budowlanego w inżynierii, a nawet do zarządzania produktem.
• Rdzeniem algorytmów i systemów są modele danych. Zajmując się projektem technicznym systemu, upewnij się, że zawsze najpierw rozumiesz modele danych.
• Automatyzacja w infrastrukturze może prowadzić do poważnych błędów. I chociaż te problemy nie są zabawne dla nikogo, możesz ich użyć do znalezienia innych martwych punktów i zbudowania solidniejszego systemu.
• Twoja domyślna kadencja operacyjna powinna być uruchomiona – ważne jest, aby startupy nie traciły na szybkości. Jeśli możesz coś zrobić w tym tygodniu, a nie w następnym, wskocz na to.
• Zespół prawników nie jest po to, by spowalniać prace badawczo-rozwojowe. Ich priorytetem jest dbanie o to, aby wraz z rozwojem firmy i wzrostem złożoności nadal działała w granicach prawa.

Jeśli podoba Ci się nasza dyskusja, sprawdź więcej odcinków naszego podcastu. Możesz śledzić na iTunes, Spotify lub pobrać kanał RSS w wybranym odtwarzaczu. Poniżej znajduje się lekko zredagowany transkrypcja odcinka.

Liam Geraghty: Cześć i witaj w Inside Intercom. Jestem Liam Geraghty. Jeśli jesteś regularnym słuchaczem, wiesz, że przeprowadzamy wywiady z twórcami i wykonawcami ze świata zarządzania produktem, projektowania, start-upów i marketingu. Mamy również dwa inne podcasty – Intercom on Product, w którym współzałożyciel Intercomu Des Traynor i Intercom SVP of Product, Paul Adams, omawiają swoje najnowsze przemyślenia na temat tworzenia udanych produktów na dużą skalę oraz Scale by Intercom – w których badamy, jak działają firmy napędzanie wzrostu poprzez relacje z klientami.

Jeden z podcastów, o których na pewno nie wiedziałeś, to jeden o nazwie Czaty inżyniera , a to dlatego, że jest to wewnętrzny podcast w Intercomie. Gospodarzem był Jamie Osler, były tutaj starszy inżynier produktu. W każdym odcinku Jamie siadał, aby porozmawiać z różnymi osobami na różne tematy związane z inżynierią.

Dzisiaj przedstawiamy dźwiękowe okno na wszystkie aspekty inżynierii w Intercomie. Zaczerpnęliśmy najlepsze fragmenty z serialu, z historii najgorszej awarii, jaką kiedykolwiek mieliśmy, po to, jak zespoły prawników i inżynierów mogą lepiej współpracować. Po pierwsze, ujednoznacznienie: czynność lub proces rozróżniania podobnych rzeczy i znaczeń w celu uczynienia znaczenia lub interpretacji bardziej jasnymi lub pewnymi. Mike Stewart, były starszy główny inżynier w firmie Intercom, usiadł, by porozmawiać z Jamiem w październiku 2020 r. o tym słowie i o tym, dlaczego tak często używa go w pracy. Oto Jamie.

Ujednoznacznienie do samego końca

Jamie Osler: Widziałem, jak robiłeś świetne rezultaty, gdy podchodziłeś do projektu, który jest trochę niewyraźny i niezbyt dobrze zdefiniowany pod względem tego, co oznacza sukces i jak najlepiej do niego podejść, co czasami nazywasz ujednoznacznieniem. Czy możesz nam powiedzieć, co masz na myśli, kiedy to mówisz?

Mike Stewart: Tak. Ujednoznacznienie. To słowo, którego nigdy nie używałem, zanim przyjechałem do Intercomu, i używam go tak często, odkąd tu przyjechałem. Prawdopodobnie powinienem był go użyć w poprzednich miejscach, ale to takie dobre słowo. Nie dotyczy to nawet projektów wełnianych lub niejednoznacznych. Wydaje mi się, że jest to bardzo ogólny czasownik, stanowiący część naszego całego procesu budowania, który wykracza daleko poza inżynierię i obejmuje wiele rzeczy, które robią PM, aby rozgryźć różne rzeczy.

„Masz szeroką przestrzeń rozwiązań… to proces likwidacji tej sytuacji w oparciu o dowody, decyzje i rozmowy”

Jeśli wrócisz do stanu sprzed projektu, oczywiście mamy zespoły, mają obszary własności i opracowują mapy drogowe wokół nich, prawda? Zespół jest odpowiedzialny za cały nasz obszar marketingu / zaangażowania / wyjazdu / powierzchni i jest w stanie odnieść sukces w tym zakresie. To jest niejednoznaczny problem. Proces zastanawiania się, gdzie siedzimy w tym i wszystkich rzeczy, które możemy zrobić, i sposobów, w jakie możemy je zrobić, oraz zawężania – może nie stuprocentowego rozgryzania – i zamykania tej przestrzeni rozwiązań, aby uzyskać ciaśniejsze i bliższy widok, w ramach wszystkich rzeczy, które można zrobić w przestrzeni zaangażowania, to te, które naszym zdaniem są najważniejsze, te, których klienci szukają najbardziej, najwyższy zwrot z inwestycji – to proces ujednoznacznienia. Masz szeroką przestrzeń rozwiązań, niejednoznaczność co do tego, gdzie powinieneś się udać w wielu różnych miejscach, do których możesz się udać w tej przestrzeni rozwiązań, i jest to proces likwidacji tego w oparciu o dowody, decyzje i rozmowy.

Kiedy odtwarzam to w projekcie inżynieryjnym, kilka etapów w dół jest tego samego rodzaju. Gdy zdecydowaliśmy się zbudować nowy komunikator z publiczną platformą, na której można tworzyć aplikacje i osadzić je w komunikatorze, dostępna jest cała przestrzeń rozwiązań, co to oznacza, wszystkie różne kształty, które mogą przybrać, jak to może się zamanifestować, i jak możesz to zbudować. Ujednoznacznienie do samego końca, aż dojdziesz do punktu, w którym niejednoznaczność, o której myślisz, brzmi: „Wiemy, że chcemy osadzić ramkę iFrame, która ma określony interfejs, programiści poruszają się tam iz powrotem, a następnie, w jaki sposób faktycznie to zaimplementuj, zaprojektuj to technologicznie i napisz kody, aby to zrobić?” To są jeszcze bardziej powiększone poziomy. Nadal pracujesz tam nad niejednoznacznością. Myślę więc, że ujednoznacznienie dotyczy całego procesu rozwoju produktu.

„Prawie myślę o tym jako o jednym z tych filmów o wszechświecie, które rozciągają się od zbliżenia aż do Ziemi jako kropki w galaktyce, przez całą ludzką skalę i mikroskalę”

Jamie Osler: Ty też to zawęziłeś. Może mógłbyś to trochę ujednoznacznić.

Liam Geraghty: Mike ma świetny sposób na wizualizację procesu ujednoznacznienia.

Mike Stewart: Tak. Niemal myślę o tym jako o jednym z tych filmów o wszechświecie w różnych rzędach wielkości, które rozciągają się od zbliżenia aż do Ziemi jako kropki w galaktyce, przez całą ludzką skalę i mikroskalę. Na każdym z tych poziomów jest ciekawa struktura i w ten sam sposób, myślę, że na każdym z poziomów powiększenia pojawia się interesująca niejednoznaczność, gdy rzeczy stają się coraz bardziej zdefiniowane.

Techniki są inne, gdy, powiedzmy, piszesz kod i zastanawiasz się: „Hej, jakie są moje koncepcje w kodzie i jak powinienem ustrukturyzować ten kod?” w przeciwieństwie do tego, kiedy zastanawiasz się: „Hej, jak mam to zaprojektować?” i jakie są modele danych i ruchome części w porównaniu do rozwiązania w porównaniu z planem? Abstrahuję to bardzo daleko, ponieważ to wszystko jest ujednoznacznieniem. Najważniejszą zasadą w mojej głowie jest rozmyślanie o tym, co atakujesz i przy jakim poziomie powiększenia. I tutaj inżynierowie mogą bardzo naturalnie dać się wciągnąć w głębsze poziomy powiększenia, ujednoznacznienia, wymyślania, jak coś zbudować, ponieważ jest to coś, co często jest wygodniejsze lub łatwiejszy do zgryzienia.

Bycie jednym z modelami danych

Liam Geraghty: Aby połączyć to wszystko z konkretnym przykładem, Jamie przedstawia ten przykład.

Jamie Osler: Kiedy przyglądaliśmy się, jak system bilingowy wysyłał dane do Zuory i jak starał się zapewnić synchronizację stanu między nimi, musieliśmy zrozumieć, jak robi to obecny system, abyśmy mogli uzyskać tego rodzaju ujednoznacznienie obecnego systemu i rozbicie go na jego podstawowe idee i zasady oraz sprawdzenie, które z nich są istotne w przyszłości. W ramach tego napisałeś dokument, który badał, jak działało modelowanie danych planu cenowego przez Zuora w czasie. I myślę, że było to coś, czego wielu ludzi nie zagłębiłoby się na tym poziomie. Co skłoniło cię do myślenia, że ​​byłoby to przydatne? A kiedy wiesz, kiedy przeprowadzić to śledztwo, a kiedy nie?

Mike Stewart: Tak, na pewno. Jeśli chodzi o poziomy powiększenia, o których mówiliśmy wcześniej, to dla mnie jest to słuszne w tym zaawansowanym, technicznym poziomie powiększenia. Podsumowując, w rozliczeniach byliśmy w punkcie, w którym: „Hej, całkiem dobrze rozumiemy, że mamy te dwa systemy. Mamy własną aplikację Rails i mamy zewnętrzny system Zuora. Wiemy, że przynajmniej przez przyzwoitą część przyszłości będziemy mieć te dwa systemy. Nie zmienimy tego ograniczenia. Dużo zbudowaliśmy na ich dwójce, więc nie można się ruszyć. Musimy zsynchronizować te dwa systemy, aby się ze sobą zgadzały, a wszystkie te problemy, które wynikają z tego, że nie jesteśmy w stanie się z nimi zgodzić, muszą zniknąć. Poniekąd zrozumieliśmy, że to była misja.

„Nie można opracować algorytmu niezależnego od modelu danych. I myślę, że to samo dotyczy sytuacji, gdy zaczynasz mówić o systemach i funkcjach produktów”

A potem chodziło o to, jakie rozwiązanie techniczne jest na to sposobem? Jeśli chodzi o techniki, kiedy myślę o projektowaniu technicznym i tej fazie projektowania technologicznego na wysokim poziomie lub fazie projektowania systemu, prawie zawsze kieruję się do modeli. Istnieje wiele obszarów powierzchni, które możesz spróbować zrozumieć. Jest wiele ważnych rzeczy, na przykład jaka jest struktura twojego kodu, co się porusza i jacy masz pracowników i co próbuje zrobić? Ale podstawowe pojęcia, podstawowe pojęcia w systemie, są prawie zawsze takie same, jak modele danych w rzeczywistej bazie danych; ich schemat w Twojej bazie danych lub schemat publiczny w Twojej firmie zewnętrznej, lub czymkolwiek one są. Są to podstawowe pojęcia w zaangażowanych modelach danych. A pewien znany informatyk – nie mam pojęcia który – zdecydowanie wyraził opinię, że rdzeniem algorytmów są modele danych. Nie można opracować algorytmu niezależnego od modelu danych. Myślę, że to samo dotyczy sytuacji, gdy zaczynasz mówić o systemach i funkcjach produktów. Modele danych są podstawą każdego projektu.

Tak więc w tej sytuacji pierwszą rzeczą, którą zrobiliśmy, kiedy wylądowaliśmy w rozliczeniach, było zrozumienie naszych własnych modeli danych. Ponieważ dla ciebie i dla mnie, Jamie, lądowanie tam było jak dziki zachód. Jak większość Intercomu, nigdy nie widzieliśmy tego od wewnątrz, była to nowa, odważna granica. Więc przede wszystkim musieliśmy zrozumieć: „Hej, co to za te wszystkie stoły zaangażowane w nasz własny system?” Doszliśmy do tego zrozumienia stosunkowo szybko z pomocą poprzedniego zespołu w San Francisco i zbudowaliśmy ten model mentalny.

„Nigdy nie czuję się komfortowo posuwając się naprzód z projektem technicznym, chyba że w pełni rozumiem modele danych”

Następnie kolejnym ważnym elementem, którego brakowało, a myślę, że prawie przyszliśmy zaatakować zbyt późno, było: „Zrozummy naprawdę model danych Zuory, system, w którym się zagłębiamy”. Wysiłek, o którym mówiłeś, myślę, że to był może tylko tydzień czasu, kiedy w zasadzie odpalałem konsolę, ręcznie przeszukując modele danych w Zuorze, zmieniając coś, uruchamiając kilka poleceń, aby zobaczyć, co się stało, i odkrywając coś w rodzaju stylu czarnoskrzynkowego, aby zrozumieć model danych. I pod koniec zrozumienia tego możemy powiedzieć: „Hej, jest ten duży stos modeli. Te naprawdę ważne są tutaj, tuż przy liściu. Są jak plan taryfowy, segmenty opłat lub coś, co przechowuje wnętrzności danych”. A kiedy właściwie zrozumiesz podstawowe koncepcje i modele danych, możesz zacząć budować, możesz zacząć projektować system. Jest to szczególnie prawdziwe, gdy mówimy o takich systemach replikacji, których podstawowym zadaniem jest niezawodne tasowanie jednego zestawu modeli danych i przekładanie go na semantycznie równoważną rzecz w innym zestawie modeli danych.

Twoje pierwotne pytanie, aby nie stracić tego z oczu, brzmi: skąd wiesz, kiedy powinieneś to zrobić? Dla mnie to naprawdę proste. Nigdy nie czuję się komfortowo posuwając się naprzód z projektem technicznym, chyba że w pełni rozumiem modele danych. I powiem wam, że jednym z miejsc, w którym byłem spalony przez niezbyt głębokie przestrzeganie tej zasady, było później, gdy przybyłem do Salesforce, miałem pewne zrozumienie podstawowych koncepcji i modeli danych, że Salesforce był wielkim, dużym światem. Tak więc była duża presja czasu. I nie doszedłem do tej samej głębi zrozumienia modeli danych, co w przypadku Zuory. Myślę, że to samo dotyczyło wszystkich członków zespołu. Nie doszliśmy do tego samego poziomu głębi modeli danych. Odczuwamy tego skutki w postaci tego, że zbudowaliśmy coś dobrego, ale rok później, po szerszym kontekście tych modeli danych, zdaliśmy sobie sprawę: „Hej, za pierwszym razem nie zrozumieliśmy ich poprawnie. Nie zmapowaliśmy poprawnie tłumaczenia między Salesforce a naszym własnym systemem i mamy więcej pracy do wykonania, aby naprawić ten brak wiedzy”.

Jamie Osler: To bardzo przydatne. To była świetna pogawędka o tym, jak rozróżniasz projekty.

Mike Stewart: Mam nadzieję, że to była świetna pogawędka, Jamie, i mam nadzieję, że mamy tu trochę przydatnej zawartości.

Jamie Osler: Treść hashtagów.

Jasna strona chwalebnie złej awarii

Liam Geraghty: Na początku tego roku, jeśli jesteś użytkownikiem Facebooka, WhatsApp lub Instagrama, bez wątpienia pamiętasz przerwę w październiku. Była to najdłuższa globalna awaria Facebooka w jego historii. Wszystko sprowadzało się do błędnej zmiany konfiguracji po ich stronie. Tak więc przerwy w dostawie nie są zabawne dla nikogo. Ktoś, kto ich szczególnie nie lubi, to Brian Scanlan, główny inżynier systemów interkomowych.

Brian Scanlan: Nienawidzę przestojów, dlatego poświęciłem swoją karierę walce z nimi.

Liam Geraghty: Brian usiadł, aby porozmawiać o nich z Jamiem w listopadzie 2020 r.

Brian Scanlan: Jednym z powodów, dla których lubię przerwy w pracy, dlaczego mnie do nich ciągnie, lub spędzam na nich czas, jest to, że jak na razie było to całkiem dobre dla mojej kariery. A to dlatego, że postanowiłem się tym zainteresować, zaangażować się w ich prowadzenie, myślenie o nich, bycie ich częścią i śledzenie ich.

Liam Geraghty: Brian przypomniał sobie kilka znaczących przestojów w Intercomie.

„Pamiętam, że chciałem być chory w koszu, kiedy zdałem sobie sprawę, że Elasticsearch jest pusty. Pomyślałem: „Och, to jest takie złe””

Brian Scanlan: Jednym z najbardziej traumatycznych przestojów, z jakimi miałem do czynienia, mimo że nie było mnie tam podczas awarii, była wielka awaria Elasticsearch w styczniu 2019 r.

Liam Geraghty: Ktoś, kto tam był, to Patrick O'Doherty, starszy inżynier bezpieczeństwa tutaj w tym czasie.

Patrick O'Doherty: Pamiętam, że chciałem być chory w koszu, kiedy zdałem sobie sprawę, że Elasticsearch jest pusty. Pomyślałem: „Och, to jest takie złe”.

Brian Scanlan: To było szczególnie spektakularne. Nie byłem tam, ponieważ byłem na 40. urodzinach drinka z przyjaciółmi. To było jak w piątek wieczorem. A ponieważ nie boimy się wysyłania kodu do produkcji w piątek, zatwierdziłem pull request, który dodał podsieć do naszego VPC AWS w piątek wieczorem.

Jamie Osler: Między drinkami?

Brian Scanlan: Nie, to było w drodze. Byłem wtedy trzeźwy. Kiedy próbowano dodać tę podsieć do naszej sieci w Amazon, automatyzacja, którą napisaliśmy… Używamy narzędzia o nazwie Terraform do zarządzania naszą niskopoziomową infrastrukturą w AWS i mieliśmy kilka modułów zespołu – pomyśl o tym jest to kod wielokrotnego użytku, który napisaliśmy, aby uprościć całą infrastrukturę wewnątrz AWS ze wszystkimi ustawieniami i rzeczami, które chcemy zastosować.

„W tym momencie, gdy konfiguracja została zastosowana, całkowicie zniszczyła lub przełączyła naszą sieć w tryb offline”

I tak ta automatyzacja bardzo skrupulatnie wzięła opis podsieci, którą chcieliśmy dodać. Ale w momencie aplikacji API AWS odrzuciło to, ponieważ istniała nakładająca się podsieć IP, a raczej podsieć, która była konfigurowana, nakładała się na już istniejącą. I tak w tym momencie proces aplikacji Terraform po prostu się poddał. Zatrzymało się. Co w wielu przypadkach jest całkowicie rozsądne. Niestety, sposób, w jaki zaimplementowaliśmy nasz moduł Terraform, oznaczał, że usuwał wszystkie informacje o tablicach routingu, które istniały w podsieci, i dodawał je z powrotem podczas konfigurowania wszystkich tych podsieci. W efekcie usunięto wszystkie trasy, dzięki którym sieć wie, jak dostać się do Internetu i innych sieci, co jest dość ważne. Tak więc w tym momencie, kiedy konfiguracja została zastosowana, całkowicie zniszczyła lub przełączyła naszą sieć w tryb offline. To dopiero początek.

Jamie Osler: To znaczy, to źle, prawda? To nie jest dobrze.

Brian Scanlan: Tak. To spowodowało, że Intercom całkowicie przełączył się w tryb offline. A potem zajęło nam trochę czasu, zanim doszliśmy do punktu, w którym mogliśmy się wycofać. Mówiąc my, to znaczy nie ja. W tym momencie cieszyłem się moimi napojami. W ten sposób zespół wymyślił sposób na dostanie się do naszej infrastruktury aprowizacji Terraform i wycofanie się do zmiany konfiguracji.

„Odkrycie, co się u licha wydarzyło i dokąd trafiły te dane, również zajęło dużo czasu. Mówimy tutaj o ośmiogodzinnej przerwie”

Ale niestety w międzyczasie pojawiła się inna automatyzacja. Tym razem automatyzacja, której właścicielem był AWS. Używamy tej technologii o nazwie OpsWorks, która jest zarządzaną wersją Chef, do zarządzania naszymi hostami Elasticsearch. Miał wbudowaną funkcję zwaną autonaprawianiem, którą domyślnie włączyliśmy w naszej konfiguracji na poziomie hosta. A jeśli backend OpsWorks nie mógł się skontaktować z hostami, system przepływu pracy OpsWorks próbowałby automatycznie naprawić danego hosta, ponieważ zorientował się, że coś poszło nie tak. System operacyjny jest uszkodzony, może zabrakło pamięci – stało się coś złego, więc spróbujmy to naprawić. Tak więc ta płaszczyzna sterowania OpsWorks postanowiła naprawić całą naszą infrastrukturę poprzez wymianę hostów.

Niestety, korzystaliśmy z Elasticsearch i nadal korzystamy z tego, co nazywamy pamięcią efemeryczną. To jest pamięć masowa oparta na hoście – nie używamy magicznego systemu opartego na chmurze, który przechowuje twoje dane w systemie innej firmy lub z systemu poza hostem. To tylko na fizycznym hoście. A jeśli fizyczny host zostanie zniszczony, dane znikną. I tak właśnie stało się z każdym hostem Elasticsearch. Każdy klaster Elasticsearch utracił każdą pojedynczą część danych, co jest dość złe, ponieważ ogromne ilości interkomu są oparte na Elasticsearch. To nie jest główny magazyn danych. Mamy tendencję do zapisywania danych do jednego magazynu danych, na przykład DynamoDB dla naszych użytkowników, a następnie kopiowania tych danych do Elasticsearch w celu wyszukiwania. I możemy go przywrócić, ale proces odzyskiwania wszystkich danych za pomocą kopii zapasowych i konieczności ponownego wprowadzenia wszystkich zmian od czasu naszych poprzednich kopii zapasowych trwał bardzo długo. Ponadto ustalenie, co się stało i dokąd te dane trafiły, również zajęło dużo czasu. Mówimy tutaj o ośmiogodzinnej przerwie.

„Nie powiedzieliśmy po prostu: „Cóż, teraz wiemy o tych dwóch problemach, naprawmy je”. Poszliśmy i poszukaliśmy innego rodzaju obszarów automatyzacji, które mogłyby nas ugryźć w dziwacznych sytuacjach”

To była wielka sprawa, ponieważ zdarzyło się to późno w piątek, potrzeba było całej ogromnej liczby ludzi, aby przywrócić stabilność. W pewnym sensie wiedzieliśmy o tych problemach, musieliśmy ponownie najechać lub ponownie wypełnić nasze klastry Elasticsearch i zdrapywać. Nie wiedzieliśmy o niektórych zagrożeniach ukrytych w naszej własnej automatyzacji i niektórych automatyzacji w AWS.

To było interesujące, ponieważ podążając za tym, nie powiedzieliśmy po prostu: „Cóż, teraz wiemy o tych dwóch problemach, naprawmy je”. Poszliśmy i poszukaliśmy innego rodzaju obszarów automatyzacji, które mogłyby nas ugryźć w dziwacznych sytuacjach. Skończyło się na tym, że zrobiliśmy wiele rzeczy, aby być naprawdę dobrymi w przywracaniu klastrów Elasticsearch z różnych stanów, będąc w stanie przywrócić dane w różnych momentach do naszych klastrów Elasticsearch, jeśli kiedykolwiek będziemy w tyle lub będziemy mieć podobne sytuacje typu katastrofy. I, wiecie, ogólnie rzecz biorąc, wiele się nauczyliśmy podczas tej chwalebnie złej awarii, a później proces był całkiem dobry, czego się dowiedzieliśmy i jak rozpowszechnialiśmy te informacje.

Patrick O'Doherty: Nie pamiętam, kto to był, ale jakąś godzinę później ktoś podziękował mi za spowodowanie tego incydentu, ponieważ powiedział: „Wow, naprawdę strząsnęłaś tu dużo rzeczy z drzewa. To będzie naprawdę zabawna reakcja na incydent”. To było w zasadzie sedno tego. To było jak: „Och, wow. Wykopujemy tu różne rzeczy. I to było. Nasze wykorzystanie Terraformu i nasza ogólna dojrzałość do tego, jak używamy narzędzi, jednocześnie będąc świadomym, że narzędzia mogą również nas skrzywdzić. Szanuj elektronarzędzia. Podobnie jak infrastruktura, elektronarzędzia są niebezpieczne. Mogą poruszać się szybko i cię zaskoczyć, i myślę, że tego dnia nauczyliśmy się naszej lekcji.

Brian Scanlan: Miałem też z tego powodu rozmowę Inside Intercom. Poza tym nie byłem na tym incydencie, ponieważ byłem w pubie na urodziny. To było wspaniałe. To był doskonały incydent.

Z prędkością światła

Liam Geraghty: W grudniu 2020 roku, w Boże Narodzenie, którego na pewno nigdy nie zapomnimy, współzałożyciel Intercomu, Ciaran Lee, dołączył do Jamiego, aby porozmawiać o szybkości i dlaczego Ciaranowi zależy na szybkim poruszaniu się.

Ciaran Lee: Jestem niezwykle niecierpliwą osobą. To jedna rzecz. Jeśli mogę coś zrobić szybko lub wolno, osobiście wolałbym to zrobić szybko. Intercom może wydawać się starą firmą, która ma powstać za 10 lat, ale szczerze wierzę, że dopiero zaczynamy. Mamy tak wiele do zrobienia. Jesteśmy tak ambitni. Możemy zobaczyć obraz tego, kim chcielibyśmy być, to wszechstronne narzędzie, z którego każdy, kto prowadzi biznes internetowy, może rozmawiać ze swoimi klientami. A tam tylko drapiemy powierzchnię.

Jedną z rzeczy, które naprawdę lubię w Stripe, fajnej firmie, którą podziwiam, był świetny post na blogu autorstwa Patricka McKenzie, w którym opisał, że ustawili domyślną kadencję operacyjną. Domyślnie poruszają się nieprzyjemnie szybko, zawsze pytając, czy możemy zrobić to szybciej w tym tygodniu, zamiast za sześć miesięcy od teraz. I po prostu osobiście to lubię. Taka postawa dobrze nam służyła. I myślę, że zawsze jest fajnie o tym myśleć. Czy możesz jechać szybciej?

„Fajnie, jeśli osiągniemy stuprocentową dostępność na kwartał, ale może powinniśmy zadać sobie pytanie: „Hej, czy nie jesteśmy wystarczająco ryzykowni?”

Jamie Osler: Jeśli szybkość działania ma kluczowe znaczenie dla Twojej firmy i jest to coś, co robisz przez cały czas, masz tendencję do mniej psucia się.

Ciaran Lee: Tak. Poruszaj się szybko i niszcz rzeczy w akceptowalnych parametrach. Przestoje są w porządku. Błędy są w porządku – oczywiście pewnych kategorii błędów chcesz mieć mniej niż innych, ale mamy budżety dostępności. Fajnie, gdy ćwierć osiągamy stuprocentową dostępność, ale może powinniśmy zadać sobie pytanie: „Hej, czy nie jesteśmy wystarczająco ryzykowni? Czy moglibyśmy podjąć trochę więcej ryzyka, aby poruszać się szybciej?” Powinieneś znajdować się w celowym punkcie spektrum. I na pewno spoczywa na nas duża odpowiedzialność. Mamy wielu klientów, setki tysięcy logujących się osób, których zadaniem jest korzystanie z naszej skrzynki odbiorczej, aby codziennie rozmawiać ze swoimi klientami. Nie możemy upodobnić się do łamania ich rzeczy, poruszając się zbyt szybko lub zmieniając je tak szybko, że nawet nie wiedzą, jak ich już używać. To byłoby złe. Mamy ograniczenia, ale w ramach tych ograniczeń powinniśmy bezwzględnie poruszać się tak szybko, jak to możliwe.

Gdzie legalność wchodzi w grę

Liam Geraghty: Przechodzimy przez ten odcinek tak szybko, jak to możliwe. Następnie interkom, starszy radca prawny, Meena Polich. Meena jest członkiem naszego zespołu prawnego, który koncentruje się na produktach i inżynierii. W styczniu 2021 r. Meena i Jamie rozmawiali o tym, jak zespoły prawnicze i inżynierskie mogą ze sobą współpracować.

„Jesteśmy tutaj w pewnym sensie maszerując krok po kroku z firmą i wszystkimi naszymi klientami, aby dostać się tam, gdzie musimy iść odpowiedzialnie, nie spowalniając nikogo”

Meena Polich: Bardzo ważne jest dla nas zrozumienie produktu. Jak możemy ewentualnie doradzić firmie, jakie przepisy będą miały na nas wpływ lub jakich przepisów musimy przestrzegać, jeśli tak naprawdę nie rozumiemy, co sprzedajemy? Na bardzo podstawowym poziomie, ze strategicznego punktu widzenia, musimy zrozumieć nie tylko to, co teraz sprzedajemy, ale także to, co chcemy sprzedawać i jak chcemy się pozycjonować i rozwijać. W ten sposób możemy zacząć tworzyć prognozy rzeczy, na które będziemy musieli mieć oko z prawnego punktu widzenia. I po prostu upewniając się, że jesteśmy tutaj w pewnym sensie marszem z firmą i wszystkimi naszymi klientami, aby dostać się tam, gdzie musimy iść odpowiedzialnie, nie spowalniając nikogo. Z bardziej taktycznego podejścia zrozumienie wartości firmy i produktu jest niezwykle pomocne w negocjacjach z klientami, a nawet dostawcami. Kiedy rozumiem, co staramy się zrobić, stawia mnie to w znacznie lepszej sytuacji. A potem mogę wyjaśnić naszym dostawcom: „Ponieważ staramy się to zrobić, potrzebujemy, abyś był w stanie to zrobić”.

I odwrotnie, kiedy negocjuję z klientami, często ludzie po drugiej stronie stołu to inni prawnicy lub agenci zaopatrzenia, którzy są tak samo techniczni, jeśli nie mniej techniczni, jak ja. I tak, będąc w stanie wyjaśnić, co robi produkt, jako prawnik, który mówi: „Słuchaj, wiem, jakie masz obawy z prawnego punktu widzenia zarządzania ryzykiem, ale oto jak faktycznie działa ta platforma. Oto jak produkt faktycznie działa w praktyce. I właśnie dlatego nie zwróci tego ryzyka, o które się martwisz. Nie spowoduje to ryzyka, o które się martwisz.

„Moim priorytetem jest pomaganie działowi badawczo-rozwojowemu w zrozumieniu, że nie jestem tutaj, aby zniweczyć niesamowity postęp, jaki robimy”

Jamie Osler: Myślę, że to działa w obie strony, prawda? Jeśli dział badawczo-rozwojowy lepiej rozumie rodzaj ogólnego przeglądu prawnego tego, gdzie mogą znajdować się obszary zainteresowania, pomaga im to uniknąć niezamierzonych działań lub wytwarzania produktów, które byłyby ryzykowne lub naruszałyby te przepisy.

Meena Polich: Tak, absolutnie. I to jest najważniejsza rzecz do odebrania lub próba skupienia się na budowaniu relacji prawnej z B+R. Moim pierwszym priorytetem jest pomoc działowi badawczo-rozwojowemu w zrozumieniu, że nie jestem tutaj po to, aby zniweczyć niesamowity postęp, jaki robimy, a mój zespół nie jest tutaj, aby powstrzymać nas przed dalszym wchodzeniem na rynek z doskonałymi produktami. Nasz zespół jest po to, aby w miarę rozwoju i coraz trudniejszego śledzenia wszystkiego, co robi każda osoba w firmie, nadal postępowaliśmy w sposób etyczny i nadal robimy to w granicach prawa. A kiedy możemy, staramy się zarządzać tym ryzykiem.

To jeden z powodów, dla których zgodność w fazie projektowania jest tak ważna. Jeśli będziemy pamiętać o wymaganiach dotyczących zgodności lub oczekiwaniach dotyczących zgodności i będziemy projektować zgodnie z nimi, wiele razy wprowadzane przez nas zmiany projektowe będą rzeczami, które rzeczywiście przyniosą korzyści naszym wynikom. Może wystąpić początkowy koszt pod względem alokacji zasobów, ale w dłuższej perspektywie, a nawet w bardzo długim okresie – w wielu przypadkach w ciągu sześciu miesięcy do roku od wprowadzenia tej funkcji – zobaczymy niesamowitą korzyść pod względem wzrostu przychodów i rodzaju pozyskanych przez nas leadów oraz przyciągania klientów, bo nam zaufają.

Liam Geraghty: Dziękuję Jamiemu Oslerowi, który stworzył Czaty Inżyniera , jego nowemu gospodarzowi Brianowi Scanlanowi oraz wszystkim dzisiejszym gościom, którzy uprzejmie pozwolili nam umieścić swoje wewnętrzne czaty na zewnątrz. Jeśli podobał Ci się dzisiejszy program, zostaw nam recenzję lub powiadom nas w mediach społecznościowych. Uwielbiamy widzieć i słyszeć, co myślisz. To wszystko na dziś. Wrócimy w przyszłym tygodniu z kolejnym odcinkiem Inside Intercom.