Salut tout le monde, bienvenue à la fête de la fête de la podcast.
Google est un podcast sur la compétition de l'engineering et de la production de la

Je suis votre host, Steve McGee.
Cette fête est de nos amis et de nos taux de la France.
C'est tout pour ce qui est venu dans le space de la SRE, de la nouvelle technologie, de
les processus modernisés.
Et bien sûr, la partie la plus importante est la fête que nous avons faite.
Alors, bonheur de l'entraînement et de la souhait.
C'est pas une stratégie.
Vous m'avez mis la fête sur le niveau de la fête.
Bienvenue à l'épisode de la podcast de Google, le podcast de la production de la production de la SRE.
Et nous allons dire que nous avons un guest qui est de la fête de la première saison.
Jessica Théodat.
Jess, salut.
Salut, Jordan et Steve.
Merci d'avoir moi en revanche.
So Jess, you have a foot in two different worlds, I believe.
Security and reliability, everyone's favorite two worlds.
These are the things that keep things going.
Is that am I right about that or how would you better describe?
How would you better intro yourself than my silly analogy that we just did?
Yeah, no, no, for sure.
So definitely in the two worlds, I guess one way to pitch it is that I'm a
security focused reliability engineer to kind of break that down.
So I'm on Prem, so I primarily focus on infrastructure and systems for Google's premises.
So that includes things like data centers in offices, locals, Colos.
And in terms of responsibility, my role is to identify and assess and mitigate potential problems.
And it's not strictly go to just security.
I take a look at the bigger picture, right?
I look at the potential effects of the bigger picture and we'll we'll
dive into that a little more later, hopefully.
So when it comes to risk management, it's not all one size fits all.
And so fundamentally, the translation of security risks and reliability risks
to business impact is highly contextual, right?
And so the idea is that I help stakeholders in their teams understand
what those risks are to their businesses, help them prioritize it
and implement strategies to address.
Nice. OK.
I thought it was funny that you said on Prem,
because I know when people think of people who work at Google
and then they think of the word on Prem, they think of like the stuff
that isn't at Google, they think about their data center.
But you're talking about the Google data center, which is the cloud
on Prem, which is like the stuff that the cloud actually runs on,
which I think is is pretty cool.
Like so for customers of cloud, Google has an on Prem.
Also, it's weird, but it's the thing that all your stuff runs on.
So that's a good point.
And we have the champion here.
That's it.
Is what I'm here.
Yeah, for sure.
So SREs often claim reliability is the number one feature of any system.
Is security feature number zero?
Or where does that fall in the hierarchy now?
Takes welcome.
Oh, for sure, for sure.
So interestingly, people often joke about this,
but in reality, it doesn't actually reflect reality, right?
I think what I found having both on both sides of the fence now
and at the intersection, the two domains often pull each other
in opposite directions.
You have on one hand where security wants to resist and control.
And then you have on the other hand, where reliability
wants to ensure availability, right?
And what we're seeing, I think we all see, really,
is that most orgs kind of struggle with this tension.
And they usually over index for one at the expense of another.
And I think that the real challenge isn't ranking them,
like whether which one is higher than the other,
but rather actually finding the right balance
between the two for your specific context.
As an SRE, I've been focused on reliability, availability
and latency and all that stuff forever.
And I've found that a good interaction with the security team
is that we're both aiming for the same big goal,
which is like we want to protect the user.
We want to maintain the service level of the thing
and we want the service to actually be the right thing.
We don't want it to be altered by someone else or whatever.
And they're actually, it's all in the same purpose.
Like we're on the same team,
but I've seen it work poorly on the other side,
where yeah, we're working on the same team,
but we have our blinders on.
We're only focusing on our thing.
We're not being holistic about it.
And cases like this, you can see where teams are trying to
roll back a broken change or something like that,
but they're not able to because of a security control.
And then when they say,
oh, we need to go past the security control
to allow us to fix the thing,
there isn't a way.
And security says no.
This is a common response.
We want to be able to roll out a security patch
very fast bypassing the reliability concerns.
We want to be able to push this patch to all the VMs at once,
like right now, because this is really important,
because there's a thing out there.
And the reliability team is like,
no, you can't possibly do that.
Same deal.
So I think being aware of this alignment
is really, really important and being able to think about this
ahead of time and being able to say,
same team, everybody, let's go here.
Does that resonate with you?
Absolutely.
Yes.
Absolutely, absolutely.
And I think you really nailed it with that one,
because the interesting thing about the two spaces is that,
once you find yourself in a position
where you have an incident and you need to compensate for something,
they're both very difficult to bolt on.
Right?
Like, it's very difficult to then try to make your system
more reliable if you didn't consider it
in the early stages of your design, right?
Yes.
And the same is true of security as well.
It's very difficult to make something more secure
without having to necessarily redesign or refactor
your entire infrastructure,
which I've had experience with,
and I will say, it is a lot of heavy lifting.
Oh, you don't think this is fun
to have to refactor a whole thing?
Fun.
Yes.
Fun.
Et donc, ce sont les choses que nous voulons considérer
en plus en train de considérer
la phase de design de nos systèmes,
comme quand nous sommes en approchant,
de construire des choses différentes,
ou nous sommes en train de parler de différentes features.
Ce que nous voulons faire,
c'est essentiellement travailler avec cette pensée intégrée,
où vous avez, et vous considérez les perspectives
de la sécurité et de la reliance,
et que vous vous optimisez pour les deux spécifiques.
Et donc, ce qui s'invite
à comprendre ce que les traitements sont
et à optimiser ces choses,
encore avec une pensée intégrée,
et le bénéfice de tout ce que vous faites
est que ce qui se passe est que vous vous endvez
avec un système que les utilisateurs
s'impliquent implicitement.
Parce que, en tout cas,
les utilisateurs ne savent pas de votre posture de sécurité
et ne savent pas de votre métro.
Je suis désolé, Steve, ils ne savent pas.
Mais ce qu'ils really carent
est que le système fonctionne
et que ça fonctionne sécurément.
Ça me rappelle de notre dernier épisode,
en considérant le risque dans un système.
Et généralement, quand nous parlons de risque,
nous parlons de l'availability, de la latence,
et de toutes ces autres choses,
et de la scalability, et de la fois,
la sécurité est clairement un pool de risques.
Donc, en pensant à un risque
dans un moyen abstract,
tous les risques doivent être considérés
et, idéalement,
les réveillent et les préventent.
Et, en regardant le côté de l'offense,
ou le côté de l'offense,
on peut dire que nous avons une main à chaque côté,
on a des côtés sur les côtés,
je ne sais pas si c'est possible,
mais en considérant le risque sur les deux côtés,
c'est difficile de faire
dans une organisation qui a deux équipes.
Donc, en étant quelqu'un,
en étant, comme vous, Jess,
ça peut être l'interface entre les deux équipes,
ou, à moins de dire,
« Hey, vous savez que ce autre équipe existe ? »
C'est super important.
Donc, j'ai vu des équipes où les gens
ont pu se faire entre les équipes.
C'est vraiment aidant pour les groupes
dans le monde qui veulent essayer de faire ça.
Juste, faites-vous qu'il y ait un ingénieur
qui n'a pas de la réveillement,
qui va dans la sécurité,
ou d'autre côté,
et qui a juste de leur comprendre avec eux.
Et, probablement,
par un processus de la possibilité de la lausse,
vous allez avoir un peu plus d'évoil
de chaque côté de cette fenêtre,
ou ce que nous sommes en train de dire.
Et, légez sur votre TPM aussi.
Si quelqu'un est actuel,
c'est un tissue connectif,
pas de être mon propre drame,
mais ça ressemble à quelque chose qui est comme,
« Oh, vous savez que nous avons un équipe ? »
« Ça fait ça déjà ? »
Ce serait peut-être juste le truc que vous avez besoin
de l'intégrer dans votre système.
Donc, à cause de tout ça,
comment vous vous suggèrez,
que vous avez vu en termes de
ces deux équipes,
ou ces deux mondes ou des hats,
ou ce que vous voulez dire.
Comment est-ce le meilleur moyen de les interagir ?
Parce que je sais que ça doit être différent
de un start-up vers un grand mega-corps.
Est-ce qu'il y a des thèmes
qui peuvent aider ces différents équipes
à interagir avec eux ?
Ou peut-être des choses à l'évoil ?
Ou quelque chose comme ça ?
Qu'est-ce que vous pensez, Jess ?
Je pense que vous portez un point très intéressant.
Je trouve que ça fonctionne différemment
dans les petits start-ups,
ou dans les petits start-ups et les petits business
vers les grandes entreprises,
et dans les petites entreprises
ou des start-ups,
ce que vous pouvez voir,
c'est que les mêmes personnes
qui sont en sécurité de la réhabilité,
sont les mêmes personnes
qui sont en réhabilité de la réhabilité.
Et l'invénement de ça,
c'est que vous avez des gens
qui sont essentiellement considérés
comme deux domaines.
Et parce que ça,
cette pratique
sera probablement partie
de votre culture d'ingénierie,
plutôt que d'opérer des fonctions.
Mais avec des grandes entreprises,
ce que vous allez voir
est que les deux ont des deux différents organisations,
et les deux ont de très attention
à leurs points de connectation
en prenant en sorte qu'ils ont des planchons jointes,
en fait, ils ont des météques à partager,
et qu'ils ont des visibilités
dans lesquels ils ont des goals.
Et l'une des moyens que les équipes
ont exercé
c'est d'implémenter un processus de réhabilité
qui évaluate les deux sécurité
et la réhabilité qui impactent simultaneously.
Donc, en revanche,
sur l'idée originale,
nous sommes approchés de ce design,
nous sommes en train de considérer
que les risques de sécurité et de réhabilité
sont optimisés pour les deux.
Et partie de ce processus
est également évalué
ce qui est le impact de ces optimisations.
C'est bien,
comme les impacts de la optimisation
pour la sécurité et la réhabilité.
Et puis,
l'autre chose que j'ai vu,
et que Google a fait,
et que je pense vraiment bien,
c'est de développer des outils de sélection
pour que nous
voulons ensuite regarder
avec la même lens,
ou au même point,
au moins, à la fois,
donc, en utilisant les frameworks d'automation,
les plateformes d'observabilité,
nous regardons la même information,
nous le processons différemment
parce que nous travaillons dans différents contextes,
mais plus ou moins nous travaillons
avec le même set de outils
et d'informations disponibles.
C'est pas vrai tout le monde ?
C'est difficile de faire, Jess ?
C'est ce que tu as soulevé ?
C'est très difficile.
Oh non.
Mais c'est pas impossible,
je pense que,

ça va finalement
être attentionnel
et comprendre
quelles sont vos goals de business ?
Et comment formes-tu
votre équipe et votre culture
pour parler de ces choses ?
Je ne sais pas,
mais quel est ton problème ?
Qu'est-ce que tu as vu ?
Donc, j'ai vu,
à l'extérieur de Google,
j'ai vu des rôles très distinctes
et des outils très distincts,
et l'intérêt de l'obligation
de voir les autres outils
pour les utiliser
ou comprendre
est très commun.
C'est très commun.
À l'intérieur de Google,
j'ai vu un nombre de rôles.
Un exemple que j'aime partager
avec les clients que je parle de
est que quand tu fais
une sécurité,
pense en un patch,
pas nécessairement,
comme un patch traditionnel,
mais comme un update de sécurité,
en utilisant le même rôle à mechanism
que tu aies à utiliser pour des changements productifs,
comme opposed à
quelque autre chose,
comme quelque chose de sécurité
ou de rôles de rôles de sécurité.
C'est génial.
Je pense que c'est vraiment bon.
C'est dit,
ce rôle à la machine
doit maintenant savoir
dans la mode de sécurité,
potentiellement.
Donc je peux avoir besoin
de l'obligation pour
appeler à l'aide
d'un plus que un
chard à la fois
ou quelque chose.
Donc,
cela requiert
que les équipes
ne soient pas envers les autres
en termes de
qu'on a ce requin
pour ce toulon.
D'autre part,
nous devons construire
notre propre toulon
par là
et ce n'est pas
un bon
et comme comme comme.
Donc,
avoir un système constrain
qui vous permet
de dire
que tu es dans cette mode
maintenant
et que tu es dans cette mode maintenant
est un peu de software
enginéering.
Ça se passe.
Dès tout ce que je pense,
ça nous lead
à notre prochain point,
ce qui est
ce que nous faisons
en réponse à l'incident.
Et c'est une incédence de sécurité,
pas un incident de reliant.
Deux fois,
des mots
probablement
de mêmes tools.
Peut-être
que tu es en train
de utiliser
un toulon
qui s'appelle OMG,
qui est le meilleur nom
pour un toulon
comme ça,
évidemment.
Oui,
c'est certain.
Mais ce que les équipes de sécurité
font
est différent
de ce que les équipes de reliant
font,
je pense.
Tu sais,
je vais me dire si je suis d'accord,
mais je sais
qu'il y a beaucoup plus
de
siloisation
de
besoin
de connaissances.
Donc,
par exemple,
comme
quand je vois un incident de sécurité,
à la plupart de la time,
il y a un nom qui est
clairement auto-generé
par un programme
d'autres.
Comme le nom n'a rien à faire
avec l'outage.
Et c'est comme,
j'ai entendu,
sur le purpose.
Aussi,
comme je ne peux pas voir
la plupart des choses
dans ce nom,
encore,
c'est probablement
pas parce qu'ils ne m'ont pas aimé,
c'est probablement
parce que
il y a des raisons actuales.
Donc,
pourquoi ça se passe?


C'est pas

problème.
Parce que
vous ne savez pas
quel système
ou les comptes
qu'ils ont accès
ou
qui a accès à quoi.
Et beyond that,
les équipes
ont des informations différentes.
Exacts
ont vraiment
besoin de savoir
ou de savoir
le impact de
le business
d'un incident.
Les équipes
ont des
procédures
et,
comme
votre
réponse à l'incident
vous vous
étudiez
naturellement
les gens
à l'in,
mais vous allez faire ça
sur un besoin à savoir
base
parce que
pas tous
doivent savoir
les détails
de votre attaque.
Ouais,
c'est un bon moyen
d'en mettre,
parce que je sais
j'ai entendu la phrase
« besoin de savoir beaucoup »
et ça ressemble
comme un

junk corpore.
Tu sais,
comme « vas-y,
je dois savoir
beaucoup de choses,
je suis une personne
curieuse. »
Ou comme un agent secret.
Tout le tape
et tout le tape rouge.
Ouais,
ouais.
Mais envers
l'idée que
une chose
de la réliabilité
n'a pas été
une chose qui a été
mis en place
dans le même endroit
ou dans le même
configuration
ou tout ça,
c'est
un système
passif
comme
il n'y a pas
des codes
qui ne sont pas
écoutés
en général.
Mais en
l'incident de sécurité
c'est toujours
une possibilité.
C'est possible
que
vous ayez
une
adversaire

dans l'incident de sécurité
qui est
fondamentalement différent.
Et ça me crée
moi.
Je suis vraiment
content
d'être sur la réliabilité
et pas sur la sécurité.
Parce que ça ressemble
beaucoup.
C'est
je veux dire
que je suis un janitor.
Je me suis fixé
des choses bloquées.
Je ne veux pas
se faire
avec les
bons gars.
Ça semble
difficile.
C'est
en
responsable
et en
plus
créative
comme vous et
j'ai parlé
juste avant.
Dans l'incident de sécurité
quelqu'un a
perdu
ceci
dans un
moyen
qui n'a pas
suivi les
règles.
C'est changer
les règles
et
c'est
c'est
essayer de
prendre
cette information.
Et
la réliabilité
est
ce qui
me fait
ceci
pour
travailler
dans ce
moyen.
Je dois
faire
ceci
disponible
et
accessible
qui est
très
compteur
pour
comment
une personne
qui
tient
à
déterminer
la sécurité
pense.
C'est un
différent
script
vers
aucun
script
pour
suivre.
Je pense.
C'est
une bonne
façon
de le mettre.
C'est
une bonne conversation.
Je pense
qu'on doit
commencer
à
râper
les choses
un peu.
Je veux dire
comment
émettre
cet

governmental clingé.

produits
et
תחilés
^^
SPE Allah
pour
dans
est
station

des
Et
comment
figuring out how to help them work together.
What's the idea here?
Especially in the context of AI.
Don't forget that.
We forgot about the trend for a little while.
Yes, we do have to add the trends.
For sure, for sure.
So I think that the takeaway here is to recognize that it's not a zero sum game.
Ultimately, we're working towards the same thing, right?
Ensuring that we earn and keep user trust.
So if I'm a CIO or whatever it is, titles that people use in the world of VP or something like that,
and I have a reliability team and a security team that I work with or work for me or something like that,
like, who do I fund more?

Who do I tell is in charge?
Like, it seems this is a loaded question, obviously, right?
Like, yeah, that's a tough one.
How do I get them to work together?
How do I get them to understand that they're both important?
Or do I just say like, good luck, everyone?
You know, like, is there something here that we can give in terms of guidance
around how these teams can work together?
I think the guidance here is to understand the trade-offs between the different decisions
and the optimizations that you're doing, right?
And mapping those back to the higher business goals.
Again, because ultimately, the reason why we're doing all of this
is to serve a need, right?
Or to fulfill a need for our users.
And those are usually best described as business objectives or goals.
And so we want to make sure that the strategies and the direction that we're heading in aligns to those things.
And the way that you do that is by evaluating the different properties
that speak to the goals and evaluating the trade-offs between them
and understanding, like, how each decision impacts users,
how each decision may impact revenue or reputation and so on and so forth.

And then what you do is you prioritize for the most likely and most impactful failure modes.
Oh, and this makes sense.
Like, knowing that, oh, the thing that you expect to happen
is the thing that you should definitely plan for.
So it helps with the prioritization.
It helps with understanding, oh, which thing do I have to invest in?
Maybe we should do something about that.
Thank you so much, Jess, again, for coming back to us on the broadcast.
We are so thankful to have you and we're so thankful to have you fighting
to keep our tools reliable and secure.
Appréciez-vous de nous rejoindre aujourd'hui.
Merci, merci pour avoir regardé.
Merci pour venir.
Vous avez regardé le podcast Google, sur le podcast de l'engineering de la reliantité.
Visitez-nous sur le web sur le site sre.google où vous pouvez trouver des papiers, des workshops, des vidéos et plus sur le sre.
Le podcast est hosté par Steve McGee,
avec des contributions de Jordan Greenberg, Florian Rathgeber et Matt Siegler.
Le podcast est produisant par Paul Gulli-Amino, Sunny Schaou et Salim Virgi.
Le podcast est télébotte par Javi Beltran.
Special thanks à MP English et Jen Petoff.