alt Hacker News> DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles. Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
That's exactly the issue that DevOps aims to solve, though. When you have developers who have no ownership or responsibility once the software is running on production, it becomes a "throw it over the fence" situation, and devs don't care about the operational side.
Logging? Who needs that, if there's a bug report I'll reproduce it on my local machine (and if I can't, CLOSE-WONTFIX!) Performance monitoring? That's an ops problem, tell 'em to buy better hardware. Application crashes? Works on my machine, probably a bug in the server config; ops problem. Tell them to set up a scheduled restart every hour.
You still need dedicated operations staff who deal with the overall system health and design, but yes, a developer needs to be involved when a DDOS brings down the service, because how should the system behave under heavy traffic? Can it serve up cached read-only pages? Did someone find a very CPU-intensive public endpoint that is being exploited and needs to be fixed? Only your developers can answer this question, not the ops team.
> devs don't care about the operational side.
That's an org issue. For a given service dozens of roles will be involved, if devs are needed to do every single of them to care and be invested, there is a problem.
> [...] Only your developers can answer this question, not the ops team.
Yes. Those are questions that need an answer before a service is released, and the ops team need the veto power + sufficient means to escalate recurring issues in ways that will hurt the dev teams enough to make them care.