Out of ~20 engineers, we have about 4 that have unrestricted access to production. A couple more have read only I believe to one of the databases.<p>I also have direct knowledge of a couple of other startups, similar size of 20-30 people in engineering, and they are about the same, no more than ~6 people.<p>In most cases, people really shouldn't be accessing production, it should mainly be deployment tasks that do. But you need a certain number of people to have access to cover failures etc. For example, having at least 4 people provides coverage if one person is on vacation, and then another gets sick etc.<p>I've read other companies basically have every engineer has production access to what they deploy, not sure I agree with that approach but I can see the argument.
DevOps manages production. Everyone junior-senior asks for access, senior-senior knows better and lets the team assigned manage it. If anything goes wrong in production at 4am not having access means you will not be called
I can access the Production website and create new builds that can go into the pipeline of UAT and Production.<p>I don't have access to approving the pipeline to release to Production, but that's just a permissions thing that we only realized last week I didn't have when I was to manage the release while my boss was on vacation. I'm the tech lead of the project with four other developers on the team.
Each team has production access to their own services, access to each services is managed via a custom solution integrated with GitHub. Requesting access to a service will requires the relevant service owners to approve the pr, you can also delegate access via this repo aswell if you want
Needless to say, if your identity here can be traced back to your employer + your name, be careful what you say. It could lead to spear phishing attempts.