So much for DevOps :'(

I just read a statistic that "DevOps Engineer" is the most recruited job on LinkedIn. Maybe I should be excited because I have been promoting the principles of DevOps for what seems like forever, but this trend of having a "DevOps Guy/Gal" or "DevOps Team" seems like it contradicts the entire philosophy of DevOps. The meaning of DevOps is that EVERYONE on a project has awareness of all the aspects of Software Lifecycle from Development to Operations and everything in between. The problems with having a "DevOps Guy/Gal" or "DevOps Team" are that:

1.) It becomes too easy for people to say, “that’s somebody else’s problem.”
2.) The meaning of DevOps changes to only include deployment automation.
3.) Instead of breaking down silos between different roles, you just create another silo (made things worse).

Now unlike some people, I am not saying that everybody needs to be an expert in everything and that every task should be able to be taken by anyone on the team. Yes, that would be great but it’s just not realistic. In the real-world specialization exists, and it exists for a reason.  A team may consist of a lead architect, back-end developers, front-end developers, data architects, build and deployment automation specialists, test automation engineers, operations engineers, etc., etc. A true DevOps culture exists if all these specialists have keen awareness of, and account for, the other team-members concerns. That would mean the following:

• Architects would only design systems that developers can run and debug locally, that would be testable in all environments including production, and that would emit enough data to allow operational awareness and alerting.
• Developers would need to organize their solutions so they are easily packaged and deployed, run automated (and possibly updated) automated acceptance tests locally and never commit code that breaks a test.  They should also build things that are designed to be tested (in all environments) and add instrumentation for operational awareness.  Developers should never commit code into the mainline/truck that is not production ready.
• Testers and test automation engineers must guide developers requirements to ensure features are built to be tested and find ways of integrating tests into the operational monitoring approach.
• Data engineers and DBAs must embrace concepts like database refactoring, schema versioning, backward compatibility, and deployment automation.
• The build and deployment engineer’s role are to build up a Continuous Integration/Continuous Delivery pipeline that is as complete as possible, eliminating as much manual intervention as possible.  This should include build, unit testing, static code analysis, packaging, deploying, load tests, penetration tests, automated acceptance test, and potentially much more. 

One important thing I think that is forgotten in all this is that as much as we want or CI/CD pipeline to get things to production, a good CI/CD pipeline is designed to stop releases from getting to production and provide feedback as to why a particular release should not be promoted.  I developer did a commit assuming it was ready for production and because of the combined efforts of all the team his/her assumption was quickly disproven, in an automated manner, without it getting in front of a customer.
As soon as we remember that DevOps is a philosophy in which everyone plays a role, the better off our industry will be.