[kyrra]

Fun fact, Google uses IRC as a communication channel for incidents[0]. IRC is stable, simple to host and connect to, and easy to log. So all of Google could be on fire, but the incident responders have a simple tool to use to communicate that likely won't die.

[0] https://landing.google.com/sre/sre-book/chapters/managing-in...

[tomrod]

Is this something folks outside Google can access to get a human being in Google?

[joshuamorton]

Lord no. In what universe would it make sense to let random people spam a channel you're using to coordinate an emergency response.

[tomrod]

Intake/ingestion.

[joshuamorton]

Avenues for that already exist. But the signal from those kinds of things is so so low compared to the noise that you often need multiple layers of moderation and filtering before anything useful.

A direct line from $random user to the on call is a recipe for disaster (ie your sres quitting) when you have many users. Engineers aren't first line tech support and those roles shouldn't be confused.

[tomrod]

Of course. And my thinking when posting my first comment was the cliche critique that Google has no human tech support. I wrote it a bit tongue in cheek after trying to get a human at another tech firm for several weeks now.

I fully understand what you're saying and mostly agree. Thoughts on having registered users of certain products having access (e.g. Domain purchasers, Google app admins [office? What is that product suite called these days?])?

[rhizome]

Outsiders would be -v devoiced.

[joshuamorton]

Then this doesn't solve GPs problem (being able to communicate with insiders) and leaves the problem of needing to worry about all communication being public. That means people's names, commands, tools, architecture, etc. Which is certainly something I'd be curious about, but there's no good reason to take those risks.