hi jorge<p>I&#x27;d actually applied to work at stripe about two years ago, you guys turned me down ;)<p>I was responsible for ops at a billion-device-scale mobile analytics company for about 1.5 years. Your tooling is far superior to anything we produced. I like the idea of a single source of truth describing the data model (code, tables, query patterns, etc.) a lot, and doubly-so that it&#x27;s revision-controlled and available right alongside the code.<p>I think it&#x27;s far from decided though, how much to involve human operators in processes like this. Judging from this answer, you seem to be on the extreme end of &quot;automate everything&quot;. How then, I&#x27;m curious, do you train&#x2F;communicate to developers what can be done safely vs. something that would cause i&#x2F;o bottlenecks, slowdown, or other potentially production-impacting effects? Can you even predict these things accurately in advance? (Some of our worst outages were caused by emergent phenomena that only manifested at production scale, such as hitting packet throughput and network bandwidth limits on memcached -- totally unforseeable in a code-only test environment).<p>It sounds like you let developers request changes (a la &quot;The Phoenix Project&quot;) but ops is responsible for final approval of the change? That actually sounds like a great system. Would love some elaboration on this.<p>In any case, great writeup and from one guy who&#x27;s been there when the pager goes off to another, sounds like the recovery went pretty smoothly.