Intercom은 엔지니어 채팅을 제공합니다.

우리는 제품과 기능, 그리고 우리가 기대하는 출시에 대해 모두 이야기했습니다. 이제 우리는 당신을 무대 뒤에서 그것을 가능하게 한 사람들의 작업을 소개합니다.

수년에 걸쳐 우리는 팟캐스트에서 많은 부분을 다루었습니다. 매주 Inside Intercom을 통해 제품 관리, 디자인, 지원 및 마케팅의 세계에 대한 통찰력을 제공합니다. 업계 리더들이 CX를 사용하여 Scale을 통해 비즈니스를 성장시키는 방법을 탐색합니다. Intercom 공동 설립자 Des Traynor와 Intercom 제품 SVP인 Paul Adams가 훌륭한 제품을 만드는 방법에 대한 최신 생각을 공유하는 세계를 보여줍니다.

그리고 이제 완전히 다른 것을 위해. 처음으로 우리는 Intercom에서 엔지니어링의 모든 것에 대한 내부 팟캐스트인 Engineer Chats 를 출시합니다. 이전에는 Intercom의 수석 제품 엔지니어인 Jamie Osler가 7년 넘게 호스트했지만 이제는 수석 시스템 엔지니어인 Brian Scanlan이 지휘봉을 잡고 채팅을 계속해야 합니다.

이번 주에는 Jamie와 Brian 외에도 다음과 같은 소식을 듣게 됩니다.

• Mike Stewart, Intercom의 전 수석 수석 엔지니어
• Intercom의 전 수석 보안 엔지니어이자 현재 Oso의 엔지니어인 Patrick O'Doherty
• 인터콤 공동 설립자 Ciaran Lee
• Meena Polich, Intercom의 R&D 지원 선임 고문

명확화 과정과 우리가 겪었던 최악의 정전부터 속도에 대한 집착과 법무팀과 엔지니어링 팀이 함께 더 잘 협력할 수 있는 방법에 이르기까지 Engineer Chats 는 Intercom의 엔지니어링 프로세스 이면을 엿볼 것입니다.

시간이 부족한 경우 다음 몇 가지 간단한 사항을 참조하세요.

• 명확화 또는 각 문제의 넓은 솔루션 공간을 좁히는 과정은 모호한 프로젝트에만 좋은 것이 아닙니다. 엔지니어링 및 제품 관리의 전체 건물 프로세스에 사용할 수 있습니다.
• 알고리즘과 시스템의 핵심은 데이터 모델입니다. 시스템의 기술 설계를 다룰 때는 항상 데이터 모델을 먼저 이해해야 합니다.
• 인프라 자동화는 심각한 실수로 이어질 수 있습니다. 이러한 문제는 누구에게나 재미가 없지만 다른 사각지대를 찾고 보다 강력한 시스템을 구축하는 데 사용할 수 있습니다.
• 기본 운영 케이던스는 실행되어야 합니다. 스타트업이 속도를 타협하지 않는 것이 중요합니다. 다음 분기 대신 이번 주에 무언가를 할 수 있다면 바로 실행하십시오.
• 법무팀은 R&D 속도를 늦추기 위해 존재하지 않습니다. 그들의 우선 순위는 회사가 성장하고 복잡성이 증가함에 따라 법의 범위 내에서 계속 그렇게 하도록 하는 것입니다.

토론이 재미있다면 팟캐스트의 더 많은 에피소드를 확인하세요. iTunes, Spotify에서 팔로우하거나 선택한 플레이어에서 RSS 피드를 가져올 수 있습니다. 다음은 에피소드의 가볍게 편집된 대본입니다.

Liam Geraghty: 안녕하세요. Inside Intercom에 오신 것을 환영합니다. 저는 리암 게라티입니다. 정기적으로 청취하는 경우 제품 관리, 디자인, 신생 기업 및 마케팅 분야의 제작자 및 수행자를 인터뷰한다는 것을 알게 될 것입니다. Intercom 공동 창립자 Des Traynor와 Intercom 제품 SVP인 Paul Adams가 대규모로 성공적인 제품을 구축하는 방법에 대한 최신 생각에 대해 토론하는 Intercom on Product와 비즈니스가 어떻게 운영되고 있는지 살펴보는 Scale by Intercom이라는 두 가지 다른 팟캐스트도 있습니다. 고객 관계를 통해 성장을 주도합니다.

우리가 만든 팟캐스트 중 하나는 당신이 확실히 몰랐던 것인데 Engineer Chats 입니다. Intercom의 내부 팟캐스트이기 때문입니다. 이곳의 전 수석 제품 엔지니어인 Jamie Osler가 주최했습니다. 각 에피소드에서 Jamie는 엔지니어링과 관련된 다양한 주제에 대해 다양한 사람들과 이야기를 나누었습니다.

오늘은 Intercom의 모든 엔지니어링에 대한 음향 창을 제공합니다. 우리는 우리가 겪은 최악의 정전에 대한 이야기에서 법무팀과 엔지니어링 팀이 함께 더 잘 협력할 수 있는 방법에 이르기까지 쇼에서 가장 좋은 부분을 가져왔습니다. 첫째, 명확화(disambiguating): 의미 또는 해석을 보다 명확하거나 확실하게 하기 위해 유사한 사물과 의미를 구별하는 행위 또는 과정. Intercom의 전 수석 수석 엔지니어인 Mike Stewart는 2020년 10월 Jamie와 함께 그 단어와 그가 직장에서 그 단어를 많이 사용하는 이유에 대해 이야기했습니다. 여기 제이미가 있습니다.

아래로 명확성

Jamie Osler: 성공이 무엇을 의미하는지, 어떻게 접근하는 것이 가장 좋은지 명확하지 않은 프로젝트에 접근할 때 훌륭한 결과를 얻는 것을 본 적이 있습니다. 그 말씀을 하실 때 무슨 말씀이신지 말씀해 주시겠습니까?

마이크 스튜어트: 네. 명확하다. 인터콤에 오기 전까지는 한 번도 사용하지 않은 단어였고, 여기 와서도 그렇게 많이 사용했습니다. 아마 예전에 예전에 사용했었어야 했을텐데 너무 좋은 단어네요. 양털 프로젝트나 모호한 프로젝트에만 해당되는 것은 아닙니다. 저는 이것이 엔지니어링을 넘어 PM이 파악하는 많은 작업에 들어가는 전체 구축 프로세스의 일부인 매우 일반적인 동사라고 생각합니다.

"당신에게는 광범위한 솔루션 공간이 있습니다... 증거와 결정 및 요청을 기반으로 이를 축소하는 과정입니다."

프로젝트 이전 상태로 바로 돌아가면 분명히 팀이 있고 소유권 영역이 있으며 주변의 로드맵을 파악합니다. 그렇죠? 팀은 우리의 전체 마케팅/참여/아웃바운드/표면 영역을 책임지고 있으며 그 안에서 성공을 소유하고 있습니다. 그것은 모호한 문제입니다. 그 안에서 우리가 어디에 앉아 있고 우리가 할 수 있는 모든 일과 우리가 할 수 있는 방법을 파악하고 범위를 좁히는 과정(아무도 100%는 아닐 수도 있음) 더 자세히 들여다보면, 참여 공간 내에서 할 수 있는 모든 것 중에서 가장 중요하다고 생각하는 것, 고객이 가장 찾고 있는 것, 가장 높은 투자 수익을 얻는 것, 이것이 바로 명확성의 과정입니다. 당신은 솔루션 공간이 넓고, 솔루션 공간 내에서 갈 수 있는 다양한 장소 중 어디로 가야 하는지에 대한 모호성이 있으며, 증거와 결정 및 요청을 기반으로 이를 정리하는 과정입니다.

내가 엔지니어링 프로젝트에 그것을 플레이할 때, 파이프라인에서 몇 단계 아래에 같은 종류의 것이 있습니다. 앱을 빌드하고 이를 메신저에 포함할 수 있는 공개 플랫폼으로 새로운 메신저를 구축하기로 결정하고 나면, 그것이 의미하는 바, 취할 수 있는 모든 다양한 형태, 그것이 어떻게 나타날 수 있는지에 대한 전체 솔루션 공간이 있습니다. 그리고 당신이 그것을 구축할 수 있는 방법. "우리는 특정 인터페이스가 있는 iFrame을 포함하고 개발자가 앞뒤로 움직인 다음 어떻게 해야 하는지 알고 있습니다. 실제로 그것을 구현하고, 기술적으로 설계하고, 이를 수행하는 코드를 작성합니까?” 그것들은 훨씬 더 확대된 수준입니다. 당신은 여전히 ​​​​모호함을 통해 일하고 있습니다. 그래서 저는 제품 개발 과정 전반에 걸쳐 모호성을 없애는 것이 있다고 생각합니다.

"나는 이것을 은하계의 한 점으로 지구까지 확대하는 우주의 비디오 중 하나라고 생각합니다. 인간의 규모와 미시적 규모의 모든 방법을 통해"

Jamie Osler: 그것도 정말 좁혀 놓으셨습니다. 아마 당신은 그것을 조금 명확하게 할 수 있습니다.

Liam Geraghty: Mike는 명확하게 하는 과정을 시각화하는 훌륭한 방법을 가지고 있습니다.

마이크 스튜어트: 네. 나는 이것을 은하계의 한 점으로 지구까지 확대하는 것에서부터 인간 규모와 미시적 규모를 통해 모든 방향으로 가는 다양한 크기의 우주 비디오 중 하나라고 거의 생각합니다. 각 수준에는 흥미로운 구조가 있으며, 마찬가지로 사물이 점점 더 정의됨에 따라 각 확대/축소 수준에 흥미로운 모호성이 있다고 생각합니다.

예를 들어 코드를 작성하고 "이봐, 코드에서 내 개념은 무엇이며 이 코드를 어떻게 구성해야 합니까?"를 알아낼 때 기술이 다릅니다. "이봐, 이걸 어떻게 기술적으로 디자인해야 하지?" 데이터 모델과 움직이는 부분은 무엇이며 솔루션은 무엇이며 로드맵은 무엇입니까? 나는 그것이 모두 명확하기 때문에 그것을 매우 추상화하고 있습니다. 공격하려는 대상과 확대/축소 수준에 대해 매우 신중하게 생각하는 것이 가장 중요한 원칙입니다. 그리고 엔지니어는 명확성의 더 깊은 확대 수준으로 매우 자연스럽게 빨려 들어갈 수 있습니다. 무언가를 구축하는 방법을 알아내는 것입니다. 왜냐하면 그것이 종종 더 편안하거나 깨지기 쉬운 너트이기 때문입니다.

데이터 모델과 하나되기

Liam Geraghty: 이 모든 것을 구체적인 예와 연결하기 위해 Jamie는 이것을 제시합니다.

Jamie Osler: 청구 시스템이 Zuora에 데이터를 전송하는 방법과 이 둘 사이에서 상태가 동기화되도록 하는 방법을 살펴보았을 때 현재 시스템에서 이러한 종류의 데이터를 얻을 수 있는 방법을 이해해야 했습니다. 현재 시스템의 모호성을 없애고 이를 핵심 아이디어와 원칙으로 분류하고 그 중 어떤 것이 앞으로 관련성이 있는지 확인합니다. 그 일환으로 Zuora의 시간 경과에 따른 요금제 데이터 모델링이 작동하는 방식을 탐구한 문서를 작성했습니다. 그리고 나는 그것이 많은 사람들이 그 수준에서 파고 들지 않았을 것이라고 생각합니다. 그것이 유용한 일이라고 생각하게 된 계기는 무엇입니까? 그리고 언제 그 조사를 해야 하는지, 언제 하지 말아야 하는지 아십니까?

마이크 스튜어트: 네, 물론입니다. 우리가 이전에 이야기한 확대/축소 수준의 관점에서, 저에게는 이것이 바로 높은 수준의 기술 디자인 확대/축소 수준입니다. 요약하자면, 청구에서 우리는 "이봐, 우리는 우리가 이 두 시스템을 가지고 있다는 것을 꽤 확실히 이해하고 있습니다. 우리는 자체 Rails 앱과 외부 Zuora 시스템을 가지고 있습니다. 우리는 적어도 미래의 상당한 덩어리 동안 이 두 시스템을 갖게 될 것이라는 것을 알고 있습니다. 우리는 그 제약을 바꾸지 않을 것입니다. 우리는 그 두 가지를 기반으로 많이 구축되어 있으므로 이전할 수 없습니다. 우리는 두 시스템을 동기화해야 하고 서로 동의해야 합니다. 서로 동의하지 못하는 데서 비롯되는 이 모든 문제는 사라져야 합니다. 우리는 그것이 임무라는 것을 이해했습니다.

“데이터 모델과 독립적인 알고리즘을 고안할 수는 없습니다. 시스템과 제품 기능에 대해 이야기할 때도 마찬가지라고 생각합니다.”

그리고 이를 실현하기 위한 기술적인 해결책은 무엇인가에 대한 사례였다. 테크닉의 면에서, 내가 테크 디자인에 대해 생각할 때, 그리고 이 높은 수준의 테크 디자인이나 시스템 디자인 단계에 대해 생각할 때, 내가 거의 항상 하는 일은 모델에 가는 것입니다. 이해하려고 노력할 수 있는 표면적은 많습니다. 코드 구조가 어떤지, 어떤 것들이 움직이고 있는지, 어떤 작업자들이 있고, 무엇을 하려고 하는지와 같이 중요한 것들이 많이 있습니다. 그러나 시스템의 핵심 개념인 기본 개념은 실제 데이터베이스의 데이터 모델과 거의 항상 동일합니다. 데이터베이스의 스키마 또는 타사의 공개 스키마 또는 무엇이든 상관없습니다. 그것들은 관련된 데이터 모델의 핵심 개념입니다. 그리고 어떤 유명한 컴퓨터 과학자는 알고리즘의 핵심이 데이터 모델이라는 감정을 분명히 표현했습니다. 데이터 모델과 독립적인 알고리즘을 고안할 수 없습니다. 그리고 시스템과 제품 기능에 대해 이야기할 때도 마찬가지라고 생각합니다. 데이터 모델은 모든 디자인의 기본입니다.

따라서 이 상황에서 청구에 착수했을 때 가장 먼저 한 일은 자체 데이터 모델을 이해하는 것이었습니다. 너와 나 Jamie에게 그곳에 착륙하는 것은 황량한 서부와 같았기 때문입니다. 대부분의 인터콤과 마찬가지로 우리는 이 내부를 본 적이 없으며 용감한 새로운 개척지였습니다. 그래서 우선, "이봐, 도대체 이 테이블들이 우리 시스템에 포함된 게 다 뭐야?"를 이해해야 했습니다. 우리는 샌프란시스코에 있는 이전 팀의 도움으로 비교적 빠르게 이해하고 정신 모델을 구축했습니다.

"데이터 모델을 완전히 이해하지 않으면 기술 설계를 진행하는 것이 결코 편하지 않습니다."

그런 다음, 너무 늦게 공격하게 되었다고 생각하는 누락된 다음 주요 부분은 "우리가 파헤치고 있는 시스템인 Zuora의 데이터 모델을 제대로 이해합시다."였습니다. 말씀하신 노력은 기본적으로 콘솔을 실행하고, Zuora에서 데이터 모델을 수동으로 파고들고, 무언가를 변경하고, 어떤 일이 일어났는지 확인하기 위해 몇 가지 명령을 실행하고, 일종의 탐색을 수행한 일주일 정도의 시간이었던 것 같습니다. 데이터 모델을 이해하기 위한 블랙박스 스타일. 그리고 이해가 끝나면 이렇게 말할 수 있습니다. 정말 중요한 것들은 여기 아래, 바로 잎사귀에 있습니다. 데이터의 내장을 저장하는 요금제, 요금 세그먼트 또는 기타와 같습니다.” 그리고 핵심 개념과 데이터 모델을 제대로 이해하고 나면 구축을 시작할 수 있고 시스템 설계를 시작할 수 있습니다. 그리고 이것은 기본적으로 한 세트의 데이터 모델을 안정적으로 섞고 다른 데이터 모델 세트에서 의미상 동일한 것으로 변환하는 것과 같은 복제 시스템에 대해 이야기할 때 특히 그렇습니다.

그것을 놓치지 않기 위한 당신의 원래 질문은 당신이 그것을 해야 할 때를 어떻게 압니까? 저에게 그것은 정말 간단한 것입니다. 데이터 모델을 완전히 이해하지 않는 한 기술 설계를 진행하는 것이 결코 편하지 않습니다. 그리고 그 원칙을 깊이 따르지 않아 불타버린 한 곳을 말씀드리겠습니다. 나중에 Salesforce에 와서 Salesforce가 크고 큰 세상이라는 핵심 개념과 데이터 모델에 대해 어느 정도 이해하고 있었습니다. 그래서 시간적 압박이 컸다. 그리고 저는 Zuora에서 했던 것처럼 데이터 모델에 대해 깊이 있게 이해하지 않았습니다. 그리고 팀의 모든 사람들도 마찬가지였다고 생각합니다. 우리는 같은 수준의 데이터 모델에 도달하지 못했습니다. 그리고 우리는 뭔가 좋은 것을 만들었다는 점에서 그 결과를 느끼고 있습니다. 하지만 1년 후, 이러한 데이터 모델에 대해 더 많은 맥락을 파악한 후에 우리는 깨달았습니다. Salesforce와 자체 시스템 간의 번역을 올바르게 매핑하지 못했고 지식 부족을 해결하기 위해 해야 할 일이 더 많습니다.”

Jamie Osler: 매우 유용합니다. 프로젝트를 명확하게 구분하는 방법에 대한 훌륭한 대화였습니다.

Mike Stewart: 즐거운 채팅이 되었기를 바랍니다. Jamie, 그리고 여기에서 유용한 콘텐츠를 얻을 수 있기를 바랍니다.

Jamie Osler: 해시태그 콘텐츠.

엄청나게 나쁜 정전의 밝은 면

Liam Geraghty: 올해 초 Facebook, WhatsApp 또는 Instagram 사용자라면 10월에 발생한 정전을 기억할 것입니다. 이는 페이스북 역사상 가장 긴 글로벌 정전이었다. 이 모든 것은 결국 잘못된 구성 변경으로 귀결되었습니다. 따라서 정전은 누구에게도 즐겁지 않습니다. 그들을 특히 싫어하는 사람은 Intercom 수석 시스템 엔지니어인 Brian Scanlan입니다.

Brian Scanlan: 저는 정전을 싫어합니다. 그래서 정전에 맞서 싸우는 데 제 경력을 바쳤습니다.

Liam Geraghty: Brian은 2020년 11월에 Jamie와 이야기를 나누기 위해 자리에 앉았습니다.

Brian Scanlan: 내가 정전을 좋아하는 이유, 정전에 끌리는 이유 또는 시간을 보내는 이유 중 하나는 지금까지 내 경력에 꽤 좋았기 때문입니다. 그 이유는 제가 관심을 갖고 운영에 참여하고, 생각하고, 일부가 되고, 후속 조치를 취하기로 결정했기 때문입니다.

Liam Geraghty: Brian은 Intercom에서 몇 가지 주목할만한 정전을 회상했습니다.

“Elasticsearch가 비어 있다는 것을 알았을 때 나는 쓰레기통에서 아프고 싶었습니다. 나는 '아, 이건 너무 나쁘다'라고 생각했습니다."

Brian Scanlan: 내가 관련되었던 가장 충격적인 정전 중 하나는 정전 기간 동안 실제로 거기에 없었음에도 불구하고 2019년 1월에 발생한 대규모 Elasticsearch 정전이었습니다.

Liam Geraghty: 그곳에 있었던 사람은 당시 수석 보안 엔지니어인 Patrick O'Doherty였습니다.

Patrick O'Doherty: Elasticsearch가 비어 있다는 것을 알았을 때 나는 쓰레기통에서 아프고 싶었습니다. 나는 "아, 이건 너무 나빠."라고 생각했습니다.

Brian Scanlan: 이것은 특히 장관이었습니다. 나는 40 번째 생일에 친구들과 술을 마셨기 때문에 거기에 없었습니다. 금요일 저녁 같았습니다. 그리고 금요일에 프로덕션으로 코드를 배송하는 것이 두렵지 않기 때문에 금요일 저녁에 VPC AWS에 서브넷을 추가하는 풀 요청을 승인했습니다.

Jamie Osler: 음료 사이에?

Brian Scanlan: 아니요, 실제로 진행 중이었습니다. 나는 그 당시에 정신이 없었습니다. 그 서브넷이 Amazon 내부의 네트워크에 추가하려고 시도했을 때 우리가 작성한 자동화는… 우리는 Terraform이라는 도구를 사용하여 AWS 내부의 저수준 인프라를 관리하고 많은 팀 모듈을 가지고 있었습니다. 우리가 적용하려는 모든 설정과 항목을 사용하여 AWS 내부의 많은 인프라를 시도하고 단순화하기 위해 작성한 재사용 가능한 코드입니다.

"그 시점에 구성이 적용되었을 때 네트워크가 완전히 파괴되었거나 오프라인 상태였습니다."

그래서 이 자동화는 우리가 추가하고 싶은 서브넷에 대한 설명을 매우 부지런히 취했습니다. 하지만 신청 당시 AWS API는 IP 서브넷이 겹친다거나, 기존에 구성 중인 서브넷이 이미 존재하는 서브넷과 겹친다는 이유로 이를 거부했다. 그래서 그 시점에서 Terraform 애플리케이션 프로세스는 거의 포기했습니다. 멈췄다. 많은 경우에 이것은 완전히 합리적인 일입니다. 그러나 불행히도 Terraform 모듈을 구현한 방식은 서브넷에 존재하는 라우팅 테이블에 대한 모든 정보를 제거하고 이러한 모든 서브넷을 구성하는 동안 다시 추가한다는 것을 의미했습니다. 따라서 사실상 네트워크가 인터넷 및 기타 네트워크에 도달하는 방법을 아는 방법인 모든 경로를 제거했습니다. 이는 매우 중요합니다. 따라서 그 시점에서 구성이 적용되었을 때 네트워크가 완전히 파괴되거나 오프라인 상태가 되었습니다. 이제 시작일 뿐입니다.

Jamie Osler: 제 말은, 그게 나쁜 거죠, 그렇죠? 그 좋지 않다.

브라이언 스캔란: 네. 그래서 Intercom을 완전히 오프라인 상태로 만들었습니다. 그런 다음 롤백할 수 있는 지점에 도달하는 데 시간이 좀 걸렸습니다. 우리는 내가 아니라 우리를 의미합니다. 나는 이 점에서 나의 술을 즐기고 있었다. 그래서 팀은 Terraform 프로비저닝 인프라에 들어가 구성 변경으로 롤백하는 방법을 알아냈습니다.

“도대체 무슨 일이 일어났고 그 데이터가 어디로 갔는지 알아내는 것 역시 오랜 시간이 걸렸습니다. 우리는 여기서 8시간의 정전에 대해 이야기하고 있습니다.”

그러나 불행하게도 그 사이에 다른 자동화가 시작되었습니다. 이번에는 AWS가 소유한 일부 자동화가 시작되었습니다. Chef의 관리 버전인 OpsWorks라는 이 기술을 사용하여 Elasticsearch 호스트를 관리합니다. 기본적으로 호스트 수준 구성에 활성화된 자동 복구라는 기능이 내장되어 있습니다. 호스트가 OpsWorks 백엔드에서 연락할 수 없는 경우 OpsWorks의 워크플로 시스템은 문제가 있는 호스트에서 문제가 발생한 것으로 판단하여 해당 호스트를 자동 복구하려고 시도합니다. OS가 다운되었거나 메모리가 부족할 수 있습니다. 문제가 발생했으므로 문제를 해결해 보겠습니다. 그래서 이 OpsWorks 컨트롤 플레인은 호스트를 교체하여 전체 인프라를 수정하기로 결정했습니다.

불행히도 우리는 Elasticsearch를 실행하고 있었고 여전히 임시 스토리지로 알려진 작업을 수행하고 있습니다. 그것은 호스트 기반 스토리지입니다. 우리는 일부 타사 시스템이나 호스트 외부의 시스템에서 데이터를 저장하는 마법 같은 클라우드 기반 시스템을 사용하지 않습니다. 물리적 호스트에만 있습니다. 그리고 물리적 호스트가 파괴되면 데이터는 사라집니다. 이것이 모든 단일 Elasticsearch 호스트에 일어난 일입니다. 모든 단일 Elasticsearch 클러스터는 모든 단일 데이터 조각을 잃어버렸습니다. 이는 Elasticsearch 위에 엄청난 양의 Intercom이 구축되어 있기 때문에 꽤 나쁩니다. 기본 데이터 저장소가 아닙니다. 우리는 사용자를 위해 DynamoDB와 같은 하나의 데이터 저장소에 데이터를 쓴 다음 검색을 위해 해당 데이터를 Elasticsearch에 복사하는 경향이 있습니다. 그리고 우리는 그것을 복원할 수 있지만 백업을 통해 모든 데이터를 다시 가져오고 이전 백업 이후의 모든 변경 사항을 다시 구동해야 하는 프로세스는 길고 길고 오랜 시간이 걸렸습니다. 또한 지구에서 무슨 일이 일어났는지, 그 데이터가 어디로 갔는지 알아내는 것 역시 오랜 시간이 걸렸습니다. 여기에서 8시간의 정전에 대해 이야기하고 있습니다.

“우리는 '이제 우리는 이 두 가지 문제를 알았으니 해결하자'고만 생각하지 않았습니다. 우리는 이상한 상황에서 우리를 물릴 수 있는 다른 종류의 자동화 영역을 찾았습니다.”

이것은 금요일 늦게 일어났기 때문에 큰 문제였습니다. 상황을 다시 안정시키는 데 엄청난 수의 사람들이 필요했습니다. 우리는 Elasticsearch 클러스터를 다시 구동하거나 다시 채우고 스크래치를 만들어야 하는 이러한 문제에 대해 어느 정도 알고 있었습니다. 우리는 자체 자동화와 AWS의 자동화에 잠재된 위험에 대해 알지 못했습니다.

흥미롭게도 우리는 "이제 이 두 가지 문제를 알았으니 해결해 봅시다."라고만 하지 않았습니다. 우리는 나가서 기괴한 상황에서 우리를 물릴 수 있는 다른 종류의 자동화 영역을 찾았습니다. 그래서 우리는 다른 상태에서 Elasticsearch 클러스터를 복원할 수 있고, 뒤처지거나 유사한 재해 유형 상황이 발생하는 경우 다른 시간에 Elasticsearch 클러스터로 데이터를 다시 구동할 수 있도록 하기 위해 많은 일을 하게 되었습니다. 그리고 전반적으로 우리는 이 영광스럽게도 나쁜 정전으로부터 많은 것을 배웠고 그 과정은 실제로 우리가 배운 것과 그 정보를 전파한 방식이 꽤 좋았습니다.

Patrick O'Doherty: 누군지 기억이 안 나지만 약 1시간 후 누군가가 "와, 여기 나무에서 정말 많은 것을 흔들었군요. 이것은 정말 재미있는 사건 대응이 될 것입니다.” 그것이 기본적으로 그것의 요지였습니다. 그것은 마치 "오, 와우. 우리는 여기에서 물건을 파헤치고 있습니다.” 그리고 그랬다. Terraform을 사용하고 도구를 사용하는 방법에 대한 일반적인 성숙도는 도구가 우리에게도 해를 끼칠 수 있다는 점을 의식하면서 이루어집니다. 전동공구를 존중합니다. 인프라와 마찬가지로 전동 공구도 위험합니다. 그들은 빠르게 움직이고 당신을 놀라게 할 수 있고, 나는 우리가 그날 우리의 교훈을 배웠다고 생각합니다.

Brian Scanlan: 나는 또한 이것에 대해 Inside Intercom 이야기를 들었습니다. 또한, 나는 내 생일에 술집에 있었기 때문에 사건에 참석하지 않았습니다. 그것은 훌륭했다. 완벽한 사건이었다.

빛의 속도로

Liam Geraghty: 2020년 12월, 우리가 절대 잊지 못할 크리스마스에 Intercom의 공동 설립자인 Ciaran Lee가 Jamie와 합류하여 속도와 Ciaran이 빠른 이동에 관심을 갖는 이유에 대해 이야기했습니다.

Ciaran Lee: 나는 매우 조급한 사람입니다. 한 가지입니다. 빨리 할 수 ​​있는 일이나 천천히 할 수 있는 일이라면 개인적으로는 그냥 빨리 하는 편이 낫다. 인터콤은 10년이 된 오래된 회사처럼 보일 수 있지만 솔직히 저는 우리가 이제 막 시작했다고 믿습니다. 할 일이 너무 많습니다. 우리는 너무 야심차다. 우리는 인터넷 사업을 하는 모든 사람들이 고객과 대화하는 데 사용할 수 있는 이 올인원 도구인 우리가 되고 싶은 모습을 볼 수 있습니다. 그리고 우리는 거기에서 표면을 긁고 있을 뿐입니다.

내가 존경하는 멋진 회사인 Stripe에서 내가 정말 좋아하는 것 중 하나는 Patrick McKenzie가 기본 운영 케이던스를 실행하도록 설정했다고 설명한 훌륭한 블로그 게시물이었습니다. 그들은 기본적으로 불편할 정도로 빠르게 움직이며 지금부터 6개월이 아니라 이번 주에 더 빨리 할 수 ​​있는지 항상 묻습니다. 그리고 개인적으로 정말 좋아합니다. 그런 태도가 우리에게 정말 큰 도움이 되었습니다. 그리고 항상 생각하는 것은 재미있는 일이라고 생각합니다. 더 빨리 갈 수 있습니까?

"분기에 가용성이 100%에 도달하는 것은 좋지만 '이봐, 우리가 충분히 위험하지 않은가?'라고 자문해야 할 수도 있습니다."

Jamie Osler: 빠른 속도로 진행하는 것이 회사에 중요하고 항상 하는 일이라면 고장이 덜 나는 경향이 있습니다.

시아란 리: 네. 빠르게 움직이고 허용 가능한 범위 내에서 물건을 부수십시오. 정전이 되는 것은 괜찮습니다. 버그가 있는 것은 괜찮습니다. 분명히 다른 범주보다 적게 갖고 싶은 특정 범주의 버그가 있지만 가용성 예산이 있습니다. 분기에 가용성이 100%에 도달하는 것은 멋지지만 "이봐, 우리가 충분히 위험하지 않습니까? 더 빨리 움직이기 위해 조금 더 위험을 감수할 수 있을까요?” 스펙트럼의 의도적인 지점에 있어야 합니다. 그리고 확실히, 우리에게는 큰 책임이 있습니다. 많은 고객이 있고 수십만 명이 로그인하여 받은 편지함을 사용하여 매일 고객과 대화하고 있습니다. 우리는 너무 빨리 움직여서 그들의 물건을 부수거나 너무 빨리 바꿔서 더 이상 사용법조차 모르는 것처럼 할 수 없습니다. 그것은 잘못된 것입니다. 우리에게는 제약이 있지만 그 제약 내에서 최대한 빨리 움직여야 합니다.

법률이 들어오는 곳

Liam Geraghty: 그리고 우리는 이 에피소드를 통해 최대한 빨리 움직이고 있습니다. 다음은 Intercom, 선임 고문 Meena Polich입니다. Meena는 제품 및 엔지니어링에 중점을 둔 법률 팀에 있습니다. 2021년 1월 Meena와 Jamie는 법무팀과 엔지니어링 팀이 함께 일하는 방법에 대해 논의했습니다.

"우리는 아무도 속도를 늦추지 않고 책임감 있게 가야 하는 곳에 도달하기 위해 회사 및 모든 고객과 함께 걸음마를 떼고 있습니다."

Meena Polich: 우리가 제품을 이해하는 것은 정말 중요합니다. 우리가 판매하는 제품을 실제로 이해하지 못한다면 어떤 규정이 우리에게 영향을 미치거나 어떤 법률을 따라야 하는지에 대해 어떻게 회사에 조언할 수 있습니까? 매우 기본적인 수준에서 전략적 관점에서 우리는 지금 무엇을 판매하고 있는지 뿐만 아니라 무엇을 판매하고 싶은지, 어떻게 자신을 포지셔닝하고 성장시키고 싶은지 이해해야 합니다. 그런 식으로 우리는 법적 관점에서 주시해야 할 사항에 대한 예측을 시작할 수 있습니다. 그리고 우리가 회사 및 모든 고객과 협력하여 아무도 속도를 늦추지 않고 책임감 있게 가야 하는 곳에 도달하도록 하는 것만으로도 충분합니다. 보다 전술적인 접근 방식에서 회사 가치와 제품을 이해하는 것은 고객 및 공급업체와 협상하는 데 매우 유용합니다. 우리가 무엇을 하려고 하는지 이해할 때 훨씬 더 유리한 위치에 놓이게 됩니다. 그런 다음 공급업체에 설명할 수 있습니다.

반대로, 내가 고객과 협상할 때 많은 경우 테이블 반대편에 있는 사람들은 나보다 못하지는 않지만 기술적인 다른 변호사나 조달 대리인입니다. 따라서 제품이 무엇을 하는지 설명할 수 있는 변호사는 "법적 위험 관리 관점에서 귀하의 우려 사항이 무엇인지 알고 있습니다. 하지만 플랫폼이 실제로 작동하는 방식은 다음과 같습니다. 제품이 실제로 작동하는 방식은 다음과 같습니다. 이것이 바로 여러분이 걱정하는 이 위험을 알리지 않는 이유입니다. 당신이 걱정하는 그런 위험을 촉발하지는 않을 것입니다.”

"저의 최우선 과제는 R&D가 우리가 이루고 있는 놀라운 발전을 방해하기 위해 여기 있는 것이 아님을 이해하도록 돕는 것입니다."

Jamie Osler: 이 방법은 양방향으로 작동하는 것 같습니다. 맞죠? R&D가 우려 영역이 어디에 있는지에 대한 높은 수준의 법적 개요를 더 잘 이해하고 있다면 의도하지 않게 위험하거나 해당 법률을 위반하는 일을 하거나 제품을 만드는 것을 방지하는 데 도움이 됩니다.

Meena Polich: 네, 물론입니다. 그리고 그것은 R&D와 법적인 관계를 구축할 때 빼거나 집중해야 할 가장 중요한 것입니다. 나의 최우선 순위는 내가 우리가 만들고 있는 놀라운 발전을 방해하기 위해 여기에 있는 것이 아니며 우수한 제품으로 시장에 계속 출시하는 것을 방해하기 위해 여기 있는 것이 아니라는 것을 R&D가 이해하도록 돕는 것입니다. 우리 팀은 우리가 성장하고 회사의 모든 개인이 하는 모든 일을 감시하는 것이 더 어려워짐에 따라 윤리적으로 계속 수행하고 법의 테두리 내에서 계속 수행할 수 있도록 합니다. 그리고 우리가 할 수 있을 때 그 위험을 관리하려고 노력합니다.

이것이 설계에 의한 규정 준수가 중요한 이유 중 하나입니다. 규정 준수 요구 사항 또는 규정 준수 기대치를 염두에 두고 이를 위해 설계하면 많은 경우에 우리가 수행하는 설계 변경은 실제로 수익에 도움이 될 것입니다. 리소스 할당과 관련하여 초기 비용이 있을 수 있지만 장기적으로, 심지어 초장기적으로는 그렇지 않습니다. 많은 경우 해당 기능을 출시한 후 6개월에서 1년 이내에 놀라운 이점을 보게 될 것입니다. 매출 성장, 우리가 생성한 리드 유형, 고객이 우리를 신뢰하기 때문에 끌어들이는 측면에서.

Liam Geraghty: Engineer Chats 를 만든 Jamie Osler, 새로운 호스트 Brian Scanlan, 그리고 내부 채팅을 외부로 허용해 준 모든 손님에게 감사드립니다. 오늘 쇼가 재미있었다면 리뷰를 남기거나 소셜에서 칭찬을 아끼지 않으시겠습니까? 우리는 당신이 생각하는 것을 보고 듣는 것을 좋아합니다. 오늘은 여기까지입니다. 다음 주에는 Inside Intercom의 또 다른 에피소드로 돌아오겠습니다.