Welcome to Season 3 of the broadcast. 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 SRE. Our guests come from a variety of roles both inside and outside of Google.
Happy listening and remember, hope is not a strategy.
Hello and welcome to the broadcast. This is Google's podcast about SRE and reliable software.
This season, Season 3, we're focusing on software engineering and building reliability into your systems directly.
We have a couple of guests here that we'll introduce themselves in just a minute, but first off, I'm Steve McGee, reliability advocate in Google Cloud.
My co-host is Jordan Jordan. Why don't you introduce yourself?
Hey, I'm Jordan Greenberg. I'm a program manager in Google Cloud Platform Security.
Thanks. So we have today drumroll Sylvia Nile. Sylvia Nile, could you please introduce yourselves?
My name is Sylvia Bottros. I am a senior architect at Twilio currently.
My background is heavily rooted in relational databases, which tend to be the worst thing to make reliable.
And so I've been working with teams in Twilio for a while now on expanding that trauma that experience into reliability across the board and not just with relational databases.
Cool. Nile.
Very good. My name is Nile Murphy. I've made a long career with Failure.
Sometimes Failure or Downward, Sideway, sometimes Upwards.
I come to you from 70 and 80 years in cloud providers, including Amazon, Google and Microsoft.
Most recently, I am the CEO and co-founder of a teeny tiny startup in the reliability slash SRE slash infrastructure space.
And I'm probably most well-known in the outside world as the SRE Book Instigator.
That is a lofty title to have. The SRE Book Instigator.
Well done.
I'm sure that somebody that works on this specific podcast might have something to say to you.
We'll make sure to carry that info over.
Is that a threat, Jordan? What is going on?
It's like, oh, so it's you.
Excellent.
The thing that comes to mind when I hear Nile talk about the olden days when the book is the meme from...
I think it was the first Lord of the Rings movie where he says I was there again all 3,000 years ago when the war was first blah, blah, blah.
I was able to use that recently and I think it's my new favorite meme.
So it makes me feel old and I kind of like it actually, but I'm not quite as old as Nelf.
Anyway, why don't we get into it?
Reliability is often described as making the thing under your application just up more.
But I think there's more to it than that.
So I'm hoping today we can talk about the application itself.
And of course, the application is not just the front end.
In the middleware, it's also database.
Sylvia will teach us some things, but it's not just like get VMs with more nines, please.
There's probably more stuff than that, I'm guessing.
So I'm wondering if we can get started with those databases, because frankly, I know very little about them when it comes to reliability.
I've gotten away with being at a place where someone else takes care of that, which I highly encourage people to do if you can pull that off.
But how can they be bad?
What is unreliable about databases?
Weren't they solved at least 55 years ago or is it still imperfect?
Was that what's going on?
I mean, like everything in what we do, we keep hoping that it's about the technology, but it ends up being about technology and people.
And the people part is always very big.
One of the biggest challenges, especially with the relational databases and databases in general, actually, not just relational, is for quite a while as a field, we lean too hard towards what you described would make it someone else's problem.
She's running the databases.
The schema changes go through her.
The performance issues go through her.
If we think there's a database problem, we page her on being basically a human single point of failure.
Oh, no.
Personally, that little rock at the bottom of the XKCD comic.
It was not good.
There's a whole culture in the database engineering space that is thankfully now starting to sort of change a little bit where it was the DBA runs the database.
And here, the multiple risks there is it's not just the DBA, it's also the database.
We no longer build products that way.
It's we're way past the lab stack days, except for like one company that's still living that way.
And even that one company is not even one database anymore.
So big part of the risk there has been a culture shift before even the technology could come in the picture where you stop thinking about this is like there's just one person who has the magic incantations to figure out exactly what to do.
And it's more about you predict failure and you plan accordingly.
And therefore, you don't want a single database failure to dig down your whole product.
But one of the things that I that I made sure to do when I was given the big task of writing the fourth edition of high performance, my sequel after folks that I looked up to and learn from was to change that mindset where older versions of that book were about benchmarking and performance management and squeezing out the last bit of performance of your database and far more about looking at it as an SRE.
It's just specific databases.
You assume failure, how to assess the return on investment on the work you're doing in the databases, how to figure out the point at which the performance is acceptable, and it's not causing impact and don't spend more cycles there spend them and other things instead.
Nice.
When did you like notice that this cultural shift was happening like stop thinking about like the witch in the forest that has all the spells but she's been vanished to the forest because you know magic's not actually allowed in the town.
So when did you see this shift from that sort of like hey we have a problem with the thing that we don't know about can you fix it for us to this is now within our suite of tools and this is the way we debug it this is the way we monitor and manage it.
When did you see that how did you see it.
How do you support it.
So, I wish I could say that it's done.
It's still an unevenly distributed change.
I know of a number of companies where it's still very much like a small group of humans know how to do this thing and they're the only ones who do it.
Big part of it has been more and more sophisticated managed database solutions.
When you start introducing to the business.
Hey, you run this thing on that manage database and you reduce your toil by this much, but the trade off is now it's a managed service.
And you can't just have one person go into the box and do a kernel patch.
And now suddenly the IO is three times faster.
It forces teams to think about this in a very different way because your trade off the shape of your trade off becomes very different.
And you can't just be like I'm going to go and do it directly.
And then from the other side is for me personally, I was very much like at the beginning of my career databases, I was Milton with the red slingler.
Like I'm not going to lie.
I spent a good amount of time because it feels good when you're up and coming in the field where it's like oh, I own this like I'm doing this.
Therefore, I will do everything in this.
It was personally for me like a few of incidents and you know, a little bit of burnout sort of recognize that I can do this better if I don't do it the same way all the time.
I need to lift boats.
I need to educate a lot more rather than just constantly being like being called in with my red cape to go fix it when it's already broken in production.
So you went from a red stapler to a red cape.
I like it.
I like that too.
Not all heroes wear staplers.
Never thought of it that way.
I like that.
Yes.
We're going to mark that timestamp.
That's going to be the short.
There you go.
Nailed it.
So I presume there are websites in the world that are more than a database and I'm curious if Nile can talk us through.
I know it's hard to believe.
Talk us through how a system that maybe talks to database might deal with adding reliability to itself, right?
Maybe in the way that it talks to that database or other things inside its own, you know, logic bubble.
What are the things that teams can do directly to their code to make their system more reliable away from the infrastructure but actually in the code itself?
Yeah, it's a huge question.
And it's a very interesting one because of course coming back to the thing that you led with the start of this conversation, we often are primed to regard reliability as a question of interfaces.
And so when you disappear into an interface, you're kind of like, OK, somehow the complexity of the world is being pinched into a bubble for me and some thing or some word is handling that stuff.
And so it's all going to be fine, which is of course not true.
But the way in which it is not true is different to the way it is not true within your application.
Everything is a potential source of unreliability.
One of the particularly interesting consequences of Spectrum Meltdown, if you remember the controversy, that's the right word, the event around discovering that certain processors have the ability to leak information if they were programmed in a particular way.
That brought to the fore for a lot of developers the key point that, oh, actually I'm not really running on abstract stuff that adds things for me.
Like I'm running on a thing that has a definite structure and a lot of consequence and its design has meaningful kind of consequences.
So that was coming back to one earlier question, I think an interesting mindset shift for a bunch of people.
But anyway, we're accustomed to thinking of things in terms of interfaces.
Actually, it's not quite that simple, of course.
You can have unreliability in the simplest of functions.
I do a lot of tests driven development and I'm always amazed by, you know, I write a function that I think is pretty simple.
I write a test for it.
I'm like, oh yeah, actually, there's no way that could have possibly worked.
And I have a lot of reflections upon my own meager talents as a software engineer.
Anyway, long story short, there's a lot of things you can do with respect to reliability within the application and looking at it as a software problem or a software discipline or engineering, you know, questions of methodologies
Viewpoints that humans might take with respect to how to write software correctly.
They all start to come into the picture now.
But it actually ranges from things which might be considered extremely simple.
Have you considered checking the return code of your calls?
Wow.
That is a huge, exactly.
That is a huge piece out there, which is even today not necessarily being followed or paid attention to.
But it goes all the way up, up the stack to various levels of abstraction.
And so you can see within your application, you can bring in frameworks that are trying to use,
whether they're trying to make it easier to use stuff like Paxos or really high level abstractions around reliability.
My current area of interest is kind of a middle ground, which is frameworks to make addressing external and internal things on the other end of a T-Speak connection, essentially,
et plus reliable.
Et c'est une des choses qui me défendent les systèmes de la compagnie.
Mais la base est que quand tu es exigant une fonction,
la fonction a un certain nombre de pré-conditions, un certain nombre de post-conditions,
comme les choses que tu as prévenues après la fonction.
Mais selon la complexité de ce que tu es travaillant,
tu as probablement besoin de rappeler les fonctions,
vérifier les codes de retour,
avoir d'autres cas de constat pour les cas de la traînée, etc.
Mais tu dois assembler ces fonctions dans un moyen
où le programme vous aide à trouver des résultats de sécurité.
C'est un autre moyen de regarder.
Tu es en train de faire des récits, pour que l'outil soit bien.
Tu ne changeras pas trop de temps,
tu ne pourras pas dégager les données d'utilisation,
tu ne pourras pas faire des erreurs,
tu sais que des choses sont vraies et tu te le dis à la fin de la histoire,
en fait, tu ne le dis pas.
Sylvie, tu n'as pas de problème avec ça.
Je vais dire que j'aime vraiment cette approche,
parce que quand je travaille avec les équipes,
je pense que c'est un problème de reliant sur le database,
mais c'est un problème de reliant plus ambitieux.
Je vois beaucoup de choses.
En tant que ingénieurs,
comme Nile a dit,
on est prêts à penser à la code de la récité,
comme ça,
et si tu as fait le script dans ta tête,
plus en plus,
je le donne à X, je ne m'expecterai pas de Y,
et donc, en regardant,
est-ce que c'est vrai?
C'est un peu comme un coup de main pour beaucoup de gens,
je me reconnais que
tu peux faire cette code et faire ces procès,
mais si l'objectif n'est pas ce que tu as prévu,
et je me sens comme si ça était
très similaire dans ma tête
de comment nous étions toujours des gens
qui ont fait les tests,
mais c'est à un niveau de plus de niveau abstract,
d'un test unitel et d'un code,
ce qui me sent plus efficace,
parce que les tests sont très bons,
mais ils ne vont pas vous donner la grande picture.
Il y a des programmes de la paix,
et puis tout le autre.
Mais ça ressemble à beaucoup de travail,
mais ça se trouve, c'est important.
C'est assez drôle,
parce que j'ai vécu dans ma vie de la carrière
de la operation et des choses database,
et donc j'ai vivé toute ma vie
dans la production de la merde,
et puis, en essayant de
aligner ce mindset
avec des ingénieurs qui disent
que le code IY est de la production,
donc c'est bon.
Et c'est comme, oh non, mais
tu as vécu le code et la production,
et puis d'autres choses ont été réalisées.
Et comme vous avez dit, le path de la paix,
c'est un sort double,
mais j'ai toujours essayé de venir
quand je travaille avec des équipes
sur un document de design,
ou un plan pour comment faire la construction.
Je suis généralement
ma réputation interne,
et les entreprises ont été,
je vais venir, je vais être
comme, prends cette partie,
c'est plus, c'est plus
un plan paranoide que le plan de la paix.
Et c'est
les deux choses qui
sont toujours un peu intentionnées,
mais vous avez besoin de les deux
pour avoir des outils plus bons.
C'est comme de
pour un tour, et puis
vous repassez, et puis
vous repassez dans une configuration différente,
et puis vous vous endvez avec quelque chose,
mais la prochaine fois vous savez mieux
comment vous repassez.
Peut-être que la prochaine fois vous allez avoir un go-back,
sort de dans cette façon,
en pensant sur ce que vous vous en faites
pour le test pour se faire avancer.
Pour les deux de vous,
il y a beaucoup de raisons que vous pourrez
introduire ces types de changements,
ou des improvements.
Certaines peuvent être bornes
par Niles' préféré de failure,
ou des autres raisons,
motivations au sein de votre contrôle,
ou des raisons de l'héritage,
ou des choses qui vous permettent de changer
ces choses. Est-ce un improvement technique
pour impliquer ou changer de changement?
Comment de nombreuses fois
des choses bornes par un outil
vers un outil qui veut
éprouver quelque chose?
C'est ouvert pour les deux de vous.
C'est un peu plus outil.
Ou comment devrait-il travailler?
Comment vous suggèrent que les gens apprécient?
Une question très grande.
Ce qui est généralement le outil est outil.
Ce que j'ai essayé
de faire est
de le faire au niveau
qui ne vous permet pas de
résoudre le outil qui a été apprécié.
Vous voyez comment le outil qui a été apprécié
peut se passer d'une autre façon.
Vous vous rendez dans un bon endroit,
ce n'est pas la seule façon de vous avoir
dans un bon endroit.
Vous vous rendez dans un endroit où vous réalisez
que vos backups ne fonctionnent pas.
Il y a beaucoup de différentes manières
pour se faire comprendre
que peut-être
apprécier un
test de backup.
Ce sont des exemples très simples.
Il doit être de cette façon.
Il y a aussi des choses qui ont
passé d'outils de la route
où la première chose qui vient de la main
est la version complète
et la version de résidence
que beaucoup de nous devons
faire, et surtout quand les entreprises
se créent.
Ce sont des choses qui ont tendance
d'être plus hypothétiques
ou que
Audit X nous dit que nous devons faire
ceci.
Je pense que mon réponse est
que ça dépend, ce qui est un bon
peu de réponse pour le principal
enjeu, plus ou moins tout.
On a vu ça.
On devrait savoir comment
c'est fait.
C'est un de ces deux.
On peut les raconter.
Donc,
mon version particulière
qui dépend en ce cas est
relative à
toutes les choses sur l'ingénierie
culturelle. Vous pouvez être
très producteur
envers un
product
pour un meilleur mot.
Vous pouvez avoir des features
qui vont dans le backlog.
Vous n'aurez pas la chance de voir
où ils vont.
Il y a des choses qui répondent
du spectre et du meltdown.
Ce sont des engeneurs de software
dans le monde qui se faisent
rapidement, pour répondre
aux incidents de sécurité.
Ce n'est pas changé
dans les 6 ans de l'intervenu.
Il y a
beaucoup de raisons
d'entraîner
pourquoi ça peut arriver.
Un intéressant,
qui est souvent pas discuté
est la réponse au complexité.
Parce que l'une des choses
que nous faisons dans le space de
la réliabilité est que
nous sommes en train de faire un diagramme

Je ne comprends pas ce que je peux
et je ne pense pas que personne peut
simplifier ça.
La simplification peut être une réponse
à certains problèmes de
la réliabilité qui sont de la complexité.
Bien sûr, la simplification
peut être faite dans un nombre de moyens.
Une extrêmement commune
de la réliabilité est de
faire des trucs incompréhensible.
Maintenant je vais le mettre
derrière un API.
Maintenant je peux l'inquiéter
qui a des problèmes
comme la clause que personne ne veut
ouvrir.
Les problèmes que nous avons discutés
avant, il y a un autre moyen
qui n'est pas vraiment
fait dans la réliabilité qui est
de se tourner
ou de arrêter les choses
ou de dépréter
les choses ou pas juste de dépréter
mais de les faire
et
évidemment,
les détails
qui ne sont pas compétents
les détails
de comment ça fonctionne
ils ont beaucoup de choses
mais l'une des choses
que je suis en train de le voir
est que les implications
de la réliabilité
sont très importants
avec les initiatives de simplification
et vous pouvez dire que
ceci ne reproduise que 5% de nos
incomees et ça m'a dit 10%
de faire le bon travail
ou de faire le bon équipement.
Un question que j'ai
c'est de dire que vous avez un service
qui est plus mouté
et plus réliable.
Ce n'est pas dans la category 5%
10% que vous avez décédé
mais ça nous fait du mal
et c'est un peu problématique
donc on devrait peut-être
faire ça mieux.
Dès quelque chose où ce n'est pas
totalement bloqué mais c'est aussi pas le meilleur
est-il un espace magique
que je peux utiliser pour convaincre
mes bosses que c'est
un temps de valeur
?
Est-ce que la réliabilité
peut être préditée
ou est-ce que ça soit préditisé
quand il s'agit de la mécanismes
que les entreprises
dans le monde ont tendance à avoir ?
Je pense que ce n'est pas toujours
évident que c'est la bonne chose
pour travailler.
Est-ce que c'est vrai ou non ?
Qu'est-ce que tu penses ?
C'est un peu de la mécanismes
qui ne sont pas les données.
Tu as demandé le nom
dans les wards ?
Je l'ai dit quelques fois dans ma vie
mais il a maintenant sa main.
Oui, très bien.
Il y a deux réponses.
Le répondant industriel
et le répondant
que j'ai déclaré
dans l'année prochaine
qui j'aime beaucoup.
Le répondant industriel
est un commun qui est
OK, quel était
la faute de
les dernières 10 outages
de ce type
par exemple ?
Rassimilément, pas adressant
ce qui nous coûte
plus que
plus que
moins que x,
c'est un
rampant simplification
d'une très grande
et typiquement social interaction.
Et parfois, c'est
un business qui est relativement.
Le répondant
qui est déclaré
plus récemment, c'est
plus intéressant, même si
ce n'est pas nécessairement correct.
Il est basé sur un piece de
research par Microsoft.
Ce qui a été
déterminé
pour un produit
qui a été déterminé
à peu près une troisième
de tous les features
étaient positifs
quand implementés, c'est-à-dire
qu'ils ont déclaré le nombre
d'accords ou d'adresses
ou tout ça.
Et ça nous a fait

qui a été neutral,
qui a été
négatif
pour les gens
d'assurer le produit
ou ça coûte plus que
cela, et ça
et si
nous étions
dans un monde de policy évident
nous serions
en train de faire attention
et de dire, 66%
de l'heure, votre produit ne va pas
faire ce que tu penses que ça fait.
D'ici, j'ai un fixe pour votre infrastructure.
Ça va faire le truc que nous pensions
faire. Comment on
élimine votre produit pour ce
qui, en général, sera correct?
J'ai pas de conversations.
Je me suis dit que c'est le problème.
Ça semble être un plan parfait.
Si seulement toutes les VPs se sont posés à ça,
ça va bien.
Il y a des nuances
sur comment tu pourrais addresser ça.
Mais je pense que
l'intuition que
les quotes sont pas très bonnes
en en savoir ce qui va arriver
avec le software après que nous avons écrit
ce qui est bien sûr,
le software est un truc compliqué, le monde est un truc compliqué
et tout ça.
Tout ça en étant vrai,
tu voudrais dire
généralement, pas toujours,
mais généralement, le travail de la réliabilité
a un genre de scope
qui permet
de être interprété.
Le résultat est de être interprété
plus bien
que le travail de la fonction publique.
Donc tu pourrais traduire
un scope beaucoup plus grand pour un scope narrow.
Maintenant, tu as
les implementations
ou la réliabilité,
qui est une nouvelle structure X,
ou un rétrofit de paque
dans ton modèle de données,
ou un style de la réglage de horror,
comme ça.
Mais généralement, je pense
que nous devons faire plus de petitions
pour
la simplification complexe
et tout les autres choses
que je parlais de l'intérêt de la recherche de Microsoft.
Je dirais
que mon réponse
est, bien, tout d'abord,
je me souviens toujours de
les recherches, je vous le souviens,
vous vous souvenez de ce paper, et j'aime ça beaucoup.
Mais ça vient de
ce que l'on est dans le système.
Assumez que vous avez
une leadership supportive
qui est une simple chose
d'un podcast, mais c'est une question
très réelle de l'une entre les autres.
Assumez que vous avez une leadership
qui veut vraiment comprendre
comment assurer ces traitements.
Une des choses
que j'ai vu dans les dernières
années, qui ont vraiment
apprécié la conversation
sur ces choses, parce que finalement
on sort de essayer de
quantifier des choses
comme si je change
ce que je vais faire en plus tard.
On essaie de s'appliquer
des mesures pour les choses qui
sont en train de forecaster le futur.
Et une des choses que j'aime vraiment
beaucoup, c'est les métriques doramétriques,
je suis certain que c'est la même
Château de Dr. Forstgren, parce que je sais que le paper
pour Microsoft était aussi sa travail, je pense.
J'espère que je ne vais pas le faire mal.
Mais les métriques doramétriques sont une des choses
que je sais
ont évolué par la
assaisonnement annuelle que nous voyons
chaque année, mais
à leur coeur, et je vous recommande
le livre Accelerator, parce que ça va
beaucoup plus bas à pourquoi ces sont les métriques
que j'ai terminé par là,
ça peut aider les leaders à quantifier les choses
comme, ce n'est pas juste que
ce service nous a fait du mal,
le team qui a appelé pour ça est
un peu scère de changer,
c'est un feeling squishy
que si tu couples avec
quelque chose comme
Change Failure Rage, c'est une des métriques doramétriques,
tu commence à voir des données
chaque fois qu'ils ont fait un deploy
quelque chose de petit
et puis chaque 20 deployés
ou quelque chose de grand
et donc, le team
s'en fait confiance en faire des changements
pour le service qui fait que beaucoup de money
est décliné, ça doit être adressé
et ça devient, tu commences à appliquer
un peu de meilleures
mesures pour les choses qui sont plus
squishies et senties.
Oui, je pense que dans le passé, on a toujours dit
que chaque domaine est sa propre
spéciale snowflake, donc comment on peut
pouvoir comparer ces données?
Mais je pense que Dora et Accelerator
nous ont donné des bonnes numéros
et ils disent, oui, elles sont toutes spéciales
mais elles sont toutes les choses
en train de faire des compétences, donc on peut
measure cette partie.
Alors,
peut-il vous parler
dans la lens
de
construire des choses
pour soutenir la reliant?
Quels sont les spécifiques
qui ont déjà été donné
nous pour nous aider?
Par exemple,
d'exponentiales, de la reçue,
de la règle, de la règle,
de la chute, de la stuffe.
Nous avons des magiques ici.
Peux-tu parler de
cette magique, peut-être des magiques
de votre préférence, ou un exemple
de quand vous avez utilisé des choses comme ça
pour accomplir un goal de la reliant?
Il ne sera jamais sans doute
que je ne suis émaisie de combien de temps
et de diverses manières,
une entreprise peut avoir un incident
parce qu'ils ont interprété un dynamique d'O.S.
Non, comme...
Le système A fait ceci
et le système B n'a pas de clous,
ce qu'il s'agit de la fête, et boom.
Je veux dire,
ne laisse pas...
Je sais,
le call est venu de l'intérieur de la maison.
Oui, et le truc que je disais aux ingénieurs
quand ça se passe, c'est pas que
cette manière particulière
va se protéger, c'est que
ça va se passer, il faut être
plus paranoïde. Par exemple,
ne laisse pas un call de log
être synchroniste.
Réguisant un logline
ne devrait pas s'assurer ton service.
Réguisant un metric ne devrait pas s'assurer ton service.
Maintenant, il y aura des choses
qui doivent s'assurer ton service.
Tu es en train de faire un line à un database
et le database n'est pas là.
C'est une raison valide.
Et pour cela, tu penses
comment vite tu peux faire un call.
Tu as besoin d'un single writer database.
Qu'est-ce qui se passe si tu le switches
à un database qui est plus
disponible que consistance orientée.
Il y a d'autres choses,
mais la façon dont
les mêmes smells
sont en train de se passer
me surprise.
Je pense
que c'est un peu
comme en utilisant une des analogies
d'arrière.
Si tu penses que les calls de l'orPC
sont des calls stacks externalisés
pour un machine
et un computer,
chaque fois que tu parles
d'une autre fonction, tu fais un call de l'orPC.
Mais je pense que
tu as tendu à oublier
qu'il y a
une chaine de call
qui est
un stack de software
qui peut
et devrait être regardé
comme plus compliquant
que de la pêche
ou d'un autre pour ta application
mais en fait,
comme un sujet de réalité observée,
c'est vraiment très difficile.
Et c'est particulièrement très très difficile
dans les cas où
tu es en train de te doser
dans les cas où le management de la

devrait être un très puissant
pour tu contrôler
ton call stack mais pas
parce que tu n'as pas les tools etc.
Donc, nous faisons
un bon limite pour les services
et un peu de choses.
Et donc, un bon limite
en termes de
pouvoir, en vrai temps,
contrôler
et
prioriser en particulier
différents call stacks
sur l'autre est
une très underuse
de la capacité
de software. Il y a
beaucoup de choses à l'open source
qui font des pièces de ça
mais la plupart
ne pensent pas
les cas de doigts.
Bien sûr, en commençant,
en parlant, tu es comme
Hey, si je suis dust, mon truc est populaire, excellent,
c'est fantastique. Et puis
tu te laisses un peu
en pleine ronde, des gens qui disent
je vais aller chez ta compétition et je ne vous le verrai pas.
Ils ne vous croient pas maintenant.
Ils ne vous croient pas maintenant.
En fait, comme une sérénur,
je pense que nous,
comme profession, ne sommes pas vraiment
d'étonner le respect de l'accès
et nous ne sommes pas sûrs
de quoi ça cause pour être perdu
complètement, et ce qui cause
pour être le plus stupide, etc.
Il y a beaucoup de nuances, je pense que nous ne sommes pas
d'accord. Mais le
management de la carrière de la carrière,
la prioritisation,
le chède de la sérénur,
particulièrement la sérénur de la clientèle,
où tu peux arrêter de vendre le travail
plutôt que le travail
juste arrivant à la machine,
et ça doit être désirulisé
et faire des décisions
pour se dédouer, ce qui est plus de travail.
Tu veux vraiment contrôler la clientèle.
Toutes ces techniques
sont très techniques,
qui sont utilisées en utilisant.
Une des différences cruciales
entre les gens qui sont écrits
dans le management de la carrière
et la tradition de la carrière,
est que souvent, ils pensent
très bien, gréant,
de la minutieuse
de la carrière que ils tentent de déployer.
Mais la picture de l'hélistique est souvent
pas faite, et en fait,
ils ne sont pas réwardés
pour la picture de l'hélistique nécessaire.
Maintenant, cette picture est compliquée,
le staff de la carrière
tend à se déployer un peu plus horizontal,
mais par rapport à ces différences,
qui signifie
que les gens qui ont été écrits
dans la tradition de la reliabilité
ont souvent un peu d'église de
les défais de la casquette,
des suprimations de la balance
de la load, je me souviens
d'être déloué quand je l'ai trouvé
que un système
pouvait retourner
500 plus vite que
le data légitimité
que c'était, en fait,
qui signifie que ces systèmes
ont attracté
plus de trafic de la
configuration de la load balance
la plus basse de la lait
en temps, mais pas le jour après
ou le jour après.
Donc, il y a beaucoup de
des choses qui sont subtiles.
Mais, je pense que
ce n'est pas le cas.
Une chose qui a été
déclenché pour moi,
c'est un bon
point que, maintenant,
dans cet état,
je me souviens
d'avoir écrit ce blog
sur le principe d'un ingénieur principal,
et la réaction que j'ai
appris c'était, wow, c'est cool,
et je me souviens vraiment que
ça serait nouveau, comme ça,
mais, une chose,
je sais, mais ici est le point,
quand quelqu'un
s'est promos
dans leur IC Ladder
de
un ingénieur principal
c'est pas comme le jour après qu'ils se sont
appris le système,
je veux que ça soit le cas, mais ce qui s'est passé
c'est que, une des deux choses,
tu vas arriver à apprendre comme ingénieur
et j'espère que beaucoup de les gens qui sont
intéressés à entendre ce podcast sont en train
d'apprendre ces skills.
Une de les deux manières que tu vas apprendre,
c'est que tu vas either live through
some really traumatic incidents
in production, that teaches you
how these things can happen,
how those cascading effects can occur,
or you go learn from other people's
experiences, drama,
how they did it, and sort of
always keep an eye out on the patterns.
And my hope is that more and more folks
learn these skills the second way
rather than the first way,
that we're also going to be slogging through incidents.
That's a great point.
And the hope is you don't.
Given that, thank you for the perfect
lead-in to my next question.
My question really is, if we have
all of these tools that are possibly
available to us, should only we get them
and use them and be proficient at using them.
And we have these systems we don't really understand perfectly well.
Do we have to wait for incidents to happen
to be able to know which tools to use
where, or can we look at other people
what they are doing,
what they've done, and maybe kind of
make an educated guess?
Or is there maybe something else we can do?
I'm curious if anyone has seen
more formal tools, though I've seen
things like TLA+, there's a system
called Stamp, not a system, but a methodology
called Stamp out of MIT.
Are these more formal systems ever
helpful in helping you determine
how the system might better be controlled
in the future? This is like
proactive getting in front
of it approaches.
Yeah, actually I've used
TLA+,
myself a bit,
and the number one person to
talk to about this is Hillel
Wayne,
who runs a consultancy
and does training, and I actually have
the benefit of a small amount of training with him,
but he also does a newsletter on
software and computer things generally,
which I highly highly recommend.
Anyway, a plug over, reasoning
formally about your system,
the set of transactions that can happen
to the tree in post conditions,
and so on, hugely, hugely
valuable in terms of
the complexity
of the space that you cut off
by making sure that your system
can't get into undefined or weird states,
or well, maybe making sure
but reducing the probability
a lot. I do believe
there's serious things, and in fact
it's not a matter of belief, there's serious
benefit to doing this kind of stuff.
In terms of your other question,
which I'll deal with only briefly,
with respect to, is there anything that we could
use to help determine
where we would spend our reliability dollars
or infrastructure or frameworks, or however
you would think of it, there's a huge tradition
in the
incident analysis, post-incidence
and response space, etc.
that tries to,
I suppose address some of these questions,
I am afraid, hand on
heart, I'm
definitely, and it depends
person in this context.
There is lots
of frameworks to use.
There are kind of
bicycles for the mind style
things, typically speaking,
but there is a cost benefit to them
and I don't think there's
an algorithm to choose these.
Anyway, that's where I am.
So, I'll take this question back to
like, it's not first about
the tool, it's first about the people.
This may be a shock to this audience,
because we're all steeped in this, but I still
routinely encounter teams where they just
don't think they need to spend
time sort of preparing for incidents.
Whereas, they've just
accepted that incidents happen to them.
So, getting folks to just get out of that
mindset first is probably
like, jump number zero.
Having gone to that, one number
of the things that I recommend to teams
that I've seen actually been very useful
in the past is
try to, like, first of all,
one of the things that are
very up and coming in the field right now,
and a lot of people are sort of taking on is domain design.
You start off, like,
if you are a company that has grown
so much that you have multiple products,
you cannot continue with those
products, just like have hazardous flat
network talking to each other, because now the
space of possible failures becomes
untenable. Now, I understand the risk
of what Niles explaining earlier of like
you can't just shove things behind an API and call it good.
But there's a happy medium.
You need to find the Goldilocks where you shove
the parts that actually make sense together
behind APIs, and so you can
separate making those individually
reliable and then separately
figuring out the cross communication
being more reliable.
At minimum, there, you start gaining things
like blast radius mitigation
when actually things break.
One of my favorite things to do
with teams are things like table tops
where once you know what your domain looks
like, you start talking about,
okay, traffic is 10x.
What's going to break first?
We don't even know. Okay, well, we should know.
So things of that nature, like the
hypotheticals that you probably
will have a hard time testing in reality
in production, but you should think about
what are the parts that need load shedding
more than others? What are the parts that are like?
Yeah, this is probably, like,
you start recognizing, oh, this service
that is in the middle of every single call
hot path is probably
2x away from having way more failures.
What's the ceiling of its performance?
And we start talking about, this is how
you start recognizing things like
if we don't start planning for rewriting
this thing now
in a year, we're going to have a lot of
incidents and by then it'll be too late.
Because a lot of times, and this harps
all the way back to customer trust because
by the time the customer walked out the door,
it's too late.
So, you know, you don't want to
find out how many incidents it will take to lose
hatched customers.
That's not a number you want to find out.
You want to just, like, never get close to that number.
Right.
We are unfortunately running out of time,
so we have some time for some very quick
questions for you.
Where can we find you on the internet?
Ooh.
So, I used to be fairly active
on the formally known
artist's Twitter, but I don't
anymore.
I suppose at this point, my blog
is on dbsmeshore.com
and a lot of what I explain
if you're interested in it, specifically in a
database lens, go find
Hyperformis MySQL version 4.
It was a lot of fun to write with
my friend Jeremy.
Awesome. Nile?
I am still on the
artist formally known as Twitter.
I am on LinkedIn.
You can find my company at
www.stands.systems
and I also keep
a blog on reliability issues,
which is out of URL search
for my name, kind of,
like, maybe it's the 17th result
or something. I'm really selling this.
I'm telling you, this is cool.
Definitely.
Go read his book.
I keep telling folks, the SRE handbook.
Go get that too.
Awesome. Well, thank you to
Nile and Sylvia, my co-host Steve
and the Witch of the Woods for this episode
of the podcast. Have an awesome day.
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
Rathgeber.
The podcast is produced by
Paul Gullimino, Sonny Chow
and Salim Virty.
The podcast theme is
Telebot by Javi Belcher.
Special thanks to
MP English and Jen Pedoff.