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.
Hey, everyone. Welcome back to another episode of the broadcast. Google's podcast about SRE and production software.
I'm your host, Steve McGee.
And I'm Jordan Greenberg.
This season we're focusing on software engineering and SRE.
And today we have two guests to tell us a little bit about the development of a piece of software inside of Google.
It's a system called Maglev. But we'll get to that.
Our guests today are Cody Smith and Tricia Weir. Can you both introduce yourselves?
Yeah. I am currently the CTO and co-founder of a startup called Camu Energy.
But before that, I was at Google for more than 14 years from 2004.
Cool.
And my name is Tricia Weir.
I am currently the manager of the Traffic Services Data Plane Infrastructure SRE department.
What that boils down to is ProdGFE, DDoS, and a number of other services all around the front end.
I've been at Google for 21 years.
I started as an infant.
Now straight out of undergrad, much like Cody, and started in hard drops and worked my way into SRE and really found my calling there.
And I've been in various forms of production adjacent since then.
Fun fact, by the way, Tricia referred me to Google.
I would not have worked at Google if it weren't for her.
Wow.
Oh, this is so fun.
Cody and I have known each other since we were teenagers because we actually worked together at the student run ISP at UC Berkeley.
It turns out that if your idea of a fun student job is running an internet service provider, you might be in SRE.
Oh, wow.
That's awesome.
That is amazing.
Yeah, that was a great gig.
When I was in high school, I had a friend who ran a teenager ISP as well.
And I thought it was the coolest thing ever.
And I did not get a job, but I totally wanted a job there.
I thought it was the coolest.
And yeah, so began my descent into SRE as well.
There is a lot of physical work too.
Yeah.
So today, we're going to talk about rebuilding core systems with reliability in mind, namely this thing called Maglev,
which is a piece of front-end infrastructure.
And we'll talk about it more in a bit.
But first, let's hear a little bit more about our guests.
And we talked about it for a second just then.
But what prepared you to become an SRE for either or both of you?
You mentioned the ISP.
Do you think that really did it?
Was that the only thing that prepared you or was there more?
I think the first part of the SRE, the ISP work,
at least for me, when I was really getting into it, was physical work.
Like Cody and I, we showed up for the job and they would hand us these bales of network cable
and we would crawl under the buildings wiring them for CAT5.
Some of it, I think, is this idea of the importance of getting the internet to the users really did sink in.
Like working at that ISP, you cared about the users.
You cared when their internet connections were down, they had a really bad day.
And I think that kind of prepped me for the focus of reliability as an importance.
What about you, Cody?
Yeah, I mean, I think I was a computer kid.
I really did not go outside much.
Yeah, I was just always on the computer, playing video games, growing up
and was very entranced by the web when it first came out, was building websites in like, maybe five.

That's awesome.
Working at Rescom was a really nice compliment to my education in Berkeley.
It was like, in theory, a part-time job, but often like well over part-time,
especially in the summer, like, we work in 60, 80 hour weeks.
And just a whole huge variety of different things.
And that's kind of the life of an SRE.
Like you don't necessarily work on the same problem for a long time in SRE.
If you're making progress on the problem, you eventually solve it,
you move on to the next biggest problem.
I think they call that automating yourself out of a job.
It's like everybody, every SRE's wish to be able to do that for themselves.
But it's also being a generalist.
And my favorite way to talk about generalists is to describe them as stem cells
because they're the type of person you can kind of drop in and they become whatever is needed,
but they have the potential to be any number of different roles.
I think for me, really what got me interested in SRE particularly
was working at Google and being in hardware ops.
Because when you're out in a data center and something goes wrong,
who's fixing it?
Who are you talking to on the phone?
It's the SREs.
They were calm, they were competent.
Even around campus, like I kind of describe them when they walked,
they walked in formation.
The wind blew in their hair and it bounced.
Their mailing list was literally called the cool kids table.
And you saw this group of people and you're like,
I want to be one of them someday.
Like they know they can just figure anything out.
They drop into a situation they've never seen.
They figure out what's going on.
They're the cavalry.
That's an appealing mission.
What a lovely image to have of like the SRE with the flowing hair.
I mean, at Google, our SREs are like unicorns.
So that's what I'm imagining now.
Walking in formation, coming in.
Yes.
Explosions behind them, just like a movie.
Yes, exactly.
So since it took a while you got here,
you saw these inspirational people who were at the cool kids table.
They were SREs.
At least that now to what it was like when you were in search and traffic.
How did these sort of like teams interact with each other?
Who did what?
Did they have as nice hair?
All these good questions.
Yeah, I started when the teams were just starting to differentiate.
So it was like production team back in the day,
which then did underwent like a cell division and turned into search SRE and traffic SRE.
I had been working in a group called cluster ops and worked together in the Mustang war room with a bunch of would soon be called SREs.
So I was working with a group who, after the experience working together in the war room,
just picked up my desk and relocated it to their part of the office.
You've been selected.
And had a hard talk with my old manager.
So in the early stages, there was a lot of kind of like work that was moving back and forth.
And a lot of folks that were sort of straddling the two teams.
Some people were like specializing pretty quickly and others were kind of going back and forth.
Like me, you know, I had a lot of interest in the traffic stack personally.
And so took on projects like maglev over on that side, just probably because of my short attention ban.
And to clarify for our listeners, Cody, you were on the Web Search SRE team and then Trisha,
you were on traffic team, which was about front end infrastructure, load balancing, things like that.
Is that correct?
Right, right.
We were the first really infrastructure SRE team and search was the first product SRE team.
And I think Gwis followed pretty shortly thereafter.
I think the teams were really close.
We sat together, we ate lunch together, we hung out after work together.
And a lot of that was really helpful because, you know, we kind of saw each other as one team.
It wasn't like, oh, that's that seems problem.
If it was their problem, it was our problem.
It made for a really high trust situation, which I think we'll get into later, but it was really helpful.
And there was a real cohesion, like we all took our annual ski trip off site together.
We called it the single point of failure day because if there was a big food poisoning incident,
it would really hurt Google if everybody got sick at once.
I think the interactions were really positive and really, really close ties.
That's awesome.
So getting into the technical meat, the subject at hand.
Can you tell us, like, what do we mean by front end infrastructure?
Don't you just throw a bunch of engine Xs out there and call it a day?
Or is it a little bit more than that?
And then what is it that kind of happened?
Like, what was the story like, we didn't want the thing anymore.
So we're going to do something else.
Like, what was the story of Maglev's beginning?
So when we say front end infrastructure, the joke is it's low balance is all the way down.
But it really kind of is everything that has to happen.
If you type in news.google.com, everything that happens from you hitting enter on the keyboard
to your query, getting to a news backend or an ads backend or a Gmail backend.
That's all really front end infrastructure in front end networking.
It's massively complex.
All of the things that allow us to have high reliability come with high risk of outage as well.
We need to be able to load balance traffic across the globe.
We do DNS based load balancing.
We need to be able to do failover between regions.
We need to be able to absorb DDoS attacks crypto term.
There's a whole lot of things that are all happening behind the scenes.
And one thing about front end infrastructure is that it's shared.
It's not like everyone has their own stack.
It's not like maps has their own front end infrastructure and then Gmail has their own.
Absolutely.
Cool.
So then, what was the problem?
What did you guys face?
Yeah, we have right at the front of the stack, there's a thing called a network load balancer
that's doing sort of IP, TCP level balancing a packet as they come in.
And so it's keeping track of TCP connections and making sure that packets on that same connection
always go to the same back end from the network load balancer standpoint.
The back end is the Google front end GFE.
And we were using a device provided by a vendor kind of in the realm of network hardware.
It's a, you know, the vendors focuses on network hardware and they were pretty expensive.
I think they were something like $20,000 a box.
Oh, wow.
And then the support contracts went into the millions for all of the devices.

That's where the real money is.
Yeah, the 20K would get you a gigabit of throughput.
When we started the project, it was like bi-directional.
So it had to carry packets, both inbound and outbound.
Getting on the DSR was my first project.
Yeah.
I remember going to the team picnic and we wrote, there was a Hanna artist doing Hanna art.
And we wrote DSR or die on my knuckles, like a knuckle tattoo.
Wow, I love that.
Yeah, DSR means direct server return.
And so you can imagine a packet coming in through the network load balancer and going to a GFE.
And then when it goes back out to the user, it just goes straight to them and not back through the load balancer.
And so this saves you on egress bandwidth and sort of like removes a bit constraint in your load balancer capacity.
So there must be a reason why there are so many comments about these load balancers.
Did something happen?
A lot of things happened and they kept happening.
There were some basic things like we needed features that the vendor would just say that's not a priority for us.
We wanted to do GRE encapsulation to be able to allow us to do more advanced routing of the traffic.
And the vendor would just say we can't implement that on our devices anytime soon.
The bigger issues were that, well, actually another growth issue is that they couldn't push very large configurations.
And as we grew, our configurations got larger and larger and larger.
But the biggest issue is they were deployed in an active passive pairing.
And this was our redundancy, right?
If one of them had a problem, you failed over to the other one.
But it wasn't a clean failure.
The failover process caused these massive ARP storms.
So you already have a failover happening and then you have an ARP storm on the network because of that.
And we brought all of these concerns to the vendor and they really said, like, it's just not a priority.
Yeah, they were very focused on features.
Like there are other customers just really wanted lots and lots of like kind of layer seven features that we didn't really care about.
We were just bulk trying to move traffic in and out.
And so we were kind of weird compared to the rest of their users.
Et donc la prochaine chose, c'était que tu as essayé de le faire.
Oui, Asin Bud et moi, je dois expliquer un petit peu de contexte.
Nous avons un programme de mission control où les ingénieurs vont venir de l'équipe pure de la dev team
pour joindre le SRE pour une rotation de six mois.
Et si ça a travaillé bien, ils pourraient rester.
Asin Bud était l'un des quelques folks dans la team qui avait cette expérience de product development
avant de venir ici.
Et elle avait une confiance raisonnable que nous pouvions faire.
Et l'intuition sur comment faire des choses que je n'avais pas,
parce que je suis allé de l'intergrès en SRE.
Avec Air Cover, notre manager, Jena, qui a aussi consterné des difficultés avec ce vendeur,
nous avons commencé à couper les problèmes dans les compagnons et à couper les compagnons.
Nous avons fait une liste de les bouts de load,
il va y avoir des 7 compagnons.
Et elle et moi avons fait des tournes en prenant la prochaine priorité,
et c'est une partie de la liste.
Et ça a réveillé plus rapidement que ce que nous espérions.
Je pense que le Bouncer de la Network est un truc très complexe.
Mais c'est 3 ou 6 mois entre la décision de la code et de la première récolution de la trafic.
C'est très rapide.
C'est très rapide.
Il y a eu 2 mois entre...
Je pense que tu avais un prototype pendant 2 ou 3 mois, si je vous le souviens.
Nous étions en train de faire des choses un peu sconches,
donc ça a été important.
Je pense que l'importance de ce contexte est que nous avons juste eu un autre projet
sur le team qui a été créé pour un très long temps et qui n'a jamais réussi à lancer.
C'était un tour interne et il n'avait jamais été créé par un nombre de problèmes de scopes.
Il n'a jamais été créé et il a été créé après un an.
C'était un challenge de crédibilité de développement de software en SRE.
Et donc, plutôt que de commencer ce projet avec des annonces de boule,
que nous serions allés faire un autre projet,
que nous serions allés essayer de faire ça de nouveau,
c'était un peu un peu sconche-work.
Je pense que ça s'occupe beaucoup de 2 choses.
Je pense que c'est un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un
peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu
un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un
un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un peu un
But people think Google a lot.那 maybe it could be first reduce the
respond to that piece of value.
This means just answer as many of them as you can. It's important.
Everyone's always ping in Google
just to make sure this thing works.
Yep, I do it too.
There was some big shifts as it was going.
You were talking aboutessenary involvement.
Some of it was input from the broader esgerauteem
on how this is gonna go.
On a une forte distingue entre les racks de contrôle et les racks de production.
Les racks de contrôle dans le centre de la date sont fixés en place.
Ils ont souvent des machines de rack.
Les choses ne changent pas très souvent.
Ils sont souvent spécialisés sur les devices de hardware.
C'est très spécial.
Les dernières parties de l'on de la 3e partie de la Network Load Bouncer
ont été allées pour les racks de contrôle.
Quand nous avons commencé à regarder, nous savions que nous voulions le faire
sur le hardware de la commande,
mais nous pensions que nous avions
une machine de la commande de la commande
dans le rack de contrôle.
Il y avait un long tangent
sur comment cela pourrait fonctionner.
Je vais dire que l'une des mes propres concerns
qui s'est annoncé par les racks de contrôle
était que je m'aimais dans les racks de contrôle.
Je m'aimais dans les machines de réparation
dans le centre de la date.
Ce n'était pas un système de contrôle
où vous avez une machine de contrôle.
C'était un cas spécial.
Ils n'avaient pas toujours des parties.
Ils n'avaient pas de tickets, c'était une machine de contrôle.
On a commencé à explorer
ce qu'il fallait prendre pour faire ces machines de production
à la place de la cluster.
Si vous avez un Maglev en cours de production,
et que ça ne faise pas,
on le verra sur la prochaine fois.
Ce n'est pas une question
de filer un ticket,
on va réinstaller un pilon de réparation
sur cette machine.
Je dirais que c'était
une visite de plus en plus de la SRV.
C'était une visite de plus en plus de la SRV
pour le Maglev en particulier.
En termes de timeline,
c'est aussi post-Borg, je crois.
Ce n'était pas de
trouver un espace et une spreadsheet pour une machine.
C'était comme
type button, hit enter, get machine.
C'était totalement automatique.
Je me souviens de la décision
de la machine de la machine pour le Maglev
en cours de production.
Si vous ne vous inquiétez pas,
vous pouvez me dire
que le tournage
n'est pas le végétal.
Qu'est-ce que c'est
et comment ça a été fait?
Oui, c'était
le plus nerveux
dans les jours plus tard.
On a essayé de faire ça, on a
pris une pièce d'envergage
d'envergage d'open source,
qui s'appelle Quagga,
qui était un client de BGP,
et on a répliqué
dans notre propre
contrôlant
ce qui intervient
avec les buffer protocoles
et les établissements.
Ce serait connecté
à la pièce d'envergage
et à la pièce de BGP
pour le VIP, je suis le prochain
top et les routers
ont été configurés pour
permettre ça.
On peut commencer de migrer
du VIP par VIP
du trafic
de l'existence
de vendeur
sur ces servers maglev.
On a
pu faire des tests
de l'envergage
que le throughput était
faible. Le kernel Linux
n'était pas très bon
à distribuer
une entreprise de la nette
sur plusieurs cores.
Ces machines étaient très bifides
mais on a essayé de faire tout le travail
sur une cour.
On avait un limiter
de 100 000 packets
par seconde par machine
de 200 000 à 300 000,
mais la saleté
pour 64 packets
serait 1,5 million.
Oh, wow.
Juste pour vous clarifier,
vous avez parlé du VIP
c'est un moyen de partition
du trafic, on n'a pas de détails
de la base.
En tout cas,
on a un subset logique
qui représente des maîtres
ou des services
de trafic
sur email
et on va dire que c'est juste
ce que nous allons faire aujourd'hui.
Google Toolbar, si quelqu'un
m'en souvient,
c'était un premier produit
plus ancien,
plus la priorité.
Nous avons des VIPs
qui étaient créés
pour des trafic plus
plus tolerant de risques.
C'est important.
Deuxième,
l'établissement de la base
m'a aidé beaucoup
pour faire un experiment.
Si votre plan est en train de
faire un tour de la base,
on ne sera pas un grand plan.
Vous avez fait un VIP par VIP.
Qu'est-ce qu'il y a?
Nous avons commencé avec les VIPs
et nous avons des résultats
de tout ça.
On a vu que c'était bien.
Nous faisions un peu de redistribution
parce que ces machines n'étaient pas
aussi vite que le vendeur.
Nous ne pouvons pas juste faire
un pour un, c'est pas grave.
Nous avons travaillé de la manière
plus courte,
les VIPs,
les websearchs et autres
produits importants
que nous avons utilisé.
Les clusters différents
ont des types de hardware
parce que chaque hardware a des
différents constraints
et des configurations de speciale
et des choses comme ça.
On a des modèles actifs
pendant ce coup de l'opération.
Il ne sait pas
ce qu'on a fait
pour les VIPs.
Les probes de l'infrastructure
nous ont dit que si quelque chose
était off Baumart,

On giants dans la hopefully
d'un niveau,
on essaye d' économiser solving
parent les calliers
en France.
dynamique pour les différents régions.
Vous avez des places avec de la haine de la seconde,
des places avec de la seconde de la haine de la seconde.
On a vraiment essayé de faire une distribution
de l'air de la cluster ou des clusters de tests
tout au monde.
C'est génial.
La diversité de vos workloads est vraiment importante
quand vous essayez de satisfacer quelque chose comme ça.
Oui.
Je me souviens que,
comme vous avez créé ces environnements
pour essayer ces choses-là,
avez-vous trouvé de bons bugs
pendant que vous étiez testant ces trucs ?
Oui.
Il y avait un bug que je pense encore
probablement trop souvent.
C'était dans ma course.
C'est Hansi ?
Oui.
J'ai écrit la interface de kernel.
Nous avons utilisé la même interface
que la TCP dump
qui utilise pour les packets
du kernel
et la code de packet parser
qui va ensemble.
Je n'étais pas paranoïde
qu'il y aurait un bug ici
et j'ai écrit un test de test
qui a été clampé
sur le packet parser
et qui a pris une grande map
de production
avec cette code
pour procéder un trillion de packets.
C'est un grand travail.
Et ça a été dit,
pas de bugs.
Et je suis ecstatique.
Mais la première fois
nous avons eu un packet
qui était plus grand que la length de snap
sur le buffer
que nous avons donné au kernel,
c'était la length de snap
et les lengths de packet
étaient différents
et nous étions les mêmes
en nous réveillant.
Non.
Et c'est OK
pour les autres buffers.
Vous avez juste
les sujets dans le packet
mais si vous êtes à la fin
de votre buffer,
vous vous réveillez
dans une mémoire inallocée
et vous utilisez la faute de segmentation.
Et donc,
nous avons fait
une tournée
où un trafic local
de loopback
était 64 kilobytes
MTU
et il était tronché
dans le buffer
et
a crashé.
Et nous avons découvert
le problème de la faute.
C'était très facile
mais très embarrassant
parce que c'était
comme
5 lines de code
avant que le test de fuzz
soit plongé.
Oh, wow.
Donc je vois que
ce n'est pas
Rust
ou Java
ou une sorte de
mémoire
en langue de la modernisation.
Oui, c'était plus en plus.
Bien.
Respect.
Oui.
Je pense que l'autre problème
qu'on a commencé à faire
en faisant un rollout
était
qu'on a commencé
à saturer les switches de racktop.
On considérait
l'availabilité de la banque
là-bas
comme une concern.
Mais ce n'était pas
quelque chose
qui était construit
comme une concern
à l'un des systèmes
qui ont fait un replacement auto.
Et
quand nous avons commencé
à être placés sur les racks
qui avaient d'autres neighbour
qui étaient aussi
de la banque
avec les utilisateurs,
nous avons commencé
à avoir des problèmes de saturation.
Et je me souviens
que, en travaillant avec
l'Izador,
c'était le tool
de la période
que Cody might remember.
Mm-hmm, oui.
L'Izador team
a été
à faire
et à impliquer
une nouvelle constrainure
pour que,
quand il était
mis à l'allocation
il y ait un check
pour ce type de diversité.
Donc, vous diriez
que peut-être
ce n'était pas
parfaitement plané
et que votre team
a dû adapter
pour l'expérience
que cela a résulté
de ce change
que vous avez fait
sur un système très complexe.
Je pense que c'est faible.
Je pense que c'est
ce genre de chose
qu'on pense de maintenant.
C'était un monde de la nouvelle
et donc,
nous avons
donné
l'ambient
de la connaissance ambiante
à l'industrie de l'époque.
Nous l'avons mis
bien de temps
mais ça ne pourrait pas
jamais se passer.
Mm-hmm.
Je veux dire,
nous sommes ici aujourd'hui.
Oui.
Je suis pas sûr que Maglott
soit en train de

plusieurs centaines
de paquets par
nanosecondes.
Je ne sais pas.
Il y a un certain sort de nombre.
Ok.
Donc...
Il y a un mathenfall.
Avec respect à
les SREs
qui ne sont pas à Google.
C'est ce que les listeners
sont sur ce podcast.
Est-ce que cette histoire
est ambitieuse ?
Est-ce que vous avez besoin
de la taille de Google
pour faire quelque chose comme ça ?
Pas nécessairement
cet exacte
task.
Mais ce processus
de remplacer
un truc
avec des softwares
et d'initier
et de construire
et de voir si ça fonctionne.
Comment vous conseillez
les gens de la monde
pour prendre cette histoire ?
Qu'est-ce qu'ils doivent apprendre ?
Je pense qu'il y a toujours
une balance à être destructé
avec savoir
est-ce que c'est quelque chose
que je dois construire
moi-même
ou peut-être
mon outil
de la tâche d'existence
parce que vous pouvez bouger
plus vite si vous êtes sur les
bâtons de géants.
Et donc je pense que
quelque chose de développement
serait ce que
l'intuition est de
est-ce que ce n'est pas
quelque chose de tâche d'existence
qui va faire ?
Et est-ce que je dois
mettre ces features ?
Une chose que Cody et moi
parlions de avant
qu'on était en train de faire
aujourd'hui
était l'idée
qu'il y avait un liste
de features
que notre système de
hardware
et Cody et Eisenberg
ont juste déclaré
beaucoup de ces features.
Ils sont comme
vous savez,
on n'a pas besoin
de ce spécial
feature.
On n'a pas besoin de ce
spécial feature.
Ce qu'on a besoin
est ce qu'il y a de
features particuliers
que rien d'autre
au marché
est donné.
Et donc avant
de commencer un projet
comme ça
pour décider si c'est
un bon use de votre temps,
je dirais que
on va faire ce que l'intuition
et ce sort de
l'économie.
Tout le monde
veut faire quelque chose
nouveau
et personne ne veut
faire de la maintenance
c'est un quote
sur Kurt Vonnegut
que j'aime vraiment.
Les gens souvent
veulent construire
des nouvelles choses.
Ce construire
n'est pas toujours
l'exemple.
Mais en ayant
un jugement
sur ce qu'il y a
ou non,
c'est quelque chose
qui va vraiment
vous aider.
Bien.
Oui, je dirais que
je pense que
la pression de temps
était vraiment utile
dans le contexte
de la chose qu'on a besoin
de construire.
Ce n'est pas
vraiment prudent
pour être
ce complexe.
Et une grande partie
de cela
est la brutalité
avec laquelle
nous avons
gardé des choses
simple.
Le tout
ne compte
que le client BGP
sur le code base
était
je pense que 2000 lignes
quand nous avons lancé.
Wow.
Donc c'est
pas que beaucoup de code.
Et
la pression de temps
de comme
ce n'est pas
un point de vue
qu'on doit démonstrer.
Un résultat
avant de l'accès
était vraiment utile
parce que
il a fait
beaucoup de décisions
sur
si nous devons
supporter
ce feature
sur le lunchday
ou non.
C'est très simple.
Si l'answer
peut
d'un point de vue
être non
il devrait être non.
Donc
quel conseil
vous donnerz
aujourd'hui?
Vous savez,
les enfants
qui travaillent
sur le code base
en se défendant
qui ils sont.
En se défendant
qui ils vont travailler
avec pour un long
temps, pour les prochaines 20 ans,
il y a des
très grandes entreprises
qui ne peuvent pas
même exister.
Quels conseils
vous donnerz
à eux?
Pour
comment ils peuvent
vous en mettre
sur Internet
et faire
cela plus vite
ou plus fort.
Je pense que
en plus
dans votre
career
tenter de
trouver
des rôles
qui ont
un grand
contenu
autour de eux.
Il y a beaucoup
de différents places
que vous pouvez
aller
dans le rôle.
Vous ne pourrez pas
faire
juste
un truc
sur et sur
encore.
Oui.
Mais
beaucoup de choses
que tous
travaillent ensemble
sont
très
abis
dans les
stables
et
il arrive
à
Ты
sa werd
master
et
souls
Port darf
un
honte


pillars
l'avantage de la santé psychologique.
Nous sommes dans le milieu de l'outage.
Nous devons se sentir bien et de
proposer une solution très wild,
et de savoir que vos co-workers ne vont pas dire
que c'est ridicule.
Ça ne devrait jamais ne pas être le cas.
Je ne peux pas croire que vous ne savez pas ça.
Parce que parfois l'idée wild est la chose qui fixe ça.
C'est vrai de la SRE, mais c'est aussi vrai
de tout le monde qui est innové.
Vous devez être capable de m'innové,
d'avoir une idée wild,
d'en savoir que si vous vous faillissez,
vous allez avoir le bosse.
De savoir et de la people autour de vous.
Donc beaucoup de,
à moins mon éducation,
vous devez faire des codes,
et vous devez faire ça tout de suite.
Vous devez être des hauts et de faire vraiment bien.
Mais tout ce que j'ai vu arriver,
huge à Google, a été résulté
de la collaboration massive.
Et beaucoup de ça vient de
travailler avec les autres,
d'intégrer leurs idées,
d'y respecter, même quand vous vous déguisez.
Donc je vous conseille de
trouver des gens que vous avez apprécié
de travailler avec, parce que si vous ne vous
n'avez pas apprécié votre temps, si vous ne vous
vous sentez pas bien, si vous n'avez pas
pu être votre entier autour de vous,
vous ne vous devez pas vous donner vos meilleures idées,
vous ne vous devez pas pouvoir
faire des gens de votre idée,
et vous ne vous devez pas aller aussi loin.
Et ce n'est pas si bien.
Vous n'avez pas besoin de les meilleurs amis,
vous n'avez pas besoin de vous faire des gens
de la semaine, il y a plein de gens
qui sont en train de se tourner.
Et nous nous verrons
une fois de l'année maintenant, nous ne sommes pas
les besties, mais il y a
quelqu'un que je pense, quelqu'un que je
croise et respecte.
Et je pense que cet aspect est vraiment important.
C'est génial.
Je dois dire, c'est pas jusqu'à la fois que je
suis en train de parler sur Google,
que j'ai appris le phrase,
et je pensais que c'était assez pressant,
que ça n'était pas un truc
dans Google, ou dans le SRE,
que personne ne s'est dit que c'était un jour dans
l'année, parce que c'est comme, ces lignes,
c'est juste que c'est beaucoup de choses,
allez-y, et ça marche
mieux de cette façon.
Je l'avoue.
Merci à tous nos guests, Cody et Trisha.
Cody, où pouvons-nous trouver vous sur Internet?
Oui, la compagnie
que j'ai co-foundée
et qui travaille maintenant, c'est KAMU Energy.
Nous sommes KAMU.Energy.
Et si vous voulez m'emmouler,
c'est Cody et KAMU.Energy.
Perfect.
Comment vous, Trisha?
Je suis à Google,
vous pouvez m'emmanger à trisha.google.com
à TRISH.
Perfect.
Merci à tous pour faire
ce épisode possible,
et à un bon jour.
Merci.
Merci beaucoup.
Bye.
SRE.Google