There are two answers to this: the scrum answer and the deeper answer to the questions under the surface.
First, the scrum answer on carry-over work. At the end of a sprint, all items go back to the product backlog. There is, of course, strong motivation to pull them into the next sprint to finish, but it isn't assumed. Sometimes in the past 2 weeks other very important items came up that are more important than finishing that item. Also, carry over work is a light antipattern in Scrum. What I mean by this is that we do want to get to a complete product increment each sprint, but we also know that a team doing challenging work won't all the time. The rule of thumb Mike Cohn uses is "100% of the work done 80% of the time".
Ok, now the answer to why you're struggling. I don't mean to berate you when I say this, but there are a lot of misused practices in there and that is causing the parts of the Scrum framework not to support each other properly. First, Scrum looks to past sprints for the team's capacity. If in the last 3 or 4 sprints you completed an average of 25 man-days of work, then you take on around 25 man-days of work in the next sprint. Also, the team commits to a body of work, not individuals. Also, production issues are often open-ended, so unless you already know the problem and have an idea of what the solution may be, estimating them isn't often helpful. Usually, we want to instead time-box them, which sets an outer limit on how long you are willing to work on them before it impacts the overall sprint. Of course, some are very important, so if you reach your timebox, you don't just drop it, you regroup with the team and discuss how to move forward next. Usually, if you extend the timebox, you are also agreeing what work you will kick out of the sprint to make room.
This kind of capacity planning will give you more control over your pace of work and after a few sprints, you can get to that Mike Cohn rule I mentioned before. Once you are there, you can get into the really interesting bits of Scrum. Scrum looks at the team as a whole, not individuals. By fielding work as a team (sometimes this means things like pairing, group sessions, divide and conquer of individual tasks, etc) many teams find synergies allowing the overall team to be much more productive than the sum of the individuals. (I know synergy has become a terrible buzzword, but it's actually a real thing too)
For the charts, in Scrum, remember that those charts aren't the goal. Burndown charts, CFDs, velocity charts, they're like meters on a dashboard. They just tell you information. Carry-over work often leaves these charts looking erratic - which just tells you that the team is delivering the work in an erratic way. As they are able to smooth out the delivery of work, the charts smooth out.
On the review, in Scrum, the review happens at the end of the sprint and stakeholders and users give feedback on the work that was done in the sprint so the team has a better idea of what to do next. This may be another thing that is out of alignment. One of the most important things that Scrum lets you do in each sprint is learn. If the feedback from sprint reviews isn't changing your understanding of the work you are doing and influencing where you put your effort next, you aren't getting the primary value out of scrum. If your work doesn't need that (you work in a service center where you are simply doing tasks first come-first serve or in priority order), then Scrum may actually be the wrong framework to use. Not that it won't work at all, but it's like driving in a screw with a hammer.
