SLI, SLO, SLA 정리에서 가용성 SLO를 30일 동안 99.9%로 잡으면 "0.1%까지는 실패해도 된다"는 허용량이 생긴다고 했는데요. 이 허용량을 어떻게 부르느냐가 생각보다 중요합니다. "허용 오차"라고 부르면 넘지 말아야 할 선처럼 들리지만 "예산"이라고 부르는 순간 질문이 바뀌거든요. 남은 예산을 어디에 쓸까? 🤔 이게 에러 예산(error budget)이라는 개념의 전부입니다. 실패해도 되는 양을 쓸 수 있는 자원으로 보는 거예요. 이 글에서는 에러 예산이 무엇인지, 예산이 남았을 때와 바닥났을 때 무엇을 하기로
온콜 정리의 끝에서 남겨 둔 질문이 있었죠. 오류율 알림의 임계값을 5%로 할지 1%로 할지를 놓고 팀 안에서 의견이 갈리는 상황이요. 개발 쪽은 "1%는 너무 빡빡해서 배포할 때마다 울린다"고 하고, 운영 쪽은 "5%면 사용자 스무 명 중 한 명이 실패하는 건데 그걸 그냥 둘 거냐"고 합니다. 둘 다 틀린 말은 아닌데 대화가 끝나지 않아요. 🤔 이 논쟁이 안 끝나는 이유는 "우리 서비스가 얼마나 실패해도 괜찮은가"를 먼저 정하지 않았기 때문입니다. 그 기준을 세우는 도구가 SLI, SLO, SLA인데요. 비슷하게 생긴 세 약어가
알림 규칙을 공들여 만들어 놨다고 해 볼게요. 그런데 알림이 채팅 채널 하나에 전부 쏟아지고 있습니다. 낮에는 누군가 보고 반응하지만 새벽에는 아무도 안 봐요. 반대로 팀 전원에게 전화가 가도록 해 둔 팀도 있는데 다들 "누가 보겠지" 하고 다시 잠듭니다. 😅 규칙은 제대로 발동했는데 사람에게 닿지 않은 거죠. 알림이 발동한 순간부터 누군가 대응을 시작하는 순간까지, 그 사이의 경로를 설계하는 게 이 글의 주제입니다. 알림을 어디로 보낼지, 누가 받을지, 못 받으면 어떻게 할지, 그리고 알림이 너무 많아지면 무슨 일이 생기는지를
새벽 3시에 결제 API가 죽었는데 아침 9시에 출근해서 대시보드를 열어 보고서야 알았던 경험, 혹시 있으신가요? 😅 대시보드는 있었습니다. 그래프도 정확했고요. 오류율이 치솟은 시각까지 그대로 그려져 있었죠. 문제는 그 여섯 시간 동안 아무도 그 화면을 보고 있지 않았다는 겁니다. 이런 일을 겪고 나면 "대시보드를 더 잘 만들어야겠다"는 결론으로 가기 쉬운데요. 사실 대시보드가 아무리 좋아져도 문제는 해결되지 않습니다. 대시보드와 알림은 하는 일이 다르기 때문입니다. 이 글에서는 둘의 역할이 어떻게 나뉘는지, 알림 규칙이 무엇으