I look at it differently, everything used to be hobbled together messes without real consideration for running live. Then when you go to scale, you had to redo the whole thing because it’s base architecture was garbage. This is going to sound dumb, but the philosophy behind DevOps creates an environment that encourages building extensible systems that hopefully will not require taking a fucking sledge hammer to the systems to upgrade when you get users. My role in particular would require time from a dev from each team and a SysAdmin that understands software and OS at a low levell. That is really inefficient and has communication gaps.

Most DevOps spend our days designing and coding. We are deeper into architecture than anyone else, the dev team does not even consider deployment and uptime. We have to go to each separate teams meetings because our input is needed for many decisions. I had no idea that it was like this when I got into it.

When I was a Sysadmin at a MSP, we had client with 2 main sites and multiple satellite sites. At one of the satellite locations there were two servers. The first ran a bunch of VMs and the second was the backup. If you disconnected the backup, the AD stopped working everywhere and half of the NAS storage was not reachable. As a far as anyone knew the second server was set to spin up replacement VMs if the first went down and nothing else. We were a pretty shitty MSP and never spent any time doing proactive work. So when that server dies, that company is going to have the most epic outage that will cost them a fortune.

I have been thinking about this and there are 4 messages I could receive that would illicit a similar response. I would ask if the system is down and if it is up, I have 2 people that would be forced to take the day off. Mainly because they never read any documentation throughly and can’t follow instructions.