We spend so much of our time talking about distributed computing systems and their various components that we often lose sight of the human systems that drive their design. How can our knowledge about systems thinking in the computing world be applied to the often invisible systems that we operate in every day? Together we’ll explore the core concepts of systems thinking, how we apply that to computing systems. Then we’ll illuminate some of the human systems that drive our behaviors and what our new found knowledge can do to make these systems more efficient.

A lot of security people have a bad attitude about DevOps. Heck, sometimes it’s for good reasons. Lots of vendors are selling “DevOps in a box”, they’ll come in and “do the DevOps for you”, etc. What can you end up with? Lots of people with root access to servers with real data on them, code being deployed straight into production without appropriate testing, dogs and cats living together, mass hysteria!

I’m here to show you that it doesn’t have to be that way. I come armed with data from several years of the State of DevOps Report that shows how enterprises are finding security wins in embracing DevOps. I’ll show results of that survey and talk about trends in what we’ve seen. As well, I’ll talk about processes that a security team can put into place to make measurable wins for their infosec program. Not in security? I’ll show you what you can do to help out and start shipping better software or services. This isn’t just for web app shops either, we’ll talk about doing this in enterprise IT where you don’t get the luxury of writing everything you have to run.

Many organizations say they want diverse teams. In this talk, I address how, beyond recruitment, individuals and managers can create a culture that sustains a truly diverse environment. Using my own transition, starting out as a functional business analyst, to working as a DBA before becoming a DevOps/Infrastructure Engineer, I discuss how individuals and managers can take specific actions to foster creativity and diversity of thought and empower team members that may be subject to unconscious bias. Culture is a choice, and every team member makes a difference, regardless of their level. Good culture benefits everyone, and communication is key to creating good culture. I will discuss how specific communication choices can help anyone enable their team to create a positive, productive environment.

Every failure is a mystery to be solved. Solving those mysteries is a skill that can be honed. Let’s talk about how to get better at figuring out what’s up when things go wrong! This is a talk full of both high level advice and concrete tips from somebody who loves fixing weird production issues.

What does it mean to be good at debugging production issues? That’s the question we’ll explore in this talk! I’ll be sharing a grab bag of the postures, practices, tips, and tricks I’ve learned from years hanging out near production.

Running production systems are not always designed for operability, and yet we still need to fix them. Thusly, my goal is to share techniques that apply across a range of operational maturity levels. This breaks down into a few sections:

Adopting a productive attitude towards failures
Learning to love logs, wherever you may find them
Guerrilla systems thinking and domain modeling
Code reading for failure analysis
Collaborating to remediate and solve production issues
Production failure analysis has been one of the most rewarding skills that I’ve built up in my career. I hope that after this talk you’ll have a few tools to walk away with, but - more importantly - you’ll be inspired to get better at responding to failures.

Anxiety, stress and depression are becoming bigger parts of our lives as devs, whether we believe it or not. It’s time to confront the issues we’re facing rather than hiding from them. Carpenters fall off ladders, we burn out. We work our brains all day long, wtf do you think is going to happen!?

“I didn’t recognize you without your computer!” is what I used to hear a lot. I was in a constant battle with myself to keep coding, more and more. There’s so much to learn, so many different products to build - how am I ever going to have the time to build it?

If you’ve had those thoughts - you’re not the only one. We spend our days, nights and lives sitting in front of our computer screens and we forget to take care of ourselves. Anxiety, stress and depression are becoming bigger parts of our lives whether or not we want to admit it.

It’s time to take a break and talk about ourselves! How do we fix our own bugs? How do we perform better? How can we improve upon the anxiety that’s been bogging us down?

We need to, as a community start acknowledging these issues and talking about them in person. You can introduce all the new frameworks in the world but if developers are getting panic attacks and throwing their computers out the window, what’s the point?

Have you ever been pressed in your career about whether you want to go into management or be technical? I get asked this a lot. My answer is always, “why do I have to choose?” I’ll like to dive into the root of this question and then cover ways in which you can be a leader and still be a technical contributor. It’s a challenge, but certainly possible. I’ll draw on my experience over the last five years at Puppet, Inc.

Items Covered:

What is technical work anyway?
Prioritization is most important
Check your title when doing technical work
Don’t put yourself on critical path
Don’t fall into micromanagement designs
How are you improving those around you?

In a world of buzzwords and trends it is easy to believe that a type of infrastructure is now dead or that a new type is the future. Beyond those with clairvoyance, no one can say with certainty what the future of infrastructure will bring. What we can know is that in today’s reality many applications must run on mixed infrastructure - bare metal for static compute heavy loads, virtual machines for persistent data stores, and ephemeral short lived containers for stateless portions of the application. Come to this talk to learn how to determine what parts of an application go on what type of infrastructure and how to coordinate the different types into a coherent and powerful experience.

Many organizations have some kind of incident response process to coordinate during a major service outage. Some operationally mature companies incorporate a formal Incident Commander role in their process for a faster, more effective response. The Incident Commander serves as the final decision-maker during a major incident, delegating tasks and listening to input from subject matter experts in order to bring the incident to resolution. Whether or not a company has a formal process that includes an Incident Commander, most companies believe that your most senior engineer is best suited to lead an incident response. I challenge this assumption.

I have learned first hand that you do not need to be highly technical, let alone senior, to effectively lead a coordinated response to a major incident. Comfort with a structured process and soft skills such as communication are actually more important than technical knowledge for an effective Incident Commander.

All organizations need to maximize the number of people able to lead a major incident response to avoid burn-out of their most senior technical leaders and increase overall availability of their service. Audience members will learn from this talk how to develop an inclusive incident response process that welcomes more Incident Commanders without compromising response effectiveness that they can immediately apply at their own organizations.

The security industry works best with a waterfall approach to development and has not keep up with modern methodologies. This talk will look at tools and techniques to shift security testing left so software can be released early and often without increasing risk to the organisation.

Security is big business. Between security companies trying to sell us security-in-a-box and infosec professionals charging a fortune to tell us “we’re doing it wrong”, is it any wonder security is still an area that often deprioritised?

In this talk, we’ll look at what we should be doing to left shift security testing. By removing the fear and blame pushed by a lot of the security industry, we can start to see what can and should be automated and what really does need a security expert. We’ll look to understand that writing secure applications does not need to be costly and not all applications need to have the same level of security.

By looking at real penetration test reports, we will look at the tools and techniques we can use to detect vulnerabilities automatically and early in the development lifecycle, ultimately allowing us to release software often and quickly while still having a good understanding of our application’s risk.

The aim of this talk will be to understand why security has not kept current with modern development practices and give developers the ability to integrate security into the development pipeline.

My team is finishing a 15 month project aimed to convert over 500 Enterprise applications to a standard development methodology and CI/CD pipeline. This included a company-wide re-org, defining new Scrum processes and attending bootcamps, and undergoing a complete tooling overhaul.

After roughly 12 months of the project was completed and 300 applications had been migrated, we realized only 8 applications were deploying to Production with the new tooling. This realization shocked our whole team – we had taken all of these applications from long weekends of manual deployments and tech bridges to automated builds and deploys with push-button functionality - why weren’t more people using it? The answer came to me at a company Mardi Gras party.

A good friend of mine was telling a story about the previous weekend’s deployment, which took 16 hours to complete. The team took pride in working this long, grueling day, celebrating in hard work paying off and rewarded with extra days off. It seems that, while hard work should be applauded in any organization, employees were hesitant to use automation because it could result in less work for them. The fear is automation could make them less important to the organization, and possibly end in the loss of their job. A DevOps change is not complete until the way the organization values work changes.

If DevOps goals are to complete tasks faster with as much automation as possible, praise and rewards should focus on these elements and work to discourage laborious efforts that could be automated.

This talk will focus on understanding the DevOps movement from the perspective of the database professional. We will discuss the Values, Principles, Methods, Practices and Tools applied and provide an example of how these will effect the database teams. This talk will discuss techniques such as version control of the database, continuously integrating database changes, deploying databases changes in an automated way, automated database sandbox creation, automated database comparison, using tools such as dbdeploy, dbmaintain, liquibase, flyway and many others.

Lending Club runs 400+ microservices that comprise its online marketplace lending platform, the largest in America. Every one of these services has been developed, tested and deployed without drama. How? Our DevOps team uses graph database technology to manage infrastructure and operate the company.

Through our DevOps journey from monolith to microservices, datacenter to cloud, we learned that in order to automate all the things, we needed to have accurate and timely data about what exactly those things were. By loading all infrastructure components—from source code repositories to CI jobs, from bare metal hosts to virtual servers, from load balancers to auto-scaling groups—into a graph database, we created a single, central hub of information that we could query at any time and that helped us make sense of our complex, interdependent infrastructure components.

Understanding and dynamically mapping the relationships among our infrastructure gave us visibility into components that we previously had no idea were related. It allowed us to answer important questions vital to ensuring our site had four nines of uptime. “Is a service down or suffering a partial outage?” “Do we have a single point of failure?” “What services will be affected if this storage array goes down?” “Are multiple revisions of a single app currently deployed in production?” “How much are our AWS instances costing us by account and region?” “Is our secondary load balancer configured the same as our primary one?” We set up monitoring, alerting and reporting that helped us to prevent outages before they happened. We fully automated our datacenter deployments. When the time came to move to the cloud, we fully automated those deployments too. All these things and more were made possible because of our graph model.

In this talk, Ashley Sun, DevOps Engineer at Lending Club, will share the key insights Lending Club has learned throughout their DevOps journey, the technologies used, the challenges faced, and the lessons learned.

With the constant demand to build systems rapidly with more resiliency and less budget, compounded with on-call support duties and a seemingly endless stream of alerts, it’s no wonder that burnout has become a serious problem within the DevOps community.

In this session I’ll share ways that you can identify burnout and actions steps to prevent yourself from burning out. But we are also a DevOps community, which means we need to take care of each other. I’ll provide an easy to remember framework attendees can implement to identify, help and support others experiencing burnout and mental health issues.

Privilege is access to societal and economic benefits based on a characteristic you possess. The most well understood forms of privilege are the ones most people don’t choose for themselves like racial, gender, and physical privilege, but there are also selected privileges like religion, sexuality, and education.

This session will teach you how to lend your privilege. You’ll learn the various types of privilege lending including credibility lending (where you attach your name to a project being undertaken by someone without privilege) and access lending (where you provide access to a location or event for someone without privilege). These different types of privilege lending will be illustrated through well known examples and an explanation of how they can be applied to software development.

Attending conferences and speaking in public left me in a state of anxiousness, exhaustion, and anger. Thanks to the DevOps community, I’ve come out the other side. Come listen to my journey as a women in tech who is trying to interact with conferences attendees and organisers.

In this Ignite talk, I will share my personal adventures as women attending conferences and speaking in public in the 1990s. The undercurrent of condescension, harassment, and unconscious bias left me feeling isolated and frustrated. I didn’t want to be the the “problem” so I didn’t talk about how these experiences shaped me. My inner anger could have powered a small city. Being included in open communities like DevOps Days helped me realize I am not alone. We need to talk about these experiences in safe environments without the pressure of finding a solution. I want to start a dialogue. You in?

The decision to begin automating deployments seems fairly straight-forward and simple. This talk will cover the unforeseen consequences of that decision and the challenges of automating builds and deployments across heterozygous environments, languages and platforms. Starting with how do you make time for automation, the talk will touch on the need for automated testing, static code analysis, configuration management, artifact repositories and other technologies. Automation isn’t the answer to your DevOps problem, it is the start of your journey.

If you thought that last year’s thoughts were deep, wait until you hear this year’s. Not Jack Handey returns with another ignite full of one-liner jokes and fun “facts” about devops inspired by the SNL segments of yesteryear.

This talk is primarily tongue-in-cheek humor and will be comprised of “deep thoughts” that are entirely new to Chicago (aside from maybe one or two favorites from last year). There will be some “thoughts” pulled from other iterations of Devops Deep Thoughts and many entirely new “thoughts”.

You have a data lake and you’re worried about drowning in it. This talk will address solutions and process for using what data you’ve collected effectively with your team and the rest of the organization. Practical and hands-on lessons covering the glamorous and not-so-glamorous next steps.

You’ve collected a ton of data and it’s just sitting there. You want to use it but where do you start? This talk will give you map so you can navigate your unique situation by asking and answering questions such as: What kind of data do you have and why does it matter? What things will come back to bite you if you don’t consider them up-front? What does collaboration that rocks look like? What problems will you run into and what strategies are useful for troubleshooting them? How do you choose what to do first? Why is interdisciplinarity important? Once it works, how do you automate it?

With the trend towards increased usage of containerization, has your companies security practices kept pace? Many popular vulnerability scanners only examine the host OS, making it easier for CVE’s to go unnoticed. In this talk we explore how to identify and protect against vulnerable containers.

While containerization technologies such as Docker have many well-understood benefits, there are some non-obvious caveats that can impact the security of the overall platform. When vulnerabilities like Heartbleed are announced, DevOps teams often need to race to patch an array of impacted systems. But which containers are affected? Which systems need the most immediate attention? What change control must be observed in order to meet strict regulatory and compliance requirements?

In this talk, we will explore some of the issues my company has encountered as they’ve moved their infrastructure to an entirely container-based platform on AWS. We will cover some of the tooling required in order to quickly move bug fixes and security updates to production, and methods my team has developed to programmatically identify CVE’s and remove older, vulnerable containers that would be unsuitable for production rollbacks. These methods will be presented as additions made to a common CI/CD pipeline to deliver continuous security improvements when shipping software.