►
From YouTube: Handling Error Budgets and Tech Debt
Description
The Verify:Testing group documented (https://about.gitlab.com/handbook/engineering/development/ops/verify/testing/#error-budget-issues) how they handle prioritizing issues that may come from review of the Error Budget dashboard and how this works with prioritization of Technical Debt and features.
A
A
And
we
just
wanted
to
record
a
quick
walkthrough.
We
had
recently
merged,
mr
mr
to
our
team,
page
talking
about
air
budget
issues
and
updating
a
little
bit
are
prioritizing
technical
debt,
and
this
is
in
how
we
plan
on
the
page.
I
wish
I'm
not
sharing
my
screen.
Why
don't
I
do
that?
So
everyone
can
see
what
I'm
looking
at
on
our
team
page.
We
have
some
great
documentation
about
how
we
work
both
planning
and
workflow,
within
the
planning
section.
A
We
don't
consider
bugs
technical
debt,
but
it's
always
work
that
the
team
wants
to
do
to
better
make
the
code
just
work
better,
make
our
systems
work
better
and
then
recently,
we've
taken
on
this
error,
budgeting
methodology
of
keeping
track
of
things
scott.
You
want
to
talk
through
that
a
little
bit
and
how
we're
using
the
error,
budgets
and
our
slos.
B
B
I
will
review
that
budget
dashboard
weekly
on
a
weekly
basis,
if,
if
we
are
spending
too
much,
if
we're
going
over
our
budget,
we'll
I'll
be
looking
through
to
see
which
endpoints
are
causing,
that
and
researching
and
and
creating
an
issue
for
fixing
that
and
improving
that
endpoint
in
any
way,
and
then
we'll
prioritize
that
accordingly,
whether
how
much
their
budget
is
being
taken
up
from
that
endpoint
and
prioritize
it
accordingly
to
our
technical
debt.
A
Yep
and
we
have
on
the
up
section,
pi
review
page,
a
section
about
our
error
budget
and
our
technical
debt
last
I
looked
we're
at
99.98
availability,
so
we're
above
our
target
of
99.95
three
nines.
A
So
so
far,
things
are
working
great
and,
as
we
run
into
issues
we'll
pull
those
in
and
prioritize
those
those
might
end
up,
bumping
other
stuff
out
of
a
milestone,
but
we'll
probably
follow
our
usual
cadence
of
create
the
issue,
pull
it
into
the
next
milestone
and
let
the
team
continue
to
focus
on
what
they're
currently
working
on
as
long
as
it's
not
a
severity
one
issue.