Source
r/redhat•
bishopolis

Escalating tickets for adequacy

I've requested a ticket be escalated today, and I hate the reasons why.

The support rep must be trying, and must be putting in the effort, but it seems we've swung really hard in the RH support quality pendulum, and I just can't wait for it to swing back.

For me, the last crisis of faith this big was 2014, when the company I'd just joined had a strange request: set up spacewalk, and then convert the company's entire stable to centos from RedHat. It was an easy task, but I simply had to know why. The reason? Management was so upset with support that it was ditching its entire subscription, feeling they were self-supporting anyway, and this way they could save enough to fund a full-time staff position -- not me, as I was already filling a seat vacated rapidly because #dotcom. Yes, we all know support contracts and bloated everything-but-rhel-as rhel courses are how we fund kernel maintenance; but you know how people only see the tail and not the dog.

It's 8 years later, and I'd jump to the same conclusion. Today's case had all the hallmarks of a really challenging support interaction:

  • not reading what we already discussed (me and this rep)
  • quoting KBs that I've already mentioned trying
  • processes that seem to be stalling efforts (sosreports for issues not on a given host)

I rather feel like someone's phoning it in until the customer gives up. Some of this would be tolerable, except the articles I'm ploughing through are increasingly trending away from "technical writer" to "elementary drop-out" in writing quality. If you say "quick writing and chat doesn't need to be actual English", I'll debate where the dividing line is - and where we begin respecting our readers enough to revise and spell-check - all day. The highly-localized writing patterns have edged into the realm where I'm making really bad assumptions about the writer, and losing that air of authority doesn't seem good when readers are supposed to trust that some process on offer has been tested and validated as a solution.

These articles, they'll claim, are part of a programme to bring answers quickly and make them more available, but one wonders when the actual technical writers get the hand-off and make them coherent; or just bring them up to archival or reference quality. I was privileged to belong to a company with two teams of technical writers, one for each Unix OS it built, and I wonder whether we've lost our way because we no longer know what good documentation looks like.

Maybe a spell-check is a good start, and we can work on adjective order later.

Thank you for listening to my rant. If you point out any unclear bits or simply mistakes, I'd be happy to take 4 seconds and revise them more than any article I've read today.

Update: we're back up and running. And when it's done, whole avenues of questions - including why a request to escalate - written, not button - was ignored, and some technical questions - remain; but I haven't the energy to pursue it all. I'm weary. Just a comment and case closed. But sad soliloquies aside, I would point out that part of my near-quarter century of experience with RHL and RHEL was some years mentioned above at a similar shop in a number of roles from bottom to top; and when I say that this experience and a growing number like it would not have attracted me had it been the norm in 1998, I hope it's understood that it comes from a position of caring and growing concern, and the insider experience to objectively compare against. There's only so much regret we can share about a worrisome trend before it needs to be more-than. Again, thank you.

Posted Jul 20, 2022, 5:17 PM UTC · edited

2113
ctowsleyRed Hat Employee•

u/bishopolis, I just wanted to offer the opportunity to reach out to me directly with your ticket info, either here on reddit via DM or directly at [email protected]. I've been in contact with our Escalation Management team regarding this post and they'd love the opportunity to touch base with you, figure out what's gone wrong, and hopefully resolve any communication issues in your ticket so that the investigation and troubleshooting can move forward.

If you'd like, just provide me your ticket number or the email you use for the Red Hat account attached to the ticket and we'll reach out!

17
ctowsleyRed Hat Employee•

These articles, they'll claim, are part of a programme to bring answers quickly and make them more available, but one wonders when the actual technical writers get the hand-off and make them coherent; or just bring them up to archival or reference quality.

Specific to Knowledge Base Solutions (and not the technical product documentation), generally speaking, for better or worse, they are handled exclusively by the support team and never receive interaction from specific technical writers who handle official product documentation. As a result, the quality can vary based on the specific engineer, and the time frame of the article.

Obviously there are guard rails in place and format guidelines to try and set a specific standard as well as review processes to help identify poorly written solutions, but as you identified these solutions are often intended to be used for quick-reference materials for very specific configuration or use case issues which don't fit well in generalized product documentation. We're always working to improve and update existing material so don't hesitate to just open a ticket specifically about a poorly formatted or written article and it's likely it will be resolved.

Additionally, I certainly wouldn't discourage you from engaging with our escalation team if you feel like communication has broken down (or never really started up!) in your support ticket - again we're all humans over here and sometimes we miss the mark which is why that escalation button exists; to get your problem out in front of more eyes so we can help reorient and prioritize appropriately. Don't feel bad about using it, it's not a "bad" thing necessarily, just a tool for our customers to help us improve our engagement with you, the customer.

11
jlprufrock•

Thank you for your rant.

I second it.

4
vap0rtranz•
  1. Why not press the Escalation button? That's what it's there for.
  2. Who is your RH customer rep? and when did you mention this experience to them?

Not sure why folks are hesitate to escalate. The purpose is a) huge biz impact, or b) unsatisfactory support. RH support is like any large vendor support, so they all have these support levels & processes now. L1/Helpdesk is basically there to route your request after covering the basics.

Maybe a spell-check is a good start, and we can work on adjective order later.

It is absurd to assume everyone speaks English as their native/1st language, and there's plenty of grammar / spelling errors in code itself. Heck, there were explicatives in the Linux kernel that had to be purged for the offended! If folks only want only US based, English 1st support engineers, then the price of that support will be much larger than current licensing / maintenance costs.

we all know support contracts and bloated everything-but-rhel-as rhel courses are how we fund kernel maintenance

This is just inaccurate.

The big corporate kernel contributors are: Intel, AMD, Hauwei, Google, IBM/Red Hat ... the order / ranking changes year to year. Point is: Intel, AMD, Hauwei can recoop costs of kernel maintainers via hardware sales. Google can re-coop through ad revenue. RH can only re-coop costs via their license. It's not bloated, and it's not just the kernel.

I don't think folks realize how much OS bells and whistles cost. I had a chance to dig deep into RHEL's NIST and CSI certifications. It's not cheap, and the certs have to be redone (aka. re-occuring OpEx), and those aren't the only certs. If you don't use the cert, fine; but there lots of examples of an OS being more than the kernel. Hardware certs costs money too, and usually the OEM pays (most) the cost of those but not always. Given all this, RHEL is cheap. It's not free but it ain't expensive IMO.

If you want $0 nothing is stopping you from maintaining Slackware for your organization. Job security FTW! :) Another option is those "rhel courses". It builds your resume without having to build-your-own OS, and with certs -- any certs -- you can demand a high income in the market. For reasons we know but those reasons are a political hotbed to discuss -- IT folks expect to be paid a heck of a lot of $$$ in the US and those incomes get paid through revenues generated by customers paying big licensing invoices. If all those support engineers are US-based & English native, the cost of a RHEL license must go up.

7
ctowsleyRed Hat Employee•

RH support is like any large vendor support, so they all have these support levels & processes now. L1/Helpdesk is basically there to route your request after covering the basics.

Well to correct you somewhat, we use a collaborative swarming method for ticket management. While we do have an internal technical escalation path, an individual support engineer will handle your ticket from beginning to end 95% of the time, with contributions from specialist resources where necessary. Generally, we find this helps with maintaining a coherent support experience.

If folks only want only US based, English 1st support engineers, then the price of that support will be much larger than current licensing / maintenance costs.

As a side note, we do offer Confirmed Stateside Support for many of our subscriptions. That said it won't change who the author of a specific KB solution was.

6
vap0rtranz•

we do offer Confirmed Stateside Support

1st I've heard of that. How do customers get this? Add-on to sub?

2
ctowsleyRed Hat Employee•

It's mostly targeted to government customers, but definitely bring it up with your sales team for more information! CSS is a specific SKU that would replace your current product in your account. Depending on when your most recent renewal was, you may be able to discuss a "mid service upgrade", where you'd replace your current subscriptions with the new ones and just pay the difference in the time left on the sub.

2
bishopolisOPRed Hat Certified Engineer•

Why not press the Escalation button? That's what it's there for.

As a Canadian, I believe adequacy isn't an emergency for which we need to raise a daily alarm. It's cultural, like the empty left lanes in western Massachusetts.

It is absurd to assume everyone speaks English as their native/1st language

Yes it is, but that's not what I was saying in the slightest; and I said something actually quite different. You're sounding a bit defensive so I'm reluctant to address this point; but it's reliably the case that for a particular audience and environment, people exist that are educated, native writers or at least fluent, to which the work of checking these documents can be assigned after the mad rush 'early-access' period has passed. Of course I would not try to edit an article in Icelandic, for example, for I'm not educated in Icelandic sentence structure and it would be difficult to read; but I appreciate the support.

I'm not sure we need to talk about coding, the kernel, or the other tangents.

1
R3D3MPT10NRed Hat Employee•

I hate seeing stories like this. I’m sorry you have had that experience. You already have someone on this thread ready to help you with it. But to echo the sentiments here, don’t hesitate to hit that button. It’s not a negative thing at all. We do have ticket handling expectations that I won’t outline here in a public forum. But basically, tickets are reviewed for case quality. Those solution articles have a similar quality review. But when you hit that button, your case will be reviewed and we will make sure the short comings are resolved.

I can wholeheartedly assure you that we want you to have the best possible experience as a customer. And we will absolutely do our best to address issues as they are bought to our attention. I come from the support organisation and now work within the engineering group. In both areas, customer experience is definitely front and centre.

Let us know via that escalation button, case comments and also the survey all the ways in which we can do better. Also, if you find a crappy solution article, feel free to raise a support case about it. We will address it. We endeavour to have a solution article for all customer issues. So if we solve your case, and there was some takeaways there that could have prevented it, that info should be captured in a solution article. But anyone can write them and it’s more of a peer review process rather than technical writers. So sometimes, there can be issues. But we will definitely resolve them as we become aware. I quite often review the ones I come across to see if they’re still relevant or can be improved.

2
vap0rtranz•

Well, don't conflate in your comments either.

Your OP is about escalating a ticket. Then there's this conflation with KB docs written with poor grammar?? These are unrelated. These aren't related. Write 1 complaint about escalation, and a 2nd about poor tech writers. Hence you get replies attempting to understand what the heck your talking about.

2
[deleted]•

[deleted]

1
corsicanguppy•

I get the poor writing, and you have a point about sticking to one topic: the theme wandered a bit.

Like rants do.

I think the really bad writing in the tech docs (that never gets cleaned up ever) looks really bad for PurpleHat. Like, it's great that we get to see a fix, but can we lose the 'see below item follow' bit? Is that the localization she's talking about?

And the thing about the coursework is a bit of a diversion. My hat rep talks about Ansibull, OpenFlack, MSSybase, and I wonder whether they're on a mission to sell everything that isn't RHEL and ignore the fact that they still make an OS. Looking at the preponderance of fridge art in this new one, I'm thinking they've already forgotten it's supposed to be unix-like! ;-)

But there I was on a tangent too. Happens when you're old.

0
eraser215•

I'd put it to you that comments like yours are generally insulting to the people you're talking about and just generally unhelpful. Please have a think before you post something like this again.

2