Maybe that depends on who's uttering the phrase and what it means to them. Some points in the space:
- "Devops" as a movement encompassing the ideas that developers should not be walled off from operational realities, and that software operations tasks should be encoded as repeatable, testable software (vs ad-hoc stuff a sysadmin does on a box somewhere).
- "Devops" as "oh look, we can hire less people and just get some 'devops' to do it all."
The way i have seen it used was more like the inverse of your first example, where one go from encoded and tested sysadmin tasks to "lets throw into production any newfangled thing the devs (monkeys hammering keyboards, more like it) wants to use".
Devops can definitely be used as a very expensive bandaid around poor engineering practices.
But there's more to it... sometimes the engineering work it takes to prevent something from crashing is much less than just monitoring and restarting when failures are detected. Maybe "failure engineering" is a good term for a lot of the value Devops techniques can bring to a team?
When implementing a failure-tolerant system, one has to remember that "crash" can often be parlayed into "exploit" or at least "denial of service", and thus not become too tolerant of failure.
But isn't that what all systems engineering is all about? Feedback loops with resiliency. Why is it that the software folks think they have discovered something new?
- "Devops" as a movement encompassing the ideas that developers should not be walled off from operational realities, and that software operations tasks should be encoded as repeatable, testable software (vs ad-hoc stuff a sysadmin does on a box somewhere).
- "Devops" as "oh look, we can hire less people and just get some 'devops' to do it all."