December Writing Challenge Week 3 Recap
We’re more than halfway through the challenge now, and I’m simply blown away by the quality of the responses. While I’ve excerpted a few for each day, you really need to walk through the comments to get a sense of the breadth and depth. You’ll probably hear me say it every week, but thank you to everyone who has taken time out of their day (or night) to read, reply, and contribute.
14. Event Correlation
Correlating events—from making a cup of coffee to guessing at the contents of a package arriving at the house—is something we as humans do naturally. THWACK MVP Mark Roberts uses those two examples to help explain the idea that, honestly, stymies a lot of us in tech.
Event Correlation is automagical in some systems and manual in others. If you can set it up properly, you can get your system to provide a Root Cause Analysis and find out what the real problem is. Putting all those pieces together to set it up can be difficult in an ever-changing network environment. It is a full-time job in some companies with all the changes that go on. The big problem there is getting the information in a timely manner.
She’s a “box shaker!” So am I.
Flash back 20 years—a box arrives just before Christmas. The wife and I were both box shakers and proceed to spend the next several days, leading up to Christmas, periodically shaking the box and trying to determine the contents. Clues: 1) it’s light 2) it doesn’t seem to move a lot in the box 3) the only noise it makes is a bit of a scratchy sound when shaken.
Finally Christmas arrives and we anxiously open to the package to find a (What was previously very nice) dried flower arrangement—can you imagine what happens to a dried flower arrangement after a week of shaking . . .
I think of event correlation like weather. Some people understand that dark clouds = rain. some people check the radar. Some people have no idea unless the weather channel tells them what the weather will be.
15. Application Programming Interface (API)
There’s nobody I’d trust more to explain the concept of APIs than my fellow Head Geek Patrick Hubbard—and he did not disappoint. Fully embracing the “Thing Explainer” concept—one of the sources of inspiration for the challenge this year—Patrick’s explanation of “Computer-Telling Laws” is a thing of beauty.
I click on an icon
You take what I ask,
Deliver it to
The one performing the task.
When the task is done
And ready for me,
You deliver it back
In a way I can see.
You make my life easier
I can point, click and go,
You’re the unsung hero
and the star of the show.
API to me is a way to talk to a system or an application/software running on it, while we invest a lot of time in building that we should also make sure it’s built with standards and rules/laws in mind. Basically we shouldn’t be investing a lot of time on something that can’t be used.
In many ways an API is a lot like human languages. Each computer/application usually only speaks one language. If you speak in that language, it understands what you want and will do that. If you don’t, it won’t. Just like in the human world, there are translators for computers that know both languages and can translate back and forth between the two so each can understand the other.
16. SNMP
Even though “simple” is part of its name, understanding SNMP can be anything but. THWACK MVP Craig Norborg does a great job of breaking it down to its most essential ideas.
SNMP still is relevant after all these years because the basics are the same on any device with it. Most places don’t have just one vendor in house. They have different companies. SNMP gets out core monitoring data with very little effort. Can you get more from SNMP with more effort? Probably. Can other technologies get you real time data for specialty systems? Yup, there is lots of stuff companies don’t put in SNMP. But that’s OK. Right up there with ping, SNMP is still a fundamental resource.
SNMP: Analogous to a phone banking system (these are still very much a thing btw).
You have a Financial Institution (device)
You call in to an 800# (an oid)
If you know the right path you can get your balance (individual metric)
However when things go wrong, the fraud department will reach out to you (Trap)
Sending notes all of the time
For everything under the sun,
The task is never ending
And the Job is never done.
I can report on every condition
I send and never look back,
My messages are UDP
I don’t wait around for the ACK.
17. Syslog
What does brushing your teeth have to do with an almost 30-year-old messaging protocol? Only a true teacher—in this case the inimitable “RadioTeacher” (THWACK MVP Paul Guido)—could make something so clear and simple.
Like a diary for your computer
A way for your computer/server/application to tell you what it was doing at an exact moment in time. It’s up to you to determine why, but the computer is honest and will tell you what and when.
18. Parent-Child
For almost 20 days, we’ve seen some incredible explanations for complex technical concepts. But for day 18, THWACK MVP Jez Marsh takes advantage of the concept of “Parent-Child” to remind us our technical questions and challenges often extend to the home, but at the end of the day we can’t lose sight of what’s important in that equation.
Thank you, this is great. I think of the parent-Child as one is present with the other. As the child changes the parent becomes more full, and eventually when the time is right the child becomes a parent and the original parent may be no more.
The Parent-Child Relationship is one that nurtures the physical, emotional and social development of the child. It is a unique bond that every child and parent will can enjoy and nurture. ... A child who has a secure relationship with parent learns to regulate emotions under stress and in difficult situations.
I’m a bit further down the road than you, having launched my two kids a few years ago, but I will say that the parent-child relationship doesn’t change even then, although I count them more as peers than children now. I’m about to become a grandparent for the first time, and our new role is helping them down the path of parenthood without meddling too much hopefully. It’s only much later that you realize how little you knew when you started out on the parent journey.
In keeping with the IT world:
This is the relationship much like you and your parent.
You need your parents/guardians in order to bring you up in this world and without them you might be ‘orphaned’
Information on systems sometimes need a ‘Parent’ in order for the child to belong
You can get some information from the Child but you would need to go to the Parent to know where the child came from
One parent might have many children who then might have more children but you can follow the line all the way to the beginning or first ‘parent’
19. Tracing
I’ve mentioned before how LEGO bricks just lend themselves to these ELI5 explanations of technical terms, especially as it relates to cloud concepts. In this case, Product Marketing Manager Peter Di Stefano walks through the way tracing concepts would help troubleshoot a failure many of us may encounter this month—when a beloved new toy isn’t operating as expected.
Take apart the puzzle until you find the piece that is out of place
I think you highlight an important piece of tracing—documentation! Just like building LEGOs, you need a map to tell you what the process should be. That way when the trace shows a different path you know where the problem sits.
Hey Five-year-old me,
Remember when I talked about Event Correlation a while back and told you that it was like dot to dot, because all the events were dots and if you connected them together you can see a clearer “picture” of what’s going on?
Well, today we’re going to talk about Tracing, which “seems” like the same thing, but it isn’t.
See in Event Correlation you have no clue what the picture is. Event Correlation’s job is to connect events together, so it can create as clear a picture as it can of the events to give you an outcome. Just remember, Event Correlation is only as good as the information that’s provided. If events (dots) are left out—the picture is still incomplete, and it takes a little work to get to the bottom of what’s going on.
In tracing—you already know what the picture is supposed to look like.
Let’s say you wanted to draw a picture of a sunflower.
Your mom finds a picture of the sunflower on the internet and she prints it off for you.
Then she gives you a piece of special paper called “vellum” that’s just the right amount of opaque (a fancy term for see-through) paper, so you can still see the picture of the sunflower underneath it. She gives you a pencil so you can start tracing.
Now in tracing does it matter where you start to create your picture?
No it doesn’t.
You can start tracing from anywhere.
In dot-to-dot, you can kinda do the same thing if you want to challenge yourself. It’s not always necessary to start at dot 1, and if you’re like me (wait...you are me)...you rarely find dot 1 the first time anyway. You can count up and down to connect the dots and eventually get there.
Just remember—in this case, you still don’t know what the picture is and that’s the point of dot to dot—to figure out what the picture is going to be.
In tracing—we already know what the picture either is, or at least is supposed to look like.
And just like in tracing, once you lift your paper off the picture, you get to see—did it make the picture that you traced below?
If it didn’t—you can either a) get a new sheet and try again or b) start with where things got off track and erase it and try again.
To understand tracing in IT, I want you to think about an idea you’ve imagined. Close your eyes. Imagine your picture in your mind. Do you see it?
- Good.
We sometimes say that we can “picture” a solution, or we “see” the problem, when in reality, a problem can be something that we can’t really physically see. It’s an issue we know is out there: e.g., the network is running slow and we see a “picture” of how to fix it in our mind; a spreadsheet doesn’t add up right like it used to, and we have a “picture” in our mind of how it’s supposed to behave and give the results we need.
But we can’t physically take a piece of paper and trace the problem.
We have programs that trace our “pictures’ for us and help us see what went right and what went wrong.
Tracing in IT is a way to see if your program, network, spreadsheet, document, well...really anything traceable did what it was supposed to do and made the “picture” you wanted to see in the end.
It’s a way to fix issues and get the end result you really want.
Sometimes we get our equipment and software to do what it’s supposed to, but then we realize—it could be even BETTER, and so we use tracing to figure out the best “path” to take to get us there.
That would be like deciding you want a butterfly on your Sunflower, so your mom prints off a butterfly for you and you put your traced Sunflower over the butterfly and then decide what’s the best route to take to make your butterfly fit on your sunflower the way you want it.
And just like tracing—sometimes you don’t have to start at the beginning to get to where you want to be.
If you know that things worked up to a certain point but then stopped working the way you want, you can start tracing right at the place where things aren’t working the way you want. You don’t always have to start from a beginning point. This saves time.
There’s lots of different types of tracing in IT. Some people trace data problems on their network, some people trace phone problems on their network, some trace document and spreadsheet changes on their files, some trace database changes. There’s all sorts of things that people can trace in IT to either fix a problem or make something better.
But the end question of tracing is always the same.
Did I get what I “pictured?”
And if the answer is “yes” - we stop and do the tech dance of joy.
It’s a secret dance.
Someday, I’ll teach you.
20. Information Security
THWACK MVP Peter Monaghan takes a moment to simply and clearly break down the essence of what InfoSec professionals do, and to put it into terms that parents would be well-advised to use with their own kids.
(while I don’t normally comment on the comments, I’ll make an exception here)
In the comments, a discussion quickly started about whether using this space to actually explain infosec (along with the associated risks) TO a child was the correct use of the challenge. While the debate was passionate and opinionated, it was also respectful and I appreciated that. Thank you for making THWACK the incredible community that it has grown to be!
I think Daddy's been reading my diary
He asks if I'm okay
Wants to know if I want to take walks with him
Or go outside and play
He tells Mommy that he's worried
There's something wrong with me
Probably from reading things in the diary
Things he thinks he shouldn't see
But I'll tell you a little secret
That diary isn't real
I scribbled nonsense in that journal
And locked away the one he can't steal
If Daddy was smart he woulda noticed
Something he's clearly forgot
Never read a diary covered with Winnie the Poo
Whose head is stuck in the Honeypot.
I haven't thought of how information security applies or is in the same category as privacy and being secure online. I have always thought of Information Security in the context of running a business. It is the same thing, just usually referenced differently. Thanks for the write up.
The OSI model
Has seven layers,
But it leaves off
The biggest players.
The house is protected
By the people inside,
We are all on watch
As such we abide.
To protect our house
As the newly hired,
All the way
To the nearly retired.
Top Comments
-
network_defender
-
Cancel
-
Vote Up
+1
Vote Down
-
-
More
-
Cancel
Comment-
network_defender
-
Cancel
-
Vote Up
+1
Vote Down
-
-
More
-
Cancel
Children