시행착오 겪으며 성장하기
외부 시스템 연동 시 주의할 점
p-291
외부 시스템 문제로 장애가 발생했어도 고객은 원인을 인지할 수 없기 때문에 우리 서비스에 대한 고객 경험 하락과 함께 부정적인 인식이 생길 수 있습니다. 그렇기 때문에 외부 시스템을 연동할 때는 반드시 그 시스템의 장애가 우리 서비스의 장애로 이어지지 않도록 주의를 기울여야 합니다. 조금의 장애도 발생하지 않는 서비스는 없기 때문에 항상 외부 시스템의 장애를 염두에 두고 연동해야 하며, 해당 시스템 장애 시에 우리 서비스의 영향 범위를 최소화할 수 있는 고민이 필요합니다.
장애를 대처하는 자세
p-295
외부 시스템의 장애를 완벽하게 제거하는 것은 불가능합니다. 하지만 이를 사전에 알고 적절한 조치를 함으로써 그 영향 범위를 줄여나가는 것은 여전히 중요합니다. 외부 시스템을 연동할 때는 충분히 고민해보고, 잘 지켜보고, 빠르게 대응하도록 많은 노력을 기울여야 합니다.
장애 대응
p-296 장애는 서비스의 성장, 서비스의 변화 등 다양한 과정 중에서 발생하는 성장통이기 때문에 장애가 발생하는 것을 원천적으로 차단할 방법은 없습니다. 그렇게 때문에 빠르고 적절히 장애에 대응해 신뢰도 하락을 최소화하는 일이 중요합니다.
장애 후속 조치
p-305 장애 복구가 완료되고, 서비스가 정상화되면 원인 파악과 재발 방지 대책 수립을 위해 장애 리뷰를 진행합니다. 장애 대응 조직에서는 보고서를 작성합니다.
장애 원인 분석
장애 원인을 찾는데 5whys 기법을 사용합니다. 이는 토요타에서 체계적인 문제 해결에 사용하기 위해 개발한 도구로, 어떠한 문제 상황에 대해 '왜 그렇게 상황이 발생했나요?' 라는 질문을 여러 번 반복해 나가며 문제의 근본 원인에 도달할 수 있는 방법론 입니다.
장애 리뷰에 적용하면서 아래 세 가지 포인트를 고려합니다.
첫 번째 질문은 항상 장애에 영향을 받은 고객의 관점에서 시작해야 합니다.
검증이 가능한, 혹은 검증된 사실에 기반해서 답변을 해야 합니다.
5번의 횟수는 상징적인 숫자로 꼭 질문이 5개일 필요는 없고, 더 적거나 더 많아도 됩니다.
재발 방지 대책 수립
근본 원인을 찾았다면 그 문제가 다시 발생하지 않도록 재발 방지 대책을 수립합니다. 이때 재발 방지 대책은 원인을 제거하는 데서 그치지 않고 더 빠른 탐지와 더 빠른 복구에 도움이 되는 모든 조치를 포함합니다.
이러한 조치로는 다음이 포함됩니다.
모니터링 지표 추가
설정 값 변경
코드 리뷰 절차 개선
배포 프로세스 수정
이러한 사항들을 고려하며 단기, 중기, 장기적으로 개선할 방안들을 도출합니다.
단기적: 부하가 발생하는 로직 개선, 이슈 발생 시 빠른 탐지를 위한 알림 강화
중, 장기적: 아키텍처 개선, 레거시를 제거하는 것과 같은 대규모 작업
장애 리뷰
장애 보고서가 작성이 되면 장애 리뷰를 진행합니다. 내부에서 정해진 장애 등급에 따라, 일부 장애는 팀/실 단위의 리뷰를 진행하고 대규모 장애의 경우 담당 팀, SRE팀 뿐만 아니라 조직장과 CTO까지 모두 리뷰에 참여합니다. 이렇게 많은 인원이 모여서 리뷰를 하는 이유는 더 넓은 범위를 살펴보기 위함입니다.
함께 고민하는 문화
p-309
장애에 대해서 터놓고 이야기하는 것이 쉽지는 않습니다. 장애가 발생한 도메인 담당자의 입장에서는 미안한 마음이 들어, 리뷰를 진행하면서 물어보는 입장에서는 혹시 불편해하지 않을까 고민이 되기 때문입니다. 하지만 우리가 이렇게 터놓고 이야기 할 수 있는 것은 장애에 대해 특정 개인이나 팀을 탓하지 않는다는 것을 모두가 알고 있기 때문입니다. 오늘 내가 한 실수는 내일 내 옆자리 동료도 할 수 있는 실수이고, 수백 명의 개발자가 잠재적인 위험을 안고 있다는 뜻일 수 있습니다.
작은 불씨일 때는 몇 명의 입김으로 불을 끌 수 있지만, 덮거나 숨기면 그 불씨는 더 커져서 산 하나를 홀랑 태워먹을 수도 있습니다. 감추고 숨기기 보다는 함께 해결하고 함께 고민하는 것이 장애 대응의 가장 중요한 핵심이며, 그렇게 할 수 있는 조직이 건강한 조직이라고 생각합니다.