►
From YouTube: GitLab 15.3 Kickoff - Monitor:Respond
A
A
So
over
the
last
few
milestones
ever
since
15.00
we've
been,
we've
been
doing
a
lot
of
cleanup
on
a
bunch
of
different
areas
of
code
base
that
the
respond
group
is
responsible
for
so
in
15.2
we
remove
the
code
for
our
old
style,
metrics
and
logging
capabilities,
so
they're
no
longer
part
of
the
get
lab
code
base
going
forward.
A
So
in
this
milestone,
15.3
coming
up,
we
are
actually
doing
a
bunch
of
feature
work
yay
that
dovetails
from
the
incident
timeline
nbc
that
we're
launching
in
15.2.
A
So
the
first
capability
that
we're
adding
is
the
ability
to
edit
an
existing
timeline
item
so
in
the
mvc
you
can
add
or
delete,
but
in
this
follow-up
iteration
we'll
be
having
the
ability
for
users
to
edit
a
pre-existing
timeline
event
and
beyond
editing,
we're
going
to
add
an
ability
to
add
timeline
events
directly
from
comments.
So,
during
the
fire
fight
where
instant
responders
are
busy
trying
to
resolve
the
issue,
sometimes
people
may
be
adding
a
comment
into
the
issue.
That's
actually
really
important,
such
as
hey.
We
discovered
what
went
wrong.
A
A
A
The
comment
gets
added
to
the
timeline,
so
we'll
notify
the
user
directly
close
to
the
place
where
they
click
the
button
and
once
it's
added
you'll
have
important
information
as
to
who
made
the
comment
when
it
happened
and
obviously
the
comment
itself.
A
Next
up,
we're
also
going
to
be
adding
a
brand
new
feature
that
we're
calling
the
links
widget,
as
you
can
imagine,
in
firefighter
lots
of
things
going
on.
There
may
also
be
lots
of
resources
available
to
the
team,
so,
for
example,
a
slap
channel
where
the
incident
is
being
discussed
is
something
you
want
quick
access
to.
Similarly,
the
zoom
call
that
all
of
your
responders
are
talking
in.
That
might
be
a
place.
A
You
want
to
highlight,
beyond
that,
your
grafana
dashboard,
a
specific
link
to
your
monitoring
tool,
a
notes
document
for
your
keeping
track
of
what
you
discovered.
These
are
all
important
things
that
you
want
to
have
quick
access
to
during
the
incident,
so
to
facilitate
that
we're
adding
this
step
back
a
few
there's
this
new
links,
resources
widget,
so
you
can
add
a
new
one,
adding
the
appropriate
text
and
the
link
and
it's
going
to
show
up
so
that
other
participants
in
the
incidents
can
get
quick
access
to
it.
A
A
So
people
have
a
baseline
for
discussions
to
make
improvements
upon
to
figure
out
what
went
wrong
going
forward
and
one
of
the
problems
that
we
realized
is
the
only
time
stamps
beyond
like
when
people
add
a
specific
other
comments
that
shows
up
on
the
incident
timeline
is
when
the
instant
issue
is
created
and
closed.
However,
this
doesn't
necessarily
match
to
when
the
incident
actually
started
and
when
the
incident
actually
ended
and
beyond
that
there
are
also
other
important
time
stamps
you
might
want
to
record,
such
as
when
when
the
team
is
engaged.
A
These
are
important
time
stamps
that
enables
an
instant
response
team
to
capture
how
long
something
took,
what
improvements
they
can
make
based
on
how
they've
responded
in
the
past,
so
we're
adding
this
feature
called
instant
tags
that
allows
you
to
do
that
so,
when
you're,
creating
an
incident,
you'll
notice
that
we'll
be
adding
in
this
new
event,
type
drop
down
for
the
nbc,
we're
only
starting
with
start
and
end
of
the
incident,
as
you
can
see
here,
and
then
we'll
be
adding
more
to
this.
A
To
this
capability
in
the
future,
and
then
of
course
you
can
also
add
a
comment
and
once
added
it
shows
up
on
the
timeline
order
by
chrono
chronologically,
and
then
it
has
a
special
little
ui
treatment
to
indicate
that
this
is
a
specific
thing,
that's
tagged,
and
with
this
data
we
can
do
all
manner
of
things
going
forward
from
calculating
how
long
took
how
long
response
took,
and
we
can
capture
calculate
things
like
mean
time
to
resolution
across
a
bunch
of
instances.
B
Sure
can
you
see
my
screen?
Okay,
great,
I'm
just
going
to
talk
a
little
bit
about
what
we're
going
to
look
at
for
design,
mostly
we're
going
to
be
digging
into
how
to
improve
our
integration.
With
slack
for
incident
management,
we
do
have
some
capabilities
and
some
integrations
with
slack
currently,
but
our
sre
team
has
their
own
slack
app,
currently
called
woodhouse,
and
the
ecosystem
team
is
also
improving
the
gitlab
slack
app.
So
last
milestone.
B
So
there's
you
can't
separate
the
notifications
at
all
currently
a
way
to
declare
an
incident
from
slack
and
include
important,
additional
details
for
incidents
like
severity
and
things
like
that
directly
from
slack
and
then
a
way
to
keep
content
synced
up
between
gitlab
and
slack,
because
conversations
are
often
happening
both
in
slack
and
on
the
gitlab
issue
or
incident
issue.
So
we
need
to
make
sure
that
we
can
keep
the
content
synced
up
so
that
the
incident
can
remain
the
single
source
of
truth.
B
So
we're
going
to
kind
of
tackle
the
first
two
parts
of
this
last
milestone.
I
made
some
rough
wireframes
for
how
all
of
these
things
could
look
and
I'm
going
to
try
to
focus
on
creating
higher
fidelity
designs,
but
introducing
incident
specific
slack
notifications
is
going
to
be
the
first
part
of
that
that
I'll
look
at,
and
this
is
just
a
rough
wireframe.
B
But
if
we
separate
out
the
notifications,
for
instance,
people
can
define
specific
channel
to
receive
all
of
the
notifications
for
incidents.
So
they
don't
have
to
have
all
updates
about
all
issues.
B
They
can
just
have
incident
specific
notifications,
and
then
we
can
perhaps
introduce
things
like
the
ability
to
create
a
new
slack
channel
for
each
new
incident
declared,
and
things
like
that.
If
we
have
incident
settings
incident,
setting
separate
from
issue
settings
and
the
other
thing
we're
going
to
start
looking
at-
is
how
to
open
and
close
incidents
from
slack
right
now.
B
You
can
create
an
issue
from
slack,
but
you
can't
create
an
incident
specifically
and
it
would
be
helpful
to
be
able
to
create
an
instance
specifically
because
there's
different
data
that
teams
need
to
populate
in
an
incident
with
specifically,
so
you
know
if
we
introduce
a
slash
command
again.
This
is
just
a
rough
wireframe
to
create
a
new
instant.
B
Then
we
can
kind
of
capture
some
of
that
data
like
severity
and
service,
and
things
like
that,
and
these
are
the
kinds
of
functionalities
that
are
already
in
woodhouse,
that
our
own
sra
team
is
using,
but
it's
actually
making
them
available
to
everyone
outside
to
everyone
else.
Who
is
using
slack
for
incident
management?
So
I
think
that
that's
that's
it
from
me.