Hacker News Reader

Comment by cfors | Hacker News Reader

I love these sorts of write ups. I wish there was a way to encourage internal transparency like this, as opposed to my least favorite way to be greeted when I let someone know about an issue with their product: "Can you try again?"

Nothing as infuriating as that, it could be a valuable learning lesson for many people just like this!

View on HN

I would love to see a blog post explaining the non-technical interaction for something like this. Is it a single person that understands all the networking plus the whole software stack, from HA-Proxy to the SSH hosts, or is it a team of people working together on the problem?

I feel like everyone involved would have to be more eager to solve the problem than worrying about assigning blame. Does that work because it's all within the same company or does GitLab make extra effort to dis-incentivize blame shifting and other unproductive behavior?

In my life (all small scale - local vendors) I call people and the only answer I ever get is roughly "our stuff if perfect. It's you."

We definitely take deliberate effort to dis-incentivize blame; it's specifically called out in our values at https://about.gitlab.com/handbook/values/#blameless-problem-... but speaking as an employee, I can confirm that this is my daily experience.

Of course for this specific issue there really wasn't anything or anyone to blame: no-one really did anything wrong at any point. Systems simply get complicated at certain scales and circumstances, and we have to engineer our way around the issues.

Back when I was studying for a cybersecurity course, I had the pleasure of reading a few posts on the Cloudflare blog. There are about 88 pages(!) of blogs at blog.cloudflare.com

A few recent ones might pique your curiosity

https://blog.cloudflare.com/on-the-recent-http-2-dos-attacks...

https://blog.cloudflare.com/a-gentle-introduction-to-linux-k...

https://blog.cloudflare.com/the-deep-dive-into-how-verizon-a...

Reply on news.ycombinator.com