Most posters here don't seem to get it. Most replies appear to be the idea that DevOps means you fire your Ops people and the Developers do Ops previous job and their own Development job as well.
It caused the dev team to implode (everybody but one person on the 8-man team left within a year). The systems' stability and overall architecture was utterly terrible, servers would fall over because they would log so many things that they'd run out of disk space ("what's logrotate?" "What's a slave database?"), no metrics, no definition of success for a service, etc.
I suppose you could pull this "DevOps" thing off if you really wanted to, but you have to hire folks who can program and actually like sysadmin work. Otherwise you end up hiring developers to do everything, who are terrible at sysadmin work, and who get burnt out because they never get to actually program.
DevOps is not get rid of the Ops team. DevOps is not get rid of the dev team. It is get Ops and Dev to talk and understand each other. Ops should not be completely clueless as to how the developers workflow works. That doesn't mean they are a developer. Development should not be completely clueless about what happens during deployment but that doesn't mean they're on call to handle OS issues.
DevOps is these two teams are working for the same company and same goal, so damn well talk to each other and act like it.
Hint: In a devops work flow, if you were large enough to need a separate ops team, you still have a separate ops team.
Previous job had a "Systems" team and a "Database" team. Both were just teams of obstructionists.
"Oh you need something today? Well, if you get a jira ticket made I could look into getting the requirements written up sometime in the next 2 weeks, to get the work assigned out next month."
Not saying that's the norm, but damn I hope I never experience that again.
My favorite was the marketing manager who thought an email, with a full size image attachment, and note saying 'this needs to go on the marketing site' was sufficient requirements.
Requirements and prioritization are not a bad thing. Excessive bureaucracy is.
Both were just teams of obstructionists.
"Oh you need something today?
... get a jira ticket made
... work assigned out next month."
In my current job, I am the sole developer responsible for maintaining a certain set of our codebase. I have multiple internal customers, each of whom have separate (external) customer-facing needs. I have enough tickets created for three people working full time, so I am constantly having to triage which are the most important.
Part of the solution to this was to have a proposed plan for when to work on things -- I can then say, "Thank you for this well thought out ticket. I will be able to work on that in June." The most important thing is that my users' opinion about the criticality of things does not always match the overall picture, and I am always having to choose which tickets to postpone.
I wonder if one can draw parallels to the BYOD thing.
In both senses it seems to boil down to someone bypassing the IT admins because their manager wants to see results ASAP, and IT is going "sorry, budget and/or regulations says we can't at this time".
It seems to have stemmed from Ops teams saying "What can we do let dev teams build what they want, but in a way we can support it"
e.g. - a system needs an entry in the /etc/hosts file (a bad example I know, but a nice simple one for the basic use case)
old method: Dev files a Jira ticket, and the Ops team make it part of their golden images for production.
new method: Dev makes a change in the Config Management DB. Gets reviewed by a member of Ops, who either approves, or makes a suggestion to change it. Change gets tested against staging, then merged, and the system gets updated.
Ops know what the system needs, Dev knows how long it will take, and has an understanding of how it is deployed in real life.
Applications used to run on a fairly static number of instances that were maintained by an operations team. When more capacity was needed, operations would provision new machines. But now, especially with the increasing shift toward the cloud, infrastructure is seen more as something that's created programmatically, or even in response to events (load or otherwise) in the network. It's a powerful conceptual shift to think of infrastructure as something that isn't physical, but is more ephemeral. Just like a process on a server may die, a server on a cloud hosting platform may die. But you can engineer for failure at the infrastructure level the same way that you'd engineer for failure at the system level.
With this change, you can no longer rely on a fleet of sysadmins to manage everything for you. Instead, you rely on scripting everything..."Infrastructure as Code." You create recipes to create each and every part of your infrastructure and tools to orchestrate everything. Gone are the days where you actually ssh to boxes in a terminal...there are far too many boxes to make this practical. Instead, ssh becomes the protocol that your orchestration uses to communicate with its fleet of machines. Things are much more dynamic and you start to view your infrastructure more holistically rather than as a collection of individual machines.
Once you've started to think this way, you realize that neither the traditional development mindset or the traditional operations mindset work in isolation. You need to meld the two together so that operations understands better how to automate everything and development understands more about the environment in which their code will run.
The problem is in most orgs, the roles for people who fight fires in production tend to be demoted to a lowly "support" title, and paid/hired for accordingly, which is really not commensurate with the value they provide to the organization.
We were understaffed, underfunded, and underpaid.
Exactly, you have to fire the developers too.