NMS Migration Made Easy: Lessons Learned
Summary
In this post, I’m going to point out some of the opportunities you have in front of you not only because you now have Kentik NMS up and running, but more importantly, as a result of all the hard work you did to get here.
The three previous blog posts in this series have focused on getting you from your old monitoring solution into Kentik NMS with a minimum of fuss, muss, or rework. But as I reviewed the content for this series, I realized that tucked away inside those posts (as well as the full NMS Migration Guide) were nuggets of wisdom that applied not only to a migration but to the broader body of work we do as IT practitioners.
I felt it was worth taking a moment to highlight skills that aren’t just useful for a migration but are, in fact, things we should be doing as IT professionals in our daily work.
In this post, I’m going to point out some of the opportunities you have in front of you, not only because you now have Kentik NMS up and running but, more importantly, because of all the hard work you did to get here.
Revisiting those customers, consumers, and constituents
You worked so hard to build those relationships, so don’t let them die on the vine now. Go back to them via Slack, email, Zoom, or by strolling up to their desk.
Touch base with the customers – the people who pay the bills. It’s entirely likely these folks are (sadly) used to staff begging for money, only to disappear once the dollars have been dispensed, with nary a word about whether that investment bore fruit or not. Make sure they get a status update: The old system is not only shut down, it’s no longer sucking up budget dollars and staff time. Make the value Kentik NMS provides equally clear to them (more on that in a minute).
Check in with the consumers to verify that Kentik NMS is handling everything the previous solution covered and find out what the old tool never did but they’d always wanted. Let this be the start of an ongoing feedback loop between you and the true beneficiaries of network observability.
Use these regular (every three to six months) updates to do the following:
- Validate whether the monitors, reports, dashboards, and alerts still deliver the expected results.
- Tweak the ones that have drifted too far off the mark.
- Delete anything that’s no longer needed.
- Reserve time to discuss new needs and opportunities.
Finally, this is a great time to consider attending a Network Observability Road Show among the constituents. It’s hard to understate the impact of a short presentation highlighting specific problems you’ve used monitoring and observability to solve, followed by a quick review of capabilities. This is less about singing Kentik’s praises specifically and more a chance to share the results of network observability at a high level.
Inevitably, some of the folks you speak with will realize that the technology they rely on may benefit from the capabilities you’re describing.
Management as a second opinion
You may recall how we reminded you that the beloved tools used by teams today often have some monitoring baked in, but that didn’t mean Kentik NMS should supplant them.
That is 100% true. But it’s also true that those tools can pull very specific telemetry from their systems, and you would be remiss to dismiss it out of hand. Instead, look for ways to validate Kentik NMS’ data against those sources of truth. This isn’t to say that vendor-provided management tools are always right. If we’re being honest, neither is Kentik NMS. Instead, those tools are a validation point. If their results differ from Kentik’s, it’s an opportunity to investigate why. Your environment as a whole can only improve from the effort.
Monitor what matters
And make monitoring matter.
As part of this migration, you’ve spent a lot of time gathering and validating the inventory of devices, elements, sub-components, dashboards, reports, and alerts. Now is the time to review that list and ask the hard questions about what value these assets provide.
Not the devices themselves. Obviously, those are valuable to the business. But do you really need to monitor ARP tables? Do you need to collect them every 60 seconds? Does the alert telling you when any server has over 60% CPU utilization provide the business with meaningful insight? How about that report sent to the entire DBA team (in which half of them most likely have an email rule that sends it directly to the trash folder)?
This is more than just Marie Kondo-ing your monitoring and throwing out anything that doesn’t spark joy. As mentioned earlier, each and every element in Kentik NMS represents a unit of work. It serves nobody to collect data nobody ever intends to use, to alert on events nobody responds to, or to send reports to folks with no interest in the information.
Flex your language skills
Finally, it’s possible that this project opened up a seat at the table with your leaders. Don’t dismiss the incredible opportunity this presents or shy away from it because you – a seasoned IT practitioner – are afraid of being sucked into a management role and losing your technical edge.
Being bilingual means speaking two languages fluently, not losing the ability to speak one in favor of another. Having developed fluency in the language of the business, you should use your newfound superpower for good (and not evil) in precise ways:
- Continue to frame the technical achievements monitoring and observability (to say nothing of Kentik NMS) have achieved in business terms, describing how they have helped reduce cost and remove risk (and bonus points if you’ve used it to help increase revenue).
- As you sit at the leadership table, listen carefully. You will undoubtedly hear about what the business cares about most. Pay attention to this information, as it’s a cheat code to get more positive attention, support, and (most importantly) budget. Knowing what is most critical to the business tells you (and in terms you can tell your team) where to focus your efforts concerning what should be monitored.
- Take what you heard back to your team. Use your bilingual fluency to translate those business goals back into technical specifications. Leverage the company priorities you heard about to elevate projects that support them. But most of all, share what you heard with the team because, more often than not, there will be additional ideas on how to do things even more effectively.
As Kenneth Blanchard said, “None of us is as smart as all of us.”
The feedback loop that inevitably results – hearing what is important, monitoring it vigorously, and reporting back the positive results, which, in turn, will spark conversations where you hear about more business-critical initiatives – will ensure that the business continues to understand the value network observability brings to the table and therefore supports your efforts.
The end of the beginning
There are many more blog posts to come on NMS and the rest of the full suite of Kentik solutions. But for now, we’re setting aside the subject of migrations. That doesn’t mean you should set aside the skills you’ve learned along the way.
It’s all too common to underestimate lessons and techniques learned in a specific context (e.g., migrating from one monitoring tool to Kentik NMS) and ignore how they apply in a wide range of other scenarios. Hopefully, this post gives you a reason to pause momentarily and consider the valuable tools you’re effectively throwing away.
Regardless, we hope you find a few bits of wisdom you can add to your toolbox.
