Developer Experience: Publish infrastructure service catalog for VFS teams

[jhouse-solvd]

Problem Statement

It is difficult for developers to navigate the platform’s infrastructure services. It is also hard to provide quality support when services are undefined.

Background / Context

The Infrastructure Team consistently receives the highest volume of support requests by team. The support bot is helpful, but many of the requests can not yet be classified as belonging to a specific service that the platform offers.

It would be great to "productive" the infrastructure services that the platform offers by making them available to developers on the platform website. Hopefully, this would also empower infrastructure & SRE personnel to provide high-quality, consistent support for those services.

How might we...

...make it easier for developers to navigate the platform's available infrastructure services? ...provide better documentation for the platform's available infrastructure services? ...better support developers in using the platform's available infrastructure services?

Hypothesis or Bet

We believe that this will result in a higher quality infrastructure support experience for VFS and platform crew teams. We believe that this will result in a higher quality infrastructure support experience for infrastructure and SRE personnel.

We will know we're done when... ("Definition of Done")

Five (5) infrastructure services are published to the Platform Website. And, the following exists for each service:

• the service is listed on the platform website
• developer-oriented documentation for the service exists on the platform website
• there is internal documentation (such as a playbook) for platform support personnel
• there are machine-readable GitHub issue templates (ie with boilerplate text, fields, choices; pre-defined by YAML; w/ limited free-form input)

Known Blockers/Dependencies

TBD

Projected Launch Date

TBD

Launch Checklist

Is this service / tool / feature...

... tested?

• [ ] Usability test (TODO: link) has been performed, to validate that new changes enable users to do what was intended and that these changes don't worsen quality elsewhere. If usability test isn't relevant for this change, document the reason for skipping it.
  • [ ] ... and issues discovered in usability testing have been addressed.
  • Note on skipping: metrics that show the impact of before/after can be a substitute for usability testing.
• [ ] End-to-end manual QA or UAT is complete, to validate there are no high-severity issues before launching
• [ ] (if applicable) New functionality has thorough, automated tests running in CI/CD

... documented?

• [ ] New documentation is written pursuant to our documentation style guide
• [ ] Product is included in the List of VSP Products
  • List the existing product that this initiative fits within, or add a new product to this list.
• [ ] Internal-facing: there's a Product Outline
• [ ] External-facing: a User Guide on Platform Website exists for this product/feature tool
• [ ] (if applicable) Post to #vsp-service-design for external communication about this change (e.g. VSP Newsletter, customer-facing meetings)

... measurable

• [ ] (if applicable) This change has clearly-defined success metrics, with instrumentation of those analytics where possible, or a reason documented for skipping it.
  • For help, see: Analytics team
• [ ] This change has an accompanying VSP Initiative Release Plan.

When you're ready to launch...

• [ ] Conduct a [go/no-go] (https://vfs.atlassian.net/wiki/spaces/AP/pages/1670938648/Platform+Crew+Office+Hours#Go%2FNo-Go) when you're almost ready to launch.

Required Artifacts

Documentation

• PRODUCT_NAME: directory name used for your product documentation
• Product Outline: link to Product Outline
• User Guide: link to User Guide

Testing

• Usability test: link to GitHub issue, or provide reason for skipping
• Manual QA: link to GitHub issue or documented results
• Automated tests: link to tests, or "N/A"

Measurement

• 5 ops-owned services are published to the platform website

• 50% of Ops support requests per sprint are completed by linking to a published platform website

• 3 or less support requests per sprint take longer than 30 minutes to complete

• Release plan: link to Release Plan ticket

TODOs

• [ ] Convert this issue to an epic
• [ ] Add your team's label to this epic

[jhouse-solvd]

Next epics:

[Access Management] Update AWS request process for VFS and Platform Crew teams [Platform Infrastructure] Standardize infrastructure request process for VFS teams

[mchelen-gov]

@jhouse-solvd What is the status of this Initiative?

[jhouse-solvd]

@mchelen-gov - This initiative never began. It was de-prioritized in favor of #35039.

However, we did begin putting together service documentation together in "Platform Infrastructure Services"

And, there was an issue template created that could be tested to see if it meets the needs of VFS teams:

"Infrastructure Request Form WIP"

Let me know what you'd like to do with this issue. Happy to discuss more! Thank you.