How I Cut Time To Solve User's Problems From Hours To Minutes

Disclaimer: this article of mine only serve as historical purpose only. I don't recommend going through the same process at this year considering this is not the best method to do so (it is pretty outdated). Please just take anything good and leave the bad behind.

Continuing the last post, So here I am at 2016, freshly graduated, newly employed IT employee getting a task from HR to search any trouble-related things in my team and creating a project to solve it.

 

Finding the problem

At first month, I came into a conclusion that our team was a kinda messy IT team -- there's no clear limit on what we did. So my senior at 1PM was tweaking the database or reinstalling servers, then helping users reinstall their Thunderbird at 2PM.

But hey, that's fine. The HR already told me before hand, and I think this might be a big opportunity to learn a lot.

We have a monthly meeting where we will discuss anything IT related with our manager, and of course we told our report about what we did last month. The report consisted many things, and one of them was the time needed to help our user (or, being IT helpdesk).

The time was kinda big, around hours every ticket. After collecting a lot of data of the tickets, finally I arrived at the conclusion that we spent a lot of time mainly only to go to the user's location.

Should I build a rocket to make the trip faster?
 

It makes sense, because the company was huge and pretty much like a labyrinth. What made me go crazy was that we might be only spend some seconds on the user's desk; just a few clicks and few typing and it's done.

For real example, a user called me asked is there anything wrong with our webpage because he couldn't type anything on it. I went to his place (took around 5-10 minutes on foot), just to plug his unplugged keyboard.

This can't be real. A solution really should be done.

 

Remote Desktop to the rescue

My senior told me that back then there was a project about remote desktop to make our life being IT helpdesk easier. I haven't heard anything about this tech back there, so it felt magical to me. Then I googled a lot, and with the help of my mentor, finally I created a new way to solve this problem.

This is the oversimplified version


After a lot of studying about bash-scripting (yes, our workplace mainly use linux) to automate things, finally there's no need to go to our user's place anymore (IF it can be solved remotely). User's problem solved faster, the team can use their time to solve other problems -- Huge win-win!


The technical things

So I used:


 Basically, there's a desktop shortcut at user's desktop for user to click when they need some help.

The desktop shortcut was linked to execute my bash script, calling Kdialog (yes, our workplace used KDE) to display a 'Connect' button and 'Disconnect' button.

When the user clicked the Connect button, the script generated a random password, inserted it to the fwknop configuration, started the fwknopd and SSHD service, and send the fwknop password to our IT team.

This way, only those that have the password can connect via SSH to the user's computer. For the graphics, X2Go server was also installed at the user's PC -- therefore we could remote it using X2Go via SSH Protocol.

 

Why?

There should be many why-s about my flow.

First of all, why was it like that?
Well, I was inexperienced, so it was messy. I was hunted by deadlines and the shortage of my knowledge back then was not a joke. I knew literally nothing about IT, so my project might sound lame.

Second, why I used X2Go?
At that time I only knew X2Go, I didn't knew other software like Teamviewer, Anydesk, Nomachine, VNC, etc etc. So I picked it up.

Third, why I used (the old) fwknop?
Like what I wrote, I picked an old project by my mentor. The old project also used fwknop. The fwknop was essential because it's a way to make sure that only those selected people can remote the user.

Last, why SSH?
No particular reason though, at that moment I only knew that to connect to other computer, SSH was the only answer. And yes, it didn't work on some user that used Windows PC.

 

Is it successful?

Well, it works! Even though maybe some months later there're some complications like updated OS, broken dependency, etc.

Actually the project was kinda not suited to my jobdesk (actually handed by other co-worker specialized in user's workstation), so after some time they took it, but couldn't keep up with updating it.

But the HR main goal wasn't about the technical, it's about how I see a problem and solve it. Considering it was pretty okay, so I passed the exam.

What about today?

Years have passed, I have more knowledge now. But I haven't think about it again (busy with work) until I make this article.

I think maybe at some point in the future I will renew the way this works. Of course with more refined way. I have some ideas, but it's always better to do a lot of planning and research beforehand. A lot.

Consider me excited for the next project!