Operational Excellence in DevOps: Monitoring, Incident Response & Deployment Discipline

[0:00]Rafal: Welcome back to The DevOps Stack, where we dig deep into the real-world practices that make or break modern software teams. I’m your host, Jamie Tran. Today’s episode is all about operational excellence in DevOps—how monitoring, incident response, and disciplined deployments can transform your team’s outcomes.

[0:24]Rafal: Joining me is Morgan Liao, Principal DevOps Engineer at StratusOps Solutions. Morgan, thanks for taking the time to share your experience today!

[0:33]Morgan Liao: Thanks, Jamie. Excited to be here—and honestly, operational excellence is one of my favorite topics. It’s so much more than just keeping the lights on.

[0:49]Rafal: Let’s dive right in. When people hear 'operational excellence', they might think of uptime, or maybe they picture a wall of green dashboards. But what does it actually mean to you in the context of DevOps?

[1:10]Morgan Liao: To me, operational excellence means building a system—and a team—that can deliver changes reliably, recover from failures quickly, and learn from every incident. It’s not just about avoiding outages. It’s about evolving how we work, so we actually get better over time.

[1:29]Rafal: I love that. And before we get into the technical weeds, could you share a bit about your journey? What led you to focus so much on ops excellence?

[1:50]Morgan Liao: Sure! I started as a backend developer, but early on, I kept getting pulled into incident calls. I realized the code was just one part—how we deploy, monitor, and fix things in production was the real test. At StratusOps, I work with teams that run at serious scale, and I’ve seen firsthand how small improvements in ops can make a huge difference.

[2:13]Rafal: Let’s pause and define that a little more. When you talk about 'ops making a huge difference', are there any moments that really hammered this home for you?

[2:33]Morgan Liao: Absolutely. I’ll never forget a client where a lack of clear monitoring meant we missed all the early warning signals before a critical database failure. The outage turned a minor blip into a multi-hour incident. That was a turning point—the team realized we needed to rethink everything from alerting to deploys.

[2:55]Rafal: That’s a perfect segue. Let’s talk about monitoring. Nowadays, teams are awash in dashboards and metrics. Where do you see most teams going wrong?

[3:15]Morgan Liao: The biggest mistake? Mistaking visibility for actionability. It’s easy to collect thousands of metrics, but if you don’t know what ‘normal’ looks like, or you’re drowning in noise, you’re not actually safer. Real monitoring is about knowing what matters, and having systems that alert you only when human action is needed.

[3:34]Rafal: How do you help teams figure out what ‘normal’ is, especially in complex, distributed systems?

[3:57]Morgan Liao: You have to start with your business goals. For example, if you care about user experience, latency metrics might matter more than CPU. Also, baselining—looking at historical patterns to detect true anomalies—helps. And finally, involve engineers who know the system; automated tools are great, but human context is critical.

[4:17]Rafal: Let’s break down the types of monitoring—metrics, logs, traces. For listeners newer to DevOps, how do you explain the difference, and when do you reach for each?

[4:41]Morgan Liao: Metrics are your high-level numbers—like request rates or error counts. Logs are event details, super useful for debugging. Traces follow requests across services, so you can see where delays happen. Together, they give you both the big picture and the details, which is essential for troubleshooting complex issues.

[5:00]Rafal: Do you ever see teams over-index on one type and miss the others?

[5:16]Morgan Liao: All the time! I’ve seen teams with beautiful dashboards but no logs, so when something breaks, they’re blind. Or the opposite—logs everywhere, but no trendlines to spot slow drifts. The key is balance, and integrating them so you can pivot quickly from metrics to logs to traces.

[5:36]Rafal: Let’s make this concrete. Can you share a story where a monitoring blind spot led to a real-world issue?

[5:55]Morgan Liao: Definitely. At one fintech company, the team tracked API errors but ignored upstream database latency. One day, a slow query caused cascading timeouts, but the metrics dashboard looked fine—no error spikes. By the time users complained, we’d lost precious time. Afterward, we set up latency SLOs and started correlating logs and traces. It made a huge difference.

[6:20]Rafal: Such a classic scenario. So, how do you avoid drowning in noise? Alert fatigue is a real problem—how do you cut through it?

[6:41]Morgan Liao: It starts with ruthless pruning. Every alert should have a clear owner and a documented action. If nobody acts on an alert, it’s a candidate for deletion or automation. Also, threshold tuning—make sure alerts fire only when human intervention is truly required. Less is more.

[7:00]Rafal: Have you ever seen alert fatigue lead to a major miss?

[7:17]Morgan Liao: Absolutely. One team I worked with had so many false positives that engineers started ignoring pages. When a real outage hit, nobody trusted the alerts. After a painful incident review, we cut alert volume by half and saw on-call morale go up and response time improve.

[7:38]Rafal: Let’s shift to incident response. You’ve mentioned ‘blameless’ a few times. Can you define that, and why it matters?

[7:59]Morgan Liao: Blameless incident response means focusing on what happened and how to improve, not who to punish. Incidents are inevitable. If engineers fear blame, they’ll hide mistakes or avoid reporting issues. But if you treat incidents as learning opportunities, your systems and your people get stronger.

[8:18]Rafal: What does a blameless postmortem look like in practice?

[8:35]Morgan Liao: It’s structured: timeline, impact, contributing factors, what went well, what can improve. Crucially, you look for systemic issues—not individual errors. And you share the findings openly, so everyone can learn. It’s not always easy, but it pays off.

[8:56]Rafal: Can you walk us through a retrospective that really drove change for a team you worked with?

[9:15]Morgan Liao: Sure. At a SaaS provider, we had a nasty outage triggered by a bad deploy. Instead of finger-pointing, we mapped out the chain of events: missing tests, poor canary process, unclear ownership. The action items included improving our CI/CD pipeline and better deploy documentation. That incident led to a 30% reduction in future deployment-related incidents.

[9:40]Rafal: So, incident response isn’t just about firefighting—it’s about getting better. But in the moment, things can get pretty heated. How do you keep teams calm and focused?

[10:01]Morgan Liao: Preparation is everything. Run incident drills, clarify roles, and have runbooks for common issues. During an incident, one person leads, others execute or communicate. Afterward, acknowledge the stress, debrief, and support each other. Psychological safety matters as much as technical skill.

[10:22]Rafal: Let’s dig into a specific example. You mentioned a 'midnight paging storm'—what happened, and what did you learn?

[10:42]Morgan Liao: This was at an e-commerce company during a big sale. We had a misconfigured alert that paged the whole on-call rotation for minor latency blips. Nobody knew who should respond, so everyone jumped in, creating chaos. After that night, we mapped alert severity to clear owners, reduced redundant pages, and improved escalation policies. Night and day difference.

[11:06]Rafal: That’s such a common pain point. Let’s transition to deployment discipline. Some people think deploying fast is the only goal—how do you see it?

[11:24]Morgan Liao: Speed is great, but only if you can recover quickly. Disciplined deployment means you have guardrails: feature flags, canaries, automated rollbacks, and great observability. It’s about moving fast and safe, not just fast.

[11:39]Rafal: For listeners who might not be familiar, can you quickly define feature flags and canary releases?

[11:57]Morgan Liao: Absolutely. Feature flags let you turn features on or off at runtime, so you can test in production without deploying new code. Canary releases mean you roll out changes to a small subset of users first, watch for issues, then expand if all’s well. Both reduce risk.

[12:14]Rafal: Do you ever see teams overcomplicate their deployment setup?

[12:29]Morgan Liao: Yes, sometimes. Too many manual steps, or overengineered pipelines, can slow things down and introduce new failure points. The goal is automation with human checkpoints where needed—balance is key.

[12:45]Rafal: Let’s get concrete again. Can you share a mini case study on a team that moved from manual deploys to a more disciplined, automated pipeline?

[13:06]Morgan Liao: Sure. A logistics startup I worked with used to deploy by SSHing into servers. One night, a typo took down the order system for hours. After that, we invested in a CI/CD pipeline with automated tests, canary deploys, and rollback scripts. Deploy frequency went up but incidents dropped—because we caught problems earlier.

[13:27]Rafal: That’s a great example. But here’s a question—some folks argue that too much automation can make teams complacent. Thoughts?

[13:45]Morgan Liao: I hear that a lot. Automation is powerful, but you still need humans in the loop for judgment calls. If you don’t understand what your automation is doing, you’re just moving the risk around. Regular reviews and runbooks help keep knowledge fresh.

[14:00]Rafal: So, it’s about intelligent automation, not just more automation.

[14:09]Morgan Liao: Exactly. Automate the repetitive, risky steps, but keep humans involved for decisions, especially during incidents or major releases.

[14:23]Rafal: Let’s recap. So far, we’ve covered monitoring, alert fatigue, blameless incident response, and disciplined deployments. If you had to pick one practice that’s most often neglected, which would it be?

[14:41]Morgan Liao: Honestly, it’s the post-incident retrospective. Teams are so eager to move on that they skip the learning step. But that’s where the real improvement happens.

[14:54]Rafal: Couldn’t agree more. For teams just starting on this journey, what’s the first thing you’d have them do tomorrow?

[15:07]Morgan Liao: Audit your alerts and incidents from the past month. Ask: Did we need all these pages? Did we actually fix root causes? Even a one-hour review can reveal huge opportunities.

[15:23]Rafal: That’s actionable advice. Morgan, let’s pause here for a quick recap. After the break, we’ll dig into the nuts and bolts of deployment strategies, on-call sustainability, and how to move from reactive to proactive operations.

[15:33]Morgan Liao: Looking forward to it!

[15:39]Rafal: Welcome back. Morgan, before we get into deployment discipline, I want to push on something you said earlier: balancing speed and safety. It sounds great, but isn’t there always a trade-off?

[15:59]Morgan Liao: There is, but it’s not a zero-sum game. The best teams invest in their tooling and processes so that deploying quickly *is* safe—because tests are automated, canaries are real, and rollbacks are easy. If you’re cutting corners on safety for speed, you haven’t reached operational maturity yet.

[16:17]Rafal: That’s a strong point. But some leaders might say, 'We need to ship faster to stay competitive.' How do you respond?

[16:33]Morgan Liao: Shipping faster only helps if you can recover even faster. An outage or bad deploy that takes hours to fix will hurt your reputation far more than a small delay. Fast, safe deploys are the goal—and that means operational excellence isn’t optional.

[16:51]Rafal: Let’s get into deployment strategies. What are the core ingredients of a disciplined deployment process?

[17:08]Morgan Liao: Automated builds and tests, feature flags, staged rollouts—like canaries or blue-green deployments—and strong observability tied directly to new releases. Plus, a clear rollback plan. Everyone should know how to revert quickly if something goes wrong.

[17:23]Rafal: Do you recommend blue-green deployments for every team?

[17:36]Morgan Liao: Not always. For stateless services, blue-green works great. But for stateful apps or big databases, it can get complicated. Sometimes canary or progressive rollouts are simpler and safer.

[17:51]Rafal: Can you give a quick example of a deployment gone wrong—and how discipline helped recover?

[18:07]Morgan Liao: Sure—a media company pushed a new image processing service. They skipped the canary step, and a memory leak brought down half the fleet. With a proper rollback plan, we restored service in minutes, not hours. The lesson: never skip the safeguards.

[18:24]Rafal: Have you ever disagreed with a team about how much process is too much?

[18:37]Morgan Liao: Definitely. Some engineers want to automate everything, others want manual reviews everywhere. My view: automate what’s repetitive and low risk, but always review high-impact changes. It’s about context.

[18:49]Rafal: How do you resolve those debates in practice?

[19:01]Morgan Liao: Try experiments. For example, run with automated deploys for low-risk services, but require manual approval for core systems. Measure the results—incidents, deploy speed, team happiness. Data usually wins the argument.

[19:19]Rafal: Smart. Before we move on, let’s talk about on-call. Burnout is real. What can teams do to make on-call more sustainable?

[19:35]Morgan Liao: Rotate duties fairly, limit after-hours pages, and give engineers time to recover. Also, invest in tooling to automate responses to common issues. And recognize on-call as real work—not just an afterthought.

[19:50]Rafal: In your experience, what’s the most effective way to reduce on-call load?

[20:02]Morgan Liao: Fix recurring issues at the root. If the same alert fires every week, automate the response or fix the underlying bug. Over time, this shrinks the on-call burden dramatically.

[20:17]Rafal: Let’s recap where we are. We’ve talked about what operational excellence means, actionable monitoring, incident response, and deployment discipline, with lots of practical examples along the way.

[20:31]Rafal: Morgan, before we hit the halfway mark, any final thoughts on how teams can get started on this journey—especially if they’re overwhelmed?

[20:46]Morgan Liao: Start small. Pick one system, one alert, or one deploy process to improve this week. Celebrate progress, share wins, and keep iterating. Operational excellence is a journey, not a destination.

[21:03]Rafal: Great advice. After the break, we’ll go deeper on advanced deployment patterns, chaos engineering, and building trust between Dev and Ops. Stay with us—you won’t want to miss the next half.

[21:10]Morgan Liao: Can’t wait!

[27:30]Rafal: Alright, as we move deeper into the conversation, I want to pivot from the foundational principles to some of the real-world challenges teams face after adopting DevOps. So, let’s talk about how monitoring can break down in production, even when teams think they’re doing it right.

[27:57]Morgan Liao: Absolutely. One classic pitfall is over-reliance on static dashboards. Teams set up beautiful dashboards at the start, but as the system evolves, those dashboards get stale. Suddenly, you’ve got blind spots—services go down, but alerts never fire because the metrics aren’t up to date.

[28:19]Rafal: That’s so true. I’ve seen teams find out the hard way that their alerts were only watching for CPU, and missed a memory leak that took everything down.

[28:38]Morgan Liao: Exactly. Or the classic: you monitor uptime, but not response time. Your service is technically ‘up,’ but users are timing out. A key lesson is to keep iterating on your monitoring. Treat it as a living system, not a set-and-forget checklist.

[28:53]Rafal: Can you share a story where a team got this wrong, and what it cost them?

[29:18]Morgan Liao: Sure. I worked with an e-commerce company—let’s call them ShopX. They monitored server availability and error rates, but didn’t watch transaction latency. On a big sale day, the checkout service slowed to a crawl, but stayed technically ‘up.’ Customers abandoned their carts. By the time the team realized, they’d lost out on a huge chunk of revenue. Afterward, they started tracking latency and user journey metrics, not just system health.

[29:47]Rafal: That’s a painful but powerful example. It speaks to the need for end-to-end visibility. So, let’s dig into incident response. How do high-performing teams handle surprises?

[30:09]Morgan Liao: The best teams embrace blameless postmortems. When something breaks, they don’t focus on who messed up. Instead, they dig into what happened, why it wasn’t caught, and how to make sure it doesn’t happen again. That psychological safety is key. People are more willing to report near-misses, which gives you a chance to fix systemic issues early.

[30:34]Rafal: Right, and that’s not just warm and fuzzy—it actually boosts reliability. Can you walk us through what a good incident response looks like in practice?

[30:53]Morgan Liao: Sure. Let’s say there’s an outage. First, the on-call person gets paged and acknowledges the incident. Next, they assemble the right folks—maybe via a chat channel or a call. They work through a checklist: Isolate the blast radius, communicate with stakeholders, start a public status update if needed. As they triage, someone documents what’s happening. Once recovered, they schedule a post-incident review and identify action items to prevent recurrence. The key is clear roles, communication, and documentation—before, during, and after.

[31:24]Rafal: I love that you mentioned documentation. It’s so often skipped. Why does it matter so much?

[31:41]Morgan Liao: When you’re in the heat of the moment, it’s easy to forget what you tried, what worked, and what didn’t. Documentation lets you learn from each incident and build up runbooks, so the next time someone’s in trouble at 3 a.m., there’s a clear playbook to follow.

[32:02]Rafal: Let’s shift gears for a second—how do you balance moving fast with deployment discipline? Sometimes teams go all-in on continuous delivery, but things get reckless.

[32:20]Morgan Liao: That’s a great point. The magic is in guardrails. Automated tests, canary deployments, and feature flags let you move quickly, but with a safety net. You want to make it easy to deploy, but hard to make a catastrophic mistake.

[32:39]Rafal: What’s a real-world example of those guardrails saving the day?

[32:52]Morgan Liao: One SaaS company I worked with—let’s call them DataFlow—rolled out a new API version using canary releases. Within minutes, the canary users started seeing 500 errors. The deployment pipeline halted the rollout automatically, and the team fixed the bug before most users ever saw an issue. Without that discipline, it could have been a full-blown outage.

[33:16]Rafal: That’s a great segue. Let’s do a quick rapid-fire round—short answers, whatever comes to mind first. Ready?

[33:20]Morgan Liao: Let’s do it!

[33:22]Rafal: Best monitoring metric teams overlook?

[33:25]Morgan Liao: User experience metrics—like page load time.

[33:27]Rafal: Most common cause of alert fatigue?

[33:30]Morgan Liao: Too many low-priority or noisy alerts.

[33:32]Rafal: Favorite tool for incident response?

[33:35]Morgan Liao: A good chat-based incident command system.

[33:37]Rafal: One thing to automate ASAP after starting DevOps?

[33:40]Morgan Liao: Deployment pipeline testing.

[33:42]Rafal: Biggest myth about deployment discipline?

[33:45]Morgan Liao: That it slows you down—it actually speeds you up in the long run.

[33:48]Rafal: Last one: most underrated team habit for operational excellence?

[33:51]Morgan Liao: Regular retrospectives, even when nothing goes wrong.

[33:56]Rafal: Love it. Rapid-fire success! Let’s go back to our main thread. You mentioned canaries and feature flags. Are there any trade-offs or risks to these patterns?

[34:15]Morgan Liao: Definitely. Canary deployments need good monitoring—if you’re not watching the right metrics, you might not catch subtle bugs. Feature flags add complexity, too. If you leave old flags in the codebase, they create technical debt and confusion. So, you need discipline in cleaning up and reviewing them regularly.

[34:34]Rafal: Let’s bring in another mini case study. Have you seen a team struggle with feature flag sprawl?

[34:50]Morgan Liao: Yes. A fintech team I worked with introduced dozens of feature flags, but never removed them. Over time, it became almost impossible to know which code paths were active. A critical bug slipped into a rarely-used pathway controlled by an old flag. Their lesson: treat feature flags as temporary, and schedule regular flag audits.

[35:15]Rafal: Great advice. Let’s talk about cultural aspects. How do you help a team that’s stuck in a blame culture shift toward blamelessness?

[35:33]Morgan Liao: Start small. Celebrate when someone catches a near-miss or admits a mistake. Model the behavior as a leader—publicly thank people for raising risks. Over time, this builds trust, and people feel safer being honest about issues.

[35:52]Rafal: And when it comes to incident response, how do you avoid hero culture—that one person always saving the day?

[36:07]Morgan Liao: Rotate on-call duties, document everything, and make sure knowledge is shared. If only one person knows how to fix things, you’ve got a single point of failure. Encourage team-based problem solving.

[36:24]Rafal: Let’s touch on deployment discipline again. What’s your take on deployment freezes—useful or risky?

[36:39]Morgan Liao: They can be useful before major events, but overuse leads to pent-up changes and bigger, riskier releases. It’s better to make small, safe changes regularly, so you’re not sitting on a mountain of untested code.

[36:57]Rafal: I’ve seen that too. Let’s pivot a bit—how do teams handle monitoring for third-party dependencies? That’s often an overlooked area.

[37:13]Morgan Liao: Great question. You can’t control third-party services, but you can monitor how your application behaves when they’re slow or down. Set up synthetic checks, track error rates to external APIs, and have fallback strategies. Basically, monitor the impact, not just the service.

[37:34]Rafal: As we near the end, let’s dig into the ‘how it fails in production’ stories. Have you got one more example where operational discipline could have saved the day?

[37:51]Morgan Liao: Definitely. At a media company, someone accidentally pushed a debug config to production. The deployment pipeline didn’t have checks for config drift. It exposed sensitive internal endpoints for hours. Afterward, they added automated config validation and started treating configs as code, with reviews and tests.

[38:13]Rafal: That’s a nightmare scenario for compliance and security. It really highlights why deployment discipline is about more than just code.

[38:25]Morgan Liao: Absolutely. Treat everything—code, configs, infrastructure—as code. Automate checks, reviews, and rollbacks.

[38:36]Rafal: Before we hit our checklist and wrap up, what are some signals that a team is maturing in their operational excellence?

[38:52]Morgan Liao: You’ll see fewer recurring incidents, faster mean time to recovery, and more proactive fixes rather than reactive firefighting. People ask ‘how can we make this more reliable?’ instead of just ‘how do we fix it?’

[39:08]Rafal: And leaders start tracking those signals, right? They make it part of the team’s regular reviews.

[39:18]Morgan Liao: Exactly. The best teams make operational health visible and a shared responsibility.

[39:30]Rafal: Let’s get practical. Could you walk us through an implementation checklist for teams looking to level up their operational excellence with DevOps?

[39:41]Morgan Liao: Definitely. Here’s a high-level checklist—let’s riff on this together.

[39:46]Rafal: Perfect. Let’s do it step-by-step.

[39:52]Morgan Liao: First: Inventory your current monitoring. Make sure you’re covering infrastructure, applications, and the end-user experience.

[40:01]Rafal: Second: Tune your alerts. Remove noise, set clear thresholds, and make sure every alert has an actionable response.

[40:09]Morgan Liao: Third: Automate incident response where possible—build runbooks, integrate chatops, and rehearse with game days.

[40:16]Rafal: Fourth: Harden your deployment pipeline. Add automated tests, canary releases, and rollback mechanisms.

[40:25]Morgan Liao: Fifth: Review your use of feature flags and remove old ones regularly to avoid technical debt.

[40:31]Rafal: Sixth: Institute blameless postmortems and make learning from incidents a regular practice.

[40:39]Morgan Liao: And finally: Foster a culture of shared ownership. Everyone should feel responsible for reliability, not just the ops team.

[40:47]Rafal: That’s a solid checklist. If a team wants to start tomorrow, what’s the one thing you’d have them do first?

[40:56]Morgan Liao: Start with visibility. Map out what you can and can’t observe right now. You can’t improve what you can’t see.

[41:04]Rafal: Love that. As we wind down, what’s the future for operational excellence and DevOps? Any trends you’re excited about?

[41:17]Morgan Liao: I see more automation—AI-driven incident detection, self-healing systems, and better observability tools that bridge business and technical metrics. But at the end of the day, it’s still about people and process.

[41:30]Rafal: Couldn’t agree more. There’s always a new tool, but the fundamentals don’t change. Any final thoughts for listeners who want to level up?

[41:42]Morgan Liao: Iterate. Make small, continuous improvements. Celebrate reliability wins just as much as feature launches. And remember, operational excellence is a journey, not a finish line.

[41:55]Rafal: Thanks so much for joining us. This has been a deep dive, and I think a lot of teams will take away practical strategies from today’s episode.

[42:04]Morgan Liao: Thanks for having me. I always enjoy these conversations.

[42:14]Rafal: Before we officially sign off, let’s do a lightning summary of our key takeaways for operational excellence with DevOps.

[42:30]Morgan Liao: Alright—here we go: 1. Keep monitoring relevant and up-to-date. 2. Practice blameless incident response. 3. Automate deployment with safety nets. 4. Regularly review and clean up feature flags. 5. Make reliability a team sport.

[42:46]Rafal: Perfect. If you’re looking for more resources, check out our episode notes for links to runbook templates, postmortem guides, and more.

[42:55]Morgan Liao: And remember, every incident is a chance to get better—don’t waste it.

[43:10]Rafal: Thanks to everyone who listened in. This is Softaims, signing off until next time. Keep building, keep learning, and keep striving for operational excellence.

[43:19]Morgan Liao: Take care, everyone!

[43:31]Rafal: And that’s a wrap. Thanks for joining us for another episode on DevOps and operational excellence. See you soon.

[43:37]Morgan Liao: Looking forward to it!

[43:44]Rafal: Alright, we’re officially out. Until next time!

[43:50]Morgan Liao: Bye!

[44:00]Rafal: Thanks again for listening, and don’t forget to subscribe.

[44:06]Morgan Liao: See you all soon.

[44:10]Rafal: Take care.

[44:15]Morgan Liao: Bye for now!

[44:20]Rafal: And we’re out!

[44:25]Morgan Liao: Have a great day.

[44:30]Rafal: Thanks everyone. Goodbye.

[44:35]Morgan Liao: Goodbye!

[44:40]Rafal: This episode was produced by Softaims. For more, visit our website.

[44:44]Morgan Liao: Thanks, and take care.

[44:50]Rafal: Goodbye!

[44:55]Morgan Liao: All the best.

[45:00]Rafal: We’ll catch you in the next episode.

[45:05]Morgan Liao: Looking forward to it.

[45:10]Rafal: Stay operationally excellent, everyone.

[45:14]Morgan Liao: Yes, keep pushing the boundaries!

[45:20]Rafal: And don’t forget to follow us on your favorite podcast app.

[45:24]Morgan Liao: Bye!

[45:29]Rafal: Take care!

[45:33]Morgan Liao: Goodbye!

[45:39]Rafal: Thanks so much.

[45:42]Morgan Liao: Thank you!

[45:45]Rafal: We’re out!

[45:48]Morgan Liao: Goodbye!

[45:50]Rafal: Signing off from Softaims.

[45:55]Morgan Liao: Until next time.

[46:00]Rafal: And with that, we end our episode on operational excellence with DevOps. Thanks for listening!

[46:05]Morgan Liao: All the best!

[46:10]Rafal: Bye!

[46:12]Morgan Liao: Goodbye!

[46:15]Rafal: Thank you, everyone.

[46:17]Morgan Liao: Thank you!

[46:20]Rafal: We’re out!

[46:23]Morgan Liao: Bye!

[46:25]Rafal: Thanks for tuning in.

[46:30]Morgan Liao: See you next time.

[46:35]Rafal: Stay excellent.

[46:38]Morgan Liao: Bye!

[46:40]Rafal: Goodbye.

[46:45]Morgan Liao: All the best.

[46:50]Rafal: That’s all for today.

[46:55]Morgan Liao: Thank you.

[47:00]Rafal: Take care.

[47:05]Morgan Liao: Bye!

[47:10]Rafal: Goodbye.

[47:15]Morgan Liao: See you.

[47:20]Rafal: Thanks again.

[47:25]Morgan Liao: Bye!

[55:00]Rafal: And with that, we close out at exactly fifty-five minutes. Thanks for being with us.