Self-Service Provisioning
Teams getting infrastructure without a ticket, and the guardrails that make that safe.
6 to work through
-
beginner Multiple choice
Provisioning a database on this platform takes about 4 engineer-hours of real work. The median request takes 6 working days end to end. The platform team of 5 is fully occupied. Why is the lead time roughly twelve times the work time and which change reduces it most?
3 min answer -
intermediate
A platform offers self-service provisioning and teams still file tickets. Why, and what would change it?
2 min answer -
intermediate
Design the self-service interface for provisioning a database, so that developers do not file tickets and security does not object.
2 min answer -
intermediate Multiple choice
Which platform operations should be self-service, and which should require review?
1 min answer -
advanced
A self-service database provisioning workflow takes 40 minutes and fails about 15% of the time. The platform team says the cloud provider's API is unreliable. Retrying the whole workflow usually works. What is actually going on, and what would you change?
3 min answer -
advanced
Your platform team is now a ticket queue — every environment, every permission, every new service goes through them. How do you get out of it?
1 min answer
4 terms in this topic
Provisioning Reconciliation
Running a scheduled comparison between what a self-service platform intended to create and what actually exists in the cloud account, so partial fail…
practiceProvisioning Self-Service
Teams obtaining infrastructure without a ticket, within bounds that make the request safe by construction rather than by review.
practiceSelf-Service Provisioning
A developer obtaining infrastructure through an automated interface bound by policy, with no ticket and no human approval in the path.
conceptTicket Ops
An operating model where teams obtain infrastructure and change by requesting it from another team, making that team a queue.
Neighbouring topics
Platform Engineering
General material on internal platforms as products with users, adoption and lifecycles.
Internal Developer Platform
The assembled surface teams actually touch, and what belongs behind it.
Paved Road & Golden Path
A supported default route that is easier than the alternatives rather than mandatory.
Service Templates
Scaffolding new services with observability, CI and security already wired in.
Platform APIs
Treating the platform's own interfaces as contracts with consumers and compatibility rules.
Platform Tenancy
Isolating teams sharing a cluster, account or pipeline fleet, and where isolation must be hard.
Cluster Architecture
How many clusters, split by what, and the blast radius each split buys.
Service Mesh Operations
What a mesh genuinely solves, its failure modes, and the cost of running one.
Container Image Strategy
Base images, layer hygiene, rebuild cadence, and patching a fleet of images.
Developer Environments
Local, remote and ephemeral environments, and the fidelity each can honestly claim.
Inner Loop & Outer Loop
Where an engineer's time actually goes, and which loop a platform investment shortens.
Abstraction Level Choice
How much to hide, and the leak that turns a helpful abstraction into a trap.
Platform SLOs
Committing to reliability for internal consumers who cannot choose another provider.
Platform Adoption
Migrating existing teams onto a platform without a mandate, and reading the adoption curve.
Platform Funding
Central cost, showback, chargeback, and justifying a team that ships no customer feature.
Platform API Deprecation
Removing something dozens of internal teams depend on, on a timeline that holds.
Guardrails vs Gates
Preventing a class of mistake automatically versus stopping to ask a human.
Platform Telemetry
Instrumenting the platform itself: usage, friction, and where teams leave the paved road.
Platform Team Topologies
Stream-aligned, enabling, complicated-subsystem and platform teams, and their interactions.