3 ms·

I don't know how to check, maybe someone was cleaning tickets older than 3-4 months. But, the status is 'resolved' (again, not sure who can set this), but there

I don't know how to check, maybe someone was cleaning tickets older than 3-4 months. But, the status is 'resolved' (again, not sure who can set this), but there has been no communication from AWS since. I just checked now, the issue either was fixed by us dumping less data or by AWS. However, the SLAs that I can see are 'initial response', which for better or worse, sometimes happen. However, the most egregious example of how broken that model is, we had a business critical system down ticket down that got an answer of 'looking into it' in 19 minutes, then ~1:45 an answer of "oh, yeah, I checked and this and this DB you talked about didn't reboot", which was true, the person that made the ticket pointed out the wrong instance. 3 hours after I point the correct DB we get told, yes, you are right, it rebooted. And then on the 1st of April I ask for a timeline of how the writer/reader nodes changed during the reboot, I get an answer on the 20th, even though we pushed in the ticket and through our TAM for an answer. Generally, I'm not really sure how people are so happy with AWS support, every issue that is even the least bit complicated gets wrong answers (took a month for us to convince people, though meetings with our TAM, that it's not a configuration or capacity issue that's causing some issues) or just sits there for ages. Once we got an engineer on the Aurora team assigned to the case I used as an example, we started making progress, we even got a patched version of PostgreSQL RDS deployed, but once the bug was identified, we had to work around it, since a fixed version was not an option in less than a few months. All in all, for the hundreds of thousands of dollars we're spending a month on support, I have a feeling that when we need it, we're kind of alone.

whoknew1122 4y ago
I'm not exactly sure how your example is particularly egregious. AWS Support doesn't know your workload. If you, who know your workload, can't figure out what's wrong, how can AWS Support figure it out in 15 minutes? > "that got an answer of 'looking into it' in 19 minutes, then ~1:45 an answer of 'oh, yeah, I checked and this and this DB you talked about didn't reboot', which was true, the person that made the ticket pointed out the wrong instance." Which wasn't AWS Support's fault. They looked into the resource on the ticket. Again, AWS Support doesn't know your workload and isn't going to go on a fishing expedition to guess which DB might be the issue. > "3 hours after I point the correct DB we get told, yes, you are right, it rebooted. And then on the 1st of April I ask for a timeline of how the writer/reader nodes changed during the reboot, I get an answer on the 20th, even though we pushed in the ticket and through our TAM for an answer." Timelines and RCAs have to go through the service team. Up to, and including, the service GM at times. It can be frustrating to wait for an RCA, but sometimes the things just take time. > "All in all, for the hundreds of thousands of dollars we're spending a month on support, I have a feeling that when we need it, we're kind of alone." I'd encourage you to open a chat or phone for a business critical issue. That way Support doesn't spend an hour and a half trying to troubleshoot the wrong resource. Those errors can quickly be found and remediated on a call.
- gcbirzan 4y ago
  > Which wasn't AWS Support's fault. They looked into the resource on the ticket. Again, AWS Support doesn't know your workload and isn't going to go on a fishing expedition to guess which DB might be the issue. No, they won't. I mean, definitely, two hours is not enough time to do anything except say "but it didn't reboot". > Timelines and RCAs have to go through the service team. Up to, and including, the service GM at times. It can be frustrating to wait for an RCA, but sometimes the things just take time. If essential information isn't present in the event log, or in any way accessible to the customer, and especially given how trivial the info was (we got back literally four bullet points two timestamps), almost 3 weeks is a disgrace. > I'd encourage you to open a chat or phone for a business critical issue. That way Support doesn't spend an hour and a half trying to troubleshoot the wrong resource. Those errors can quickly be found and remediated on a call. The colleague who made the ticket put a phone number to get a callback in the ticket. They didn't call. We were actively trying to fix the issues we had, caused by the weird design by the Aurora failover system, not sit in a queue for an hour (yes, we had that too, business critical system down tickets where we spent >45 minutes waiting for a support rep). On another note, this is why I hate AWS support. It's literally a game of who can blame the customer or avoid fixing issues better. RDS export doesn't handle large databases? Don't make large exports. The UI breaks when you have large exports? Don't use the UI. Errors on an RDS instance when you spin up a second read replica? You ran out of capacity! And that's not saying anything of being ping ponged between teams for technical guidance tickets or having to fight support staff when trying to explain my problem. More than 1 hour spent in the loop of "but it works for me" "I don't care, it doesn't work for me", or outright false statements (even from engineers, not only support staff) that they have to carefully walk back when we actually try things out. I've not seen this 'customer obsession', ever. And I'd understand that if we were on developer plan or something, but we're not.

whoknew1122 4y ago

I'm not exactly sure how your example is particularly egregious. AWS Support doesn't know your workload. If you, who know your workload, can't figure out what's wrong, how can AWS Support figure it out in 15 minutes? > "that got an answer of 'looking into it' in 19 minutes, then ~1:45 an answer of 'oh, yeah, I checked and this and this DB you talked about didn't reboot', which was true, the person that made the ticket pointed out the wrong instance." Which wasn't AWS Support's fault. They looked into the resource on the ticket. Again, AWS Support doesn't know your workload and isn't going to go on a fishing expedition to guess which DB might be the issue. > "3 hours after I point the correct DB we get told, yes, you are right, it rebooted. And then on the 1st of April I ask for a timeline of how the writer/reader nodes changed during the reboot, I get an answer on the 20th, even though we pushed in the ticket and through our TAM for an answer." Timelines and RCAs have to go through the service team. Up to, and including, the service GM at times. It can be frustrating to wait for an RCA, but sometimes the things just take time. > "All in all, for the hundreds of thousands of dollars we're spending a month on support, I have a feeling that when we need it, we're kind of alone." I'd encourage you to open a chat or phone for a business critical issue. That way Support doesn't spend an hour and a half trying to troubleshoot the wrong resource. Those errors can quickly be found and remediated on a call.

gcbirzan 4y ago
> Which wasn't AWS Support's fault. They looked into the resource on the ticket. Again, AWS Support doesn't know your workload and isn't going to go on a fishing expedition to guess which DB might be the issue. No, they won't. I mean, definitely, two hours is not enough time to do anything except say "but it didn't reboot". > Timelines and RCAs have to go through the service team. Up to, and including, the service GM at times. It can be frustrating to wait for an RCA, but sometimes the things just take time. If essential information isn't present in the event log, or in any way accessible to the customer, and especially given how trivial the info was (we got back literally four bullet points two timestamps), almost 3 weeks is a disgrace. > I'd encourage you to open a chat or phone for a business critical issue. That way Support doesn't spend an hour and a half trying to troubleshoot the wrong resource. Those errors can quickly be found and remediated on a call. The colleague who made the ticket put a phone number to get a callback in the ticket. They didn't call. We were actively trying to fix the issues we had, caused by the weird design by the Aurora failover system, not sit in a queue for an hour (yes, we had that too, business critical system down tickets where we spent >45 minutes waiting for a support rep). On another note, this is why I hate AWS support. It's literally a game of who can blame the customer or avoid fixing issues better. RDS export doesn't handle large databases? Don't make large exports. The UI breaks when you have large exports? Don't use the UI. Errors on an RDS instance when you spin up a second read replica? You ran out of capacity! And that's not saying anything of being ping ponged between teams for technical guidance tickets or having to fight support staff when trying to explain my problem. More than 1 hour spent in the loop of "but it works for me" "I don't care, it doesn't work for me", or outright false statements (even from engineers, not only support staff) that they have to carefully walk back when we actually try things out. I've not seen this 'customer obsession', ever. And I'd understand that if we were on developer plan or something, but we're not.