SysAdmin, You Need a Hobby

Yesterday I posted about hitting 10 years in IT. I see a lot of posts around the internet about people in IT burning out. Having a hobby that isn’t related to your job is a crucial aid in staving off burnout!

7 years ago I was a sysadmin for a small credit union. My manager frequently scheduled last minute late night work for me, would berate teammates in meetings, was churlish and dishonest, and just not a good manager.

I realized one day that I needed some sort of healthy outlet for the frustrations from work. So I got into woodworking. I didn’t have many tools, but I built a dining room table out of construction grade lumber with a circular saw, a miter saw, and a cheapo Harbor Freight sander. It wasn’t that well built, but it was a start. And you know what? As I cut the wood, put it together, sanded it, and stained it, I felt the frustration of work melt away.

So I kept making things. And I got better. Below are some things I’ve made recently: a new maple dining table made with mortise and tenon joinery and a desk I made out of cherry (with process pics).

After I bought the maple, I let it sit in my garage for a few weeks to acclimate, then I cut the boards to rough length.
Playing around with layouts.
Rough cut planks glued up into preliminary panels
Glue ups.
After I glued the panels together, I used a router sled to flatten the tabletop.
Man glitter.
Chopping out the mortises for the breadboard ends.
Attaching and pinning the breadboard ends.
Getting threaded inserts ready.
Installing inserts
Finished product!
Some cherry lumber.
Rough cut cherry.
Glue ups
More glue ups and planing of panels.
Threaded inserts
I added this medallion to the underside of the desk
Completed desk.

I also picked up gardening in 2020 (Hey, it seemed like civilization might collapse, so I thought it would be prudent to learn to grow stuff). I also enjoy hiking. Sometime I’ll share pictures from hiking too.

Find a hobby guys and gals!

10 Years in IT

A cool anniversary just passed yesterday.

10 years and 4 months ago I was managing a store in South St. Louis for the pink cellular carrier, and I saw my wages getting cut over and over due to bad tactics by the company. I mentioned this to a friend I was planting a church with, and he told me he worked in IT and extolled the wonders of working with computers. He encouraged me to get into the field of Information Technology. To sweeten the encouragement, he even offered to reimburse me for the costs of obtaining Security+, if I passed it on my first try.

Since I like challenges, and since it’s very less than ideal to see your income declining from barely making ends meet to not making them eat when you have a wife and baby at home, I bought a study guide and hit the books for a few weeks. Then I took the exam and passed it. My friend was good on his word and he reimbursed me.

Another friend informed me that his company was hiring for help desk technicians. He gave me the direct line of the recruiter. I called that guy every day for 3 weeks and left a voicemail repeating my desire for the job.

I got a call from the recruiter after a few weeks and he apologized for not calling sooner; he had been on vacation! Whoops! He liked my eagerness, and he scheduled me for an interview.

Thankfully I did well and got the job.

Since then I’ve done help desk, application support, and sysadmin stuff. It’s been a good ride so far!

I’m not a graybeard yet. Wait, I do have a little gray in my beard, I guess.

10 years later, though I don’t interact with end users very much anymore , and though I work a lot with vSphere, other hypervisors such as QEMU and Hyper-V, networking, storage, I still reach into the back pocket for that old troubleshooting tool every now and then:

“Have you tried turning it off and on again?”

Where in the World is vWebster?!

It has been a while since I’ve published a blog post here.

I’m still alive though. I am still doing technical things, and I still design, implement, and maintain technical solutions that use VMware products. However, my day to day is much more of a generalist in my role.

So, I’ve used the time (and employer benefits) to begin pursuing an MBA. I’m about 2/3 of the way through that now. I also snagged a CCNA and have been working towards getting a CCNP. I will probably wait to try the ENCOR again, and the ENARSI exams until I’m done with the degree.

In the meantime, I will be tinkering with my home lab, maybe posting some more blog posts, wrapping up grad school, and traveling for work.

Seen below, my home lab (the networking part of it anyway) and the current topology. I’ve got some ESXi hosts also that aren’t pictured.

VCAP-DCV Design Attempt #2

About a year and a half ago, I sat the VCAP-DCV Design  6.5 exam. I failed it on my first try. I needed a 300 to pass and I scored a 284. So, it would seem, I likely missed passing by one or two questions.

The VCAP Design is well known as a difficult exam that takes many people more than one try to pass. I wanted to retake it, but at that time I was too broke to pay for a second exam, and I got buried in work.

I started a new job last August doing a mix of design and implementation work, and back in March of this year, I got Covid-19. Now, I didn’t get that sick, but I was forced to self-isolate for a couple of weeks. Once I was feeling better enough, I started studying again for the VCAP-DCV 6.5 Design exam.

After I was out of self-isolation, my company adopted a policy allowing telecommuting, so I was able to spend more time in the evenings studying, and in April I was thrilled to see that Pearson-Vue was offering proctored VMware exams online. I registered for the exam and continued preparing.

This morning I sat the exam, and aside from some minor technical difficulties on getting signed in (of course the home internet dropped briefly about 15 minutes before the scheduled exam!), I was out of the gates.

It took me about an hour to navigate through the questions. I didn’t really feel like there were any gotcha questions, and I felt very confident once I’d reviewed the marked questions. I clicked Finish, and immediately saw that I had passed. I may have startled the proctor with my triumphant shout…

I scored a 332. It’ll do.

To prepare for the exam I used the following resources

I suppose this makes me a VCIX-DCV 6.5. I’ll post the badge when I get it.

What’s next? I’ve committed to my employer to become more network savvy this year. So, you’ll probably see more design posts and some network oriented posts too.

 

Principles of Good Design – Putting it All Together

So, now that we have defined Requirements, Constraints, Assumptions, and Risks (RCARs), I want to provide some helpful tips around putting those together in a design.

  • Derive all requirements from the customer’s stated requirements. Some of these will require little translation into technical requirements. Most will require you to ask additional questions. For instance, their requirement might be stated as, “We need high availability.” You then need to clarify what high availability is. Is it 3 9s of uptime? 5 9s? Quick and automated failover?
  • Ask all relevant stakeholders to weigh in on Requirements and Constraints.
  • Think through every assumption.
  • Think through all of the possible risks. Then think through ways to mitigate those risks.
  • Validate all assumptions!
  • Organize RCARs into a logical format with tables. Give each item a relevant tag, such as R-001.002 for a requirement, or RK-01 for a risk.
  • Your whole design flows from RCARs. Word them and organize them in such a way as to make them easy to refer back to.

Principles of Good Design – Risks

It has been a crazy few weeks since I last wrote! But you know, roll with the punches!

The last basic category of design elements I wrote about was Assumptions. In this post, I’m going to introduce Risk.

A Risk is any uncertain thing that could negatively impact the completion of a project, or its functionality. It is your job as the designer to think through every possible risk.

For instance, going back to my bathroom example, a risk in the design was that I’d have to replace more of the subfloor than I anticipated, which would have increased costs as more plywood would have needed to be bought.

An example of a risk in IT is

It is possible that there will be a shortage of the necessary DDR4 memory at the time the order is placed, which may increase price and lengthen delivery time.

The goal here, in designing a solution is to recognize the Risks, determine their impact, and think through a way of mitigating them.

The example above, regarding DDR4 memory, would have the impact of increasing the price of the solution (supply drives price, sometimes), and would lengthen the delivery time. This risk, would then create additional risks if it’s not mitigated. A lengthened delivery time might, if the memory in the risk is being used in a new server to replace an old one, cause the old server to lose support leaving a window of usage where there is no OEM support. Or, if the memory is being added to an existing server because of environmental growth, it could constrain growth or cause unacceptable performance impacts.

So, recognizing that, this risk, like all risks, must be mitigated.

What are some ways we could do that? Well, we could consider buying our additional memory through a different VAR, who may have that memory in stock in a warehouse. Maybe, we consider buying the additional memory from a different OEM (make sure the alternate OEM is supported by the server OEM, or you have just introduced another risk!).

Every project has risks, and not all risks can be mitigated completely. But, all risks can be at least partially mitigated.

Another word on assumptions; if you do not validate your assumptions, they become risks.

Principles of Good Design – Assumptions

When talking about requirements and constraints, there are always factors that haven’t yet been quantified or proven. These are called Assumptions.

Going back to the bathroom renovation, an assumption I had approaching that project was,

The subfloor under the toilet will need to be replaced as it has partially rotted.

I knew the toilet would rock back and forth if you leaned too far to one side, and this seemed to be a reasonable assumption.

An assumption you may have with an IT project is,

There is sufficient bandwidth, compute power, and storage to replicate data to a second site.

Once you have identified the assumptions over the project, and the assumptions you bring to the project, you must then quantify whether those are valid or not. If you don’t prove out your assumptions and validate them, they become risks.

In the bathroom instance, I validated the presence of a rotten subfloor by going into my basement, and shining a light up to the underside of the floor and observing evidence of rot. In the IT instance above, you would probably consider how much data is being replicated to the “second site,” how much that data changes every day (deltas), and what the compute requirements are. Once you have that in mind, you can then calculate what sort of bandwidth is needed using an online calculator.

Now, let’s say you don’t validate those assumptions.

When I replaced my bathroom floor, had I not validated that the subfloor only needed to be replaced under the toilet, I may have spent extra money buying subfloor panels I didn’t need.

In the design example, your client will be very angry if you design a solution for them and they discover they need to order a lot of extra bandwidth to replicate your solution to their second site!

Always validate your assumptions.

You know what happens when you assume…

Principles of Good Design – Constraints

In the last post, we reviewed Requirements. We said that requirements are specific things required in the solution, or what the solution must be able to do.

The solution must enable the organization to recover its own data with minimal loss in the event of hardware or logical failure

Constraints are sometimes called nonfunctional requirements. They limit choices in the design; they constrain our options. Whereas requirements (aka Functional Requirements) tell us what the solution must be able to do, constraints usually tell us how the solution should do it.

In my previous example of replacing my bathroom floor last November, a constraint on the design of the floor could be, “The new floor must make use of gray tile.” See? That constraint instantly rules out brown, or white, or black tile.

In the IT Design world, an example of a constraint might be,

The solution will use Fibre Channel as the storage networking protocol

See? With that constraint, other storage connectivity options like iSCSI have just been ruled out.

The requirements and constraints allow us to begin building a design. They act as guard-rails in a way, as the final design must adhere to the requirements and constraints.

Next up, we will look as Assumptions and Risks!

Principles of Good Design – Requirements

Anytime you approach a project from the design phase, you need to gather the requirements. Anytime a project is handed to you by a Project Manager or a consultant, you need to refer to the requirements.

Most simply, requirements are specific things required in the solution. More specifically, requirements are what a solution must do.

I replaced my bathroom floor about 8 months ago. An example of a requirement for that project is, “The new floor must provide a water-resistant surface over the subfloor.” Another example might be, “The new floor must be easy to clean.”

Some IT examples might include,

The solution must enable the organization to recover its own data with minimal loss in the event of hardware or logical failure.

It is important to identify requirements before moving on to any other phase of design. The requirements are the guiding principles upon which the whole design relies.

Requirements will usually align with the design factors; Availability, Manageability, Performance, Recoverability, Security, and Cost.

Who do you get the requirements from? Normally the stakeholders in the project. That might be the CTO overseeing the initiative, the CIO, the IT Manager, the Systems Engineers, the Software Engineers, etc. You may need to translate requirements as mentioned into business language.

Requirements usually don’t mention specific technologies or technical solutions.

Next time we will talk about Constraints!

Principles of Good Design

I am going to start a new series on this blog to outline what constitutes Good Systems Design, and give some examples I’ve seen or even built myself (in the old days) of Bad Systems Design.

In this series, I’ll cover the following areas:

  1. Requirements, Constraints, Assumptions, and Risk – What are they? Why do they matter?
  2. AMPRS (Availability, Manageability, Performance, Recoverability, and Security) – the Big Design Qualities. I’ll also mention Cost, as that is often a design quality as well.
  3. Conceptual vs Logical vs Physical Design
  4. Real World Examples!

 

Stay tuned!