5 ms·

I'm not an expert with AWS or Google Cloud, so I'm interested in knowing: What "level" of customer or SLA do you have to be to get a certain quantity or guaran

I'm not an expert with AWS or Google Cloud, so I'm interested in knowing: What "level" of customer or SLA do you have to be to get a certain quantity or guarantee of support and troubleshooting? Or is it that if even a free-tier customer points out something that is fundamentally a problem, it will receive attention by certain solutions engineers? Are there $ spending, 20 x (c3.4x.large), or I-pay-you-for-certain-uptime/troubleshooting levels that get you certain response levels? Do certain problems get resolved with "well, you just have to live with that behavior, we're not fixing that". Do you get to call them or chat live? Or is it all via tickets?

andyljones 6y ago
Here you go: https://cloud.google.com/support#support-plans https://cloud.google.com/support#support-plans $250/month/dev is the minimal for phone calls on technical issues, $150k + 4% of GCP spend for 'come running' support. There're more details here https://cloud.google.com/support/docs/procedures#additional_services_for_gold_platinum_production_and_enterprise_support_customers https://cloud.google.com/support/docs/procedures#additional_... though they use the old names for the support tiers.
- fenesiistvan 6y ago
  What "dev" or "user" means here ...for example if I run a server serving some HTTP API.
  - londons_explore 6y ago
    I believe it means "person who wants the ability to contact cloud support". For small to medium sized businesses, that number is probably 1.
- ehsankia 6y ago
  It seems like the blog post talks about a written case report, which the 100$ tier has access to, albeit with 4 hour first response instead of 1 hour. So it is possible that you could get your case escalated to such an in depth debugging with that tier?
  - perfect_wave 6y ago
    I've seen free tier tickets get escalated to product engineering teams for investigations about sub $100 charges.
  - qmarchi 6y ago
    It's possible but there's steps to jump through, and the expected response times don't change even if you get escalated to a TSE from a different area. Disclaimer: Is a TSE...
deleted 6y ago
[deleted]
mancini0 6y ago
This question brings to mind a recent experience I had with Scaleway support. I pay maybe 25 euro a month to host my k8s based application on their managed k8s offering.I did not pay the extra 2 euro a month for an upgraded support tier. I encountered an issue when deploying istio to the cluster, pinged the scaleway support chat on a saturday, and they had figured out the bug on their end and had a fix eta estimate within a few minutes and had the fix in the next business day. Those guys have fantastic support.
- kbenson 6y ago
  Support should be judged on how they perform under load, and how they perform consistently, not how they perform on random events. We don't really have any way to know from your story whether Scaleway's support was under normal or extra load and delivered an excellent experience, or whether they had a bunch of bored support reps just waiting for something to work on because it was abnormally slow. The latter is nice, at the moment it happens, but doesn't really help you if 2 days later for a different issue you're left in a lurch for days on end because they're busy. The former would be good for maybe indicating that. That's the whole point of service level guarantees. They provide a lower bound on the support you'll receive, which is often much more important and useful to track.
londons_explore 6y ago
When purchasing support, you should consider you are really buying an expert who really knows google cloud, but doesn't have special buttons to click to do things you couldn't do. If a service you depend on is down, your support agent will be able to tell you it's down, but not speed up the fix. Cloud support will have more information about performance black holes and limitations that the documents don't describe. They also will be able to advise on "is this design or that design likely better". They generally know how the backends of GCP services work, and their common failure modes, which is pretty hard knowledge to get from the outside.
- bb611 6y ago
  This sounds a lot like my experience with AWS support. They really deeply understand AWS, are very responsive to calls/emails, but often have no tools to solve the problem we're having right now. This even happened with some of their high end hardware, we did an upgrade for a critical set of instances to some extremely pricey dedicated hosts and ended up in a runaround for over a week due to a hardware issue on their side.
fivre 6y ago
At my previous employer, a large network services provider, everyone got the same depth of support, even people that were on the free tier! Granted, the people paying us $ENTERPRISE usually got responses in minutes, whereas free users might be waiting around for a week on more difficult cases, but it was the same set of engineers working on each. Free customers did report bugs, and we would replicate, triage, and fix them as usual. These tended to be more obscure bugs (more severe ones would usually surface in the paid queues first), but we didn't discard them immediately. Whether we effectively ignored bugs depended more on the ability of the customer to provide an actionable report. Some users provide exactly what we need up front, but there is a lot of "it doesn't work!" white noise from users that aren't able to or aren't willing to put in the work to accurately describe their issue and/or action feedback from us. There's usually not a whole lot support can do in that scenario if we don't see any obvious issues, but we'd go a bit further to placate paying customers--I fondly remember joining a call between some very technically inept user and their ISP who was adamant that either we or the ISP were at fault, after we guided their network team through taking local packet captures showing unanswered SYNs past their network border.

andyljones 6y ago

Here you go: https://cloud.google.com/support#support-plans https://cloud.google.com/support#support-plans $250/month/dev is the minimal for phone calls on technical issues, $150k + 4% of GCP spend for 'come running' support. There're more details here https://cloud.google.com/support/docs/procedures#additional_services_for_gold_platinum_production_and_enterprise_support_customers https://cloud.google.com/support/docs/procedures#additional_... though they use the old names for the support tiers.

fenesiistvan 6y ago
What "dev" or "user" means here ...for example if I run a server serving some HTTP API.
- londons_explore 6y ago
  I believe it means "person who wants the ability to contact cloud support". For small to medium sized businesses, that number is probably 1.
ehsankia 6y ago
It seems like the blog post talks about a written case report, which the 100$ tier has access to, albeit with 4 hour first response instead of 1 hour. So it is possible that you could get your case escalated to such an in depth debugging with that tier?
- perfect_wave 6y ago
  I've seen free tier tickets get escalated to product engineering teams for investigations about sub $100 charges.
- qmarchi 6y ago
  It's possible but there's steps to jump through, and the expected response times don't change even if you get escalated to a TSE from a different area. Disclaimer: Is a TSE...

deleted 6y ago

[deleted]

mancini0 6y ago

This question brings to mind a recent experience I had with Scaleway support. I pay maybe 25 euro a month to host my k8s based application on their managed k8s offering.I did not pay the extra 2 euro a month for an upgraded support tier. I encountered an issue when deploying istio to the cluster, pinged the scaleway support chat on a saturday, and they had figured out the bug on their end and had a fix eta estimate within a few minutes and had the fix in the next business day. Those guys have fantastic support.

kbenson 6y ago
Support should be judged on how they perform under load, and how they perform consistently, not how they perform on random events. We don't really have any way to know from your story whether Scaleway's support was under normal or extra load and delivered an excellent experience, or whether they had a bunch of bored support reps just waiting for something to work on because it was abnormally slow. The latter is nice, at the moment it happens, but doesn't really help you if 2 days later for a different issue you're left in a lurch for days on end because they're busy. The former would be good for maybe indicating that. That's the whole point of service level guarantees. They provide a lower bound on the support you'll receive, which is often much more important and useful to track.

londons_explore 6y ago

When purchasing support, you should consider you are really buying an expert who really knows google cloud, but doesn't have special buttons to click to do things you couldn't do. If a service you depend on is down, your support agent will be able to tell you it's down, but not speed up the fix. Cloud support will have more information about performance black holes and limitations that the documents don't describe. They also will be able to advise on "is this design or that design likely better". They generally know how the backends of GCP services work, and their common failure modes, which is pretty hard knowledge to get from the outside.

bb611 6y ago
This sounds a lot like my experience with AWS support. They really deeply understand AWS, are very responsive to calls/emails, but often have no tools to solve the problem we're having right now. This even happened with some of their high end hardware, we did an upgrade for a critical set of instances to some extremely pricey dedicated hosts and ended up in a runaround for over a week due to a hardware issue on their side.

fivre 6y ago

At my previous employer, a large network services provider, everyone got the same depth of support, even people that were on the free tier! Granted, the people paying us $ENTERPRISE usually got responses in minutes, whereas free users might be waiting around for a week on more difficult cases, but it was the same set of engineers working on each. Free customers did report bugs, and we would replicate, triage, and fix them as usual. These tended to be more obscure bugs (more severe ones would usually surface in the paid queues first), but we didn't discard them immediately. Whether we effectively ignored bugs depended more on the ability of the customer to provide an actionable report. Some users provide exactly what we need up front, but there is a lot of "it doesn't work!" white noise from users that aren't able to or aren't willing to put in the work to accurately describe their issue and/or action feedback from us. There's usually not a whole lot support can do in that scenario if we don't see any obvious issues, but we'd go a bit further to placate paying customers--I fondly remember joining a call between some very technically inept user and their ISP who was adamant that either we or the ISP were at fault, after we guided their network team through taking local packet captures showing unanswered SYNs past their network border.