►
From YouTube: 2021-09-09 Scalability Team Demo
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Yeah,
so
it's
about
an
issue.
It
started
when
jan
and
sean
were
talking
about
having
a
separate
separator
sli
for
the
service
desk.
So
the
thing
that
receives
emails
and
creates
issues
for
that
for
those
emails
and
so
on,
but
that's
not
as
used
as
everything
like
that
runs.
That's
mostly
sidekick.
So
that's
where
that
sli
would
live,
but
that's
nowhere
near
used
as
much
as
all
the
other
sidekick
jobs
that
run
so
we
would
need
like.
A
B
B
But
if
you
cast
yourself
back
far
enough,
we
didn't
have
jsonnet
generating
all
of
this
stuff
and
it
was
all
hand
coded
rules,
and
it
was
really
hard
not
to
mess
things
up,
because
you
had
to
make
sure
that
everything
was
here
and
here
and
here
and
in
10
different
yaml
files,
which
was
really
horrible,
and
one
of
the
things
that
I
chose
to
keep
things
a
little
bit
simpler
was
to
have
a
single
slo
per
service,
because
it
was
just
like
one
less
thing
that
you
could
mess
up,
and
the
intention
has
never
been
to
stick
with
that
and
now
that
we
have
it
in
the
in
the
jsonnet.
B
And
it's
like
you
know,
everything
is
got
a
single
source
of
the
truth.
Instead
of
having
ten
sources
of
truth,
I
don't
see
any
reason
why
we
have
to
keep
that
it
is.
My
is
my
take
on
that
cool
and.
A
Do
you
have
thoughts
on
where
to
keep
it,
because
the
suggestion
sean
made
on
the
merger
quest
was
like
to
keep
it
right
next
to
the
sli
definition.
A
B
Right
so,
okay,
so
those
yeah
it's
slightly.
So
I
think
if
you
aggregate
up
to
so
we'll
have
to
treat
those
as
the
ones
for
the
service
and
at
the
service
level
we'll
have
one
set,
but
then
on
the
individual
level.
I
guess
it
will
inherit
the
ones
from
the
service,
but
I
think
we
should
definitely
keep
them
on.
You
smiling
at
the
wincing.
B
A
B
A
B
B
A
Yeah
but
like
even
for
an
essa
like
if
you
don't
specify
a
different
one
for
deployment
or
for
mtbf,
then
like
we'll
just
not
record
it
and
everything's
fine.
C
A
Well,
the
deployment
one
is
used,
I
think,
but
the
like
for
this
kind
of
super
low
traffic
sli.
B
Although
what
came
up
in
a
meeting
I
had
with
that
technical
debt
assessment
meeting
with
christopher
on
tuesdays,
they
wanted
to
have
a
whole
bunch
of
like
for
every
feature,
flag,
toggle
like
basically
like
a
more
rigorous
set
of
dashboards
and
everything,
and
what
I
was
encouraging
is
actually
pointing
to
an
sli
rather
and
then
so
in.
In
those
cases
with
the
feature
flags,
it
would
be,
you
know
it
would
be,
there
would
be
an
action
on
the
individual.
B
You
know
if
the
sli
of
a
particular
feature
went
over
an
edge,
then
the
feature
flag
could
be
automatically
reversed,
for
example,
would
be
one
would
be
one
approach
to
that,
but
that's
a
slightly
different
discussion,
but
I,
I
think
yeah
if
we
just
had
a
single
one,
which
was
effectively
the
the
monitoring
one.
B
Yeah
yeah
because
the
deployment
one
doesn't
matter
mtbf1
I
mean
ultimately
over
time
the
mtbf1
is
kind
of
like
a
where
we
want
to
be.
Rather
so
yeah,
it's
it's.
We
should.
You
know
those
two
should
theoretically
come
together,
but
we'll
see
that
happening
when
it
happens,
but
yeah,
I
think
I
think
from
you
know,
and
also
let's
do
it
as
a
first
with
the
monitoring
and
then
we'll
have
a
better
understanding
of
it.
And
then
we
can
move
forward
and
if
we
need
the
mtv
f1,
we
can
do
it,
but
yeah.
A
B
Yeah
yeah,
I
I
think
that
might
get
quite
like
like
there's
a
lot
of
yeah.
A
There's
a
lot
of
conflict
there
I'm
going
to
this
is
my
main
concern
about.
A
That's
like
implementation
detail,
I'm
going
to
take
note
of
what
you
said
like
keep
them
close
together.
The
threshold.
B
B
In
those,
then
they
there's
another
reason
as
well
bob
and
that's
that's
we're
starting
to
see
some
places
where
people
are
sort
of
duplicating
services
and
then
what
they're
actually
doing
is
they're
kind
of
denormalizing
slis
out
of
there,
and
the
case
that
I
can
think
of
is
alejandro
with
the
post,
petroni
and
petroni
registry.
I
think
it
is
it's
basically
another
copy
of
the
petroni
metrics
catalogue
and
he's
basically
dried
it
up
and
he's
copied
and
pasted
right,
and
in
that
case
it
makes
more
sense.
B
Yeah
yeah
yeah
exactly,
but
in
that
case,
when
you're
looking
at
that
sli
that's
shared
between
multiple
services.
You
wouldn't
want
to
kind
of
have
to
remember
to
go
to
another
place
to
see
the
slo
right.
It
makes
sense
for
those
things
to
be
kept
together,
because
then
you
know,
although
it
might
be
problematic,
if
you
want
different
ones
for
different
services,
but
that's
just.
A
A
C
Since
we
are
talking
about
air
budgets
and
having
both
of
those
both
of
those
thresholds
listed
in
for
each
of
them,
I
just
wanted
to
bring
up
that.
There
is
a
conversation
that
some
people
are
having
about
splitting
the
view
of
error
budgets
into
two
parts,
so
that,
if
anyone
wants
to
contribute
to
that
they
can,
they
can
do
so.
Some
of
the
teams
want
to
treat
different.
C
They
want
to
treat
the
different
portions
with
different,
like
with
a
different
level
of
urgency
like
they
want
to
treat
the
errors
first
and
the
updates
portion
second,
but
when
they're
looking
at
it
as
a
whole,
they're
only
seeing
it
as
a
whole,
they
have
to
dive
in
to
be
able
to
split
them.
Apart.
B
A
The
time
to
be
doing
that-
and
I
also
I
would
prefer
to
like-
I
would
prefer
to
go
to
a
place
where
we
monitor
groups
the
way
we
monitor
services,
so
they
have
a
short
range
like
they
watch
the
last
six
hours
like
we
do
on
the
service
overview,
and
then
they
see
things
happening
there
and
then
the
the
big
number
is
more
of
like
how
much
have
we
improved
over
time
and
then
like
now.
C
If
that's,
if
that's
the
case,
then
I'll
get
the
conversation
to
pause
so
that
they
first
see
the
advantages
that
are
going
to
come
from
having
the
customer
customers
for
endpoint
and
if
that
doesn't
give
them
enough,
then
we
can
start
having
a
conversation
about
what
they
actually
need
further
than
that,
but
I
think
you're
right
pausing,
the
conversation
is,
is
more
effective
yeah
I
mean.
A
B
The
patient
is
on
the
table.
Bob
is
performing
the
heart
surgery
like
now's,
not
the
time
to
to
give
him
a
new
pair
of
lungs.
Well,
maybe
it
is,
let's
just
I
would
say,
like
we're,
going
to
have
a
very
good
idea
of
of
of
what
that's
going
to
change
with
regards
to
the
aptx's
and
so
like.
Don't,
let's
not
change
the
other
thing.
At
the
same
time,.
A
Make
sense:
okay,
yeah?
What
are
your
like
thoughts
for
the
future
on
this,
like
with
what
I
just
mentioned,
I'm
having
a
short
view,
and
so
like
the
like?
What
do
we
use
the
28-day
thing
for,
because
that's
more
of
like
an
sla
number?
What's.
C
Really
nice
about
having
the
short
view
is
people
people
want
to
make
changes
and
watch
the
changes
affect
the
error
budgets
right
now.
They
want
to
almost
watch
it.
While
it
rolls
out
and
watch
the
little
graph
change
and
feel
good
that
they've
they
can
see
the
direct
impact
of
their
work
and
over
the
28
days
you
can't
really
it
takes
a
long.
The
the
gratification
is
not
instant.
So
having
a
six-hour
view
is,
I
think,
is
good.
Yeah.
A
B
So
I
mean
bob
this
actually
ties
into
that
that
that
brief
mention
that
I
had
earlier
of
the
feature
flags
right.
So
if,
if
you
can
tie
a
feature
flag
to
an
sli,
we
could
give
them,
we
could
give
the
engineering
teams
an
outs
to
avoid
you
know.
Please
give
us
the
query
that
you
want
for
your
logs.
Please
give
us
the
query:
the
dashboard,
you
know
the
prometheus
query
and
like
fill
in
these
20
things,
you
can
do
the
20
things
or
you
can
give
us
the
name
of
the
sli
and
and.
B
It
in
the
first
version-
it's
just
oh,
this
sli
has
gone
south
okay,
cancel
it,
but
in
a
future
world
it's
like
turn
off
that
feature
flag
straight
away.
Like
no
human
involvement.
B
You
know
obviously
raise
an
alarm
and
everything
else,
but
just
just
toggle
it
off
and
you
can
actually
start
doing
stuff
like
you
know.
There
might
be
multiple
feature
flags
on
at
the
same
time
and
you
can
kind
of
statistically
look
at
where
the
which
one
is
contributing
the
most
actually.
A
B
That's,
that's
it
and
and
sort
of
the
the
the
response
that
I
got
from
from
from
christopher
was
like
well,
do
you
expect
like
every
every
endpoint
to
have
an
sli,
and
I
said
no,
I
expect
every
feature
to
have
an
sli
and,
and
he
was
like.
Well,
that's
that's
a
huge
ask,
and
I
was
I
said:
well
you
know
do
we
want
to
monitor
these
features
like?
I
think
I
think
it
is
a
big
ask
but-
and
it
will
take
time,
but
if
we
can.
B
A
No,
but
the
thing
that
that
that
young
wanted
to
do
with
the
with
the
service
desk
stuff,
that's
like
the
first
thing.
That's
it
like
exactly
what
yeah.
D
B
B
C
B
Yeah
because
there's
there's
from
from
the
the
calls
that
I've
been
there's
like
a
huge
amount
of
pressure,
that's
there's
a
lot
of
things
behind
that
525
at
the
moment,
like
another
example,
was
in
the
call
on
in
the
infra
dev
call
or
engineering
allocation
call
on
tuesday.
Eric
did
a
great
job
of
saying.
Well,
you
know.
Let's
look
at
the
area
budgets
that
you
published
rachel.
I
don't
know
if
you
watch
the
recording
of
that
call,
and
it
was
fantastic.
It's
like
okay.
B
Well,
so
we
breezed
over
it
and
then
eric
said
no,
no,
no,
let's
go
back.
What
are
we
doing?
You
know
these.
These
teams
are
out.
What
are
we
doing
about
this,
which
is
which
is
amazing,
which
is
like
really
kind
of
like
the
enforcement
of
it,
which
was
fantastic,
but
anyway,
one
of
the
things
that
came
out
of
that
was
well.
Then
the
teams
have
to
develop
modern.
B
You
know
one
of
the
things
that
they
might
have
to
do
is
develop
better
monitoring
and-
and
I
said
like-
let's
not
go
in
and
have
like
lots
of
teams,
adding
like
rules
and
and
alerts
to
to
to
the
run
books
like
that's
not
what
we
want
here.
B
Let's
rather
wait
for
bob
and
for
five
to
five
to
be
finished,
and
then
they
can
get
that
monitoring
by
adding
slis
and
that
will
ultimately
benefit
the
whole
product,
not
just
gitlab.com
and
also
it's
not
gonna,
be,
like
you
know,
a
reversion
back
to
everyone,
adding
like
the
10
alerts
for
the
10
last
incidents
and
going
back
to
that
cause-based
approach
right.
So
so
the
and
the
pressure
there
was
like
those
teams
are
getting
told
to
add,
alerting
and
I'm
saying
like.
B
C
A
But
that's
the
reaction,
that's
that's
just
the
thing
that
we
are
doing
it
for,
because
the
ask
at
first
was.
We
want
to
set
a
different
duration
for
a
request,
but
the
way
we're
getting.
There
is
a
way
to
define
a
slice
and
we're
using
that
thing
for
the
requests.
But
then
the
groups
could
already
like
earlier
start
defining
their
own
stuff,
like
yeah
before
we've
gone
through
all
of
the
the
request
endpoints
and
set
appropriate
thresholds
on
them.
A
It's
also
andrew
the
way.
I
currently
think
this.
It's
not
magic
like
when
a
new
sli
record
like
not
for
requests
but
something
else.
For
example,
the
service
testing
desk
thing
would
be
defined.
It
would
still
need
to
be
added
to
the
run
book.
Somehow
like
this
is
a
thing
that
sidekick
will
emit
and
yeah.
B
It
still
has
to
be
added
to
the
like,
I
mean.
Ultimately,
we
should
be
able
to
just
kind
of
pick
that,
like
like,
we
should
be
able
to
publish
that
label
through
the
you
know
through
through
prometheus
and
then
just
basically.
A
Inherit
that
label
it's
not
a
single
metric
like
everything
that
every
new
sli
that's
defined,
will
have
a
new
metric
and
that
should
have
a
feature.
Category
label,
but.
C
A
Right
now,
the
the
metric
is
like
the
requests
count
and
an
abdex
success
count
or
something.
I
don't
remember
why.
B
B
And
then
whatever,
and
then
in
the
run
book
side
we
don't
have
to
configure
each
one.
We
just
say
this
is
a
special
kind
of
sli
and
it
and
it's
we
pick
up
the
you
know
the
name.
You
know
it's
like
a.
We
inherit
the
name
from
the
label.
We
don't
define
each
one
separately
and
then
literally
as
it
rolls
out,
you
know
we
pick
it
up.
We'll
probably
still
need
to
pick
up
metadata
for
like
dashboards.
A
B
B
D
This
is
the
point
we
well.
We
need
to
kind
of
talk
a
bit
about
how
this
will
actually
look
like
this.
No
negotiation
between
inferent
development,
because
that
needs
to
happen.
Like
you
just
said,
there
is
a
possibility.
Someone
will
say
well,
10
seconds
is
fine,
because
my
things
are
green
and
our
infrastructure
can
only
take
five
seconds.
For
example,
what
do
we
want
that?
How
we
want?
How
do
we
want
that
negotiation
to
look
like.
D
D
A
For
now,
like
there's
an
issue
inside
that
epic,
that
says
like
we're,
going
to
set
the
most
important
ones
for
the
endpoints
that
we're
monitoring
now,
but
that's
again
just
for
requests,
but
but
I
haven't
thought
about
the
new
sli
bit
of
that
and
I
haven't
thought
about
slos
on
the
other
side.
So,
on
our
side,
the
request
duration
thresholds,
I
like
in
in
the
beginning.
I
would
just
do
the
thing
that
doesn't
scale
and
ask
us.
C
I'd
also
say
in
the
beginning
that,
when
they
are
set
that
we,
someone
from
scalability,
should
be
a
reviewer
on
those
requests
and
when
we
observe
them
to
be
excessive
for
what
the
endpoint
is,
we
have
to
have
a
conversation
with
them
about
what
it
should
be.
B
Can
I
offer
an
alternative
proposal,
so
I
think
that
the
method,
the
methodology
that
we
use
for
sidekick
and
for
saying
that
things
can
be
slow,
but
then
you
know
basically
having
trade-offs.
So
you
can,
you
can
have
a
95
slo,
but
then
so
with
with
with
sidekick
it
was.
You
can
take
a
minute
to
run
a
sidekick
job.
I
mean
you
could
take
10
minutes
if
you
want,
but
then
we're
not
gonna
treat
it
as
urgent.
You
can
have
you
know.
Maybe
we
can
do
a
different.
C
B
Yeah
and
so
so
so
so
we
give
it's
kind
of
like
a
give
and
take,
and
I'm
this
is
like
really
kind
of
off
the
bat,
but
I
mean
maybe
we
could
do
something
like
where
we
actually
start
sending
traffic
to
like
different
parts
of
the
fleet,
and
it's
like
sure
your
request
can
take
five
seconds,
but
that
puma
there's
going
to
be
a
lot
more
queuing
on
that
and
it
might
take
like
a
second
for
that
request
to
be
seen.
You
know
in
a
busy
time,
because
we
we're
going
to
have
different
scaling
characteristics.
C
C
B
The
the
lever
there
is
actually
the
is
the
is
the
auto
scaling
of
the
fleet
right
because
that's
the
that's
the
thing
that
controls
that
queuing
latency,
the
the
the
amount
of
time
will
take
for
puma
to
see
a
job,
and
so
you
know
we'll
say
by
all
means
you
can
have
five
seconds,
but
we're
gonna
reach
it.
The
problem
is
it's
kind
of
difficult
to
read
traffic
according
to
those
sli's
right
and
but
maybe
that's
something
we
can
overcome.
D
And
just
to
reiterate
rachel's
question,
because
I
don't
think
I
understood
the
answer
to
it.
Is
there
a
way
for
us
to
make
this?
This
is
rachel's
question.
Is
there
a
way
for
us
to
do
this
smaller
right
now
with
one
team,
even
if
it's
super
janky,
because
I
think
one
of
the
other
items,
one
of
the
other
items
that
I
think
is
worth
mentioning
in
this
call-
is
in
that
same
engineering
allocation
call
after
eric
brought
us
back
to
the
error
budgets
topic.
D
He
said,
and
I
quote,
buckle
up
everyone
and
quote
this
is
going
to
be
a
rough
ride,
so
we
need
to
be
prepared
that
there
is
going
to
be
a
bit
of
a
back
and
forth
until
we
get
it
right,
and
I
think
we
should
be
using
that
warning
right
now,
if
possible,
because
it
works
in
our
advantage.
So.
B
B
A
B
We'll
we'll
buckle
up
and
and
see
how
far
we
can
get,
but
but
but
I
do
think
that
that
using
consistent
metric
names
might.
B
B
A
What
I
did
there
is
no.
What
I
plan
to
do
is
enforcing
a
feature
category
label
and
on
an
sli,
that's
well
enforcing,
then,
if,
if
we
review
that,
that's
what
I'm
going
to
mention,
but
then
the
feature
category
label,
for
example,
for
request,
is
going
to
be
different.
All
the
time
and
the
naming
is
also
prefixed,
like
the
the
names
are
also
all
going
to
be
the
same.
It's
like
prefix
with
gitlab
sli,
sli
name,
and
then
it
has
a
total
and
a
success
count.
So
two
counters
with
that
name.
C
Can
we,
I
don't,
have
this
fully
formed
in
my
head,
so
this
may
not
come
out
straight,
but
can
we
get
it
to
the
point
where
we
can
tell
the
stage
groups
what
we
want
them
to
do
while
we
actually
build
it
to
work
in
the
background?
So
if
we
know
that
this
is
the
structure
that
we
wanted
to
have,
it
needs
to
look
like
this
in
the
files.
A
B
A
B
Out
of
interest
is
that
an
api
that
you've
defined-
I
am
defining
yeah,
yeah
yeah,
but
but
yeah,
because
you
can
have
an
api
and
get
everyone
to
implement
the
api
and
then
how
what
you
do
on
the
back
end
of
that
is
kind
of
you
can
you
can
parallelize
those
things.
C
Okay,
so
so
bob
as
part
of
updating
that
effort
today,
can
you
please
perhaps
actually
you
and
I
need
to
have
a
separate
conversation
after
this,
so
that
we
can
figure
out
from
that
epic
which
pieces
get
pulled,
because
I
want
to
be
able
to
communicate
to
people
we're
doing
this
part
of
it
at
this
line.
We
need
you
to
start
defining
slis.
C
While
we
do
these
other
things.
I
just
want
to
be
able
to
have
the
communication
that
we
can
send
out
to
people
so
perhaps
united
chat
after
it.
A
Would
be
very
nice
and
like
even
before
we
start
doing
stuff
with
the
sls
that
they
define
in
the
rails
code
base
and
that
metrics
are
there
when
we
start
doing
stuff
with
them
for
alerting
and
monitoring
like
because
otherwise
we
have
nothing
to
work
with
like
if
we
have
seven
days
worth
of
data,
that's
handy.