알림 메일은 보냈는데 고객은 못 받았다면: SPF·DKIM·DMARC와 반송 관리
발송 API 성공은 수신함 도착을 뜻하지 않습니다. 도메인 인증, 발신 도메인 정렬, 반송·불만 처리와 업무 알림의 최종 상태를 운영 관점에서 설명합니다.
NOTES
서비스 운영
모델을 만들고, 웹과 앱을 짓고, 업무를 자동화하며 확인한 것을 기록합니다. 통한 방법만이 아니라 통하지 않았던 시도까지 남깁니다.
TOTAL 7 · 서비스 운영
장애가 나면 누가 무엇부터 할까? 플레이북과 사후 분석을 만드는 법
장애 대응은 알림을 받는 것에서 끝나지 않습니다. 영향 파악, 역할 분담, 복구, 고객 공지, 사후 분석을 연결하는 작은 팀의 운영 플레이북 설계법입니다.
외부 API가 느려질 때 우리 서비스까지 멈추지 않으려면: 타임아웃·재시도·회로 차단
결제·배송·문자 같은 외부 연동은 실패할 수 있습니다. 요청 마감시간, 중복 안전성, 재시도 예산, 회로 차단과 대체 응답을 함께 설계하는 방법을 설명합니다.
서버는 살아 있는데 고객은 장애를 겪는다: 사용자 여정으로 정하는 SLO
서버 가동률만으로는 고객의 주문·신청·조회 실패를 설명하기 어렵습니다. 핵심 사용자 여정에서 SLI와 SLO를 정하고 오류 예산을 운영 결정에 쓰는 방법을 정리합니다.
메일을 보냈는데 고객은 못 받았다면? 업무 알림의 발송 상태와 재시도 설계
메일 API의 성공 응답은 고객이 읽었다는 뜻이 아닙니다. 업무 이벤트에서 알림을 분리하고, 전달 상태·반송·중복·수신 설정까지 관리하는 방법을 설명합니다.
백업은 있는데 복구가 안 된다면? RPO·RTO로 설계하는 복구 리허설
백업 파일이 생성됐다는 알림만으로 서비스 복구를 보장할 수는 없습니다. RPO·RTO를 업무 기준으로 정하고, DB·업로드 파일·설정을 함께 복원해 실제 사용자 흐름까지 확인하는 방법을 설명합니다.
서버는 정상인데 사용자는 왜 느릴까? 로그·메트릭·트레이스로 원인 찾기
CPU와 메모리가 정상이어도 사용자는 결제 실패와 지연을 경험할 수 있습니다. 구조화 로그, 메트릭, 분산 트레이스, SLI·SLO와 오류 예산을 연결해 실제 장애 원인을 찾는 관측 가능성 설계를 정리합니다.