Tag Archives: blogelul

Day 04 – Understand More

Last year I discussed how some areas of technology were in (and others were out) of the range of our understanding – depending on what area of focus we have ourselves.
And the guys from Gesher Academy ROCK!
I still think those things are true. We need to be willing to understand, and simply prioritize based on the available time and importance.
However, a blog I read recently reminded me of an important aspect – we also need to know why.
In an essay titled, simply enough, “Why”, Derek Sivers points out that you need to understand WHY you are doing what you are doing. And the answer is not a panacea. By asking and answering “why”, certain aspects of life will become more important, and others less so.
If your goal is to be famous, then you may have to make sacrifices to family life or even money. If your goal is job stability, then career growth may take a back seat.
This is the ultimate form of understanding. It is the meta-understanding. Once you nail down the fundamental reason for your choices, you can make them faster and with more confidence that they will ultimately get you where you want to go.
Derek summarizes by saying:
“That’s why you need know why you’re doing what you’re doing. Know it in advance. Use it as your compass and optimize your life around it. Let the other goals be secondary. So when those decision moments come, you can choose the value that you already know matters most to you.”
Shakespear famously wrote “To thine own self be true”. But this is impossible unless you first take time, as Siver suggests, to really understand what you want.

Day 3 – Search

As IT pro’s, we find ourselves searching for many things. We search for solutions. We search for truth (both regular and capital-T truth). Most of those things we either have a good chance of locating, as long as we’re persistent and intelligent about it.
But one of the searches that many (if not all) IT pro’s undertake is the search for the right fit in their job.
Forums, job boards, and advice columns – not to mention innumerable after-work-over-beer discussions – are filled with tales of horrific bosses, harrowing workplaces, and hideous jobs.
If there were easy answers, they’d be out there already. After 30 years, the only wisdom I can give is this: it’s the same as any other problem. You have to be persistent. You have to be smart. You have to be willing to abandon your pre-conceived notions and start over – again and again if necessary. You have to accept that the solution which worked for another person in another place may not be your solution.
And sometimes the search has to be given up for now, with the trust that you’ll take it up again another day when you are fresh and ready to try again.

#BlogElul 02-Act

An excerpt from an essay I wrote for an upcoming issue of “Data Center Journal” was especially relevant to today’s post. The essay is titled “Data, Information, Action”:
The saying, “you can have data without information, but you cannot have information without data,” may never have been so blindingly obvious or true as it is today. We are awash in seas of data, fed by thundering, swollen tributaries like the Internet of Things, mobile computing and social media. The goal of the so-called “big data” movement is to channel those raging rivers into meaningful insight.
For almost 20 years, my specialty within the field of IT has been systems monitoring and management. Those who share my passion for finding ever newer and more creative ways to determine when, how, and if a server went bump in the night understand that data versus information is not really a dichotomy. It’s a triad.
Of course good monitoring starts with data. Lots of it, collected regularly from a variety of devices, applications and sources across the data center. And of course transforming that data into meaningful information—charts, graphs, tables and even speedometers—that represent the current status and health of critical services is the work of the work.
But unless that information leads to action, it’s all for naught. And that, patient reader, is what this article is about—the importance of taking that extra step to turn data-driven insight into actionable behavior. What is surprising to me is how often this point is overlooked. Let me explain:
Let’s say you diligently set up your monitoring to collect hard drive data for all of your critical servers. You’re not only collecting disk size and space used, but you also pull statistics on IOPS, read errors and write errors.
That’s Data.
Now, let’s say your sophisticated and robust monitoring technology goes the extra mile, not only converting those metrics to pretty charts and graphs, but also analyzing historical data to establish baselines so that your alerts don’t just trigger when, for example, disk usage is over 90 percent, but rather, for example, when disk usage jumps 50 percent over normal for a certain time period.
That’s Information.
Now, let’s say you roll that monitoring out to all 5,000 of your critical servers and begin to “enjoy” about 375 “disk full” tickets per month.
That, sadly, is the normal state of affairs at most companies. It’s the point where, as a monitoring engineer (or, at the very least, the person in charge of the server monitoring), you begin to notice the dark looks and poorly hidden sneers from colleagues who have had “your” monitoring wake them one too many times at 2 a.m.
So, what’s missing? The answer is found in a simple question: Now what? As in, once you and the server team have hashed out the details of the disk full alert, the next thing you should do is ask, “What should we do now? What’s out next step?” In this case, it would likely involve clearing the temp directory to see if that resolves the issue.
And the next logical step from there is automation. Often, the same monitoring platform that kicks up a fuss about a server being down at 2 .m. can clear that nasty old temp directory for you. Right then and there, all while you’re still sound asleep. Then, if and only if, the problem persists, will a ticket be cut so a human can get involved. And said human will know that before their precious beauty sleep was so rudely interrupted, the temp directory had already been cleared, so it’s something just a bit more sophisticated than that.
This type of automated action is neither difficult to understand nor super complicated to establish. But in the environments where I’ve personally implemented it, the result was a whopping 70 percent reduction in disk full tickets.

#BlogElul 01-Prepare

(This post is a day late. I guess you could say I wasn’t prepared to post it during the long holiday weekend. ON the other hand, posting it then would have caught people ill-prepared to carve out the time necessary to read it.)
Preparation implies forethought, knowledge, information, capability, and (as I mentioned last year) choice (https://www.adatosystems.com/2015/08/16/blogelul-day-1-prepare/).
Prepare is wonderful. Prepare is beautiful. In the world of IT, preparation is the work we hope we get to do every day. It is the hope we have as we drive to work.
The idea of “prepare” has an ugly underbelly though.
To borrow a concept from “Stranger Things” (https://en.wikipedia.org/wiki/Stranger_Things_(TV_series)), the “UpsideDowns” of preparation, where everything that we know and find familiar is a dark, twisted, and toxic mirror image, is “reaction”.
And THAT is a term that IT pro’s know all too well. Managers will chide us that “we’re being too reactive”. As if ignoring the system outage, network spike, or looming disk capacity issue is going to make it go away, or teach it a lesson that it needs to wait its turn.
“Let it wait” is the phrase non-IT people say without realizing it translates to “Do what *I* want now and I don’t care if the event punishes you doubly-hard later.”
So how do you avoid the demogorgon of the UpsideDown of IT?
Partly, by doing what the kids in the NetFlix show did – huddle up your posse of friends, identify the enemy for what it is, be relentless in saving each others’ butt, and rising to the challenge no matter how tired or drained you feel.
But that’s only part of the answer. The other answer is “I don’t know”. After almost 30 years in IT, I still find myself running full-tilt through horrific architecture landscapes not of my choosing, trying to evade the ravenous monster that gamely pursues me.
If there are better answers, I’m open to them. As are the comments below.


#BlogElul: ZeroDay

tl;dr version

A daily blog-athon running from now until Oct 3rd, with hundreds of people writing a daily post on a specific theme. You are invited to participate. I am.
Source Code
Coming up soon (the evening of Oct 2nd, to be exact) is Rosh Hashana, the Jewish New Year.
As I mentioned last year (https://www.adatosystems.com/2015/08/16/zeroday-introducing-blogelul/), between now and then is a time to reflect on how the past year went so that you can commit to making adjustments in attitude and behavior so that we continue to improve as people.
To help with that, a bunch of folks from all walks of life participate in #BlogElul: A daily writing exercise that could be a single sentence, a haiku, or an 800 word essay. Each day a single word is provided as the theme, and people take it from there.
If you missed this series last year, you’re probably thinking “Leon, this is a Jewish thing and completely outside the scope of my experience.” Yes and no.
If you have worked in IT for more than 15 minutes, you’ve probably been involved in a large development project, system rollout, or upgrade. And as the date for the big cutover approaches, there are usually daily status updates. I’m taking this opportunity to set up a standing meeting and report on my progress toward the upcoming release called “MyLife, 5777”
If you are interested in joining in you can find more information on the blog of Rabbi Phyllis Sommer, the woman who started it: http://imabima.blogspot.com/2016/08/blogelul-and-elulgram-2016.html
If you have suggestions on what I should include for any of the days, let me know!
Meanwhile, here is the word list I’ll be following:
Elul 1 (Sept. 4): Prepare
Elul 2: Act
Elul 3: Search
Elul 4: Understand
Elul 5: Accept
Elul 6: Believe
Elul 7: Choose
Elul 8: Hear
Elul 9: Observe
Elul 10: Count
Elul 11: Trust
Elul 12: Forgive
Elul 13: Remember
Elul 14: Learn
Elul 15: Change
Elul 16: Pray
Elul 17: Awaken
Elul 18: Ask
Elul 19: Judge
Elul 20: Fulfill
Elul 21: Love
Elul 22: End
Elul 23: Begin
Elul 24: Hope
Elul 25: Intend
Elul 26: Create
Elul 27: Bless
Elul 28: Give
Elul 29: Return

#BlogElul Day 29: Return

RETURN is one of the most basic of all constructs in IT. Whether you are a programmer, sysadmin, network engineer, Virtualization architect, or something else, there is an almost 100% likelihood that you have needed to find out the RETURN code from one of your systems at some time in the past.

For that reason, I love that this is the last prompt for this series. It’s a way of saying “We’re all done here. Run garbage collection, write to the log files, and close this puppy down.”

It’s been a great run – by far my most successful participation in #BlogElul. Not only did I complete each and every one of the prompts this year, I did it twice – once on this blog and once on EdibleTorah.com.

For those who are long on time and short on inspiration, here’s a review of each of the essays.

Thank you for coming along on this journey with me.


// Every good programmer leaves an easter egg or two
// Here’s where I would like to thank a few people:
// First, I am blessed beyond measure to have had the chance to marry my best friend.
// without her, I would be lost adrift in the sea of madness and chaos.
// Second, thank you to Phyllis Sommer (aka “Ima on (and off) the Bima”) for kicking this // event off year after year and generating both writing prompts AND enthusiasm
// Third, to Rabbi Raphael Davidovich. This was his first year participating in #BlogElul, and
// I tried not to ape his thoughts too much. or without attribution. But like a good partner
// at the gym or a good chevruta (sorry, CHEVRUSA) at yeshiva, his work pushed me to do
// my best as well even when I might have been more lenient with myself.

#BlogElul Day 28: Give

If you work in IT, there are a few things which I know are true about your job even if I’ve never met you:

  • You are busy. You have enough work for you, your clone, and your clone’s cousin. Same goes for your coworkers (and their clones and cousins).
  • You know things. Maybe a lot of things. If you have worked in IT for more than a month, you have a few tricks up your sleeve that other people who “know computers” will never have heard of.
  • You hold the things which are known – by you, your coworkers, their clones, and cousins – in very high regard. The things you know are what make you valuable as an IT professional.

Knowing all of that, I understand how what I’m about to say may shock you:

Give. It. Away. All of it.

Despite being busy. Despite the fact that the person you are going to give away all your hard-won knowledge may not have “put in their time” or “earned their stripes”. Despite the fact that if TWO of you know the tricks, there’s a chance that you may not be as valuable. Despite all of that.

Because I know something else: You are wrong.

You are not too busy to give your knowledge – to write or podcast or vlog or just sit someone down and TELL them (ewwww! How ANALOG!). You are not too busy for that.

Because in sharing what you have, you will gain. In spreading what you know, you will never lose. In giving away for free the things which cost you in the precious coin of time and sweat and tears you increase rather than decrease the value of it.

In fact, giving may be the greatest gift you ever receive.

#BlogElul Day 27: Bless

As I’ve been writing each day this month, I’ve come back repeatedly to the idea that – if you choose a career in IT – it is important to find a niche (both in terms of the company where you work, the company you keep, and the work you do) that you love.

I realize this is far easier said than done. But just because it’s difficult doesn’t mean the effort is not worth it.

That would have been hard for me to prove until recently. I’ve been blessed this past year to have found a place as Head Geek at SolarWinds. It’s a job that engages so many facets of my experience – from my theatrical training in college to my love of writing to my years as an IT generalist, and of course my passion for monitoring. But it’s also a job that allows for the facets of my life which are not work related but equally important to me – my religious convictions, my family, and even the city where I’ve chosen to put down roots.

So I’m not going to drag this out. I have found my blessing in this work that I’m doing.

I hope in the coming year, you do, too.

#BlogElul Day 26: Create

A couple of months ago, SolarWinds held their 4th ThwackCamp – a completely free, completely online conference. In the keynote, Head Geek Patrick Hubbard spoke to an interesting dichotomy in the life of an IT Professional.

“(In IT) we’re always fixing things. […] but fixing just eventually wears us down. So stop fixing things, and start to solve things.”

More than just semantics, Patrick highlighted both a mindset and an action plan. Fixing things is merely the act of making the problem go away. Maybe permanently, but that’s not part of the job. It’s just to make the pain/alarm/complaining stop.

Solving things goes deeper. It speaks to the root of the problem and to a willingness to address both the symptoms and the core cause of the issue. Solving means changing architectural or organizational issues. Solving means building a better system based on everything we’re learned from the old one. Solving means playing a long game.

If you are sitting in the hot sun, fixing the problem means dumping some water over your head. Solving the problem means planing a tree for shade.

Over the last month, many of my daily thoughts have spoken to action. What do we intend, plan, hope, or pray to do. What do we believe? How will we start (or end)?

Today I want to suggest that DO-ing is the same as FIX-ing. It’s a good start, but it’s not the whole story.

Beyond asking ourselves what we’re going to DO, we should think deeply and seriously about what we are going to CREATE.

The question is not about having the ability, or intention, or permission to create. You already have those. The question is what you are creating right now, what you will create tomorrow.

So as we look ahead to the coming year, don’t settle for just fixing things. Look at ways you can start SOLVING them. And don’t just get caught up in what you are going to DO.

Decide what you are going to CREATE.

#BlogElul Day 25: Intend

There is a popular saying about the road to hell. It may equally apply to the road that leads to a system outage.

  • If we intended to back up our servers, but never requested the SAN storage…
  • If we intended to patch the application, but never cleared time for the change control
  • If we intended to upgrade the network, but never included it in the budget
  • If we intended to get that certification, but never scheduled the class (or exam)

It’s fair to say that when something goes wrong in IT, it is rarely because that was the intent of the people responsible.

So why do we let things like that happen? After more than a half-century of modern IT operations, you would think most of this would be utterly and unquestionably standardized.

Part of this is that things appear to change (something I’ve written about elsewhere) and therefore we fool ourselves that the methods that provide stability somehow don’t apply any more.

But part of it is that we intend to do it, but allow other things to get in our way. From the manic (“we have to inventory and integrate 3 new acquisitions this quarter”) to the mundane (“someone said something factually incorrect on Facebook!”) there are plenty of compelling reasons to postpone that change control request or certification exam.

At least, until it’s setting off alarms. Then we realize our intentions were just more fuel for the fire.