Adding development tooling frustrations to personas to reflect cost of multi-team root cause analysis

Why is this change being made?

When we develop GitLab our team members generally have full admin access to a GitLab instance and can debug problems from end-to-end.

When our tool is used by customers, only in the smallest shops would this be the case.

The Customer's separation of duties of "development on GitLab" (Sasha persona) and "GitLab operations" (Ingrid persona) will precludes these same troubleshooting steps.

At customers doing root cause diagnosis on GitLab misconfigurations can quickly become a multi-team, multi-day affair.

However, during GitLab product development this pain is less perceived because development teams generally have a completely dedicated test environment.

Better log hinting and "after error problem probing" can dramatically reduce this friction.

Hopefully this encourages an engineering approach to exception processing that is sort of "Support Call Deflection as a first priority"

Every time we can have exception processing do a little more work to narrow the range of a problem, we improve the built-in intelligence of the system and reduce expensive synchronous human work for ourselves and for customers.

I don't feel we should be OK with the error messages of third party tools if their ambiguity creates the risk of synchronous support.

This is exactly what DevOps is supposed to fix. When I led a developer tooling team of 4 that serviced 4000 devs - we directly took the escalation support calls related to our own code (DevOps) - and it did exactly what it was supposed to do - we were very responsive about building in as much root cause narrowing intelligence as we could so that devs could find their own misconfigurations before presuming it was a central resource that was down and causing a lot of synchronous human interactions.

Case In Point in Power of Perspective Shift

This Issue: Disambiguate Error Messages for KAS versus GitLab Agent Connectivity and this small MR Draft: Add probing for service port connectivity demonstrate that a change in perspectives is needed and can be very valuable in creating both GitLab and Customer efficiency in regard to support escalations and developer troubleshooting.

Author Checklist

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added.
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
• If the changes affect team members, or warrant an announcement in another way, please consider posting an update in #whats-happening-at-gitlab linking to this MR
  • If this is a change that directly impacts the majority of global team members, it should be a candidate for #company-fyi. Please work with internal communications and check the handbook for examples.

---