Intercom의 데이터 인프라 팀이 확고한 원칙으로 증가하는 수요를 충족한 방법

회사를 확장하는 것은 결코 선형 프로세스가 아닙니다. 스타트업이 규모가 커지면 팀은 새로운 요구 사항에 빠르게 적응해야 하는 장애물에 직면하게 됩니다.

바로 2020년 말에 데이터 인프라 팀을 찾은 곳입니다. Intercom 전체의 팀이 통찰력을 얻고 중요한 프로세스를 실행할 수 있도록 데이터와 도구를 제공하며 그 어느 때보다 수요가 많았습니다. Intercom은 지난 몇 년 동안 큰 성장을 경험했으며 우리의 여정을 돕기 위해 믿을 수 없을 정도로 재능 있는 많은 사람들을 고용했습니다. 그 결과 우리 회사의 궤적이 빠르게 바뀌었습니다. 작년 말까지 우리 팀은 그 어느 때보다 수요가 많았습니다. 우리는 우리가 사용하던 인프라, 관행 및 프로세스가 새로운 규모에서 효율적으로 운영하는 데 어려움을 겪고 있음을 깨달았습니다.

데이터 인프라 팀은 전환점에 도달했습니다.

팀은 우리 시스템 내에서 발생하는 사소한 문제를 처리하는 데 대부분의 시간을 보냈습니다. 근본적인 문제를 살펴보고 사전에 인프라를 강화하는 대신 지속적으로 사후 대응적으로 작업했습니다. 우리에게는 단순히 시간이 없었습니다. 관리자로서 팀의 방향, 전략 및 전문성 개발에 집중하기보다 일상 업무에 뛰어들어 도와야 하는 경우가 많았습니다. 우리는 전환점에 도달했고 무엇인가를 바꿔야 한다는 것이 분명했습니다.

"우리는 목표에 따라 팀을 정렬하고 작업에 집중하기 위해 일련의 원칙을 수립했습니다."

그룹 엔지니어링 관리자인 Cormac McGuire가 팀에 합류했을 때 우리는 한 발 물러서서 정상 궤도에 오르기 위해 해야 할 일이 무엇인지 살펴보았습니다. 우리는 지식의 사일로화, 지속적인 컨텍스트 전환, 중요한 시스템 상태 문제의 우선순위 해제와 같이 과거에 블록 팀에서 보았던 몇 가지 문제를 발견했습니다. 이러한 문제를 해결하기 위해 우리는 팀을 목표에 맞추고 작업에 집중하기 위한 일련의 원칙을 수립했습니다.

Intercom에서 일하는 방식에 원칙이 필수적인 이유는 무엇입니까?

수년에 걸쳐 우리는 최고의 성과를 거두고 가장 행복한 팀이 업무 방식에 대해 사려 깊고 신중할 때 요구 사항을 더 잘 처리한다는 것을 배웠습니다. 우리는 원칙이 팀을 확장하고 정렬을 유지하면서 올바른 일을 하도록 신뢰하는 가장 좋은 방법이라는 것을 알게 되었습니다. 우리의 원칙은 효과가 있는 것과 그렇지 않은 것에 대해 배운 것에서 성장합니다.

다음은 우리가 해결해야 할 가장 시급한 문제와 각 문제에 적용한 원칙입니다.

문제 1: 문제 해결보다 속도 우선

우리는 프로젝트를 신속하게 제공하여 Intercom의 동료인 고객을 기쁘게 했지만 해결해야 할 핵심 문제를 이해할 충분한 시간을 허용하지 않았습니다. 사전 가정이 잘못된 것으로 판명되거나 시나리오가 간과되었다는 것을 깨달았을 때 완료된 프로젝트를 종종 다시 방문해야 했습니다.

원칙 1: 덜 하고 더 잘하라

더 적은 수의 작업을 수행하면 컨텍스트 전환이 줄어들고 문제를 완전히 이해하는 데 더 깊이 집중할 수 있습니다. 팀은 우리가 달성하기 위해 설정한 목표를 충족할 때까지 솔루션을 반복할 수 있는 더 많은 공간이 있습니다.

"더 적게 하고 더 잘하라"는 원칙을 채택한다는 것은 장기적으로 팀에 이익이 되도록 어려운 절충안을 만드는 것을 의미했습니다. 먼저, 다른 팀이 우리에게 체크인하는 대신 데이터의 진행 상황을 확인할 수 있도록 상태 서비스를 구축했습니다. 이렇게 하면 쿼리에 응답하는 데 사용할 시간이 확보되어 시스템에서 작업하고 궁극적으로 데이터 전달 속도를 높일 수 있습니다.

“우리는 문제가 해결될 때까지 한 가지에 집중해야 했고 다시 방문할 필요가 없다고 확신했습니다. 그래야만 다음 작업으로 넘어갈 수 있습니다.”

둘째, 매일 밤 최신 데이터를 가져오고 기존 데이터를 모두 새로 고치는 프로세스인 일일 ELT(추출, 로드, 변환)의 신뢰성에만 집중하기로 했습니다. 우리는 문제가 해결될 때까지 한 가지에 집중해야 했고 그것을 다시 방문할 필요가 없다고 확신했습니다. 그래야만 다음 작업으로 넘어갈 수 있습니다.

문제 2: 지식 사일로

우리의 데이터 인프라 팀은 소규모이므로 엔지니어는 일반적으로 개별적으로 프로젝트를 수행합니다. 팀의 다른 엔지니어들이 필요한 컨텍스트 없이 코드를 검토하는 것은 어려웠고, 기존 서비스에 문제가 발생하면 시스템에서 작업한 엔지니어만이 문제를 신속하게 해결할 수 있는 지식을 가지고 있었습니다.

“우리는 똑똑한 사람들이 똑똑한 일을 동시에 하도록 했습니다.”

그 엔지니어가 휴가를 가면 모든 작업이 중단됩니다. 우리 팀원들은 한 지역을 책임지는 유일한 사람이라는 사실에 곧 좌절했습니다. 요컨대, 우리는 똑똑한 사람들이 똑똑한 일을 동시에 수행하도록 했습니다. 우리는 엔지니어를 더 잘 지원하는 응집력 있는 프로세스를 만들어야 했습니다.

원칙 2: 문제에 짝을 지어라

모든 솔루션에는 최소한 두 명의 엔지니어가 작업해야 합니다. 엔지니어 2명 대신 1명을 배정한다고 해서 반드시 결과의 효율성이나 품질이 두 배가 되는 것은 아니며, 실패 지점의 위험이 증가할 뿐입니다. 프로젝트는 프로세스에 둘 이상의 관점이 포함될 때 항상 더 나은 결과를 산출합니다.

특정 영역 내에서 항상 질문에 답하거나 문제를 해결하는 사람이 있다는 사실을 알고 있으면 개별 엔지니어의 부담이 줄어들어 휴식을 취하거나 새로운 프로젝트로 이동하는 것이 더 쉬워졌습니다.

문제 3: 시스템 상태의 우선 순위가 낮음

시스템 상태 문제는 모든 서비스 운영의 일부입니다. 그러나 새로운 문제를 분류하고 우선 순위를 지정하는 효과적인 시스템이 없으면 대기 중인 엔지니어가 주관적으로 먼저 해결할 문제를 결정할 것입니다.

이러한 시스템 상태 문제가 발생했을 때 우리는 분석 데이터가 엄격하게 고객을 대상으로 하지 않으며 따라서 덜 중요하다고 생각했기 때문에 이러한 문제를 최우선 순위(P1)로 표시하는 것을 꺼렸습니다. 그러나 이러한 문제는 전체 시스템 상태에 영향을 미치고 우리 팀의 작업에 부정적인 영향을 미칠 가능성이 있습니다. 우리는 우리가 그것들의 우선 순위를 충분히 높게 지정하지 않았으며 시간이 지남에 따라 더 큰 문제를 일으키기 위해 복잡해지고 있다는 것을 깨달았습니다.

원칙 3: 시스템 상태는 항상 P1입니다.

기본 SLA(서비스 학습 계약)에 영향을 미치는 모든 시스템 문제는 최우선 순위(P1)입니다. 문제를 P1으로 표시하는 접근 방식을 재고해야 했습니다. P1을 긴급하고 고객을 방해하는 긴급 상황으로만 생각하지 않고 대신 중요한 프로세스의 선동자로 생각합니다.

이 원칙을 구현한 이후로 우리는 문제를 훨씬 더 효과적으로 처리했습니다. 시스템 상태 문제는 P1으로 플래그가 지정되며, 대기 중인 엔지니어가 새로운 P1 문제를 독립적으로 해결할 수 있는 충분한 컨텍스트가 없는 경우 팀은 문제의 근본 원인이 완전히 해결될 때까지 사전 예방 작업을 일시 중지하고 노력을 리디렉션합니다. 사건은 엔지니어링 팀 Slack 채널에 자동으로 기록됩니다. 즉, 문제에 대한 추가 컨텍스트나 통찰력이 있는 조직 전체의 모든 사람이 가능한 한 빨리 문제를 해결하기 위해 입력할 수 있습니다.

팀이 처리할 수 있는 사항에 대해 현실적이어야 합니다.

소규모 팀은 너무 많은 일을 하고 초점을 너무 얕잡아보고 장기적으로 더 많은 작업을 생성할 중요한 세부 사항을 놓치기 쉽습니다.

더 적게, 더 잘하고 시스템 상태를 최우선 순위로 두는 것은 프로세스의 다른 핵심 요소를 개선하고 사후 대응이 아니라 사전에 작업할 수 있는 보다 강력한 구조를 구축할 수 있음을 의미했습니다. 각 프로젝트에 두 명의 엔지니어를 할당함으로써 우리가 일하는 방식이 바뀌었습니다. Intercom의 가치 중 하나는 "우리는 더 멀리 함께 간다"이며, 이것은 우리가 이 접근 방식을 채택한 이후로 거듭거듭 입증되었습니다.

우리가 일하고 문제에 접근하는 방식에 관심이 있습니까? 우리는 당신과 이야기하고 싶습니다 - 우리의 열린 역할을 확인하십시오.