고객 관리 작업을 위한 권장사항

이 가이드에서는 효과적인 지원 케이스를 작성하기 위한 권장사항을 제공합니다. 이러한 권장사항은 기술 지원 케이스를 더 빠르게 해결하는 데 도움이 됩니다.

지원 케이스 만들기

지원 케이스를 만들기 전에 알려진 문제를 검토하여 케이스가 이미 제출되지 않았는지 확인하세요.

혼란을 방지하고 단일 지점에서 요청을 추적할 수 있도록 문제당 하나의 지원 케이스를 만드세요. 생성된 모든 중복 케이스는 종료됩니다.

문제 설명

지원 케이스를 자세히 작성하면 고객 관리팀이 더 빠르고 효율적으로 응답하기가 쉽습니다. 지원 기록에 중요한 세부정보가 누락되어 있으면 추가 정보를 요청드려야 해서 시간이 추가로 소요됩니다.

자세하고 구체적인 지원 케이스가 가장 좋습니다. 이러한 보고서는 발생한 문제와 원래 예상했던 결과를 알려줍니다. 지원 케이스에서 문제를 기술할 때는 다음 세부정보를 포함하세요.

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

이 문제를 해결하는 고객 관리 전문가가 고객과 같은 시간대에 있지 않을 가능성이 매우 높으므로 다음과 같은 상대적 문을 사용하면 문제를 진단하기가 더욱 어려워집니다.

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

제품

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

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

예를 들면 다음과 같습니다.

  • 'Google 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에 연결'

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

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

유용한 아티팩트

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

예를 들면 다음과 같습니다.

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

문제 유형

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

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

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

설명 예시

예시 1

JobName:

A_ATL_BIG1toBQ_big_04)201704202

00045_491

Source:

S3_avl-transfer

Destination:

CloudStorage: avl-transfer

Start time (ISO 8601 format): 2017-04-20 20:14:43 PDT

End time (ISO 8601 format): 2017-04-21 at 10:03:44 PDT

I started a file transfer at 2017-04-20 at 20:14:43 PDT using the transfer API.
This job normally takes 10 minutes to complete, but in this case the job was
still running when I canceled it the next day (2017-04-21 at 10:03:44 PDT). This
is not an isolated event; several other jobs involving the transfer API had
intermittent, significant delays.

Please investigate the cause of the delays and advise of any best practices that
we can implement to prevent these issues in the future.

예시 2

Start time (ISO 8601 format): 2017-05-12 at 11:03:43

End time (ISO 8601 format): The issue is still happening as of the time of this
report.

Issue summary:

`/cron/payments-service/sync-v2-batch` cron using the App Engine Task Queue API
has stopped running since 2017-05-12 at 11:03:43. We rely on this job to handle
payments correctly.

We saw datastore and queue errors and then the cron stopped running. We
attempted unsuccessfully to fix the issue by re-uploading cron.xml. Here is the
error trace:

`[error trace]`

Please advise if the issue is with the API or our implementation and let us
know next steps.

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

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

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

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

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

케이스를 P1으로 설정하면 전문가에게 즉시 해당 문제를 전담하라는 알림이 전송됩니다. Google Meet을 통해 실시간 문제 해결 통화에 참여하라는 빠른 초기 응답이 수신됩니다. 조직에서 Google Meet을 사용할 수 없는 경우 전문가가 참여할 수 있도록 원하는 화상 회의 소프트웨어 링크를 포함합니다. 그런 다음 해당 케이스를 통해 정기적인 업데이트를 받습니다.

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

P1 케이스 지원에 대해 예상할 수 있는 사항

  • 새로운 P1 케이스

    • 지원 전문가가 Google Meet 또는 제공된 다른 브리지를 통해 사용자에게 연락합니다. 사용자는 15~30분 이내에 통화에 참여할 것으로 예상됩니다. 어떤 이유로 통화에 참여할 수 없는 경우 지원 전문가에게 알려주세요.
    • 케이스는 기본적으로 '주간을 기반'으로 합니다. 즉, 지원 전문가는 케이스가 완화되거나 우선순위가 해제될 때까지 연중무휴 24시간 응대합니다. 케이스 완화를 가장 잘 진행한 특정 리전에서는 해당 케이스를 특정 시간대로 고정할 수 있습니다. 이 효과를 얼마나 선호하는지 Google에 알릴 수 있습니다.

  • P1 우선순위 상향

    • 문제가 프로덕션 환경에 영향을 미치기 시작했거나 영향을 미치려고 하는 경우 기존 P2 - P4 케이스의 우선순위를 P1으로 상향할 수 있습니다.
    • 기존 케이스의 우선순위를 P1으로 상향하면 지원 케이스가 다시 할당되어 지원 가능한 지원 전문가가 즉시 주의를 기울일 수 있습니다.

  • 비프로덕션에 미치는 영향

    필요한 곳에 적절한 리소스가 할당되도록 하기 위해 지원팀에서 사용자와 협력하여 P1으로 표시되었지만 프로덕션에 영향을 미치지 않거나 비즈니스에 큰 영향을 미치지 않는 케이스를 다시 평가할 수 있습니다.

응답 시간

문제 우선순위 수준에 따른 응답 시간은 Google Cloud Platform 기술 지원 서비스 가이드라인에 사전 정의되어 있습니다. 특정 시간까지 응답이 필요한 경우 보고서 설명을 통해 알려주세요. P1 문제를 24시간 내에 처리해야 하는 경우 '업무 시차' 서비스를 요청할 수 있습니다. 이러한 케이스는 하루에 여러 번 다시 할당되어 근무 중인 고객 관리 전문가가 처리합니다. P1 케이스 문제를 해결하는 동안 효율적인 소통이 가능하도록 문제가 해결될 때까지 질문에 계속 답변하는 것이 좋습니다. 3시간 넘게 응답이 없으면 사용자가 다시 문의할 때까지 케이스 우선순위가 P2로 하향될 수 있습니다.

에스컬레이션

상황이 바뀌면 문제를 에스컬레이션해야 할 수 있습니다. 에스컬레이션의 적합한 사유는 다음과 같습니다.

  • 비즈니스에 미치는 영향 증가.
  • 해결 프로세스의 분석 내역. 예를 들어 합의된 시간 내에 업데이트를 받지 못했거나 여러 메시지를 교환한 후에도 문제가 진행되지 않고 '중단'됩니다.

심각한 문제가 발생하는 경우 최상의 해결책은 케이스를 에스컬레이션하는 대신 적절한 시간 동안 적절한 우선순위로 설정하는 것입니다. 에스컬레이션해도 케이스가 더 빠르게 해결되지 않으며 우선순위를 변경한 직후에 에스컬레이션하면 케이스 해결 속도가 더 느려질 수 있습니다. 자세한 설명은 에스컬레이션해야 하는 경우 동영상을 참조하세요.

케이스를 에스컬레이션하는 방법에 대한 자세한 내용은 케이스 에스컬레이션을 참조하세요.

필요한 시간대로 케이스 라우팅

고객 관리 가용성의 기반이 되는 요인으로 인해 지원 케이스가 운영 시간 이외에 근무하는 고객 관리 전문가에게 할당될 수 있습니다. 특정 시간대의 영업일 중에 고객 관리에 참여하려고 할 수 있습니다. 이 경우 고객 지원 케이스를 케이스에 편리한 시간대로 라우팅하도록 고객 관리에 요청하는 것이 좋습니다. 기록 요청 또는 응답에 이 요청을 추가할 수 있습니다. 예를 들면 Please route this case to the Pacific time zone (GMT-8)입니다. P1 케이스는 주간을 기반으로 하기 때문에 다음 리전의 고객 관리에 전달되지만 다른 케이스는 현재 케이스 소유자에게 유지되어 다음 날 이어서 작업이 수행됩니다.

CES 설문조사로 의견 제공

케이스가 해결되면 프로세스가 진행된 방식에 대한 고객의 의견과 관련한 고객 노력 점수(CES) 설문조사가 이메일로 전송됩니다. 무엇이 잘 이루어졌는지, 이러한 측면을 개선하기 위해 해결해야 할 문제가 무엇인지 확인할 수 있도록 몇 분만 시간을 내어 작성해 주시면 큰 도움이 될 것입니다.

모든 의견 제출 양식은 고객 경험팀에서 수동으로 검토되며 향후 환경을 개선하기 위한 조치로 이어집니다. 점수는 5점 만점입니다. 3점 이하의 점수는 고객 측에서 어려움을 느낀 것으로 간주됩니다. 4점 이상은 고객 측에서 상호작용이 어려웠고 긍정적 경험으로 간주되었다는 의미입니다.

자세한 내용은 CES로 Google Cloud 서비스 피드백을 제출하는 방법 동영상을 참조하세요.

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

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

템플릿을 사용하려면 앞선 링크를 열고 복사합니다. 모든 관련 기록 및 내부 추적 버그 링크를 포함하세요. 이 문서를 계정팀 그룹과 공유하고 해당 고객 관리 전문가와 공유하도록 요청합니다.

이 문서에는 다음과 같은 정보가 포함됩니다.

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

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

프로덕션 중단 보고

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

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

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

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

  • 여러 고객에게 영향을 주는 것으로 알려진 관련 문제
  • 보고된 문제를 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 또는 둘 다 사용하는 경우가 많습니다. 이러한 도구에 익숙해지는 것이 좋습니다.
  • 패킷 캡처(일명 'pcap', 'libpcap' 라이브러리 이름에서 가져옴)는 실제 네트워크 트래픽을 관찰한 것입니다. 두 엔드포인트에서 동시에 패킷 캡처를 수행하는 것이 중요하며 이 작업은 까다로울 수 있습니다. 필요한 도구(예: tcpdump 또는 Wireshark)를 사용해 연습해 보고 미리 설치해 두는 것이 좋습니다.