In Part 1 of this series, we covered the operational overlap between DevOps and Site Reliability Engineering (SRE). While DevOps emerged from the need for agile and automated software delivery cycles, SRE has its roots in teams doing systems engineering. SRE emphasizes stability, observability, and proactive failure management. On the surface, they might appear to serve different priorities (speed versus stability), but both aim to build resilient systems that deliver value continuously and reliably.

Now, in Part 2, we shift focus from theory to practice. We will explore how organizations can harmoniously integrate both practi: the agility of DevOps and the resilience of SRE. During integration, it requires deliberate changes to culture, tooling, metrics, and collaboration patterns. We’ll examine how cross-functional teams can work in tandem. Additionally, we will cover how a unified performance framework can combine DORA metrics with SLOs and error budgets.

We’ll also look at real-world practices that teams can adopt. This guide will equip you with practical steps to build software at scale without compromising reliability.

Culture as the Foundation

Organizational culture determines how teams react under pressure, how they collaborate, and how they learn from failures. Without a shared culture rooted in trust, transparency, and ownership, even the most advanced tooling or process redesigns won’t succeed. When integrating DevOps and SRE, culture is the first and most crucial frontier.

Shared Ownership and Blameless Culture

Both DevOps and SRE emphasize a culture of ownership. Instead of assigning blame when things go wrong, high-performing teams focus on continuous learning. This mindset is supported by practices such as blameless postmortems, which encourage open discussions about incidents without fear of retribution. Even while working in high-stakes scenarios.

That doesn’t mean avoiding individual accountability. If someone accidentally deletes the production sales database and causes, for example, a $10,000-a-minute outage, the goal isn’t to gloss over what happened. It’s to understand why the system allowed a single person to cause such a failure, and how to prevent it in the future. A blameless approach focuses on improving processes to avoid the same mistakes from repeating themselves in the future.

A practical step is to institute joint retrospectives that involve both development and SRE teams. For example, after a production outage, a team may hold a postmortem that includes:

Such retrospectives, when shared transparently across teams, prevent knowledge silos and foster a shared understanding of system fragility. This learning cycle improves future resilience and helps ensure that the same mistakes aren’t repeated.

Practical Example

A practical example of implementing a blameless culture is by automating postmortems after high-severity incidents. Below is a GitHub Actions workflow (in YAML) that triggers when a GitHub issue labeled sev1 is closed. It automatically creates a new postmortem issue using a Markdown template. For more details, see GitHub Actions syntax reference and this GitHub repo.

What’s in the postmortem output?

A basic postmortem Markdown template (e.g., the PULL_POSTMORTEM_TEMPLATE.md referenced in the previous code sample) may include some basic system information, to which you would add details and follow ups after studying and discussing the issues that occurred:

This makes postmortems consistent, quick to generate, and easy to share across teams. You can customize the Markdown template to include other fields like severity ratings, customer comms, or Slack channel logs.

Explanation of the YAML Code Snippet for GitHub Actions:

Cross-Functional Teams

Siloed teams, each working on their own piece of the system without knowledge or concerns for the other teams, leads to communication breakdowns and delayed responses. Integrating DevOps and SRE means breaking down these silos by building cross-functional teams that work together toward common goals, enhancing both agility and reliability. Effective communication between teams fosters proactive problem-solving and quick adaptation to changing system conditions.

A powerful model is the DevOps-SRE rotation. In this model, developers take on on-call duties (even for a few days per sprint) under the mentorship of experienced SREs. This approach helps developers better understand operational challenges, encourages them to write more resilient code, and ensures that everyone has a stake in the system’s stability.

When developers switch roles, they gain direct experience with real-world issues that SREs face in production environments, from handling incidents to managing alert fatigue. Similarly, SREs get a chance to familiarize themselves with the design and functionality of new features, which helps in scaling and maintaining those features effectively. This reciprocal learning strengthens the bonds between development and operations, fostering empathy and creating a more resilient system overall.

Another effective approach is embedding SREs within development squads for specific feature sprints. During this time, SREs can:

These practices ensure that operational requirements are considered early in the development process. It leads to smoother deployments and fewer performance-related surprises in production.

To integrate developers and SREs into a cohesive on-call rotation, you can create on-call schedules using tools like PagerDuty or Opsgenie.

Example of a Terraform snippet to provision a rotation for DevOps and SRE teams using PagerDuty:

Earlier, we mentioned how integrating DevOps and SRE teams can include shared on-call responsibilities, such as having developers rotate into on-call schedules under SRE mentorship. If you’re implementing that model, you’d typically use something like PagerDuty schedules to manage alternating on-call duties automatically.

However, in many real-world cases, teams prefer a fallback-style escalation, where an SRE is paged first, followed by a developer if the SRE doesn’t respond in time. This model ensures that operational expertise is the first line of defense while still encouraging cross-functional awareness and shared responsibility.

The following Terraform snippet creates a PagerDuty escalation policy using static user references. It escalates to the developer only if the primary SRE does not acknowledge the incident within 10 minutes.

Explanation of the Code Snippet:

This configuration ensures that both the DevOps and SRE teams are engaged in the incident response process, reducing the risk of alert fatigue and fostering a sense of shared responsibility. The escalation policy also ensures that there is no gap in incident resolution, maintaining system reliability and speed in resolving issues.

This shared responsibility model helps both teams build empathy and technical depth by understanding each other’s contexts and operational challenges. The integration of developers and SREs into a single, unified workflow improves collaboration and ensures a smoother path to achieving both system reliability and software agility.

Leadership and Buy-In

Cultural transformation requires leadership to prioritize and model reliability. Leaders must treat reliability as a first-class feature, integrating it into team KPIs (Key Performance Indicators) and OKRs (Objectives and Key Results). This ensures that reliability is a shared responsibility across teams.

For example, leaders might set the following OKRs to focus on reliability while maintaining delivery speed:

These metrics ensure reliability is a key part of performance reviews. Leaders should actively review them in sprint reviews to reinforce the shared responsibility for reliability.

Additionally, the “you build it, you run it” model works best when leadership provides support. Engineers should be empowered to own their work, but adequate resources and guidance are crucial to avoid burnout.

Leaders should foster a culture of accountability and support by providing necessary tools, mentorship, and feedback, ensuring teams can deliver high-quality, reliable systems

Tooling That Unites, Not Divides

A fragmented toolchain often reinforces silos. When DevOps and SRE teams work on separate platforms and dashboards, it limits visibility and creates tunnel vision. To successfully integrate these philosophies, teams must establish shared visibility, standardized workflows, and tooling choices that support both fast delivery and system reliability.

Common Tooling Stack

The key to integration is aligning on a unified tooling stack across essential areas like CI/CD, Infrastructure as Code (IaC), monitoring, and observability. A potential integrated stack could include:

One of the most overlooked areas in DevOps pipelines is database change management. Traditional DevOps pipelines often exclude databases, treating them as manual bottlenecks. This leads to inconsistent deployment processes and makes it difficult to ensure smooth database changes. Redgate SQL Change Automation fills this gap by:

This ensures that database changes follow the same process as application code, allowing both developers and SREs to contribute to safe and traceable database deployments.

Sample Pipeline Using GitHub Actions and Flyway

For teams practicing database DevOps, it’s essential to integrate schema migrations into the same CI/CD pipelines that manage application deployments. Flyway, a widely adopted open-source database migration tool, enables version-controlled and testable database changes using SQL scripts or Java-based migrations.

Here’s a simplified example of how to automate database deployments with GitHub Actions and Flyway. This pipeline validates and deploys schema changes to a staging environment whenever code is pushed to the repository.

Explanation of the Workflow:

Flyway supports a wide range of databases (PostgreSQL, SQL Server, MySQL, Oracle, etc.) and allows you to manage schema changes with plain .sql files or Java-based migrations. You can store these scripts in version control to ensure traceability and rollback support.

Integrating Flyway into your CI/CD pipeline ensures that database changes pass through the same validation and deployment controls as application code. This improves release consistency and reduces the risk of breaking changes during production deployments.

SRE Observability Meets DevOps Pipelines

SREs often use Service Level Indicators (SLIs) and Service Level Objectives (SLOs) to track system performance. However, these metrics are frequently managed outside the deployment lifecycle, which results in missed opportunities for proactive remediation. To address this gap, it’s essential to integrate reliability checks directly into the CI/CD pipelines. This ensures that any performance issues are caught early and acted upon before they reach production.

Key strategies to integrate SRE observability into DevOps pipelines include:

Redgate’s Flyway integration can enhance this process by embedding database SLOs into the CI/CD pipeline. For instance, if a database schema migration is expected to take more than 10 seconds the deployment is halted, and a remediation workflow is triggered.

What is a database migration?In this context, a migration refers to any database schema change applied to a target environment, such as creating or altering tables, adding indexes, modifying constraints, or running pre-populated data scripts. Migrations can range from safe, additive changes (like adding a column) to non–backward-compatible operations such as dropping tables, renaming columns, or restructuring schemas.

Given this variability, teams should scope their SLOs based on the nature and risk level of each migration. For instance:

Here’s an example shell script to enforce a 10-second migration time threshold using Flyway:

This script can be extended to evaluate change types based on naming conventions or metadata (e.g., flagging destructive operations for stricter checks

Here’s another shell script you can use in a Jenkins pipeline to detect when a latency-based Service Level Objective (SLO) limit has been breached. While this script doesn’t enforce a rollback, it can be used as a gate that stops the deployment process early, helping teams catch issues before they reach production.

This script functions as an early exit checkpoint—if the 95th percentile latency exceeds the defined threshold it prevents the pipeline from progressing further. In a full implementation, this would typically be followed by rollback commands or automated remediation steps, such as reverting to a stable build, notifying on-call engineers via Slack or PagerDuty, or logging the event for audit purposes.

Note: This snippet is intentionally simplified to demonstrate the SLO check. In production systems, you’d likely wrap this in a larger script that includes rollback logic, notification workflows, or integration with deployment platforms.

More Explanation of the Code Snippet:

This type of gate is crucial because it prevents poorly performing builds from reaching production, thereby protecting the end-users from experiencing degraded service. By embedding SLO checks into the CI/CD pipeline, teams can proactively ensure that reliability objectives are met before a deployment progress to production.

Aligning Metrics and KPIs

Metrics are powerful tools for driving behavior. If your team’s metrics aren’t aligned, their priorities won’t be either. In DevOps, speed is often prioritized, measured by DORA metrics. While in SRE, stability is essential, tracked via SLIs (Service Level Indicators), SLOs (Service Level Objectives), and error budgets. An effective strategy strikes a balance between both.

Merge DORA + SLO Metrics

To get a complete picture of software performance, it’s crucial to combine the following key metrics from both DevOps and SRE:

When you merge these metrics, you can gain a more comprehensive understanding of both the speed (from DORA) and stability (from SRE) of your software. For example, if your team deploys multiple times daily, but constantly violates SLOs with incidents spiking post-deployment, this signals a reliability issue that needs addressing.

How Integration Looks in Practice

To integrate both sets of metrics, here are some practical steps:

Tag deployments in your observability tools (e.g., Grafana, Datadog, New Relic)

Deployment markers help correlate changes with performance shifts. For instance, when a new release is pushed, a tag allows teams to visualize when that happened and whether key metrics (latency, error rates, CPU usage) changed immediately afterward.

Correlate service performance with any kind of change event

This includes code deployments, configuration changes, and database migrations. Use CI/CD metadata, commit hashes, or deployment annotations to connect change events to service metrics like API latency or transaction success rates. This creates a traceable path between what changed and how the system behaved.

Trigger alerts for SLO violations after deployments

For example, if latency increases or query timeout rates spike beyond acceptable thresholds, this may indicate a degraded experience or reliability issue. These alerts help teams proactively catch performance regressions before they affect users.

Code Snippet 1: PromQL Query for SLO Burn Rate

Here’s a Prometheus Query Language (PromQL) query to measure the SLO burn rate for HTTP requests:

This burn rate query returns a ratio, specifically, the fraction of requests over the last 5 minutes that completed successfully (i.e., under 0.5s and not HTTP 500 errors).

Note on terminology: This query shows how close you are to meeting your SLO, not how much of your error budget has been “used up.” While the term “burn rate” is commonly used in SRE contexts, it’s important to understand that this isn’t a cumulative metric. It’s a real-time indicator of performance degradation — if the ratio drops consistently below your SLO target, then you start consuming your error budget.

Explanation of the Code Snippet

What’s the difference between _bucket and _count?

In Prometheus, _bucket is used to measure latency distributions by counting requests that are less than or equal to specific thresholds (e.g., 0.5s, 1s, 2s). _count tracks the total number of requests, so it acts as the denominator for calculating ratios or percentages.

Learn more about Prometheus histograms and SLOs:

Code Snippet 2: Git Tagging for Deployment Metadata

Incorporating deployment metadata into your observability stack helps teams correlate performance changes with specific deployments. One common technique is to tag commits in your Git repository at the point of deployment. This gives you a timestamped, versioned reference to when a specific codebase was shipped — which can later be visualized in tools like Grafana, Datadog, or Honeycomb.

Here’s a sample Git command used during deployment automation to create a timestamped tag:

Explanation of the Code Snippet

Dashboards and Visibility

A unified dashboard strategy is key to improving cross-team visibility and accountability. Rather than having separate DevOps and SRE dashboards, it’s more effective to consolidate them into a single, cohesive observability pane. This gives everyone, from engineers to management, a shared, real-time view of system health and performance trends. A well-structured dashboard should include:

Many teams use tools like Grafana to build and maintain unified observability dashboards.

Why Grafana?

Grafana is an excellent choice for building unified observability dashboards. It’s highly customizable and supports:

For enhanced collaboration, share these dashboards in Slack incident channels so that the team is immediately aware of any issues. You can also rotate ownership weekly to ensure that all team members stay familiar with the health of the system. Standups and retrospectives are great opportunities to review these dashboards, discuss any problems, and make improvements.

Example: Grafana Dashboard Panel for Error Budget Tracking

Here’s an example of how you might visualize error budget remaining in Grafana using a gauge panel. While Grafana dashboards can be exported or configured using JSON, most teams use the web-based UI to build them interactively.

This JSON configuration defines a gauge panel:

Explanation of the Code Snippet

What this does:

The panel calculates the remaining error budget by subtracting the current SLO burn rate from 100. For instance, if your burn rate is 0.25 (25%), this panel would display 75% error budget remaining.

How to use it in practice:

In Grafana’s UI, you would:

This configuration is useful when paired with alert thresholds — for example, triggering a warning when the remaining error budget drops below 50%, or a critical alert below 10%.

See Grafana’s panel editor in action:

Common Pitfalls and How to Avoid Them

Even with the best intentions, teams often stumble when merging DevOps and SRE. Understanding common failure modes can help you avoid them.

Silos Reappearing

Ironically, merging DevOps and SRE can recreate old boundaries. DevOps teams focus on deployment, while SREs chase uptime.

Solution

Co-author quarterly roadmaps and OKRs that align business velocity with error budget policies. For example:

Create shared quarterly reliability objectives across squads.

Example:

Tooling Overload

More tools ≠ better outcomes. Fragmented platforms lead to unclear ownership, duplicated effort, and increased maintenance overhead.

Solution

Standardize around a minimal, interoperable toolchain. Ideally, one that’s used consistently across DevOps, SRE, and development teams.

For database automation, use a tool like Flyway (or Liquibase). Flyway supports version-controlled schema migrations, integrates smoothly with CI/CD pipelines, and is simple enough for both developers and DBAs to adopt.

Assign clear owners for each tool in your stack and document internal usage guidelines. This ensures teams know how tools should be used, prevents duplication, and reduces context-switching overhead. A shared, consistent toolset empowers collaboration and makes system behavior more predictable at scale.

Maintain a single, easily accessible tool-ownership.md file (a Markdown file typically stored in your internal documentation repo) that lists each major tool in your engineering stack, along with its primary and backup owners. This helps prevent confusion, ensures continuity during PTO or turnover, and improves accountability for tooling decisions.

For example:

Tip: This file should be part of your internal engineering handbook or runbook, preferably version-controlled (e.g., in GitHub or GitLab), and linked from your developer portal or team wiki. Make it easy for anyone to find out who to contact for tooling questions or issues.

Not Defining Toil or SLIs Clearly

When toil is untracked, the monotonous nature of the work can cause people to silently (and sometimes not so silently) burn out. Toil refers to manual, predictable tasks that are operational but don’t contribute to long-term system improvements, such as restarting stuck services, manually pushing builds, or cleaning up logs.

These activities may seem minor in isolation, but over time, they consume team capacity, create frustration, and distract from higher-value work like automation, optimization, or feature delivery. Similarly, when SLIs (Service Level Indicators) are vague or poorly defined, they fail to reflect what matters to end users. This leads to misaligned priorities and missed reliability goals.

Solution

Quantify toil and set goals to reduce it.

Examples:

Also, align SLIs with user experience:

Track toil using Jira/Linear with a custom label toil and query reports monthly:

Wrapping Up: Working with DevOps and SRE

DevOps and SRE are not mutually exclusive. Together, they represent the next evolution of software engineering. They combine speed with safety, autonomy with accountability, and agility with observability.

The successful integration of DevOps and SRE requires more than adopting tools or changing titles. It’s a holistic effort that spans cultural transformation, shared metrics, and thoughtful tooling. Redgate Flyway exemplifies how a tool can operationalize this integration. It brings automation, versioning, and reliability to a traditionally opaque part of the stack: the database.

Organizations that implement this fusion not only ship faster but also build systems that withstand change. They align their teams on shared goals, empower them with reliable tools, and create feedback loops that continuously improve delivery and operations.

When you bridge the gap between DevOps and SRE, you’re not choosing between delivery velocity and reliability, you’re choosing both. And in doing so, you’re building the kind of resilient, scalable, and responsive systems that define modern software excellence.