그런 글은 따로 쓰면 되는 이야기고, ”장애 원인 분석“ 과 ”장애 해결 과정“ 은 별도의 토픽이고 둘 다 중요한 이야기인데, ”장애원인 분석“ 이 없었다고 글의 가치를 까내리는 행동은 이해하기 힘드네요...

원인 분석 글 도 후속으로 써주면 더욱 좋을 것 같다고 말씀하시면 되는데, 그 전에 가치없다고 말씀하시는건 좋은 태도는 아니네요.

엄밀하게 말하자면 '장애 해결 과정' 아니고, "불완전한 데이터 복구 노가다" 과정입니다. 단지 손실 범위를 좀 줄였다? 이 정도.

위 글에 데이터 복구가 “불완전”하다는 내용이 어디 있습니까? 적어도 위 글 내용상으로는 완전 복구에 성공했다는데요. 그리고 날려먹은 DB를 복구한 게 장애 해결이 아니면 뭡니까? 저 사건 이후로 해당 서비스가 그대로 운영을 종료했나요?

결과적으로 뽑아낸 파일에 모든 사용자 데이터가 정확하게 담겨있음을 확인할 수 있었습니다.

1. 기본적으로 그 이야기는 아예 다른 글에서 하고 있습니다. 제목을 붙일 글부터가 틀렸습니다.
2. 그 다른 글을 읽어보면, 장애가 시작된 가장 근본적인 원인은 스크립트 파일에 들어간 경로가 잘못된 것과 그것을 피어 리뷰하지 않고 그냥 써먹은 게 문제였습니다. 제목에 딱히 그런 정보가 들어가 있지 않으니, 오히려 별로 도움이 안되는 제목 같습니다.
3. 무엇보다도, 제목이 노잼입니다. 그런 제목을 가진 글을 원하시면 그냥 학술지 혹은 사고 보고서를 찾아보시기 바랍니다. 글을 발표하는 매체의 특성을 생각하지 않고 제목을 짓는 것은 좋은 생각이 아닙니다.
4. 그래서 “장애 처리하면서 바이너리 변환하느라 고생한 얘기”를 하지 말아야 할 이유는 뭐죠?

"CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기" --> 제목이 너무 웃겨서요. 궁금한게 해소 됬습니까 ?

그건 이 이야기를 하지말아야할 이유가 아닌데요?

세상 참 힘들게 사시네요

저렇게 거창하게 제목 달아서 할 얘기가 아닌듯 해서요. 그냥 오픈 소스 중 바이너리 포맷 알아서 변환해서 csv 로 저장해서 다시 읽었습니다. 한줄이면 끝. 근데 제목이 참... 아주 그냥 뿌듯한 듯... 거~~~~~~~창 하네 그려.