제가 보기엔, 진정 도움이 되는 글을 쓴다면 제목이 이렇게 되야 하지 않을까요 ?
"노드 설정 미스로 인해 클러스터 불가 에러 발생 원인 분석 및 교훈"
그런 글은 따로 쓰면 되는 이야기고, ”장애 원인 분석“ 과 ”장애 해결 과정“ 은 별도의 토픽이고 둘 다 중요한 이야기인데, ”장애원인 분석“ 이 없었다고 글의 가치를 까내리는 행동은 이해하기 힘드네요...
원인 분석 글 도 후속으로 써주면 더욱 좋을 것 같다고 말씀하시면 되는데, 그 전에 가치없다고 말씀하시는건 좋은 태도는 아니네요.
엄밀하게 말하자면 '장애 해결 과정' 아니고, "불완전한 데이터 복구 노가다" 과정입니다. 단지 손실 범위를 좀 줄였다? 이 정도.
위 글에 데이터 복구가 “불완전”하다는 내용이 어디 있습니까? 적어도 위 글 내용상으로는 완전 복구에 성공했다는데요. 그리고 날려먹은 DB를 복구한 게 장애 해결이 아니면 뭡니까? 저 사건 이후로 해당 서비스가 그대로 운영을 종료했나요?
결과적으로 뽑아낸 파일에 모든 사용자 데이터가 정확하게 담겨있음을 확인할 수 있었습니다.
- 기본적으로 그 이야기는 아예 다른 글에서 하고 있습니다. 제목을 붙일 글부터가 틀렸습니다.
- 그 다른 글을 읽어보면, 장애가 시작된 가장 근본적인 원인은 스크립트 파일에 들어간 경로가 잘못된 것과 그것을 피어 리뷰하지 않고 그냥 써먹은 게 문제였습니다. 제목에 딱히 그런 정보가 들어가 있지 않으니, 오히려 별로 도움이 안되는 제목 같습니다.
- 무엇보다도, 제목이 노잼입니다. 그런 제목을 가진 글을 원하시면 그냥 학술지 혹은 사고 보고서를 찾아보시기 바랍니다. 글을 발표하는 매체의 특성을 생각하지 않고 제목을 짓는 것은 좋은 생각이 아닙니다.
- 그래서 “장애 처리하면서 바이너리 변환하느라 고생한 얘기”를 하지 말아야 할 이유는 뭐죠?
"CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기" --> 제목이 너무 웃겨서요. 궁금한게 해소 됬습니까 ?
저렇게 거창하게 제목 달아서 할 얘기가 아닌듯 해서요. 그냥 오픈 소스 중 바이너리 포맷 알아서 변환해서 csv 로 저장해서 다시 읽었습니다. 한줄이면 끝. 근데 제목이 참... 아주 그냥 뿌듯한 듯... 거~~~~~~~창 하네 그려.
의도치 않은 설정 미스 (이게 가장 크리티컬한 어처구니없는 휴먼 에러. 복제본 동작을 못하게 끔 만드는 엄청난 조작을 이런 식으로 저질러 버린 것, db 설계 개발자를 다 데려와도 이건 복구가 안됨)
그래서 데이터를 통째로 날릴수는 없으니... 최신 데이터 정합성은 포기 하고라도 최종 저장된 바이너리 형태의 DB 데이터를 직접 찾아서 (7 TB) 이걸 csv 로 변환하기 위해 go 프로그램을 작성... ?
이거 변환 go 프로그램 만드는 게 그거 아무리 잘 만들어도 뭔 의미가 있을까..
휴.. 참 생각만해도 답답하군요. 왜 이래야만 했을까..
이런 휴먼 에러 안나게 프로세스를 강화하는게 제일 중요하겠네요. 장애 처리하면서 바이너리 변환하느라 고생한 얘기는 하지 말고.