"Things get much easier if you-"You can stop right there. There is no easy way. That is the DevOps misunderstanding. To understand why, look at your car.
Your car is a complex system that appears simple. You just purchase it, put gas in it, turn a key, shift a gear, press a pedal, and it goes. And goes, and goes, and goes. But over time the tires will go bald, the brakes will wear out, you will run out of coolant and brake fluid, the engine oil will turn to sludge, and the car will break down. Past those inevitable faults, some parts will randomly fail and require troubleshooting and replacement. You have two choices: either become a mechanic, or pay for one. (Or I guess. run it into the ground and buy a new one...) Computer systems are the same.
Say you just want to "buy and drive". Ok, so you buy a PaaS. You still have to learn how to drive it. And they are only easy to drive up til the point they break down and need more maintenance. And that's just driving it...
Now say you're in auto racing (building your own high performance, high reliability system). Someone has to build the car, someone has to maintain it, and someone has to drive it. You can't build a race car without knowing how to change a tire; otherwise you could build a car that runs like shit on the track. But mechanical engineers don't generally race cars, so they hand it over to mechanics and drivers to deal with running it on the track. And in doing so, they teach the mechanics and drivers all the insides and outs of the car. If they didn't, the car would never leave the garage, much less win a race. Imagine a random Ford mechanic or your cousin Bobby at the helm of an F1 car.
People who build systems should know how to run them. However, if people building systems don't know how to run them, they must teach whoever is running them how it was built and how it works inside and out. If anything significant changes, the mechanics need to know. And if something fails on the track, or even some unexpected brake fade, the engineers need to know so they can redesign their parts.
NASCAR, Formula 1, Le Mans, etc would be completely impossible otherwise. When the cars fail, the mechanics would be constantly shouting at the engineers pulling teeth trying to figure out how to fix the car in the middle of the race. There is no time for that madness. Toyota also builds their cars by having a continuous improvement cycle between engineers, the people assembling the cars, and service technicians. Toyota has basically been doing DevOps for 70 years (if you don't know the TPS system, you don't know dick about DevOps).
When I was fixing my brakes the other day, I ran into eight different operations I need to do properly. I needed to use a breaker bar and torch to unseat stuck bolts, because banging a wrench with a hammer strips bolts (guess how I know). I needed to use a custom tool to push the caliper piston back for the rear piston, because it requires twisting to reseat rear pistons. I needed anti-seize put on the rotor and wheel hub surfaces to prevent them sticking the next time I remove them. I needed to remove the caliper slide pins, clean them of dirt, and re-grease them, to prevent uneven/premature brake failure. I needed to grease the brake pad slides as well as the caliper contact points (without getting any on the pad material). I needed to torque the bolts to the right specification (the front and rear bolts take different torque). I needed to bleed the brakes with a custom appliance to remove air bubbles from the lines. And I needed to properly bed the brakes. All of those operations are necessary to prevent failure. But if I'd never learned about all the failure modes, I would have just slapped it all together and the brakes probably would have failed soon after. (The brakes will still fail eventually, I just control how soon it happens)
There is no getting around the knowledge gap. There is no easy way. If you're not all on the same page, you can ship a new car, but it's likely to be a lemon.