Hi folks! This is a writeup I published earlier in the year because I hear of a lot of people curious about the '4 Key Metrics of DevOps', what to measure, and how to get started making improvements to flow and performance.
TL;DR: Starting from a clear outcome is more important than chasing someone else's metrics, and mapping with your team can help you effectively translate your goals into action.
I'd love to hear thoughts, experience, and feedback!
I'm a big fan of decision frameworks but without those two clarifications it's hard to give feedback. To make this practically valuable it would be great to have logging and an escape path for criteria that doesn't apply or when information isn't available. If I get to question 5/6 and I don't know the answer, can I get a valuable outcome? It would be ideal to capture those cases with logging so the tree can be improved.
This is a great idea and start though. I love how minimal it is. Once I use it, I immediately want it just built into Jira or wherever I'm making important/repeated decisions.
It would be interesting to see what you're saving on each tool and why they beat free alternatives. I think the only one that doesn't have a compelling free option is getresponse but there's sendfox for email that does the job well.
I'm in this camp - I want to share content with Pocket (and increasingly Notion for personal use, then outward to Twitter/LinkedIn/Automation and all of that is already in my browser.
That's close, but still a problem. If you put change responsibility formally on the shoulders of a team or individual you're throwing them under the bus. It needs to be approached as a cross-functional team initiative (which is reproduced to scale out). A DevOps team might work if they're in a leadership position, but how does it work on the ground?
DevOps doesn't mean people doing multiple jobs. You can collaborate with separated roles and be productive. Furthermore you can build abstraction to simply remove manual, unrecorded interaction with systems to satisfy auditing and regulation.
Thanks for checking it out! It sounds like what you're looking for is a Ops or deployment checklist (but really just deployment automation). DevOps really is about "general engineering team principles", one of them being 'DevOps is not isolated to a specific role in our organization.' aka 'Don't have a "DevOps guy"'. There's a lot of great material in the references section at the bottom if you'd like more information on the reasoning there, but I think some investment in automation would relieve the checklist issue and make your deployments quicker and more flexible as a result.
So here's what that actually is: DevOps is super popular with recruiters and managers since the venn diagram of people who care about DevOps tend to be good team players with general yet current competency with very valuable tools and techniques, and they happily pay very well for these people. People who like being paid very well and enjoy working interesting and current problems realize this and thus DevOps is a tag that allows these two groups to find eachother. It absolutely gets misused in job titles for visibility, and we don't care because it usually doesn't mean the company wants a person who knows and does everything (though it certainly happens). It is entirely possible for DevOps to refer to a position, but by the very nature of the contraction, it would be two jobs for one person. Right now we live in a time of sufficient complexity such that in all but the smallest organizations that doesn't make sense, and in those organizations job titles are moot anyways.
In reality, if you look at the history of the term and the current leadership of the development and discussion around DevOps, it still represents the following core areas: 3rd Order Cybernetics, Agile (Infrastructure + Software Development) and Continuous Delivery. I personally believe it's just a simpler way to refer to 3rd Order Cybernetics (3OC will never catch on) and DevOps the term will give way to something that better fits the nature of the movement, but until then, that's what DevOps is. I agree there's a lot of noise and confusion, but that hasn't erased the history, the progress or the true current state.
I disagree. I think the article speaks rather well about what DevOps is really about. There's actually a great deal of consensus within the community about it's meaning, and Mr. Kim has been a major contributing member for quite some time now. Every DevOpsDays since 2009 has critiqued and reaffirmed the ideals and principles. Have a look at vimeo.com/devopsdays or the wikipedia article for DevOps.
Swapping DevOps for PostOps or NoOps or FooOps doesn't change what it means.
Recruiters and managers starved for multidisciplinary, highly skilled T-shaped staff have started to throw the term around in job descriptions, but misuse of a term doesn't change it's meaning until the majority of its users adopt the evolution.
Speaking of speakers: The official deadline has just past (we just missed this!) but I'd love to have some HNers submit for DevOps Days Toronto here: http://devopsdays.org/events/2014-toronto/propose
- Doesn't define project
- Success was defined by not violating the iron triangle (so nobody knew what they were saying OR they're working on trivial "projects")
- If you read reviews for the book it's totally AI generated nonsense