Video recording and production done by DevOpsDays.
As a community we are consumed with tools. Tools that automate, tools that automate the automation. We discuss and write blog posts about the latest tool for X or why A is better than B.
Are we alone in this tool obsession? Do doctors discuss the merits of a new stethoscope on the market or talk about compassion for patients? Do musicians argue which guitar picks is better for shredding (hint: they do) or why Zeppelin will always beat Metallica in an awesome contest?
Let's explore the underlying causes of our tool-dominated culture and see if we can push beyond The DevOps Tool Talk.
Lovingly brought to you by a self-described toolsmith.
As a medium-sized company of around 100 people, we're engaged in a business-to-business (B2B) model with some of the world's largest companies where security is paramount. We provide a vendor solution that resides on our customers' websites, as well as store and transmit customer-owned (i.e. Confidential) data. Signing new customers up to our SaaS generally triggers a "security review process", which is both effort-intensive and can delay closing of the contracts. At the beginning of the year we committed internally to beginning a SOC2 audit as both a competitive differentiator and also to shorten the the time to complete a security review.
In this talk I'd go over how I prepared for the SOC2 audit with DevOps in mind. This will include: how I selected an auditor to work with * how we wrote controls together * how I attempted to minimize manual effort for all teams * how I attempted to enable common "DevOps values" such as: developers releasing their own code * developers having access to Production * small, frequent releases * teams empowered to make decisions instead of an external control board
I hope this can be useful to other companies, even if most engineers want to shy away from policy-based work in favor of more exciting things like tool development or engineering challenges.
Customer Service & Support in Devops - Mark Cornick
That's not a DevOps... this is a DevOps - Alan Sharp-Paul
Introverts and Tech Conferences - How to avoid stress and enjoy yourself - Tom Duffield
I work for a company called SPS Commerce, it's been a very aggressive growth company and a heck of a wild ride, being the 82nd employee when I started in 2005 I have had the opportunity to observe the wide variety of challenges a company can go through at different sizes (we're over 750 employees now).
What I have come to observe as a critical factor in the success of a technology company is how well priorities are aligned across the company, not just Dev and Ops, but product, security, marketing, etc... I think this is a critical ignored factor of effectively delivering a service and as a result it causes humans to work against each other.
This talk will go into how and why I believe not effectively managing an organization's priorities is as damaging to a company's success as not trying to implement a DevOps culture at all! (I will try to touch on how this is different at various sizes of companies)
Two critiques I've heard from first-time DevOpsDays attendees are that they felt like they were on the outside looking in and they didn't take away anything actionable. I posit that these are two aspects of the same problem we've created and can solve.
What exactly do unicorns, horses, and goats have to do with corporate IT and software development, asks a newcomer? We want to reach outside the echo chamber, so we need to make the jargon and references of this community more accessible. We talk about empathy as the essence of DevOps; we need to ensure we practice inclusion. Whether it's providing more context for common references or giving clear speaker bios and introductions, we need to ensure our community mindfully welcomes new participants.
Being new to the space can mean looking for rubrics and implementable strategies. It's not wrong to want a list of action items, but acting without reflection isn't enough. We need to make it clear that the "how" stems directly from the "why" and the "what".
And just because DevOps is for everyone doesn't mean that DevOps encompasses anything and everything. There's no RFC for DevOps, but it does go beyond culture to automation, measurement, and sharing. There are many great tools in that space, and large organizations might implement them differently from small ones. Commerce in this space is welcome and expected, but the practice of DevOps itself is not a commodity.
Forget hipster DevOps versus enterprise DevOps. The DevOps in the window is just DevOps, and it's not for sale.
While a single person may have the technical skills that it takes to be considered DevOps, one person cannot DevOps alone. DevOps is a mentality. It's a culture that has be adopted by your entire technical staff. There's no checklist of how to do this, because every organization is different. But while it's difficult to know how to do things right, it's much easier to point out when we're DevOopsing: doing DevOps wrong.
By recognizing our weak areas, we can work to improve them to move towards less pain and more glorious DevOpsing goodness. If you and your company are DevOopsing, gather round as we discuss the growing pains in adopting DevOps, both from a technical and cultural perspective. I'll use real-world examples from my own experiences in a company that is still working to achieve the DevOps holy grail.
"If Only They Knew" - The Dunning-Kruger Effect - Seth Goings
Keep DevOps Simple - Tom Martin
Layeth the SMACeth down(eth) - Turning DevOps on Its Head - Steve Pereira
Strategies for Living Without Scheduled Maintenance - Doug Barth
As an evangelist for Continuous Delivery at Orbitz, I have been able to see many of the struggles and there to see how we have over come them. None of these struggles are purely development struggles. These changes are building stronger DevTestOps teams.
Over the last year, Orbitz has started the transition from deploying our 175 applications at most once every 2 week to being able to deploy them at will, daily or more often. This is creating cultural change that is not always easy to bear. Our history has built a culture where a failed release is shameful and not just a learning opportunity. As the deployment of the Orbitz Global Platform's applications become more frequent we are entering a new level of maturity. As releases become more frequent the value of them changes. The value of many of our practices are changing also to the point of abandoning some of them, automating others, and refactoring the rest.
As we simplify, automate, and speed up the deployment pipeline, the feedback of a release candidate's production worthiness becomes more important and clearer. In the past, there was a fuzzy gray area between Go and No-Go. We are learning to kill off a bad release sooner because another release is already on deck. Trying to salvage a release is an effort in fighting stupid and blinds you from an opportunity to make more awesome.
There is a lot to learn from our mistakes such as:
* made heroic efforts to deploy apps when procedures didn't work
* kept releases in production that should have been rolled back
* put undue pressure on teams to resolve an issue in the next days release
* begged our Product partners to give us business justification for an additional off-cycle release in an effort to cover up our mistake
As we are just entering the new maturity, I am sure there will be much more by October. We believe the community at the conference will benefit from hearing what we've learned, how we're changing, where we are still struggling, and how awesome it's going to continue to be as we head down this path.
At PagerDuty, we are building out our highly available service for alerting the right person when s%IT breaks, but how does PagerDuty monitor PagerDuty? In this talk we will cover the strategies that PagerDuty uses to always make sure our service is always up and running.