Thursday, September 15, 2016

Finishing what you started

A quality of a good Startup engineer is "Finishing what you started". I value finishers more than people who talk good theory and start many things but don’t finish most of them. Most of the time people get excited and start many things concurrently but leave them in limbo or they finish 95% of the thing.  Over 7 years at my current Startup I have observed that in many projects doing first 95% may take you X units of time but its the remaining 5% that demands 10x cognitive effort and time from you. Its this last 5% where people either burnout or give up. Its the finishers who keep the compass pointing to North star, never give up and do what ever it takes to Finish( in indian mythology saam, daam, dand, bhed).

Recently One of my respected colleague "Sachin" left for a sabbatical. He was one of the Finishers whom I would hire any day on my team or would choose as a buddy to watch your back.  "Sachin" has a zeal like a Rhino or Triceratops to Finish what he started and for this I value him the most.  Best of luck to him and I hope he gets bored with sabbatical and joins back :).

Saturday, September 3, 2016

What a rocky start to labor day weekend

Woke up by earthquake at 7:00 AM in morning and then couldn't get to sleep. I took a bath, made my tea and started checking emails and saw that after last night deployment three storage node out of 100s of nodes were running into Full GC. What was special about the 3 nodes was that each one was in a different Data centre but it was named same app02.  This got me curious I asked the node to be taken out of rotation and take a heap dump.  Yesterday night a new release has happened and I had upgraded spymemcached library version as new relic now natively supports instrumentation on it so it was a suspect. And the hunch was a bullseye, the heap dump clearly showed it taking 1.3G and full GCs were taking 6 sec but not claiming anything.



I have a quartz job in each jvm that takes a thread dump every 5 minutes and saves last 300 of them, checking few of them quickly showed a common thread among all 3 data centres. It seems there was a long running job that was trying to replicate pending storage objects as per replication policy and it had 50M or so backlog to catchup.  It seems newrelic was holding on to all that data for the thread and not just collecting the aggregate stats, the job was running for hours causing memory to increase with each replicated file.

Now I had two options:-
  1. Rollback the library
  2. Suppress newrelic instrumentation
I thought of going option#2 as it wont require any new build, just run puppet and restart all nodes.  Boy I was wrong , newrelic has negligible documentation for the yml file.  I filed a support ticket as they have no phone support even for emergencies even though we pay thousands of dollars a month. After IPO their support team quality has also reduced, the support told me hey go and disable the class, i am like its natively supported by you so give me some hints how to do it. She told me that a OOM ticket is filed 2 versions ago so I can wait for it to be fixed, wtf. I waited 20 min for her to tell me how to disable it and no reply,  It seems even she didnt knew how to do it so she was buying time letting me hanging dry on a cloth line. I started mining the support forum and google and I tried 5-10 settings with our devops engineer and newrelic agent is stupid that it would take any wrong setting too and show it in the UI. I ended up with a settings nightmare


Finally I tried one setting which was weird but worked, I had updated library to spymemcached-2.12.1 but the setting to turn it off in newrelic was

  class_transformer:
    com.newrelic.instrumentation.spymemcached-2.12.0:
      enabled: false

notice the setting is called 2.12.0 even though my library is 2.12.1, wtf.  It was late in night for the devops engineer and I was almost 5 hours on the desk, we just patched those 3 special nodes and called it a day. The other nodes would be patched by puppet before Monday using automation. 

Today I also complete 7  years at the company :).


Thursday, September 1, 2016

Hanging on to old things

I have seen my Kid grow from 0 to 6 year and one startup growing from 20 to 150 employees and another growing from 5 to 300+ employees.  A common trend I seen is hanging on to old things.  Not sure if its due to sentimental value attached to things or inability to make hard choices.  My Kid still has his toys that he used to play when he was 1 year old. He wouldn’t let us throw them or give it to someone, I am recently working with him to let go of old things.  Problem with old things is that they are a drag, they just sit around the house and are a clutter. Its the same with old books, I have many of them and one day I need to go and clean them once I read a book,  I rarely read them again so why not donate them to library.

A common observation with Startups I have worked is feature bloat due to holding on to old features. Features that are not maintained but are in use by a handful of customers causes drag. Recently I wanted to refactor folder listing code to not load additional versions data as the new UI doesn’t require it. But as I started chasing reference graph I found 5-10 places in old versions of UI using it with some complex intertwined data structures and what seemed like 1 hour worth of work seemed like 1 week of work. I gave up refactoring it due to other important things on plate. Ultimately biggest loser in this is the new UI.

Sometimes we have to make tough decisions and let go of older things else it creates a baggage not only to us but others too.