Everyone makes mistakes. Just use the Hashnode search and you will find lots of posts about epic fails. Sure, when you break something in production, that's horrible. So in my opinion, there are different phases, and if you act accordingly and professionally, you will gain respect automatically. The phases below are a shortened/reworked version of the 8D problem solving process

Phase 1: EMERGENCY!

1. Delegate someone as "Emergency Manager". That person should communicate the emergency to all people who are involved to some degree (server unresponsive -> lines not working? Tell the shift leaders! etc.) and make sure that no one interrupts you and you have everything you need to work.
2. Analyse the problem / mistake. Do not think about who broke it, but what broke and how it can be fixed.
3. Fix it. Use all resources you need and concentrate on fixing it, even if that means getting someone out of an important meeting. Production always is top priority.
4. Calm down and congratulate everyone working on the problem. You just resolved an emergency situation!

Phase 2: Explain

This phase is about documenting what went wrong and talking to you boss. If it's a good boss, they will not even ask who caused the problem, but

• Why/How did it happen?
• How was it fixed? Is it a temporary fix?
• How can the emergency be prevented in the future?

The last question is more of a "homework". Prepare a few counter-measures. If you deployed bad code to a live-system inadvertently, change the process so that it is not that easy to deploy to that server by accident any more. Add the 4-eyes principle.

Phase 3: Lessons learned

Sit together with people involved in fixing the problem and your boss. Present them your solutions for preventing the bug. Show them that you gained experience! Once you reached a conclusion, implement it.

Phase 4: Be happy

There was a problem, you fixed it, but most importantly, you learned from it. Learning and growing with problems is important, too! No one is perfect and many problems with processes and standards can only be discovered by an incident. What you did was not only a good thing for yourself, but you also made the company a better place for your colleagues, because you (hopefully) found a way to prevent anyone from getting into your situation ever again.

There might even come a time when you tell other people about that emergency over a beer and you will all laugh. I have already heard countless stories of embarrassing mistakes. Hearing those stories tells me about things I have to watch out for and is a fun way to learn more about your colleagues. :)

Use this as an opportunity to discuss your HADR (High Availability, Disaster Recovery) strategies and how you may need to invest in more robustness. Here is a good read from Brent Ozar that addresses this issue as it relates to database administration (you can easily apply these principles to other aspects of your application though).

Write PMA: You need to report what happened, analysis how did it happen, and finally give practical solutions about how to prevent it happen again. You need to learn something and improve your workflow at last.