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

지원 기록을 자세히 작성하면 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 출력, 로그 스니펫, 스택 추적 예시를 첨부합니다.

문제 유형:

  • 간헐적: 간헐적인 문제는 규칙적인 장애 패턴 없이 무작위로 발생합니다. 간헐적인 문제는 불규칙하므로 장애 발생 시 데이터를 수집하기 어려워 문제해결이 어렵습니다. 이 경우 아키텍처의 병목 현상을 파악하고 리소스가 최대 임계 사용량에 도달했는지 확인해야 합니다. 또한 자동화를 사용하여 작업을 정기적으로 자주 검사하고 검사에 실패하면 장애 발생 시 디버그 정보를 수집해야 합니다. 이러한 유형의 대표적인 장애는 DNS 확인 실패와 패킷 손실입니다.

  • 일시적: 일시적인 문제는 순간적이거나 단기적으로만 발생합니다. 1초 또는 수 마이크로초 정도만 문제가 발생하는 경우 트래픽에서 경미한 버스트가 발생했거나 리소스 최고 사용률에 도달했는지 확인해야 합니다. 대부분의 경우 일시적 문제는 자주 재발하지 않고 서비스가 일시적인 장애를 허용하도록 설계된 경우에는 무시할 수 있습니다. 이러한 유형의 대표적인 장애는 수 마이크로초 동안만 발생하는 네트워크 지연 시간 급증, 시간 초과를 초래하는 소규모의 패킷 손실입니다. 전송 제어 프로토콜(TCP)은 소규모 패킷 손실이나 지연 시간 급증과 같은 장애를 방지하기 위해 설계되었으며, 애플리케이션이 지연 시간에 민감하지 않은 경우 이러한 문제를 효과적으로 처리할 수 있습니다.

  • 지속적: 지속적인 문제는 웹사이트가 다운되는 등의 완전한 장애 문제가 발생하는 경우입니다. 지속적인 문제는 재현 가능하므로 문제해결이 비교적 쉽습니다. 이 경우 지원 엔지니어가 환경을 재현하고 문제를 해결할 수 있도록 문제 재현 방법을 알려주세요.

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

우선순위는 문제가 고객의 비즈니스에 미치는 영향을 파악하는 데 도움이 되며 Google에서 문제를 해결하기 위해 응답하는 시간에 영향을 줍니다. 우선순위는 다음 표에 정의되어 있습니다. 자세한 내용은 Cloud 지원 절차를 참조하세요.

우선순위 정의 상황 예시
P1: 심각한 영향 - 프로덕션에서 서비스 사용 불가 프로덕션 환경에서 애플리케이션 또는 인프라를 사용할 수 없으므로 사용자가 직면하는 오류가 크게 증가합니다. 수익 손실, 잠재적인 데이터 무결성 문제 등 비즈니스가 심각한 영향을 받습니다.
P2: 높은 수준의 영향 – 심각한 수준의 서비스 사용 불가 프로덕션 환경에서 인프라의 성능이 저하되어 사용자가 겪는 오류가 눈에 띄게 증가했거나 새 프로덕션 시스템을 가동하는 데 어려움이 있습니다. 수익 손실 위험, 생산성 저하 등 비즈니스가 어느 정도 영향을 받습니다.
P3: 중간 수준의 영향 - 일부 서비스 사용 불가 문제의 범위 또는 심각도가 제한적입니다. 이러한 문제는 사용자에게 눈에 보이는 영향을 주지 않습니다. 불편함, 비즈니스 프로세스에 대한 사소한 영향 등 비즈니스가 약간의 영향을 받습니다.
P4: 낮은 수준의 영향 - 정상적으로 서비스 사용 가능 업무적, 기술적 영향이 없거나 거의 없습니다. 긴밀한 소통보다는 심도 있는 분석, 문제해결 또는 상담이 필요한 컨설팅용 티켓에 권장됩니다.

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

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

케이스를 P1으로 설정하면 담당 지원팀 구성원이 즉시 알림을 받아 해당 문제를 해결하는 데 적합한 전문가를 찾습니다. 빠른 초기 응답이 제공됩니다(엔터프라이즈 고객의 경우 15분 이내, 역할 기반 지원 프로덕션 역할 고객의 경우 1시간 이내). 그런 다음 정기적인 후속 조치를 받게 됩니다.

선택한 우선순위 수준을 자세히 알려주시면 적합한 대응을 하는 데 도움이 됩니다.

응답 시간

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

에스컬레이션

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

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

GCP 지원 기록이 에스컬레이션되면 지원 관리자에게 즉시 알림이 전송되며 1시간 이내에 답변을 드립니다. 에스컬레이션 관리자는 에스컬레이션이 종결될 때까지 에스컬레이션을 담당합니다. 관리자는 에스컬레이션 근본 원인을 파악하여 해결하고 향후 유사한 에스컬레이션을 방지하는 예방 조치를 보고합니다.

케이스를 에스컬레이션하려면 현재 케이스에 댓글로 에스컬레이션을 요청하거나 케이스를 작성하고 60분 후에 나타나는 케이스 에스컬레이션 버튼을 클릭하면 됩니다.

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

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

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

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

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

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

프로덕션 중단 보고

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

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 API를 사용하는 /cron/payments-service/sync-v2-batch 크론이 2017-05-12 11:03:43 이후에 실행을 중지했습니다. 결제를 처리하는 데 이 작업을 사용하고 있습니다.

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

[error trace]

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