Multiple people in this thread have asked "what is devops pragmatically." I will both try and answer why there is no clear answer to that, and what my clear an

Multiple people in this thread have asked "what is devops pragmatically." I will both try and answer why there is no clear answer to that, and what my clear answer would be. 1. Everyone has their own definition largely because everyone takes the bits of what they've heard of devops that they think are beneficial to them. I don't even think this is necessarily a bad thing (chose right tools for the job/culture, etc) but it certainly makes it difficult to centralize on a definition, compounded by... 2. That many of the people who want it only know, as sister posts have suggested and what the OP describes, what they want it to achieve, but don't necessarily have a clear roadmap to getting there beyond "devops". 3. So from that, what is my "pragmatic" definition (e.g. my "what happens in the real world" definition); pessimistically, "devs are now responsible for ops/sysadmin work as well, including on call, infrastructure and telemetry, but without any additional training, purview, or increase in pay." Now, to make that criticism, I should propose a better definition; and this was hinted at by sister posts as well: "Give devs the tools, expertise, and purview to accomplish ops tasks that previously were thrown over the wall. This does not mean GETTING RID OF ops domain experts, but unifying them with your devs to remove unnecessary separation, facilitate communication and needs fitting, and share expertise and skillsets where appropriate, since there are many ops tasks that benefit from a more engineering bent, and MANY eng tasks that benefit from an ops "I need to be able to run this understand it and fix it" mindset going in, as a first class citizen, rather than as an afterthought."