You have to do this at the inception of the software you’re building rather then strap it on the donkey when something breaks (the usual way).
Moving fast has it's downsides and I can't say I blame people for deprioritizing good logging practices. But it does come back to bite...
Though as a caveat, you don't always have control over your logs -- especially with third party services, large but fragmented engineering organizations, etc. -- even with great internal practices, there's always something.
On another note, access to codebase + live logs gives room to develop better auto-instrumentation tooling. Though perhaps cursor could do a decent enough job at starting folks off
* Make sure the logs are actionable
* Make sure the logs are readable
* Make sure you are collecting operational metrics
* Make sure the metrics are useful
* Make sure you have error handling
* Make sure you have alerting
* Make sure you document how to support the application
* Make sure you have knows and levers you can pull in an emergency to change the systems behavior or fix things
* Make sure you have vetted the system for security issues
etc.