Geek Speak

9 Posts authored by: KMSigma Expert

We’re sure getting excited for THWACKcamp™ 2018, and I’m particularly excited for you to join me at one of my sessions, There’s an API for That: Introduction to the SolarWinds® Orion® SDK. You won’t want to miss out on this exciting and informative session, so be sure to make it a part of your session track planning, along with the other highly-anticipated THWACKcamp sessions.

 

During this session, I’ll be joined by two fellow THWACK® MVPs. You’ll be able to watch history in the making, as it’s the first time three MVPs present a THWACKcamp session together. On top of being THWACK all-stars and IT experts, Zack Mütchler (zackm) is an experienced software engineer and Leon Adato (adatole) is a SolarWinds Head Geek™. Together, the three of us will deep dive into the Orion Platform API, which is readily available for anyone who has installed and is working on the Orion Platform. As the title implies, this session is not just about the API, but also the Software Development Kit (SDK), which is essentially a bunch of tools that can help you use and interact with the API. With all this already at your disposal, what next? Tune into this session so you can learn exactly what the SDK and API are capable of, and how you can use both to their greatest potential, including removing some of the repetition involved with your tasks, and in the process, make your life a little easier.

 

THWACKcamp is the two-day, premier online IT event that anyone involved in or interested in the IT world should be a part of. A top-tier event like this must be pretty expensive, right? Not at all. You can take part in this entirely virtual, totally awesome IT learning event for free! You don’t even have to worry about travel costs, since it can be accessed anywhere there’s Wi-Fi. Register now for THWACKcamp 2018, taking place October 17 – 18. See you there!

Flood of Kobolds vs. Epic Boss Fight

I had a group where I was running a dragon-themed adventure.  Before you gasp and say mockingly, “In Dungeons & Dragons, there are actually dragons?” let me tell you that that was just thematic (as far as my players knew).

Kobold

Part of this was making Kobolds be in a frenzy because they were acting on the orders of their dragon overlord.  For those unaware, Kobolds are the cannon fodder of the D&D world.  The party was repeatedly beleaguered by hordes of them with staged battles (archers then infantry then mages).  Long story short, each battle felt like a big fight with the difficulty ramping up each time.  Unfortunately for my players, these were just the opening volleys.

The big battle was against a young dragon.  Don’t let the word “young” distract you from the word “dragon.”  This wasn’t an easy fight.  Sadly, it was nearly a total party kill (TPK) for the group because they got overconfident based on their previous encounters.  Confidence is great – overconfidence less so.

I’ve seen the same thing in IT.  Technicians get cocky thinking that they know everything and bite off more than they can chew.  This is typically something that green IT people do, but they don’t have exclusive rights to this failing.  The thought that “in a perfect world it will go just like this” falls on its face when you realize that there’s no such thing as a perfect world.  New IT people sometimes don’t have the good sense to think, “maybe this isn’t just one-degree harder than the previous thing I did.”  If there’s a lesson to be learned here, it’s that you cannot win every fight with the same skills you already have.  Learn new ones and evaluate your scenarios before rushing in.

Summation

We get to the final question here, “Has running a D&D game actually provided me with any life skills?”  The answer is a resounding “Yes!”  So much so, that I would have no issue putting a few things on my professional resume.

·         Meet with peers for scheduled creativity and conflict resolution exercises

·         Assisted multiple people with gathering experience for both character and skill development

  Learned to quickly assess situations and collaborate on best solutions

Short-Circuiting your Adventure

I’ve noted that preparation and planning are some of the hallmarks of both a good DM and IT professional, but sometimes planning gets short-circuited.  In the past, I’ve spent hours working on a campaign with intricate details, a slowly building storyline, interesting character interactions, and a clear path from point A to B to C and so on.

Then we sit down to play this epic tale, and the players choose to follow the white rabbit instead of the obvious path in front of them and jump immediately to point J.  That’s it.  A small change and they’ve completely gone off course.  In the past, I’ve had this go one of two ways: the group takes a petty diversion and makes it more than it’s supposed to be or they’ve jumped ahead in the story so much that I don’t have anything else planned.  As the DM, you can either throw up your hands and walk away, force them back on the “right” path, or see where the adventure leads.

One of those avenues reminds me of scope creep in IT Projects.  You’ve outlined everything in a beautiful waterfall plan and the team starts taking side-trips and tacking on new requirements.  The adventure of discovery is upon you!  Keep going!  Let’s see where this will end up.  Will planning to only swap out a power supply lead to the adventure of replacing all the UPS’s in a data center?  Who knows?  Mystery abounds.

The clear answer here is “within reason.”  You’ve planned one change and now people are adding more and more to that change request.  Where do you draw the line?  I can’t answer that for you, because it’s different for every scenario, but you should be open to change.  Embrace it where you can and push it off where you cannot.

The flip side of this scope creep is having your entire plan thrown out and being asked to “skip to the end.”  Just like in D&D this leaves you asking, “what’s next?” and not having a clue.  Maybe you’ve only planned for five steps and you need to jump right to step six.  Can you plan for this?  Probably not.  About the only thing you can do it plan for unexpected.

Looking back, the same solution presents itself for each problem: plan for the unexpected.  This applies to the players, the DM, and the IT Professional.  There’s always going to be another tree in the forest, and there might be a goblin archer behind one.  Plan for these diversions, but don’t let them pull you from your goal.

This is the second post in a post that started in Part the First.

CRIT! Unplanned Good/Bad

Randomness is a part of life.  This has widespread areas of affect: from human interactions to chaos theory.  To make Dungeons & Dragons more lifelike, it needs to inherit this randomness from real life.  This is where the dice come in.  The one that’s used most often is the 20-sided die (referred to as a d20).

On any roll of a d20, you have a 5% chance to get any number.  The best and worst rolls being a 20 or a 1, respectively.  Anyone has a 5% chance of hitting either result (thanks math!).  In D&D these get special connotations: they are called Critical Rolls.  So, a 20 is a Critical Hit and a 1 is a Critical Fail.

Critical Hits in IT

Sometimes you or your team just hit something out of the park.  Yes, I’m mixing metaphors here, but you get the point.  You didn’t plan for this task to go as well as it did.  You’ve moved 1,000 mailboxes during the night with no downtime.  Your team executed a zero-downtime upgrade of a SQL cluster.  Your coworker applied configurations to 200 WAN routers with no blips.  This a Critical Hit!

On the chance that you’ve encountered one of these rare events, be sure to celebrate.  Do a little dance, take everyone out for a lunch, let your management team know about it, whatever you do to mark accomplishments.

Then again, there’s the other side of the coin die.

Critical Fails in IT

I hate to say it, but in Information Technology, it always feels like there’s more probability of getting a 1 on a d20.  I stated earlier that in the game, you have a 5% chance to get a critical failure, but real-life IT probability feels skewed towards failure instead of success.

In game when you have a critical failure whatever you are trying to do fails… epically.  You go to push a troll off a bridge and instead you lightly caress his shoulder.  You both feel awkward.  This is an epic failure and the scope of it is bound to DM discretion.

In IT, epic failures take different forms.  They can be something as simple as turning off the wrong port on a switch or as great as crashing a mail server.  An IT department doesn’t have a DM to choose what happens when things go wrong.  Instead we rely on our own knowledge and the experience of others to help guide us on how to proceed.  Quick thinking and decisive action are key parts to following up after a failure, but the best thing you can do is communicate.

Communicate with the department and the affected parties.  Clean, clear communication of the issue and your plans for recovery are the first, best thing you can do after getting an epic failure.  Here’s where every member of IT gets to be their own DM.  It’s up to you to decide the next move.  Make it a good one with transparency.

So, here’s the first confession: I’m an über nerd.  I’ve been playing Dungeons & Dragons (D&D) since I was about 16 years old.  It was also about that time (possibly coincidentally) that I also became engrossed with computers.  Not just watching my fake family die from dysentery, cholera, snake bites or drowning, but actually how they worked and why this was important.

In High School, I had a job with a few good friends and still had some free time.  What’s a teenager to do with some free time, friends, evenings off, while still maintaining a clean criminal record?  We decided to give this Dungeons & Dragons thing a try.

Defining Roles

Part of the deal with a new D&D group is punishing someone deciding who will be the Dungeon Master (the “DM”).  Where everyone else gets to read parts of one book, the DM gets to read that whole book and two others.  Your job as DM is to provide the game bounds and guide the characters on their adventures. Done well, it’s like collective story telling with some randomness added.

Looking back, the parallels between working in Information Technology and running a D&D campaign have striking similarities.

Party Balance

Confidence and a little bit of showmanship are key attributes of a DM.  You are the center of attention most of the time as you weave the story and outline possible paths.  Understanding and enforcing the rules is important, but even more vital is keeping the players working together.  This can be especially difficult based on their experience with the game, the varying personality types, and the jobs or alignments they’ve chosen for their characters.

Thinking back, this isn’t any different than working with an IT Team.  There are going to be people who know more than others, each will different skills, and their personalities can be just as varied.  Leading a team like that can be frustrating, but also incredibly rewarding.  The different skills create a great “party balance” and the different levels of experience offer multiple perspectives when solving a problem.

Come to think of it, creative problem solving is also something that crosses the boundaries of Dungeons & Dragons and Information Technology.  Given a situation (dragon in a tower or storage array tray failure) you need to work together to try and find a solution.

Planning

Some would argue that being a Dungeon Master is only as difficult as taking the time to do the reading and planning.  Sure, you can pick up a pre-written module, but you still need to read through it and prepare.  Planning is key as it keeps the process (or story) moving forward.  Keeping tabs on various players, settings, and key items is just as important as getting updates on teammates, inventory, and project status.

My past, in both IT and D&D, have influenced each other in more ways that I can count.  In a game a few years ago, my wife was playing as an elven bard.  Basically, her role in the party was to poke fun at the other players and keep things moving forward.  If the players were sitting on their hands debating opening a door, she would kick it in and keep the game moving forward.  Whether she knew it or not, she was acting as my Project Manager – keeping the process moving.

Check back for part 2 soon.

Every year, THWACKcamp is my favorite industry event. Yes, I like going to Microsoft Ignite, VMworld, and Cisco Live, but interfacing with more like-minded people is my bag. This is why things like the SolarWinds User Groups and THWACKcamp are my jam. I’ve been attending THWACKcamp since the beginning.

 

Let me start by saying that I was a proponent of SolarWinds’ solutions long before it became cool. Does that make me a SolarWinds hipster?  If so, I’ll wear that fedora at an ironic, yet jaunty angle. Years ago, I joined the THWACK community and sometime later was invited to be a THWACK MVP. Since that time, I moved to the “dark side” and became a Product Manager for SolarWinds.

Although I’ve participated in THWACKcamp as a customer since the beginning, this is my third year seeing THWACKcamp from the inside. I've been able to be a part of THWACKcamp since 2015, and I have to say that this year's event was the biggest and best. As always, the content was great. We got input from some of the biggest names in the industry and even had some grace our studio. This year there were more panels, more real-world discussions, and more input from the community than ever.

All of this was great, but I’m here to tell you that the best part was hearing from and meeting THWACK MVPs. This year we had 22 in attendance (25 if you count Leon, Mike, and myself ). You even got to see some of them during the live interludes between sessions.  Many are repeat visitors, others were people I’ve only met at SWUGs, but several were new faces. Though I’ve spoken with many of them online, this was the first time for me to meet them face to face.

Many of these people traveled thousands of miles to be here for the event. In an effort to make it as enjoyable as possible, we tried to line up a few outside events. Thus, the hangover.

Day 0

On Day 0 (the day before the official event), we set up a game night. I got to break out my uber-nerdiness and run a session of Dungeons & Dragons for some of the MVPs.

Here there be dragons... in dungeons.

We even decorated the game room (big thanks to mrssigma for gathering all the goodies)! And a week later, the decorations are still up.  I have no intentions of taking them down... ever.

The Gates of Fun!

Because you can't have a game night with just one game, another group gathered to play SysadMANIA. The laughter was loud and often.

sysADMANIA spotted in the wild!

Day 1

Then Day 1 happened and introductions were made, conversations exchanged, and assistance grabbed.

At the end of Day 1, there was a UX Happy Hour, which turned into a Happy Evening. So happy that even though the restaurant closed at 9:00 pm, we stayed until nearly 11:00 pm.

UX Happy Hour(s)

Day 2

Day 2 began a little slow. I mean, we all got there, but some of us were worse for the wear.

The second day also included more laughs with the MVPs, including a game of "Who Wore it Better?"

Who Wore it Better?

Day 2 ended with a surprise from the MVPs. They unveiled the T-shirts they designed in honor of the UX team.

It brought meech to tears and hugs were everywhere.

Day 2 ended with me going to my bowling league, so I had to beg out of the second-night shenanigans, but that doesn't mean that there isn't photographic evidence.

So I missed some fun.

For the second night in a row, the MVPs closed not one, but two restaurant/bars.

What a great year! It was really fun meeting up with people, talking tech, and building friendships.

Do you feel like you missed anything? Were you unable to watch one session because you had to choose another in the same time slot? Fear not, you can watch all of them here! Check out what you missed, or watch your favorite sessions again, as often as you can. If you're like me, you are already anticipating THWACKcamp 2018. I can't wait!

Without a doubt, we're at a tipping point when it comes to security and the Internet of Things (IoT). Recently, security flaws have been exposed in consumer products, including children's toys, baby monitors, cars, and pacemakers. In late October 2016, Dyn®, an internet infrastructure vendor, suffered a malicious DDoS attack that was achieved by leveraging malware on IoT devices such as webcams and printers that were connected to the Dyn network.

 

No, IoT security concerns are not new. In fact, any device that's connected to a network represents an opportunity for malicious activity. But what is new is the exponential rate at which consumer-grade IoT devices are now being connected to corporate networks, and doing so (for the most part) without IT's knowledge. This trend is both astounding and alarming: if your end user is now empowered to bring in and deploy devices at their convenience, your IT department is left with an unprecedented security blind spot. How can you defend against something you don't know is a vulnerability?

 

BYOD 2.0


Right now, most of you are more than likely experiencing a flashback to the early days of Bring Your Own Device (BYOD) - when new devices were popping up on the network left and right faster than IT could regulate. For all intents and purposes, IoT can and should be considered BYOD 2.0. The frequency with which IoT devices are being connected to secured, corporate networks is accelerating dramatically, spurred on in large part by businesses' growing interest in leveraging data and insights collected from IoT devices, combined with vendors' efforts to significantly simplify the deployment process.

 

Whatever the reason, the proliferation of unprotected, largely unknown and unmonitored devices on the network poses several problems for the IT professionals tasked with managing networks and ensuring the organizational security.

 

The Challenges


First, there are cracks in the technology foundation upon which these little IoT devices are built. The devices themselves are inexpensive and the engineering that goes into them is more focused on a lightweight consumer experience as opposed to an enterprise use case that necessitates legitimate security. As a result, these devices re-introduce new vulnerabilities that can be leveraged against your organization, whether it's a new attack vector or an existing one that's increased in size.

 

Similarly, many consumer-grade devices aren't built to auto-update, and so the security patch process is lacking, creating yet another hole in your organization's security posture. In some cases, properly configured enterprise networks can identify unapproved devices being connected to the network (such as an employee attaching a home Wi-Fi router), shut down the port, and eradicate the potential security vulnerability. However, this type of network access control (NAC) usually requires a specialized security team to manage and is often seen only in large network environments. For the average network administrator, this means it is of premier importance that you have a fundamental understanding of and visibility into what's on your network - and what it's talking to - at all times.

It's also worth noting that just because your organization may own a device and consider it secure does not mean the external data repository is secure. Fundamentally, IoT boils down to a device inside your private network that is communicating some type of information out to a cloud-based service. When you don't recognize a connected device on your network and you're unsure where it's transmitting data, that's a problem.

 

Creating a Strategy and Staying Ahead


Gartner® estimates that there will be 21 billion endpoints in use by 2020. This is an anxiety-inducing number, and it may seem like the industry is moving too quickly for organizations to slow down and implement an effective IoT strategy.

 

Still, it's imperative that your organization does so, and sooner rather than later. Here are several best practices you can use to create an initial response to rampant IoT connections on your corporate network:

  • Create a vetting and management policy: Security oversight starts with policy. Developing a policy that lays out guidelines for IoT device integration and connection to your network will not only help streamline your management and oversight process today, but also in the future. Consider questions like, "Does my organization want to permit these types of devices on the corporate network?" If so, "What's the vetting process, and what management processes do they need to be compatible with?" "Are there any known vulnerabilities associated with the device and how are these vulnerabilities best remediated or mitigated?" The answers to these questions will form the foundation of all future security controls and processes.
    If you choose to allow devices to be added in the future, this policy will ideally also include guidelines around various network segments that should/should not be used to connect devices that may invite a security breach. For example, any devices that request connection to segments that include highly secured data or support highly critical business processes should be in accordance with the governance policy for each segment, or not allowed to connect. This security policy should include next steps that go beyond simply "unplugging" and that are written down and available for all IT employees to access. Security is and will always be about implementing and verifying policies.
  • Find your visibility baseline: Using a set of comprehensive network management and monitoring tools, you should work across the IT department to itemize everything currently connected to your wireless network and if it belongs or is potentially a threat. IT professionals should also look to leverage tools that provide a view into who and what is connected to your network, and when and where they are connected. These tools also offer administrators an overview of which ports are in-use and which are not, allowing you to keep unused ports closed against potential security threats and avoid covertly added devices.
    As part of this exercise, you should look to create a supplemental set of whitelists - lists of approved machines for your network that will help your team more easily and quickly identify when something out of the ordinary may have been added, as well as surface any existing unknown devices your team may need to vet and disconnect immediately.
  • Establish a "Who's Responsible?" list: It sounds like a no-brainer, but this is a critical element of an IoT management strategy. Having a go-to list of who specifically is responsible for any one device in the event there is a data breach will help speed time to resolution and reduce the risk of a substantial loss. Each owner should also be responsible for understanding their device's reported vulnerabilities and ensuring subsequent security patches are made on a regular basis.
  • Maintain awareness: The best way to stay ahead of the IoT explosion is to consume updates about everything. For network administrators, you should be monitoring for vulnerabilities and implementing patches at least once a week. For security administrators, you should be doing this multiple times a day. Your organization should also consider integrating regular audits to ensure all policy-mandated security controls and processes are operational as specified and directed. At the same time, your IT department should look to host some type of security seminar for end-users where you're able to review what is allowed to be connected to your corporate network and, more importantly, what's not allowed, in order to help ensure the safety of personal and enterprise data.

 

Final Thoughts

 

IoT is here to stay. If you're not already, you will soon be required to manage more and more network-connected devices, resulting in security issues and a monumental challenge in storing, managing, and analyzing mountains of data. The risk to your business will likely only increase the longer you work without a defined management strategy in place. Remember, with most IoT vendors more concerned about speed to market than security, the management burden falls to you as the IT professional to ensure both your organization and end-users' data is protected. Leveraging the best practices identified above can help you begin ensuring your organization is getting the most out of IoT without worrying (too much) about the potential risks.


This is a cross-post of IoT and Health Check on Sys-Con.

I may be dating myself, but anyone else remember when MTV® played music videos? The first one they ever played was The Buggle's "Video Killed the Radio Star."  The synth-pop feel of the song seemed so out of place with the words, which outlined the demise of the age of the radio personality. Thinking back, this was the first time I can remember thinking about one new technology completely supplanting another. The corollary to this concept is that radio stars are now antiquated and unneeded.

 

Fast forward a few decades and I'm entrenched in IT. I'm happily doing my job and I hear about a new technology: virtualization. At first, I discounted it as a fad (as I'm sure many of us old-school technologists did). Then it matured, stabilized, and gained a foothold.

 

One technology again supplanted another and virtualization killed the physical server star. Did this really kill off physical servers entirely? Of course not. No more so than video killed radio. It just added a level of abstraction. Application owners no longer needed to worry about the physical hardware, just the operating system and their applications. Two things happened:

1.       Application owners had less to worry about

2.       A need for people with virtualization experience developed

 

From that point on, every new person who entered IT understood virtualization as a part of the IT stack.  It was a technology that became accepted and direct knowledge of physical servers was relegated to secondary or specialized knowledge. Having knowledge about firmware and drivers was suddenly so "retro."

 

Virtualization matured and continued to flourish, and with it, new vendors and capabilities entered the market, but dark clouds were on the horizon. Or perhaps they weren't dark-just "clouds" on the horizon. As in private clouds, hybrid clouds, public clouds, fill-in-the-blank clouds. The first vendor I remember really pushing the cloud was Amazon® with their Amazon Web ServicesTM (AWS®).

 

Thinking back, this seemed like history repeating itself. After all, according to many, Amazon nearly destroyed all brick and mortar bookstores. It looked like they were trying to do the same for on-premises virtualization. After all, why worry about the hardware and storage yourself when you can pay someone else to worry about it, right?

 

This seems reminiscent of the what happened with virtualization. You didn't worry about the physical server anymore-it became someone else's problem. You just cared about your virtual machine.

 

So, did cloud kill the virtualization star, which previously killed the server star? Of course not. For the foreseeable future, cloud will not supplant the virtualization specialist, no more so than virtualization supplanted the server specialist. It's now just a different specialization within the IT landscape.

 

What does this mean for us in IT? Most importantly, keep abreast of emerging technologies. Look to where you can extend your knowledge and become more valuable, but don't "forget" your roots.

 

You never know-one day you may be asked to update server firmware.


This is a cross-post from a post with the same name on the VMBlog.

As technology professionals, we live in an interruption-driven world; responding to incidents is part of the job. All of our other job duties go out the window when a new issue hits the desk. Having the right information and understanding the part it plays in the organization is key to handling these incidents with speed and accuracy. This is why it's critical to have the ability to compare apples-to-apples when it comes to the all-important troubleshooting process.

 

What is our job as IT professionals?

Simply put, our job is to deliver services to end-users. It doesn't matter if those end-users are employees, customers, local, remote, or some combination of these. This may encompass things as simple as making sure a network link is running without errors, a server is online and responding, a website is handling requests, or a database is processing transactions. Of course, for most of us, it's not a single thing, it's a combination of them. And considering the fact that 95 percent of organizations report having migrated critical applications and IT infrastructure to the cloud over the past year, according to the SolarWinds IT Trends Report 2017, visibility into our infrastructure is getting increasingly murky.

 

So, why does this matter? Isn't it the responsibility of each application owner to make sure their portion of the environment is healthy? Yes and no. Ultimately, everyone is responsible for making sure that the services necessary for organizational success are met. Getting mean time to resolution (MTTR) down requires cooperation, not hostility. Blaming any one individual or team will invariably lead to a room full of people pointing fingers. This is counterproductive and must be avoided. There is a better way: prevention via comprehensive IT monitoring.

 

Solution silos

Monitoring solutions come in all shapes and sizes. Furthermore, they come with all manner of targets. We can use solutions specific to vendors or specific to infrastructure layers. A storage administrator may use one solution while a virtualization and server administrator may use another and the team handling website performance a third solution. And, of course, none of these tools may be applicable to the database administrators.

At best, monitoring infrastructure with disparate systems can be confusing, at worst, it can be downright dangerous. Consider the simple example of a network monitoring solution seeing traffic moving to a server at 50 megs/second, but the server monitoring solution sees incoming traffic at 400 megs/second. Which one is right? Maybe both of them, depending on if they mean 50 MBps and 400 Mbps. This is just the start of the confusion. What happens if your virtualization monitoring tool reports in Kb/sec and your storage solution reports in MB/sec? Also, when talking about kilos, does it mean 1,000 or 1,024?

 

You can see how the complexity of analyzing disparate metrics can very quickly grow out of hand. In the age of hybrid IT, this gets even more complex since cloud monitoring is inherently different than monitoring on-premises resources. You shouldn't have to massage the monitoring data you receive when troubleshooting a problem. That only serves to lengthen MTTR.

 

Data normalization

In the past, I've worked in environments with multiple monitoring solutions in place. During multi-team troubleshooting sessions, we've had to handle the above calculations on the fly. Was it successful?  Yes, we were able to get the issue remedied. Was it as quick as it should have been? No, because we were moving data into spreadsheets, trying to align timestamps, and calculating differences in scale (MB, Mb, KB, Kb, etc.). This is what I mean by data normalization: making sure everyone is on the same page with regard to time and scale.

 

Single pane of glass

Having everything you need in one place with the timestamps lined up and everything reporting with the same scale — a single pane of glass through which you see your entire environment — is critical to effective troubleshooting. Remember, our job is to provide services to our end-users and resolve issues as quickly as possible. If we spend the first half of our troubleshooting time trying to line up data, are we really addressing the problem?

 

About the Post

This is a cross-post from my personal blog @ blog.kmsigma.com. [Link].

Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.