All posts by leon

Showing Your Scars

One summer I was hired to help build scenery for a local summer stock theater venue. The problem is that I had been trained as an electrician, so every task in the wood shop required that I learn new skills on-the-fly. Because this was a job not a class and I was expected to know what I was doing, I didn’t ask enough questions and ended up making about twice as many mistakes as necessary on everything. Most of those mistakes weren’t life-threatening.

But one of the times, I was working on the table saw had my first experience with kick-back (for a video of what this looks like, see here. No, that’s not me.).

Similar to the video linked above, I was lucky that nobody was hurt, but then something weird happened – everyone started showing off their scars.

Guys who hadn’t even been in the wood shop when my accident happened came down from ladders, up from trenches, and over from across the park to show me scars that decorated their arms, fingers, hands, legs, and torsos. Each one came with a story, and the stories were remarkably similar:

“I was doing this thing… I was standing in the wrong place… I stopped paying attention for a second…  and BOOM!”

This story was followed by “And that’s why from then on I always make sure I <fill in the name of the safety procedure>”.

In addition to being thankful that no one was harmed, I was grateful for them everyone not making me feel like I was a complete numskull for letting this happen. Apparently it can (and does) happen to everyone.

But I also wondered why nobody thought to tell those stories on the FIRST day. Like I said earlier, this wasn’t a teaching environment but I could imagine some sort of first-day ritual – the showing of the scars – where everyone lists their  experiences (in effect, showing their scars) and sharing the life lessons they learned from them.

Because not EVERYONE has had EVERY mishap, but in a team of 5 or more professionals, collectively the group has seen a lot.

At the time I thought that if every scene shop adopted a custom like that, more people would learn better lessons and have fewer scars (not to mention more severe injuries) to show for it.

I was reminded of this episode in my life the other day, when someone tweeted about reconfiguring a remote network device, only to find they had messed up one of the commands and the entire site was no longer accessible. A 2 hour drive was required to get on-site and fix the issue.

Immediately after the tweet came an outpouring of advice:

“Cisco’s ‘reload in’ command is your best friend.”;
“Always test your config in GNS3 first”;
“Never update a config until another set of eyes has looked at it first”
…and so on…

It reminded me of everyone coming down to the scene shop to show me their scars.

The next time you are sitting with your colleagues at the office – maybe you have a new face on the team; or maybe it’s YOUR first day; or maybe you’re starting a new project. Think about ways you can initiate a “showing of the scars”. Go around the table and list out your worst mistakes and the lessons you learned from them.

I’m willing to bet that you will grow closer as a team; that fewer “rookie” mistakes will be made by everyone; and that even the most grizzled veterans will probably learn a few things they didn’t know (or possibly had forgotten).

More people learning better lessons with fewer scars to show for it.

Using NetFlow monitoring tactics to solve bandwidth mysteries

NetFlow eliminated the hassle of network troubleshooting after a school complained about its Internet access.

Life in IT can be pretty entertaining. And apparently we admins aren’t the only ones who think so — Hollywood’s taken notice, too. The problem is, the television shows and feature films about IT are all comedies. I’m not saying we don’t experience some pretty humorous stuff, but I want a real show; you know, something with substance. I can see it now — The Xmit (and RCV) Files: The Truth is Out There.

 In fact, I’ve already got the pilot episode all planned. It’s based on an experience I had not long ago with the NetFlow monitoring protocol.

The company I was with at the time offered monitoring as a service to a variety of clients. One day, I was holding the receiver away from my head as a school principal shouted, “The Internet keeps going down! You’ve got to do something.”

Now, there are few phrases that get my goat like “the Internet is down,” or its more common cousin, “the network is down.” So, my first thought was, “Buddy, we have redundant circuits, switches configured for failover and comprehensive monitoring. The network is not down, so please shut up.”

Of course, that’s not what I said. Instead, I asked a few questions that would help me narrow down the root cause of the problem.

First up: “How often are you experiencing this issue?”

“A bunch,” I was told.

“Ooookay … at any particular time?” I asked.

He replied, “Well, it seems kind of random.”

Gee, thanks. I’m sure I can figure it out with such insightful detail.

It was obvious I was going to have to do some real investigation. My first check was the primary circuit to our provider. Nothing there. So, I’m sorry, Virginia, but “the Internet” is not down, as if I had any doubt.

Next, I looked at the school’s WAN interface, which revealed that yes indeed, the WAN link to the school was becoming saturated at various intervals during the day. Usage would spike for 20 to 30 minutes, then drop down until the next incident. I checked the firewall logs — not my favorite job, which showed a high volume of http connections at the same times.

Now, for many years, checking was the pinnacle of network troubleshooting — check the devices, check the logs, wait for the event to happen again, dig a little further. And in my case, that might have been all I could do. Our contract had us monitoring the entire core data center for the school system, but that only extended to the edge router for the school. We had exactly zero visibility beyond each individual school building’s WAN connection.

But as chance would have it, I had one more trick up my sleeve: NetFlow.

NetFlow has been around a while, but it’s been only in the last few years that it’s entered the common network admin lexicon, largely due to the maturation of tools that can reliably and meaningfully collect and display NetFlow data. NetFlow collects and correlates “conversations” between two devices as the data passes through a router. You don’t have to monitor the specific endpoints in the conversation, you just have to get data from one router that sits between the two points.

 

Hmm, that sounds a lot like a WAN router connected to the Internet provider, which is exactly what I had. Correlating the spike times from our bandwidth stats, we saw that during the same period, 10 MAC addresses were starting conversations with YouTube. Every time there was a spike, it was the same set of MAC addresses.

Now, if we had been monitoring inside the school, we could have gleaned much more information — IP address, location, maybe even username if we had some of the more sophisticated user device tracking tools in place — but we weren’t. However, a visit to WireShark’s OUI Lookup Tool revealed that all 10 of those MAC addresses were from — and please forgive the irony — Apple Inc.

At that point, I had exhausted all of the tools at my disposal. So, I called the principal back and gave him the start and stop times of the spikes, along with the information about 10 Apple products being to blame.

“Wait, what time was that?” he asked.

I repeated the times.

“Oh, for the love of … I know what the problem is.” Click.

It turns out the art teacher had been awarded a grant for 10 shiny new iPads. He would go from room to room during art period handing them out and teaching kids how to do video mashups.

This was one of those rare times when a bandwidth increase really was warranted, and after the school’s WAN circuit was reprovisioned, the Internet stopped mysteriously “going down.”

The episode would close with the handsome and sophisticated admin — played by yours truly, of course — looking into the camera and while channeling the great Fox Mulder saying, “Remember, my fellow admins, the truth is out there.” (And, I would add, for those of you reading this blog post, don’t forget how valuable NetFlow can be in finding network truth.)

Now, if that’s not compelling TV, I don’t know what is.

(This article originally appeared on SearchNetworking)

The Difference Between Work & Life

TL;DR: My opinions are my own, but sometimes I gotta pay the bills. I’m also not willing to win a flame war only to lose my job.

Henri Ducad/Ra’s Al Ghul: Mind your surroundings, always
Bruce Wayne: Yield!
Ducard: You haven’t beaten me. You just sacrificed sure footing for a killing stroke.

In “Batman Begins” Bruce learned that maintaining a focus on one’s surroundings is sometimes more important than the actions of one’s opponent or goal.

For sure, one cannot focus on surroundings to the exclusion of the opponent or goal, but rather it is a constant juggling of attention, or (for the technical readers) rapid task switching if not true multi-tasking.

The reason I bring this up is because now, more than ever, I have to mind my surroundings.

My job as SolarWinds HeadGeek – my dream job, I might add – affords me the chance to write articles in a wide variety of publications, to speak at a variety of conferences, and to be active on social media as part of my job. 

I mean, how cool is that? I get PAID to tweet, blog, like, follow, pin, instagram, and more!

BUT… it comes with a pricetag – I’m expected to be professional. Which most of the time is not a big deal. I *like* being professional. I think being polite, kind, positive, encouraging, insightful, introspective, self-deprecating, and (when I’m lucky) funny is kind of my jam. 

Never the less, there are things that push my buttons. It could be an act (whether personal or corporate) that I see as un-just; or an event that touches on a cause that is important to me; or a technical choice that rubs me the wrong way. 

Or maybe I’m just ornery that day.

The challenge is that the trade-off for getting to write and speak and tweet is that I represent more than just me. If I lose my cool and call someone a flaming jack-wagon on Facebook, it’s not just Leon’s opinion (no matter how many “opinions are my own” disclaimers I put in my profile). Effectively, I and the company I represent have just called someone a flaming jack-wagon. 

And that is what we call in IT circles a “Resume generating event”. 

SO… this is a reminder (which I will link to on social media from time to time) that:

  • I am me. A person with opinions about life, religion, politics, food, operating systems (Linux!), tabs vs spaces (SPACES!), and whether it’s the network’s fault (it’s never the network)
  • I am also (and, I should add, PROUDLY) a HeadGeek for SolarWinds

Sometimes my public activity will be part of “paying the bills”. In the middle of a social event you’ll see me tweet about the next episode of SolarWinds Lab. Or I may be strangely silent about the thing everyone is talking about. 

That doesn’t mean I’m a shill for the man, or that my account is operated by a soul-less corporate robot. It just means that I have to mind my surroundings, and make sure that I’m not sacrificing the sure footing of my platform and support for the fleeting glory of a temporary victory.

IT Monitoring Scalability Planning: 3 Roadblocks

Planning for growth is key to effective IT monitoring, but it can be stymied by certain mindsets. Here’s how to overcome them.

As IT professionals, planning for growth is something we do all day almost unconsciously. Whether it’s a snippet of code, provisioning the next server, or building out a network design, we’re usually thinking: Will it handle the load? How long until I’ll need a newer, faster, or bigger one? How far will this scale?

Despite this almost compulsive concern with scalability, there are still areas of IT where growth tends to be an afterthought. One of these happens to be my area of specialization: IT monitoring. So, I’d like to address growth planning (or non-planning) as it pertains to monitoring by highlighting several mindsets that typically hinder this important, but often surprisingly overlooked element, and showing how to deal with each.

The fire drill mindset
The occurs when something bad has already happened either because there was either no monitoring solution in place or because the existing toolset didn’t scale far enough to detect a critical failure, and so it was missed. Regardless, the result is usually a focus on finding a tool that would have caught the problem that already occurred, and finding it fast.

However, short of a TARDIS, there’s no way to implement an IT monitoring tool that will help avoid a problem after it occurs. Furthermore, moving too quickly as a result of a crisis can mean you don’t take the time to plan for future growth, focusing instead solely on solving the current problem.

My advice is to stop, take a deep breath, and collect yourself. Start by quickly, but intelligently developing a short list of possible tools that will both solve the current problem and scale with your environment as it grows. Next, ask the vendors if they have free (or cheap) licenses for in-house demoing and proofs of concept.

Then, and this is where you should let the emotion surrounding the failure creep back in, get a proof-of-concept environment set up quickly and start testing. Finally, make a smart decision based on all the factors important to you and your environment. (Hint: one of which should always be scalability.) Then implement the tool right away.

The bargain hunter
The next common pitfall that often prevents better growth planning when implementing a monitoring tool is the bargain-hunter mindset. This usually occurs not because of a crisis, but when there is pressure to find the cheapest solution for the current environment.

How do you overcome this mindset? Consider the following scenario: If your child currently wears a size 3 shoe, you absolutely don’t want to buy a size 5 today, right? But you should also recognize that your child is going to grow. So, buying enough size 3 shoes for the next five years is not a good strategy, either.

Also, if financials really are one of the top priorities preventing you from better preparing for future growth, remember that the cheapest time to buy the right-sized solution for your current and future environment is now. Buying a solution for your current environment alone because “that’s all we need” is going to result in your spending more money later for the right-sized solution you will need in the future. (I’m not talking about incrementally more, but start-all-over-again more.)

My suggestion is to use your company’s existing business growth projections to calculate how big of a monitoring solution you need. If your company foresees 10% revenue growth each year over the next three years and then 5% each year after that, and you are willing to consider completely replacing your monitoring solution after five years, then buy a product that can scale to 40% of the size you currently need.

The dollar auction
The dollar auction mindset happens when there is already a tool in place — a tool that wasn’t cheap and that a lot of time was spent perfecting. The problem is, it’s no longer perfect. It needs to be replaced because company growth has expanded beyond its scalability, but the idea of walking away from everything invested in it is a hard pill to swallow.

Really, this isn’t so much of a mindset that prevents preparing for future growth as it is something that’s all too often overlooked as an important lesson: If only you had better planned for future growth the first time around. The reality is that if you’re experiencing this mindset, you need a new solution. However, don’t make the same mistake. This time, take scalability into account.

Whether you’re suffering from one of these mindsets or another that is preventing you from better preparing your IT monitoring for future growth, remember, scalability is key to long term success.

(This article originally appeared on NetworkComputing)

Time for a network monitoring application? What to look for

You might think that implementing a network monitoring tool is like every other rollout. You would be wrong.

Oh, so you’re installing a new network monitoring tool, huh? No surprise there, right? What, was it time for a rip-and-replace? Is your team finally moving away from monitoring in silos? Perhaps there were a few too many ‘Let me Google that for you’ moments with the old vendor’s support line?

Let’s face it. There are any number of reasons that could have led you to this point. What’s important is that you’re here. Now, you may think a new monitoring implementation is no different than any other rollout. There are some similarities, but there are also some critical elements that are very different. How you handle these can mean the difference between success and failure.

I’ve found there are three primary areas that are often overlooked when it comes to deploying a network monitoring application. This isn’t an exhaustive list, but taking your time with these three things will pay off in the end.

Scope–First, consider how far and how deep you need the monitoring to go. This will affect every other aspect of your rollout, so take your time thinking this through. When deciding how far, ask yourself the following questions:

  • Do I need to monitor all sites, or just the primary data center?
  • How about the development, test or quality assurance systems?
  • Do I need to monitor servers or just network devices?
  • If I do need to include servers,  should I cover every OS or just the main one(s)?
  • What about devices in DMZs?
  • What about small remote sites across low-speed connections?

And when considering how deep to go, ask these questions:

  • Do I need to also monitor up/down for non-routable interfaces (e.g., EtherChannel connections, multiprotocol label switching links, etc.)?
  • Do I need to monitor items that are normally down and alert when they’re up (e.g., cold standby servers, cellular wide area network links, etc.)?
  • Do I need to be concerned about virtual elements like host resource consumption by virtual machine, storage, security, log file aggregation and custom, home-grown applications?

Protocols and permissions–After you’ve decided which systems to monitor and what data to collect, you need to consider the methods to use. Protocols such as Simple Network Management Protocol (SNMP), Windows Management Instrumentation (WMI), syslog and NetFlow each have its own permissions and connection points in the environment.

For example, many organizations plan to use SNMP for hardware monitoring, only to discover it’s not enabled on dozens –or hundreds — of systems. Alternatively, they find out it is enabled, but the connection strings are inconsistent, undocumented or unset. Then they go to monitor in the DMZ and realize that the security policy won’t allow SNMP across the firewall.

Additionally, remember that different collection methods have different access schemes. For example, WMI uses a Windows account on the target machine. If it’s not there, has the wrong permissions or is locked, monitoring won’t work. Meanwhile, SNMP uses a simple string that can be different on each machine.

Architecture–Finally, consider the architecture of the tools you’re considering. This breaks down to connectivity and scalability.

First, let’s consider connectivity. Agent-based platforms have on-device agents that collect and store data locally, then forward large data sets at regular intervals. Each collector bundles and sends this data to a manger-of-managers, which passes it to the repository. Meanwhile, agentless solutions use a collector that directly polls source devices and forwards the information to the data store.

You need to understand the connectivity architecture of these various tools so you can effectively handle DMZs, remote sites, secondary data centers and the like. You also need to look at the connectivity limitations of various tools, such as how many devices each collector can support and how much data will be traversing the wire, so you can design a monitoring implementation that doesn’t cripple your network or collapse under its own weight.

Next comes scalability. Understand what kind of load the monitoring application will tolerate, and what your choices are to expand when — yes, when, not if — you hit that limit. To be honest, this is a tough one and many vendors hope you’ll accept some form of a, “it-really-depends” response.

In all fairness, it does matter, and some things are simply impossible to predict. For example, I once had a client who wanted to implement syslog monitoring on 4,000 devices. It ended up generating upwards of 20 million messages per hour. That was not a foreseeable outcome.

By taking these key elements of a monitoring tool implementation into consideration, you should be able to avoid most of the major missteps many monitoring rollouts suffer from. And the good news is that from there, the same techniques that serve you well during other implementations will help here.  You want to ask lots of questions; meet with customers in similar situations, such as environment size, business sector, etc.; set up a proof of concept first; engage experienced professionals to assist as necessary; and be prepared — both financially and psychologically — to adapt as wrinkles crop up. Because they will.

(this originally appeared on SearchNetworking)

HumbleBrag: Gesher’s Upper Level IT Training

For the last few months, I’ve been working in conjunction with Gesher Cleveland to set up a program to help people in my community acquire IT skills (and subsequently an actual paying JOB in IT.). While I plan to write about this effort in greater detail later, I wanted to share the official announcement here. Never before (and, likely, never again) will you see me referred to as “an unassuming genius”. For a whole host of reasons.

You can find the announcement here. But in case it ever archives into the great bit-bucket in the sky, I’m copying it below:

gesher connections
 

Introducing – The Upper Level

adato leon

Gesher, is launching a new program- The Upper Level, a fast track IT training program enabling members of the community to join the world of high tech. The IT field is projected to grow by 12% by 2024. The average median income for Computer & IT occupations was $81,430 in 2015.

Program Director- Leon Adato
The Upper Level is being led by Leon Adato, an unassuming genius of a man who holds the position of Head Geek for Solarwinds, Inc in Austin, TX. Adato, coding since 1989, is dedicating his vast knowledge and skill set to make this program a reality.

Self Motivated Candidates
The job skills training program is predicated on the participants’ ability to learn with minimal supervision, using pre-existing online-curriculum to drive self-study. Program staff will provide oversight, guidance, and support but not training in any significant sense.
However, The Upper Level staff will be key drivers during the assessment of incoming participants, presenting and assisting in the selection of program tracks and ongoing follow up during and after the participant has graduated.

Soft Skills
The program schedule is a rigorous one, requiring the utmost in self-discipline and motivation, prompting a highly selective application process.
Balancing the IT work will be training in non-technical career skills, such as resume writing and the interview process, as the goal of The Upper Level is to ensure that the individual graduates with a well-rounded education, with all he/ she needs to invest in his future.

First Cohort- In Session
The first cohort began several weeks ago with 8 participants. The focus is to educate graduates of Yeshiva/ Kollel in a field that caters to their sort of intelligence, character and devotion; Information Technology. Adato, in his 3rd week wrap up commented,”I am extremely excited to report that we have not only committed students, but extremely ambitious ones!”

Highest Level of Assistance
While Gesher is proud of its ability to assist those in need within the community, it is even prouder to
introduce a program such as The Upper Level, which will facilitate growth and progression among individuals, preventing the need for assistance in the future.

If you would like to share your skills and expertise with the group please email ajoseph@geshercleveland.org or leon@adatosystems.com

 

See you next month!

©2017 Gesher | 2120 S Green Rd, South Euclid, OH 44121, USA

 
 

 

ICYMI: IT monitoring: ignore it at your peril

This interview was originally posted on http://onlyit.ca

To many businesses, IT monitoring software is a luxury they cannot afford. However, that mindset is dangerous. Not monitoring your IT infrastructure can cost you in stolen data and damage your reputation. Leon Adato, who holds the title of “head geek” at SolarWinds, shared his thoughts on why IT monitoring software is vital to the health of companies as well as the consequences of ignoring the need to monitor your IT infrastructure.

“Over the course of my 25 years in IT, with 12 years specifically focused on monitoring, I would say that more often than not-say 60 percent of the time-businesses lack a gut understanding that monitoring helps save them money, and lots of it,” said Adato. “In addition, I’ve never seen a company, large or small, actually do the work to estimate and document the savings monitoring provides, either overall or on a per-alert basis.”

Adato recounted an anecdote from when he first started working in IT. “As an example, early in my career when I was doing desktop support, I got a call that the barcode printer on ‘production line seven’ was down,” he remarked. “When I got there, I realized the fix was going to take some time. It was the end of the day, I was tired and I wanted to get home. I figured this particular printer issue could wait until the next day. The guy working that line said to me, ‘I completely understand if you’ve got responsibilities, but let me make sure you understand the choice you are making-each one of these circuit boards is $10,000 of profit, and we don’t get the money until they ship, and they don’t ship until they get a barcode from that printer.’ I realized I was looking at 4 racks with about 150 boards per rack. I made a few calls and stayed late to get the printer back up and running.”

“The point of the story is that the guy on the line knew exactly what the cost breakdown was,” Adato continued. “He knew the material costs, labor costs, gross and net revenue, and he could have told you per minute, per hour, per production line how much money was being lost. That’s not uncommon in production environments. Unfortunately, companies usually don’t approach IT monitoring and alerting with the same attitude and level of awareness, even though they could, and in my opinion, certainly should.”

Even if businesses have some type of IT monitoring in place, it might not be across the entire business. “Monitoring is always happening, whether it’s a server tech who checks all his servers manually from time to time (‘monitoring via eyeballs’) or teams that implement their own ‘skunkworks’ systems,” Adato commented. “People in the trenches don’t like surprises. Those systems will be narrowly focused, though, and will probably overlap in terms of features as well as scope. For example, the server team and the Exchange team might both monitor the same server; possibly using two different tools that collect much of the same data.” This approach is inefficient and not cost effective.

Adato cited the benefits of a business-wide IT monitoring program. He noted that it provides “the ability to have ongoing metrics that allow for capacity planning, forensic analysis of unexpected events-there will always be black swans-and the shortening of not only mean time to repair but also mean time to innocence by using data to prove that something, such as the network, is not at fault so efforts can be focused elsewhere.”

SolarWinds’ head geek acknowledged that businesses will need to invest financial and personnel resources into IT monitoring. Furthermore, IT monitoring can shatter some illusions about infrastructure. “[There is] the potentially unhappy realization that the environment is not as stable as you thought it was,” Adato said. He sees a silver lining to that situation, though. “Of course, this is a good thing masquerading as a bad thing because knowing there’s a previously-undetectable problem is the first step to fixing it before it blows up,” Adato concluded.

The Top 5 Network Issues You Didn’t Know You Had

(and how monitoring can solve them)

I spend a lot of time talking about the value that monitoring can bring an organization, and helping IT professionals make a compelling case for expanding or creating a monitoring environment. One of the traps I fall into is talking about the functions and features that monitoring tools provide while believing that the problems they solve are self-evident.

While this is often not true when speaking to non-technical decision makers, it can come as a surprise that it’s sometimes not obvious even to a technical audience!

So I have found it helpful to describe the problem first, so that the listener understands and buys into the fact that a challenge exists. Once that’s done, talking about solutions becomes much easier.

With that in mind, here are the top 5 issues I see in companies today, along with ways that sophisticated monitoring addresses them.

Wireless Networks

Issue #1:

Ubiquitous wireless has directly influenced the decision to embrace BYOD programs, which has in turn created an explosion of devices on the network. It’s not uncommon for a single employee to have 3, 4, or even 5 devices.

 

This spike in device density has put an unanticipated strain on wireless networks. In addition to the sheer load, there are issues with the type of connections, mobility, and device proximity.

The need to know how many users are on each wireless AP, how much data they are pulling, and how devices move around the office has far outstripped the built-in options that come with the equipment.

Monitoring Can Help!

Wireless monitoring solutions tell you more than when an AP is down. They can alert you when an AP is over-subscribed, or when an individual device is consuming larger-than-expected amounts of data.

In addition, sophisticated monitoring tools now include wireless heat maps – which take the feedback from client devices and generate displays showing where signal strength is best (and worst) and the movement of devices in the environment.

Capacity Planning

Issue #2

We work hard to provision systems appropriately, and to keep tabs on how that system is performing under load. But this remains a largely manual process. Even with monitoring tools in place, capacity planning—knowing how far into the future a resource (CPU, RAM, disk, bandwidth) will last given current usage patterns—is something that humans do (often with a lot of guesswork). And all too often, resources still reach capacity without anyone noticing until it is far too late.

Monitoring Can Help!

This is a math problem, pure and simple. Sophisticated monitoring tools now have the logic built-in to consider both trending and usage patterns day-by-day and week-by-week in order to come up with a more accurate estimate of when a resource will run out. With this feature in place, alerts can be triggered so that staff can act proactively to do the higher-level analysis and act accordingly.

Packet Monitoring

Issue #3

We’ve gotten very good at monitoring the bits on a network – how many bits per second in and out; the number of errored bits; the number of discarded bits. But knowing how much is only half the story. Where those bits are going and how fast they are traveling is now just as crucial. User experience is now as important as network provisioning. As the saying goes: “Slow is the new down.” In addition, knowing where those packets are going is the first step to catching data breaches before they hit the front page of your favourite Internet news site.

Monitoring Can Help!

A new breed of monitoring tools includes the ability to read data as it crosses the wire and track source, destination, and timing. Thus you can get a listing of internal systems and who they are connecting to (and how much data is being transferred) as well as whether slowness is caused by network congestion or an anaemic application server.

Intelligent Alerts

Issue #4

“Slow is the new down”, but down is still down, too! The problem is that knowing something is down gets more complicated as systems evolve. Also, it would be nice to alert when a system is on its way down, so that the problem could be addressed before it impacts users.

Monitoring Can Help!

Monitoring tools have come a long way since the days of “ping failure” notifications. Alert logic can now take into account multiple elements simultaneously such as CPU, interface, and application metrics so that alerts are incredibly specific. Alert logic also now allows for de-duplication, delay based on time or number of occurrences, and more. Finally, the increased automation built into target systems allows monitoring tools to take action and then re-test at the next cycle to see if that automatic action fixed the situation.

Automatic Dependency Mapping

Issue #5

One device going down should not create 30 tickets. But it often does. This is because testing upstream/downstream devices requires knowing which devices those are, and how each depends on the other. This is either costly in terms of processing power, difficult given complex environments, time-consuming for staff to configure and maintain, or all three.

Monitoring Can Help!

Sophisticated monitoring tools now collect topology information using devices’ built-in commands, and then use that to build automatic dependency maps. These parent-child lists can be reviewed by staff and adjusted as needed, but they represent a huge leap ahead in terms of reducing “noise” alerts. And by reducing the noise, you increase the credibility of every remaining alert so that staff responds faster and with more trust in the system.

So, what are you waiting for?

At this point, the discussion doesn’t have to spiral around whether a particular feature is meaningful or not. As long as the audience agrees that they don’t want to find out what happens when everyone piles into conference room 4, phones, pads, and laptops in tow; or when the “free” movie streaming site starts pulling data out of your drive; or when the CEO finds out that the customer site crashed because a disk filled, but had been steadily filling up for weeks.

As long as everyone agrees that those are really problems, the discussion on features more or less runs itself.

(originally published on GeekSpeak)

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.