►
From YouTube: In the Clouds (E20) | How SRE teams boost DevOps
Description
Site Reliability Engineers (SREs) are a fast-growing and in-demand position that has quickly spread into every corner of IT. What are the different roles that SREs play and the interaction between enterprise customers and the SREs of the services that they consume? In this episode, host Stu Miniman is joined by Candace Sheremeta and Christoph Blecker to discuss how Site Reliability Engineering teams can help continuously improve the reliability and performance of cloud platforms, how SREs take DevOps to the next level, and how the SRE role can benefit your business or organization.
Want to learn more?
https://cloud.redhat.com/blog/5-agile-practices-every-sre-team-should-adopt?sc_cid=7013a000002qG16AAE
https://cloud.redhat.com/learn/topics/openshift-site-reliability-engineering?sc_cid=7013a000002qG16AAE
Try Red Hat OpenShift: https://red.ht/3Haxapr
Follow us:
Stu Miniman https://twitter.com/stu
OpenShift https://twitter.com/openshift
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_confirmation=1
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
OpenShift on redhat.com https://red.ht/3JBaOia
OpenShift on GitHub https://github.com/openshift/
#RedHat #OpenShift #HybridCloud
A
C
A
Welcome
to
in
the
clouds,
I
am
your
host
stu
miniman
and
I'm
sure,
like
you,
I'm
shocked.
We
are
already
in
march
of
2022.,
sometimes
a
little
bit.
I
have
to
remind
myself
what
year
it
still
is
at
this
point,
and
the
months
have
seemed
to
fly
on
by
and
really
excited.
We
are
going
to
be
talking
today
about
site,
reliability,
engineering,
hopefully
sre
is
a
term
that
you
are
familiar
with
and
I'm
really
happy
to
have
two
of
the
red
hat
sre
team.
A
Here
with
me,
I've
got
candace
shermeta
and
christoph
blecker,
as
I
said,
both
both
with
the
sre
team
and,
let's
hop
right
into
it,
candace.
Why
don't
we
start
with
you
tell
us,
you
know
how
long
you've
been
with
red
hat
your
role
here,
and
you
know
what
was
the
you
know,
the
quick
summary
path
that
led
you
to
to
be.
You
know
that
mythical
sre.
B
Sure
so
hi,
I'm
candace.
I
have
been
with
red
hat
for
about
seven
years
now.
I
am
actually
started
here
with
a
couple
of
internships
and
then
got
hired
in
full
time
as
a
tech
support
engineer
spent
some
time
supporting
both
satellite
and
openshift.
While
I
was
in
tech
support
and
then
going
from
supporting
openshift,
I
knew
I
wanted
to
go
into
a
role
that
did
a
little
more
software
engineering.
C
C
A
Awesome,
thank
you
both
yeah.
It's
always
fascinating
to
hear
kind
of
the
those
paths
to
sre
candace,
something
that
jumped
out
on
me.
You
talked
about.
You
know
software
development.
You
know,
sre
is
not.
You
know,
you
know
it's.
Some
people
would
look
at
it
and
be
like
wait.
Is
this
kind
of
you
know
the
next
gesture
generation
sysadmin?
A
You
know
how
does
devops
fit
into
it?
You
know
what
does
writing
code
fit
into
what
you're
doing
so,
maybe
if
you
could
tease
out
a
little
bit
for
us,
you
know
that
that
you
know
the
the
day-to-day
activities
that
you
know
your
team
works
on.
You
know
you've
been
the
individual
contributor.
You've
now
got.
You
know
some
people
reporting
to
you.
You
know
that
balance
of
activity
that
that
you
work
on.
B
Absolutely-
and
it
is
really
a
great
balance
of
a
variety
of
activities
that
we
do
on
the
sre
team,
so
I
did
mention
software
development.
Our
sre
team
is
maybe
a
little
bit
different
from
sort
of
the
google
standard
of
sres.
In
that
we
do
write
a
lot
of
new
features
for
the
product
that
we
develop.
B
So
basically,
what
we
do
is
we
take
the
base
openshift
product
and
write
some
things
on
top
of
that
and
and
package
that
up
and
deliver
it
as
a
managed
service,
and
so
our
sre
team,
because
we're
writing
new
features
and
and
delivering
those
to
customers.
We
do
have
a
lot
of
software
engineering
that
we
do
in
order
to
write
those
features.
We
write
a
lot
of
operators,
lots
of
things
in
goaling,
etc,
but
we
also
have
a
balance
of
a
variety
of
other
things.
B
We
have
to
do
as
an
sre
team
in
order
to
to
make
everything
sort
of
run
smoothly.
So
we
also
you
know.
We
balance
that,
with
operational
work,
on-call
rotations,
making
sure
that
the
clusters
that
we
maintain
are
healthy,
making
sure
that
the
service
that
we
offer
to
our
customers
is
reliable
and
scalable.
B
B
We
work
a
little
bit
in
the
middle
in
really
focusing
our
efforts
on
how
do
we
make
this
service
reliable
and
scalable?
How
do
we
make
sure
that
we
as
sres
can
support
the
service
that
we
are
offering
to
customers
and
and
that
we
don't
have
to
scale
the
sre
team
linearly
with
the
number
of
clusters
that
we
scale
or
the
number
of
customers
that
we
have?
A
Yeah
that
scaling
is
such
an
important
piece.
You
know
christoph
you,
you
know
my
background.
Is
networking
not
not
as
deep
as
yours
is,
but
you
know
that
that
scalability
is
something
you
think
about.
You
know
the
typical
you
know
network.
You
know,
you
know
architect
right
the
thing
that
canda
said
I'm
concerned
about
like
wait
as
I
have
more
customers
and
as
they
grow
is
the
burden
going
to
be.
You
know
more
and
more
on
my
team.
A
Can
you
speak
a
little
bit
from
your
standpoint
and
I
guess
what
I
also
want
to
understand.
Is
you
know
you
know
we
have
services
that
are
running
on
top
of
a
public
cloud,
so
you
know
we
mentioned
you
know.
Google,
google
invented
sres.
You
know,
google
has
a
phenomenal
network,
you
know,
probably
you
know
you
could
argue
they
have
the
best
network
in
the
world
for
what
they're
doing
underneath.
So
what
do
we
need
to
do?
C
But
we
need
to
understand
kind
of
where
the
rough
edges
are
in
those
networks.
And
we
need
to
be
able
to
deeply
kind
of
understand
those
rough
edges.
And
how
can
we
increase
our
observability
into
that,
not
being
like
not
being
the
the
the
entity
that
actually
owns
that
network,
which
which
could
sometimes
sometimes
be
a
a
a
challenging
thing?
But
you
know,
especially
when
we're
supporting,
like
the
the
sre
team,
supports
the
the
three
big
cloud
providers
aws
and
google
and
azure.
C
So
each
one
of
those
as
we're
moving
from
different
network
different
network
has
their
own
rough
edges
that
were
we're
constantly
learning
some
of
them.
We're
working
with
our
partners
on
this
cloud
providers
to
to
fix
any
bugs
that
we
find,
as
well
as
adapting
our
service
to
be
resilient
in
the
face
of
any
of
those.
Those
rough
edges
that
that
might
come
up.
A
Okay
and
when
I
think
about
you,
know
the
the
the
the
goals
of
the
sre
team,
can
you
speak?
You
know
what
does
the
customer
see?
So
you
know
I
think
about
you
know
from
a
google
standpoint.
I
don't
necessarily
think
about
the
sres
they're,
the
ones
kind
of
behind
the
curtain.
They
run
a
service,
but
how
about
from
from
the
red
hat
service
you
know.
Is
there
interaction
between
our
sre
team
and
the
customers?
And
you
know
some
customers
have
sres.
A
C
I
would
say
the
in
the
best
case
scenario:
you
don't
have
to
hear
from
us,
because
the
service
is
up,
it's
running
it's
reliable
and
that
the
the
customers
that
are
deploying
things
onto
to
our
network
and
on
to
our
service
have
all
the
tools
and
visibility
that
they
need
like.
We
will
build
built
out
like
self-service
and
that
kind
of
stuff
to
allow
those
those
folks
to
do
what
they
need
to
do
and
for
us,
as
an
sre
team,
every
time
that
we
as
humans
need
to
touch
a
component.
C
If
that
that
time
that
we
spend
there
limits
our
ability
to
scale
as
candace
was
saying
like
we,
we
want
to
scale
the
service
that
we're
building
without
necessarily
linearly
hiring
more
humans
to
interact
with
it.
So
if
we
can
build
out
practices
and
self-service
and
automation
to
handle
those
for
us
and
to
enable
the
consumers
of
our
platform
to
do
what
they
need
to
do
without
humans
being
involved,
that's
the
best
case
scenario.
C
But
the
best-case
scenario
doesn't
always
happen.
Sometimes
there
are
bugs
and
incidents,
and
that
kind
of
stuff
that
that
that
crop
up
and
in
the
in
those
cases,
the
red
hat
sre
team
does
very
regularly
engage
on
customer
specific
issues
that
are
raised
through
our
support
teams,
as
well
as
we
handle
all
the
proactive
monitoring
for
the
platform.
So
again,
hopefully,
if
you're,
if
there's
a,
if
there
does
end
up
being
a
problem,
you
will
hear
from
us
in
most
cases
before
we
need
the
before.
B
Another
way
that
we
interact
with
customers
is,
you
know
we
want
to
provide
a
white
glove
service
for
our
customers.
You
know
we're
competing
with
pretty
major
services
like
aks
and
eks,
and
what
we
want
to
do
as
an
sre
team
is
have
the
one
up
on
on
those
options
on
our
competitors
by
providing
our
customers
with
exactly
what
we
need
and
so
frequently
we
will
have
conversations
with
customers
before
they
even
sign
up
for
our
services
to
ask
them.
You
know
what
is
it
that
you
need
from
our
service?
B
Is
there
any
sort
of
feature
that
we
can
add
into
our
service?
That
would
you
know,
help
you
make
the
decision
to
come
and
join
us
as
opposed
to
some
of
our
competitors,
and
so
we
do
a
lot
of
requirements
gathering
with
our
customers
before
they
join
our
our
service,
and
we
we
take
all
of
those
requirements
and
work
on
trying
to
figure
out
if
there's
a
way
and
usually
we're
pretty
successful
at
this.
B
We
do
this
a
lot,
but
we
try
to
figure
out
if
there's
a
way
to
work
those
requirements
into
our
service
in
such
a
way
that
it's
available
to
all
customers
or-
or
you
know,
if
the
customers
don't
want
it,
they
can.
They
can
kind
of
ignore
that
option
and
and
use
our
service
without
necessarily
needing
the
the
new
features
that
we're
adding.
On
top
of
it.
We
have
a
pretty
opinionated
installer
right
now.
B
We
obviously
want
to
make
sure
that
all
of
our
clusters
are
aligned
to
some
kind
of
standard
so
that
when
sres
are
logging
into
clusters
and
working
on
clusters,
they
have
a
good
idea
of
what
they
should
expect
to
see
in
that
cluster.
And
so
we
we
have
a
pretty
opinionated
installer
and
a
pretty
standardized
suite
of
software
that
we
run
on
the
clusters,
and
we
want
to
make
sure
that
in
meeting
our
customers
requirements
we're
giving
those
options.
C
A
Well,
you
actually
you
you
already
started
to
dig
into
a
question.
I
want
to
ask
here.
So
if
you
know
I
think
about
you
know
in
the
data
center,
one
of
the
biggest
sins
we
had
is.
I
would
you
know
architect,
this
beautiful
temple
for
my
application
and
I
use
all
the
little
geek
knobs
and
I
make
sure
that
it
gets
the
scalability
and
the
performance
that
I
need.
But
you
know
you
know
snowflake.
No,
I
mean
this
is
a
beautiful
temple
that
we
spend
18
months
building
for
exactly
the
requirements
and
making
changes.
A
It's
very
tends
to
be
more
rigid,
and
when
I
go
to
the
cloud
you
know
I
need
scalability
and
I
need
performance,
but
I
need
to
be
able
to
move
faster.
So
how
do
we
make
sure
that
we
can?
You
know
how
do
the
customers
learn
to
be
able
to
build
properly,
to
take
advantage
of
the
cloud
services
without
having
to
you
know
get
to?
You
know
that
that
snowflake
environment,
because
everybody's
environment's
a
little
bit
different?
A
C
You
know
when
you're
a
company
like
google
or
facebook,
or
something
like
that
you're
not
dealing
with
you're,
not
thinking
about
things
at
a
server
level
like
an
individual
server,
an
individual
piece
that
you're
building
out
you're
thinking
about
entire
racks,
you're
thinking
about
entire
data
centers
at
a
particular
level,
and
that's
actually
one
thing
that
kubernetes
offers
just
in
general
to
to
to
consumers
of
it,
is
instead
of
thinking
about
things
at
the
the
small
scale.
You
can
think
about
things
at
a
slightly
larger
scale.
C
C
And
we
need
to
think
about
it.
At
kind
of
that
wider
scale.
That's
kind
of
like
at
least
the
starting
point
for
for
me
of
that
philosophy,
is
trying
to
zoom
out
and
take
what
take
once
one
step
back,
because
you
might
craft
a
specific,
like
your,
as
you
say,
like
craft,
your
perfect
temple
to
for
for
your
application
to
run
in,
but
as
we
are
moving
faster
and
we're
like
upgrading,
more
and
there's
more
features
and
you're
wanting
to
take
advantage.
C
You're
going
to
have
to
rebuild
that
temple
over
and
over
and
over
again
and
the
less
that
you
can
do
of
that,
rebuilding
the
temple
where
you
can
say.
Okay,
I
have
this
smaller
package.
I
have
the
smaller
service
this
one
particular
application.
I
don't
care
where
it
runs.
It
makes
it
a
lot
easier
to
kind
of
swap
those
individual
parts
out.
B
Yeah,
I
I
agree
with
christoph
absolutely,
and
I
I
think
that
stu,
you
know
thinking
about
your
question
in
regards
to
how
do
we
sort
of
educate
our
customers
and
how
do
we
enable
them
to
to
run
what
their
applications
on
our
service
and
and
to
use
our
service
in
a
way
that
that
works
for
them?
You
know,
I
think
what
we
try
to
do.
B
Is
we
try
to
take
away
the
need
for
that
even
like
the
premise
of
the
question
is,
is
a
little
strange
for
us,
because
we,
ideally
our
customers,
don't
need
to
know
a
whole
lot
about
the
service
and
this
kind
of
gets
into
what
kristoff
was
saying.
You
know
if
they
can
just
send
us.
Their
engineering
teams
and
their
engineering
teams
have
applications
that
perhaps
they
want
to
containerize
they're
already
containerized.
B
You
know
the
engineering
team
can
just
really
focus
on
you
know:
let's
get
our
applications
containerized
and
let's
put
them
on
this
platform,
and
they
don't
need
to
know
all
of
the
ins
and
outs
of
the
openshift
platform
itself,
which
is
really
the
great
value
of
having
an
sra
team
here
at
red
hat.
Managing
the
platform
for
the
customers,
you
know
just
just
the
idea
that
you
don't
need
to
hire
openshift
admin,
you
don't
need
to
have
someone
who's
who's,
an
expert
in
kubernetes.
B
You
know
just
just
containerize
your
applications
and
and
roll
them
out
on
our
platform,
and
you
know
we'll
kind
of
take
care
of
the
rest
behind
the
scenes.
So
you
know
we
do
obviously
have
some
customer
education
efforts.
You
know
we
have
plenty
of
documentation
in
case
they
want
to
learn
more
about
the
openshift
platform
and
they
want
to
dig
in
and
of
course,
they
are
unable
to
kind
of
get
into
it
as
much
as
they
really
want
to.
A
Them
in
candace,
I
appreciate
you,
you
know
calling
out
that
right.
I
should
have
a
different
mindset
when
I
think
about
you
know
cloud,
I
think
about
sas
applications.
You
know
one
of
the
things
that
comes
up.
You
know
we
should
be
getting
away
from
thinking
about
things
like
upgrades,
so
you
know
I
I
remember
when
I
first
heard
coreos
and
they
said
you
know,
I
should
be
able
to
think
of
my
infrastructure.
The
way
that
I
think
of
chrome
chrome
is
running
it
just
updates.
A
In
the
background,
it
always
has
the
latest
security
patches.
Well,
you
know
how
about
from
our
services,
so
openshift
rolls
out
now
we're
about
three
times
a
year.
Ideally,
I'd
love
you
to
hear
you
say:
well,
hey
customers,
don't
even
need
to
think
about
it.
We
just
roll
the
latest
version
that
we
have,
but
we
know
one
of
the
things
that
red
hat
offers
for
for
customers.
If
they're
self-managing
openshift
is
there's
some
longer-term
supports,
we
make
sure
we
can
go
from.
You
know
one
version
to
another.
A
B
Yeah,
so
we
we,
I
mean,
I
I
think
that
I
can
say
you
don't
really
need
to
worry
about
it.
We
do
have
a
managed
upgrade
process.
The
upgrades
can
be
completely
automated.
You
actually
get
to
choose
when,
when
you
sign
up
and
install
the
cluster
you
get
to
choose.
If
you
want
the
upgrades
for
that
cluster
to
be
automated
or
not,
and
if
they,
if
you
choose
them
to
be
automated,
and
of
course
we
encourage
everyone
to
do
that.
You
know
they're
completely
automated.
B
We
we
keep
you
on,
usually
n
minus
one
and
kristoff
might
be
able
to
speak
a
little
bit
better
to
this
than
I
will,
but
we
usually
keep
you
somewhere
around
the
latest
version:
minus
minus
one
y
stream
or
sorry,
one
z
stream,
and
so
you
know,
there's
there's
not
really
a
whole
lot
to
to
worry
about
there.
If
you,
if
you
choose
to
not
do
the
upgrades
in
an
automated
way,
you
know
there's
there's
a
little
more,
obviously
that
you
need
to
worry
about.
C
Yeah,
so
a
a
couple
points
on
how
we
handle
upgrades
number
one.
We
have
the
benefit
of
a
ton
of
data
from
our
the
openshift
fleet,
not
just
the
managed
openshift
fleet
but
openshift
as
a
whole
to
understand
when
upgrades
are
successful
and
where
we
hit
specific
corner
cases
and
and
bugs
in
in
that
openshift
upgrade
process.
C
So
we
we
can
take
all
that
data
and
we
can
determine
when
a
particular
version
has
has
hit
that
that
that
that
kind
of
level
where
we
know
that
there's
enough
upgrades
that
are
running
and
stable,
that
we
can
actually
roll
something
out
to
the
the
entire
fleet
and
select
the
next
version
that's
going
to
roll
out
to
the
fleet,
but
in
in
the
managed
service
context.
We
do
that
all
for
you,
like
that's
all
kind
of
abstracted
away
from
you
as
the
customer.
You
don't
need
to
need
to
necessarily
think
about
that.
C
We'll
just
tell
you
hey,
there's
an
upgrade
available.
The
one
kind
of
consideration
that
we
we
have
to
push
out
to
to
our
consumers
and
and
that
customers
need
to
be
mindful
of
is
there's
still
some
limitations
around
things.
Like
api
deprecations,
so
when
there's
changes
in
kubernetes
upstream
and
there's
things
where
you
might
need
to
change
the
particular
manifests
in
your
application,
we
will
alert
you
like
hey.
This
upgrade,
isn't
necessarily
safe
to
do.
C
Unless
you
fully
understand
what
your
application
looks
like
and
you
may
need
to
make
some
changes,
but
as
a
managed
service,
we
can
flag
those
up
to
you
and
direct
you,
okay.
So
here's
step
by
step
how
you
can
do
that
to
make
sure
your
application
is
ready
for
that
next
version
of
kubernetes
and
then,
when
you're
ready,
we'll
take
it
from
there
and
handle
the
entire
upgrade
process
for
you.
A
Awesome
well,
we
we've
been
talking
mostly
about
what
we
call
our
platform
services.
So
that's
the
the
openshift
based
activities.
Last
year,
red
hat,
we
rolled
out
application
services
which
can
run
on
top
of
them.
Maybe
could
you
speak
a
little
bit
to
you
know
your
visibility
into
the
red
hat
portfolio?
C
Yes,
thank
you.
Sorry,
I'm
just
used
to
all
the
acronyms
for
now
so
sometimes
it
becomes
a
little
bit
acronym
soup
pretty
quickly
but
yeah
like
there's.
There's
these
specific
products
that
that
enable
your
application
to
either
perform
better
or
an
easier
or
to
be
able
to
take
an
application
that
you've
designed
on
premise
and
get
it
running
in
the
cloud
faster.
So
those
those
kind
of
those
kind
of
building
blocks
that
we
can
put
on
top
of
the
foundation
are
crucially
important
and
red
hat.
C
Does
this
internally
as
well,
where
a
lot
of
a
lot
of
our
services,
like
you
know,
I'm
thinking
things
like
quay.I
o.
We
also
build
them
on
top
of
the
same
platform
that
we
are
are
then
turning
in
turn
offering
to
to
our
customer
base
and
having
that
kind
of
common
foundation
allows
us
to
find
all
of
those
like
weird
rough
edges
that
happen
in
large
scale
applications
so
that
those
those
issues
and
things
can
be
resolved,
hopefully
before
any
customer
ever
notices
them.
A
Yeah,
I
I
guess
one
of
the
other
things
that
wanted
to
touch
on
that
people
might
not
be
aware
of
is
red
hat,
does
a
lot
of
maintaining
certifications
and
something
that
obviously
customers
need,
but
that
it's
one
of
those
is
it
something
that
they
will
need
to
do
themselves,
or
is
it
something
that
that
the
service
can
offer?
Okay?
Can
other
of
you
talk
a
little
bit
about
some
of
the
the
ongoing
certifications
that
are
that
are
done
to
help
me
make
sure
that
customers
are
meeting
certain
governance,
compliance
type
activity.
B
Yeah,
absolutely
so,
just
like
you
said
stu,
we
have
a
number
of
certifications
that
we
have
already
accomplished.
We
actually
have
a
list
in
our
documentation
of
the
various
ways
that
our
managed
services
are
certified.
According
to
you
know,
a
variety
of
security
compliances
and
things
like
that,
we're
also
in
the
process
of
working
on
new
certifications.
B
All
the
time,
one
of
the
one
of
the
big
projects
that
we're
working
on
this
year
is
fedramp,
and
so
we're
really
excited
about
getting
that
certification
going
and
and
being
able
to
offer
our
services
to
the
public
sector
to
to
government
customers.
Here
in
the
us,
we
yeah
so
we're
doing
things
like
that,
all
the
time
and
trying
to
make
sure
that
we
offer
a
service
that
that's
you
know
certainly
flexible
and
meets
our
customers
needs,
but
also
is
very
secure
and
and
gives
our
customers
some
reassurance
about.
C
Yeah
and
a
lot
of
the
the
certifications
and
stuff
that
we
we
have
and
are
working
on,
a
lot
of
them
focus
around
like
not
just
security,
but
also
best
practices,
around
change,
management
and
and
that
kind
of
stuff.
But
the
the
practices
and
policies
that
we
have
in
place
are
detailed
and
are
are
going
to
ensure
that
the
service
is
is
reliable,
that
it's,
you
can
get
a
consistent
experience
and
that
we
have
audit
trails
for
for
everything.
A
Yeah,
I
guess
the
last
topic
is
just
you
know.
Your
teams
are
spanning
across.
You
know
multiple
clouds
dealing
with
lots
of
different
customers
in
their
environments.
You
know
what
what
kind
of
best
practices
do
you
have
that
that
you
can
share
with
others?
You
know
we
always
look
at
kind
of
the
community
of
practice
of
everyone
involved.
You
know
tips
that
you
give
back
what
what's
so
and
red
hat's
always
heavily
involved
in
communities.
B
So
we've
already
touched
on
one
of
the
sort
of
strategies
that
is,
you
know,
is
the
in
the
forefront
of
my
mind
all
the
time
in
regards
to
how
to
run
a
great
sre
team,
and
that
is
you
know,
standardization
and
making
sure
like
christoph
said
earlier,
that
you're
not
introducing
snowflakes
into
your
fleet
of
clusters,
and
I
think
that's
that's
the
importance
of
that.
Really
can't
be
understated.
B
You
know
if
you
have
that
sort
of
standardization
and
you
don't
have
those
snowflake
clusters,
you're
really
going
to
be
able
to
allow
your
sres
to
to
know
what
they're
getting
into
whenever
they
log
into
a
cluster,
and
it's
really
going
to
add
to
their
ability
to
support
and
maintain
the
clusters
in
in
that
way.
So
I
would
start
there.
B
You
know
saying
if
you're,
if
you're
thinking
about
starting
up
an
sre
team,
definitely
put
a
lot
of
time
and
thought
into
how
your
fleet,
how
your
your
service
is
going
to
be
standardized
across
the
fleet.
But
there
are
some.
There
are
some
other
strategies
that
we
have
in
place
as
well.
One
one
thing
that
we
kind
of
touched
on
a
little
bit:
you
know
in
thinking
about
how
secure
the
the
clusters
are
and
how
we
try
to
maintain
security,
compliance,
cert,
certifications
and
things
like
that.
B
We
also
want
to
make
sure
that
we
find
balance
between
that
sort
of
security
and
user
enablement,
and
so
that's
sort
of
we
have
that
tension
quite
a
bit.
Although
we
see
that
quite
a
bit
on
the
team
where
we
want
to
enable
our
customers
to
use
the
clusters
in
a
way
that
works
for
them
and
and
that
they
feel
good
about.
But
we
also
want
to
make
sure
that
we
maintain.
B
You
know
certain
standards
around
security
and
compliance
and
and
what
have
you
and
also
make
sure
that
we're
not
introducing
enablement
in
our
environment,
that
that
makes
our
sre's
life
hard
and
or
harder
in
any
way.
And
so
we
we.
We
have
to
find
balance
there
as
well,
and
so
that
would
also
be
something
that
I
would
recommend
if
you're
thinking
about
starting
an
sre
team.
You
know
think
about
where
how
you
find
that
balance
between
user
enablement
and
making
your
products
stable.
Secure
reliable,
scalable,
et
cetera.
C
C
You
can
scrape
all
sorts
of
data
out
of
your
environment,
but
it's
important
to
try
and
find
what's
important
to
to
you
and
your
business
and
your
business
goals
so
that
you're
not
just
swamped
in
data
and
not
able
to
actually
make
decisions
that
actually
benefit
you
an
important
kind
of
way
of
looking
at.
That
would
be
if
your
goal,
like
you
know
a
lot
of
folks
focus
on
uptime
as
as
a
goal,
but
sometimes
uptime
is
not.
The
most
important
factor
to
think
about.
C
Uptime
can
be
really
important,
like
if
you're
running,
for
example,
like
an
e-commerce
platform
or
site.
If
your
site
is
offline,
you're
directly,
like
you're,
not
able
to
make
sales,
and
that
can
directly
impact
your
your
bottom
line
as
an
organization,
but
sometimes
you'll
want
to
balance
hey.
Maybe
we
sacrifice
a
little
bit
of
uptime
for
being
able
to
deploy
faster,
to
get
more
features
out,
because
again,
the
demand
for
your
particular
business
goals
requires
you
to
ship
faster
and
to
ship
more
features,
so
understanding
what
your,
what
your
goals
are,
and
what?
C
What
is
your
service
level
objective,
and
sometimes
that
can
be
a
technical
objective.
Sometimes
it
can
be
a
people
objective.
You
know
you,
maybe
you
don't
want
to
burn
out
your
humans
that
are
working
on
your
your
system.
So
it's
important
to
think
about
those
things
like
what
is
the
actual
goal
that
you're
trying
to
get
to
so
that
you
can
know?
How
do
I
observe
that
goal
and
what
kind
of
steps
can
I
work
towards
achieving
that
goal
and
are
the
steps
that
I'm
taking?
C
The
second
thing
that
I
want
to
bring
up
that's
kind
of
related
to
that
is
again
empathy
for
the
people
and
that
are
working
around
you
to
achieve
that
goal.
You
know
it's
very
easy
to
get
caught
up
in
systems
and
technology
and
moving
fast
and
that
kind
of
stuff
you
know,
but
the
differentiator,
at
least
in
my
experience
of
whether
you're
actually
going
to
be
successful
in
the
long
run
is,
do
you
have
empathy
for
everyone
around
you?
C
Do
you
have
empathy
for
your
customers
and
the
situations
that
they're
facing
and
they're
going
through?
Do
you
have
empathy
for
your
colleagues
and
and
the
the
stressors
that
they
might
be
going
through
if
you
can
bring
empathy
to
that
conversation
and
actually
again
use
the
empathy
to
kind
of
figure
out
what
the
goals
are
and
how
to
achieve
those
goals?
You're
going
to
be
a
lot
more
successful
in
the
long
run,
building
out
whatever
service
that
you're
trying
to
do.
B
Yeah
to
follow
up
on
that
point
christoph
makes
a
great
point
about
empathy,
but
to
get
a
little
bit
deeper
into
that,
I
think
it's
super
important
that,
in
in
starting
up
an
sre
team,
you
think
about
what
teams
you
are
going
to
have
to
interact
with
the
the
sre
team
is,
is
obviously
not
the
only
team
that
that
allows
us
to
provide
the
service
that
we
provide.
You
know
we
we
have
relationships
with
the
openshift
engineers
who
work
on
the
base
platform.
B
We
have
relationships
with
tech
support
engineers
who
help
us
support
the
customers
that
that
consume
our
our
services
and
in
going
into
you
know
the
idea
of
I
need.
I
want
to
create
an
sre
team.
You
really
have
to
consider
what
do
you?
What
do
you
need
those
relationships
with
those
other
teams
to
look
like
you
know?
What?
What
are
you
going
to
do
when
you
know
there's
an
incident?
You
know
things
are
on
fire.
B
How
do
you
get
in
touch
with
the
people
you
need
to
get
in
touch
with
if
they're,
not
on
your
team?
That
kind
of
thing
we're
very
lucky
here,
with
with
our
sre
team,
to
have
really
close
relationships
with
the
openshift
engineers
where
we
can
reach
out
and
say:
hey
we've
got
a
cluster
down
right
now.
We
need
some
help
from
from
this
particular
team.
B
A
Well,
kristoff
and
candace,
I
think
so
some
really
important,
you
know
information.
You
shared
some
really
good
tips
there.
I
I
know
I
had
a
general
understanding.
You
know
I'd
interviewed
plenty
of
sres
before
I
joined
red
hat,
but
you
know
the
sre
team
at
red
hat
is
something
that
you
know
really
impressed
me
even
more
once
I
joined
the
company,
I
got
to
be
part
of
some
meetings
get
to
know
some
of
the
people
involved.
A
So
I
know
I
have
lots
of
conversation
with
customers
and
you
know
to
your
point
kristoff
right.
Just
because
you
can
do
something
doesn't
mean
it's
necessarily
the
right
one.
You
know
I
I
feel
like
I'm
pulling
out
what
little
hair
I
had
left
when
it
was
like.
Oh
hey,
oh
yeah.
No,
no.
We
threw
100
engineers
on
that
and
in
two
years
you
know
we
made
a
lot
of
progress
on
that
and
it
was
like
wow.
You
know.
A
If
you
had
partnered
with
us,
you
could
have
spent
those
two
years
working
on
some
higher
level
things
because
our
team
already
does
this.
For
you
know
hundreds
of
customers
on
a
regular
basis.
So
you
can
spend
more
of
the
time
on
the
the
measurements
and
the
things
that
are
important
for
your
business,
not
and
let
us
run
more
of
the
infrastructure
for
you,
so
both
of
you.
A
Thank
you
so
much
for
your
time
great
to
hear
from
you-
and
I
I
know
our
team
is
also
hiring
so,
if
you're
interested
in
learning
more
lots
of
resources
online
and
if
you
check
jobs.redhat.com,
you
can
learn
about
some
of
the
openings
that
are
have
there
so
kristoff
candace.
Thank
you
again
for
for
joining
us,
I'm
stu
miniman
and
as
always,
thank
you
for
joining
us
in
your
journey
in
the
clouds.