►
From YouTube: Development First Responder Q&A 2020 07 22
A
C
C
C
C
Yeah
we've
had
we've
had
success
with
the
Devon
call
process
so
far
and
yeah
we
we've
got
a
hundred
engineers
in
the
rotation.
We've
seen
a
lot
of
strong
collaboration
and
many
resolved
incidents,
but
there's
some
opportunities
for
improvement
right
now.
The
scheduling
process
is
very
manual
complicated,
as
well
as
the
escalation
process.
It's
also
manual
right
now,
so
we're
looking
to
to
automate
it.
The
questions
that
we're
asking
ourselves
is:
can
we
better
leverage
sort
of
the
globally
distributed
team
that
we
have?
C
So
so,
what
would
an
escalation
look
like
so
an
escalation
would
would
basically
happen
like
this.
The
incident
would
occur.
An
SRE
determines
that
they
need
any
help
from
development.
They
would
type
incident
or
some
other
command
in
the
dev
escalation.
Slack
channel.
That
command
would
trigger
the
bot
to
select
a
back-end
engineer
based
on
its
algorithmic
criteria.
C
C
C
So
we
do
have
a
bot
demo,
which
James
Lopez
this
and
he's
the
architect
of
this
bot.
So
kudos
to
James
he's
got
a
video.
Please
check
it
out,
demoing
that
we're
not
going
to
go
into
the
demo
right
now
so
then
weekend.
On-Call
would
continue
to
operate
as
it
as
the
on-call
process
currently
works
or
the
scheduling
process
currently
works.
It
would
be
done
manually
via
the
spreadsheet
and
it's
currently
mandatory
to
take
part
in
it
for
anyone
who's
legally
eligible
to
participate.
C
The
the
differences
here
would
be
that
the
bot
would
you
know,
basically
in
order
to
keep
the
escalation
flow
as
similar
as
possible.
Between
the
weekday
and
the
weekend,
the
bot
would
point
to
the
spreadsheet,
and
you
know
whenever
they
type
slash
incident
or
whatever
command.
It
would
trigger
a
message
to
say:
hey,
go,
look
in
the
spreadsheet
so
that
the
process
would
be
as
similar
as
possible
from
weekday
to
weekend.
C
D
To
you
know,
make
yourself
available
and
respond
within
like
it.
Certainly
won't.
You
know
like
a
couple
minutes
at
most,
so
that
was
my
main
concern,
because
yeah,
like
being
like
a
some
communication,
is
like
went
up
our
like
main
ideals
and
I
want
to
make
sure
that
this
can
be
preserved.
So
if
you
want
to
sign
out
a
flag
floor
for
an
hour
or
so
so
if
you
don't
disrupt
that
process,
that
was.
E
C
H
Now
I
think
I
think
that
that
makes
sense,
I
think
the
it's
not
a
big
issue
in
terms
of
getting
paint
on
that
thing
or
doing
behalf.
You
won't
have
to
be
on
call
like
before,
like
every
month
or
so
once
you
get
being,
you
may
not
get
dinging,
maybe
one
or
two
years
so
it
won't
be.
H
A
I
H
We
can,
we
can
definitely
implement
dice.
Quite
it's
quite
easy
to
be
honest,
I
think
it's
a
bit
tricky
to
know
exactly
because
who's
gonna
be
next
is
definitely
someone
who
who
has
to
be
online.
We
don't
know
who's
gonna
be
online
before
before
the
next
incident.
However,
we
can
point
a
list
of
people,
maybe
I,
don't
know,
say
20
or
something
who
are
going
to
be
next
and
if
they
online,
they
can
be
paying.
So
they
know
that
during
the
next
couple
of
months
they
may
get
ping
basically,
the
next
month,
I
think.
F
Very
much,
and
thanks
for
putting
all
this
together,
like
it's
really
great,
to
see
this
evolving.
My
question
really
was
about
the
weak.
De-Escalation
selection
process
just
want
to
make
it
clear,
like
we
have
back
into
engineers
in
infrastructure
and
I,
see
from
no
it's
also
other
places
quality,
for
example,
just
to
make
it
clear
that
they're
already
in
a
different
uncle
rotor.
So
we
need
to
make
sure
there
remain
excluded
from
this
from
this
process.
A
A
H
James
yeah
next
one
just
something
something
to
that
we
can
I
can
just
mention
that
we
need
to
decide
on
the
slash
command.
If
you
want
to
use
this
logic,
amount
isn't
taking
I.
Think
infrastructure
is
for
using
it
with
these
slash
on
call
or
something
else,
as
I
say
that
we
can,
we
can
take
this
off
lying
and
maybe
clear
an
issue
or
something
and
vote
yeah.
There's
no
other
have
any
any
preference.
H
B
You
want
to
go
so
I
can
read
it
just
to
brulee,
so
really
I
said:
can
we
reconcile
data
about
on
call
availability
with
the
team?
Yeah
Moe
file,
for
example,
tell
whether
or
not
a
team
member
is
doing
dev
on
call
if
they
can
do
weekends
or
willing
to
if
that
proposal
is
approved.
We
have
too
many
spreadsheets
to
deal
with
today,
which
are
difficult
to
keep
track
of.
C
Yeah
yeah
yeah
I
definitely
think
that
the
better
leveraging
the
team
ammo
or
coming
up
with
another
yeah
mo
file
that
we
could
use
to
for
for
even
scheduling
would
be
better
for
us,
because
that's
going
to
allow
for,
for
the
the
bot
to
be
able
to
better
ingest
that
data
and
and
may
even
enable
us
to
you
why's
the
bot
more
expansively
on
the
weekends
and
not
have
to
leverage
the
spreadsheet.
So
I
would
definitely
we.
B
Definitely
want
to
get
get
away
from
the
spreadsheet
with
it.
It's
it's
unwieldy
to
work
with,
and
you
chase
after
the
team
to
fill
up
open
slot,
so
we'd
be
getting
away
at
least
from
the
spreadsheet.
At
the
start,
the
spreadsheet
would
be
for
weekends
only
and
we
wouldn't
have
a
spreadsheet
for
weekdays.
A
Yeah
as
much
as
automation,
that
will
be
all
we
should
for
so
this
is
the
missing.
Innovation
is
about
automating
automating,
the
weekdays,
and
we
can
kind
of
we
still
have
to
stick
to
the,
especially
because
there's
a
little
bit
of
challenging
working
women.
But
from
my
point,
I
just
don't
know
that
there
are
certain
information
on
eligibility
is
no
public.
So
if
we
roll
that
information
into
te
amo,
we
may
have
a
problem
here.
A
H
E
Yeah
with
with
rotation
spots
for
respondent,
coming
up
as
you're
saying
you
know
every
year
or
two
for
engineers
and
we
change
processes
quite
often,
so
even
when
you're
doing
a
particular
task
even
once
a
month,
it's
very
easy
to
have
drift
in
your
knowledge
and
your
awareness
of
the
process,
as
well
as
general
practices
and
I,
haven't
really
seen
any
sort
of
thoughts
around
how
that
will
impact.
For
example,
if
I
know
that
I
have
a
rotation,
a
rotation
coming
up
on,
say
Friday
on
Wednesday
I
can
say:
oh
I
have
an
hour.
E
I
can
go
review
the
process
or
so
I
understand
what
to
do.
If
there
is
an
incident
versus
I'm
working
way
on
a
random
Tuesday
and
suddenly
I
get
a
ping
and
I
have
to
go
type
into
the
editing
room.
I
may
not
know
what
to
do
or
who
to
talk
to
or
how
to
to
interact
with
that
team
and
process.
So
is
there
any
sort
of
like
thinking
around
expanded
training
or
more
emphasis
on
engineers
being
current
on
response
policies.
A
Discussions
about
the
training
and
we
consolidate
consolidating
several
ideas
there
in
the
resources
section
of
the
process
and
things
of
both
from
my
personal
experience,
the
most
effective
way
to
get
up
to
speed
is
to
participate.
You
know
rehearsal.
Do
some
rehearsal,
then
just
right,
along
with
some
active
incidents,
ongoing
instance
see
how
that
goes.
That
may
give
you.
A
You
know
the
visibility
of
how
the
process
looks
tied
to
how
people
work
together
to
troubleshoot
or
tragedy
incident
and
also
give
you
exposure
of
the
you
know
the
tools
were
using
and
how
to
approach
the
probe.
The
incident
so
I
think
the
best
my
personal
opinion.
The
best
approach
is
to
write
a
law
with
going
incident
and
to
to
see
who
was
I'm
going.
The
incident
Channel
incident
management
channel
there
are
lot
of
incidents
are
reported
there.
So
I
would
encourage
everyone
to
join
that
a
work
ride-along
with
I
sorry's
I.
C
Guess
follow
that
up
with
with
saying
that
the
original
proposal
issue
included
a
section
on
kind
of
improving
training
and
onboarding
for
for
on-call
participants,
we
kind
of
decided
to
scope
this
to
just
escalation
and
better
scheduling,
basically
automating
scheduling
and
escalation
for
now.
I
think
that
kind
of
addressing
sort
of
improved
training
or
even
improve
access
to
like
run
books
of
what
of
how
developers
should
should
address
an
incident
is
something
that
we
could
definitely
follow
up
with
and
I.
Think
that's
a
really
important
thing
for
sure.
J
Okay,
so
I
have
a
question
about
sorry.
Do
you
hear
me
so
when
we
look,
we
have
two:
will
Julia
choose
what
type
of
ships
to
wants
like
Vicky
days
or
week,
weekends?
So
like
will
we
have
some
understanding
how
many
shoots
in
case
of
we
can
still
be
assigned
per
person
and
if
there
will
be
like
a
process
to
switch
back
from
there,
we
can
still
their
weekdays
and
back.
C
But
there
would
be
a
deep
prioritization
of
those
that
are
on
that
weekend
list,
so
they
would
likely
not
get
called
up
during
the
weekday.
So
it's
kind
of
address
your
question:
there's
not
really
a
choice,
necessary
voluntary
choice
from
weekend
or
weekday
from
my
understanding
of
this,
because
it
kind
of
isn't
where
you
live,
and
what
the
what
the
kind
of
legal
framework
is.
Doesn't.
B
J
B
Your
person,
if
you
sign
up
for
weekend
a
weekend
shift
as
you
are
today.
Anyone
who
signs
up
for
a
weekend
shift
when
they
sign
up
for
their
weekend
shift.
They
need
to
be
available
to
for
escalations
during
that
time
window
just
like
it
is
today,
and
then,
during
the
weekday.
If
an
incident
comes
up,
the
bots
look
to
see
who
was
most
lit
or
least
escalated.
B
Something
during
the
weekday
and
also
taken
to
account
did
did
that
for
those
people
who
took
a
weekend
shift
recently
and
it'll
prefer
people
who
did
not
do
a
weekend
shift
recently
and
have
not
had
gotten
an
escalation
during
the
week
date
recently,
so,
basically
net.
If
you
do
a
weekend
shift,
you
are
unlikely.
You
are
much
less
likely
to
get
an
escalation
during
the
weekday
turned
I.
Think.
A
K
A
K
B
Present
because
we
start
searching
because
we're
not
gonna
have
a
schedule
for
weekdays
thick
schedule
for
weekdays,
or
people
sign
up
for
slots.
The
number
of
slots
that
people
sign
up
for
should,
in
theory,
be
much
less
than
they
are
today,
because
there
are
fewer
of
them.
It'll
be
a
little
less
than
two
days
a
week.
Two
days
a
week
versus
seven
days
a
week
and.
A
One
practical
improvement
we
can
make,
it
is
probably
you
know,
people
have
the
phone
calls,
I
mean
I,
sorry
is
probably
kinda
recharged
by
phone
calls,
then
will
be
more
directed
and
it
will
stop
you
award
not
requiring
everyone
to
be.
You
know,
sitting
have
laptop
always
in
front
of
you.
We
can
use
the
phone
calls
and.
C
So
you
have
your
computer
in
your
backpack
or
something,
but
during
the
week
in
this
scenario,
are
with
this
proposal.
There's
no
reason
to
be
constantly
watching
the
channel
unless
you're
pinged,
so
it
shouldn't
you
shouldn't
feel
like
you're,
always
on
call
just
because
you're
in
the
channel
you
like.
Hopefully
it
should
provide
a
little
bit
more
feeling
of
flexibility
like
if
you
need
to
step
out,
then
you're
not
going
to
get
pinged
like
that
type
of
thing.
C
G
Something
else
to
add
that
I've
I've
popped
in
point
number
eight
is
just
that
people,
UPS
and
legal
is
also
working
under
viewing
this
from
a
policy
standpoint
to
try
to
level
the
playing
field
a
bit
on
the
weekends
and
have
more
people
eligible
to
work
on
the
weekends.
If
they
choose
to
do
so.
So,
as
John
mentioned,
we
don't
have
a
great
solution
today,
but
we're
working
on
making
this
a
bit
more
equal
for
everyone.
L
I
just
wanted
to
highlight
the
wheat
de-escalation
procedure
may
have
some
challenges
on
a
couple
days.
Throughout
the
year,
things
like
Christmas
or
New
Year's
were
probably
a
lot
of
people
across
the
globe
or
taking
off,
or
things
like
contribute.
So
I
just
want
to
highlight
that
that
could
cause
problems
and
I.
Don't
know
whether
we
want
to
look
at
a
volunteer
system
for
that
or
having
named
people
for
those
particular
days
and.
B
Would
do
that?
It's
a
great
question
said:
how
do
we
do
that
with
the
current
process?
Do
we
look
for
I
guess
we
look
for
sign
ups
on
those
days
in
the
spreadsheet
just
like,
as
if
they
were
as
if
they
were
any
other
day.
So
perhaps
we
should
treat
holidays
that
are
very
common
or
or
that
a
large
number
of
the
kilim
team
members
take
off
as
basically
trim
like
weekends.
A
M
N
So
it's
a
bit
more
I,
guess
yeah,
the
scheduling
tooling
is.
Is
it
the
thing
that
we've
been
tripping
over
cuz?
You
have
to
go
into
spreadsheet
and
look
at
do
some
day
time.
Math
plus
I
know
from
the
developer
side
of
things
like
it's
it's
hard
to
trade,
it's
hard
to
do
some
things,
and
so
I
just
called
up
some
some
open
source,
tooling,
that's
used
by
some
rather
large
companies
like
Target
and
Linkedin,
that
that
does
a
lot
of
this
scheduling
so
yeah
a
couple
of
questions
there.
So
so.
B
That's,
let's
know
great
questions,
let's,
let's
separate
so
the
controlling
in
place
to
limit
time
to
escalate,
so
the
current
the
current
bought.
We
said
five
minutes
if
the
person
who
in
pics
does
not
acknowledge
within
five
minutes,
it
goes
on
to
the
next
least,
recently
escalated
to
person
who
is
online
and
not
do
not
disturb.
C
C
We
could
have
it
paying
to
people
in
the
first,
because
the
idea
of
this
is
that
it's
a
first
responder
program
that
whoever
gets
there
first
can
can
you
know,
be
the
one
to
help
so,
but
but
also
trying
to
deal
with
the
bystander
effect,
because
if
it
just
you
know,
broadcasts
into
a
channel
the
likelihood
of
somebody
picking
it
up
is
less
so
we
want
to
select
specific
people
that
they
can
be
the
DRI.
For
that
you
know
at
that
moment,
so
we
could.
We
could
ping
multiple
people
we
could
have.
C
B
We
could
have
the
body
track
time
to
respond,
so
we
could.
We
could
check
that.
So
we
could,
you
know,
look
at
trends
over
time
and
then
optimize
it.
You
know
maybe
after
three
escalations
and
if
it
misses
after
three
people,
it
does
a
at
channel
two
paying
everybody
which
is
a
sledgehammer
form
of
escalation
which
nobody
prefers,
but
maybe,
after
a
certain
time
period.
If
you
know
more
than
X
number
of
people
don't
respond
when
the
time
period.
A
N
I'm
worried
about
experimenting
in
that
way,
I
mean
this
is
like
gitlab
site
reliability
and
we
have
a
pretty
narrow
margin
and
when
we
slip
that
margin,
we
all
customers
money,
so
I'm
worried
about
also
enforcing
reinforcing
some
bad
behaviors
from
my
team
of
just
like
automatically
just
adding
the
channel
if
the
bot
doesn't
respond
fast
enough.
So
that's
why
I
brought
in
the
second
question.
What's.
N
N
B
So
perhaps
you
know
it's
it's
gay
so
perhaps
and
you
we
can
iterate
and
I
want
to
get
to
your
next
question
is
well
Brenda,
perhaps
on
the
bot
we
would
we
would
go
to.
Maybe
we
would
initially
name.
You
know
a
tag.
The
next
three
least
people
at
least
recently
escalated
to
people
and
then
and
then
wait
that
you
know
wait
a
certain
amount
of
time.
Wait.
10
minutes.
Does
the
essay
is
15
and
then,
if
we
don't
see
at
one
of
them
respond
or
acknowledge
within
within
that
10
minutes,
then
at
Channel
yeah.
M
M
Your
concerns
valid
that
the
change
can
cause
problems
proposed
way
to
address.
This
is
for
the
first
month.
We
don't
fully
switch
over.
We
actually
still
have
a
plan,
so
then
you're
guaranteed
somebody's
gonna
show
up,
but
then
we
see
whether
or
not
the
actual
hit
actually
happens
associated
with
that
I.
Don't
really
like
doing
it
for
a
full
month,
but
the
problem
is,
is
we
only
have
eight
a
month.
G
N
Yeah
so
I
mean
the
the
process.
We
have
right
now,
it's
reliable,
it's
not
the
easiest
to
use
from
I
know
from
the
developer
side
of
things,
because
I
think
it's
really
hard
to
like
shuffle
your
schedule.
If
you
suddenly
have
something
that
you
need
to
do,
it's
like
also
being
reminded
if
you're
on
call
so
I
do
recognize
a
difficulty
there,
but
and
as
much
as
I
complain
about
doing
date/time
a
that's
when
I
look
at
the
spreadsheet
like
we
know
who's
on
call
and
can
immediately
get
that
person
and
yeah.
N
M
M
M
H
Sorry
I
was
gonna
mention
that
if
someone
is
D&D
or
a
way
what
we
will
escape
it,
so
we
won't
it
won't
waste
time.
Maybe
there's
like
milliseconds
there,
and
then
it
will
be
the
next
available
person
and
if
there's
a
lady
15
minutes,
I
mean
we
can
instead
of
five
minutes,
we
can
wait
less.
We
can
see
more
people
there's
a
few
things.
We
can
do
there
and
again
the
diversity
is
right.
Now
it's
just
an
MVC.
H
M
K
H
M
Actually,
in
this
particular
scenario,
I'd
love
both
individuals
to
respond,
and
you
know
if
they
need
to
collaborate
to
work
on
the
problem,
then
that's
that's
even
better.
From
that
perspective,
you
know
we're
not
my
understanding
of
this
program
is
we're
not
waking
people
up,
so
they
answer
a
call.
So,
like
you
know,
that's
something
we
can.
You
know,
at
least
in
the
short-term.
We
can
manage
that
process.
B
So
break
your
other
question,
which
is
another
great
question.
You
know
how
about
other
tools
like
go,
alert
or
on-call
tools
or
what
LinkedIn
released
open
source?
Is
we
evaluated
these
and
and
they
are
designed
for
having
a
small
number
of
people
in
a
rotation
in
many
different
groups?
And
that's
not
the
situation
that
we
have.
We
have
a
large
number
of
people,
so
so
the
small
groups,
by
like
10
people,
it
might
be.
B
You
know
one
group
supporting
the
database
and
other
group
supporting
you,
know,
authentication
and
other
group
supporting
logging-
or
you
know
it's
quite
kind
of
my
feature
and
by
component
and
we
have
a
large
number
of
people.
You
know
Turner
people
in
this
larger
rotation
signing
up
by
schedule,
not
by
you
know,
a
escalation
path
of
you
know
this
person.
First
then
this
person
in
this
person
so
those
tools
we
could
we
could.
Obviously
you
know
some
of
them
are
open
source
and
we
could
modify
them
for
our
needs.
B
But
when
we
went
down
that
is
like
they
don't
meet
our
needs.
As
is
and
based
on
the
survey
that
we
did
across
the
team,
they
preferred
more
of
it
led
us
towards
the
path
of
this
week
day.
We
have
enough
volunteers
to,
or
people
interested
in
doing
this
week
day,
rotation
via
slack
and
then
weekends
the
other
way.
So
we
did
look
at
them.
A
So
I
experiment
in
parallel
for
sorta
period,
we
can
decide
how
long
that
is
and
see
how
it
goes
at
that
point
until
we
decide
if
we
continue
this
as
official
world
or
we
revert
back
to
the
current
way
that
completely
spreadsheet
I
mean
right
now
we
are
just
in
the
other
certain
about
reliability
versus
there's.
The
flexibility.
O
Yeah
I
was
just
wondering
about
the
very
conversation
about
making
this
a
voluntary
process
is
this
was
an
add-on.
You
know
if
you
signed
on
and
it's
specifically
not
part
of
your
role.
This
is
an
add-on
like
extra
sponsz,
abilities
and
duties.
So
we
talked
about
making
this
voluntary
so
that
the
folks
who
were
able
to
or
wanted
to
could
sign
up
and
I
see
some
answers
down
here.
You
know
if.
B
C
Yeah
I
mean
just
just
adjust
that
a
little
bit
so
originally,
the
idea
was
to
create
more
like
a
first
responder
program
like
more
like
a
specialized
group
of
folks
that
were
trained
and
that
were
could
jump
in
when
they
need
it
to
and
it
seemed
like.
After
we
did
the
survey
we
just
didn't
get
enough
enough
feedback
that
people
would
be
interested
in
supporting
or
taking
part
in
a
weekend
on
call
or
a
weekend
first
responder
program.
So
that's
where
it
had
to
shift
a
little
bit.
C
O
I
suppose
my
question
is:
this:
is
technically
the
sre
role,
so
if
we
you
know,
could
we
consider
engaging
more
sres
like
adding
more
to
that
headcount,
getting
them
the
training
and
the
support
to
do
that,
because
that
really
is
the
sre
rule
and
you're,
always
in
I've,
been
in
that
role
and
it's
your
engagement,
full-time,
you
know.
What's
going
on,
you
know
the
changing
processes.
O
Like
you
know,
the
main
branch
is
read
quite
often
and
things
were
allowed
broken
and
we
have
to
roll
them
back
and
we've
seen
that
a
couple
of
times
we've
seen
that
go
out,
we
have
13
it's
about
drop,
broken
Todd.
You
know
these
kinds
of
things
right,
we're
not
protecting
ourselves,
and
so
the
on
call
is
kind
of
patching.
Something.
That's
broken
so
I'm
wondering
have
we.
What
are
we
doing
to
iterate
against
that?
O
Like
that's,
because
I
feel,
like
that's
more
the
core
thing:
I'm
not
trying
to
be
mean
here,
so
please,
please,
don't
take
it
that
way,
but
I
see
that
the
poor
trying
to
address
a
problem
by
adding
more
blankets
to
the
fire
instead
of
just
putting
out
the
fire.
So
that's
what
I'm
trying
to
wrap
my
brain
around
as
well.
C
Yeah
I
mean
like
we
should
be
adding
wet
blankets
to
the
fire.
So
yeah
I
mean
to
me
that
that
seems
really
important,
but
a
little
different
in
terms
of
like
we
shouldn't
be
pushing
broken
code.
I
mean
that
should
just
be
standard
right.
We
should.
We
should
be
pushing
things
that
we
would
feel
good
about,
but
this
this
was
more
to
add.
C
O
I
do
understand
that
it's
just
I've
tried
to
stay
engaged
with
this
process,
as
it's
changed
over
time
and
I
feel
like
this
I've.
Never
thought,
like
there's
been
a
good
answer
that
question
so
as
we
iterate
this
process,
I
just
felt
like
it
needed
to
come
back
up
and
there's
a
more
appropriate
place
to
have
that
discussion.
Let
me
know
I'm
always
happy
to
add
thoughts.
I,
just
I
didn't
know
where
else.
To
put
it
no.
G
I
mentioned
above
legally
people,
ops
are
kind
of
working
on
making
it,
so
everyone
who's
interested
in
weekend
shifts
is
eligible
to
do
so
from
a
legal
standpoint,
but
it
sounds
like
this
is
more
just
based
on
weight
and
Nicholas's
comments.
It's
more
of
a
volunteer
challenge
versus
an
eligibility
challenge
from
a
legal
standpoint.
Yeah.
A
B
I
think
with
one
of
the
ideas,
I
can't
I
think
they
came
from
Christopher
earlier
I'm
keeping
the
spreadsheet
in
the
first
month,
so
you
use
the
bots
first
and
then
the
bots.
If
the
bot
does
not
get
the
attention
of
someone
who'd
knowledge
is
in
a
certain
period
of
time.
Then
we
go
to
the
spreadsheet
I.
Think
that
lowers
the
risk
significantly
of
a
delay.
A
significantly
delayed
escalation.
We'd
have
to
play
with
the
timeframes
like
how
long
do
we
wait
before
we
go
to
the
spreadsheet?
Maybe
it's
not
very
long.
B
Maybe
it's
only
five
minutes
before
we
go
to
the
spreadsheet
and
we
make
sure
the
spreadsheet
the
slots
are
figured
out.
That
would
cover
us
on
the
risk
side
of
having
a
significantly
delayed
escalation.
We
actually
in
theory
and
hopefully
would
have
faster
escalations
with
this,
but
you
know
we
surely
don't
know
that
until
we
try
it
so
I'm
not
at
doing
a
survey
to
see
if
we
should
move
forward.
I
think
that
idea
lowers
our
risks.
B
B
For
the
first
month
continue
to
have
the
spreadsheet
for
all
time,
wind
and
the
bot
waits
only.
You
know
a
small
number
of
minutes,
maybe
five
or
ten
before
it
encourages
the
sre
to
use
the
spreadsheet
and
we
make
sure,
there's
a
coverage
in
the
spreadsheet
to
lower
a
risk.
In
case
the
bot,
as
slack
escalation,
is
not
successful.
Often
enough.
I.
B
Sorry,
I'm
talking
immune
other
folks
thoughts
on
that,
just
if
that
reduces
the
risk
of
a
significantly
delayed
escalation.
M
B
But
yeah
I
know
we
just
said:
I
said
you
know
no
survey
or
I
was
not
in
favor
siree.
Could
we
do
a
quick
if
you're
in
favor
of
us
moving
foe
of
us
being,
you
know,
get
lab
moving
forward
this?
Can
you
do
a
reaction
of
a
thumbs
up
in
in
zoom
and
get
a
general
feel
for
it
thanks
and
if
not
don't
do
anything.
A
B
B
A
B
Yeah-
and
so
it's
been
that
group
of
the
four
of
us
at
least
initially
working
on
this
with
feedback
from
many
folks,
if
anyone
would
like
to
be
more
put
put
time
in
this
to
help
guide
it
as
we
make
the
decisions
and
go
forward.
In
addition
to
you
know
commenting
and
on
issues
and
being
this
me,
please
I
guess
since
Chen's
gonna
schedule,
the
meeting,
just
let
Shawn
know
would
be
more
than
happy
to
include
you
in
the
discussions
where
we
definitely.