Category Archives: DevOps

The false security of Notifications

it’s like jumping into my car and every time i see the dashboard every light in there is brightly lighted up – to the point that one day i stop caring. eventually, someday something will fail – i just hope it’s not the day when I am driving to someplace in an emergency.

Most of our Notifications and alerting strategy is more than a brightly lit Dashboard. We cant any more tell what’s gonna fail when.

It’s a false hope we live with.

Make Sense out of your Stack Traces

I recently came across this cool tool http://www.stackifier.com/ which allows you to make so much sense out of your stack traces. Once I have locked on a stack I want to look at, this tool makes it so much easier.

Don’t Like Throttling?

Guess what – you are stuck with it. So you can chose to let the underlying system handle it or you can chose to dictate how your traffic should flow.

Do not let the illusion of control dictate the performance. Be the one who needs to control and manage the traffic

High availability design

Of course, eventually with many fixes over time you will eradicate a lot of cases that led to failures but it would have taken you so long and the reputation that the brand holds do dear is already damaged. You can chose to design for High Availability or you can chose to be just like Indian Railways – always delayed and always cancelled – a perspective that will i don’t think will ever be fixed no matter what they do.

Quality has new meaning – it is shit

Project Manager: I was just checking on the defect count and noticed we have 24 open P1 and P2 in system. How are we are going to go live tomorrow. What just happened?

QA Manager 1: Nothing, it is just that my team currently does not have any work for Release 2. They had some time on their hands and hence pro-actively they started to test in R1 and logged these defects.

Project Manager 1: so what are you going to do?

QA Manager 1: Nothing, these are not R1 defects. Testing is closed. We wrapped that last week and all these have tobe logged in R2. These are not R1 defects.

Who the hell needs Quality?

I will let you do the math, but what made me fell out of my chair was the fact that everyone in the room was accepting the fact that even before we were developing the application we would have 66% of the time spent in fixing defects. Not even once did anyone asked, how can we ensure that we do not have so many defects in the application. Now even once did anyone asked if we already have Unit testing how come we still have these many number of defects.