Production Environment Review: The Ultimate Checklist

You’ve written code, you tested it and built it. Now, your release is ready to deploy into production.

But: is your production environment ready for the release? That’s a question every IT professional and platform engineer should be asking before accepting a new release — whether the release is an update of an existing app or a totally new deployment.

To that end, here’s a checklist to make sure that your production environment is ready to go. Obviously, your mileage will vary, and this list doesn’t address every aspect of every production environment in existence. But you can think of it as a starting point for designing a production environment review that ensures you…

• Are ready to accept a new release.
• Have the resources you need to support the release once in production.

So, let’s dive into the checklist to understand some things you should always review in production environments to improve release quality and cadence.

(For more dev resources, check out these DevOps conferences & must-read DevOps books.)

Production environment checklist for successful releases

These are things that any production environment should be prepared for. To learn more, explore these release management best practices.

Infrastructure mapping

Before accepting a new release, you should have a clear understanding of the infrastructure that will support it. Whether your infrastructure is on-premises, hybrid, a single cloud or multiple clouds, you want to be able to:

1. Map the architecture.
2. Know which specific servers or services will be hosting the release.

Delivery chain

How, specifically, is your application being released? Which tools are you using to deploy it? When should you expect the next release?

You can answer all of these questions by making sure you understand the delivery chain that is pushing the release out. Although the delivery chain is not part of your production environment per se, it plays a major role in ensuring that you can place applications into production successfully.

Service mapping

If your application consists of multiple services — as most do in cloud-native apps — you should understand how those services interact in order to compose the complete application.

• Which APIs or other interfaces do they use to communicate?
• Where is each service hosted?

Network mapping

Network mapping allows you to understand how your network or networks are configured. It’s particularly important in today’s world of complex, multi-layered, software-defined networks. Be sure that your network map both:

1. Includes public-facing endpoints as well as internal devices.
2. Distinguishes between external and internal endpoints.

(Learn more about network operations.)

Firewall configuration

Although the nature and efficacy of firewalls for cloud-based workloads isn’t what it was in the days when everything ran on-premises, firewalls are still useful tools. Before deploying a new release, be sure that yours is working and configured properly.

SLAs and contracts

Another basic requirement for a successful release is knowing which contractual requirements your production environment needs to be able to support. To be sure:

1. Check service level agreements (SLAs) and other contracts.
2. Ensure that your production environment is ready to support any requirements specified in them, such as uptime or data recovery.

(Read about SLAs, SLIs and SLOs.)

Backups and disaster recovery

What is your plan for backing up data or workloads and recovering them in the event of a failure? Your backup and recovery tools will vary widely depending on factors such as which type of infrastructure you use or what your recovery requirements are. Either way, make sure you have a backup and recovery plan in place.

Incident response

In the event that something goes wrong (it will), you’ll need a plan that defines who does what, and tools to help coordinate those activities. Even the best-designed production environments sometimes suffer failures or disruptions, and a solid incident response plan is the difference between a mere hiccup and a total disaster.

(Explore common incident response metrics.)

Performance monitoring

Deploying applications successfully requires not just getting them into production but ensuring that they perform adequately once they are there.

• Which application performance monitoring (APM) tools and processes will you use to monitor for performance challenges, identify their source and respond to them?
• Which team members are responsible for overseeing these tasks?

Security monitoring

How will you monitor for vulnerabilities or breaches in your production environment? Keep in mind that security monitoring is a multi-layered affair that should extend from application code to environment configurations to identity and access management and beyond.

Remote access & physical access

Which remote access tools, if any, will you use to support your production workloads? Are they properly secured? Likewise, if you rely on physical access to manage the environment, is that access available and is it secure? You want to answer these questions before deploying a new release.

Cost control

It’s easy for costs to spiral quickly due to unnecessary cloud resources left running or poor alignment between the type of cloud service you use and the workloads it hosts. Although ideally you’ve already thought about cost optimization before you deploy a new release, be sure that you have a plan in place for monitoring costs and identifying cost-optimization opportunities once your workload is running.

Planning for future releases

Your production environment will evolve over time. The infrastructure that hosts it, the configurations that govern it and the workloads deployed on it will change. For that reason, you should have a plan and process for accommodating future releases and needs, all while ensuring that your environment is able to adapt successfully as requirements change.

Successful future planning may be as simple as quarterly reviews. Often, a better approach is to build a continuous feedback channel that allows all stakeholders (developers, IT Ops and everyone in between) to communicate about upcoming changes or new requirements that will be placed on the production environment.

What is Splunk?

This article was written by Chris Tozzi. Chris Tozzi has worked as a journalist and Linux systems administrator. He is particularly interested in open source, agile infrastructure and networking. He is Senior Editor of Content and a DevOps Analyst at Fixate IO. His book For Fun and Profit: A History of the Free and Open Source Software Revolution was published in 2017.

This posting does not necessarily represent Splunk's position, strategies or opinion.