Episode 30: Documentation - Boom or Bust!
Documentation! Everyone's favorite topic! OK, maybe not. This week we break down why documentation is so important, albeit, not the most exciting topic. Documentation can really make your job easier if done right, tune in to see how Pat and Kyle have handled documentation and why you should be doing it from day 1!
Like us? Give us a review on Podchaser or Apple Podcasts to let us know!
Check out our website https://www.breakingbytespod.io
Email us! - breakingbytespod@gmail.com
Follow Pat and Kyle!
Twitter:
Follow Breaking Down the Bytes!
-
Pat: 0:31
Hey everybody. Welcome back to this week's edition of Breaking Down the Bytes as usual in the hot seat driving this bus or crazy train, depending on if you like us or not. I'm your host, pat, you can find me on Twitter @layer8. That's the number eight. You can find Kyle who's riding shotgun with me as always. He's on Twitter as well @Danath256. You can find the show on Twitter @breakinbytespod we're pretty active on Twitter. So come say, hello, Kyle. We're back for another week. Another arousing episode here we are rocking and roll and what's up, man?
Kyle: 1:09
Crazy downpours today. It was pretty wild.
Pat: 1:11
It was wild. Yeah, that was like, that came in.
Kyle: 1:15
like opened up and
Pat: 1:17
Yeah.
Kyle: 1:19
yeah.
Pat: 1:20
I was like, oh, let me take the, let me take the garbage out real quick. And I was just like Nope, not in that downpour. Like all of a sudden it showed up and I was like, wow, where did you come from? You angry, little storm. You all right. yeah. And then it,
Kyle: 1:34
but yeah, it's all over. Like it never even happened now.
Pat: 1:36
I know now it's bright and sunny and the deck is drawing off. So
Kyle: 1:40
No. Yeah. Nice.
Pat: 1:42
Come and go. So this week on the show, I wanted to do this for a long time and I could never quite find the right place to throw it in, but I think it's something that it needs to be talked about. It's not the most exciting topic, but I feel it needs to be talked about and covered and deserves the time in the spotlight. It's our favorite friend documentation. And for one, let me tell you, I know. Yeah. Get outta here and all this other stuff. Like I said, it's one of those things where it's boring. It's kind of man, but it is really important in an environment to have your documentation ready to go up to date. and, rocking and rolling in case a fire breaks out. And you're, looking for the fire extinguisher, which in many times is the documentation. So, I figured we would cover that tonight and see what kind of hatred we can build among the community out there. Cause I know a lot of people hate it. I really don't like it. It's one of the, like you said earlier, before we started recording, it's one of those necessary evil. Or it's just like, you have to have it, but it's so it's not fun to build. It's not fun to keep track of an update, but it really does save your ass quite a bit.
Kyle: 2:55
Yeah, well, well, hopefully everybody's still listening and they didn't just turn it.
Pat: 2:59
yes. So thank you. If you're still here. Thank you very much. Yeah, so, there's a couple things for documentation. I've been at some places where it, the documentation's really good and some of the places where it doesn't exist at all. And then I get all jazzed up to do the documentation and then. I, it kind of like falls outta favor and it really suffers and like just, documentation is one of the things that always comes last because there's always something else to do.
Kyle: 3:29
Definitely, especially, I mean, if you're working on something it almost feels like one of the least productive things you could be doing. you're not implementing anything. You're not building anything out. You're not like really making any kind of connections or anything like that. You're like just writing things down
Pat: 3:45
Yeah, it
Kyle: 3:46
That's not very exciting,
Pat: 3:47
it's most lackluster thing. But, like I said it's important and it deserves a little respect from the, it pros such as yourself and I, it really does. Yeah, so just a couple of a few reasons that. Kind of just sparked in my head as far as why good documentation is important, right? It's and these are no sort of order. Just what comes off the top of my head. Like it's a single source of truth, right? So everybody knows, okay, this is the platform we're using. This is what is happening. This is how you actually, this is how you work it. And it's gonna be updated to the best of everyone's abilities, that has access to said. Platform. Like I said, single source of truth, it prevents like random docs and random, knowledge bases and all this crap that just like all over. Right. And by all over, I mean, like, over multiple medias. So like, different map drives or, people's one notes or if people use a, use a task program like a Trello or an Evernote, or, something that keep them, on their day to day stuff, like, they write notes in there and that's like, oh yeah, that should come out of there and go into a centralized, database somewhere. So, it prevents a lot of. From just being scattered all over. So, if somebody's looking for it, mainly when I say somebody, usually it's the boss that comes looking for said thing, because something broke and something, some process wasn't followed and then the boss comes and goes, where's that written down? And you're like Here it's like some local notepad and the boss like shakes his head and goes, oh, it's one of those things. So yeah, stuff like that, single source of truth, which I really like. But the problem with that is like, if you have a single source of truth, everybody in the department has to be on board with. Making that the single source of truth. Cause if you have 10 guys in here to pretend, guys gals in your department and only two of them are using it as an actual platform and actually putting the time and doing something, then it doesn't matter. Cuz those other eight are making changes on the fly. Nobody knows what the hell they. I've had that. Right. I've had that happen all the time. So like, it almost has to like the documentation thing has to come from the top down and be like, look, this is what we're doing. Everyone is on board. No questions asked or else it really does fall apart. And people just do what they want anyway. And that's why documentation suck so bad. Cuz everybody just does what they want. It's just this mush of, eh, whatever people kind of scrounge, which really does make it suck. And the other part of that too, I think Kyle you have a couple here which I really liked it's, the hit by the bus theory, right? So prevents one person from holding all the knowledge, or. If that person gets hit by a bus or whatever, then you know, you guys are the company's screwed. Right. You don't know what this program is or what the logic was behind building, said whatever.
Kyle: 6:37
Yeah. And I mean, that, that could affect anybody, small companies, big companies, but especially like you're running a real small crew and you got one guy or two guys that do the network or CIS admins or something like that.
Pat: 6:51
yeah.
Kyle: 6:51
Something happens to that person. Nobody has any idea, really, like what's going on or where to even pick up to like try and fill in that role to, to do any of those tasks. It's just like, and our hands are tied and we don't know anything, just lost.
Pat: 7:06
So then that takes the rest of the team. However big that team is X amount of weeks. To actually dig into that and get back to where they started. So it's like that person was, hit by a bus most of the time that person leaves for another opportunity. Right. hit by a bus is not a literal statement, but you know, it sort of sets everyone back a couple of weeks to kind of catch up to where that person, if that person would've just documented what they knew and did a, decent handoff or whatever then you'd be a well oiled machine. You just, okay. That person's go, that person's leaving and, next up and we will kind of take the reins until they hire someone else. So, yeah, so I, the documentation platform really helps with that as far as everyone's on the same level, as far as knowledge. And, but you know, the other thing too is like, Documentation. It's one of those things where you get out of it, what you put into it. So if you don't put a whole lot into it, obviously you're not gonna get a whole lot out of it. There isn't this magic button that you hit and it goes out and like scours your entire environment for all the bits and pieces that you could ever imagine. Like, there is a lot of manual work involved in that. And again, you have to have everyone on board on your team to really make that, make that unicorn work. If you.
Kyle: 8:21
Yeah, definitely. And keeping it up to date too, is another thing you. Some sort of version control maybe, or, collaboration like, Hey, we changed X, Y, Z, make sure you update the documentation. So, it reflects that.
Pat: 8:37
Yeah. And and there's some real legs out there to people, it's probably a little more niche at the moment. I don't know if it's ever gonna get. A little more broader, but you know, people really use, GitHub for their version control of whatever right now, GitHub is a software developer's, playground, if you will it's mainly, it appeals to software developers and they write their code and, put versions up there and, whatever, but you know, like Kyle, I think you said I think you said a few weeks ago that you have a buddy that, that does GitHub with his resume. So like different versions of his resume, which I thought was a really cool idea. So if people can do that, then why couldn't people do documentation as far as that, and then, GitHub it as far as from a revision, standpoint. So, I'm relatively new to GitHub. I, to me not being a software dev, I find it a little confusing as far as how things roll and, push and. Get and all that kind of crazy stuff. So like there is, to me there's a learning curve to it, but you know, maybe to someone else it's not it's just one of those things where you're just like, oh, okay. Yeah, whatever in certain circles, GitHub works very well for depending on what your environment is and what you're trying to, to accomplish. So, just keep that in the back of your mind as well from that standpoint, and then Kyle, I think it also documentation also helps from reinventing the wheel. And we sort of talked about that a little bit, just a few minutes ago, but you know, again you're. Whatever you can reuse in your documentation, do it. Why create it four different times for four different pieces of documentation out there. So, don't try to reinvent the wheel. It just, it doesn't help. Documentation can really help with that. So whether that's from like a knowledge based article perspective, so, okay. Look like, say you're a level three tech or whatever, senior, whatever you're gonna call it. You write knowledge bases for the folks that are, level one level, two help desk. And, know, depending on what the actual issue is, you say, okay, look, make sure they have a doc that they can. That they can reference to, to say, okay, look, I've had, this is the issue. Here are some of the things that could be the resolution here are said steps to, some of those things, that sort of thing. And you could have issues that are very similar, so steps. If it's a 10 step, fix and one through five are the. It only really differs when you start at steps, step six, for whatever issue, reuse one to five in however many documents, you need to reuse it in. Why kill yourself with trying to do individual. Knowledge bases are pieces of documentation when you can really reuse a lot of that reuse in some of your code and some of your some of your jargon. So I feel like that's good as well. Kyle, there's a couple other things on here too, that you kind of jotted down, so I'll kind of let you take the wheel here and see what your thought process is.
Kyle: 11:18
So I had some duplicate work. Could have multiple people doing the same thing or working on the same thing because they don't know cuz there's no communication, there's no documentation of expectations or what's already being completed. So, then you just end up essentially wasting time, cause you got everybody doing the same job and, or like, like you even said, like the steps one through five kind of deal like that. You may already have a solution on that sheet, the documentation. So you don't have to start right at the ground level and troubleshoot your way up. It'd be like, oh, you have this error message. Well, that typically is, this problem, follow these steps and you're already done.
Pat: 11:58
Yeah, exactly. Yeah. The
Kyle: 11:59
instead of a half an hour worth of troubleshooting, it could be, three minutes of here's an instant answer for.
Pat: 12:04
right. Yep, exactly. Right. I feel like that's a good point with, you, you just need to keep. Keep it on paper. Everybody knows where it's at and then reuse as much as you can. So there's, so if everybody's pulling in the same direction, cuz with documentation, if you have, if you, like I said, if you have 10 people on your team and everyone's pulling in a different direction, then nobody's getting anywhere. It reminds me of like, everyone's hooked up to the same bungee cord strap, and everybody goes in a different direction and you all end up right back in the middle it's one of those things. So make sure there's a clear, concise way of, or agreed upon way to do documentation and move forward, in that aspect. So then you're not duplicating work and you can, like I said, reuse what you can for that the next one I'm gonna kind of. Talk about as far as, cause this, I have a story with this, but it can, documentation can really help with. Right. So I feel like onboarding is a, I don't wanna say a buzzword in today's world, but it sort of is right. So everybody prides themselves on onboarding and, oh, look at this and we send you swag in the mail and and, or, Hey, here's a shiny picture to put on your LinkedIn and all this stuff. And it's like, okay, it's all great. But like, what happens when you're three weeks into the job and there's a fire and people are looking at you to fix something, you. Crap. I should have, I should have looked at some documentation that probably would've helped, that kind of thing. So, which is great. And just another side fact of that or side note, everyone focuses on onboarding, but nobody really focuses on onboarding. So like when you actually leave, nobody really gives a shit. They're all like, yeah. Your last day is, next Friday we'll go out for pizza and that's it. Like, it's like, okay, like, and I feel like in today's world of, oh yeah. Onboarding and look at this and we're attracting talent and all this stuff and yeah, that's great. But if you have people leaving and you don't know why they're leaving do, are you really doing. Yourself a service. No, you have no clue. So like the last couple jobs I've had, actually, I don't think I've ever gotten an exit interview at any of the jobs I've ever had. Heck some of the jobs I've ever I've even had HR never even reached out to say anything like, Hey, your benefits end this last day, or Hey, your last paycheck is blah, blah, blah, nothing. So like. You're only really as good as you're off boarding. Cuz if people are leaving in droves and you don't really wanna know why you're really not in it for the long haul so, or you're not, it's not in the best interest of set company, but maybe that's another discussion for another day. But no onboarding, I think is I think onboarding is super important with documentation, cuz it can help, rest some of those fears of, oh shit. Like, am I gonna jump in with two feet here? I better have some documentation to sort of catch me and get me up to speed personally, when I've started a job. I do two things I should say I do. I do one thing in two different parts. When I first start a job from a network perspective, I make a layer two diagram, a Visio for the entire network. That includes, like I said, a Visio with ports and VLANs and, all that kind of stuff as much detail as I can get on that Visio for layer two. And then also I make a layer three diagram as well for the entire network. So that includes IP addresses routing info, whether they're using, O SPF or any sort of routing protocol. Writing that down interfaces with IPS, static routes, anything like that. I try to make a layer three diagram, so that way that serves two purposes, right. That gets me up to speed as far as okay. If I can document this network, then I have a little better grasp of. What's happening. And if something does break, I'm not starting from literally, ground zero, right. Maybe starting from floor two. Right. it's always better than nothing. And then secondly, if there is no documentation like that exists, you basically just. Made a new friend with the boss and now they have documentation that they previously did not have. So it serves multiple purposes to really get in there, get your hands dirty take a half hour, whatever it is, or half a day to really document your environments, especially the stuff that you're gonna be working with. Right. The core stuff, right? The network, right. Or, in my case, the network. So, a layer, two diagram, a layer, three diagram, boom, rock, and. And it, like I said, serves, multiple purposes, but I would consider that part of the onboarding piece of it. Onboarding, whether that's yourself or, if it's given to you, great, you can tweak it to, if it needs more detail or, whatever. Or if they have one, just go over it again, jump into those pieces of gear and kind of follow it and trace it and make sure the diagram's up to date. Right. Cause if they hand you something that could be a year old, right. So it doesn't hurt to, fact check them, quote unquote for that reason. So, I always think that's important that kind of goes with training there too. Did you have anything else here for like training Kyle as far as, from a documentation perspective outside of like, Hey, there's a change control call every Tuesday or, Hey, there's, we meet as a team every Thursday or, things on HR. So from as far as like a training perspective any other sort of detail there.
Kyle: 17:11
I know at least that my. Previous place of employment kind of deal like that. We did a lot of work, not we, but the programmers and stuff like that, did a lot of custom integrations and custom programs and stuff like that. So, having documentation to kind of understand how it works and stuff like that was, priceless, cuz it's, you look at stuff and you're like, I have no idea what this does or. What to feed into it to get back results or anything like that. And, just with good documentation for that, it worked out perfect.
Pat: 17:44
I think that always helps to be honest. I think the more of your internal department processes you have written down, I think helps from a newbie perspective, not trying to have that overwhelming feeling of, oh my God everyone's in this, department's been together 10 years and I've been here three days. What am I gonna do? It's one of those they're like, oh my God you're sort of swimming information. I think that's a good one. The preventing errors, right? We talked about that as far as, duplicating work and making sure everyone's on the same page, prevents confusion, right? So as a newbie, right, as somebody working in, walking in there, fresh as a Daisy, if you will, and ready to conquer the world it can be confusing if you're walking into a place that has zero. Documentation. And I've walked into places that have next to nothing. You're like, oh my God. and then you have this like overwhelming sense of dread that you're like, I'm responsible for all of this documentation. So you're like you have this rosy idea of what you want this documentation to be, but you don't want to be the guy or gal actually doing said documentation. at least for me, I hated it. I hated like, oh God. But I, like I said, it is good. In, in that aspect of it prevents, confusion saying, Hey, look, this is, and I don't know, like if it's, I really haven't gotten. Like I haven't gotten to this spot yet, but maybe, twice a year, maybe once a quarter, depending on how busy you are or what's going on, like, dedicated day and say, okay, look, I'm gonna, at least, if you're looking at Vios, right, say, Hey, look, I'm gonna go through all these vis and make sure this is. Good Intel, right? I'm gonna make sure that, or if you're ha if you have an IP spreadsheet, right. That, tracks your IPS and what devices are tied to IPS, like go through it and say, okay, look, I'm gonna take a half a day and, really make sure this is up to date cuz you know, honestly with. People moving positions or company moving in another direction, right? So maybe going from on-prem to cloud something changed and it wasn't touched, right. That could be a big eye opener as far as from a difference, perspective Yeah. Things of that nature. So I think that's that's always good as well. Don't underestimate the documentation piece of it from a vendor perspective as well, right? Say, okay. Look, my big, my three big vendors are, Cisco, VMware and Microsoft. And, we talked to Nick Townson, last week and she said, everyone, you get an account manager tied to you. Technical people tied. You make sure they don't change either. Right. Cause those companies or those vendors, those people change like, like crazy. Right? So it feels like every other week you're getting somebody new cause people shuffle around. So, update your contact list as well. Or at least, like I said, once a quarter or whatever or reach out and say an email and say, Hey, are you still here? Or, cuz I've. I've had places that, we had used a vendor now, whether that's, an actual like hardware vendor or like, like a CDW or Shi or, you one of those partner levels and our account manager changes and we had no idea. Right? So it's one of those things like, all right, you gotta make sure all those people are accounted for and all your predicaments. Cuz if something goes down, you need one of those people and you send an email saying, oh my God, I got a fire. The worst feeling in the world is getting a bounce back like, oh, this email doesn't exist anymore. Shit. I've had that before and then you're
Kyle: 20:55
Yeah, when you gotta play. Musical chairs. Like somebody gets promoted or moves apart or departments or something. And you'll like email 'em and they're like, oh, I don't do that anymore. Or I'm not your region, like whatever. And then it's like, let me forward you over to the new person, and then you're wasting time with like, Hey, I don't want to not do introductions, but at the same time, like, I have a fire and I need to put out like now.
Pat: 21:18
Yeah. Ex exactly right. I feel like that's a big one too. The other thing I feel like too and this is really sort of getting in the weeds, but I would track your track, your circuits, right? Your actual, your internet circuits. Right. So from a, whether, it's easier to attract them in the data center cuz they don't change as much as maybe, like a branch office, right. That's just out there, flying in the breeze, whatever. Yeah. You change whatever. Data center, circuit's a little more sturdier or steadier I should say then something maybe a branch or if there's multiple vendors at a branch or ISPs at a branch, you may go from one to another and. Somewhere that got missed. Right. So, I would document circuits, circuit IDs, again, like a knock number for them. Right. So like an 800 number, usually mill these vendors have an eight. Knock number. I would do that again, if you have an account rep, to that or, if pictures are another good one, right? If you get pictures of, the at and T box hanging on the wall, that usually has a circuit number on there, or. Some sort of N number or handoff or, that sort of thing. Update those as well. Cuz I mean, that's happened quite a bit, a branch changes ISPs you go from at and T to Comcast or whatever. You know that's gotta be documented up updated to your, in your centralized whatever platform that you're, that you're using. So that's a big one there as well from a circuit perspective.
Kyle: 22:32
It's a good, that's a good point too, with. Companies buying other companies and stuff like
Pat: 22:38
Oh yeah.
Kyle: 22:39
No, we've definitely run into that. Like this used to be whatever, and then they were acquired by this thing and then that changed hands. And now it's this other company bought, that and
Pat: 22:49
Yeah, it's wild
Kyle: 22:50
who do you reach out to? What, like,
Pat: 22:52
right there. Again, people buying companies and whatnot.
Kyle: 22:56
That's a good.
Pat: 22:56
People buying companies, then you get a new account manager, you get new technical people now. Cause you could fold it in, to, to the bigger conglomerate. Right. I had that with lumen or yeah. Now lumen used to be CenturyLink. When they bought level three, And even further back when Verizon bought XO communications, that was another one. Right. So, it's one of those things where like, okay, you had all these account reps and whatnot, and now they've been sucked up into the big boys. And now you're like, oh man, I don't know who to talk to the big boys. So, get that stuff straight. And at least and most vendors or account reps, like when you reach out to them and say, Just checking in, see whatever. Cause then they're like, oh yeah, maybe he needs something. Maybe there's a sale there. That kind of thing. I've had that before, yeah. So just kind of check in on them and then from a network perspective and again, I know Kyle, you and I are network people. So this may not for everyone, depending on what vein you wanna be in, but from a documentation perspective of circuits, I normally put the circuit ID. And some sort of description right on the interface description, say, okay, look, gig zero is my public interface that's handing off to at and T put the circuit ID right into the description. Now I have that down. Oh shit, what is that? Oh, that's my outside. People do that on the land side too, say, Hey, look, this land port goes to, 10 gig, whatever on the core switch, that kind of thing. So document as much as you can from a actual physical gear perspective when you're in the, when you're in the piece of gear and from a VI perspective. So then, if they match up you're, 95% sure that's true in, in, in that case, so just little ti tidbits of that kind of stuff. A documentation can really go a long way because if if something goes down at 3:00 AM and you got one bloodshot eye, you are not trying to dig through, different network shares and maps and trying to find what the hell's, what depending on what industry you're in, you could be losing boatloads of money by the second. So you're like, oh boy, this is, yeah. You plan you build your documentation for when you don't need it. That's sort of what my mantra is. Cuz again, if you're you get woken up at three, am it better be for a good reason? It usually is something is down or, some sort of VPN went down or some bullshit and you're like, oh no, where's that circuit. You don't wanna be searching for a circuit or any sort of easy layup information at three o'clock. That's just not a good time. Not a good time, especially the
Kyle: 25:13
Especially, like you're saying if you're, setting up an interface in the first place you. Tagging it doing whatever. It only takes like three more
Pat: 25:21
Yeah. You're already in
Kyle: 25:22
while you're
Pat: 25:22
You might as well
Kyle: 25:23
just throw. Yeah. And like if you have to go back and do it and you're like, I gotta do, 96 interfaces and like, that sucks. But if you're doing, when you're setting it up, just do it and you'll thank yourself later. And you'll feel like the best coolest guy on the block when you're like, my documentation saved the day.
Pat: 25:43
that's right. I go buy me a beer cuz I fixed it in, in, in 10 minutes versus an hour in 10 minutes. I would've had to search an hour for some bullshit.
Kyle: 25:54
right.
Pat: 25:55
Yep. Been there multiple times. Yeah. So just a couple things on that documentation piece of it. Also too, I just kind of thought of this From a vendor perspective, right. Or even from internally, like what does your escalation path look like? Right. So Kyle you and I are sort of at the bottom of the chain or whatever, you know what they say, shit rolls downhill. So you know, you and I are at the bottom and where the guy, we're the guys pumping and, Slamming the keyboards, but you know, say, okay, look, I bang on this an hour. I, I don't know what the deal is. I have it sort of, kinda narrowed down to an ISP issue or whatever the case may be. Have an escalation path for both your internal company wise and whoever you gotta get ahold of from a vendor perspective, have the escalation path to them as well. Cuz it could be sometimes that that your account rep or whatever is on vacation and we all know. These vendors don't do the best of, doing like a warm handoff of when they go to Disney for a week on a vacation of what could go on at their accounts. So I only have one way in one way outta that company. That's my account manager. So if again, if he gets hit by a bus, oh shit, what do I do? It's like, oh, so I would have, or at least, you may not. Right away, but at least strive towards getting an escalation path from a vendor perspective. Cuz you're gonna need it at some point. You're gonna need somebody above that account manager and you're not gonna know who the hell you're gonna talk to. So I would, get it both internally to let your people know, Hey, look, this went out at this time. I tried this. Here's where we are. Here's what I think it is. So that way then, they can go to their uppers or however many levels of management that you have, they're all in the same loop. And then, from a vendor perspective, try to, UN unravel that. Spider web that it could be depending on who you're dealing with. So I think an escalation path is a good one to have as well. Again, pick whatever platform that you want to use from a documentation perspective or whatever one they have, right. That most companies in you roll into it. They have some sort of documentation platform now whether how, whether, how good it is or not, that's a different story, but but if they. Hey go, go out and look for one. So, I don't know, Kyle, have you worked with like multiple documentation platforms? Like I've worked with a few. I don't, I'm just kind of curious on which ones you, was it something that was homegrown to where you were at or did they take a flyer on, on, on something that was either like open source or a paid version or.
Kyle: 28:16
Actually, when I, well, previous place, when I first started, we just had a binder I mean, that was it. A three ring binder. And you would just page through like, oh, here you go. Like, with some screenshots and stuff like that, it It wasn't the prettiest,
Pat: 28:30
Oher.
Kyle: 28:31
it did it at least got the job done. It was something
Pat: 28:35
L is for load balancer. Oh no. Oh, that's under C for Citrix. Oh shit.
Kyle: 28:40
Right.
Pat: 28:42
yeah, no, I've been there. I've used a few. I think now. I think a lot of the ticketing systems have a documentation platform that's being built into them. Like, for example, we use ServiceNow and I've used ServiceNow for the last, like three or four jobs that I was at. They all had ServiceNow and ServiceNow has a CNDB or central data central. Something database CMD, I forgot what the M stands for, but DV stands for database. So, centralized, managed database, I think is what it is, but yeah, so they, people now. Okay. Look, we're already using service now for, ticketing purposes, change management. Problem management or problem tracking incident management, things of that nature. So people are weren't, knowledge base, right? When I was when I was at reneg hill, they used it for knowledge base as well, KB articles, they used to call it, but. Now they're sort of baking in, that's all part of your documentation, platform. So, people just usually stick with what's already built and then you just kind of throw, throw things in there and, then your visios and whatnot, they sort of live in their own world. But, most people now, most platforms now, ticketing platforms, whatever, have a documentation piece built into it. And it's just easier for people to kind of go to one place, right. Tickets and documentation, all in one. One gooey. So, doing that I, but before I've used I've used JIRA before at at one place that was okay. It really JIRA's one of those things where it was sort of new to everybody, so nobody really owned it. So it was just kind of like. All over, like nobody had any sort of like structure to it. We just kind of dumped stuff in there and it's like, oh, okay. So like, yeah didn't have to spin J up for this. You go and get JIRA for the structure and then you don't do any structure with it. And that sound seemed kind of weird. So I've used JIRA before that was, like I said, that was okay. I wish I knew more about it at that time of life, but originally JIRA was used for a bug in like an issue tracker, but recently it's grown more into like a work management tool, sort of thing. So I think it's a little more rounded out and I used JIRA probably oh, geez. Probably like a good 6, 5, 6 years ago. So that's probably. If I looked at JIRA now, I probably wouldn't recognize it But at that time when I used it, it was more for a, like I said, like a bug and issue tracker. But I hear from the interwebs that it's kind of grown into this work management tool, I'd be curious to see what it looks like again. Right. So, that's an option from a documentation platform perspective. I guess you could do a centralized like OneNote, right? So if you're a Microsoft shop anyway, use, one note is already out there, you're already kind. And I do now. I use it for, I use it for like more of my own personal notes kind of thing. If we're looking at something new from a product perspective and I go out there and, watch a video on you to me. Whatever one of those training platforms and I'll take my outline style notes and put it in one note. Right. So it, so it's there locally and I can, get back to it. Or I've known people to use one note for their for like budget items, say, Hey, I want this. Or, Hey, I'm, whatever, Hey, 20, 22 budget, 2023 budget, blah, blah, blah. So it's more of a personalized thing, but if you, I guess you could use one note for. Across an enterprise. I don't know how well that would scale for some of the larger organizations out there, but it is decently structured and it can be used with that. Definitely. It can be used for small teams. I don't know how, like I said, you start to scale and start to, get a lot of people in a room. If one node is the answer from a scalability perspective. But I think it works for a small. Kind of just jotting things down and, screenshot and all those things that one note does. Right. You could certainly do it that way. So, net box is another good one. Currently I'm in the middle of a net box project. I actually brought net to where I'm at now. so, we're documenting all of that. Our old IPAM was was end of life. And so they needed to either, upgrade what they had or get onto something else. And I threw NetBox out there cuz I was sort of keeping an eye on NetBox for a while. And I could never quite get the places I was at to really like go in, go all in on it. It was one of those things where like, I liked it a lot, but I was the only one that really like, knew about or wanted to take the time to know about it. So I was pushing the rock up the hill by myself. so, and usually when you're doing that, you don't get very far. So, But no they liked it here. And I, it's been implemented about a month and it's, it is a lot of work depending on your environment. Now NetBox is like a network documentation platform. That's pretty much all it does. So it documents, devices and individual IP addresses, subnets rack diagrams circuit inventory things of that nature. So it's very network centric. So you probably would need another platform for other general documentation purposes, but from a network guy's perspective, NetBox is awesome is it's really cool. In all the stuff you can do now, it's all manual input. So you can like, it does CSVs, like you can import CSVs and things of that nature. But a lot of it's manual input to really get the most out of NetBox. You really have to put a lot of time into it. So depending on how big your environment is, it could take you, couple days it could take you a couple months. So it just depends on the size, your, of your environment, cuz it, it is very manual. Intensive. It's one of those things where, you get out what you put into it, sort of thing. But if you have a clean slate from it, build it right. Cuz it's really gonna help you down the road. So, I like it. I vouch for it all the time. It's open source. It is it's a brainchild of a guy named Jeremy stretch. He used to work at digital. And then I think what happened is he was like, ah, man, there's gotta be a better platform out there for, network documentation, things of that nature. And he sort of like just started programming this on his own and it kind of took a life of its own. And now he's like the sole, kind of developer for this NetBox, it was his brainchild. So, So, yeah, so, NetBox is out there as well. There's a whole good hub community out there for NetBox, which I'm really finding really useful. So as I build this stuff, so, so what happens is, so you can actually keep track of devices as far as like down to models. So like say you have a Cisco 9,300. P right, which is, I think is the Poe, 48 P the Poe version of that particular model. And if you go on net boxes, GitHub, there's people there that have all this, the community sort of come together to put some of the more common devices together, and they put 'em together in a Gamel file. So basically you would just copy and paste. Look for your particular model, copy and paste the Yamo file from the GitHub, and then just import it into net box, just copy and paste the Yamo file right in the net box. And it builds the whole model for you. It gives you all the interfaces. It gives you power, ports and console. It builds it all. Otherwise you'd have to do it by yourself, right? If you didn't have that ammo file. So, I'm really leaning on. The the GitHub community in the last couple of weeks to really kind of get, models and D device types know, kind of ironed out. Everybody's interested in a demo it's demo.netbox.dev. And I'll put that in these show notes for this week. And if you log in it's admin admin. So it's just a, it's just a demo out there that you can kind of fool around with and get the full power of it. But it really is really cool. Like you can. You can track your VMs, your virtual machines in there. If you have clusters or anything like that wireless is in there. You can do wireless lands and all kinds of stuff. Organization from an organizational perspective. So sites and like I said, racks, if you have different tenants. So if you're a, if you're a holding company at the top and you own a bunch of smaller companies at the bottom, each of those could be a tenant, right? So you kind of break it out in that aspect. Again, we talked about contacts and contact groups, things of nature. You can throw that in there as well. So it's very, it's a very network centric. And then also it's very API heavy as well. So say again, say your company is on ServiceNow, right. Or you're using a monitoring system. Right? So the popular one out there now is logic monitor, right. For a couple, couple different places. I've worked to use logic monitor. So, say you're using that and say, okay, look, I really like working in NetBox cuz you know, that's the single source of truth. Everybody understands that and knows that's what's gonna be used. Then you can basically just do APIs API calls from either ServiceNow or from logic monitor to your, to your instance of NetBox. And it pulls information. You don't have to replicate it in three different spots. You do it, you input it in one spot and it replicate. To however everybody, wherever you have an API calling from. So that's really cool there as well. So again, if you wanna do a demo on it, I highly recommend it. It's demo.netbox.dev. And again, we'll put that in the show notes. So I dunno, that's my little Ted talk on NetBox only because that's been a little project. that's been a project for me for the past, like almost month and a half I've been trying to, and it's still not done. It's just it's we just have pretty large environment. So trying to get as much as we can down. Nitty gritty and everything in one particular spot. So yeah, NetBox is pretty cool. The other thing that's out there too, more, a little more rounded. It glue I hear is a popular one. I've belong to a couple. A couple different groups on Facebook, like it centric groups and people talk about it, glue a lot all the time. They really like it. So, that's another one as far as from a documentation platform. And then Last, but not least, at least for me confluence I've used confluence as well. The same place I used JIRA at. So they were, I think they were together at that. At that point, confluence in JIRA, they were the same. They were they were kind of a package deal if you will. And confluence is more for like the documentation, piece of it like writing knowledge based articles and, tructure. Procedures, pro process the procedures and things of that nature. And then JIRA was the other side of that from a documentation perspective. So again, I think it was a little, it was one of those things where like somebody told the boss that, Hey, we should be using JIRA in confluence. And the boss was like, yeah, sure. I don't anything about it, but sure. And we all were sort of stuck with, stuck with this stuff that nobody really signed up for. So, but I'm sure these programs have come quite far. And if you're already, it you're a fan, then confluence should not be new to you cuz that, I think that, like I said, they go hand in hand, but if you take the time to learn them, I think it really it does well with that. So, that was kind of it from a document documentation perspective, the good, bad, the ugly causes you anything else to add to this? Do you have any other notes there that you wanted to mention?
Kyle: 38:49
That was a good point about the ticketing software. I didn't actually think about that as the documentation source until you said it. I was like, oh yeah, we did. In fact use that, especially. you put resolutions in there when you close the ticket
Pat: 39:03
Yep.
Kyle: 39:03
and you can go back and look at metrics and you can be like, well, we have, every week 17 people call in with X, Y, Z problem. You could put it in there as a solution. You could put it in there. So somebody doesn't have to go through, again, those first five, six steps every single time to get. To that point, you could just be like, oh, you got this problem. Here's the answer, boom. And now you just saved yourself a whole bunch of time and don't hoard knowledge, Sherry, everybody needs.
Pat: 39:33
Sharing is caring. That's the motto nowadays, right? no, I think that was good. Like I said, documentation, isn't the best, it's not the most exciting topic, but it can be really useful if you do it. Right. Most people don't do it. Right. Cuz they think it's a pain in the Dick, which it totally is but you know, it's like one of those things. No, it's not fun. It's terrible. Yeah. It's just one of those things. So, but we feel like it, it needed some time in the limelight to get this to get it out there and, break the stigma. That is documentation. Right. Just trying to figure out which one's best for you. And, but like I said, most of the time, when you walk into an environment, they're gonna have something. So, just kind of be prepared for that and see how you can use it to your advantage. To your everyday, day to day job and, do some of the easy things right off the bat, cuz it'll make your life easier. Down the road again at 3:00 AM. You don't wanna be searching for a circuit ID, right. When something is down. So, do it now while you have the time and you typically, you wanna do it before it's a fire. Right. So however you fit it into your schedule, do it before it's an actual fire. You'll thank yourself later. So, that's kinda it, Kyle, anything else from you?
Kyle: 40:40
I mean, just gives me flashbacks to, being in Kevin's class and him standing over a shoulder and just be like, just remember guys document document. It was like every day
Pat: 40:51
shout out to Kevin. Who's supposedly coming on this podcast in a few months. So we'll see if he shows up. Yeah. Now Kevin was our Cisco instructor back in our college days and we, Kyle and I spent a lot of time in that room. It was in the basement. If I'm not mistaken.
Kyle: 41:06
it was
Pat: 41:07
little windows and, it's just, I don't wanna say a dungeon cuz it did have drywall up, but it was close to a dungeon. Yeah. It's not there anymore. Right Kyle,
Kyle: 41:16
step up
Pat: 41:16
He moved
Kyle: 41:17
now they got, yeah. Nice bright colors windows, you know?
Pat: 41:22
man, these young kids, I got it all, man. Lemme tell you, we We had the security guards stop in us, stop in and open the door every once an hour to make sure we were still alive. And now these kids get bright colors and sunshine and in their windows it's like, oh man, where was that? I could use some of that when I was, knee deep and whatever we were learning. But no that's a good point. Yeah, it was funny. I don't know if you were in that class, Kyle, the way they did it at the college of con I went to way they did it was four. I think it was four semesters which technically was like it was over two years. Right. And so that should have been your two year degree, but it was four semesters. So you had like, and they numbered him. It was like CCNA one, two. I think they did three and four together. Kyle, at least. At least when I was there, they did three and four together as one semester. And then they did CCMP one as the fourth semester to sort of round you out into those two into those two years. But I think it was like CCNA two. So we were all still sort of green in as far as like, okay. Like, cause CC one was very theory driven. Like you didn't have a whole lot of hands on lab stuff. It was very theory. Like here's the subed, here's how you subnet. Here's a, seven layers of the OSI and all this crazy shit. And you're just like, oh my God, all this theory, my head's gonna explode. And so like it was CCNA two, I think semester two, we were really like, he really. Unleashed the beast sort of thing, and like powered on routers. And we actually sat there with a console cable. We're like, all right, now we're getting into some good shit. This and that. And I had classmates, I can't remember who they were. But I had classmates that we were like, we were working on like routers and like, we were working on like password recovery stuff and they totally. Bombed it, like they made a mess of it. And like, even Kevin, like couldn't even like back out and like start it from scratch. They had it in like, like Ramon mode where like nothing booted, like couldn't find like a boot file, like nothing. And Kevin's like, What in the world did you do? He's like I got other classes that's kind of use this stuff. it's one of those things like, but like, yeah, like you got but you gotta document the whole way. So if you were to put that in the steps and document, and then nine times outta 10, you could work backwards. Right. And sort of get back to a fresh slate of glass, if you will. But like, yeah, it was like two or three people. They were, we were in groups and the one guy goes oh, I think I messed it up. And Kevin walks over and like, Kevin's over like a half hour. It's like banging on the keyboard, trying to get this shit to work. And it's like, nothing's working. Oh my God there, forget that. It's like, oh geez, look out. But Now a good time. So shout out to Kevin. I think he's gonna be here in the next few weeks he's very into kayaking and doing that thing. So he's on the water, quite a bit. Kayak, ski, skiing, that kind of stuff. He's all into it. So, once we can pry him away from yeah. Once we can pry him away from nature, then we'll get him. We'll get him on here. so, I think that was it for me. Just a quick note, before we get outta here go check out last Friday's episode of packa pushers, heavy networking. That is the 29th. This just this past Friday. I was on Packet Pushers with Ethan Banks of Packet Pushers fame. Who's got, they have. Biggest podcast, tech podcast platforms going right now. So, I was on with last Friday on his heavy networking podcast and talking the differences between a an en an architect and an engineer. So as far as from a network space. So if you're interested in that, go check that out. It's uh, packetpushers.net I believe it is yeah. packetpushers.net is where you can get that or anywhere, from your favorite podcast app or wherever you get your podcast. So, Ethan's a real cool guy go support. Those guys are really cool. A lot of knowledge over there. So, it was nice to be on, to be a guest on one instead of hosting it and driving. So that was always refreshing. So go check that. That being said, we're gonna get outta here this week. So right around that hour, mark, like we like to stick around. So. Thanks again for joining this week on breaking down the bites, make sure either visit our website, breakingbytespod.io it's right.io, not.com. We're trying to be like the cool kids. You can subscribe to the show in iTunes or any of your, one of your favorite platforms, right from there? Stitcher, Spotify or just an RSS. You can get it there as well. That's just as cool. Throw us some radio on iTunes. That'd be awesome. Plays the algorithm I St I think, and gets you to the fresher news section. More eyeballs and more friends. We always like more friends, right? Or speaking to friends, simply tell a friend about the show that works just as well, word of mouth in this heavy tech driven world that we live in. So, again, follow us on Twitter. I'm @layer8packet that's the number eight. Kyle's @danath256. We have a LinkedIn page now, which is new for us. So https://t.co/ZHBzeutv0o getting a little following, a little traction on there. It's not just gonna be for, Hey, we have a new episode. There's gonna be actual content on there. So. Once I get in gear, I'll have my layer eight packet.io blog up and running. So, I gotta get in gear for that. So, we'll be sharing that on LinkedIn and just the articles that we find interesting that would appeal to everyone that listens. So that'd be awesome. Facebook.com/breaking down the bites. We're there too. Invites in the show notes for the discord server again LinkedIn is new to us. Come say, hi we like friends on there, so that's gonna do it, Kyle. Awesome. As always as usual, another rock solid episode on documentation. So appreciate everybody stopping in. Give us a shout out on Twitter. Come say hello, email. breakingbytespod@gmail.com. That's always monitored inbox as well. You'll get it right from Kyle and I that's it. We'll see you next week for a brand new episode. Bye everybody.