클라우드 지원 사용 시 권장사항

지원 기록을 자세히 작성하면 Google 지원팀이 더 빠르고 효율적으로 응답하기가 쉽습니다. 지원 기록에 중요한 세부정보가 누락되어 있으면 추가 정보를 요청드려야 해서 시간이 추가로 소요됩니다. 이 가이드에서는 Google이 기술 지원 기록을 해결하는 데 필요한 정보를 설명하여 문제가 더 빨리 해결되도록 합니다.

문제 설명

가장 좋은 보고서는 자세하면서도 구체적입니다. 이러한 보고서는 발생한 문제와 원래 예상했던 결과를 알려줍니다. 적절한 문제 보고서에는 다음 세부정보가 포함되어 있습니다.

  • 시간: 문제가 시작된 구체적인 타임스탬프입니다.
  • 제품: 문제와 관련된 제품 및 기능입니다.
  • 위치: 문제가 발생한 영역입니다.
  • 식별자: 프로젝트/애플리케이션 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

이 문제를 해결하는 지원 엔지니어가 고객과 같은 시간대에 있지 않을 확률이 매우 높으므로 다음처럼 상대적 문구를 사용하면 문제를 진단하기가 더 어렵습니다.

  • "이 문제는 어제 어느 순간부터 시작되었습니다."(의미하는 날짜를 엔지니어가 추론해야 합니다.)
  • "9/8에 문제를 확인했습니다."(9월 8일로 해석하는 사람도 있고 8월 9일로 해석하는 사람도 있으므로 모호합니다.)

제품

기본 기록 양식에 제품 이름을 지정하도록 되어 있지만 구체적으로 해당 제품의 어떤 기능에서 문제가 발생하고 있는지 정보가 필요합니다. 보고서에 특정 API나 Cloud Console URL(또는 스크린샷)을 언급하는 것이 가장 좋습니다. API의 경우 URL에 제품 이름이 포함된 문서 페이지에 연결할 수 있습니다.

요청을 시작하기 위해 사용하는 메커니즘(예: REST API, gcloud 도구, Cloud Console 또는 Deployment Manager와 같은 도구)에 대해서도 알려주세요. 여러 제품이 관련되어 있는 경우 각 제품의 이름을 구체적으로 언급하세요.

예시:

  • "Google Compute Engine REST API에서 다음 오류를 반환했습니다."
  • "console.cloud.google.com의 BigQuery 쿼리 인터페이스가 멈추었습니다."

다음과 같은 문구는 구체적이지 않아 문제를 진단할 때 어떤 부분을 조사해야 하는지 알 수 없습니다.

  • "인스턴스를 만들 수 없습니다."(Google에서는 인스턴스를 만들기 위해 사용 중인 방법을 알아야 합니다.)
  • "gcloud compute create instances 명령어에서 오류가 발생합니다."(명령어 구문이 올바르지 않으므로 Google에서 해당 명령어를 실행하여 오류를 재현할 수 없습니다. 실제로 발생한 오류가 어떤 것인지도 알 수 없습니다.)

위치

Google에서는 종종 한 번에 한 리전 또는 한 영역에 변경사항을 배포하기 때문에 고객의 데이터 센터가 소재한 리전을 알아야 합니다. 리전 및 영역은 기본 소프트웨어의 버전 번호에 대한 프록시입니다. 이 정보는 특정 소프트웨어 버전의 브레이킹 체인지가 사용자의 시스템에 영향을 미치는지 파악하는 데 도움이 됩니다.

예시:

  • "us-east1-a에서"
  • "us-east1 및 us-central1 리전을 사용했습니다."

식별자

구체적인 식별자가 있으면 문제가 발생한 Cloud 프로젝트를 쉽게 식별할 수 있습니다. 프로젝트의 영숫자 ID나 애플리케이션 ID가 반드시 필요합니다. 프로젝트 이름은 도움이 되지 않습니다. 문제가 여러 프로젝트에 영향을 주는 경우 영향을 받는 ID를 모두 포함해주시기 바랍니다.

프로젝트 ID 또는 애플리케이션 ID 외에도 다음과 같은 여러 가지 식별자를 알려주시면 기록을 진단하는 데 도움이 됩니다.

  • 인스턴스 ID
  • BigQuery 작업 ID 또는 테이블 이름
  • IP 주소

IP 주소를 명시할 때 IP 주소가 사용되는 컨텍스트도 알려주세요. 예를 들어 IP가 Compute 인스턴스, 부하 분산기, 커스텀 경로 또는 API 엔드포인트 중 어디에 연결되어 있는지 구체적으로 적어 주세요. 또한 IP 주소가 Google 시스템과 관련이 없는 경우(예: IP 주소가 집 인터넷, VPN 엔드포인트 또는 외부 모니터링 시스템용인 경우) 알려주세요.

예시:

  • "프로젝트 robot-name-165473 또는 my-project-id에서"
  • "여러 프로젝트에서(my-project-id 포함)"
  • "회사 게이트웨이 56.56.56에서 GCP 외부 IP 218.239.8.9에 연결"

다음과 같은 일반적인 문구는 너무 광범위해서 문제를 진단하는 데 도움이 되지 않습니다.

  • "인스턴스 중 하나에 연결할 수 없습니다."
  • "인터넷에서 연결할 수 없습니다."

유용한 아티팩트

문제와 관련된 아티팩트를 제공하면 발생한 문제를 정확하게 파악하는 데 도움이 되므로 문제 해결 속도를 높일 수 있습니다.

예시:

  • 스크린샷을 사용해 발생한 문제를 정확하게 보여줍니다.
  • 웹 기반 인터페이스의 경우 .HAR(Http ARchive) 파일을 제공합니다. HAR Analyzer에는 세 가지 주요 브라우저용 명령이 있습니다.
  • tcpdump 출력, 로그 스니펫, 스택 추적 예시를 첨부합니다.

우선순위 설정 및 에스컬레이션

우선순위는 문제가 고객의 비즈니스에 미치는 영향을 파악하는 데 도움이 되며 Google에서 문제를 해결하기 위해 응답하는 시간에 영향을 줍니다. 우선순위 정의 목록은 절차 참조를 확인하세요.

가장 높은 우선순위를 설정해야 할 경우

비즈니스에 중요한 서비스에 영향을 주는 문제가 발생했으며 Google로부터 즉각적인 조치가 필요한 경우에는 우선순위로 'P1'을 선택하세요. P1을 선택한 이유를 구체적으로 알려주시기 바랍니다. 이 문제가 비즈니스에 주는 영향에 대한 간략한 설명을 포함하세요. 예를 들어 개발자 버전에서 발생한 문제가 최종 사용자에게는 직접적으로 영향을 주지 않더라도 중요한 보안 수정을 차단하고 있다면 P1으로 간주할 수 있습니다.

응답 시간

문제 우선순위 수준에 따른 응답 시간은 Google Cloud Platform 기술 지원 서비스 가이드라인에 사전 정의되어 있습니다. 특정 시간까지 응답이 필요한 경우 보고서 설명을 통해 알려주세요. P1 문제를 24시간 내에 처리해야 하는 경우 '업무 시차' 서비스를 요청할 수 있습니다. 이러한 기록은 근무 중인 지원 엔지니어에게 하루에 몇 번 다시 할당됩니다.

우선순위 에스컬레이션

상황이 바뀌면 문제를 에스컬레이션하여 더 즉각적인 조치를 받을 수 있습니다. 에스컬레이션의 적합한 사유는 다음과 같습니다.

  • 비즈니스에 주는 영향이 증가했습니다.
  • 문제를 더 빨리 해결해야 합니다.
  • 몇 차례 메시지를 교환한 후에도 진척이 없어 문제가 '고착'되었습니다.

기록을 에스컬레이션하려면 우선순위만 변경하면 됩니다. 예를 들어 문제를 P3에서 P2로 변경할 수 있습니다. 이와 같은 경우 변경이 필요한 이유를 알려주세요. 그러면 Google의 기록 처리 시스템에서 상담사에게 알림을 보내며 해당 상담사는 기록을 검토하고 후속 조치를 취합니다. Google에서 적절하게 응답하는 데 도움이 되므로 에스컬레이션이 필요한 이유에 대한 자세한 설명을 제공해 주시기 바랍니다.

해결하는 데 오래 걸리거나 해결이 어려운 문제

해결하는 데 오랜 시간이 걸리는 문제는 복잡하고 진척이 느려질 수 있습니다. 이를 방지하는 가장 좋은 방법은 템플릿 맨 위에 최근 상태 요약이 포함되는 장기 실행 문제 템플릿을 사용하여 정보를 수집하는 것입니다.

템플릿을 사용하려면 위의 링크를 열고 복사하기만 하면 됩니다. 모든 관련 기록 및 내부 추적 버그 링크를 포함하세요. 이 문서를 계정팀 그룹과 공유하고 해당 지원 엔지니어와 공유하도록 요청하세요.

이 문서에 포함되는 정보는 다음과 같습니다.

  • 현재 상태 요약(맨 위에 요약)
  • 잠재적으로 참일 수 있는 가설 목록
  • 각 가설을 테스트하는 데 사용할 테스트 또는 도구

각 기록에서는 한 가지 문제만 집중적으로 다루고 새로운 문제를 보고하기 위해 기록을 다시 열지 마세요.

프로덕션 중단 보고

문제 때문에 애플리케이션에서 사용자에게 트래픽을 제공하지 못하거나 이와 유사하게 비즈니스에 중대한 영향이 발생하는 경우 프로덕션 중단에 해당할 수 있습니다. 이러한 경우 가능한 빨리 알려주세요. 반면 소수의 개발자만이 중단을 겪는 경우 프로덕션 중단으로 간주되지 않습니다.

Google은 프로덕션 중단 보고를 받으면 다음과 같이 신속하게 상황을 분류합니다.

  • GCP 인프라에 영향을 주는 알려진 문제가 있는지 즉시 확인합니다.
  • 문제의 성격을 확인합니다.
  • 통신 채널을 설정합니다.

고객은 다음이 포함된 간단한 메시지 응답을 받을 수 있습니다.

  • 여러 고객에게 영향을 주는 것으로 알려진 관련 문제
  • 보고된 문제를 Google이 관찰할 수 있음을 알리는 확인 메시지 또는 추가 세부정보 요청
  • Google이 사용하려는 통신 방법(예: 전화, 행아웃 또는 기록)

따라서 시간, 제품, 식별자, 위치가 포함된 기록을 신속하게 작성한 다음 더 자세한 문제 해결을 시작하는 것이 중요합니다. 조직에는 이슈 관리 프로세스가 정의되어 있을 수 있으며 이 단계는 이슈 관리 프로세스 초반부에 실행해야 합니다.

Google의 이슈 관리 프로세스에서는 이슈 책임자라는 중요한 역할을 정의합니다. 이슈 책임자는 관련 인력을 확보하고 최신 상태를 지속적으로 수집하며 문제의 상태를 주기적으로 요약합니다. 또한 문제를 해결하고 변경사항을 적용하는 업무를 다른 사람들에게 위임합니다. 이러한 위임을 통해 Google에서는 여러 가설을 병행하여 조사할 수 있습니다. 조직 내에서도 비슷한 프로세스를 수립하는 것이 좋습니다. 대개는 기록을 연 사람이 상황을 가장 많이 파악하고 있기 때문에 이슈 책임자로 적임자인 경우가 많습니다.

네트워킹 문제 보고

Google 네트워크의 규모와 복잡성 때문에 어떤 팀이 문제를 담당하고 있는지 파악하기 어려울 수 있습니다. 네트워킹 문제를 진단하려면 매우 구체적인 근본 원인을 식별해야 합니다. 네트워킹 오류 메시지는 일반적(예: '서버에 연결할 수 없음')이므로 가능한 가설의 수를 줄이려면 자세한 진단 정보를 수집해야 합니다.

패킷 흐름도는 문제 보고서를 위한 훌륭한 구조를 제공합니다. 이 다이어그램은 소스에서 대상으로 이어지는 경로에서 패킷이 통과하는 중요한 홉 및 그 과정에서 발생한 중요한 변환을 보여줍니다.

영향을 받는 네트워크 엔드포인트를 인터넷 IP 주소 또는 RFC 1918 비공개 주소와 네트워크 식별자로 식별하여 시작하세요. 예를 들어 Compute Engine 프로젝트의 기본 네트워크 주소는 2.3.4.5 또는 10.2.3.4입니다.

다음과 같이 엔드포인트와 관련된 중요 사항을 모두 기록하세요.

  • 엔드포인트를 제어하는 사람
  • 엔드포인트가 DNS 호스트 이름과 연결되어 있는지 여부
  • VPN 터널링, 프록시, NAT 게이트웨이와 같은 중간 캡슐화 또는 경로 우회
  • 방화벽이나 CDN 또는 WAF와 같은 중간 필터링

높은 지연 시간 또는 간헐적인 패킷 손실로 나타나는 많은 문제에는 진단을 위한 경로 분석 또는 패킷 캡처가 필요합니다.

  • 경로 분석은 패킷이 통과하는 모든 홉의 목록이며 "traceroute"로 알려져 있습니다. MTR 또는 tcptraceroute는 진단 기능이 뛰어나기 때문에 Google에서 자주 사용하므로 이러한 도구에 익숙해지시기 바랍니다.
  • 패킷 캡처(일명 'pcap', 'libpcap' 라이브러리 이름에서 가져옴)는 실제 네트워크 트래픽을 관찰한 것입니다. 두 엔드포인트에서 동시에 패킷 캡처를 수행하는 것이 중요하며 이 작업은 까다로울 수 있습니다. 필요한 도구(예: tcpdump 또는 Wireshark)를 사용해 연습해 보고 미리 설치해 두는 것이 좋습니다.

샘플 기록

예시 1

작업 이름:

A_ATL_BIG1toBQ_big_04)201704202

00045_491

소스:

S3_avl-transfer

대상:

CloudStorage: avl-transfer

시작 시간(ISO 8601 형식): 2017-04-20 20:14:43 PDT

종료 시간(ISO 8601 형식): 2017-04-21 10:03:44 PDT

전송 API를 사용하여 2017-04-20 20:14:43 PDT에 파일 전송을 시작했습니다. 이 작업은 일반적으로 완료되는 데 10분이 걸리지만 이 경우 다음 날(2017-04-21 10:03:44 PDT)에 취소할 때까지 계속 실행 중이었습니다. 이 문제는 여기서만 발생하는 것이 아닙니다. 전송 API를 사용하는 다른 몇 개 작업도 간헐적으로 꽤 오랫동안 지연됩니다.

지연의 원인을 조사하고 향후 이 문제를 방지하기 위해 구현할 수 있는 권장사항을 알려주시기 바랍니다.

예시 2

시작 시간(ISO 8601 형식): 2017-05-12 11:03:43

종료 시간(ISO 8601 형식): 이 보고서를 작성하고 있는 시점에도 문제가 발생하고 있습니다.

문제 요약

App Engine Task Queue를 사용 중인 /cron/payments-service/sync-v2-batch 크론이 2017-05-12 11:03:43 이후 실행 중지되었습니다. 결제를 처리하는 데 이 작업을 사용하고 있습니다.

데이터 저장소 및 대기열 오류가 발생한 후 크론 실행이 중지되었습니다. cron.xml을 다시 업로드하여 문제를 해결하려고 했지만 실패했습니다. 오류 추적은 다음과 같습니다.

[error trace]

API 문제인지 아니면 구현 문제인지 조언해 주시고 다음 단계를 알려주시기 바랍니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...