►
From YouTube: Site Reliability Engineering Adoptions: Setting up the Fundamentals - Spyridon Maniotis
Description
Site Reliability Engineering Adoptions: Setting up the Fundamentals - Spyridon Maniotis, Danske Bank Group
The session aims to present patterns and anti-patterns when adopting SRE practices in corporations; supported by real case studies/examples from the financial services industry.
Core to an SRE adoption elements such as; operating model, tenets, process engineering, skillset, technological capabilities/tactics, reconciliation with DevOps and ITSM, as well mechanisms such as "error budget" & "engagement models" will be outlined. All in relation to an "adoption at relevance".
Concluding a set of lessons learned will be presented, along with key considerations to be taken when adopting, sustaining, and scaling.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Hello,
everyone
greetings
from
denmark.
Thank
you
very
much
for
attending.
My
name
is
peridone
and
I'm
heading
the
dev
second
center
of
excellence
at
danske
bank.
I'm
here
today
to
talk
to
you
about
set
reliability,
engineering
adoptions
and
give
you
some
tips
on.
What
I
consider
are
the
fundamentals
in
your
essay
journey,
so
actually
getting
started
with
it.
A
I
will
conclude
the
session
with
some
lessons
learned
that
I
have
learned
myself
of
my
experience
with
the
concept
make
sure
that
I'm
going
to
leave
enough
time
for
your
questions
at
the
end,
so
getting
directly
into
into
it.
Its
origin
is
updated
in
2003
and
comes
from
google
and
the
most
mainstream
definition
is
the
one
that
comes
from
ben
traynor.
A
Now
there
are
many
different
definitions
of
srv
and
people
can
shape
it.
The
way
they
want
and
define
its
essence,
but
in
in
my
opinion,
it
is
prescriptive
ways
on
measuring
and
achieving
in
reliability
through
engineering
and
operations
work
and
basically,
if
you
take
the
acronym
and
you
rate
it
backwards,
you
get
engineering
the
reliability
of
the
service.
So
basically
is
several
actions.
Frameworks
patterns,
ways
methods
you
use
in
order
to
make
sure
that
you
have
reliable
services.
A
Now,
looking
a
little
bit
into
the
the
big
debate
on
what's
the
relationship
between
sre
and
devops,
this
is
actually
a
statement
coming
from
google
that
classes
every
implements
devops,
and
it's
actually
something
that
I
personally
believe
on.
So
basically,
srv
should
be
seen
as
a
discipline
in
order
to
to
enable
a
broader
devops
adoption
in
your
organization
now
going
into
the
frameworks.
There
is
this
term
in
in
in
google,
sorry
that
is
called
tenant
and
basically
the
definition
is
that
it's
a
basic
and
common
set
of
responsibilities
across
necessary
teams.
A
So
basically,
what
are
the
tasks
and
responsibilities
of
the
several
sra
teams
in
the
organization
that
are
common?
Actually,
a
very
second
term
is
actually
what
is
called
the
sre
balance.
So,
basically,
the
idea
is
that
your
site,
reliability,
engineering
team,
is
going
to
be
spending
50
of
their
time
doing
operations
work
while
the
rest
of
50
will
go
on
improvements
here
on
this
diagram,
I
have
made
an
attempt
to
define
or
list
the
tenants,
the
way
that
I
have
used
them.
A
If
it
doesn't
succeed
on
that,
then
you
get
into
the
level
one
which
is
your
sres
taking
action.
There
are
a
lot
of
stuff
around
observability
and
basically
that
goes
on
monitoring
and
logging
in
your
application.
Infrastructure
stack
post
mortems
in
case
that
you
do
have
incidents
that
you
need
to
do
some
root,
cause
analysis
and
appoint
preventives
in
in
order
to
ensure
that
they
won't
happen
again.
Release
management
deployments
work
as
well
as
service
continuity
to
make
sure
that
in
case,
you
have
a
disastrous
event.
A
If
you
don't
lose
your
service
and
we
continue
having
operations
now
on
smoothening
these
operations
and
shift
towards
what
I
call
operations,
engineering,
there's
the
latter.
Fifty
percent
of
improvements
that
the
necessary
team
will
work
on
and
that's
from
alien,
eliminating,
toil
and
toil
in
google
terms
means
manual
repeated
and
automatable
tasks,
so
basically
make
sure
that
you
can
have
as
autonomous
operations
and
hands-off
as
possible
several
actions
in
order
to
improve
the
reliability
of
a
service,
access
on
measuring
and
reducing
technical
debt.
A
So
looking
into
your
historical
data
or
looking
into
the
intended
growth
and
and
predict
what
the
the
how
your
applications
would
scale
and
take
preventive
actions
and
then
a
lot
of
stuff
around
release
engineering
and
basically
this
is
looking
into-
let's
put
it
so
simplified
release
management
process
front
to
back
and
the
engineering
steps
away
that
you
have
implemented
in
your
csd
pipeline.
Your
writing
service
management
tool,
your
infrastructure
platforms
and
basically
make
sure
that
you
can
balance
release
velocity
with
reliability.
A
This
percentage,
of
course,
is
not
prescriptive.
What
google
wants
to
to
say-
and
the
concept
wants
to
say,
is
that
you
should
not
be
spending
more
than
fifty
percent
of
operations
and
it
it
depends
a
lot
with.
Where
is
your
life
cycle
of
your
service
at
the
current
moment?
Is
it
still
early
deployments
you're
in
canada
releases
phase,
or
do
you
have
a
mature
product?
A
Now
why
this
is
a
very
important
framework
and
fundamental
of
sre
is
defining
the
balance
and
defining
the
tenants
is
actually
very
important
because
in
essence,
you
explain
what
you
want
to
make
out
of
it.
So
basically,
what
will
be
the
responsibility
of
the
srv
team
and
what
is
going
to
be
operating
modern,
it's
actually
derived
by
the
objective
you
want
to
achieve
with
implementing
the
concept
now.
The
second
fundamental
and
very
important
is
topologies,
and
there
are
several
combinations
on
how
you
can
organize
your
research
teams.
A
I've
brought
only
two
here,
but
you
can
sense
and
probably
have
experienced
way
more
than
that,
and
one
very
important
thing
is
that
you
need
to
reconcile
this
topology
with
your
broader
devops
operating
model
ecosystem.
So
you
need
to
embed
it
into
the
current
devops
model
you
have,
or
if
you
are
in
the
face
of
involving
it,
you
need
to
involve
the
sra
topology
together
with
it.
So
basically
the
first
one
I
call
it
embedded
slash
organic
and
this
is
full
ownership.
A
This
is
important
because
it
can
give
you
a
higher
return
of
investment,
the
more
the
scale,
the
bigger
the
rate
of
investment.
It
can
help
you
to
harmonize
and
orchestrate
within
your
ecosystem,
but
also
you
can
make
sure
that
you
can
have
a
lot
of
good
mechanisms
of
error
handling.
So
basically
it
is
the
the
the
one
rotten
apple
in
the
bucket
of
apples
scenario
that
if
you
have
one
wrote
in
apple,
it's
just
a
matter
of
time
for
the
rest
to
get
rotten
and
the
same
goes
on
the
reliability
concept.
A
If
you
just
focus
on
reliability
of
a
single
application,
if
you
don't
look
into
the
referrals,
it's
just
the
amount
of
time
that
we're
gonna
break
you.
So
basically
looking
at
ecosystems,
tactically
placing
the
people
and
get
them
to
harmonize
as
much
as
possible
across
tenants
and
and
the
methodology
of
doing
things.
A
And
then
it's
very
important
that
when
you
have
your
core
infrastructure
that
you
have
the
most
technological
utilities
consume
and
the
biggest
volume
of
clients.
We
also
do
tactically
embed
site
reliability,
engineering
and
two
examples
that
I
can
bring
here
that
I've
seen
in
my
experience,
paying
a
lot
of
is,
for
instance,
your
container
platform
or
your
cicd
pipeline,
or
your
enterprise
message
bus.
So,
basically,
making
sure
that
your
core
foundation
is
also
aligned
with
the
reliability
practices
of
the
application
layer.
A
Now
the
second
model,
it
is
what
I
call
task
force
and
basically,
this
is
com,
stabilized
transfer,
knowledge
and
move
on,
and
this
is
on
applications
that
don't
really
have
a
big
dependency.
They
have
an
indirect
one
without
direct
one
and
for
the
ones
in
the
fsi
industry.
You
can
see
core
payments
and
equity
trading,
they
do
have
a
dependency,
but
it's
not
a
direct
connection,
and
then
you
have
a
center
of
excellence,
so
call
it
as
you
wish.
Basically,
it's
going
to
be
sri
squads.
A
That
is
stepping
into
a
situation
that
you
do
have
reliability
and
efficiency
problems.
They
do
support
on
resolving
those,
do
knowledge
transfer
in
their
respective
teams
and
they
basically
go
back
into
the
coe
and
either
work
into
central
sre,
incubation
programs,
for
example,
or
move
to
the
next
engagement
to
to
call
it
that
way.
A
A
There
are
several
frameworks
that
are
going
to
be
very
important
for
you
in
your
journey.
I've
brought
only
four
of
them
here.
The
one
is
observability,
so
basically
it
can
help
you,
with
visibility
of
your
health
status.
Get
alerted
well
in
advance,
become
very
proactive,
use
the
data
to
do
current
engineering
and
stress
test
your
system
in
close
to
real
circumstances,
but
also
collect
data
to
capacity
planning.
A
Then
the
second
very
important
framework
is
to
achieve
autonomous
society,
service
management,
and
basically
this
is
getting
the
technologies
that
consist
of
variety
service
management,
hooked
up
and
interoperated
with
your
release,
engineering
and
actually
make
it
as
event-driven
and
autonomous
as
possible.
So,
basically,
people
just
it's.
This
is
this
term,
I'm
using
people
just
drinking
coffee
and
looking
to
screens,
while
the
tools
using
apis
and
events
take
care
of
the
whole
world,
for
instance.
A
A
The
fourth
very
important
mechanism,
which
I've
seen
extremely
extremely
valuable
in
my
experience
with
the
concept,
is
the
production
readiness
review.
So
this
is
basically
a
checklist
that
defines
function
on
a
non-functional,
as
well
as
organizational
and
governance
items
that
you
need
to
be
compliant
with
in
order
to
make
sure
that
the
service
you
move
into
production,
it
fulfills
certain
criteria
from
a
reliability
perspective,
and
this
is
actually
the
gatekeeping
mechanism
of
srv
in
order
to
take
over
a
service
in
production
or
take
over
new
releases
in
production
that
can
ensure
a
coalition
understanding.
A
So
again,
this
is
not
exhaustive.
I
have
picked
up
the
four
frameworks
that
I
see
more
vital
and,
as
I
mentioned,
it's
very
important
that
you
make
them
prescriptive,
so
people
buy
in
and
they
see
the
most
mandatory
and
that
you're
consistent
on
using
them
across
your
science
relatability
engineering
adoption,
because
they're
going
to
also
help
you
to
replicate
your
success
and
actually
give
pre-made
recipes
to
people
that
can
get
fastly
on
boarded
into
the
concept.
A
Now
next
one-
and
actually
this
is
one
of
the
the
biggest
problems
that
people
see
with
the
service
of
srv-
is
baptized
to
be
google's
itsa
microservice
management
flavor.
And
if
we
look
into
the
industry
around
dietary
service
management,
the
dominant
framework
is
item.
The
it
infrastructure,
library
and
most
organizations
are
starting
adopting
this
one
before
devops
and
before
srb,
and
then
becomes
a
religious
discussion
that
do
they
come
into
conflict.
How
can
they
play
ball
with
each
other?
A
The
process,
design,
full
life
cycle,
whereas
everything
comes
into
picture,
is
that
it
gives
you
the
process,
engineering
capabilities-
and
I
know
I
describe
it
very
simplistically
in
reality-
is
a
little
bit
more
sophisticated.
But
it's
a
very
good
mechanism
to
explain
to
people
how
this
can
happen.
So
what
I
have
done
now
in
this
screen,
I've
taken
five
vital
processes
and
five
srv
tenants
and
I've
done
them
one
to
one
mob.
A
So,
basically,
your
problem
management
in
idle
is
exactly
the
same
with
the
postmortems
in
the
sme
world,
with
a
little
bit
more
changes
on
the
engineering
mechanism
around
it
in
the
culture.
Your
release
management
is
the
corresponding
release
engineering
in
the
sr
reward.
So,
basically
you
have
a
release
management
process.
How
do
we
simplify
it
and
re-engineer
it
release
engineer
it
in
essence,
it's
very
descriptive
as
a
term
service
level,
management
can
be
implemented
through
the
slo's
sli's
mean
time
to
recover
and
the
error
budget
mechanism,
your
service
transition
phase,
definitely
needs
a
production.
A
Do
the
mapping
and
actually
keep
doing
the
reconciliation
as
both
the
concepts
evolve
and
your
overall
adoption
of
both
is
evolving
and
then
to
fit
them
into
your
broader
devops
operating
model,
because
they
need
to
also
come
into
play
with
other
devops
aspects
that
are
not
I.t
service
management
and
only
focused.
So
if
you
haven't
done
this
exercise,
I
propose
to
you
that
you
do
it
and
you're
gonna,
find
it
really
intuitive
and
and
and
that
the
one
could
also
come
to
to
complement
the
other
in
in
reality.
A
A
Whatever
your
context,
everyone
in
the
sra
team
needs
to
have
an
engineering
background,
and
everyone
should
be
able
to
code.
What
I
have
listed
here
is
quite
of
a
complete
profile
set
of
what
you
would
look
for
in
order
to
have
the
ideal
composition,
but
again
depends
on
whether
you're
on
your
on
your
context.
A
So
basically
definitely
a
software
engineer.
Definitely
you
need
qa
engineering.
Definitely,
you
need
cloud
nativeness
infrastructure
engineering,
if
you're
already
or
you're,
going
towards
infrastructure
as
code
and
users
of
public
cloud
services,
the
the
right
composition,
I've
seen
myself
is
three
to
four
of
these
profiles
that
actually
can
rotate
also
within
the
team
when
needed.
So
you
have
a
primary
and
secondary
in
its
tenant
or
discipline.
The
way
you
organize
it
and
the
magic
number
is
seven.
So
seven
people
with
one
tech
lead
and
there's
some
very
good
publications
from
google.
A
Why
it's
important
to
have
a
tech
lead
in
the
rest
of
the
team?
It
is
the
ideal
combination.
Now
it's
obvious.
We
talk
about
these
eight
profiles
and
then
basically,
capability
and
skill
set
mapping
can
be
very
handy
in
order
to
rank
profiles
horizontally
on
how
much
improvements
they
need
to
understand,
but
also
vertically
on
how
much
in
depth
they
should
be
going
in
certain
concepts.
A
So
this
is
a
little
bit
out
of
the
fundamentals,
and
I
have
some
lessons
learned
here.
I've
learned
in
the
hard
way
I
have
a
lot
of
romantic
stories,
implementing
sre
and
in
the
very
early
days
and
when
the
concept
became
available
in
2016
and
people
started
talking
and
using
it,
and
I
brought
here
a
sample
of
them,
so
it's
very
important
to
have
responsibly
lazy
people.
I
don't
know
if
that's
a
term,
but
I'm
using
it
myself.
So
basically,
your
sra
should
be
lazy,
but
also
be
very
responsible.
A
So
lazy
in
this
case
means
that
they
don't
want
to
do
manual
things.
They
don't
want
to
take
calls
at
midnight
and
they're
going
to
make
sure
that
they
prove
preventive
and
productive
actions.
To
avoid
that,
they
give
you
a
very
romantic
story.
That
was
my
the
first
slv
team
that
I've
ever
built
and
if
they're
here
now,
I'm
sure
they're
gonna
smile.
We
were
lucky
enough
that
when
we
got
started
and
in
the
first
six
to
nine
months,
most
of
them
were
other
already
had
very
young
kids
or
their
wives
were
giving
birth.
A
So
basically
they
had
many
reasons
to
wake
up
at
night,
and
the
last
thing
they
wanted
is
to
wake
up
at
night
because
we
had
the
incident
so
basically
they've
done
a
great
work
in
order
to
build
very
reliable
systems
from
the
ground
which
reliability
built
in
by
design
to
make
sure
that
they
won't
be
called
at
night,
and
this
is
a
true
story.
Actually
it's
like
by
coincidence,
now
don't
sell
it
only
as
automation.
I've
seen
that
in
many
places
for
some
for
some
reason,
people
have
difficulty
to
explain
what
site
reliability
engineering
promote.
A
It's
very
descriptive
from
its
name
actually,
as
I
mentioned
in
the
first
slide,
especially
if
you
read
it
buttons.
So
for
many
reasons
they
just
call
it
and
baptize
it
as
automation,
which
is
a
fallacy,
because
automation
and
the
elimination
of
toil
is
only
one
of
the
tenants,
so
don't
get
started
and
call
it
automation,
because
you're
going
to
lose
the
essence
of
what
you
want
to
make
out
of
it.
A
You're
going
to
get
people
lost
in
the
way
of
what
this
is
really
about,
and
also
you're
going
to
have
issue
by
to
to
create
team
skill
set.
That
is
really
fitting
your
objectives
now,
safety
to
the
extreme
left,
and
basically
that
goes
not
just
from
the
first
commit
or
the
first
requirement
written.
A
It
goes
from
the
ideation
phase,
so
safety
totally
left
in
the
us
dlc
don't
force
people
into
the
role.
And
if
we
talk
about
the,
I
thought
that
everyone
needs
to
have
an
engineering
background.
Everyone
should
be
able
to
code,
there's
some
people
that
they
prefer
coding
and
they
don't
like
the
operations
aspect
of
things.
Don't
try
to
force
them
into
the
operation
world
because
it
won't
be
good.
A
Neither
for
you,
nor
for
the
service
find
people
that
voluntarily
want
to
take
this
role
and
that
they
enjoy
to
go
back
and
forth
into
the
stlc
lesson
number
five
difficult
trout
to
attract.
We
all
have
the
same
problem.
We've
all
been
there.
We
all
are
there
and
we're
going
to
be
there,
so
basically
try
to
find
candidates
internally
and
incubate
them
into
the
rule.
It's
going
to
be
very
difficult
to
find
the
amount
and
quality
reserves
you
won't
offer
number
six
do
the
math.
A
A
A
A
In
certain
cases,
it's
going
to
be
a
lot
of
investment
for
internal
trainings,
outside
training,
certifications
and
when
people
when
organizations
discover
what
the
cost
about
it
is
they
withdraw
their
bids.
Another
lesson
learned
is
that
bring
your
business
partners
with
you,
product
owners,
business
directors,
get
them
to
understand
what
the
value
proposition
is.
So
there's
many
more
than
once
outlined
some
context
of
the
shift
left,
testing
aspect,
yeah
very
much
correct.
So
basically,
it's
happening
now.
We've
had
a
similar
session
at
work
today,
so
we're
creating
new
devops
playbook
model.
A
So,
basically,
the
patterns
and
standards
and
guidelines
that
you
use
to
design
your
application
should
take
both
functional
and
non-functional
requirements
into
account
and
this
functional
testing
like
unit
testing
regression
testing
uit,
and
then
you
have
the
whole
loan,
functional
performance,
reliability
and
and
so
on.
So
basically
we're
designing
your
application
and
outlining
your
requirements.
It's
very
important
from
the
very
early
days
to
take
these
aspects
into
account
and
look
how
you
can,
for
instance,
use
your
csd
pipeline
to
achieve
that.
What
your
test
plans
will
be,
what
test
environments?
A
A
So
have
an
estimation
framework,
for
instance,
that
is
fully
hooked
up
to
your
cicd
pipeline
and
then,
basically
that
can
be
used
to
trigger
any
any
level
of
test.
Then
take
that
test,
automation,
framework
and
and
actually
have
it,
the
more
you
shift
to
the
right,
the
slimmer
it
becomes
because
you
start
with
something
very
heavy
on
your
ci
and
then
you
can
use
subset
in
order
to
us
as
you
go
to
your
cd
side
and
which
you
can
also
use
for
chaos,
engineering
practices.
A
So
one
of
the
practices
to
use
regression
test
cases
or
performance
load,
test
cases
focus
engineering.
Also,
you
can
use
some
of
this
test
cases
for
disaster
recovery,
which
is
an
exercise
that
you
go
down
in
most
of
the
case.
If
you
don't
have
a
pre-production
environment
which
is
a
replica
of
production,
it's
going
to
happen
in
your
production
environment
so
basically
summarizing
it
without
becoming
very
lengthy.
A
It's
very
important
that
once
you
build
it
in
by
by
design
and
if
your
application
is
already
there
and
you
don't
build
it
at
the
moment-
it's
good
to
collect
data
from
production,
because
production
tells
you
the
truth
and
then,
through
the
whole
problem,
management
and
everything
enrich
your
quality
of
release.
Capability.
Sifting
left.
A
A
The
sres
are
not
entering
the
game
in
production.
The
sres
are
entering
the
game
from
the
continuous
design
and
development.
I
call
it
so
they
do
have
the
same
backlog
with
the
developers.
Maybe
it's
the
same
person
actually
the
developer
and
the
sre.
They
do
have
a
saying
on
the
prioritization.
They
do
meet
the
product
owner
when
the
partner,
chromic
and
prioritization
takes
place.
So
basically
it's
not
that
they're
going
to
get
involved
only
when
something
goes
wrong
in
in
production.
A
This
is
a
little
bit
of.
I
don't
know
how
to
call
it.
I
use
some
weird
terms
to
describe
things
to
people,
but
there's
a
little
bit
of
engineering
traditional
operations,
but
sre
actually
is
really
getting
the
people
together
with
the
process
shifting
left
in
the
sdnc,
and
then
you
can
have
if
it's
a
different
people
and
it's
not
the
same
one.
A
So
if
you
have
developers
necessary
in
I've,
seen
both
a
developer
being
srv
at
the
same
time
in
the
rotational
mode,
but
also
have
saying
five
developers
and
one
survey
taking
care
of
the
service,
the
five
developers
deliver.
So
your
whole
topology,
as
I
talked
about
fundamental
number,
two,
how
you
organize
is
super
important.
That
will
also
give
you
a
taste
on
how
much
left
your
your
routine
is.
A
Shifting
well
actually
mike.
No
definitely
there
must
be
something
from
the
linux
foundation
I
mean
the
community
is,
is
is
huge.
I
promoting
use
my
own
network,
which
I
actually
built
out
of
conferences
and
inventors
that
I
work
with
in
my
in
my
professional
life,
public
cloud
services
and
csd
vendors
and
container
vendors,
but
I'm
certain
there's
something
on
the
linux
foundation
around
this
area
that
I
haven't
discovered
myself
yet.
A
More
questions
you
can,
you
can
go
as
broad
as
you
want
and
and
go
way
far
from
the
material
I
presented
depends
david.
So,
basically
definitely
you
will
expect
a
series
to
to
know
scripting,
and
I
I
distinguish
between
scripting
and
programming
at
least
myself.
So
scripting
is
bus.
It's
python
is
ansible,
so
basically,
this
is
languages
that
help
you
to
achieve
operational
efficiencies.
I
call
them.
Programming
is
something
that
you
develop
in
order
to
build
business
logic
and
that's
could
be
dotnet,
java,
csarb
and
so
on.
A
It
is
definitely
mandatory
that
your
sris
can
script,
because
a
lot
of
the
total
elimination
and
observability
and
release
engineering
stuff
is
pure
scripting.
Actually
now,
when
it
comes
to
hardcore
basic
hardcore
business
logic
programming
to
be
a
little
bit
more
academic
again,
it
depends
on
on
your
topology
and
the
tenants
you
defined.
A
A
Actually,
david
is
going
to
stay
blurry
forever
because
it
really
depends
on
on
what
you
want
to
make
out
of
it.
The
most
difficult
challenge
is
the
company
yeah.
I
can
tell
you-
and
I
hope,
I'm
not
sure
if
my
current
colleagues
are
here,
but
definitely
colleagues
from
elsewhere-
they
wouldn't
relate
it.
Is
it
is
difficult
to
explain
to
people
what
it
is
about
and
explain
them
mostly.
Why
is
not
coming
into
conflict
with
devops
and
why
is
it
coming
into
conflict
with
idol?
A
The
biggest
difficulty
that
I
had,
and
I
can
tell
you
my
romantic
story-
the
first
cesarean
adoption
I've
done
some
years
ago.
It
was
behind
the
scenes.
It
was
backed
up
by
my
cio
and
the
top
management.
It
was
driven
by
regulatory
heavy
regulatory
project,
but
it
happened
behind
the
scenes
because
initially
we
did
fail
to
explain
to
people
that
guys,
srv
is
going
to
come
and
complement
idol
and
devops.
A
We're
not
gonna
come
and
bombard
what
has
already
happened
and
in
my
experience
it's
easier
not
to
talk
a
lot
about
it
and
then,
when
you
have
the
success
stories-
and
you
have
done
this
reconciliation
in
a
small
setup
and
you've
proven
that
you
manage
to
fit
yourself
into
the
broader
context,
then
become
more
vocal
about
it.
Because
then
people
can
see
something
real
and
it's
not
powerpoint,
slides
or
fairy
tales
from.
I
am
a
tech
giant
actually.
A
A
So
an
idea
is
agile.
Itsm,
dev,
obsessary,
getting
people
from
here
to
here
directly
is
pretty
difficult
closely
impossible.
Actually,
if
I'm
to
be
frank,
also
because,
let's
not
hide
behind
our
fingers,
this
organizational
behavior
aspects
that
don't
want
necessary
to
succeed
because-
and
I
can
talk
openly-
there's
no
no
problem
about
a
successful
srv
adoption,
minimizes
the
manual
interventions
and
hunts
you
need
to
run
services
and
that
in
some
companies
will
result
to
rethinking
about
the
people
baseline.
A
What
advice
would
you
even
have
a
postmortem
because
sometimes
again
correct?
So
basically
I
call
it.
I
use
the
term
solidarity
in
myself
and
it
comes
from
the
old
days
when
I
started
implementing
devops
and
basically
I
was
trying
to
to
to
get
closer
with
my
partners
on
the
development
side
and
operations,
and
basically
I
was
talking
about
them.
Solidarity.
A
And
and
basically
you
need
to
embed
to
people
that
we
need
to
solve
solidarity
and
it's
all
about
using
the
right
wording,
in
my
opinion.
So
definitely
definitely
if
one
area
has
done
something
wrong,
it
is
you
you
will
have
to
blame
them
right,
but
use
the
right
wording
at
the
right
attitude.
So
don't
point
the
figure.
Don't
say
you
say:
our
partner
is
in
infrastructure,
not
infrastructure,
guys.
So,
basically,
when
we
look
into
what
went
wrong,
definitely
you're
gonna,
it
has
a
necessary
need,
but
it's
all
about
the
culture.
A
How
close
you
work
with
these
teams
and
the
wording
and
and
attitudes
that
you
gotta
use
and
essentially
to
make
as
every
happen
as
any
other
concept?
That
is
a
little
bit
radical.
You
need
to
make
friends
in
the
organization,
so
it
also
depends
on
the
level
of
friendship
you
have
across
areas
which
is
on
the
soft
side
of
things.
A
A
Well,
legacy
from
colleen
that
we
are
out
of
time.
Actually.
Thank
you
very
much
for
attending.
Thank
you
for
your
questions.
I'll
be
more
than
happy
to
connect
to
linkedin
and
have
a
virtual
coffee
and
discuss
more
on
the
concept
have
a
good
afternoon
night
day
wherever
you
are.
Thank
you
very
much.