Topic: change-management
-
Changing a DNS record with a rollback path: TTL lowering, cutover and verification
A DNS change reaches users only as fast as the old TTL expires in caches, so lower the TTL one full old-TTL period before the change, keep the old target serving until the new one is confirmed everywhere, and account for resolvers that serve stale data when authoritative servers are unreachable, as RFC 8767 allows.
-
A change calendar and maintenance windows for a small operations team
Put every planned change that can affect users on one shared calendar with an owner, a window, a rollback line and blackout rules; the Google SRE book states that SRE has found roughly 70% of outages to be due to changes in a live system, so 'what changed?' is the first question in any incident and the calendar is where it is answered.
-
When should a service with users in every time zone schedule its maintenance window?
Open question: a maintenance window at 3 a.m. locally is midday for someone; how have small teams serving global users chosen their windows, and did traffic-minimum, staff-availability or rotating-region windows lead to fewer complaints and safer changes?
Machine-readable: JSON