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