 Right, so I'm gonna get started, technical problems. So welcome to the infrastructure FDU for October. Today I'm gonna talk about focus and strategy, growing the infrastructure team, grouping center and design, which is something that we're doing at infrastructure to improve our communication, Q4OKRs and then looking to CI CD with an infrastructure and through engineering at large. Our focus and strategy continues to be a relentless focus on gitlab.com availability, except that as we head into the new quarter, we've added this observable. So we spent a lot of Q3, sexually duct-taking the environment to improve availability and address some blaring issues that we were having. And now on Q4, we're gonna focus on being able to have better visibility into the environment and to be able to better measure our availability and where we're running into issues. Our overall goal continues to be to get ready for mission critical customer workloads and that it really entails predictability when we're making changes in the environment. Lots of changes are on the infrastructure team. Amar joined us in August. Lots of us had a chance to meet him. So welcome Amar, we're super excited to have him on board. And then we're gonna be very, very busy in November onboarding new members in the infrastructure team. Three SREs have signed up and then a new DVRE will start sometime in October. But we're super excited to have them on board. Again, we're gonna be super busy in November onboarding but it's a great problem to have. I'm very excited. Also, we welcome Jose, who's been with us since very the last day of August, early September. He joined us as the engineer and manager for SAE. He's been ramping up and it has been working on Postgres and essentially managing the availability team. So welcome Jose. Three of the four people joining in November are reporting to Jose. So we'll lend him a hand with the onboarding process. I want to talk a little bit about blueprints and designs. One of the things we're trying to do is to over-communicate what we're working on and what we're thinking about infrastructure work. And so these are the two areas where we're focusing. We started this section in the infrastructure page called Blueprints. We do a quarterly update where we essentially try to set up the priorities and the work we're focusing on for the following quarter. And we also published some topics specific to flesh out specific things. So for instance, we recently put out one about CI CD. The URL here, you can find it in the infrastructure page of the handbook. We're also starting to produce design documents. So we're writing out our thinking process about the solutions that we're trying to implement to address specific problems or implement ideas. We want to get better at driving decisions methodically. A lot of this work was already happening on issues but we want to have the result of the conversations that we're having in issues as far as how we intend to solve problems in a more cohesive format. And we want to be able to frame some of the technical conversations that we're having about some issues. The biggest rival for this is that complexity in the environment is increasing as GitHub.com gets bigger. And some of the problems we're solving we're having to make a better estimate as to a little bit of a better estimate in terms of long-term effects for these solutions. So we're trying to be more disciplined around documenting these. Q4OKRs, we finished the process of Q4OKRs and we're essentially focused, again, as I mentioned, on observable availability. I'm not going to go through all of these because you can read them in the handbook. But I do want to highlight some of them because they follow from work that we did in Q3. Specifically, we continue to drive availability improvements in the database in terms of backup restore verification and replication because the database is a critical aspect of the infrastructure. And then we're getting better at managing the infrastructure queue. Also, we use DO2, do the GCP migration and do as an integral part of how we plan on doing DR for GitHub.com. And then we're trying to get better and we're working on getting better at essentially managing our workloads and being able, again, to get more predictable on the amount of work that we can take on. And then we have some specific projects that Andrew is working on in terms of alerting our budget dashboards. He's also going to be working on distributed tracing and then he had done some fantastic work to deal with DDoS attacks in July and we want to essentially take that to the next level and polish that tool because it ended up being very, very useful when we were under attack. Moving on, there are three access in which we're doing some of this work and you can see the fleshed out version of this in the handbook blueprint. Culturally, again, we want to adopt more disciplined engineering practices, get better at change management, predictability of changes in the environment and adopting design documents as a way to essentially produce the design work that we're doing on how we plan to make changes in the environment. And also we want to drive this cohesive identity for infrastructure. The teams in infrastructure are made up of SREs and BDREs and so we're not the SRE team or actually the infrastructure team and there's a number of functions inside this team. Working on workload, workflow, how we decide what we're going to be working on with implemented milestones for the team so that we have a two week split focus on the work that we have to tackle. You'll hear Dave and Jose sometimes when you approach them to say, we'll work on this on the next milestone and they prioritize that work. But once we enter the milestone, we really focus on that work. And then we want to start doing some reporting on that work as well. And functionally, finally, we have functional focus for the database storage and observability. I've already mentioned some of the work that's going on in the database. We also want to focus on the storage nodes because they really hold the true most valuable data I think that we have and we do have some work to do to protect that data a little better. And finally, observability. If we are flying blind, we really can't assess the state of the environment. So we're doing a fair amount of work on that as well. Finally, I want to talk about this initiative that has been discussed in engineering recently where we're doing a push to essentially move our development process towards CI-CD. The end goal is to allow auto DevOps to deploy to get that.com. And that's a long pole and a very ambitious goal, but it's achievable because our product supports it and we know that there are customers using this. So we should be able to do it as well. The first step in that goal is to adopt CI-CD in our development process. And that entails not just some technical solutions, but also a lot of changes that we need to drive across engineering. So there's been, again, a fair amount of discussion in engineering as to what do we need to do to get started here? How do we align the engineering departments to start moving towards this goal? It's a non-trivial problem, but we know we can get there. And part of what we need to do is to commit OKRs that are related to CI-CD and to reaching this objective. So still working on some of that. We did publish a blueprint on essentially what this problem entails and why we want to get there. So more coming up, hopefully, on the next FDU on progress on this area. And with that, this FDU is complete. I will take any questions. Let me make sure to add open the comments section. Yes, I will make the edits so that the links are clickable. I don't know why Googlebot didn't make them, but I will take care of that. Yes, lots of Germany. Very excited. The Berlin meetup will be growing. Actually, infrastructure already had a few members in Berlin, and I am looking forward to traveling up to Berlin to meet everyone there. I've actually been trying to make it to... I know there are several, I guess, or co-working Fridays that I would love to attend. Just scheduling has been difficult, but I now have a great excuse to go to Berlin. We do every Thursday. Yes, I did find the dates. Just scheduling has been crazy, but I will make it one way or another. I love Berlin. Anyway, if there are no more comments or questions, as always, I'm available on Slack. The whole team is in Slack, so please always feel free to reach out with suggestions, comments, or just a coffee call. Thank you so very much. Have a good one.