The Google SRE book will challenge assumptions you did not know you had. The central idea -- error budgets -- is counterintuitive: if your service has been too reliable, you should deploy faster and take more risks. Reliability is not a goal to maximize, it is a budget to spend. Too much reliability means you are shipping too slowly. Too little means you are burning user trust. Finding the balance is the art of SRE.
This reframes everything. Instead of "zero downtime" as the north star, you think in terms of acceptable risk. A 99.9% SLA means you have 43 minutes of downtime per month to spend on deploys, experiments, and migrations. That is liberating once you internalize it.
GitHub Actions for Rails is where this gets immediately practical. One workflow file that runs RSpec in a matrix (split tests across containers for speed), Rubocop for style, Brakeman for security, sets up the test database, and deploys to staging on merge to main. You probably have some version of this already. This module teaches you to make it fast, reliable, and comprehensive. Caching gems, caching assets, parallelizing test suites -- these are the details that turn a 20-minute CI run into a 6-minute one.
On-call is a skill, not a punishment. Most developers dread it because they have never been taught how to do it well. Runbooks, escalation paths, incident classification, blameless postmortems -- these are learnable practices that turn on-call from "pray nothing breaks" into "I know exactly what to do when it breaks." The best on-call engineers are not the ones whose services never fail. They are the ones who resolve incidents quickly and prevent them from recurring.
If you want staff-level credibility, own the CI pipeline and the incident response process. These are the unglamorous systems that every team depends on and few engineers volunteer to improve.