What you're describing, if it were to be assigned a label, would probably be a lot more accurately described as "agile systems administration." Devops is another animal, though like the contemporaneous cloud computing movement, its proponents have allowed its use to become exceedingly diluted.

Devops is a specific approach to a specific problem in a specific niche. Companies whose core offerings contain both development and operations teams (i.e. most Internet companies ever) have siloing of their operations and development concerns into different areas that didn't communicate well, if at all. Bucks were passed and nobody knew what was going on. One of the solutions to this looked eerily similar to process and governance frameworks like ITIL and COBIT: more red tape, and more accountability, but nobody feeling more empowered about the situation. This approach generally leaves companies worse off than when they start, because now people are burying their production changes explicitly. This makes it possible to actually get work done and avoid being held up by meetings of some apocryphal change review board, but makes things hellish when something breaks and nobody knows what changed.

The goal of Devops was to eliminate this in a much saner, leaner way way. It's far more productive to build a culture where smart professionals are treated like human beings, and development and operations each understand the other's need to work a certain way. If operations is expected to be on call 24x7, development had better do a really good job of notifying them of changes and doing them in a standard, ops-approved way (and they had better have a developer on call too). If admins are expected to be administering an application, there should be some seasoned sysadmins at the design meetings to make sure that things are put together in an admin-friendly way. On the other hand, operations understands that their role is to facilitate the developers who build the product, and not the other way around; DevOps is antithetical to the BOFH approach. Many of the operations tools are built around letting developers work better, rather than just allowing operations folks to sleep better at night. DevOps shops often have code updates being deployed hundreds of times per day, because continuous feedback and test-driven infrastructures brought on by tight developer-sysadmin integration facilitate that easily and safely.

Much of the work focuses on metrics because if the human brain is fantastic at one thing, it's discovering patterns. I mostly disagree that this makes them system programmers. Occasionally you'll find someone who engineers something in SystemTap or DTrace, but for the most part dyed-in-the-wool DevOps guys, the ones who understand the movement and aren't just following hot topics at DevOpsDays and PuppetConf, are concerned with much higher-level operational metrics. The most important one that you'll see on any DevOps manager's dashboard: sales/checkouts/signups. There's absolutely no better indication that something is wrong with your website than when the money suddenly stops rolling in.

Incidentally, that's a metric that requires some pretty close integration work with the app developers.