
No.
As usual, the C-Suite want to reduce body count, and the way THEY see it is to automate EVERYTHING.
The problem is this. You NEED engineers who understand the tasks they are trying to automate. Automate engineers out of the equation, who is left to automate tasks on subsequent versions of, lets say, the O/S. Things change. Automation scripts don't automatically change with them. What worked on one version of an O/S may not have the same effect on the next. You just ran that blindly on 100 servers and screwed them up? Who's going to unpick that mess? Does your automation have a backout option? Are you solely relying on backup/restores to recover from such an event?
Does automation have a place? Of course it does. It can greatly enhance productivity when used by the right people for the right job. But be prepared for a large amount of technical debt. Someone has to maintain and test these automation scripts. I really don't think you're going to be able to log a call with RedHat bitching that your automation script doesn't work - so be prepared to dig into "reasons why" on your own.
I have had to conduct interviews, and one of the candidates, when asked how to patch a system, could only say that "they ran an automation script". Is that *really* the technical level you want to reduce your engineering support base to?