이 가이드에서는 효과적인 지원 케이스를 작성하기 위한 권장사항을 제공합니다. 이러한 권장사항은 기술 지원 케이스를 더 빠르게 해결하는 데 도움이 됩니다.
지원 케이스 만들기
지원 케이스를 만들기 전에 알려진 문제를 검토하여 해당 케이스가 이미 제출되었는지 확인하세요.
혼란을 방지하고 단일 지점에서 요청을 추적할 수 있도록 문제당 하나의 지원 케이스를 만드세요. 생성된 모든 중복 케이스는 종료됩니다.
문제 설명
지원 케이스를 자세히 작성하면 Customer Care팀에서 더 빠르게 효율적으로 응답할 수 있습니다. 지원 케이스에 중요한 세부정보가 누락되어 있으면 추가 정보를 요청해야 하므로 시간이 추가로 소요됩니다.
자세하고 구체적인 지원 케이스가 가장 좋습니다. 이러한 지원 케이스는 발생한 문제와 원래 예상했던 결과를 알려줍니다. 지원 케이스에서 문제를 기술할 때는 다음 세부정보를 포함하세요.
- 시간: 문제가 시작된 구체적인 타임스탬프입니다.
- 제품: 문제와 관련된 제품 및 기능입니다.
- 위치: 문제가 발생한 영역입니다.
- 식별자: 프로젝트 ID 또는 애플리케이션 ID 및 문제를 조사하는 데 도움이 되는 기타 구체적인 식별자입니다.
- 유용한 아티팩트: 문제 진단을 돕기 위해 고객이 제공할 수 있는 세부정보입니다.
- 문제 유형: 문제가 간헐적인지 일시적인지 또는 지속적인지를 나타냅니다.
다음 섹션에서 이러한 개념을 보다 자세히 설명합니다.
시간
날짜 및 타임스탬프에 ISO 8601 형식을 사용할 경우 이 문제를 처음 관찰한 시점과 문제가 지속된 기간을 알려주세요.
예를 들면 다음과 같습니다.
- 2017-09-08T15:13:06+00:00에 시작하여 5분 후에 종료되었으며 다음이 관찰됨
- 간헐적으로 관찰됨. 2017-09-10 이후에 시작되었으며 2~5회 관찰됨
- 2017-09-08T15:13:06+00:00 이후 계속됨
- 2017-09-08T15:13:06+00:00~2017-09-08T15:18:16+00:00
이 문제를 해결하는 Customer Care 전문가가 고객과 같은 시간대에 있지 않을 가능성이 매우 높으므로 다음과 같은 상대적 문을 사용하면 문제를 진단하기가 더욱 어려워집니다.
- "이 문제는 어제 어느 순간부터 시작되었습니다."(의미하는 날짜를 엔지니어가 추론해야 합니다.)
- "9/8에 문제를 확인했습니다." (9월 8일로 해석하는 사람도 있고 8월 9일로 해석하는 사람도 있으므로 모호합니다.)
제품
기본 기록 양식에 제품 이름을 지정하도록 되어 있지만 구체적으로 해당 제품의 어떤 기능에서 문제가 발생하고 있는지 정보가 필요합니다. 신고서에 특정 API나 Google Cloud URL(또는 스크린샷)을 언급하는 것이 가장 좋습니다. API의 경우 URL에 제품 이름이 포함된 문서 페이지에 연결할 수 있습니다.
요청을 시작하는 데 사용하는 메커니즘(예: REST API, Google Cloud CLI, Google Cloud 콘솔 또는 Cloud Deployment Manager와 같은 도구)도 알려주세요. 제품 여러 개가 포함된 경우 각 제품 이름을 구체적으로 알려주세요.
예를 들면 다음과 같습니다.
- "Compute Engine REST API에서 다음 오류를 반환했습니다."
- "console.cloud.google.com의 BigQuery 쿼리 인터페이스가 멈추었습니다."
다음과 같은 문구는 구체적이지 않아 문제를 진단할 때 어떤 부분을 조사해야 하는지 알 수 없습니다.
- "인스턴스를 만들 수 없습니다."(Google에서는 인스턴스를 만들기 위해 사용 중인 방법을 알아야 합니다.)
- "
gcloud compute create instances명령어에서 오류가 발생합니다."(명령어 구문이 올바르지 않으므로 Google에서 해당 명령어를 실행하여 오류를 재현할 수 없습니다. 실제로 발생한 오류가 어떤 것인지도 알 수 없습니다.)
위치
Google에서는 종종 한 번에 한 리전 또는 한 영역에 변경사항을 배포하기 때문에 고객의 데이터 센터가 소재한 리전 또는 영역을 알아야 합니다. 리전 및 영역은 기본 소프트웨어의 버전 번호에 대한 프록시입니다. 이 정보는 특정 소프트웨어 버전의 브레이킹 체인지가 사용자의 시스템에 영향을 미치는지 파악하는 데 도움이 됩니다.
예를 들면 다음과 같습니다.
- "us-east1-b에서"
- "us-east1 및 us-central1 리전을 사용했습니다."
식별자
구체적인 식별자가 있으면 문제가 발생한 Cloud 프로젝트를 쉽게 식별할 수 있습니다. 프로젝트의 영숫자 ID나 애플리케이션 ID가 반드시 필요합니다. 프로젝트 이름은 도움이 되지 않습니다. 문제가 여러 프로젝트에 영향을 주는 경우 영향을 받는 ID를 모두 포함해 주세요.
프로젝트 ID 또는 애플리케이션 ID 외에도 다음과 같은 여러 가지 식별자를 알려주시면 기록을 진단하는 데 도움이 됩니다.
- 인스턴스 ID
- BigQuery 작업 ID 또는 테이블 이름
- IP 주소
IP 주소를 명시할 때 IP 주소가 사용되는 컨텍스트도 알려주세요. 예를 들어 IP가 컴퓨팅 인스턴스, 부하 분산기, 커스텀 경로 또는 API 엔드포인트 중 어디에 연결되어 있는지 구체적으로 적어 주세요. 또한 IP 주소가 Google 시스템과 관련이 없는 경우(예: IP 주소가 집 인터넷, VPN 엔드포인트 또는 외부 모니터링 시스템용인 경우) 알려주세요.
예를 들면 다음과 같습니다.
- "프로젝트 robot-name-165473 또는 my-project-id에서"
- '여러 프로젝트에서(my-project-id 포함)'
- '회사 게이트웨이 56.56.56.56에서 Google Cloud 외부 IP 218.239.8.9에 연결'
다음과 같은 일반적인 문구는 너무 일반적이어서 문제를 진단하는 데 도움이 되지 않습니다.
- "인스턴스 중 하나에 연결할 수 없습니다."
- "인터넷에서 연결할 수 없습니다."
유용한 아티팩트
문제와 관련된 아티팩트를 제공하면 발생한 문제를 정확하게 파악하는 데 도움이 되므로 문제 해결 속도를 높일 수 있습니다.
예를 들면 다음과 같습니다.
- 스크린샷을 사용해 발생한 문제를 정확하게 보여줍니다.
- 웹 기반 인터페이스의 경우 관련 브라우저 trace 정보를 제공합니다.
- tcpdump 출력, 로그 스니펫, 스택 추적 예시를 첨부합니다.
문제 유형
간헐적: 간헐적 문제는 규칙적인 장애 패턴 없이 무작위로 발생합니다. 간헐적 문제는 불규칙하므로 장애 발생 시 데이터를 수집하기 어려워 문제 해결이 어렵습니다. 이 경우 아키텍처의 병목 현상을 파악하고 리소스가 최대 기준점 사용량에 도달했는지 확인해야 합니다. 또한 자동화를 사용하여 예약된 작업을 정기적으로 자주 검사하고 검사에 실패하면 장애 발생 시 디버그 정보를 수집해야 합니다. 이러한 유형의 대표적인 장애는 DNS 변환 오류 및 패킷 손실입니다.
일시적: 일시적 문제는 순간적이거나 단기적으로만 발생합니다. 1초 또는 수 마이크로초 정도만 문제가 발생하는 경우 트래픽에서 경미한 버스트가 발생했거나 리소스 최고 사용률에 도달했는지 확인해야 합니다. 대부분의 경우 일시적 문제는 자주 재발하지 않고 서비스가 일시적 장애를 허용하도록 설계된 경우에는 무시할 수 있습니다. 이러한 유형의 대표적인 장애는 수 마이크로초 동안만 발생하는 네트워크 지연 시간 급증, 시간 초과를 초래하는 소규모의 패킷 손실입니다. 전송 제어 프로토콜(TCP)은 소규모 패킷 손실이나 지연 시간 급증과 같은 장애를 방지하기 위해 설계되었으며, 애플리케이션이 지연 시간에 민감하지 않은 경우 이러한 문제를 효과적으로 처리할 수 있습니다.
지속적: 지속적 문제는 웹사이트가 다운되는 등의 완전한 장애 문제가 발생하는 경우입니다. 지속적 문제는 재현 가능하므로 문제 해결이 비교적 간단합니다. 이 경우 Customer Care 전문가가 환경을 재현하고 문제를 해결할 수 있도록 문제 재현 방법을 알려주세요.
설명 예시
다음 예시에서는 지원 케이스를 자세히 설명합니다.