<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Observability on Nerdsid.com</title><link>https://nerdsid.com/tags/observability/</link><description>Recent content in Observability on Nerdsid.com</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 14 Nov 2025 23:43:47 +0530</lastBuildDate><atom:link href="https://nerdsid.com/tags/observability/index.xml" rel="self" type="application/rss+xml"/><item><title>Systems Aren’t Predictable - 3 Lessons From a DR activity</title><link>https://nerdsid.com/posts/systems-arent-predictable-3-lessons-from-a-dr-drill/</link><pubDate>Fri, 14 Nov 2025 23:43:47 +0530</pubDate><guid>https://nerdsid.com/posts/systems-arent-predictable-3-lessons-from-a-dr-drill/</guid><description>&lt;p>&lt;strong>Lessons from a DR activity that didn’t go as planned&lt;/strong>&lt;/p>
&lt;h2 id="what-is-a-disaster-recovery-dr-activity">What is a Disaster Recovery (DR) activity?&lt;/h2>
&lt;p>A DR activity is a planned exercise, where you intentionally flip your workloads to a secondary setup. It may be a new region, a new cluster, or a new infrastructure environment.&lt;/p>
&lt;p>The goal is to ensure that everything works the way it should when your primary environment is unavailable.&lt;/p>
&lt;h2 id="lessons-from-dr-activity">Lessons from DR activity&lt;/h2>
&lt;p>This week, we ran a DR activity. Everything looked perfect on paper.&lt;/p></description></item></channel></rss>