Yea, this is at the heart of what I also thought were the very point of it. In my experience on the mentioned project, I felt one of the few ways to get there,

Yea, this is at the heart of what I also thought were the very point of it. In my experience on the mentioned project, I felt one of the few ways to get there, unless you wrote the whole codebase, is to have enough time to build (or configure existing) some tools to be able to visually understand and/or navigate the system. During one week of being on-call engineer, inspired by the ideas of pro-activity and monitoring in SRE, I stole myself some hours to put together a script that would parse our ArgoCD configs to create a map of our Kafka topics, into a GraphViz-based HTML file with links to to the relevant topics as well as microservices (pointing to some web based inspection tools for these). This finally made me be able to figure out what was going on and be useful during incidents as a newcomer in the field, but no one in the team had thought of this idea of being a little pro-active, so most of the time when errors occurred, people would just scramble around all over the place, and only the really senior guys would be useful because of having the whole system in their head anyway. To me, this idea of pro-activity is what SRE brings to the table.