How do you manage different environments

Hey there ​@casey  👋 Hope you are doing well!

There isn’t a native, first-class concept such as “Environment” in PagerDuty.

Also, when discussing Business Services, they should generally reflect customer-facing outcomes, so they are most often tied to Prod only.

What most people end up doing regarding environments is:

1. Configure separate technical services based on the environment
   1. Use when you want different on-call rotations, escalation paths, SLAs/SLOs, maintenance windows, and change policies. This is also great to have a clean blast- radius separation and clear analytics per environment.
   2. It does give you more services to manage, but you end up with clear ownership and minimal cross-env noise.
2. Have a single service where the environment is captured via tags/custom fields and routing rules.
   1. On this, you create a single service and rely on Event Orchestration to parse the environment out of the payload and configure tags, incident custom fields, and route/priority based on environment. With this approach, you maintain a single service but rely on rules and filters to segment things out.
3. Hybrid approach:
   1. In here, you have a technical service for Prod and aggregate all the other envs into one or fewer services. The Business Service depends on only on the Prod technical service so you keep your business impact accurate and avoid the service sprawl situation that point 1 might induce.

So a quick TLDR:

If you have different responders/urgency in Prod than in NonProd environments: create separate technical services per environment and attach only Prod to Business Services.

If your team treats all the environments the same way operationally: keep one service and use Event Orchestration + tags/custom fields to identify the environment. 

Let me know if this helped! Have a great day 😁

Thanks ​@danieljcafonso for the response.

To explain our situation, we are basically grouped into a few teams that support a `portfolio` of services that are related, often dealing with single domain, like `genomics` for example.  `genomics` will have a number of microservices underneath it, each with deployments in our 3 environments.  We don’t want to ignore these completely, however treat them as less important than our prod environment.  

For context, `genomics` might have a service called `markers` and one called `genotypes` + several more.   Each is sort of independent, but there are sometimes dependencies between them.  We care about the overall health of `genomics` because it’s degraded if any of it’s microservices are down, etc.