<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Observability and Deployment on Brian Faust</title><link>https://wimdy.works/series/observability-and-deployment/</link><description>Recent content in Observability and Deployment on Brian Faust</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 01 Jan 0001 00:00:00 +0000</lastBuildDate><atom:link href="https://wimdy.works/series/observability-and-deployment/rss.xml" rel="self" type="application/rss+xml"/><item><title>Rollback Cannot Restore a Contract You Already Removed</title><link>https://wimdy.works/thoughts/rollback-cannot-restore-a-contract-you-already-removed/</link><pubDate>Wed, 01 Oct 2025 00:00:00 +0000</pubDate><guid>https://wimdy.works/thoughts/rollback-cannot-restore-a-contract-you-already-removed/</guid><description>&lt;p&gt;Release A stores a catalogue quote in &lt;code&gt;amount_cents&lt;/code&gt;. Release B renames the
column to &lt;code&gt;amount_minor&lt;/code&gt; and deploys successfully. Every new B process is
healthy, so the deployment dashboard looks reassuring.&lt;/p&gt;
&lt;p&gt;One A process is still serving traffic during the rolling update. Its next
query asks PostgreSQL for &lt;code&gt;amount_cents&lt;/code&gt; and fails because the column no longer
exists. Restoring the A image produces the same error. The old code returned;
the contract it needs did not.&lt;/p&gt;</description></item><item><title>Observability Must Answer the Next Operator Question</title><link>https://wimdy.works/thoughts/observability-must-answer-the-next-operator-question/</link><pubDate>Mon, 01 Sep 2025 00:00:00 +0000</pubDate><guid>https://wimdy.works/thoughts/observability-must-answer-the-next-operator-question/</guid><description>&lt;p&gt;A catalogue quote request returns &lt;code&gt;503&lt;/code&gt; after its price dependency times out.
One telemetry bundle produces five uncorrelated log lines, a metric labelled
with request ID and raw URL, and three pages. None of those pages names an
owner, the affected scope, the hold duration, or even the first query to run.
There is plenty of telemetry and very little help.&lt;/p&gt;
&lt;p&gt;The other bundle records less and tells the operator more. One page identifies
the affected route, region, and release. Its first query measures the failure
users can see. From there, an exemplar selects a failed trace, the trace locates
the dependency wait, and a correlated event names the application failure
class. The runbook then asks the question which actually matters: is it safe to
bypass that dependency?&lt;/p&gt;</description></item></channel></rss>