서버가 00:32에 전원을 잃었지만 우리는 08:18에야 알았다
A Server Lost Power at 00:32. We Found Out at 08:18
2026년 8월 17일, Danube Data의 스토리지 서버 한 대가 전원을 잃고 8시간 15분 동안 다운되었습니다. S3 호환 객체 스토리지, 컨테이너 레지스트리, 서버리스 배포가 모두 중단되었지만, 기존 워크로드는 정상 작동했고 데이터 손실은 없었습니다. 문제는 서버가 죽은 사실을 아무도 몰랐다는 점입니다. 상태 페이지는 3분 만에 장애를 감지했지만, 엔지니어가 08:18에야 우연히 발견했습니다. 근본 원인은 객체 데이터의 erasure coding 청크가 서로 다른 머신에 분산되지 않아 한 대의 서버 손실로 전체 서비스가 중단된 것이었습니다. 또한 내부 부기 기록이 같은 머신에 중복 저장되어 읽기 장애가 완전한 연결 거부로 이어졌습니다. 같은 날, 온콜 전화 알림과 서버 전원을 자동으로 켜는 감시 시스템을 도입했지만, 스토리지 레이아웃과 용량 여유분은 아직 해결되지 않았습니다.
시스템이 아는 것과 사람이 아는 것 사이의 그 간격이 실제 사고입니다. 나머지는 모두 세부사항일 뿐입니다.
- danieka
이 사건은 호스팅 제공업체로서는 다소 당황스러운 일입니다. 그리고 기사는 분명히 LLM으로 작성되었습니다. PR 관점에서 보면 이는 특이한 조합입니다. 약간의 공감과 인간적인 손길이 있었더라면 좋았을 것입니다. 사고와 중단은 발생할 수 있지만, LLM이 쓴 기사를 읽으면 아무도 무슨 일이 일어났는지 신경 쓰지 않는 것 같은 느낌이 듭니다.
- walrus01
명백히 LLM이 작성한 글입니다.
페이지 자체의 매우 긴 내용에 관해서는, 서버 부재는 가장 기본적인 librenms나 opennms 유형의 모니터링 및 경보 시스템에서도 감지되었어야 합니다. 경보가 이메일로 한 사람에게만 갔다고요? 어이없네요....
- jefftk
명백히 LLM이 작성했고, 최소 6대의 서버를 대상으로 설계된 구성을 4대로 운영하고 있었던 것을 설명하고 있습니다. 그들은 어느 쪽인지 밝히지 않지만, 3개의 청크를 단일 머신에 쓰고 한 머신의 장애로 데이터를 잃었을 가능성도 있는 것 같습니다.