GitLab, 자사의 데이터 손실 복구 과정을 생중계하다

2017년 1월 31일, 복제 문제를 해결하려던 지친 GitLab 엔지니어가 보조 복제본이 아닌 회사의 주 프로덕션 데이터베이스 디렉터리를 실수로 삭제하여 프로젝트, 댓글, 이슈, 사용자 계정을 포함한 약 300GB의 실시간 데이터를 지워버렸다. 팀이 서비스 복구를 위해 분주히 움직이던 중, 그들은 두 번째이자 훨씬 더 심각한 문제를 발견했다. GitLab의 다섯 가지 공식 백업 메커니즘 전부—예약된 덤프, 디스크 스냅샷, 복제—가 몇 주 동안 조용히 실패하고 있었으며, 일부는 버전 불일치 때문이었고, 경고를 전혀 발생시키지 않았다.

이 정도로 심각한 재난—실제 데이터 손실에 더해 회사조차 몰랐던 전면적인 백업 실패—에 대한 기업의 표준 대응은 조용히 침묵하고, 이야기를 신중하게 관리하며, 사실과 법적 노출이 완전히 파악된 후에 통제된 성명을 발표하는 것이다. 위기 한복판에 있던 GitLab 팀은 반대의 선택을 했다. 무슨 일이 일어났는지 파악하는 동안 문을 닫고 물러나는 대신, 사건이 아직 해결되지 않고 결과가 불확실한 상황에서도 사건을 실시간으로 대중에게 공개해 두었다.

GitLab은 모든 백업이 실패했다는 사실의 발견을 포함해 복구 과정을 생중계했으며, 이는 극단적 투명성을 값비싼 신호로 만들어 미사여구 대신 신뢰를 구축했다.

극단적 투명성은 값비싼 신호였고, 그 설명이 진실임을 입증했다.

대중은 검열되지 않은 분투를 보았고, 이는 그 서사를 신뢰할 수 있게 만들었다.

상세한 사후 분석과 공개된 수정 조치는 개선에 대한 의지를 보여주었다.

심각한 실패가 발생했을 때, 극단적인 실시간 투명성은 통제되고 지연된 성명보다 더 많은 신뢰를 구축할 수 있다.

복구 생중계는 최고조에 동시 시청자 5,000명을 넘었으며, GitLab의 평판을 훼손하기는커녕 투명한 처리는 기술 업계 전반에서 폭넓은 대중의 공감과 존경을 불러일으켰다. 당시와 그 이후의 논평은 불투명하게 처리되었다면 심각한 신뢰 위기가 되었을 사건으로부터 GitLab의 평판이 사실상 손상되지 않았다고 일관되게 평가한다. GitLab은 사후 분석에 이어 구체적인 수정 사항을 추적하는 수십 개의 공개 엔지니어링 이슈를 만들어, 고객이 정확히 무엇이 바뀌고 있는지 직접 확인할 수 있게 했다.