Slashdot Mirror
Dev vs. Ops: The State of Accountability (overops.com)
Here's an analysis by OverOps on how shared accountability affects the delivery of reliable software in a DevOps environment, and what are some of the top challenges teams face when it comes to building and maintaining quality applications. Conclusion from the report [PDF], which relies on a survey of over 2,000 IT professionals around the globe : At the center of this DevOps adoption chaos is the evolving relationship between development and operations. Many organizations are already taking a shared approach to accountability for application health, however they still lack the tools and application visibility needed to know who is ultimately responsible for addressing and fixing each issue. As the lines between these two teams continue to blur, organizations will need to focus on adopting tools that deepen visibility into their applications. Clarifying ownership of applications and services, and avoiding the "multiple owners = no owner" syndrome is a crucial for even the most bleeding edge organizations.
The "Dev vs. Ops: State of Accountability" survey revealed that as more organizations begin the transition to DevOps workflows, defining roles and processes becomes more difficult and more important. Furthermore, businesses of all sizes are building and releasing new code and application features faster than ever before, which adds additional pressure across the entire software delivery supply chain. Organizations going through the DevOps transformation are more likely to face visibility challenges that make it difficult to maintain or improve application quality and reliability.
The "Dev vs. Ops: State of Accountability" survey revealed that as more organizations begin the transition to DevOps workflows, defining roles and processes becomes more difficult and more important. Furthermore, businesses of all sizes are building and releasing new code and application features faster than ever before, which adds additional pressure across the entire software delivery supply chain. Organizations going through the DevOps transformation are more likely to face visibility challenges that make it difficult to maintain or improve application quality and reliability.
IT and the "movement disease".
I am sort of tired of this constant "revolution" garbage that surrounds the IT industry in general. I work in this shit industry, I am well paid for what I do, but one thing is always certain... It will always suck because everyone in charge of IT came from college where stupid is the only thing being taught when it comes to computer science.
There is never anything innovative being done, by the time I am done listening to a sales pitch I realized I have heard all of this shit before, it's the same shit product emulating another shit product surrounded by proprietary technology that works like shit just in a different shitty way.
There is also the problem that every industry has... 20% of the folks do 80% of the work. Do you know what else tends to happen? 20% of the people are the only ones that knows what to do or what is going on. Do you know what else? IT is not a meritocracy either... it is still the same brown-nosing ass licking who you know path to success, like every other department. Those in the know are constantly assaulted by their lesser skilled and capable "co-workers". Those in the know are constantly waiting for some other knob in a different department to do their own damn job. And all of this while management keeps not getting a fucking clue and piling on more and more work to the point that more than 50% of projects fail by either never having the proper amount of time & expense dedicated to it.
These bullshit "cultural DevOps, ITIL, Agile, Waterfall, blah blah blah" are all stupid ideas people keep coming up with to address the problem of an industry that is riddled with incompetent management trying to rule over an incompetent group of pseudo intellectual nerds that know far less than they put on. And that is another problem as well... people hate IT personnel that do not sound "over confident" it is a practical requirement for IT pro's to act like they know every fucking thing there is to know and yet those of us at the top know different. We are all running around trying to figure out every little fucking thing on the fly because experience has taught us to just roll up our fucking sleeves and work it out... regardless of whichever newfangled fucking "operation ideology" that someone pushes.
I was our company's monitoring department and was checking systems and applications and it fits this question quite well, and you know what, IT SUCKS!
Between management that does not give two f**ks, developers who don't understand infrastructure and systems administrators who cannot manage applications, no one wants to be on the hook for anything. Just TRYING to get them fix issues without pointing a finger is a nightmare. It is like being the IRS, you never get a call from them saying you did a good job.
Everyone is afraid of looking bad because management, which does not understand IT or process, falls to politics to address issues and everyone else is afraid to make a move that make get them into trouble.
DevOps and Agile crap, will not fix broken management.
Unless your project is very small or your management is stellar this just builds a road to disaster.
Developers who do not feel the pain of their actions are not incentivized to correct issues. In the beginning, there may be a few bright eyed engineers who take to heart the messages, but eventually that gets lost in the sea of priority. A number of things start to happen which can increase page count. It could be a hard to find bug that really only produces a few escalations, but combined with a number of those the issues can severely add up. Increasing escalations that don't get attention because individually they are not severe enough and well the operators can handle those.
Perhaps the largest issue only hinted at is the brittle nature that tends to evolve. It may take the form of circular dependencies or poorly considered dependency trees. Oh, such as taking a dependency on a tier 2 service for your tier 1 service or perhaps no one discussed the volume of traffic they would be placing on this other service. Those types of failures start to creep in when you disconnect yourself from your platform and multiple specialized teams start making changes to a cohesive whole. The reality is, despite everyone's hopes, is that living in the service keeps you connected to the details. Personally, I witnessed this type of degradation occur so severely I was likely one of maybe three people who understand the entire platform in an organization of hundreds.
The last service I helped build and design was built with the concept of "I don't want to be paged in the middle of the night." We didn't get it to that point by passing the micro issues to an oncall. No, the other teams did that and many of our pages are the result of those teams poor implementation or lifting work to our successful team.
I've seen whole operation teams nearly up and quit after development teams were completely disconnected from their projects and shouldered maintenance. It usually goes that way or you get some very battered and dedicated people who eventually trickle out until the lynch pin fails.
Pain is a great motivator to fix problems or at the very worst fix their poor alarms.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
Sysadmins mostly work at Amazon and Google and Microsoft now. So, devops is largely now the process of automating cloud services.