> To make this dream come true is far beyond the scope of just dev ops. Nah. It's not unreasonable. The oddest thing was the feature that would save state and

> To make this dream come true is far beyond the scope of just dev ops. Nah. It's not unreasonable. The oddest thing was the feature that would save state and logs in a document somewhere. Logs and dashboards already allow you to focus on certain times, so no need to store that state somewhere else. In fact, that would be worse as it would discourage people from digging further. > the runbook will need to be updated constantly after each release. Nah. Nothing in there was unique or special about that specific release outside of the failover. And even the failover is general enough to be a failover. Everything else is standardized to the point of being boring. > This means there's a long enough release cycle for this to ever happen which is also unlikely. Daily. Listen, nothing here was crazy. I've lived this. It's not hard. It's just boring conventions and consistency. Again, literally the strangest part was saving the state and logs in some extra document. The other weird thing was not checking the release logs (The release time was weird, too, but I'll ignore that). Rolling that release back would have been my first thought. And none of this is difficult. I realize not everyone is going to have the same experience, but it's not a dream, and thinking it's only a dream ignores how within-reach it really is.