DevOps: What Do?!
'DevOps' is a loaded term, and is threatening to go the way of 'agile' in meaning whatever the person speaking wants it to mean, and in doing so lose any actual meaning it ever had. Most people seem to use 'DevOps' to either mean 'a sysadmin who knows Chef/puppet', or 'developers with root'. I don't think either of these really tells the story of what DevOps as an idea - as a movement - is really about.
Breaking Down Silos
DevOps is about breaking down silos between development teams and sysadmin/operations teams. Too often in dysfunctional organisations you see an antagonistic relationship between software development teams, and the people responsible for deploying and managing the software in use. The old-fashioned, backwards-looking sysadmins won't let you use the latest version of a library or software package; and the reckless software developers chuck a bunch of code over the wall and go 'it works on my laptop' when it fails to work in production.
In a sense, these differences should be expected: software development and sysadmin/operations teams have different motivations. The development team are rewarded for producing fancier software on time or ahead of schedule - and they're not punished if that software turns out to be unreliable or has complex or impractical to maintain dependencies. Meanwhile, the sysadmin team are punished - in the form of 3am outage notifications - for any unreliability, but are otherwise generally invisible and don't get very much of the glamour.
The purpose of DevOps is to integrate these two functions, to break down the wall of the silos so that both teams can work together instead of against each other. By using automation and more development-centric tooling operations management can be made more accessible to developers, so that they can take on the responsibility as well as the glory!
Building tooling
This is, for me, one of the key aspects of DevOps: by codifying best practices in tooling we can move away from having sysadmins/operations as 'guardians' of production and make it easier for development teams to deliver production-ready solutions, and safer for operations teams to iterate quickly.
Tooling is critical to fixing some of the conflict areas between development and operations. A great example is the 'works on my laptop' problem, where a developer produces code, probably on Windows or a Mac, which doesn't work properly in the, probably Linux, production environment. A DevOps approach is to give the development team an environment that mirrors - in as much as is practical - production. A simple Vagrant configuration can give a developer using a Mac or Windows machine, a Linux system to execute their code against. This might feel like a really common workflow now, but keep in mind that the Vagrant project is only five years old!
Automation
A critical part of tooling is automation. Automation is what enables developers to have an equivalent system to staging and production - because by using automation tools like Chef, Puppet, etc, we're able to run the same scripts in all environments.
Automation is also critical for enabling development teams to take the responsibility for their own deployments. Historically development teams were kept away from production hardware in case they looked at it wrong and set everything on fire, but with modern automation it's possible to give development teams safe access to production systems.
Development teams can even be given responsibility for dependency management and the like: writing Chef cookbooks is far closer to what they're used to than the traditional semi-automated BASH scripting that's powered generations of server deployments.
DevOps is not a job role
I can almost forgive job title-based nonsense like 'DevOps Engineer' (not least because it's my own job title!) since that's really just a short-cut implying a certain bundle of DevOps-related skills (if not necessarily implying a good understanding the of philosophy of DevOps). However, that doesn't mean that 'DevOps' should be thought of as a role to be filled in the organisation. A 'DevOps Engineer' is really just a sysadmin applying the DevOps philosophy, working in between traditional ops and development teams (or, in a smaller organisation, fulfilling the role of ops entirely).
If you have 'DevOps' as a role alongside both development teams and traditional operations, then all you're going to do is create a new silo, where dev teams throw code over the wall to 'DevOps', who wrap it in Chef, and throw that over the next wall to the people in charge of the servers.
This is basically just adding extra layers of bureaucracy for no productive purpose, like the countless 'certified Scrum Masters' that infect so-called 'agile' software development teams.
If you need a large number of DevOps-capable sysadmin? That's just your ops team. If your existing ops team aren't up to speed then retraining is a much better option than insulating them from modern practices by forming a DevOps team 'cocoon' around them.
An Evolving Process
DevOps, like most of our entire industry, is a new and evolving way of working. As we learn better how to work together we produce new tooling, and as we produce new tools we use them to find new ways of working. DevOps, as a philosophy, works well with this iterative approach to improvement.