From Russia with love?

As part of my return to blogging I decided to play with Google Analytics since the web people at work use it, and I figured as a sysadmin it’d be useful to have some experience with it.

Most of the visitors to this blog are from Russia. It’s most likely bots and other nastiness since I really don’t think that is my audience.

Adding more content and getting more viewers probably will change this.

Pride in your work

I’ve had to clean up pretty significant messes left by previous sysadmins several times over the years. It’s always really frustrating because you wonder how someone who has any respect for their job could leave something like that in place.

It’s not just the IT world though.

Since buying our condo about a year ago, we’ve never been able to get the air conditioning cold enough. After being told by one HVAC tech that “this is just how it is” and I decided to get another company out.

This guy took a lot more pride in his work and did far more extensive troubleshooting, and decided he had to cut into the sheet metal over the evaporator coils.

When he had it opened up, he was immediately pissed off at whoever had installed this HVAC setup back in 2003. He was clearly annoyed that someone who had the same job as him would do something this stupid. It showed total disrespect for the profession. Whoever had installed it managed to build the ductwork so that about half of the air flowing through it never even passed over the coils.

The HVAC tech managed to fabricate some pieces of sheet metal to force the air to flow through the coils, and it made a huge difference now that all of the air gets properly chilled.

I immediately had sympathy for the HVAC tech’s feelings. Not only do I wonder about the person who originally built this, but wonder how the previous owners could have put up with this.

My goal is to avoid leaving nasty surprises for future IT pros.

Don’t be afraid to share what you’re working on

I follow quite a few sysadmin blogs, and a lot of people are working on some really cool cutting edge stuff. It is easy to then think what you’re doing isn’t even worth writing about.

We are all trying to make incremental progress. In my present role we’ve made some incredible progress over the past couple of years moving to an incredibly stable environment.

For instance, our applications were not developed using perfect Agile methods and aren’t containerized with Docker running on top of OpenStack instances, but what we are doing is some of the best my group has ever done, and our customers are satisfied with what we’re providing.

Keeping that in mind, we’re also a lot further ahead than a lot of other people, and as result, I think it is important that we share what we’re doing so we can help others along the way.

Knowing when to let a project die

One of the most fortunate aspects of my current job is that I have quite a bit of autonomy in getting things done. We have the usual projects which take priority that are dictated by program or business needs, or are necessary to update existing systems. There is usually some time to squeeze in additional infrastructure projects that benefit the IT side of the house. I tend to focus on ways to improve monitoring and automation.

Since priorities change constantly, some of these internal projects end up on the back burner. They might be experimental in nature, or not have a clear plan, but they exist in some form and can linger for quite a while.

When I first took my current job, I found myself doing quite a bit of cleanup. We had quite a few virtual machines hanging around that didn’t seem to be doing much.

I asked a number of questions such as:

  • Is there an active project in place making use of this VM?
  • If the version of the software seemed old, would restarting the project require completely rebuilding the environment?
  • If we’d have to rebuild the whole thing, would we be better off killing it and starting from scratch if the project comes up again?

I decided to follow my own advice last week, and killed off two projects. I had been looking at Senusu for system monitoring, but it wasn’t an appropriate fit for our environment. I also had been looking at RunDeck for system orchestration, but the need had mostly passed.

The system resources we freed up by dumping these two projects were relatively minor, but formally killing off both of these test systems let me clear it off my to do list. Nothing is stopping us from revisiting either project in the future, but for now, they’re done.