Could you mitigate all timing attacks by putting a sleep(random()) with a naive crypto implementation? Eg if your implementation looks solid, but you're not sure what the next CPU cache vulnerability is around the corner, would this be a legitimate mitigation strategy?
To clarify, this would be a random delay measured from before the algorithm starts, so that you're not simply adding fuzz to the runtime.
Adding random sleep may make it slightly harder, but not more than that. The problem with adding random noise is that the average time will still be different between the two measurements you are trying to make. So, you will need more measurements, but eventually will get the right thing, since the averages will stand out. This is how timing attacks can be done over the Internet (see Remote Timing Attacks are Practical), even though there is timing noise in networks.
First, let's define what is usually meant when someone talk about "random delay" (correct me if I miss-understood what you actually meant). If you want to efficiently hide the real time execution of your function, you want to add $x$ seconds where $x$ is close to the average execution time (otherwise it will be easily noticeable). The way you stated your question, I will also assumed your $random$ function is uniform, i.e. all value have the same probability of being drawn.
With this setting, adding random delay will only slow down the attack since the average distributions will still be distinguishable. However, an attacker may need to collect more sample to be able to cancel the noise you introduced.
I invite you to take a look at this presentation (slides available here) which gives a well illustrated description of the problem, and go further to explore different countermeasure based on delay.
Considering an attacker able to probe your cache (namely for instruction), he would be able to determine when the real function was called, and when the sleep function was called, making this countermeasure useless.
In general, to avoid such vulnerabilities, it is recommended to make sure your code doesn't have any secret-dependent branch and memory access. A simple delay wouldn't do much, even if you use it to smooth the overall time execution (which may be quite tricky to do since as Yehuda Lindell said, the time would be platform dependent).
N.B.: If you want to consider CPU-cache vulnerabilities, you need much more than simple delay. Namely, you need to avoid secret-dependent branch and memory access.
