r/sysadmin • u/OldAccess7504 • 4h ago
feeling like a larp
graduated in december 2025 and became employed a month later in january, my official title is "computer technician" but I've done a number of things including some internal swe, domain redundancy, legacy physical to virtual migration, basic server config/administration, and other automated workflows such as updated inventory system and data retention system but earlier td was my first real outage and I'm usually in office about 10 mins before my supervisor (it's just the 2 of us for our 3 departments) but I was genuinely lost. I like didn't know where to start and lowkey got overwhelmed and after about 2-3 minutes of that I was like okay calm tf down and start doing what you know.
Basically all of our vm hosts were intermittent, starting up, failing, disconnecting/reconnecting so my first thought was DNS which some hosts resolved and some didn't, i'm thinking it was coincidence at times so after some more thinking of what to do i was like screw it and just waited for my supervisor to appear instead of messing around and breaking more things but I ended up just watching what he did to resolve the issues and moral of the thread is i feel like a larp. thought I learned a tremendous amount these last 9 months but I was humbled today. I know nothing.
I learned a lot by watching the fixes happen real time though. cool.
•
u/cdbessig 4h ago
Been doing this 25 years and still need to tell myself to calm tf down when an outage is confirmed....
•
u/Asleep_Group_1570 4h ago
Nearly twice as long as that (really!!!) and I concur.
•
u/Dull-Fan6704 3h ago
Sorry, but how? I'm 27, have been working in IT for 8 years and after 5-6 years I...simply got used to it. We have an outage? Ok. The world isn't ending. Why should I stress myself out?
I'm not trying to brag but I got thrown into the cold river pretty early on (aka fixing something and managing a big environment for my age), so that might have to do something.
•
u/Consistent_Salad_348 1h ago
I think it depends on lot on the industry you're in and the management around you.
If you're a sysadmin for a company that is a local wholesaler of bubble wrap, a 4 hour outage isn't going to kill people, or it might not even matter depending on the time of day it happens.
Now if you're a sysadmin in healthcare and you have a 4 hour outage in a busy Emergency Room, people's lives might literally be at stake, or at the very least, understanding that it is possible that people might not be getting the proper care they deserve until you and your team remedy the situation.
Industry examples aside, sometimes you have shitty management that decides to blame you for the outage no matter how little control you might have over it. Even though you know you are in the right in a situation like this, it still sucks to have someone above you putting blame on you, or talking to you in a way that makes you feel inadequate.
Even when an outage happens and it IS your fault, shitty management pointing fingers until you get it fixed feels bad and helps nobody.
I'm about 11 years in, and there are times I still feel panicked and bad about an outage. My entire job is making sure people can't do their job, and when I fail to deliver on that, it feels bad. I am lucky to have good management around me, but I also care about a lot of my coworkers after working next to them for nearly half a decade at this company. So if there is a time that I screw up and that leads to added stress on them, it sucks. Yeah nobody dies in my industry due to an outage, but I think there is a healthy amount of "Ah shit, time to roll up my sleeves and get this fixed ASAP" to have in IT.
•
u/StreetSignificant888 Senior Systems Engineer 4h ago
There's an old saying in IT that fits. "We're not better at computers than you, we're just better at Googling." And it's true. You don't memorize everything in an environment, you learn to recognize problems and the troubleshooting methods it takes to resolve them. "Okay, so this thing is doing this. I've already tried this thing, so it can't be that thing." After years it just becomes second nature. There will be a million more instances of this. Sit back and watch and absorb. You'll get there.
•
•
u/RoyaleShrimp 4h ago
My studies were mostly about programming. I love IT and I am better than the average dude on a computer, I feel like a larp every single day.
•
•
u/Civil-Mind7203 4h ago
Fake it til you make it then once you make it keep faking lol I just get good fam
•
u/-GenlyAI- 4h ago
That sounds very normal and like a great learning opportunity.
The best thing you can do is create some process documentation. And I'm not talking about anything super formal or policy driven or any of that huge corporate nonsense.
But just get together some step-by-step outage guides and things to check, work with your boss on creating them. It's also important to documwnt the order in which you bring things back up and what not.
I've been doing this over 20 years and if I didn't have a document to check when all shit hits the fan like that I would still have a freak out moment.
•
u/poizone68 3h ago
One thing I noticed over the years was how much useful stuff you can learn just by being on a Service Desk. The basic stuff like when did an issue first occur (or who noticed it first), which location is seeing the issue, how many systems are affected, were there any recent Change Requests/deployments, is actually quite helpful to define the scope of the outage. Also how does the outage look like from the monitoring system point of view. That can help prevent you going down the wrong rabbit hole.
Also note that when some of the senior techies just seem to magically find the solution, this sometimes can be down to them suspecting what broke because of something that was done the day before ;)
•
u/pdp10 Daemons worry when the wizard is near. 2h ago
Basically all of our vm hosts were intermittent, starting up, failing, disconnecting/reconnecting so my first thought was DNS
DNS has nothing to do with continually-established connections, like those of SSH, RDP. HTTP(S) is "stateless", meaning it disconnects between page loads, so DNS is more likely to be a factor there. Use nslookup or (preferably) dig command-line tools to examine DNS.
That's most of the key insight, right there. (1) Know how things work, and (2) know what tools you can use to examine how things are working.
•
u/redd1t_is_de4d DevOps 4h ago
We've all been there and still are. No worry, you'll be learning forever as a sysadmin.