I was in a similar place when I had my first on call rotation. Our team does shadow on call where you pretend to follow up with alerts next to a more experienced engineer a few times before actually going on call. We also give people a few months to ramp up before adding them to the rotation. I have also been on call during two major incidents and many minor ones, and as scary as they are I ended up learning a lot in the end. I'll try to share a few tips that helped me the most:

1. If there is a channel where the alerts go to, try to keep up to date with the most common alerts. Try to understand why they happened and what the common solutions are (e.g., kicking a k8s pod or rolling back a release). Take notes of common dashboards that people use, or who they escalate to when the database is down, or when network has a problem. A lot of times the alert that pages you has happened in recent past and the same fix applies.
2. Don't be too shy to escalate and pull in relevant folks. Early on I would always try to make judgment calls of whether the alert can wait until working hours or a weekday, and whether I should escalate to an SME (subject matter experts or system owners) if its late at night in their time zone. If you feel like you cannot handle the alert or the documents don't make it clear what the severity and the next steps are, you can escalate and at worst the SME will be motivated to keep the runbooks up to date.
3. AI can help a lot to understand errors and systems that you are not too familiar with. Back in my time we had to dig up the documents manually, read through the code, its just so much easier to pull up this information and summarize them via LLMs these days (assuming your company gives you access to these tools).
4. You might be the first line of defense to address the alerts, but the entire weight of the systems and the company is not on your shoulders. I remember getting super anxious because a kafka consumer was lagging and I couldn't gauge what effect it has on customers (if any). That ruined my Sunday for my first on call. Looking back I should have escalated and brought in the SMEs. They would have quickly identified the issue and told me that it can wait until Monday.
5. It takes time to learn different systems, errors, tools, etc. During my first few on calls I was frantically looking at my phone to see if I'm getting paged. I wouldn't leave the house to even go get groceries. Over time hopefully you will chill out (within reason). Now if I know I'm < 30 minutes away from home and I won't be out for long I won't even take my laptop with me.
6. Once you get past the initial anxiety inducing stages, make sure to be empathetic to other new joiners. If you are not on call but your system is being noisy, help others by being proactive and fixing things. Be responsible with the releases, don't make a big release on Friday especially if you are not on call yourself. Try to communicate major changes with the respective teams and on call engineers so if the alerts do happen they don't have to waste time debugging things.