The �� characters you have used in your question don't help to get an answer. These are just generic substitution characters used when the system can't display the character it's asked to. You will almost certainly have to dig in to the source data, and also check it at the various places in your system where it gets transformed.
You should first make reference to my blog post on the subject, where I explain how to decode UTF-8. This will allow you to compare the raw bytes with the characters you expect them to represent.
When you say "sometimes it is working and sometimes it is not working", the first thing to check is if content in a specific component in Tridion is always problematic. This will tell you if it's a problem with the content itself.
If you can isolate a specific piece of problematic content, check what characters have actually been entered. Some characters look very similar to others. Maybe one of your editors is working on a system that has some extra fonts installed, and is able to type something other than "CYRILLIC SMALL LETTER EN". More likely is that they are pasting content in from a source where the characters are incorrectly encoded.
If it's not about the content, it's about the various re-encodings that take place along the way. In this case, you are looking for ways in which the same source data could be transformed differently. Do you have more than one page template, with different encodings (or none) specified in the ASP directives? Does the content come from a different source entirely? For example, your page might embed results from a search service, or the content may be introduced by javascript or via include files, and the data may have followed a different route than the rest of the page.
You say that you can't see the error in pre-live, so you should double check the encodings on your publication targets.
It can be painstaking work, but no matter how much it might sometimes seem like black magic, if you can work directly with the bytes, you will be able to trace the logic.
