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.
Hi everyone and welcome to another episode of the podcast.
Google's podcast about SRE and production software.
I'm your host, Steve McGee.
As always, we have our co-host, Jordan Greenberg.
Hey.
Hey Jordan, how's it going?
Good.
I'm excited.
All right.
So this season we're focusing on software engineering and SRE.
Today we have two guests to talk about how that's done in their industry.
Specifically these two come from retail and from gaming.
These two both share two traits that we're interested in.
One is what I'm calling real timeliness and maybe less obvious the need to move or migrate
between platforms like onto cloud or between clouds or even between internal software delivery
systems.
So let's have our guests Jordan Chernev and Scott Bowers introduce themselves.
Hey everyone.
My name is Jordan Chernev.
Thank you for having me on the podcast.
A little bit about myself.
About 20 years of industry experience across both enterprise and startup cultures.
I'm a formal practitioner.
Most of the organizations that I've been a member of have been either anywhere from
50 to 200 insides all the way up to 20,000 multinationals.
I think of myself these days as a business executive of focus on technology.
Primarily, I'm more of a senior engineer and a product leader with a specialization
in data.
SRE, developer experience tech transformation and hyper growth.
Thank you very much Jordan.
How about you Scott?
Hi.
Yeah.
I'm Scott Bowers.
Je travaille en software Gearbox, qui est le plus très bien connu pour les franchises
des Bordelands Game et j'ai commencé juste à la collège.
J'ai été là depuis environ 10 ans maintenant et j'ai travaillé sur le
type de l'IT classique dans notre plateforme shift, ce qui est ce que nous appelons notre
ingénie online.
C'est cool.
Et c'est là où j'ai mes codes de la route, c'est-il?
Ouais.
Je crois que pour nous c'est le plus grand pour les keys de Golden.
Ok, ok.
Ok.
Ok.
Merci beaucoup à tous les guests pour vous introduire.
Je vous apprécie.
Qu'est-ce que vous voulez que ce soit un SRE sur les choses que les gens utilisent
pour les wines, si c'est en shopping ou des jeux?
Pour moi, dans les jeux, c'est le bon mix de responsabilité et d'excitement.
On a beaucoup de gens qui utilisent notre plateforme tous les jours, mais ça
aussi signifie que je me dérange à la fois de la fois de l'église.
Si je fais les choses d'accord.
Donc, pas de pression.
Très bien.
Ouais, c'est incroyable quand on a des choses d'accord et un autre genre d'excitement
quand on a des choses d'accord.
Ouais, plus d'un point de vue, sentiment et comment.
C'est évidemment au shopping.
Les gens veulent avoir une expérience de shopping de même.
Le fait que nous avons fait un SRE, c'est que nous avons supporté des services,
surtout pour des events de la grande journée, comme Quai Day, Cyber 5.
Ceux sont de la force de plusieurs services, de plusieurs équipes.
Ils ont tous le point de quoi se passer, consistant de l'expérience de l'experience
pour tous ceux qui tentent de shopping online.
L'excitement est un ordinateur.
Il y a beaucoup de préparation, il y a beaucoup de planing, je ne sais, test,
en making sure that everything is going to scale.
Et il y a toujours un peu de l'hélicité dans tout ça.
Je ne sais pas si on peut l'étergner, vous pouvez préparer le plus vite que vous voulez,
mais je ne sais pas, peut-être que quelques services de plus
peuvent introduire trop d'excitement que vous ne pouvez pas l'accounter.
Je ne suppose que vous, en retail et en gamme,
ne vous en rendez pas avec des spikes de trafic pendant certains temps de l'année
ou des événements ou quelque chose comme ça.
Je pense que ça ne réellement ne se passe pas.
Non, on n'a jamais eu de problème avec un launch de jeu.
Non, c'est bon.
C'est certainement pas.
Ça semble facile.
On a des spikes, et on a l'air d'avoir des problèmes
avec les créations pour les spikes,
et aussi de la construction d'un structure efficace au sein de ces spikes.
Oui, d'un point de vue, on a des spikes,
parfois qui sont anticipés ou non anticipés.
Un des exemples plus intéressants qui s'en vient,
c'est que parfois on peut introduire un peu d'inhex,
donc un webpage qui augmente la faute de la faute.
Un peu plus critiques après,
je ne sais pas si c'était critique à ce point en temps,
mais 100x, ce sont des trucs qui sont plus intérieurs,
mais oui, beaucoup d'expérience avec les campaigns d'essence,
des blasques qui sont plutôt cadrues,
ce sont les deux que vous pouvez préparer,
mais c'est une combination de deux.
Oui, le marché est vrai, il a des réels effets,
pas de joke.
Vous vous dire que ça marche ?
Je suis fêux que ça marche, oui, il se passe.
Je suis en train de le tromper Freddy,

que je holderai mon cause et la собственité de ma propagation.



explanation, un homme anglophone,

next is a cyberème paix,


ou est-ce que c'est un grand air ? Est-ce que c'est une bonne idée ou quoi ?
C'est une question qui me fait meurtre dans le gât parce que notre première
pass du monde en essayant de mettre des salauds aux services les plus importants,
nous avons été des ingénieurs sur ça et nous pensons plus sur ce que la service est en
train de faire et pas beaucoup sur ce que l'experience des utilisateurs.
C'est toujours la chose importante, comme Jordan a dit, le but de tout ce que
nous avons fait en fin, c'est l'expérience consistante pour le client.
Et en faisant des salauds, maintenant, un peu mis en train de se faire
de ce que nous pouvons ressentir.
Donc nous sommes en milieu d'un effort pour ré-defineir et ré-aligner des salauds
pour que ce que le joueur est en train de voir et de l'experience en jeu
soit le fait que nos objectifs sont en train de se faire.
C'est un point de vue technologique, mais c'est pour lesquels le business
s'intéresse, vous voulez faire sure que vous avez des bonnes connections mentales
entre ce qui existe pour la service et ce qui tient à une certaine métrique
ou une KPI que nous avons défini.
Ça fait plus facile, comme on l'a dit, que ce soit fait en pratique.
Pas tous les services ne seraient pu avoir un lien direct à une
business-level KPI.
Peut-être que votre top, ou les services critiques,
seraient plus bas, mais plus bas,
plus tard, ça doit être défini,
et si vous avez des services sévétisés,
vous avez le temps de s'offrir pour l'organisation,
comment vous pourrez le quantifier à une certaine métrique?
Il y a des trucs intéressants,
mais c'est un très utile pour vous,
pour vous tenter de communiquer et de protéger
le valeur de l'impact potentiel
pour une audience non technique dans votre organisation.
Ok, donc, par rapport à ça,
spécifiquement dans les industries,
comme on l'a dit, vous êtes réel,
et vous êtes direct à l'esprit des clients.
On peut voir des millions de personnes
quand les choses se dévouent.
Je suis inquiétant si vous vous rendez avec des services sévétisés
par minute, ou plus tard,
pour un second, je ne sais,
comment vous pouvez avoir des gains de faim?
Vous savez que votre système est en train de s'entraîner
pendant 30 secondes,
ou est-ce que ça ne se dévouera pas?
Je pense que c'est ce que je suis en train de faire.
Est-ce que c'est le plus important de l'investissement
de cette niveau de granulier?
Je pense que dans notre cas,
surtout pour nos plus grands titels,
nous avons créé un spot
où ça se dévouera.
Le second niveau d'impact
est observé par chaque joueur
pour un titre de la même,
ou parfois, selon la nature
de l'impact,
tous les titels utilisent notre plateforme.
Donc oui, nous, absolument,
si nous le connaissons proactuellement,
ou après le fait,
nous pouvons absolument voir un second level
d'impact à notre
le plus real, le service de time,
notre lobby multi-player et le système de messager.
Les gens sont dans un lobby ensemble,
ils ressentent si la chose
de les protéger, les brefs.
C'est donc, c'est définitivement une chose...
C'est vrai.
Nous payons beaucoup d'attention,
et nous avons rédesigné
le système de multiplayer
pour une meilleure observabilité
avec le but
d'un objectif réel
et d'un point de vue
de la même, pour que les joueurs soient en ligne.
Les gamers vous en sont en train de vous remercier.
Je suis un gamer, mais les joueurs vous en sont en train
parce que
beaucoup de jeux ont évolué pour être très social
et pour les services où vous avez
besoin de vous être
disponibles, quand les gens sont disponibles.
Les gens ne veulent pas
penser que le truc que j'ai envie de faire avec mon ami
n'est pas en train de travailler maintenant.
Ils ne veulent pas voir ça. Ça les fait très mal.
Je suis sûr que tout le monde est content
de ça.
Oui, j'ai connu avec ma fille que les jeux de vidéo
pour moi à ma âge maintenant sont un
excuse pour me faire étanger
sur un téléphone avec mes bouts.
Si nous n'avons pas l'excuse, nous ne nous en sommes pas.
C'est vrai.
Comment vous en parlez, Jordan?
Vous avez une situation similaire?
Je pense que c'est un peu différent.
Peut-être que c'est un peu plus relaxant
par rapport aux expériences
de l'utilisation.
Je pense que les joueurs en ligne
sont un peu plus
plus stiqués.
Surtout si les expériences sont transées
pour un hic-up en termes
de la disponibilité ou de la performance.
Beaucoup de gens ont
de la chance de aller et de
s'assurer que je le mette.
Je peux donc
pouvoir le faire.
Le modèle mental est un peu plus relaxant
par rapport aux expériences pour l'utilisation.
Nous serions capable de détecter
et de voir les problèmes que nous
avons enceintes.
Je ne pense pas que c'était un peu
pragmatique ou pratique pour nous
pour essayer de détecter
à l'élection seconde.
Mais peut-être que en un moment,
nous allons voir des impacts de business
et, pour le moment,
on ne va pas dire que
je vais avoir un moment
de la production.
On va voir un grand
shift, mais le plus
que les minutes sont
en train de s'attendre, c'est
un peu plus de la softness
et de l'expérience.
Si ça se passe,
comment communiques-tu
avec les joueurs de la production
quand les choses se sont en train de s'assurer
que les pages ne se débloquent?
Comment vous le dites?
Dependant de l'outage,
je pense que
il y a beaucoup de méthodes.
Les pages business tendent à
choisir leur personnalité
ou leur personnalité.
Vous faites
des maintenance
ou des pages.
Vous voulez communiquer
avec vos joueurs
via email après l'incident.
Vous pouvez communiquer
pour un bon blog
après le fait d'avoir
une visibilité.
Vous avez mis un code

en train de
les attraquer,
pour avoir une bonne expérience.
Je pense que
les mêmes approaches
que nous avons
ont été considérées
pour l'année.
Il y a un niveau
de halo ou de stickiness.
Même si quelqu'un s'exprime
pour un temps de brief,
ils ne sont pas toujours
dans la même heure.
Ils sont activement en ligne
et ils peuvent voir
les revenus.
Il y a un peu de temps maintenant
et il y a des gens
qui sont activement en train de
s'assurer.
Le plus sophisticated que vous avez
avec votre business, les plus visibles
sont les méthodes d'OMF.
Mais envers la communication,
c'est la première fois que je suis en train
de parler des différents canaux
sur les notifications textes,
les emails de postes,
les notifications push.
Pour un plan d'outage,
nous avons un plan de la manière
pour qui nous pouvons
prendre cette information
pour nos joueurs.
Mais pour le plus intéressant
de l'outage plan,
nous n'avons pas de bonnes
méthodes d'outages,
d'un point de vue de la même manière
que notre page de status de shift
Twitter.
Et même après,
nous avons des signes techniques
qui ont un problème.
Il y a un ingénieur qui a
validé que les joueurs sont impactés
pour avoir un poste
sur le Twitter.
Il y a beaucoup de temps pour un gamer
de penser que ça devrait travailler
et que ça ne marche pas.
Et le Twitter de status
dit que tout est bien
ou qu'il n'y a pas de poste
dans le jour. C'est quelque chose
où nous voulons mieux
et nous espérons utiliser quelque chose
comme la page de status,
quelque chose que je suis fan
de tout ça,
des sites ou des outages que j'utilise
ont ça.
C'est un challenge pour nous
si nous avons un plan d'outage
pour communiquer ça proactively
et aussi
pour que nous puissions utiliser
le Twitter pour ça.
Mais nous espérons un meilleur
et plus techniquement
solution.
Donc, dans toutes ces choses que
vous avez construites
et que vos équipes ont été
en train de développer la communication
et d'investir,
j'ai une question assez

proche, qui est
comment vous avez
investi
en ce qu'on appelle
le prochain jeu ou le prochain
feature.
Donc, parfois, on se appelle
comme shift en reliant.
Comment nous avons
fait cet ordinateur
en organisant?
Est-ce que
les équipes s'en font un peu?
Est-ce que vous êtes en train
d'utiliser des postmortem,
en enseignant et en en évoquant
vos collines et en en évoquant la code?
Comment a-t-il travaillé dans votre expérience
en termes de les choses
plus adaptées pour
ce grand scale de temps real
et les choses face à l'accès?
Je pense que le bâtiment de la LAD
est en fait un component
de culture qui est formel,
pour que tout le monde soit investi
et que tout soit successful.
Tout le monde,
tout le monde,
les personnages et les équipes
d'ingénierieurs qui doivent être aussi
investis dans le business,
les équipes productives,
en faisant des récentes sharedes
sur ce que l'expérience de l'end-usage
semble inagricée pour les gens
qui utilisent notre produit.
Donc, je pense que, en commençant
à être un peu plus
concentré sur la culture,
pour être plus concentré sur la reliant
et pour que ça impacte le produit
et le fait que l'organisation
soit en train de délivrer, je pense que c'est probablement
le premier et le plus important point de la construction.
Cool. J'ai oublié.
Qu'est-ce que tu as fait?
J'ai joigné la équipe
quand elles ont redesigné
l'ensemble de la plateforme,
de ce que nous avons
intermédiait, la plateforme V1.
Elles ont redesigné la plateforme V2
avec la reliant et l'observabilité
comme les goals.
Et je pense que c'est
par rapport aux leaders techniques
sur la équipe
avant que je les aie jointes,
voir la scale que le business
voulait acheter et voir que
ce qu'ils avaient construit en ce moment
n'était pas sur la même track.
Et je pense que ça,
avec l'incorporation de notre équipe,
de ne pas faire un appel,
ces deux choses sont ensemble,
pour que les gens les investissent
assez en l'idée de reliant,
que, man,
un effort multi-year
pour le design et puis migrer
à notre plateforme
qui a été authorisé.
Oui, ça toujours s'entend
à la scale, je pense.
Ça vous empêche de faire
plus de monnaie aujourd'hui?
Ok, c'est ce qu'on doit faire.
Il se termine.
Ok, cool, on va changer les deux
de migrations.
Jordan, nous abîmes.
Qu'est-ce que c'est une migration?
Pourquoi il faut le faire?
C'est
un cas de fond
de la semante semante.
Je pense que
ma définition de migration
pour que je puisse avoir mon travail
fait est quelque chose
où nous changeons
une pièce
fondamentale
de la feature que nous servons.
Et c'est un changement de façon
de la façon dont nous avons
décidé ensemble
comme une équipe.
Et puis il y a beaucoup de détails

et beaucoup de plan qui se change.
Mais pour moi, c'est
un changement fondamentale
qui est en une manière ultimale.
Qu'est-ce que vous pensez de migrations, Jordan?
Vous aimez-vous?
Vous aimez-vous?
Vous avez besoin?
Je pense que le plus grand
de la communauté est que
les migrations ne sont pas
pas des faits de vie.
Elles sont une
façon nécessaire pour vous
pour vous éloigner d'innovation,
des outils positifs,
ou même de payer des techniques.
Elles sont
de bonnes manières pour vous
pour vous donner une balance
de santé pour la organisation
qui veut aller au prochain.
Elles sont toujours en train de ne pas finir.
Une fois que vous avez rempli la migration,
une autre déménagement
ou peut-être que des migrations
peuvent être en même temps
qui peut avoir des conditions
de confliction
en agendas.
C'est vraiment pour construire
la bonne séquence des timelines
entre différents équipes.
C'est un endroit pour être,
si vous voulez,
être quelqu'un qui est organisé.
Mais, comme vous l'avez mentionné,
c'est un des plus positifs
pour les migrations.
C'est juste pour les SREs
que nous sommes migratrices.
Pas mieux.
Bien.
Comment ça affecte vous
avec ces trucs en temps réel?
Parce que ça semble que la migration
peut être un bon nom.
Si ça se passe de la même manière,
et que les gens l'ont remarqué
pendant quelques secondes,
ça semble être une bonne combinaison.
Donc, si vous avez des conseils,
comment nous nous permettons
de nous faire de l'argent
et de ne pas avoir
de l'argent pour nos utilisateurs?
Pour mon équipe,
de la plateforme v1
et de la plateforme v2,
de l'un des grands accounts cloud
pour les épreuver,
et de suivre des pratiques
de la meilleure,
nous avons
accepté que nous serions
juste à cause d'impact.
Il y avait des services
où l'ingénierie
pour la paix à la paix
n'était pas réaliste
ou costeffective.
Et dans ces cas, nous avons été
heureux, à un point
que les dégâts réguliers
sont acceptés.
Les gamers
ne savent pas
que les grandes entreprises,
comme Blizzard, Steam,
ont été en place de la paix
pour les maintenances régulièrement
mais quand nous savons que nous allons
causer un impact, nous allons essayer
de donner beaucoup de notes à l'heure
en jeu et sur les canaux sociaux.
Mais pour
nos services,
nous avons utilisé
une très simple
et relativement simple
pour travailler sur le fait
que nous n'avons pas
un A, B, ou un bleu, gris,
un install de l'infrastructure
et nous avons
utilisé une nouvelle plateforme
et nous avons utilisé des records d'un dégâts
avec des cnames
pour que nous puissions
avoir juste un % de la paix
et que c'était 0
pour que nous puissions commencer
et pour les choses dont nous ne pensions pas
qu'on a besoin de la paix, nous pouvons
envoyer 1 % de notre production
pour la nouvelle plateforme
et voir ce qui s'est passé.
Nous savions que nous savions que nous risquions
1 % de notre expérience, mais
nous avons donné la paix
pour se sentir confident
en envers 5 %
en bas.
On a essayé
et ne nous a pas toujours réussi.
Oui, je pense
Scott a fait un bon travail en enumerant
les stratégies.
Vous avez des options
d'une double ou de la double,
si vous essayez de la mettre en place
ou de différentes plateformes,
c'est là que les bus de message
peuvent devenir vraiment votre ami
et surtout si vous avez une situation
où vous avez à migrer
et que vous avez à valoriser les données
avant de faire les cartouilles,
ce sont les plus longs et plus
plus vides.
Mais oui, le bleu, la graine, les stratégies
et les cartouilles.
Pour des services, peut-être
ce n'est pas encore le temps
d'avoir une stratégie de 0,
pour exemple, j'ai un outil interne
qui a été utilisé par
deux équipes
sur le côté de la business.
Ils utilisent seulement ce service
durant les heures de 8h00
à 5h00 tous les jours et peut-être
je peux juste faire un
clean ou un easy cut-over
par le point d'investissement technologique
durant les heures de 6h00
à 8h00 quand ils ne sont pas en place.
Ça dépend vraiment du service,
de l'intérêt et de
comment il impacte de la perspective business
si vous êtes capable de tolerer.
C'est un traitement.
Bien.
En pensant à ça,
quand vous engagez
les services
pour aider avec la migration ?
Je pense que vous devez
commencer pendant les stages de socialisation
de l'économie
du producteur.
Ces activités sont souvent
un part de l'économie producte.
En pratique, c'est bien malheureux.
On a beaucoup de gens qui nous a mis
et souvent la SRE
s'est invité
à la phase de migration
au milieu ou au bout de la phase de migration.
Les gens sont assez
utilisés pour ça,
ce n'est pas nécessairement un padron
mais d'une manière plus importante
que pour l'involver un groupe.
C'est un bon travail
pour les personnes au sein de
le producteur.
Ça peut aider
à entendre
des développements
plus tôt que le groupe.
Je pense que
dans la manière dont je le vois
dans ma expérience, c'est peut-être
10% ou moins
que les engagements sont souvent
un part actif
de la GEDGLE.
Je pense qu'ils ont fait ça
pour tous les entreprises
parce qu'ils sont risqués de les faire
les ingénieurs si vous avez des questions.
C'est peut-être
un peu en train de le faire
les choses.
Ça matche mon expérience
de la fin.
Les SREs
ont été
un component critique
plus tôt que nous
qui auraient préféré.
Je pense que
mon groupe de SREs est assez
fort que nous avons un bunch de
ingénieurs qui veulent
impliquer l'observabilité
et les méteries et
les déclarer dans tous ces moyens.
Mais oui, il y a
des tensions entre
de la démarche et
de la faire vraiment bien.
Je n'ai pas toujours été en train de le faire.
Scott, je pense que vous avez
mentionné le point de non-retour.
Dans la migration,
si c'est
changer une plateforme, changer l'implementation
d'une toute code base,
changer l'infrastructure,
qu'est-ce que vous vous dis
par un point de non-retour et que
il y a toujours un ?
On peut pas juste rouler le truc
infiniment ?
Comment vous planifiez pour le truc ?
Je pense que
ma philosophie personnelle que je
ai essayé de convaincre mes collègues
et que c'est que
pour un
burden cognitive
et un point de santé
c'est juste
utile d'avoir un point de non-retour
où on peut dire
si nous achève
une parité de feature
à ce niveau
dans le nouveau
développement de la service,
c'est là où nous sommes faits.
Je pense que techniquement, oui,
nous pouvons toujours rouler ou
engénier notre chemin
de la nouvelle chose en arrivant
à quelque chose très près de vous,
mais c'est toujours le plus
oublie.
Donc, c'est toujours un point de non-retour
pour le demandant de la business,
mais si il y a un sénat
pour engénier
l'input, oui, ma choix est
toujours d'avoir un point de non-retour
pour que tous les gens qui travaillent
peuvent sortir
et s'enchaîner
et ne pas avoir de plus
de knowledge historique
ou de la tribe.
Oui, ça aussi
matchs mon expérience.
Quand les équipes créent des plans de jeu
nous faisons un point
de spécifiant
et de cette particularité
c'est le point de non-retour.
Donc, si vous vous coupez
dans le rubicon, il ne faut pas se battre
pour que vous fiez les remaininges issues
que vous pouvez observer dans l'environnement
et vous vous sentez très confortable
de communiquer cela à la reste de la business
autour des préoccupations
que, pour ce point,
il n'y a pas de retour
on doit continuer de faire.
Donc, je pense que, à propos de la transparency
à l'aide de la migration
je pense que c'est très utile
parce que la business sait ce qu'on expect.
Ce n'est pas un sens de non-turbulance
ou de migration.
Cool.
On est en train de faire un moment.
Je dois plus une question
et ça vient de ce que vous avez dit, Jordan.
Sécurité, quand les gens
ont commencé à utiliser le cloud
l'une des choses qu'on parle de
et d'autres choses que la business
pense de la
c'est qu'on donne beaucoup de contrôle.
Ou peut-être qu'on donne beaucoup de responsabilité.
Vous pouvez penser de l'autre façon.
Comment ça arrive
quand il parle de la business ?
Est-ce que c'est un risque versus contrôles
versus
du temps et du cost
et de la flexibilité ?
Vous avez vu que c'est un succès
quand il parle de
ce qui est un risque.
On va utiliser ce malin
qui vit dans l'air,
pas les machines qui
font la main à la nuit.
Comment ça arrive ?
Les épargés.
Ils s'en fassent bien.
Vous pouvez garder les sandwiches.
C'est une question très grande.
Je pense que, à ce point,
le concept public cloud
est, à peu près,
bien bien compréhendant
les expériences qu'ils vont avoir.
Il y a
peut-être
une perception
que le public cloud
est beaucoup plus secure
que la implementation privée.
Il y a des nuances et des shades
de gré à la statement.
Je ne me sens pas comme ça.
Mais la business
a un ad pour la valeur
pour augmenter leur posture.
Ils voient qu'il y a un bénéfice
pour le marché
pour les initiatives
ou quelque chose qui est brand-new
et négatif avec le cloud
des paradigm et des shiftes.
Ils voient que c'est une opportunité
pour vous accélérer la vitesse
pour les expériences de développement
car la plupart des interactions
qui ont un cloud sont à peu près
API-based ou API-driven.
Mais le cloud s'en vient
avec des challenges et des skillsets
donc vous devez
naviguer
ce qui est un souci
que le business n'est pas
fully aware de la transition
de CapEx à OpEx
ou de la façon dont ils attribuent
les costs avec l'OPEX model
pour des équipes spécifiques
dans l'organisation, en tant qu'un
large et responsable.
Ce sont des soucis
qui ne sont pas
préparés pour.
C'est un souci
qui a un sens très déceur
à la vitesse de la maturité.
Maintenant c'est un peu plus
je ne sais pas, le main-stream
pour vous penser que le cloud est trop
expensif et que les margins
peuvent-je potentiellement sauver
par aller en bas à un collage
avec un cloud privilé
pour des workloads spécifiques
qui ne sont pas plus versées.
On va voir la décision de la business
première, la technologie.
Merci pour parler de
ce type de stuff.
Je suis sûr que c'est bien.
Je suis sûr que tout le monde
fait de la cloud.
La dernière question que vous avez
aujourd'hui est de penser
à des gens que vous avez travaillé
dans le passé, qui peut-être
été sur la team IT que vous avez
déjà fait avant Scott,
ou à des gens qui n'étaient pas
SREs.
Peut-on nous entraîner pour devenir
SREs ? Quels sont les
responsabilités ?
La team IT classique
quand j'ai
dépassé les gens pour rejoindre
la plateforme online, j'ai été
de la carrière avec moi, un peu de leur
roadmap et des goals, et puis
apprendre un whole bunch de nouvelles
skill, et l'idée originale
était de la channelle et de leur
apprendre de la manière dont je
était trop fous sur
comment les choses sont plus belles.
Mais maintenant, nous avons
réaléé un peu et
beaucoup de leur travail
est de s'attendre à
le style que nous avons
dépassé pour la manière dont nous
avons construit notre infrastructure, et puis
de prendre les reins de nous en quelque
manière. Donc oui, je pense
que c'est un skill set qui peut être
proposé par les gens
classiques et
qui peuvent être utilisés
pour faire leurs vies plus
plus facile, c'est la chose que j'ai
fait.
C'est certainement possible et mon
expérience est vraiment la
personne ou les équipes qui
sont en train de faire la transformation.
C'est un peu de la
personne, de la vie, de la
re-skilling, de la re-skilling,
vous devez créer un environ
positif qui encourage
ce type de transformation.
Ce n'est pas le cas overnight, c'est
généralement, je ne sais pas, à
least 6 à 12 mois pour quelqu'un
qui peut être en train de
faire cette tournée et
être plus confortable avec le skill set
et les responsabilités.
Les bonnes news c'est que
des fondamentaux sont toujours
les mêmes, c'est-à-dire que si vous savez
comment les compétences travaillent
au niveau fondamental, les
cpu, les nettoies, les
storage, ceux qui translèrent
très très bien.
Je pense que c'est la plus grande
chose, comment on translerait
l'APL
sur les fondamentaux,
pour en apprendre
comment ça fonctionne,
savoir qu'il a un skill set
dans des frameworks
spécifiques, comme Terraform
et maybe Golang.
Ce sont les zones qui
sont des fonctions de la steppe
pour la compétence et la compétence
de mon expérience.
Merci, avant de finir
vous avez une
fin de take,
ou peut-être où les gens peuvent apprendre
plus sur vous en ligne, si vous avez un blog
des gens qui vont faire un blog, je pense qu'ils le font.
Les socials.
Ou quelque chose comme ça,
comme les enfants disent, quelque chose comme ça
que vous voulez un shout out?
Non, pour moi je m'envoie tout ça.
Bonne réponse, bonne réponse.
Probablement pour le meilleur, honnêtement.
Pour moi, vous pouvez me trouver
assez active dans la communauté de la
plafondation de la communauté de Slack.
Évidemment, vous pouvez me faire
sur LinkedIn. Je vais essayer
de faire une poste
de la plafondation de la plafondation
chaque friday.
Si vous me followz sur LinkedIn, vous allez
voir la subscription
de mes services.
J'ai hâte de vous voir.
Merci. Merci beaucoup.
Merci tout le monde,
merci à notre guest, Scott et Jordan
pour nous aider à shopper
et à jouer.
Nous devons être contents
d'avoir le plaisir,
surtout si tout le monde est en train
de faire des fiers pendant le jour,
de garder nos autres services en vie.
Bonne journée, tout le monde.
Bye.
Merci beaucoup.