Tag Archives: Computers

Just How Many is “Everyone”?

His problems are many, but he is only one person.

Ah, language.  I remember a while back, being a passenger in a car with a friend of mine. We were at a fast food drive though because he had a coupon.  So he placed our order and told the attendant on the other side of the speaker he had a coupon.  The attendant asked him “How many people are in the car?”

My friend replied , “All of us!”

I say this because when you are opening up an incident ticket, it may ask you how many people this incident is affecting.  Even if you have multiple personalities, if you are the only one affected, then you are the only one affected.  Saying that this is affecting the whole company when obviously it is not is more likely to get a hearty laugh from the person who gets your incident (along with a few other people on the desk). This is basically known on the desk as lying about your situation in order to have someone look at it “right now!”

Protip: This never, ever works.

You see, yes, we jump on emergencies with both feet.  We’re the high tech firemen and women, trying to make sure that real four alarm fires are taken care of quickly.  We want to help everyone, but we have to set priorities.  Sometimes we can get to you immediately. Sometimes, we can’t.  But we will, as soon as we can.

Do it enough times, and your name will become well known as someone who is trying to game the system.  Yes, we talk about people like you in between putting out fires. When we see that the incident is not the level of everyone in the country catching Ebola at the same time, we set the ticket to reality.  if you really are adamant about doing this continuously, we’ll have a conversation with your boss about it.

And that is a ticket, I don’t think you want.

Show Me On the Ticket Where the Bad Thing Happened

If you picture your Help Desk like this, it can make you feel a little better.

Not to sound dramatic, but an Incident is kind of like a crime scene. In order to piece everything together the person on the help desk needs to know exactly what happened.  Everything.  Yes I know, what you need doesn’t work, but I need to reassemble the crime scene in order to see what happened.

That is why putting everything on your ticket is helpful.  This is not a blame game, but an investigation. Sometimes, (actually, more than you think) one software program is at odds with another, and yes, this can happen when the software packages are created by the same company (I’m looking at you, Microsoft).  Sometimes it is user error.  Hey, we all make mistakes.  And sometimes what is happening can actually be a symptom of something far worse.  But unless the incident team knows what is going on, the incident is nothing more than ” Damned if I know.”

So, what needs to be on the ticket?  First, besides your name and how to contact you (which should be automatically recorded on the ticket), I need to know the following:

  1. The time it happened.  This helps us if we need to check server logs.  Things happen all the time, so knowing when it happened helps us dig through the chaff.
  2. Exactly what happened.  The more detailed you can be, the better.  Just saying “It doesn’t work” means we have to call in Miss Cleo and her tarot cards to divine what happened.  And while I love her fake Jamaican accent, she’s never right.
  3. What else was running in the background.  Excel is giving me an error message and I have Word and Visio also running.  This may have something to do with it, it may not.  But we know that there are other avenues we might be able to check if our first assumption is wrong.
  4. Screenshots.  Just like a crime scene investigation, pictures record a lot more than people think.  If you have an error message, get a screen shot to add to the ticket.
  5. If your ticketing system does not capture the information concerning the computer you are on (Some do, some are stupid), then please add that to the ticket as well.  There are times when the hardware does not play nice with the software.

In other words, nothing gets ruled out at the start.  Once we can verify the alibis for various parts, then we can find the perp, solve the problem and wrap up the case a lot neater the Law and Order sometimes does.  If we find that what you are experiencing is part of a larger problem, well, we have a larger case to solve.  We’ll keep you updated.  Olivia Benson never gives up.  Neither do we.  *Chu-CHUNK!*

You Are Not The Most Interesting Developer in the World

Where I work, we deal with developers who were apparently dropped on their heads at a very young age.  Repeatedly.  Onto concrete.  Repeatedly.  I also work with project managers who apparently had the same thing happen to them.

The reason I point this out is because some people truly believe there is a cost savings in combining development, test and production in to one happy little world.  You know, because every developer does everything right the first time. Or at least combining development and test, because, really, those are one in the same.  I actually had a PM tell me this in the last week.  As my father used to say, “That boy is about as sharp as a sack of wet mice.”  I’ll simply add, “Bless his heart”.  Because thinking it can be all in one is the coding equivalent of “Hold my Beer”.

For the uninitiated, the development area is the place where the developers can make multiple horrendous mistakes, or develop, take you choice of phrasing.  The test area is a place where you actually make sure that whatever you have developed installs as it should and that everything should be working as it is designed to.  Production is that area that everyone actually uses and they don’t take kindly to things changing or not working as designed in the middle of an actual transaction.  If you think they do, then I’ll give them your number and you can be a customer service rep as well.  Have fun.  Some groups also include a fourth level – User acceptance testing, or UAT.  This is an environment that your test group of actual business users beat on to make sure everything works to their standards after QA, but before production. I personally fond of the four-tier layout, because It brings the business in on the final product, and anything found afterwards in on their heads, not the development team’s.

Now in this multilayer fiesta there are some points that as operations, I demand.  First, all environments  should resemble production in the fact that the server structure is the same, and you have the same basic software running in the background, because there are indeed differences between, say, .NET 3.5 and .NET 4.5.  Really, there are.  That’s why they are different numbers.  Someone at Microsoft didn’t just decide to change it because they were bored.  If your production server is running .NET 3.5, then why are you developing on something else? Do not talk to me about upgrading on the fly because of backward compatibility.  Sorry, it is something that may work 90 percent of the time, but that remaining ten percent always bites you in the ass.  Replication applies to your databases as well.  Table structures need to be the same.  Change one thing, it needs to go through the whole set and it needs to be tested.  Yes, it is a pain in the neck.  Yes, it takes time.  Why all these restrictions?  Because you are not a cowboy.  You are in IT.  You want freedom, move to Montana and raise dental floss.  But do not ask me to hold your beer.