SPEAKER 1: In Google Cloud Engineering Support,
our goal is to work smoothly with you, engineer to engineer,
to resolve any issues you may encounter when using Google
Cloud Platform products.
This video describes best practices
for filing an issue report with our support engineers
in the Google Cloud Support Center,
but it's applicable to requesting technical assistance
from any GCP engineer.
This includes support cases, bug reports, and issue trackers,
and posts to our user groups and forums, like Stack Overflow.
The key principle is clarity.
Specify the right level of technical detail
and communicate your expectations explicitly
so that we can better help you resolve the issue.
The Support Center's help page and earlier videos
present the mechanics of how to file cases.
This will help you understand what to include in your cases
and why.
We will explain the details we need
and why they are important.
The four critical details to include with every case
are specific times when you experience the issue, the GCP
products you're using, the location,
and specific identifiers for any resources
relevant to your case.
Onset time and duration give us a way
to focus our time series monitoring
on the relevant period.
Please be explicit about whether the issue is ongoing
or whether it was only observable in the past.
If the issue isn't ongoing, please state that,
and give the end time if you know it.
ISO 8601 format is a good choice because it's
unambiguous and easy to sort.
Please always include the time zone.
Our internal systems tend to be in Google time, which
is US-specific, but our agents use a follow the sun model
and may be in different time zones.
Some issues are intermittent over a period.
In this case, it's good to say when
it's first observed or perhaps note a time in the past
when it was not happening.
Remark about the frequency of observations
and note one or two specific examples.
When time is specified in a relative way,
including omission of a time zone,
the reader must convert into an absolute format
that can be input into time series monitoring tools.
This is error-prone and costly, especially
considering that each reader must pay the price.
For example, sending an email about something
that happened earlier yesterday causes the reader
to search for a header in the initial email
and start doing math in their head.
Phrases to avoid are things like earlier today, because it's
not specific enough, or yesterday, because we need
to figure out the implied date when issues
take multiple days to resolve.
Don't use dates like 9/8 because it's
ambiguous and may be interpreted differently in other locales.
The Case Creation form includes basic product selection,
which is used for routing to a specialist in the area.
This isn't specific enough to locate
the components or logs that will help diagnose the issue.
Be as specific as possible about the product
you're using, ideally referring to the specific APIs
or console.cloud.google.com or screenshots.
For APIs, you can link to the documentation
page, which contains the product name and the URL.
Tell us about the mechanism you're
using to initiate the request.
For example, REST API, gcloud tool, console.cloud.google.com,
or perhaps a tool like Deployment Manager.
Sometimes multiple products are involved,
so try to be specific about each one.
Describe the behavior observing and what you expected,
then show us what you see.
You should be specific about the actions you have taken,
as well as the syntax of any commands you use.
A phrase like "can't create instance"
doesn't tell us whether you used gcloud compute,
the developer console UI, or called it from your own code.
The most clear way to communicate this example would
be something like "I ran gcloud compute instances create
my-instance--zone us-central1-a and got the following error
message."
When including the location, region and zone
are important to us, because we often roll out
changes to one region or zone at a time.
They are a proxy for the version number of the underlying
software.
We can see if there's a rollout underway in a given location
or map it to an internal release ID for use in a bug report.
You should include something along the lines
of "I tried regions us-east1 or us-central1."
In your case, please make sure to always include
specific identifiers.
Project ID is an input to most of our troubleshooting tools,
and it's a required field when filing a case.
Please provide a numeric project ID, not a project name.
If the error is observed in multiple projects
or in one project, but not another,
you should include that information in the description.
Also include IDs of other objects, like instance
IDs, BigQuery job IDs, or table names.
IP addresses are another form of unambiguous identifier.
When specifying a cloud platform IP,
tell us the context of how it's used--
for example, if it's connected to a GCE instance,
a load balancer, a custom route, or if it's an API endpoint.
If you're troubleshooting a connection issue,
then tell us a bit about the IP addresses
that are not part of GCP--
for example, if it's your home internet,
a VPN end point, or an external monitoring system.
You should always provide more specific information
than something like "one of our instances"
or "we can't connect from the internet,"
because support will need to gather
more information from you before they can begin troubleshooting.
That will mean further delays in resolving your issue.
For any information you provide to support,
be specific and explicit.
If relevant, use a screenshot to show exactly what you see.
For web-based interfaces, provide a .HAR file or a HTTP
archive.
Our documentation has instructions on how to get
a .HAR file from three major browsers.
When troubleshooting networking issues, attach TCP dump output
if you collect it, and also attach log snippets and example
stack traces you believe to be relevant to the issue.
When you file a case, support uses the priority field
for initial routing, especially when an issue may page someone.
Case priorities are also described in the case creation
form itself.
Use P1 for production emergencies.
Think of case priority in terms of the impact to your business.
In addition to setting the priority field correctly,
it's useful to add a sentence describing
the impact in your words.
For example, you may consider a problem with the dev version
to be a P1, even if no end users are directly impacted, if it's
blocking a critical security fix.
To avoid incorrect assumptions, it's
helpful to be explicit about why you selected P1.
Cases have built-in response timers,
which are designed to set reasonable expectations most
of the time.
If you have some specific needs, please let us
know when you need an update.
It's good to say something like, "I need a response by 5:00 PM,
because that's when my shift ends."
If you notice you're affected by an issue that's already
reported on the status.cloud.google.com,
you can follow the progress in the dashboard itself
or use the Me Too link in the cloud support portal
to automatically get updates for known issues.
When an issue needs to be handled around the clock,
customers with 24/7 support can request
that the case follow the sun.
Cases that follow the sun will be reassigned several times
per day, so it's always with an active support engineer.
A lower priority case will not be managed around the clock,
as the assigned support engineer will go off shift
at some point.
This can cause delays if the assigned engineer is not
in your time zone.
You can ask us to manage the ticket in your time zone
so you can communicate more easily with the support
engineer.
For example, you can say "please manage this case
in my time zone, EST."
This can help if you need a long discussion with the support
engineer, but may not help if the development
team is in another time zone.
If you need to continue the conversation over Google
Hangouts or phone after filing a case,
please provide a link or phone number.
If you request it, support will try
to call when it does not interfere
with issue resolution.
For video bridges, we strongly prefer Google Hangouts
but can use anything that works within a Chrome browser
without requiring extensions.
If you're not requesting an immediate callback,
please give two or three time slots
when you're available to get started with the scheduling.
Thank you for watching.
If you have questions, please leave them in the comments
section below, and we'll try to address them in future videos.