The key is historical data.
If you record how long (including interruptions) it takes to complete a given type or size of task, than for future tasks, you just need to identify the type/size of a new task, and apply the historical data to figure out how long such a task typically takes. Since the data you've been recording included various interruptions, etc., then the estimate for the future will factor those in as well.
Example: lets say this is the data for the last 10 times you had to make a textual update to a web page:
time note
10m
10m
1.5h got pulled away to fix a production bug
10m
45m server offline due to upgrade
10m
10m
4h entire staff evacuated due to bomb scare
10m
10m
Clearly, it only takes you 10 minutes to do the actual update. However, the average time it took in real life is about 45 minutes. If you have 5 updates to do tomorrow, estimate them at 45 minutes each.
This approach should also help factor in unforeseen items that are part of the task -- it only takes 10 minutes to do the code, but 15 minutes to deploy it because you have to FTP it over here, then rsync it over there, etc. Again, that will show up in the historical data.