As an MSP owner or manager, you want your teams to be continually improving and increasing efficiency. To make that happen, you know you need to be tracking MSP KPIs—after all, what gets measured gets improved. But which numbers do you track, how many do you track, and how do you actually use them to get better?

Aches in your back and neck? Clutter eating up your desktop and desk’s top? Feeling so absorbed in your to-do list that you forget to breathe? You could be suffering from IT job stress. And you’re not alone! Let’s look at ways to identify stress before it gets to be too much, and some helpful tips for letting it go.

It’s surprisingly difficult to find information related to monitoring a distributed network. I think this is because, in part, network pros take the term for granted. We all intuitively know what a distributed network is, and the term is pretty common in conversation. But when you start to think about a precise definition, or even search for one online, things get fuzzy. What exactly makes a network distributed? Is a distributed network fundamentally different from a decentralized network?

When I hear QUIC, my immediate reaction is, “The QUICk brown fox jumps over the lazy dog.” That sentence has been ingrained in me since my first typing classes decades ago! I doubt the creators of QUIC were going for this type of reaction when they put together the name… but the good news is that this isn’t an article on typing. We’re diving into what the QUIC protocol is, how it works and how it’s used, and how it’s going to impact web traffic in the future.

One of the largest challenges with network bandwidth metering is the way traffic flows. Traffic comes in bursts. It’s never a constant, predictable stream of data you can measure once, spec hardware for and be done with (wouldn’t that be nice?!). Instead, you need to account for the dynamic nature of bandwidth utilization and its impact on performance. You’ll never be able to predict every burst of traffic your network experiences.

The meanings behind job titles can be an elusive thing in that they might only make sense to the people actually in the roles. Take networking jobs. It’s pretty common for people to think some titles can be used interchangeably, and that depending on where you work, a job may have a different name. In some cases, even IT professionals believe that the network specialist vs engineer are jobs are really the same responsibilities.

Though I’m a big believer in the importance of network configuration management , even I’ll admit that network switch configuration from a command-line interface (CLI) is still one of the most fundamental network engineering skills you can have. It’s also one of the harder things to pick up if you’re new to the field. And it’s not just knowing what commands to enter. It isn’t always obvious what should be part of a basic configuration.

A network must align with the existing requirements of an organization, but it must also be flexible enough to easily integrate new technologies, which is where hierarchical network design comes in.

You’ve probably happened across this little conundrum at least once or twice—troubleshooting a network issue where users are connecting to the network, but they aren’t able to access any resources or the internet. You start going through your troubleshooting workflow: check physical layer, data link layer, network layer… and there’s the problem. The device has an IP address, but it’s not an IP address you’d expect to see on your network.

People often conflate monitoring and observability, and I can’t blame them. Marketers often use the terms interchangeably. However, monitoring and observability are two fundamentally different but related things. Understanding the differences between the two both technically and intuitively can help you become a better network troubleshooter, architect, and manager. After all, like many buzzwords before it, observability is an important concept if you can get past the fluff.