서비스 런북 웹사이트 디자인

auth-service 런북 디자인

이 OpenDesign 공식 웹사이트 예시는 Northwind 아이덴티티 서비스 런북을 하나의 운영 참조 문서로 보여 줍니다. 작성된 제목은 “auth-service”이며, 그 뒤에 소유 팀, 버전, 검토일, “TIER 0 · PRODUCTION-CRITICAL” 상태가 이어집니다. 이 도입부는 독자가 알림이나 명령에 이르기 전에 서비스의 책임 범위를 먼저 알려 줍니다.

서비스 요약은 웹, 모바일, 공개 API 전반에서의 세션 토큰 발급, 검증, 폐기를 명시합니다. 또한 비밀번호 저장소, TOTP/WebAuthn 등록 정보, 감사 로그 기록기도 밝힙니다. 덕분에 이 페이지는 상황 파악에 유용합니다. 대응자는 절차를 고르기 전에 이 서비스가 맡은 고객 대상 책임과 보안 관련 책임이 무엇인지 확인할 수 있습니다.

지원하는 운영 업무

이 디자인은 여러 관련 업무를 별도 페이지로 나누지 않고 한 페이지에서 지원합니다. 순서는 서비스 범위에서 의존성, 알림, 절차, 온콜 담당 체계, 장애 대응으로 이어집니다. 이 흐름 덕분에 알림을 따로 떼어 해석할 필요가 줄어듭니다. 독자는 먼저 서비스가 무엇을 소유하는지 알고, 그다음 일부가 손상되었을 때 어떻게 대응할지 알게 됩니다.

의존성 목록은 Postgres, Redis, KMS, SES, Pager에 대해 이름과 상태 패턴을 반복합니다. 네 항목은 정상(healthy)으로, SES · transactional은 성능 저하(degraded)로 표시됩니다. 오른쪽 정렬된 상태 값은 훑어보기에 도움이 되지만, 샘플 디자인의 스냅샷일 뿐 실제 헬스 체크가 작동함을 보여 주는 것은 아닙니다.

알림에서 절차까지

알림 섹션은 알림, 심각도, 의미, 최초 대응의 네 열로 이루어진 의사결정용 화면으로 설계되었습니다. 예를 들어 “auth.login_5xx_rate greater than 1%”는 “SEV-1”, 고객 로그인 차단에 대한 설명, Postgres와 Redis 대시보드를 확인하라는 안내와 짝을 이룹니다. 명시적인 임계값은 대응자에게 트리거를 제공하고 설명문은 해석을 보완합니다. 다만 실제 런북에서는 이 샘플 값에 검증된 모니터링 출처가 여전히 필요하다는 절충점이 있습니다.

절차 섹션은 간결한 행에서 제목, 사용 안내, 설명 문장, 명령 패널을 갖춘 큰 블록으로 리듬이 바뀝니다. “Deploy a new version”은 이 흐름이 블루/그린 방식이며 승격 전에 연속 두 번의 헬스 체크를 기다린다고 밝힙니다. 화면에 보이는 트래픽 순서 “10% / 50% / 100%”는 단계적 롤아웃을 전달하며, 더 큰 블록은 세로 공간을 더 차지하는 대신 명령 수준에서 더 안전하게 읽을 수 있게 합니다.

명령과 제약 조건

절차 블록은 조치와 주의 사항을 나란히 둡니다. 롤백은 배포 후 오류율이 1%를 넘을 때 사용하도록 표시되어 있고, 서명 키 교체에는 “Schedule with security; never solo”라고 적혀 있습니다. 감사 로그 절차는 백로그 알림과 명시적으로 연결됩니다. 이러한 짝짓기는 명령만으로는 충분하지 않으며, 주변 조건이 그 명령이 워크플로의 어느 지점에 속하는지 정의한다는 유용한 정보 설계 선택을 보여 줍니다.

장애 대응 순서와 기능의 한계

마지막 장애 대응 섹션은 첫 30분을 번호가 매겨진 다섯 장의 카드로 바꿉니다. 순서는 5분 이내 확인(acknowledge)으로 시작해 전용 장애 채널을 열고, 10분마다 상태 스냅샷을 요구하며, 완화를 우선하고, 인수인계 또는 종료로 끝납니다. 번호는 의도한 순서를 눈에 보이게 하고, 2단 배치는 처음 네 가지 조치를 간결하게 유지하며, 다섯 번째 카드는 자기 내용만큼만 폭을 차지합니다.

이 페이지는 디자인 전용 웹사이트 예시입니다. 캡처된 페이지에는 명령, 상태, 이름, “rolled back to v4.7.2 in 38 s” 같은 샘플 결과가 보이지만, 해당 명령이 실행된다거나 서비스가 연결되어 있다거나 표시된 운영 결과가 측정되었다는 점은 입증하지 않습니다. 이를 응용할 때는 문서화된 안내와 검증된 런타임 데이터의 구분을 유지해야 합니다.

1. 호출 확인하기

   디자인은 /ack와 5분의 대응 시간으로 시작하며, 첫 번째 조율 의무를 분명히 합니다.

2. 장애 채널 열기

   두 번째 카드는 전용 대응 공간을 만들 때 쓰는 서비스 이름과 짧은 제목 패턴을 보여 줍니다.

3. 상태 스냅샷 공유하기

   세 번째 카드는 고객 영향, 현재까지 파악한 내용, 다음 확인 사항을 반복 가능한 업데이트로 압축합니다.

4. 완화 후 인수인계하기

   마지막 두 카드는 롤백 또는 보안 에스컬레이션을 우선하고, 이어서 인수인계와 종료를 정의합니다.