Interrupts in a nutshell
CPUs spend most of their time running software, which for them means following a predictable flow of instructions. However, in some situations, it is desirable to interrupt a program's flow and have the CPU do something totally different instead.
Imagine, as an example, that a program, while doing maths, incidentally divides a number by zero. This mathematically makes no sense, so the CPU can't give a reliable result, and the program's execution can't continue normally. In that case, it's best to have the CPU run a chunk of code designed to handle this event. This mechanism is called an exception.
Another event in which a program's flow should be interrupted is when something new happens on the hardware side. Imagine, as an example, that you are running some piece of software which accepts keyboard input. How is it informed that new keys have been pressed ? In the days where dinosaurs where roaming the Earth, it was common to ask such software to periodically check if anything new has happened on the keyboard side. This process, called polling, is cumbersome, prone to failure (if software does not check keyboard often enough, key presses will be lost), and both inefficient in terms of CPU cycles and power consumption. It is in most cases much better to have the keyboard notify the CPU when a key is pressed, and make sure that this triggers the execution of a chunk of code which registers the key press before giving back control to the previously running software. From one CPU architecture to another, the name of this process varies, but it is commonly called an Interrupt ReQuest (IRQ), external interrupt, or just interrupt.