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.
... devops actually sucks just like every other âoeagileâ fad that came before and produced nothing of value other than the ability to avoid accountability
"Embrace the Agile paradigm ..."
1st Bob: What you do at Initech is you take the specifications from the customer and bring them down to the software engineers?
Tom: Yes, yes that's right.
2nd Bob: Well then I just have to ask why can't the customers take them directly to the software people?
Tom: Well, I'll tell you why... because... engineers are not good at dealing with customers...
1st Bob: So you physically take the specs from the customer?
Tom: Well... No. My secretary does that... or they're faxed.
2nd Bob: So then you must physically bring them to the software people?
Tom: Well... No. ah sometimes.
1st Bob: What would you say you do here?
Tom: Look I already told you, I deal with the @#$% customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!
Peter Gibbons: It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime; so where's the motivation? And here's something else, Bob: I have eight different bosses right now.
Bob Slydell: I beg your pardon?
Peter Gibbons: Eight bosses.
Bob Slydell: Eight?
Peter Gibbons: Eight, Bob. So that means that when I make a mistake, I have eight different people coming by to tell me about it. That's my only real motivation is not to be hassled; that, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired. ”
Apple and Microsoft could learn a lot about reliable software from Linux.
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 don't know how people like you can look at the past five years, with what's happened with Docker and containers in general, and cloud in particular, and how they've changed almost everything about deploying and running software, and say things like "it's the same shit product emulating another shit product". I mean, really?
If everyone and everything around you is the problem, the problem might in fact be YOU.
I'm in a situation now where a new VP of IT was hired late last year at the smallish (approx 500 employees total) company where I work but he came from a large multinational. Since coming in he started introducing various changes to our development and deployment processes, wringing his hands frequently about how bush league we supposedly are and frequently invoking "well in other companies they _typically_ do X".
The "funny" thing being that every time he introduces some new process that supposedly will improve delivery, it makes it worse and orders of magnitude more time consuming. We've gone from the past where deployments were total non-events and never posed any problem to a place where they are a walk through hell involving dozens of people for no good reason and they all bike-shed and conflate the unrelated so much that each and every deploy is now a fiasco.
The other "funny" thing is he constantly spouts agile terminology while forcing us to undertake a process that is virtually the exact opposite of agile.
Apple? Linux or UNIX kernel? XNU for Darwin was BSD based. Maybe you're thinking of Google/Android.
Not starting out well when they cannot name the file correctly. Also was this created in macOS? Not good.
Did I say kernel? Last week... https://it.slashdot.org/story/... https://apple.slashdot.org/sto... Not to mention that clicking "check for updates" puts you on Alpha testing for Win10.
Operations has been decimated in the past several companies that I worked at. Developers are running operations... an analogy would be the insane running the insane asylum.
Dev Ops is an example of the willing, led by the unknowing, doing the impossible for the ungrateful.
Our Dev Ops team has adopted the slogan, "Delivering Yesterday's Technology Tomorrow!"
Just cruising through this digital world at 33 1/3 rpm...
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.
DevOps typifies the phrase "jack-of-all-trades, master of none". This is a trend I've started to see where I work. A push to get everyone at least a little knowledgeable about everything, so anyone can fill in for anyone else. The idea that specialized skills allow a good team to be more efficient and productive is mostly lost on my coworkers.
Here's the thread where we talk about developers bundling ancient versions of libraries with vulnerabilities in their Docker images, calling Ops people obstructionists, and then blaming them for security failures. Also, people who refused to use CI, introduce breakage, and then try to cast blame while someone else fixes it.
Don't work for a tech company where the CEO isn't an engineer.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The complicated interconnected nature of this sort of thing means issues land initially in one expert's lap, only to be delegated to another expert. The key is to be flexible and responsive to issues and not worry so much about who is responsible for what, but who is responsible now as an issue progresses. The hand-off of responsibility is more important than defining the responsibility.
I guess there *is* a silver bullet, it's called DevOps! What wondrous times we live in.
Non-coding managers will always be be prey to anyone or anything insulating them from the unacceptable truth that making software system sing is an art form more similar to making music than a production line. Find the right artists and keep the band together and sweet music will flow to your customers.
"Knowing everything doesn't help..."
Trump is a PEACE president. He has already tried ended 3 wars - Korea (!!!), Syria, and Afghanistan.
How did the Democrats become the pro-war party??
I so dislike this attitude of 'I am not going to change' instead of looking at the methods and technologies and see how they can be of use to you. Some might be great for your organisation, some not. But dismissing everything on forehand is just so stupid and the reason some organisations are stuck in old, unmaintainable and inefficient IT environments while the world moves on.
DevOps is a joke - or at least, the implementation of DevOps is a joke. The concept is a great idea. Unfortunately when it comes to how companies actually implement it, they don’t see it as a way to improve collaboration between Ops and Developers. They either:
1) See it as a way to reduce headcount by combining two jobs into one (HR/Management viewpoint)
2) Developers see it as a way to remove “obstructions” put into place by IT/Operations, and give themselves direct access to production systems.
The majority of today’s DevOps are re-inventing the wheel and re-discovering bad ideas that more experienced system administrators discarded decades ago.
Case in point: I attended a talk by the DevOps team from Wave Accounting about their deployment strategies. In the past, whenever Wave pushed a new update of their software to production, it would take literally hours to deploy, and the deploy process was very fragile. It turns out that they were coordinating the deploy from a single server, which would use a config management tool to log into each server, check out the source, download all the dependencies, and run the build - umpteen times for umpteen servers.
The point of their talk was to showcase their brand new build system, which did away with all that and built the software locally, *once*, and then packaged the build and deployed it to each server. They thought this was the best thing since sliced bread of course, meanwhile all the experienced sysadmins in the room were rolling their eyes since *this* is how you deploy software (and control the dependency chain if you’re smart about it).
But hey, why listen to experience? Let’s just do away with the sysadmins and let the devs run amok. What’s the worst that could happen? (I mean, besides npm?)