There are a lot of changes, a lot of new methods, a lot of new tools in this area of ops, so I thought we would step back for a minute and look at the fundamental things that happen in this area that have to be done. And I think that will give you a good anchor to go and kind of explore the way that stuff is being done in your own program. And then also think about which ones might make sense to apply some new ideas and some new methods to. First of all, what is our happy place with ops? What are we trying to get to? Well, really it's chiefly these three things. High availability means our service, our app, whatever it is, is always available to the user, substantially at least. And this is really a function of two things, mean time between failures, how often does it break, and mean time to repair, how long does it take us to fix it. And particularly with the tools that are available today, with the strategies the teams deploy here are one, is stability. Let's make the perfect software that never breaks or try to get it as close as possible through, guess what? Lot's of good test coverage. And number two, let's have a lot of depth. I mean, so if a server gets unplugged in one place, let's have so many redundant instances that can take over that we don't have to worry about that too much. Somebody can come in in the next day and fix it, and that's really the relationship between the mean time between failure and mean time to repair is how long does it take for us to fix one of these things. And if you a lot of depth and you have really good automatic failover, then that's a great way to really minimize both of these and get high availability. And that is what, generally speaking, these teams are kind of pushing for. Lots of things, easier said than done, lots of things can complicate this. But those are the key Items that have to do with availability and how teams approach them. Low latency is good performance. So that often has to do with making sure that enough networking, so enough bandwidth and enough capacities. So enough servers or server instances are up and running of your application to spread out the load and make sure that the customer isn't waiting a really long time for the thing to operate. Also has to do with testing and performance testing, which we talked a bit about last week. And then finally, how much does all this stuff cost? Meaning, I mean, any one of these you could theoretically solve by just buying lots of servers, or renting lots of servers. But you don't want that, you don't want to spend more money than you need to on this stuff. And these things can become a very significant cost driver. So how do we become more efficient, how do we reduce cost? More than anything what you don't want is, this is my rendering of a snowflake. You don't want your server or servers to be these special snowflakes that everyone is terrified to modify or touch. That is a red flag. Now, there might be lots of reasonable things that happened, that got everybody stuck in that spot, but that's a place ideally you want to get out of as soon as you can, because that is sort of the opposite of how you get to this stuff here. What does this ops team do to make all that stuff happen and get to those good outcomes? Well, I've organized these things into four main chunks along this idea of a job to be done. The basic idea with a job to be done, or a JTBD, is that we're not selling somebody a quarter inch drill bit. We're selling them a quarter inch hole. That's what they really fundamentally want. And maybe really that's not even what they want. They want to hang up a picture perhaps. And so the purpose of this is to have sort of an innovation friendly anchor of, what do we fundamentally want to do? And then that sort of frees us up to think about innovative new ways of actually doing it. And so the overview of these is that this first category has to do with thinking about the way that you want the job of ops done and its relationship to other areas. Terms that other folks might use to describe this are architecture or research and planning and that's fine. I'm not trying to particularly advocate it for these individual terms, I'm just trying to make them clear. And so it has to do with figuring out processes, tuning those parameters that we just talked about, thinking about what tools and technologies we want to use as a team. Next is deploying or very often you will hear the term provisioning. And this is where I lumped kind of everything that has to do with adding more capacity because our latency or our response time is going down. You have more people using the application and we need to make it kind of bigger so that it can handle more traffic, more load, more inputs. Next, we have this job of maintaining. This is frankly where a lot of the action is. So how do we update both our own software and that 99% of software that it probably runs on top of? And how do we do troubleshooting and problem isolation, the most anxiety inducing part of this whole thing probably. And then finally, the job of monitoring. So how do we know when we need to do this? So how we detect outages or when the server is not performing well? How do we monitor demand and load over time? So we have a plan for this deploying and it doesn't become an emergency. Also worth mentioning here is that the ops team or the Java ops will have a very close and productive relationship, hopefully, with your customer support team. So those are the people on the frontlines of actually receiving inputs from the customer about what might not be working quite correctly. So there isn't really a term about this relationship. Soap ops, soap opera not soap opera. But there is this relationship between ops and support that's very important that I would, I mean, ultimately it has to do with all these things but I would particular put under this job of monitoring because ideally the ops team is finding issues and resolving them before they end up with that support team. And if they're not, they want to make sure that both they're getting the support team what they need to respond and responding quickly so we minimize the footprint of these customer issues. So that is an overview of the job of ops.
