support

AbuseIO – Open Source abuse management

AbuseIO is an Open Source software for management of abuse reports. It’s like a specialized ticketing/support system, which can automatically parse a variety of abuse notifications, file them, notify the team, and provide the tools to respond and close the incident. In a nutshell:

100% Free & Open Source

Works with IPv4 and IPv6 addresses

Automatically parse events into abuse tickets and add a classification

Integrate with existing IPAM systems

Set automatic (re)notifications per case or customer with configurable intervals

Allow abuse desks and end users to reply, close or add notes to cases

Link end users to a self help portal in case they need help to resolve the issue

If that sounds interesting, have a look at the Features page. You might also want to read the blog post covering a last year’s release of AbuseIO version 4.0.

The system is written in PHP, with Laravel framework, so making changes and adding features should be quite easy.

What does Operations do?

SysAdvent runs a blog post about Operations (in IT sense of a word), explaining what the department (hopefully it’s a department and not a single guy who doesn’t remember the meaning of the word “sleep”) does, and how the job complexity silently escalates with time.

An operations team, almost by definition, focuses on the steady-state “run” of whatever that team is responsible for … well, operating. This could be an electrical plant, an HR department, or an IT operations team; anything which needs to function day-in and day-out, reliably and without fuss. Those things the rest of us assume “just work”.

But just because we don’t notice doesn’t mean there isn’t anything happening. Much like an iceberg, where 90% of its mass sits below the waterline, nobody outside the team is aware of what the team actually does in order to make sure everything “just works”.

Anybody who’s been involved in Operations, at some point goes through this bit:

We can see how Oscar’s responsibilities grew over just two years. At first, it was just 6–8 laptops, office wifi, and a third-party office solution. Then it’s a cobbled-together server. Then development environments. Within a year, it’s 20 laptops, two application environments in the cloud, monitoring, alerting, and backups. After another 12 months, it’s a dozen third-party services, 40 laptops, 2 team members, offboarding processes, and monthly security audits.

Over beers one evening, Oscar makes the comment to a teammate that even he didn’t understand just how profoundly the company depended on the operations team; how much impact his work had on everyone else’s ability to do their jobs.

This blog post actually goes well with the one I am planning to write shortly about software features being like babies. Stay tuned.

Support lesson to learn from Amazon AWS

I’ve said a million times how happy I am with Amazon AWS. Today I also want to share a positive lesson to learn from their technical support. It’s the second time I’ve contacted them over the last year and a half, and it’s the second time I am amazed at how good well it works.

In my experience, technical support departments usually rely on one primary communication channel – be that a telephone, an email, a ticketing system, or a live chat. The other channels are often just routed or converted into the main one, or, even, completely ignored. But each one of those has it’s benefits and side effects.

Telephone provides the most immediate connectivity, and a much valued option of the human interaction. But the communication is verbal, often without the paper trail. It makes it difficult to carbon copy (CC) people on the conversation or review exactly what has been said. It is also very free form, unstructured.

Live chat is also free form and unstructured, but it’s written, so transcripts are easily available. It also helps with the carbon copy, but only on the receiving end – supervisors or field experts can often be included in the conversation, but adding somebody from the requesting side is rarely supported.

Email makes it easy to carbon copy people on both ends. It provides the paper trail, but often lacks the immediate response factor. And it’s still unstructured, making it difficult to figure out what was requested, what has been discussed and whether or not there was any resolution. (Have you ever been a part of a lengthy multi-lingual conversation about, what turned out to be, multiple issues in the same thread?)

Ticketing/support systems help to structure the conversation and make it follow a certain workflow. But they often lack humanity and, much like emails, the immediate response.

Now, what Amazon AWS support has done is a beautiful combination of a ticketing system and a phone. You start off with the ticketing system – login, create a new support case, providing all the necessary information, and optionally CC other people from a single short form. The moment you submit it, the web page asks for your phone number. Once entered, a phone call is placed immediately by the system, connecting you to the support engineer. The engineer confirms a few case details and lets you know that the case is in progress and expected resolution time (I was asking to raise the limit of the Elastic IP addresses on the Virtual Private Cloud, and I was told it will be done in the next 15 to 30 minute. And it was done in 10!). I have also received two emails – one confirming the opening of the case, with all the requested details, and another one notifying me that the work has been done, providing quick information on how to follow up, in case I needed to.

Overall experience was very smooth, fast, to the point, and very effective. I never got lost. I never had to figure anything out. And my problem was attended to and resolved immediately.

I only wish more companies provided this level of support. I’ll sure try too – but it’s a bar set high.

Microsoft support – a myth or reality?

gapingvoid, a blog well known for cartoons drawn on the back of business cards, has this post about monetizing on open source software – a very old discussion, as we know it. In that post, one IT guy is quoted saying:

“If something goes wrong with Microsoft, I can phone Microsoft up and have it fixed. With Open Source, I have to rely on the community.”

What’s your first thought after reading that? Mine was “Have you ever even called Microsoft support?“. It seems that a lot of people believe in this notion of Microsoft support magically fixing whatever problem they might have with any of the Microsoft product.

The question really is – will they? Myself I never had any experience with Microsoft support, but I know quite a few people who did. Most of them seem to agree that Microsoft support is pretty much like any other technical support service of any other company. Meaning that to get anything good out of it, you have to know how to get through to knowledgeable people and you have to know how to convince them to spend some time with your case. Otherwise, you’ll get into an endless loop of answering machines, checklist questions, and advices like “Please, reboot your computer and call us back“.

I have to say that that makes sense to me. Microsoft is the biggest desktop software vendor. Desktop computer users tend to be the most uninformed and untrained category of users (no offense intended). If even half of them believe in magic of Microsoft support, imagine what Microsoft has to go through to keep their support costs reasonable. If you have a serious problem, you’d probably need to get through all that protection and prove that you know what you are doing and that your case deserves attention. Getting through requires knowledge, experience and patience. How many people of those who believe in Microsoft support actually have the knowledge, experience and patience to get through? I don’t think many do. Am I wrong?
P.S.: By the way, there is an interesting discussion in the comments to that original post.