I am freelancing IT consultant and DevOps engineer based near Cologne, Germany. As a Unix generalist, I work with IT-infrastructure systems. Most commonly, IT infrastructure is said to consist of operating systems, networking as well as the servers providing different applications.
Generally, I operate, overhaul and extend such infrastructure when unixoid systems (Linux, FreeBSD, Solaris, AIX, etc.) are concerned. More specifically, I do so in development environments.
It has been noted that having for instance one department developing some software and another department taking the responsibility for that software later impedes communicaion, prevents learing and often leads very sub-optimal results. So, in many modern organizations, to reduce these organizational impediments, software is operated by the people who develop it.
Developers and people operating complex software now have different skills and often a different mindset. Specialization has benifts, as has been known in literature since Adam Smith. Thus, a development team needs a person with an operating skill- and mindset as a team member. This person is called the DevOps engineer or short, DevOps, DevOps being a portemanteau of development and operations.
On the technical side, the DevOps is on a high level concerned with managing the setup and configuration of a flock of often cloud-based virtual machines. The DevOps is fluent in virtualization and cloud technologies and believes in automation to 1) rapidly, 2) deterministically and 3) auditable configure systems. To reduce risk to operations when deploying, DevOps employ continous integration and continous delivery. In addition, the DevOps engineer needs to have a very solid foundation in operating systems and networking.
On the governance side, the DevOps engineer is required to organize artefacts the team develops so that these are deployable and can be operated with minimum supervision over longer periods of time. The DevOps is required to argue for portability, standardization, documentation, auditability, and availability and performance monitoring on behalf of continuous operations under load and stress.
Interesingly, doing devops properly is in my estimation only 50% technological know-how. The other part is stretching over to varios stakeholders from different backgrounds for whom the development of new features is a primary concern to keep them from learning the hard way about that unplanned downtime part.