Sweet, everyone who was here last year, raised hands. Yeah, quite a few people. Who here is not Dutch? Yeah, there's a ton of not Dutch people here. I am NOT Dutch, obviously. I am Jason, I work at Datadog. I live nowhere.

If you were here last year and you are not Dutch, hopefully you've been able to remember some of the words that I taught to you last year, hopefully been able to use them. And on all the molinator Landers, bedankt for practica. And some quirky culture things: like you might be walking around Amsterdam — for those who are new to Amsterdam — and you will see windows that don't have curtains. And this isn't because the Dutch don't like privacy. The Dutch really like their privacy, especially GDPR and stuff, but you know, they don't like to obscure their windows.

And this reminds me a lot of the state of DevOps and monitoring. How many people have heard of observability? How many people know what that is, observability? And we use it a lot. A lot of people talk about the three pillars of observability and building cultures of observability, and they really just mean monitoring, right? They're just using it as a synonym, a fancy way to say monitoring. Observability — that was a word that we've adopted from this practice. It's called control theory. And in control theory you have this idea that you have a black box and you don't know what's going on inside of it, so you measure the inputs and you measure the outputs and you try to figure out what's happening inside.

And this is a problem, right? Like, we shouldn't have black boxes. You should know exactly what's running on the systems that you're operating. In fact, most of you work with the software developers that are writing that software, so there's no reason that you can't look inside. It's almost like a Dutch house, there are no curtains. You don't have to stand at the door and figure out what's inside, you can just take a look, right? So I'm not encouraging you to look in Dutch windows as you're walking around town — that is a very rude thing to do. But the reason that we don't look through the windows is because, yeah, that's rude. The reason that we don't look into the software that we're running is often because of silos, because operations aren't talking to developers, developers aren't talking to operations, and clearly nobody wants to talk to business people to actually understand what you should be measuring.

So just as a note as you're thinking about this, whenever you hear the word observability — and I'm sure you're gonna hear a lot more of it as DevOpsDays goes on — but when you hear that word, take a moment to consider: does this person mean monitoring, or do they mean black boxes? Because if they mean black boxes, that's a warning sign.

Now one of the other things you might notice as you're walking around Amsterdam is the FEBO. And you'll notice this especially if you're drunk, which you will probably be later today after the barbecue. And when it's like 3:00 in the morning and the FEBO is great, everybody seems to say that they hate it but I think that people really like it, right? Because you're drunk, it's 3:00 a.m., you put a couple euro in the slot and you get a warm croquette, and who doesn't want that at 3:00 in the morning when you're drunk? It's fast and it's self-service.

And again, these things remind me of DevOps and how our industry has evolved, because fast and self-service are two things that we've been driving for. And it's why a lot of ops teams have done the renaming and they've become platform teams, right? So now they can focus on building a platform, and it really becomes: well, now I don't have to talk to developers, right? We can set up automation and developers can just deploy to the cloud and leave me alone. I can work on my tickets, I don't have to get interrupted. Like, hey developers, there's this thing called Docker, just put everything inside of a Docker container and we'll push it up there and everything will be fine. Leave me alone, I'll work on some automation and I'll play some PlayStation. And you know, that's the dream life, right? Who wants to not be interrupted?

But I hate to tell you that you really don't want to be the FEBO of ops, right? Because that's really what you're driving after if your goal is to stand behind a wall and build automation so that people can just put in a gyro and pull things out and you don't have to talk to anybody. That's not DevOps. DevOps means that you're talking to people. It means that you should focus on the service and not on the platform. And this is why most of us actually do hate FEBO. We eat in real restaurants, right? Because better service leads to better food. You can talk to the waiter and you can tell them I want to order steak and I want it to be rare or medium well. And then your waiter can say: do not order steak well-done, because only horrible people do that.

So as you're starting to think about how you can work in ops, think about being a service. And when you're finally done with your meal that you've properly ordered — because you didn't go to FEBO — my favorite Dutch cultural practice that you can participate in is going Dutch, because the Dutch like equality, the Dutch like responsibility, which generally means that dev and ops, we should share responsibility for the systems, for the applications that we run.

So just to recap: if you're not getting visibility into your systems, if you're talking about observability as black boxes, talk to your developers, talk to the business people. Ops: focus on providing services, not just platforms. And go Dutch, share some responsibility. Thanks.

---

Hello everybody. I'm a build master at TOPdesk. And at TOPdesk we have abolished all email alerts. We figured they are not really effective because they're so easy to ignore. And actually some developers had this email rule set up: if it's from Jenkins, delete it, we don't need it. We need something more effective. So we asked our operations department, hey, what do you guys use? You keep loads of customers online. And turns out that they use text messages. Text messages — what is this, 1996? We're in 2018. I sort of expect AI deep-learning. I want to be harassed by a chatbot that tells me that I broke the build again. I want to get these kinds of situations.

So unfortunately our company isn't yet ready for this, so instead we're using a Jenkins plugin called Build Monitor. It's on screens in every room and it looks sort of okay. And it has a downside: it's almost always green. You have to watch the screen to see what's happening.

So this is a little eye-catcher that I created: little flashlights, warning lights, with a USB-controlled relay. As soon as a build goes red it will start spinning. It's not really bright but it is really cheap, and it makes a lot of horrible noise when it turns. This grabs the attention. Since then I've upgraded to a brighter one which is a bit more silent. Now this is basically calling an API and doing something physical, and that's what we call extreme feedback. Basically it's sort of Internet of Things, just a bit of Python code querying some stuff, stuff happening in the real world.

So let's get inspired by the Internet of Shit Twitter account — do you know it? Stuff that shouldn't be on the internet. So let's take this as an inspiration and see how extreme we can take this.

So first up, I'm gonna add in a map of the physical location of all developers and hook it up to these USB Nerf rocket launchers. Developer breaks the build, just point and shoot. Boom. Nerf dart to the head. That will make them know that they broke the build.

So this is a bit of history: a company back in time was distributing CDs. A last-minute bug fix made all these CDs useless, so they turned it into the Pole of Failure and handed one out whenever somebody breaks the build. Now we can automate that. Let's grab a remote-control truck, slam a Raspberry Pi on top, and just drive it over. Again, a downside is it's pretty easy to ignore — it's just standing there.

So let's add some drones. Drones, they are really noisy, and if they just hover right next to your head — there, you broke the build — you'll notice. But our developers, they adapt quickly, so they brought their hearing protectors from home. So I upgraded.

If there are no developers left to break the build, the build will remain green. Yes. So that's maybe not a feasible procedure to keep a healthy company.

So I figured out some other examples as well. This is a great book — it will tell you all about your onboard diagnostic system in your car and how you can sniff the network and control your car from a Raspberry Pi. Let's hook that up to Jenkins, so if you break the build your car can let you know. It's a bit of shaming if it's your car that's in the car park flashing, so that's not something that you really want. We've also been experimenting with the car door locks. The look on the face of a developer when he can't go home because he hadn't fixed the build yet — that makes my day as a build master.

So we also had some other ideas. Unit4 is a salary payment provider, and they have an API. So guess what? The next time somebody breaks the build, something like this: you want to keep your salary, don't break the build.

Now any build masters out there? I'm gonna open-source this on GitHub. You only need to acquire the correct credentials and you're good to go to help motivate your developers to keep the build stable. So these are some of the crazy ideas that I could come up with. I'd love to hear what maybe you have for inspiration. So come see me during the breaks, and thanks for your attention.

So we're just figuring out it's hard, buying three more new keys for the front doors of the office and hooking that up to the build. You're ordering them right now.

---

Okay, figured that one out. So this talk is called Talk Selection Is Mockumentary Film Editing. I'm a DevOps evangelist at PagerDuty. This talk has nothing to do with PagerDuty, but it does have a lot to do with DevOpsDays. I'm also one of the organizers of DevOpsDays Chicago, one of the core organizers, but that doesn't really matter. And up until recently I had that license plate. This is really weird for me because I just sold my car, so all of my brand was around the fact that I owned a car that said DevOps, and I don't anymore. So that's kind of weird.

But so we're gonna talk a little bit about talk selection. And one of the things — so these were our numbers from 2017: we had 176 talk submissions and 18 spots to fill. We had more this year but I didn't update the slide. And one of the best and worst things about running an event like this is picking the talks, right? So I always kind of think at the beginning, when we're gonna do a year of DevOpsDays in Chicago, I'm like: we have a theme, we have an idea, there's a story that I want to tell. And the problem is that I may not get the talk submissions that are actually going to support what I want to tell.

This slide really has nothing to do with the problem — these are just some of the organizers, but I like the picture so I wanted to include that. The pictures don't always support what I'm saying, but they're fun.

So the thing is, you sit there and you say I've got like almost 200 talk selections, talks to pick from, and maybe my theme was I wanted to make fun of Schafer and I didn't get any talks that helped me do that. So what I have to do is I have to go back and I have to find a story in the talks. And notice I say a story, right? It's not a theme. People might say our theme this year is dev suck-ups — that's not a story, right? A story's a little more subtle than that.

So one of the lessons learned here is: don't force the issue. Don't be so stuck on your idea of the story you want to tell that you're gonna stick to that. You want to find this story in the things, with the talks that were submitted to you, and that requires a little bit more effort — it's a little bit harder to do that.

And so anyway, you said: well, Matty, at the beginning of this you said this had something to do with mockumentary, so what does this have to do with anything? So a little bit of background on that. If you're not familiar with the term mockumentary, kind of the first well-known one was a film called This Is Spinal Tap, and then there's basically a director named Christopher Guest who has done a lot — the great movie called Waiting for Guffman. They're fake documentaries, right? And one of the key things about that is these movies are all heavily improvised. Their scripts are about three to four pages long, of an outline.

So anyway, I made a movie about swing dancing called Waiting for Dancing with Gaia, and it was a mockumentary. And of course we decided — this being the first movie ever made — let's make it as hard as possible. Let's do what Christopher Guest inspired: improvised mockumentary. Well, the problem with that was we had about a three to four page script, we recorded about 12 hours worth of footage, and we sat down to actually edit it. The story that we wrote was not actually anywhere in the footage. We said what we thought this was a story about — this character and her journey — blah blah blah.

This is mostly just because it's a picture of me with a moustache. The background for this is one of our actors — his role required him to grow a big thick moustache. We shot this over weekends over about two months, and so out of solidarity, since I made him wear a ridiculous Chicago-style moustache, I grew one as well.

But yeah, so we wrote this story that was not actually anywhere in the footage; we had to go sit and find it. And this is also something that happens when you're making a real documentary, because you don't necessarily know the story that you want to tell, unless it's full of fake news or something like that, right? But if you want to tell a real documentary story, it's going to reveal itself through the people that you talk to, through the stories that you discover. And this is absolutely true when you're picking talks for an event, because you are one person — maybe even your talk committee is several people — but you're talking about 200 people, 200 voices that all want to participate.

This is a really bad photo of me. So this is also me being genuine and revealing myself to you. The biggest trick of that is to read through all of them and sort of let your brain unfocus, right? Because the problem was I had a story I wanted to tell and I was focused on it. So if I just sort of let these ideas wash over me, a theme and a story will come out. And believe it or not, that works. It's also very very hard for me to tell you what the story of my event is. And I'm also, similar to when I've directed films, I'm always interested to hear from people who've been at an event that I've run and what they think the story is, because usually that story is a little different than the story that I intended to run.

So a couple things to bear in mind: you can't predict what you'll get — that's super true. You want to start with an idea but be flexible about it. And also remember, improvisation can be fun. So you want to let your speakers be your guide in the story of what you're trying to tell.

This slide is from the States. I don't know if it's GDPR-compliant or not, so do this or not, but you could try. If not, I will put these slides up on my Twitter, which is at mattstratton. Thanks.