Welcome to Season 3 of the podcast. Google's podcast about site reliability engineering and production software. I'm your host, Steve McGee.
This season we're going to focus on designing and building software in Esserie. Our guests come from a variety of roles both inside and outside of Google.
Happy listening and remember, hope is not a strategy.
Hey, everyone, and welcome to another episode of the podcast. Google's podcast about Esserie and production software.
I'm your host, Steve McGee.
And I'm Florian.
This season, we're focusing on software engineering and Esserie.
And today we have two guests to tell us a little bit more about observability, this time beyond just metrics.
There's plenty of other things out there.
We have Narayan and Pat. Can you both introduce yourselves?
Sure. So I'm Narayan Desai. I'm an Esserie at Google. I work on Google Cloud.
And I particularly focus on observability and efficiency stuff.
Hi, I'm Pat Somru. I'm a production engineer at Meta.
I'm working on a lot of things, but at the moment I'm working on a SCED-AXED, which is a cool scheduler thing for Linux.
Great.
So as I mentioned, this season is about software engineering inside of Esserie.
And so in the past, we've talked about operations and culture and different jobs and things like that.
But really, at the core of it, we're dealing with software and it turns out the best way to make software better is to write more software or change the software.
And that comes down to software engineering.
So it's not just fiddling the things that are already there but writing new stuff.
And one of the kind of base problems in operating in Esserie in general is like knowing what to mess with.
And this is where observability comes in.
So we have to understand the problem before we can fix the problem, as we say.
So out in the world, if you look up observability or even monitoring, you'll see like the three pillars, as they say.
So we'll see metrics, logs, and spans or traces.
Is there more to it than that? Or is that it? Is that the extent of what we've got?
Well, there's also performance data, which I think about traces.
So I guess when you say traces, I think about elastic APM, that thing where you're doing distributed observability across containers.
But that also applies to the binary level, inside of your application.
If you pull out your kit or Perf to see where the time is going.
And it covers the traces, but not necessarily.
So I tend to think about this more from the perspective of use cases, as opposed to the data.
So I'm an analytics guy, so I think about the way that you can analyze the data and the kinds of insights that you can get out of it.
And so from that perspective, those are the data products that you have, but there's a lot of different things that you want to do with them.
And I think that the interesting aspect of this, from the perspective of those data products, is the semantics that they have.
You fundamentally have time series data, and time series data has particular properties and particular scalability issues.
You have logs, which are fundamentally events.
And then you've got traces, which are fundamentally graph structures.
And if you think about observability data through that lens, then what that really tells you is that you need three different classes of approaches for analyzing the data.
Because if anybody's ever tried to wedge graph data into a relational database, not so great.
Same thing for time series data.

So to build on that, actually an interesting observation I had a little while back.
When you said there's different classes, you have graph data, yes, and you also have time series.
But in a way, it's a time series of graphs, which is, and that, I don't know, that's an interesting thing like, you know, how's it performing?
It's a graph, or what's happening?
That's a graph, but that changes over time series.
Like a graph changes over time?
Is that what you mean?
Yes.
And that's what actually folks care, or at least I've found that folks care the most about.
Like, why did this get slower?
Why does this cost more?
Well, that graph changed.
You know, you're serializing a timestamp versus storing an integer.
Yeah.
Yeah, I think those connections are really important.
And that really makes this, you know, from an analytical perspective, a multimodal kind of problem.
Right?
Because you have things that happen at particular points in time, and you have things that are happening in metric space.
And that's going to change the structure of the graphs that you have or the content of the graphs that you have.
And being able to connect those things actually produces a whole different set of insights,
which are fundamentally actually much more, I think, interesting and compact
than all of the other data products that we tend to deal with.
That's cool.
So if you're stuck in a world where all you can do is like make a table and an XY graph,
like maybe you're missing out on some fundamental insights into what your data is trying to tell you.
Well, I think that the hard part is getting to the table with the XY graph.
With all the data, like ultimately, that's kind of what you want.
You know, it's how many servers do we need?
How much, you know, how much is this going to cost?
But, you know, a time series of a graph needs to somehow eventually be translated into, you know, something actionable,
like whether it's a code change or a number of servers or something.
Yeah, and fundamentally, many of these techniques are really about taking complex data
and building it down into an insight that's simple enough to understand.
So, you know, one, you know, one story from a while back, we were doing some analysis work
and we were using this overly complicated machine learning approach for clustering
to try to make sense of performance data for a service.
And, you know, we spent a bunch of time tweaking this approach
and like building up the infrastructure and all this.
It was this really fiddly thing, right?
And once we found something in it, we started looking at it different ways
and we found that it was actually visible with a two component PCA,
which is pretty much, you know, basic stats 101 stuff, right?
It's, you know, effectively an XY plot, right?
And then what we realized is actually also the simple methods are the best sometimes, right?
So, when you can use the simple methods, you should use them, right?
But there's this siren song of new and complicated things.
But at the end of the day, what we need to do is we need to take this very complicated structured data
that's high dimensional and we need to turn it into a thing
that the human brain can understand.
And that's frankly simple insights.
You mentioned that and I actually, I found a similar one.
So, looking for, I guess, trying to query the data, which is hard, you know,
it's like there's a lot of data just asking that a query can be tricky.
You can, you know, if you want to make it easily, you know, readily usable,
that's another problem on top of itself.
But those simple insights, it's like, if you simply have a way of representing the data
where you can discard most of it, that actually sort of intuitively,
it kind of makes sense when you think about it.
So, like, you know, you write some library, this is your hash function, right?
You're going to use that everywhere.
And when you actually look at the graph, it turns out that if you discard, like,
I don't know, 90% of the data, you're still covering, like, you know,
something like 90% of your cost.
And then that enables you to, like, you know, do wild integrations with it.

So Pat, you just outlined one of the basic truths, I guess, of profiling
and sort of figuring out what's the performance of a particular piece of code.
So for someone that knows how to profile the inner loop on their workstation,
so to speak, as it were, how does that then relate to the distributed systems,
the bigger piece that we care about at CERES and production engineers?
It kind of does.
So I gave a, I had a talk at SRE Connellal Law Back about some tricks that I came up with
and we played with at work and whatnot to kind of address that, right?
So most folks, you know, don't know how to take perf and get a flame graph from it
or to optimize it.
Like, it's not the concern at the forefront of everyone's mind,
but you kind of need everybody to be a bit concerned about it,
sort of like with security.
Otherwise, problems happen and they can be expensive.
The way I found, the thing I was saying with make the data accessible
is that if you can reduce the data by, like, you know,
removing the parts of it that you know are so small,
you don't care about it so much necessarily.
And you can find a good way to represent distinct things.
So like, you know, you might think it's your binary,
you run perf on your binary and that's how your binary performs,
except for your environmental variables.
That can change.
So, you know, you have to consider the configuration of the system
and the hash of the source code and sometimes even build information.
But once you find the correct representation of that,
then you can do things, like, I don't know,
squiggly lines in an IDE or something like that.
You know, once it's an immediate look up, it's like, oh, for this line,
well, just put a little red here.
This line of code you're editing costs a lot of money.
Be very careful not to make this lower.
Or not it costs a lot of money, but it is ran many times per day.
So like, a hotness of the code kind of, you know.
So it's both a data processing as well as a visualization challenge in a way.
Accessibility, developer accessibility, I think.
Because you can't expect everybody to be able to pull out perf
and run it on some JVM code.
I mean, if you can even do that.
I've tried to use Orchid.
But you want to make it accessible to all developers
and kind of put it in front of their face.
Unless it is their job, in which case they're going to use perf
because they're not interested in your high level of removing the details
they care about.
But you want to make it easy so everybody can kind of, you know,
you move the ship in the right direction.
I feel, yeah.
So I think one thing that's kind of related to this
that's pretty important is, you know,
fundamentally engineering is all about building up mental models
of what it is you're doing.
And, you know, I think gone are the days where someone could expect
to understand all levels of the stack deeply.
And so you have more specialization.
You just have more things to know.
And so, you know, one of the key things that I think is very important
when you're designing observability is to really think about
the mental model that people are using.
And I think that there's another angle of this
that ends up being kind of interesting as well,
which is that we don't have enough meaningful models
of how we think about distributed systems.
And so to the extent that we can build more useful models there,
we can then give people a way to think about their systems
that are more useful than, you know,
I mean, I feel like a lot of SREs, the old adages,
just bad things happen all the time.
And that's true.
It's one perspective, right?
But there are more patterns in the chaos
that we can tease out if we start to model systems better.
And that often actually ends up resulting in,
if not less data, a lot less noise in the data
because you're measuring parts of the system
that are actually meaningful interacting components.
Getting better signal is definitely a way to win.
So one thing that I spent a lot of time thinking about lately,
having worked on observability for the last several years
is one of the key problems that I don't think
that we've really tackled well enough
is understanding noise and reducing it.
So we have all these measurements, right?
And you know, anyone who's actually tried to ever use
an SLO for something, for a complicated system,
knows that you have to deal with noise,
and it's a huge problem.
And there is some level of concession that people have to noise,
which is to say, well, we need to deal with the noise somehow.
And so if we set too stringent an SLO,
we're just going to get page to death for things that aren't real.
And what that costs us is that there are going to be some things
that are real that we don't see.
You know, if we set the SLO to some less stringent value.
And I actually think that that's kind of wrong.
I think that we should really be looking at observability
from the perspective of how do we reduce noise in the system?
Because if you can reduce noise in the system,
you know, from a fundamental perspective,
that allows you to see more things and see things more accurately.

So to give a really concrete example,
we've done a lot of work in the last few years.
And a colleague of mine, Brent Bryan,
and I gave a talk on this at SRE-CON,
I think two years ago,
in doing workload modeling.
So the work that we talk about there
is basically doing quantile estimation for performance
of discrete RPCs, basically.
So you know, any service has some amount of workload dependency
when you send it a request.
There are some big ones, there are some small ones,
some of them are fast, some of them are slow,
some of them are complicated, right?
And what this means roughly is,
some of your requests should take 50 milliseconds.
And if they run in 55 milliseconds,
that's not a big deal because that's sort of
within your standard deviation.
And there's some requests that should take 10 milliseconds.
And if they run for 55 milliseconds
then something is horribly, horribly wrong.
And so, you know, the experience that we've had
with trying to model our performance events that way
is that, I love insights like this,
fundamentally workloads matter.
Like this is not surprising to anyone when you say it out loud.
But when you consider workloads
in the context of your performance events,
that allows you to normalize statistical scores
for different kinds of workloads
and then combine them back together
to understand how your service is doing as a whole, right?
And this effectively allows you to control
for the effects of workload mix shifts in your service.
So, just to drill into that, the terminology around it,
like the workload, you're referring to like
kind of the inputs to the system matter,
not just the system itself.
So, like you can have one system that gets used
in three different ways based on its input pattern
and its measurable performance will be dramatically different
between those three different ways.
But if you just average them all together
and be like, this one thing has this one number,
then how does that help you, right?
You want to be able to discriminate
between the different modes that this one binary
or system or whatever it is, is running under.
Am I getting that right?
Yeah, that's absolutely right.
And it's not even necessarily one system.
It might even be one RPC call.
So, think about an RPC call that has a cache path
and go to the database.
Yeah, totally.
So, any system will change over time
and the proportion of cache hits will change.
And as that occurs, your average latency will change, right?
This may be meaningful, it may not be, right?
It's certainly something that you want to know about,
but you should measure that explicitly
and then try to understand the extent to which
if your cache hit performance drops by 30 milliseconds,
that's a thing that you would want to recognize
discreetly from your workload mix shifting.
Are you saying that you pull out these different categories
as dimensions, like after the fact?
Yeah, so basically what we do is we extract a bunch of parameters
that characterize effectively a cohort in the workload.
And whether you hit the cache might be a parameter
that goes into that cohort, as well as maybe the customer
or some other aspects that sort of capture
the differences between the discreet workloads.
And then we're able to use that to build historical models
that we can calculate quantiles on, for example.
That is very cool.
Yeah, I can say I've only ever tried to do it the other way,
which is know the inputs.
I think the highest level of granularity I went to is like,
a request is cached or not,
but that's pretty cool, different types of requests.
Yeah, that's cool.
Yeah, the example that you gave Narayan was fascinating to me
because you don't know if a request is going to be cached
when it enters the door, it depends on the time of day
and the last thousand people who made,
did they make a similar request or not?
But ideally, hopefully, you can know it after the fact,
in some sort of log entry or performance.
This request was the speed, and also, by the way,
cache equals true.
So having that data point, at least on the other side,
is something that you can then take advantage of later.
It doesn't help you predict things, I guess,
but it does help you classify that there's this one type of request
and this other type of request.
That's awesome.
That's a good way to think about it.
Yeah, and it turns out that this kind of a calculation
is really cheap to do.
So basically, what we do is quantile estimation
is sort of like calculating a z score.
And so if you know on a per granular cohort basis
what the mean and standard deviation of historical performances,
you can get a pretty good sense of what just happened to you
and then you can aggregate that using low cardinality metric systems
relatively readily.
So this gives you a good sense of what's going on.
It's not a panacea by any means, right?
But it allows you to answer a particular class of questions.
Et donc, de toute façon, cette technique est sort de intéressant,
mais ce que l'on a réalisé après le fait,
c'est qu'une autre façon de dire ce que je m'ai dit
est que les effets de la mixture
dans les services sont introduits en plus d'attentions de noises
pour tout les mesures que vous faites de cette surface.
La conséquence de ça, c'est que si vous pouvez contrôler
ces chiffres de la mixture,
vous pouvez réduire les noises substantially.
Et en fait, c'est ce que nous avons terminé de voir
en utilisant ces techniques plus en plus.
Donc, il y a beaucoup de volatilité native
que vous voyez dans une métro,
et ça a beaucoup de ceci.
Et ça vous donne une meilleure possibilité
d'understand quand les choses changent
avec beaucoup plus de sensibilité.
Et les increases que nous...
Donc, ma opinion ici,
c'est que par contrôler pour ça,
vous avez bien réduit le nombre de noises dans le système,
ce qui signifie qu'il faut faire moins de ces noises
vers les trade-offs de précision.
Vous devez toujours les faire à un point où vous devez
décider combien de travail vous allez mettre
en fonction des problèmes dans un domaine particulier
ou avec un métro particulier, ou autre chose.
Mais si vous pouvez réduire les noises,
cela signifie que vous avez moins d'une casine
envers les alertes.
Et cela est vraiment valable.
Et je pense que ça, vraiment,
s'adresse à la décision de ce que nous réalisez
après ce travail,
que ce n'est pas un plan master,
mais que nous devons commencer à penser
sur la réduction des noises
dans un moyen très expliciel et observable,
parce que, je ne sais pas,
personne ne veut être payé par ce qui n'est pas là.
Ça ne m'a pas aidé à measure la noise.

Et je suppose que l'une des aspects cool de votre métro
est aussi que vous ne devez pas savoir
si vous l'avez compris correctement.
Vous ne devez pas savoir
le performance expectante de votre cohort de travail,
mais que vous vous inférez
par l'observation et vous vous réagissez
contre la performance passée.
Oui, c'est exactement correct.
Et je pense que ça s'adresse à une des problèmes
très grandes que nous nous en avons pratiquement
avec des approches de SLO,
qui est que la calibration est superbe.
Ce qui vous donne
est l'obligation de comprendre la variante
sur un basis granulé,
et que la variante est calibrée
contre l'historique des comportements
de tous vos laboratoires individuels.
Vous avez encore des questions
de la mixation des effets,
et de quoi vous voulez promis
dans la décision de la campagne de SLO.
Mais ça vous donne un data
très différent,
qui vous permet de
savoir plus confinément
que les choses changent de façon
historiquement.
Et je pense que le risque est un peu
dans le rafraîtr de
essayer de mettre des problèmes
dans la campagne de SLO.
Le besoin de choisir un threshold
est un problème de difficulté substantially
en termes de
choisir un threshold pour un service
est très difficile,
car vous avez beaucoup de workloads
et la mélange est constamment changeable.
Et vous avez différents requières.
Et donc, quand vous vous forgez
dans une position où vous avez besoin
d'un threshold, vous allez toujours
choisir le mauvais.
Et les implications de choisir le mauvais
sont sortes de random, selon le custom
que vous parlez de. Vous avez choisi
correctement pour. Vous avez des customes
qui ont une meilleure surface
et qui généralement ne sont pas
les plus régressibles, car
votre threshold est passée par la régression
expérimente par le custom.
Donc, en fonction de la variante,
votre modèle de temps historique
s'adresse à beaucoup de ces problèmes.
Et en particulier, parce que
les thresholds très dracquants
sont en train de choisir la performance
et les thresholds de la réalité.
Parce que si vous avez une availability
de SLO, je pense que vous pouvez
faire un plus éducatif de
ce que vous avez à propos de
la réliabilité de la service,
mais les expectations de performance
et les requières
de différents clients,
ils ont une meilleure compréhension,
en faisant le tuning
plus tricot.
Oui et non. Je dirais
que nous avons commencé
par faire ça avec la performance,
parce que la performance est clairement
il y a beaucoup de preuves de magnitudes,
particulièrement quand vous regardez les services
d'analytique qui ont tout de la question
de très, très petite question, ou des queries
très longues, qui ont des minutes
ou des heures à faire. Vous avez
beaucoup de preuves de magnitudes de différence
et de la latency, que vous ne pouvez pas
même prétendre que vous avez des résultats
pour que vous aviez les choses ensemble.
Mais je pense que ça se termine
que vous voyez l'exacte de la même
comportement et de la mémoire de la disponibilité.
Et je pense que le fait que la variante
est plus petite a confié nous
en pensant qu'on n'a pas
le problème quand on en fait.
Donc, on va retourner au cas que je
parlais un moment avant avec des cash hits.
Imaginez que vous avez un RPC,
il y a un code de cash et un path
complicateur qui va au cas de la

Quels codes de cash
pensez-vous être plus reliant?
C'est certain que c'est le path de cash.
Parce que si vous avez un entry et un cash,
vous pouvez le retirer et le servir
en bas, ou en bas.
Pour ce cas, vous pouvez faire un simple
et compliqué tout.
C'est le plus petit nombre de step.
Il n'y a pas de réseau, pas de service.
C'est un truc qui va naturellement
être plus reliant.
Ce qui veut dire
que ce que nous avons toujours fait
c'est que nous avons toujours
avancé ensemble ces différents
cohorts qui existent
dans un grand service.
Ce qui va changer en temps
est que votre cash hit rate va changer.
Donc, votre rate de faillite transie
de mauvaises choses
dans la réseau
ou dans la base database
sera un peu plus prominent.
En général, ils ne vont pas être super prominent.
Ils vont probablement être
sous la surface de la noise
parce que des effets de la mélange.
Donc, nous avons pu l'ignorer.
Mais, je vais vous dire une histoire
d'un customer.
Il y a plusieurs années, je travaillais
sur un service et un des engineers
du service a reconnu
qu'il y avait un customer
qui avait une grande
relance hygiénique et la reliance
dans leurs services.
C'était le service de la service
et si il y avait un backlog,
sur ce sujet, nous étions pas
les customers.
Donc, on a fait
ce que l'on respecte
et on a commencé à l'alerte sur les backlogs
parce que c'était un bon indication
que le service a été broken.
Maintenant, nous allons retourner
à ce que je disais
des différents cohorts de granule
qui ont différentes propriétés.
Si vous vous rendez au part du code,
et vous parlez de quel customer
c'est, vous avez des customers
où leur accès à la surface est
100%
et si vous pouvez
calibrer d'un perspective
de l'availability
vous savez que quand un événement
de la crème de l'arônie s'envoie,
il y a un problème. Si il y a un workload
d'expérience normal
de la reliance, peut-être vous avez besoin
de quelques événements pour reconnaître
que c'est un problème.
Si vous avez un workload,
et vous voyez que quelqu'un
a un workload de la crème, et c'est
constamment de la crème et de la produire
d'erreurs,
la likelihood que ceci est plus broken
ne peut pas être une
ou une fois ou 100 d'erreurs
parce que c'est toujours de la produire.
Vous pouvez penser de manière
que vous soyez tous ensemble,
mais vraiment, je pense que la idée
est que ces systèmes sont les mixtures
de workloads avec les mixtures d'outre,
et vous devez modéliser ces expériences.
Je pense que c'est un
facteur de la disponibilité
et de la performance,
mais ce n'est pas très profond
comme ça.
C'est juste aussi utile.
Ça fait partie de ce que j'ai vu
avec les SLOs,
j'ai eu des services,
et j'ai eu des stats très très hauts.
Mais aussi,
beaucoup de complains.
C'est juste une question de breakdown.
Vous avez juste le point de breakdown,
et après ça,
vous devez breakdown le point d'incompréhension
que vous réalisez,
et trouver des paths de codes différents.
Vous devez avoir
la mentionnalité
dans vos SLOs et la surface
pour voir
si c'est un path
qui est en train de faire 100 %
mais qui est très infréquent.
On appelle ces problèmes
des nidaux et des haisthacks.
Une des choses que nous avons vu,
particulièrement avec les produits infrastructure,
c'est qu'il y a beaucoup d'interactes
que vous devez avoir
un nombre très petit qui représente
une combination particulière.
Mais si la combination est faite,
c'est une chose qu'on doit savoir et trouver et fixer rapidement.
C'est exactement ce point.
On a tous entendu des services micro,
et parfois, il y a des services nano
qui n'est pas qu'on ne sait pas.
Ils sont
absolument leurs propres
et ils sont petits.
Ils doivent les faire
quand ils interagent avec le reste de l'élément.
C'est difficile de voir.
Je vais parler de la caching.
Si vous voulez parler de faire des choses
merveilleuses,
quels sont les services
avec un rate très très bas
de caches ?
Comment vous vous rappelez
quand un problème est déployé ?
Mais
avoir cette mentionnalité
aide à la finir.
Je pense que c'est
un des places où on a besoin
d'un meilleur set de tools.
Historiquement, beaucoup de
les systèmes qui déclencent la time-serie
ne permettent pas de faire des breakdowns de la cardinale.
C'est un problème pour sûr.
Je ne sais pas si ça signifie que vous avez besoin
d'un système de time-serie qui peut déclencher la cardinale,
mais vous avez besoin d'un moyen de faire des insights de la cardinale.
Donc,
la chose que j'ai toujours fait
est d'assurer
que la dimension
de la mentionnalité est émise
dans le premier endroit.
Ce n'est pas suffisant,
mais c'est assez close.
On sait que c'est un casheur ou un mis,
ou juste de la preuve de l'exception
et de la preuve de l'observité
que quand vous vous en avez un,
vous avez une idée de ce qui peut être possible.
Oui, et je pense que c'est possible
que ce soit le bon moment.
Je ne me inquiète pas
que ça va s'assurer
que ce soit le casque de la cardinale
ou que ce soit le casque de la cardinale.
Pour faire un peu de la modélisation que je vous ai parlé
ce que vous en avez terminé
c'est ces vêtements
qui sont relativement longs.
Et si vous pensez à toutes les combinations
que vous voyez, vous avez
des millions de millions de cohorts discrets
que vous modélisez.
Et c'est donc nécessaire pour
les services de la pièce.
Donc, certains des défis que vous avez décrivé
sont en train de
avoir un certain nombre
de scales et aussi
les méthodes qui requient un certain nombre
de données.
Donc, pour des essais
qui ne sont pas exactement travaillés pour
l'un des défis
ces méthodes sont encore appliquées
pour qu'ils soient stillés,
pour qu'ils soient adaptés,
c'est votre recommandation pour quelqu'un
qui ne doit pas
faire des questions sur Google et Facebook.
Des questions de la possibilité.
Je dois avoir un petit peu
d'insights
là-bas.
Les problèmes que vous
vous devez avoir sont similaires,
mais différents.
Donc, c'est un peu plus comme,
vous savez, est-ce qu'on a pas de
observabilité à tout ?
Est-ce qu'on sait pourquoi c'est très lent ?
Est-ce qu'on doit se ficher en dessous
et faire des statements de débat
et de faire un tournoi ?
Je dirais que j'ai vu des outils
qui ont été utilisés comme des outils
qui ont été distribués pour les outils de observabilité.
Mon knowledge est probablement
un peu outdated, mais je me souviens
que l'alastique APM était très bien
pour aller à la maison.
Mais c'était une forme de APM
que je pouvais coucher
dans les services et être comme
« oh, on a un appel dans le service russe,
on a un appel dans le service java. »
Donc, juste de voir
comment les choses différentes
sont, comme de voir tout ça,
la interaction entre tous ces containers
et différents systèmes.
Je dirais que c'est
un bon
premier step pour un petit endroit,
c'est très petit, mais
il y a quelque chose.
Il y a quelque chose d'infinitement meilleur que rien.
Je dirais que ça pourrait être utile,
des gens.
Je pense qu'il y a aussi des choses philosophiques
qui sont très importantes ici.
Encore,
quelles sont les services
que vous avez en vous,
qui ont une sorte de purpose business ?
Et,
d'ailleurs,
que vous avez des questions importantes,

si la chose ne semble pas
un élément de l'analysation,
vous avez le meilleur à analyser.
Je pense que l'un des aspects
d'un service important,
c'est que les systèmes sont construits
parce qu'ils ont une sorte de purpose business,
pour les servir.
Et cela signifie que le comportement
sera plus stable
jour en jour et week en week,
que vous aviez anticipé.
C'est un des grands erreurs que nous avons fait
à Google,
en plus d'un moment,
nous avons dit que nous serions construits
un système de l'analysation
qui prend des codes d'utilisation.
Nous n'avons pas d'idée de ce que ça va faire.
Les clients peuvent évaluer
les codes qu'ils veulent,
et produire des systèmes
différents.
Fundamenta,
il ne se semble pas que
il y ait pas de nombreuses business
qui veulent faire quelque chose
nouveau et différent tous les jours.
Beaucoup de gens veulent faire
le même chose,
jour en jour,
et ce sont des procédures standardes
qui ont des workloads
de période.
Et donc,
il se semble que vous avez
des patterns consistantes,
des workloads
qui devraient être consistant
en temps.
Vous ne pourrez pas
pouvoir aller au niveau de la
fidélité que je parlais,
mais,
en commençant simple
et en commençant
à faire des analyses
en ligne de vos workloads
même si ils ne sont pas
un peu plus de temps au jour,
ça vous va vous donner très,
très loin.
Et donc, je pense que,
même si la implementation
ne devrait pas être nécessairement
travailler partout,
je pense que les concepts générales
sont les plus grands.
Oui, je dirais
que,
un peu plus,
mais aussi,
si vous êtes plus petit,
vous devez juste se placer plus tard.
Vous avez moins de données.
Et,
et pas seulement ça,
mais pas que les clients
ne soient pas importants
partout,
mais la chance
que ce soit un client,
que c'est la ligne,
comme,
vous savez,
votre grand délire est
sur la ligne,
et il y a,
la expérience
n'est pas sûre bientôt,

maintenant,
le loans sur娘 everlasting,









ligne mécant,
comme,
des systèmes de l'équipe qui sont responsables d'une certaine part,
ou d'un groupe,
ce que vous avez dit ici,
je me sens comme quelque chose que beaucoup de personnes que je parle de
qui sont en honte,
c'est qu'ils installent un outil d'observité de quelque sorte,
et ils vont comme ça, venir avec des dashboards,
et ils vont être comme,
« Bien, ce sont les métriques qui sont sur le dashboard,
donc c'est ce que nous allons interpréter. »
Et donc c'est comme une commonité de juste,
de la mesure de ce qui est disponible pour vous,
comme, en bas de la mesure de ce qui est facile.
Comme, les numéros sont déjà ici,
ils sont déjà sur un graph,
donc ils doivent être importants.
Mais ce que je vois vous dire,
c'est que, en fait,
ne vous décevez pas,
comme,
pensez à votre business,
pensez à votre trends,
pensez à vos clients,
pensez à ce que vous avez écrit en code,
comme, peut-être les choses que vous ennumeriez dans le code,
ne sont pas même étant montées dans le dashboard,
parce que c'est juste vous qui vous rapprochent de CPU,
de la haute ou quelque chose,
ça ne marche pas.
Et je vois beaucoup de clients tous les jours,
ils disent,
« Mais comment on va construire un SLO de la haute de CPU ? »
Et je suis comme,
« Non, ce que nous faisons ? »
Vous savez,
c'est un slope très solide,
pour être attracté à la métrique
que vous avez déjà devant vous,
et ça ne doit pas être une métrique,
comme l'indicateur,
ou quelque chose.
Donc,
est-ce que ça ne marche pas ?
Est-ce que ça ressemble à un thème
que vous vous avez appris ?
Absolument.
Je vois deux exemples de juste ce que vous avez fait.
Oui.
Un est un service,
un service,
je l'ai rappelé pour le moment,
où il a mis les verbes,
les verbes HTTP.
Oui.
Et, oui,
les bas dashboards,
c'est un,
un défi,
ça va aller,
une computation va être faite,
et ça va juste se dépasser
jusqu'à la fin de la réforme.
Donc, vous pouvez avoir
la plus importante datae de l'univers.
C'est déjà une présumption,
les verbes que vous avez mis
sont de la manière dont ils devaient être.
Oui.
Un code 200,
un défi,
c'est ça.
C'est un défi.
On le voit tout le temps.
Exactement.
Un code 200,
un défi,
ou un code 200,
mais pas de data,
et les verbes vont se dépasser
jusqu'à la fin de la date,
et ça ne marche pas.
C'est bien.
C'est bien.
Les temps de repos de la respiration.
Oui.
Les verbes sont bien vachement magnifiques.
Oui.
Vous avez l'expect de votre respiration
pour savoir si c'est un succès
ou un fail.
C'est super.
Vous pensez.
Et même sur ce que vous avez dit,
c'est que
ça peut être compoundé
dans les systèmes,
à ce point où c'est comme,
vous avez des interfaces
qui sont en fait
construites
par les choses
de la faute,
et puis vous essayez
d'introduire l'observabilité.
Et puis vous devez
commencer à regarder
un système
qui est observé,
et transmettre
votre usage unique de choses
dans les plus standardes
des usages
et puis
l'utiliser.
Donc, oui,
vous devez juste comprendre
en profondité
et regarder tous les opérants
comme directement
possible.
Donc, une chose que j'ai vu
par le respect de l'utiliser
plus de statistiques et de l'analytique
c'est que
tout le monde aime
des insights robustes
qui peuvent être utilisées
dans beaucoup de différentes situations.
Le problème est
que ceux ne sont pas réellement existés.
Right?
Et quand vous faites ça,
vous allez être surpris
et vous allez être surpris
dans des états de la même manière.
Et donc, une des choses
que je pense que nous devons
faire en profession
est vraiment
apprendre
nos ingénieurs
comment demander
plus de questions
de nuance.
Parce que, en fait,
en regardant l'exemple
que j'ai parlé
avant avec le rate de cash,
pour beaucoup de systèmes,
les changements
dans le rate de cash
sont vraiment sensibles.
Donc, le fait
que le rate de cash
change,
vous le soyez.
Mais vous aussi
le soyez
si la performance
des passées de la code
ou la réliabilité
de la passée de la code
change.
Et donc, je pense
que ce qui va nous causer
ce qui va nous faire
en temps,
c'est de vous demander
et de vous répondre
plus et plus de questions
qui sont très spécifiques
et de plus
de questions.
Parce que vous soyez
en train de le faire
et vous soyez en train
de le faire
et vous soyez en train de le faire.
Et au bout de l'heure,
une des choses qui est fascinante
sur la réliabilité des systèmes
est que
il y a une liste

que les clients
ne soyez.
Et nous n'avons pas
articulé
et nous ne le ferons pas.
Toutes les propriétés
de notre système
que nos clients soyez.
Nous allons les prendre
les grandes.
Et vous savez,
nous avons été les grandes
et les mêmes.
Mais
il y a toujours plus de travail
pour faire.
Et comme vous parlez
sur la réplique,
ou vous parlez
sur les propriétés
plus compliquées
de notre système,
nous devons
articuler
ce data
qui va répondre
les questions
qui vous suivent.
Et ce data
ne va pas répondre
à ces autres questions.
Parce que je pense
qu'il y a une tendance
pour aller
pour la dashboard
que vous avez.
Oh,
alors ce que j'ai dit
là-bas,
ce data va
seulement répondre
à cette question.
Ce
data va

une garantie
d'une question
d'exception.
Oui,
absolument.
Vous pouvez
définir
une erreur
d'un graphique.
Je pense que
ce sera
une des questions
les plus grandes.
Vous avez
ce data
et vous
vous gardez
ça.
Mais
je sais que
plus est
mieux.
Plus est
mieux.
Parce que
si vous comprenez
ce que vous avez
et comment vous utilisez,
vous pouvez gagner des conseils.
Ok,
donc,
on a parlé de la reliabilité
et de la
vitesse de système général.
Mais une autre chose
qui en fait
ne matters,
c'est que
est-ce que nous nous
avons beaucoup à
faire de la système
que nous espérons
et peut-être que nous nous payons
pour,
surtout
dans l'époque post-désert,
la performance
n'a pas vraiment pas mal.
Est-ce que nous
voulons
prendre du ménage
de la révenue
ou quelque chose comme ça?
Est-ce que c'est
un peu...

j'ai fait
un peu,
un peu
et dans les contextes
de petites entreprises,
je dirais que c'est
juste de
poursuivre
un profiler
et essayer de
comprendre ce qui s'est passé.
Parce que,
souvent,
les plus
simples et les plus
innocents des changements
peuvent cause
quelque chose de grand.
Un cash
commence
à
déranger
les strings
des séries
des séries
des séries
des séries
d'initialité.
C'est là
et il y a aussi
à la scale
où
il y a des
largees
numéros attachées
à des
changements de performance
et
même des changements
à travers le hardware.
Si vous regardez
la performance
des chips,
vous pouvez trouver
des générations,
des générations,
comme
la performance
de la function

de la performance
de la régression.
C'est
un peu
un peu
un peu

quand vous le voyez.
C'est
que,
wow,
ce test doit être broken.
C'est un très grand
différent.
Tout d'un coup,
vous regardez
en bas.
Oh,
les chips sont différents.
Et
ils se représentent
différemment.
Mais
c'est
définitivement
ça.
Et aussi,
je pense que
le hardware
est
utilisé
de la même manière.
Un projet
que je defended
plus paradoxiquement,
c'est














You know the CPU most local to your GPU is handling a processing for that GPU just keep anything's right place
Yeah a refrain I've heard many times inside of Google and I'm sure it's the same and other giant companies is that a
You know a small percentage of a very large number is still a very large number
Yes
And so like taking advantage of the scale and just being like as long as we multiply this tiny little gain by like a bazillion
It'll be great, you know so finding those is always gold. I think
Narayan, how about you any any good performance suggestions or tails?
Well, so so we've tried doing some interesting stuff with performance analytics
so one of the things that we we think about a lot is that
You know experts are great
But it's really hard to train an expert and so we really need analytics that will tell you about the things that you should go
And send your experts to look at
so we tried to build an interesting prototype where
we tried to build a profile over time of
the sort of busyness of tasks and
You know the the amount of time they were able to do real work as opposed to being blocked on something else
Mm-hmm
And so what that basically meant was that for a service
you could basically build a histogram or a CDF of the amount of time that the CPU spent waiting and
For a properly provisioned task
This would sort of like start low when everything was really uncontended and then level out at some level and stay level all the way
you know
To P100
Presuming you never got saturated and if you were under provisioned this would basically take off at some earlier point in the CDF
Well, if you were properly provisioned or over provisioned
You would never tail off at any point even even up to P100
Right and so the thing that we were sort of looking at there was you know, could we try to manage this?
Manage the band so that you could get some confidence that a service was properly provisioned
So this isn't so much in terms of like code performance
It's more a question of how many resources do you throw at a particular workload?
Autoscaling problem
It's kind of like an autoscaling problem, right?
But a lot of times the you know, this could potentially be a different metric for autoscaling
and so this ended up being an interesting sort of thing from the perspective of
Trying to understand when an application's performance had changed for some reasons and you should look at it, right?
So, you know like that case that you were talking about pat
where you started storing data in a different way and
Things got a whole lot more idle because you're waiting for more or you know, that's a time you want to be able to detect
Yeah, yeah, I mean once Wild is what is it? I think in that case
It actually looked like things a lot more was happening
I think it coincided with some some other logic roll out and it's like whoa, the computers has done so much work now
Ah
Work was a no op. That's how it gets interesting. It's idle idle can mean very busy
Yeah
We had a system one time that spent most of its time just context switching because all it was doing was managing connections
Between way too many backends and at normal like during the normal time like the things seemed fine in it
But as soon as we hit any kind of load, it just fell apart
We just went wait what's and it turned out
It was one parameter in one config file that was just set to too many back-end connections and change that one thing and everything starts working again
So systems under load can be drastically different from you know systems that semi idle
but having insight into
You're spending 80% of your time switching between threads
Right like even at low levels like that would have unlocked that but no one thought to look at that until it was too late
And until it was breaking under pressure. So I get it. Thank you both for your time
This has been awesome
Before we go if you would like you can tell our audience your fans
Where they can hear more from you on the internet if you have some sort of blog or
Other kind of presence in the world. Maybe you go to conferences. Maybe you I don't know have a
Wordpress or I don't know if people still have those things anymore, but how can people find you on the internet?
Social medias. What's that? Yeah, I've heard of it
I am actually largely a social media hermit these days. I have a bunch of inactive accounts fair
Yeah, I get it
Pat, how about you?
Like listening more than I like talking
Just be quiet. All right more podcasts for pat. We get it cool man. All right. Well, thank you both for hanging out with us today
Thanks to Florian for jumping in as a special guest host as well
And as always may the pager be silent in the queries flow. Thank you all see you next time. Thanks. Thanks
You've been listening to podcast Google's podcast on site reliability engineering
Visit us on the web at sre.google
Where you can find papers workshops videos and more about sre
This season's host is Steve McGee with contributions from Jordan Greenberg and Florian Rathkever
Le podcast is produced by Paul Guilimino, Sonny Chow, and Celine Virty
Le podcast theme is Tellabye by Javi Belcham
Special thanks to MP English and Jen Petoff