<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Runbooks on F. Latini - IT Engineer</title><link>https://latini.dev/tags/runbooks/</link><description>Recent content in Runbooks on F. Latini - IT Engineer</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 24 Sep 2026 08:00:00 +0000</lastBuildDate><atom:link href="https://latini.dev/tags/runbooks/index.xml" rel="self" type="application/rss+xml"/><item><title>You Build It, You Run It. With What?</title><link>https://latini.dev/posts/you-build-it-you-run-it-with-what/</link><pubDate>Thu, 24 Sep 2026 08:00:00 +0000</pubDate><guid>https://latini.dev/posts/you-build-it-you-run-it-with-what/</guid><description>&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; - &amp;ldquo;You build it, you run it&amp;rdquo; is usually announced rather than equipped. Teams get a pager, a link to a wiki and a vague expectation, and the first time something hard breaks at 2am they call the platform team, because the platform team is the only group that understands the substrate. Help once and you are the escalation path forever. The fix is to treat operability the way you already treat deployment: as a paved-road default. Every service created on the road should arrive with a rota, alerts on the user journey, a dashboard, production access that works and a generated runbook that is true on day one. Split the runbook into the generic half the platform owns and generates, and a short specific half the team owns and drills. Offer enablement as a time-boxed engagement with an exit date, not as a standing rescue service. And make every rescue leave something behind in the kit, so the second call for the same problem never has to happen.&lt;/p&gt;</description></item></channel></rss>