►
From YouTube: Site Reliability Engineer in a Large Organization, s CD Foundation Online Meetup hosted by DeployHub
Description
Large Organizations that have grown organically have a complex technology landscape and an ingrained culture that poses challenges to adopting SRE ways of working. Shivagami Gugan is an Aviation IT Technologist who has experience in transforming large teams. She has international experience in building Digital and IT organizational strategies and in delivering large technical portfolios in mission critical environments. She has devised software engineering and outsourcing strategies, led service management implementations and her current focus is to help teams adopt DevOps, SRE practices and hybrid cloud across a varied application landscape. This meetup will help if you would like to discuss about challenges related to transforming the people mind-set or about building robust DevOps platform to help convert Monoliths to Microservices.
A
So
we
do
have
people
still
coming
on,
but
I'm
going
to
go
ahead
and
get
us
started.
I
am
tracy
reagan,
ceo
of
deploy
hub
and
we
host
and
manage
the
cd
foundation
online
meetups.
I
myself
am
a
board
member
of
the
cd
foundation
and,
if
you've
never
heard
of
the
cd
foundation,
it
is
part
of
the
linux
organization.
A
We
are
a
group
of
the
five.
The
projects
that
we
are
managing
includes
jenkins
jenkins,
x
spinnaker,
which
are
two
really
big
cd
tools
just
right
there.
We
also
have
tekton.
If
you
haven't
heard
of
tecton,
it's
part
of
google
and
our
last
adoption
was
a
company
called
screwdriver,
a
very
interesting
little
tool
that
has
a
pretty
strong
heart
and
engine
so
I'd
take.
I
would
suggest
you
all
take
a
look
at
the
cd
foundation,
so
you
know
what
we're
all
about
today
I
so
I
have
been.
A
I
decided
to
go
on
a
journey
and
talk
to
as
many
people
who
are
doing
microservices,
sres
and
cloud
architects
as
possible,
and
I
met
shivagami
when
she
responded
to
a
linkedin
request
that
I
said:
hey
you're
doing
some
cool
work
around
sre,
your
you
know
leading
sres.
I
want
to
hear
what
your
challenges
are
and
what
you're
doing,
and
that
led
to
this
fascinating
conversation
and
she
was
willing
to
do
this
presentation
for
us.
She
is
an
aviation
I.t
technologist
and
she
has
a
lot
of
experience.
Transforming
very
large
teams
now.
A
Transforming
large
teams
is
pretty
critical
right
now,
as
we
move
into
moving
from
monolithic
to
microservices,
and
so
I
she
has
a
lot
of
expertise
in
how
to
do
that
and
how
to
manage
big
sre
practices.
While
not
everybody
is
managing
this
large
of
a
team.
Her
experience
really
will
give
everyone
some
direction
about
what
we
need
to
look
for
and
where
we're
headed
to,
in
particular,
around
automation
in
in
a
large
enterprise,
and
on
that
I
am
going
to
stop
talking
and
I'm
going
to
hand
it
over.
B
B
Before
that
I
was,
I
was
actually
coding
in
embedded
chips,
digital
signal
processing
and
for
the
past
20
plus
years,
I've
been
with
emirates.
I've
headed
a
lot
of
departments
that
bootstrapped
the
entire
software
engineering
department,
around
1
300
software
engineers
in
2009,
and
then
in
the
recent
past.
I
moved
to
the
hybrid
cloud
department
and
for
the
past
two
two
and
a
half
years
we've
been.
B
So,
in
terms
of
going
straight
to
the
to
the
to
the
topic
right,
I
say
when
we
talk
about
site
reliability,
engineering,
it's
really
I
mean
it's
quite
loaded
and
when
you
ask
for
water
site,
reliability,
engineering
and
for
the
past
one
year,
I
I
mean
I'm
trying
to
get
my
head
around
it
and
there
are
so
many
different
definitions
for
it
right.
It's
really
like
this
blind.
B
You
know
four
or
five
blind
men
trying
to
actually
define
what
what
what
is
it
all
about
and
you
get
you
know
you
put
four
software
engineers,
you
get
five
different
definitions,
and
that
is
exactly
what
it
is.
So
what
I
tried
doing
is
I've
tried
to
negate
what
site
reliability.
Engineering
is
not
about
yeah.
When
I,
when
I
talk
about
it,
is
not
about.
Please
bear
in
mind,
I'm
I'm
I'm
trying
to
say
this
is
not
just
that
right.
So
it
is
not
about
this
specific.
B
B
So
just
to
start
with
to
start
with,
you
know,
I've
heard
people
say
you
know
sarees
or
they're
the
people
who
run
operations.
So
my
view
is
joe
they're
they're,
not
the
people
who
can
be
branded
as
labeled.
As
you
know,
people
who
run
operations
so
there
are
some
people
who
are
just
obsessed
with,
of
course,
infrastructure.
B
As
code
is
something
new
for
a
organization
like
us,
but
and
then
you
know
sres
yeah
you,
you
will
have
to
build
infrastructure
as
code
go
elastic
and
you
know
completely
make
it
work
across
multi-cloud
across
hybrid
cloud
and
that's
it
yeah
yeah.
My
view
is
not
just
that.
I've
heard
the
definitions
that
sres
are
sisops
people
they're
glorified
sysops
people.
So
I've
also
heard
that
you
know
developers
are
not
sres.
Yeah
developers
can
evolve
into
becoming
very
good
sres,
but
developers
are
not
sres.
B
B
They
are
not
the
people,
you
know
who
do
there's
an
issue
with
the
infrastructure,
yeah
application,
the
development
team
and
infrastructure.
It's
the
sres.
They
are
the
support
people
for
infrastructure
network,
or
you
know
they
know
the
operating
system
cloud.
All
of
this
is
true,
but
please,
my
point
is
not
in
isolation
right.
They
do
this
and
they
do
much
more
and
when
I
say
much
more,
my
intent
here
is:
it
is
all
about
keeping
the
the
end
customer
or
the
end
consumer
in
mind.
B
Yeah,
whatever
makes
sense
from
user
experience
to
delivering
operational
excellence,
everything
that
comes
in
between
based
on
the
strength
and
weaknesses
of
your
organization.
The
sre
normally
fills
it,
and
I
will
give
you
an
example
here,
so
we
have
this
classic
case
right.
It's
even
a
vendor
product,
it's
a
product,
that's
being
co-created
with
the
vendor
and
and
that
product
miserably
failed
at
40
percent
of
floor.
Now
it
did
not
meet
the
sli,
it
did
not
meet
the
nfl
requirements
now
here
we
can
just
take
step
back
and
say:
oh
it's
not
our
job.
B
You
know
our
sre
is
after
it
is
delivered.
No,
so
sre
also
gets
into
the
system
architecture,
whatever
changes
and
tweaks
and
tracing.
We
could
do
at
the
code
level.
It
still
did
not
bring
it
up
to
speed
to
water.
Whatever
were
the
sli
requirements,
and
here
the
sre
got
into
the
application
architecture.
B
We
proposed
an
in-memory
data
grid.
We
looked
at,
you
know
how
the
load
balancing
was
done
and
we
we
corrected
it,
and
the
vendor
in
fact,
was
very
happy
to
take
our
inputs.
So
what
I'm
trying
to
say
is
if
you
look
at,
I
mean
I'm
just
talking
about
it
being
so
broad
right,
but
I
need
to
actually
deduce
it
a
little
bit
finer
and
hence
I'm
bringing
up
this
concept,
what
we
call
as
singularity,
so
the
sre
has
to
have
this
singular
focus
on
a
few
things,
a
singular
focus
between
development
and
operations.
B
We
are
all
aware
of
that.
Singular
focus
between
you
know,
application
and
the
ecosystem
and
the
environment
in
which
it
runs
here.
What
I
mean
is
it's
not
about
you
know,
or
this
is
an
application
issue.
I
do
not
know
about
it.
I
look
at
the
deployment
side
of
the
infrastructure
side.
Now,
if
there's
a
reliability
issue,
it
is
the
entire
ecosystem,
so
he
or
she
brings
about
the
singularity
in
the
entire
ecosystem
and
again
the
singularity
between
software
engineering
and
system
engineering.
B
And
what
I
want
to
talk
about
and
share
here
is
more
not
the
hype
right.
We
we
read
a
lot
about
it
and
and
thanks
to
google,
we
have
such
excellent
documentation
around
this
topic
that
I
I
want
to
give
you
the
practical
aspects
of
it
right.
So
when
you
bring
a
software
engineering
mindset
into
the
systems
engineering
into
operations,
there's
a
lot
you
can
do
so
it's
not
just
about
you
know:
automating,
the
the
the
cron
jobs
and
the
batch
jobs.
B
It's
it's
much
beyond
that
right.
It's
looking
at
disaster
recovery,
it's
looking
at!
How
do
you
do
the
full
tech
stack
switch
over
between
data
centers?
It's
looking
at
closed
loop,
remediation
automation
around
it.
It's
it's
looking
at
automation
from
a
very
holistic
point
of
view,
because
we
believe
that
anything
manual
is
even
should
remove
soil
and-
and
this
is
on
a
water
footing-
remove
soil
across
the
the
entire
spectrum
of
a
product
life
cycle
right.
So
this
is
this:
is
we
live
by
this?
B
And-
and
this
is
the
obsession
of
an
exercise,
and
finally,
it
is
about
looking
at
the
touch.
It
is
about
understanding
what
matters
to
the
customer
it
does.
It
is
about
looking
at
the
big
picture
and
it
is
to
bring
joy
to
the
end
consumer.
Whatever
brings
joy
to
the
end
consumer,
I
tell
my
sre
team,
my
team,
you
go
for
it
because
it
is
such
a
big
vast
area
that
you
will
have
to
focus
on
some
people
on
deployment
automation.
Some
people
on
you
know
building
the
reliability
of
these
applications.
B
B
You
look
at
the
the
the
people
skills,
the
the
competencies,
what
people
call
the
soft
competencies
very
important
to
have
collaboration
as
a
very
big
competency,
because
I
have
led
sres,
the
brilliant
tech
folks,
but
but
if
they're
not
seen
to
be
collaborative
enough,
you
know
they're
not
going
to
be
as
successful
as
the
people
who
are
because
you
you
constantly
step
onto
the
shoes
of
other
people,
you
know
you
will
have
to
influence
the
product
or
the
product
manager,
the
product
owners.
You
will
have
to
influence
the
teams.
B
You
have
to
influence
your
infrastructure,
your
your
you
know
the
platform
guys
all
along.
You
are
stepping
on
people's
shoes
and
you
you
have
to
earn
respect
because
you're
putting
a
function
which
is
brand
new
and
collaboration,
is
a
very
key
competency
that
I
look
at
the
ability
to
to
bring
people
along
and
to
to
mentor
them
and
the
other
key
key
competency.
I
look
at
when
I
hire
people
is
their
root,
cause
analysis
problem
solving
skills.
B
These
two
are
very
key
when
you
are
hiring
and
you're
building
and
you're
building
a
seed
team
right,
and
I
always
see
that
they
juggle
between
two
things.
I
mean,
of
course,
juggling
between
you
know.
The
the
speed
of
delivery
of
a
product
and
stability
of
a
product
is
something
that
people
talk
about
right
because
for
forever
the
focus
has
been
to
deliver
more
and
more
and
more
from
a
functionality
point
of
view
from
a
future
point
of
view.
But
in
an
organization
which
has
got
legacy
and
heritage,
there
is
technical
debt
there
are.
B
There
is
a
lot
less
focus
on
things
that
would
bring
about
stability
to
the
product
and
increase
the
reliability
of
the
product,
and
things
like
you
know
what
will
bring
you
know:
graceful
degradation
and
disaster
recovery
and
people
don't
care
about
these
things,
because
these
are
like
insurance.
This
is
things
that
you
do
not
see
as
adding
value
straight
forward.
So
there
is
this
dichotomy
between
stability
and
speed
that
the
site
reliability
engineer
needs
to
always
work
upon,
and
I
see
that
they
intelligently
trade
off
options
right
I'll,
give
you
another
example.
B
So
we
have
in
our
data
and
analytics
area.
There
was
this
massive
amount
of
of
our
htfs
data
that
had
to
move
to
the
cloud
and
from
our
enterprise
service
bus.
We
were
pushing
this
data
onto
the
cloud
and,
of
course,
from
a
security
point
of
view
across
the
tls.
We
had
to
encrypt
it
right,
but
it
was
failing
again
miserably
the
sli
on
the
on
the
producer
side
on
the
consumer
side,
and
then
here
the
sra
had
to
get
into
the
detail
of
even
data
classification.
B
So
we
we
classified
data
as
tier
one
and
tier
two
tier
one
was
kept
on
prem
within
the
the
safe
zone,
so
it
met
the
security
requirements
and
met
the
performance
requirements
and
it
meant
the
cost
goals
right.
So
I'm
just
trying
to
re-trade,
even
when
we
have
our
firm
focus
on
what
we
call
are
the
or
the
devops
you
know
report
metrics
around
time
to
market
and-
and
you
know,
reliability
and
the
quality
and
things
like
that.
B
It
is
all
about
the
intelligent
trade-off.
It
is
about
bringing
cost-effectiveness
and
being
pragmatic
about
what
works.
Okay.
So
we
look
at
it
again.
It's
too
broad,
so
bringing
three
mantras
here:
automation.
So
when
you're,
looking
at
your
area
where
you're
working
at
look
at
what
makes
sense
and
what
adds
biggest
bang
for
the
bump
right,
so
automation
in
case
you
know
you,
you
do
not
have
your
ci
cd
flows.
If
people
their
branching
is
not
proper,
we
we
have
situations
like
that,
and
tracy
spoke
about.
B
You
know
moving
from
monoliths
to
micro
services,
we
live
and
breathe
on
that.
So
how
do?
How
do
we
convert
our
middle
middleware
into
microservices
and
and
every
time
there
is
a
an
enhancement
for
a
piece
of
work
that
comes
into
the
to
the
to
the
monolith
product?
The
sre
is
up
front
there.
You
know
trying
to
influence
the
tpm
to
say
yeah.
B
This
is
the
best
time
for
us
to
spin
it
off
to
to
strangle
it
out
as
a
micro
service
and
to
actually
move
it
from
this
old
platform
to
the
microservice
platform
right
influencing
people
to
automate
test
packs,
and
I
mean
you
may
think
these
are
very
basic
stuff
when
you
are
actually
building
a
new
green
field
application.
But
when
you
are
talking
about
applications
that
are
serving
the
purpose,
they
are
not
broken
right.
B
So
when
we
talk
about
automation,
it's
all
about
the
cool
stuff,
we're
talking
about
ci
cd
flows,
the
the
you
know,
the
continuous
release,
automation,
deployment
and
then
introducing
feature
flags
doing
av
kind
of
deployments
automating
it
so
that
we
have
cannery
releases,
then
infrastructure
as
code.
So
we
we've
we've
had
very
good
success
here
when
we
went
to
a
multi-crowd
cloud
kind
of
environment
and
we
looked
at
our
sre
team.
B
You
know
they
looked
at
the
capacity,
the
resource
utilization
of
it
and
we
could
actually
do
a
lot
of
good
stuff
there
by
bringing
workloads
together
and
and
bringing
down
infrastructure,
even
vms
yeah.
I'm
not
talking
about
auto
scaling
container
right.
I
mean
that's
less
of
a
problem,
but
the
infrastructure
support
and
building
it
so
that
it
can
work
across
multiple
clouds.
B
We
spoke
about
automation
on
the
operations
side,
so
our
switch
over
between
data
centers
happens
automatically
for
our
core
platinum
applications
and
and
the
automation
that
went
behind
that.
So
I'm
also
talking
about
things
like
you
know:
work
through
automation,
robotic,
process
automation.
So
these
things
give
you
a
lot
of
advantage
and
you
may
not
you.
May
you
may
think
that
this
is
not
a
a
proper
sre
philosophy
right,
but
but
if
you
look
at
it
from
a
from
a
lens
of
automation
for
business,
they
don't
care
right.
B
What
matters
for
them
is
what
really
has
made
their
life
easier
and
robotic
process.
Automation
is
an
excellent
tool
that
actually
makes
their
life
extremely
easier
yeah.
So
you
look
at
it
from
from
the
entire
nine
yards.
If
there
is
anything
which
is
repetitively
done
and
that
can
be
automated,
then
rpa
just
becomes
one
of
the
tools
for
you.
I
will
talk
about
the
next
mantra
right
observability.
Now,
when
you
have
monoliths,
and
you
have
applications
that
have
not
been
built
to
emit
these
signals
outside
so
yeah,
you
do
have
monitoring.
B
You
know
multiple
layers
to
look
at
observability,
rather
than
actually
waiting
for
an
incident
or
waiting
for
for
business
feedback
to
come
through
and
and,
of
course,
the
reliability.
I
don't
have
to
focus.
I
think
people
really
understand
site
reliability,
engineering
as
the
people
who
will
work
on
improving
the
the
reliability
aspect,
not
just
the
availability
aspect,
which
means
it
meets
the
slos
that
we
have
agreed
with
with
the
bigger
business
fault,
tolerance
and
then
scalability
and
capacity
planning,
and
all
of
this
right
going
to
the
going
looking
at
chaos,
engineering,
instrumenting
chaos,
engineering.
B
Who
will
create
the
automation
so
that
these
systems
are
self-enabled
there?
They,
you
know
they
they
they
self-heal
and
they
they
run
as
per
what
we
commit
to
the
to
the
business.
So
they
are
the
people
who
create
the
ecosystem
so
that
the
systems
run
as
per
their
sls.
We
spoke
about.
You
know
how
crucial
it
is
to
build
these
relationships
and
to
build
these
mentorships
so
that
in
areas
where
we
are
actually
doing
this
transformation
right,
we
are
not
getting
stuck.
B
We
are
seen
with
respect
and
we
are
seeing
as
people
who
will
add
value
and
we
are
seen
as
people
as
experts
who
will
who
will
come
and
make
things
easier.
I'm
not
talking
about
the
business
I'm
talking
about
our
own
functional
people,
the
product
people
are
developers,
and
you
know
that
the
teams
that
we
are
talking
about
to
support
people
and,
of
course,
a
complete
big
focus
on
testing
and
release
automation.
However,
how
much
ever
small
I
underplayed.
B
When
you
talk
about
tech
debt-
and
you
talk
about
cloud
adoption,
you
will
see
these
are
interleaved
yeah.
I
have
a
slide
on
that.
I
will
come
to
we're
talking
about
application
modernization,
and
you
will
see
that
these
are
actually
interlinked
now
a
platform
having
a
very
good
devsec
test
platform,
a
platform
that
can
give
you
services
that
can
be
consumed
by
the
developers
so
that
you
know
the
sr
the
the
life
of
the
sre
becomes
more
towards
helping
the
developers
adopt
it.
B
Having
a
very
strong
devops
platform
team
is
the
key
having
your
landing
zones
that
are,
you
know
across
multiple
clouds
is
the
key
right,
but
when
your
platform
is
also
coming
up
and
your
sre
function
is
also
coming
up,
these
are
coming
up
in
parallel.
Then
you
should,
you
should
remember,
to
complement
each
other
and
if
you're,
building
anything
that
is
new
to
contribute
it
back
to
the
platform,
so
that
the
platform
becomes
more
and
more
stronger
right.
B
So
have
always
this
platform-centric
view
and
of
course,
gartner
talks
about
you
know
different
ways
of
how
do
you
implement
the
platform
operations
itself?
And
you
will
see
that
you
know.
Finally,
the
decentralized
way
is
probably
the
most
efficient
way,
especially
if
you
have
multiple
application
text
tags-
and
you
know
you
have
you'll-
have
to
temporarize
your
jenkins
you'll
have
to
do
things
that
will
that
will
give
you.
Finally,
those
those
results
right,
the
results
that
that
that
will
enable
the
speed
of
delivery
of
your
your
applications.
B
Here
I
mean
if
we've
used,
we've
not
reinvented
the
wheel,
we've
actually
used
what
what
is
coming
out
of
the
devops
report,
but
it
gives
us
fairly
a
good
indication
of
the
different
areas
of
the
different
products
and
in
what
level
of
maturity
are
these
products
in?
So
we
we
look
at
the
spider
chart
from
our
dev
ops
point
of
view.
We
look
at
it
from
a
site,
reliability,
engineering,
point
of
view
from
the
tenants
around
site,
reliability
engineering
are
they?
Are
there
triage
channels,
for
example,
are
they
following?
B
For
example,
you
know
blameless
postmortems,
so
these
are
the
so
our
our
spider
chart
is
is
a
mix
of
both
automation
and
site,
reliability,
engineering.
So
when
it
is
a
new
product,
it's
it's
easy.
It's
actually
very
easy,
because
the
srs
get
to
work
on
everything
which
is
you
know,
cutting
edge
and
bleeding
edge.
B
They
go
for
a
model.
I've
just
put
a
very
basic
model
here
right,
but
it's
more
of
we
also
interleave
the
ai
and
ml
part
on
the
data
itself,
so
the
the
data
lakes
are
built
so
that
you
know
we,
the
genomes
are
exposed
that
can
be
consumed
as
services
by
multiple
applications
and,
of
course,
you
know
we're
looking
at
a
micro
service
based
architecture
here
using
service
mesh
things
like
ishta
for
doing
the
service
brokering
and
they've
also
looked
at
a
lot
of
advantages
here
right.
B
The
advantage
is
being
when
you
have
very
effective
service
brokering.
To
the
extent
that
you
know
your
environment
itself
is
is
much
better
because
you
can
have
three
services
say
version
one
two,
three
and
you
can
actually
have
configure
the
the
service
brokering
around,
which
one
is
actually
a
development
service,
for
example.
So
your
version
3,
is
still
you
know,
a
develop
development
service,
whereas
your
version
one
is
in
fraud,
is
a
broad
service.
So
actually
you
you
decompose
your
environment
to
a
service
level
itself.
So
you
do
not.
B
You
talk
about
savings
coming
from
a
dev
test,
acceptance
and
pre-prod
and
multiple
multiple
environments.
When
you
do
a
very
effective
service
brokering,
you
you
do
not
require
so
many
environments
right.
So
the
the
more
focus
you
put
on
how
you
manage
your
apis,
the
better
you.
You
can
actually
build
your
your
from
your
in
your
environment
strategies
and
then
things
like
you
know.
Cannery
release
and
a
b
testing
and-
and
I
feel
people
who
are
engaged
in
this
area
are
normally
very
very
quite
motivated.
B
B
I
have
a
slide
on
that,
so
we
so
for
the
people
who
are
working
in
this
this
ecosystem,
it's
a
bit
more
easier
for
people
who
are
working
in
you
know
in
the
monolith
area
or
people
who
are
working
towards
moving
the
monoliths
into
microservices,
it's
a
bit
more
difficult
because
for
them
the
effectiveness
around.
What
is
measured,
unfortunately,
is
slightly
different,
and
it
is
because
you
know
these
applications
are
living
for
the
past
15
20
years.
B
So
when
you
look
at
some
of
the
areas
where
the
there
is
no,
you
know
when
you
look
at
the
the
gartner's
approach
itself,
like
I'm
talking
about
like
systems
of
recorder
systems,
of
release
differentiation,
not
of
innovation.
Here
we
we
classify
and
we
modernize
the
applications
based
on
the
time
model.
So
I'm
sure
you
know,
I
don't
want
to
get
into
the
details
here,
but
we
look
at
which
are
the
applications
that
we
have
to
invest
and
innovate
and
for
those
applications.
B
There
is
a
very
good
strategy
how
these
monoliths
move
into
microservices.
We
start
from
how
their
gate
reports
are
structured
right
and
then
that
is
the
base.
And
then
we
look
at
the
main
driven
design.
How
do
we
really
construct
these
services
from
from
a
monolith
for
the
others?
It
is
more
of
you
know.
How
do
you
really
maintain
them
and
there
are
different
ways?
B
C
B
Of
the
product
itself,
it's
it's
quite
interesting,
but
from
from
a
technology
point
of
view,
are
they
working
on
the
latest
school
technologies?
You
know,
so
it
is
different.
So
again,
when
you
are
building
your
team
and
then
you're
when
you're,
placing
your
your
sres
in
different
domains
and
in
different
application
areas,
you'll
have
to
look
at
their
their
their
appetite
and
you'll
have
to
and
their
competencies,
and
you
you
actually
place
them
right.
B
Like
I
mentioned
all
of
them,
most
of
them
spend
a
lot
of
their
time
into
looking
at
building
ci
cd
flows,
various
aspects
of
the
ci
cd
flows,
but
still
a
lot
of
effort
goes
in
here.
Building
in
you
know
the
the
quality
gates
so
that
we
can
actually
have
a
very
automated
process.
At
least
till
you
know
the
the
the
the
deployment
environment
coming
from
a
from
a
from
an
organization
who
are
probably
you
know
for
people
for
some
of
you
all.
You
may
think
it
is.
B
It
goes
and
drops
into
prod
right
and
they
are
completely
built
in
a
manner
so
that
you
know
there
are
things
like
auto
canary
analysis.
There
is
what
I
mean.
There
are
alerts
that
that
that
talk
about
the
differences
you
know
before
the
deployment
and
post
deployment
and
it
alerts
you
to
auto
roll
back,
and
things
like
that.
B
So
so
we
have,
I
mean,
like
we've,
had
the
opportunity
to
look
at
a
lot
of
different
different
scenarios,
and
my
my
take
here
is:
it
is
again
horses
for
courses,
so
the
sres
have
a
real
big
toolkit
of
whatever
they
can
use
from
the
toolkit
and
use
it
to
the
extent
that
it
makes
the
end
user
life
the
most
comfortable
and
along
the
way,
they'll
have
to
collaborate,
influence
and
make
people
understand.
Take
them
along
to
to
make
things
happen
right.
B
B
How
do
you
ingest
data?
How
do
you
actually
process
data
and
then
how
do
you
send
the
data
out
and
then
rs
also
revolve
around
these
things
right?
So
when
it
comes
to
white
box
monitoring
the
the
way
you
build
events
on
the
logs
so
that
you
do
not
have
you,
you
do
have
the
right
kind
of
alerts
right.
B
So
the
first
thing
is:
you
know
the
reliability
level
when
people
say
you're,
100
reliability,
then
you're
not
talking
about
site
reliability.
Engineering
at
all,
so
my
point
is
this:
is
nothing
like
that
once
they
start
talking
about
less
than
100
target
yeah,
then
you're
talking
our
language.
We
can
start
working
on
it
right.
So,
firstly,
our
srs
have
to
understand
what
the
reliability
levels
are
and
what
does
it
mean
that
if
they
are
deviating,
let's
say
one
person
from
and
from
a
committed
reliability?
B
What
exactly
does
it
mean
right
from
a
from
a
planned
outage
point
of
view,
and
then
we
look
at
the
sli
menu
from
from
three
aspects
again.
This
is
completely
out
of
google
yeah
they're,
not
reinventing
anything,
but
of
course
we
look
at
it
from
a
request
response
angle.
So
when
you
talk
about
availability
or
latency,
so
this
is
a
ratio
right
it
is.
It
is
about
the
good
events
over
all
the
events
that
you
think
is
worthwhile
right,
so
be
it
availability
or
latency
or
quality
from
a
request
response.
B
But
if
you
were
from
a
data
processing
point
of
view,
things
like
you
know
the
coverage
and
correctness
and
throughput
so
the
again
when
an
sre
starts
a
new
area.
These
are
the
concepts
that
he
will
have
to
sell
to
the
product
manager
or
to
the
product
order,
and
then
look
at
look
at
the
agreement
that
that
we
get
from
an
slo
point
of
view
and
then
boil
it
down
to
an
sli
right.
B
So
I
I
hope
that
makes
sense,
and
this
is
again
something
that
our
sras
do
keep
looking
at
now,
just
a
few
metrics,
I
think
which
will
be
useful
for
you
all.
I'm
sure
you
people
are
using
better
metrics
or
probably
these
right.
So
these
metrics
really
help
you
to
look
at.
Are
we
moving
in
the
right
direction?
B
Has
the
deployment
frequency
actually
improved
if
it
is
a
if
it's
a
business
unit
where
they
have
asked
us
to
look
at
the
reliability
aspects?
Have
the
number
of
incident
counts
come
down?
If
it's
something
related
to
technical
debt?
Has
the
technical
debt
really
come
down?
So
these
are
the
things
that
we
that
we
look
at
from
from
a
security
point
of
view
again,
so
there
are
a
few
aspects
that
we
look
at.
B
So,
finally,
again,
I'm
retreating,
it's
all
about
delivering
business
value
to
the
customers
and
and
it's
about
bringing
joy
to
the
face
of
the
end
end
consumer
yeah,
so
a
few
values.
So
here
I
think
one
thing
is
for
an
sre
is
to
to
be
completely
honest,
so
I
will
give
you
my
own
example
right
when
I
was
a
coder.
B
We
didn't
have
tier
reviews,
but
but
the
change
that
that
was
done
with
a
very,
very
good
intent
for
me
right
that
was
related
to
some
point
of
sale
change
and
it
was
on
an
application
that
was
sent
to
you
know
we
have
around
400
outstations
it
in
those
days.
I'm
talking
about
probably
15
years
back
right.
We
would
even
send
hard
copies
and
this
supplication
change,
which
was
done.
B
B
And
so
one
aspect
is
when,
when
we
look
at
it
from
a
very
honest
point
of
view,
there
are
a
few
things
that
come
out.
One
is,
of
course,
that
particular
manager
at
that
point
of
time.
He
he
never
told
I
mean
we'll-
have
to
be
based
on
the
sensitivity
of
your
team
right
you'll
have
to
take
it
up
with
the
team
right.
B
The
other
thing
is,
you
may
come
from
a
developer
environment.
You
may
come
from
the
sysops
side.
You
always
have
an
opinion.
Most
of
us
are
biased
right,
knowing
that
we
are
biased
and
being
self-aware.
That
we
are
biased
makes
a
big
difference,
because
when
we
know
that
we
are
biased,
then
we
are
open
to
listening
to
two
things
right.
So
I
think
that
is
a
very
important
value
that
we
have
to
inculcate
in
the
team
to
to
respect
each
other's
points
of
view.
C
B
A
B
We
have
to
there's
this
continuous
unlearning
and
relearning
and
reskilling
and
upskilling
that
happens.
So
then
you
build
an
sre
team
from
from
developers
right.
The
only
I
mean,
apart
from
the
the
core
competencies
I
spoke
about,
also
look
at.
How
good
are
they
and
how
much
of
a
aptitude
they
have
to
be
towards
learning
towards
continuously
learning,
and
I
keep
telling
my
team
do
not
go
to
sleep
without
learning
something
new
for
that
day,
and
I
follow
that
yeah.
B
I
religiously
follow
that
and
I've
moved
so
many
departments
within
within
my
organization
and
every
time
I
move,
I
have
learned
things
on
the
domain
side
on
the
technology
side,
so
I
think,
learn,
learn
your
other
side.
Learn
continuously
and
building
relationships
is
at
most
paramount
important,
especially
when,
when
you're
introducing
a
very
new
functionality,
just
to
quote
we
use.
We
have
this.
What
we
call
the
release
trains
and
we
used
to
have
the
wheels
yeah
so
wheel.
One
wheel
is
an
architect
and
another
wheel
is
a
principal
engineer.
B
I
mean
there's
a
site.
Reliability
engineering
function
was
introduced
right.
There
was
a
lot
of
ask
from
my
team
to
say
we
should
become
one
of
the
wheels
right
off
of
the
train.
There
are
four
wheels
in
the
four-wheel
cetera
and
I
used
to
tell
them
no,
you
should
be
the
engine
of
the
train,
so
you
should
you
should
earn
the
respect
and
you
start
a
top-down
thing.
B
You
know
I
will
go
and
put
you
as
another
wheel
of
the
train
when
you,
when
you
earn
the
respect,
and
I
can
see
that
happening-
I
can
see
that
they
have
earned
the
respect
that
they
are
actually
seen
as
adding
a
lot
of
value
on
the
application
side.
On
the
on
the
automation
side,
on
on
building
the
right
kind
of
you
know
the
monitoring
and
the
alerts
and
and
building
the
best,
the
resiliency
on
the
operations
etc.
B
B
B
So
I
I
I
just
think
that-
and
this
is
like
it
catches
fire
when
your
business
user,
your
business
partner
talks
about
you
know,
oh
my
time
to
market,
has
actually
improved
by
10
times.
Then
it
invokes
interest
in
the
other
business
partner.
Oh,
is
that
so
my
infrastructure,
ops,
cost
has
gone
down
by
by
you
know
whatever
1
million
or
2
million
whatever.
Then
it
invokes
interest.
So
this
is
how
it
spreads,
and
this
is
how
the
transformation
journey
becomes
much
much
better.
B
So
so
that
is
what
I
had
to
share
I'm
open
for
questions,
but
I
I
had
put
this
picture
in
one
of
my
articles
when
I
wrote
in
linkedin
right
and
afterwards,
I
found
that
a
lot
of
our
vendors
and
partners
use
this
picture
and
they
tell
me
I
have.
I
have
actually
taken
this
picture
and
I
I
mean
the
intent
of
putting
this
picture
is
if
you
are
trying
to
introduce
a
site,
reliability
engineering
function
in
a
in
a
well-oiled,
properly
running
organization.
B
So
you
know
there
are
not
major
issues,
reliability,
issues
which
they
perceive
as
issues
or
they
think
that
you
know
it
is
good.
The
organization
is
doing
good
and
they
do
not
understand
what
is
taking
it
up
to
the
next
level
right
and
when
you
have
to
go
through
this
journey.
So
I'm
talking
about
when
you
have
a
team
size
of
30
and
if
because
of
automation
and
because
of
the
efficiencies,
you
can
actually
say,
redeploy
say
five
of
them
to
some
some
other
team.
B
A
A
Looking
at
damian
romero,
you
had
raised
your
hand
and
I've
unmuted
you
if
you'd
like
to
ask
a
question,
or
you
can
always
post
it
in
the
chat
and
in
fact
we
do
have
a
a
question.
The
question
is
about
how
to
calculate
or
decide
the
error,
budget
and
error
percentage.
Do
you
have?
This
is
from
a
provide?
Do
you
have
any
insights
on
that.
B
B
B
It
is
more
about
you
know,
giving
them
the
transparency
of
how
much
of
a
technical
debt
you
have
or
how
much
of
a
reliability
you
have
in
terms
of
the
probably
the
number
of
incidents
and
that
automatically
gives
them
the
the
providing
them.
The
visibility
itself
is
actually
enough
for
you
to
to
make
sure
that
due
consideration
is
given
to
to
your
reliability,
features
vis-a-vis
your
functional
features.
So
so
I
I.
C
Yeah,
thank
you
hi.
I
joined
a
bit
late,
so
I'm
not
sure
if
this
was
covered
you
know,
but
I
would
like
to
understand
what
are
the
different?
You
know
the
tools
or
something
that
you
use
to
track
their
cellos.
You
know,
because
I
understand
for
a
major
in
a
complex
monolith
application
there
may
be
so
many
downstream
applications
that
may
you
know
feed
into
this
slo
right
and
considering
the
practice
of
having
at
least
a
minimum
of
three
slice
to
be.
C
You
know
tracked
for
each
of
the
critical
user
journeys
I'm
just
trying
to
understand
how
to
it
ends
up
in
a
massive
spreadsheet
or
something,
and
I'm
just
embarking
on
this
journey
in
our
company.
So
you
know
it'll
be
very
helpful
to
know
how
did
you,
you
know,
start
this,
and
how
do
you
track
your
slows
at
the
higher
level.
B
B
When
you
build
your
final
sla,
you
know
that
it
is
built
up
of
these
slos,
and
so
it
is
more
like,
like
you
rightly
mentioned,
whenever
an
incident
happens
it's
more
of
looking
at,
which
is
the
slo
that
has
got
breached,
which
means
that
you
need
to
have
a
measurement
of
all
the
slis,
the
downstream
the
downstream
slice
and
work
towards
you
know.
Collectively.
How
do
you
address
the
your
overall
sla
right
so
because
it
may
mean
that
I
mean
I
have
seen
this
for
the
application
where
there
is,
there
is
a
breach.
B
Probably
you
know
their
sl.
Their
sla
is
quite
good
and
it
it
has
not
actually
impacted
them,
but
it
has
actually
impacted
you,
so
I
think
the
first
thing
is
to
identify
which
sli
has
impacted
your
sno,
your
sla
and
then
to
progressively
work
so
that
you
know
you
can
you
can
address
it
in
a
very,
very
joint
and
joint
or
a
collaborative
manner.
That
is,
that
is
how
we
we
actually
do
it
and
most
of
the
time
there
are
issues
around
it
most
of
the
time.
For
example,
you
know
our.
B
It
comes
with
mostly
related
to
you
know,
data
services
or
loyalty
services,
and
there
is
a
breach.
It
happens
even
with
when
you
measure
your
nfrs,
so
it
is
a
it
is
a
journey.
I
think
the
first
point
is
that
you
have
to
start
measuring
them
and
then
you
you
work
towards
you
know.
How
do
you
make
it
better
from
all
from
a
holistic
point
of
view.
A
Yes,
thank
you.
Thank
you
for
that
presentation.
There
was
a
ton
of
information.
This
will
be
posted.
I
will
send
everybody
a
link
to
it.
Shivagami
you
gave
us
some
amazing
information.
So
thank
you
so
very
much.
I
think
that
you
gave
us
a
lot
to
think
about.
As
we
run
down
this
pathway
of
building
our
sre
teams.
A
I
just
want
to
make
a
shameless
promotion
for
our
next
meetup,
we'll
be
hearing
from
murray
rozinski.
He
works
at
a
company
called
oc.
Tanner
he's
going
to
talk
about
how
what
their
experience
was
like
moving
from
monolithic
to
a
container-based,
kubernetes
environment,
so
that
will
be
on
august,
the
11th
11
o'clock
mountain
time.
So
I
hope
that
you
all
can
join
us
and
that
we
are
at
the
top
of
the
hour,
and
I
try
to
keep
these
exactly
at
one
hour,
so
I'm
going
to
end
it
at
this
point
again.
Thank
you.
Everybody.