GitLab Product Intelligence Think Big Sessions, 15 Apr 2022

Previous Meeting

⏯

youtube image

►

From YouTube: PI Think Big April 2022

Description

Topic: Decouple metrics computation from metrics collection
Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/357339
Think Big Epic: https://gitlab.com/groups/gitlab-org/-/epics/7823

A

Hey there, this is amanda rueda with product intelligence, and I want to walk you through the monthly think big sessions that we'll be hosting in product intelligence. So uh this will be our first session and I'm really excited about it. I want to talk to you about why we're doing it, what you can expect and then finally dive into the topic for this month. So why are we doing this?

A

um I'm coming up on my one year anniversary with product intelligence and I'm constantly thinking about how we can improve our product for our customers, both internal customers and external customers, and one opportunity I see: is we the product, as well as the dev team, could be working together more closely earlier in the dev and product life cycle? So typically, what happens today is somebody has an idea for something something that's recorded.

A

We have some high level product ideas that we're trying to achieve, and each of us works in our own kind of siloed swim lane to conduct specific processes along the depth cycle, and instead, what I'd like to do is capitalize on the idea of the product tree trio, which brings dev product and design into the cycle much earlier in the process, so that we're finding opportunities together we're discovering those opportunities validating those opportunities, and while we can't work that way efficiently for every piece of work we touch, we could certainly work that way for um the big, the big ideas, especially the complex ones, the ones that are not readily under um maybe understood or a solve, isn't readily um apparent to us, and so with the think big sessions.

A

I want to take a big problem and bat it around with the um with the development team with any guest customers that might be affected by it um and with myself and any other folks across get um so that we can kind of dissect it verify. If it really is a problem we want to solve and then um identify different ways we could potentially solve it.

A

We're not meant to leave a think big session with a plan for exactly how we're going to solve something and put it into the next milestone, but instead we're going to bring diversity of ideas to the forefront, to make sure that we're not thinking in a sideways manner to make sure that we are not allowing biases of experience to guide our thinking and to really challenge ourselves with being able to look at a problem in many different ways and find many different solutions to being able to solve that problem.

A

Then, with multiple solutions, um we would assign a technical spike in an upcoming milestone for somebody to take that refined those refined ideas further and then eventually we could put it into development.

A

So we're looking for big hairy, audacious problems to solve, for these monthly think, big sessions and um and that's the reason we're doing it in this manner. So what can you expect in a think big session? So, first of all we're distributed all around the world and we want to be inclusive of all of our team members. So one thing that you'll see is every month the timing of the session will change so that at least once every other month, um folks have a chance to join synchronously to the session.

A

But there are a number of async opportunities to to join and contribute as well, and that is um I'm pre-recording this session to explain what we're going to be talking about. So folks can maybe have start thinking about this asynchronously.

A

um You can jot down your thoughts in the issue even before the session happens, whether you plan to attend or not attend, um and you can start discussing as a group if you'd like asynchronously in the issue as well um after the session is complete, we will put the outputs um like an output summary in the issue, and I will tag the entire team and ask for additional contributions. So after a week of asynchronous contributions, we will then kind of call it um complete that phase complete.

A

We will take the ideas that the group decides are viable to explore and those will be scheduled for a future technical spike.

A

So that's um that's what you can expect, uh how you can contribute async and let's talk about the problem to solve for this session. So let me just do a quick screen share and so that you're not staring at me this whole time, but um just for purposes of logistics. We have an epic that explains the session format. So please go ahead and take a look at epic 7823.

A

Future sessions. Ideas will be documented here. If anybody has any ideas, please just drop them in as a um an idea in the comments and every session will have its own dedicated issue, and this is where you will be adding your comments. um I will add a a a thread here for you to contribute to async ideas.

A

Okay and so here's, where you're going to go ahead and start adding your ideas, okay, um so what is the the problem that we're trying to solve in april? So the first thing that we we're going to discuss is the idea of decoupling metrics computation from the service being collection. What does that mean so when we are pulling database sourced metrics right? So if we look at, uh I don't think I have oh here we go. So if we look at database source metrics.

A

um Many of these I don't know all because I'm not technically, I don't technically understand at all, but we have 830 of these database metrics, and I know at least some of them um are calculations right at the time that we collect service pain, and so one of the things that we've been chatting about is well if something times out.

A

um How do we allow the time out of that particular metric to occur without affecting the rest of the payload right, and so there are different things that we can do much lower barrier to to entry, less cost than this concept that we're talking about and think big. um But I want to take four steps back and say: well why not decoupling the metrics from collection, and so um I think the first.

A

The first thing we're going to try to achieve in our think big session is determine what outcome or opportunity are we seeking right really define the desired outcome, so in our first I think we we a lot um like five minutes, yeah, so, first five, ten minutes whatever it takes, um we're going to disc we're gonna discuss the problem to solve, which is: um can we decouple metrics computation from collections so that we minimize failure of the entire collection spread, processing, time um to minimize timeouts choose when and where to spend the compute time be intentional about when those things run?

A

um So we're going to talk about this question and we're going to identify what is the outcome as a group? What would success? Look like, okay, once we identify what success looks like we're going to start thinking about individual ideas to get there and before before we get to too deep in the process. I will also review this use case with you, and this particular use case comes to us from the composition analysis team. They frequently run into issues with their database service pin metrics one metric in particular is licensed man management jobs.

A

It's been failing for months, you'll see the um the issue that's been created here for that and the product manager from the composition, analysis team tells us that what they're trying to achieve is to write or up the counter right increase the counter by one every time somebody uses the license compliance feature for the first time and because this is a very popular feature um it constantly times up, and so, while we're not trying to actually solve this problem for this specific metric, we're just using this use case as something that may be positive positively influenced by separating calculation.

A

So this is a tangible use case that we can use to frame the question.

A

All right so now I want you to hear from the product manager that I spoke with um directly. So let me go ahead and share.

A

Here we go so here's nicole, and this is the problem. In her words, we end up with trash fighters, one trash fire being every time we try to record a license compliance thing, and this was just the one that was the noisiest child. So it's the one that comes to mind first, so way back when we had all of the different things that we were trying to record when this happened, because we were trying to compute in sas.

A

Was this a first occurrence and should we up the counter by one and license compliance is super popular for some reason I don't understand it would time out. It could not process that query in the rails without just dying, um and so we kept being told it's dying.

A

Why don't you use an estimation, and so we moved over to this estimation methodology and it would still time out um so okay, so that was nicole in her words um describing the problem. We appreciate that all right, so thanks so much uh for listening for hearing the problem that we're looking to solve. um Please do look at the issue and contribute either async or we'll see you at the session on tuesday. um Before we go, please make sure that you have access to mural because we'll be using that tool in the session.

A

If you don't already have access and you have not created an access request or you have one and it hasn't been closed, please create it and ping me in the issue. So I can get that expedited thanks a lot and have a great rest of your day.