GN⁺: 타스넵 서비스 중단 사후 분석

• Tarsnap 장애로 인해 서비스가 오프라인 상태가 되었습니다.
• 장애는 Amazon의 EC2 us-east-1 지역에 호스팅된 중앙 Tarsnap 서버의 시스템 상태 확인 실패로 인해 발생했습니다.
• 고장의 정확한 원인은 알려지지 않았지만, 고립된 하드웨어 오류로 추정됩니다.
• Tarsnap의 모니터링 시스템이 고장을 감지하고 운영자에게 알림을 보냈습니다.
• 대체 EC2 인스턴스가 생성되었지만, 데이터 손실을 방지하기 위해 Tarsnap 서버 코드는 자동으로 다시 시작되지 않았습니다.
• 서버 재부팅 후 로그는 파일 시스템 손상을 보여주어 이전 서버를 복구하는 대신 새로운 서버를 설정하기로 결정되었습니다.
• 복구 과정은 Amazon S3에서 메타데이터 헤더를 읽고 작업을 로컬에서 다시 실행하는 것을 포함했습니다.
• 복구 과정에서는 기계 등록 로그 항목 및 초기화되지 않은 로그 항목 순서와 관련된 오류가 발생했습니다.
• 복구 과정은 예상보다 느리게 진행되었으며 더 빠른 성능을 위해 최적화될 수 있었습니다.
• 상태 복원 과정은 7월 3일에 완료되었으며 서버가 다시 온라인 상태로 돌아왔습니다.
• 장애 후 트래픽은 장애 시작 후 약 26시간 16분 후에 다시 시작되었습니다.
• Tarsnap은 장애로 인한 보상으로 사용자 계정에 한 달 저장 비용의 50%를 제공했습니다.
• 사용자들은 Tarsnap의 창립자인 Colin Percival에게 질문이나 걱정 사항을 문의할 것을 권장합니다.

[neo]

Hacker News 의견

• 이 기사의 편집자는 장애 이후에 모든 사람들의 Tarsnap 계정에 한 달 저장 비용의 50%를 지급했습니다.
• 이 편집자는 상황을 처리하는 데 있어서 관대하고 고객 중심적인 접근 방식으로 칭찬받고 있습니다.
• 이 편집자는 기사의 인기에 놀라움을 표현하며 개인적인 이유로 질문에 대답하기에 제한이 있다고 언급합니다.
• 한 댓글러는 추가적인 장애 시간을 휴식으로 교환하는 것이 문제 해결에 도움이 될 수 있다고 제안합니다.
• 정기적으로 복구 과정을 테스트하는 것이 버그나 문제를 식별하고 해결하는 데 도움이 됩니다.
• 이 사후 분석은 전문성, 예의, 정직성을 감사받고 있습니다.
• 댓글러는 장애 복구 단계를 설정하고 테스트하여 향후 다운타임을 최소화하는 것을 권장합니다.
• 비슷한 사건에서 비즈니스의 회복력을 향상시키기 위해 파트 타이머 고용을 제안합니다.
• 잠재적인 사용자들에게는 단일 개인, 이 경우 Colin Percival에 의존하는 위험이 언급됩니다.
• 2014년의 코드 오류가 장애의 원인으로 확인되어 이와 같은 문제를 잡기 위해 TLA+ 모델링을 사용하는 것을 권장합니다.
• Tarsnap 웹사이트의 인프라 페이지는 장애를 반영하기 위해 업데이트되어야 합니다.
• Tarsnap의 암호화 소프트웨어를 Dropbox와 통합하여 안전한 데이터 저장을 할 수 있는지에 대한 질문이 제기됩니다.