Define “production-ready”

Grab as much information about the problem as you can (logfiles etc.) and then rollback the production servers to a working state. That's a pain from the developer's point of view of course, but is most likely a given.

Next, try and see if you can reproduce the problem in a development environment. If you can, then fix it and try releasing again.

If you can't reproduce it, then see if you can add more diagnostics and release to one server for a short time to get more information about the problem.

If that's not possible then look more closely at the differences between production and the dev/qa environments and try to make a dev environment closer to production.

From the development manager's standpoint, it absolutely matters whether the defect is new or whether it is an existing defect because it has a direct and immediate impact on how the bug needs to be handled. From the development manager's standpoint, the most important question is whether a new bug needs to be resolved in the current release cycle or whether or whether it can wait and be prioritized in a later cycle. That, in turn, often depends on whether the bug is new or not.

If you've found a new bug, that implies that one of the new features/ bug fixes in the current release cycle introduced the issue. If that's the case, someone either needs to remedy the issue as part of the current release (either by reverting the change that introduced the bug or by fixing the bug itself) or the business needs to decide whether adding new feature X is worth deploying even if it introduces new bug Y. Almost always, the bug has to be resolved in the current build cycle or the offending change needs to be rolled back. On the other hand, if you've found an old bug that existed prior to the current round of changes, the current build cycle can generally continue and the new bug can be prioritized for a future release. Of course, there are cases where a newly identified bug needs to be handled in the current release cycle because the bug is just that critical, those cases tend to be rare.

Now, whether it should be QA's responsibility to check whether the bug affects the current release or whether that should be done by whoever is prioritizing the bugs (assuming that prioritization happens immediately) is an open question. My bias would be to ask QA to do it since they're already writing up the bug. Since the QA person already knows how to reproduce the bug, they're best positioned to verify whether it exists in production or not. The QA department also tends to have more hours available for this sort of investigation than the person doing the prioritization does since the work can be spread across many analysts.