DevOps Burndown chart

What you're asking for is a lack of transparency.

A burndown chart shows the amount of remaining work on the y-axis and time on the x-axis. When you take on this ad-hoc work in the middle of your Sprint, the amount of remaining work will increase. If you're using a burndown chart, not reflecting the newly added work means that you are not being honest and transparent with the people reading the burndown chart.

It may be better to understand where this urgent ad-hoc work is coming from. There may be opportunities to identify the need to do the work earlier so it can be refined and planned. There may also be opportunities to understand its true urgency and importance and defer some to a future Sprint. In some cases, though, if a sufficient amount of ad-hoc work is a part of the nature of the team's work, perhaps it doesn't make sense to use a framework that is built around planning and executing timeboxed iterations.

How can I add ad hoc user stories for urgent work in DevOps Team without impacting the burndown chart? Is there any way that can be used where we donot get the scope creep type of Burndown chart? My team has to take ad hoc work almost every other day which always impacts our sprint. 

If work is being pushed on to the team, it's bound to impact their ability to meet the Sprint Goal. They've already made their commitment and now some other commitment is being thrust on them. Why are you trying to cover the matter up?