►
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
Hi
everyone,
it
is,
may
4th
2021.
A
I
will
make
the
corny
reference,
but
we'll
save
you,
the
joke
for
any
kind
of
like
star
wars,
reference
or
anything
and
move
on
from
that,
but
welcome
to
the
monthly
infrastructure
team
group
conversation
good
to
have
you
here
and
to
start
with
some
of
the
the
questions
the
slides
are
in
the
agenda
there
and
and
noop
we'll
go
ahead
and
start
with
you.
A
B
B
Congratulations
to
the
team
on
achieving
a
humongous
cost
savings
of
nearly
400k
quarter
by
disabling
object,
versioning
for
register
bucket
registry
bucket.
I'm
wondering!
Are
there
any
lessons
that
we
should
be
incorporating
into
how
we
build
the
product
convention
configuration
default
settings
things
like
that
that
we
can
use
from
here.
C
I
can
comment
on
that,
so
the
next
one
we're
looking
at
is
moving
the
marquee
servers
off
to
the
normal
gilly
shards.
In
terms
of
lessons
learned,
this
change
wasn't
actually
a
plan
change.
It
was
something
that
in
doing
other
work,
we
found
out
that
the
life
cycle
rules
weren't
in
place.
So
in
general
I
guess
lesson
learned
is
like
there's
there's
some
things
that
are
unknown
out
there,
that
we
just
like,
haven't
looked
at
in
a
while.
That
could
result
in
a
lot
of
savings
in
certain
cases.
C
So
I
don't
know
that
there's
a
ton
of
lessons
learned
other
than
each
of
the
product
teams.
You
know
knowing
a
lot
about
their
product
and
the
different
levers
they
have
to
reduce
cost
and
things
like
that
so
yeah.
I
think
just
more
knowledge
about
that
from
the
different
teams
and
yeah.
That
would
probably
help
going
forward.
B
A
Yeah,
I
don't.
I
don't
know
if
there's
been
any
look
evaluation
of
that,
that's
probably
a
a
good
thing
to
check
as
far
as
like
what
we
have
in
in
docs,
of
course,
that
this
is
the
underlying
storage
and
so
based
on,
where
a
customer
has
their
self-managed
implementation,
like
the
the
configuration
of
any
kind
of
like
object,
versioning
or
whatever
is
going
to
differ
from
provider
to
a
provider
or
or
in
the
case
of
you
know
real
on-prem
like
what,
whatever
their
you
know,
storage
solution
is.
D
And
just
more
broadly,
though,
like
I
know
that
everyone
was
answering
specifically
about
the
registry
and
the
and
the
container
storage.
But
more
generally,
there
are
a
lot
of
places
in
the
product
where
there's
no
data
retention
policy
and
just
two
things
that
I
can
think
of
or
found
are
ci
builds
and
I
think
artifacts
as
well,
but
you
know,
and
as
the
product
gets
older,
especially
gitlab.com
gets
older.
D
We
are
storing
more
and
more
data
and
we
have
to
start
defining
like
data
retention
policies
for
that,
because
we
can't
keep
every
build
of
every
project
forever.
So
you
know,
I
think
I
think
that's
a
broad
answer.
Perhaps.
A
Yeah
and
maybe
on
the
the
broader
theme,
I
think
the
other
thing
that
I
I
would
note
as
far
as
you
know,
like
lessons
learned
things
to
come
out
of
this,
is
that
the
like
the
increased
visibility
that
over,
I
think
the
past
I
don't
know
six
to
eight
months
or
so
that
we
we've
brought
to
the
the
cost
of
different
parts
of
the
the
product
and
part
of
that
is
through
the
infrafin
work
and
the
effort
that
davis
has
done
with
various
teams
and
everything
that,
like
as
the
awareness
to
that
cost,
comes
to
each
one
of
the
teams.
A
You
know
it.
It
allows
people
to
you
know
to
question
like
you
know
why.
Why
is
that
costing
so
much?
You
know
like
per
unit
cost
or
whatever,
and
to
be
able
to
dig
in
and
discover
those
things
in
this
particular
instance
that
that
wasn't
the
path
I
mean
it
was
kind
of
discovered.
Almost
you
know
by,
I
would
say,
almost
by
accident,
but
there
have
been
plenty
of
other
cases
where
there's
been
a
questioning
of
like
you
know.
Why
is
that?
A
C
Yeah,
I
think,
we've
discussed
versions
of
that
right
now
we
don't
have
a
finance
r
d
partner,
but
that
would
ideally
be
the
person
that
we
discuss
that
with
in
terms
of
how
we're
allocating
costs
across
different
teams
and
apartments,
and
things
like
that,
that'll
also
require
us
to
have
better
labeling
across
our
resources.
So
we
know
so
we
actually
have
a
standard
way
to
allocate
this
cost
out,
but
yeah.
B
C
A
Yeah,
I
I
think
to
maybe
to
add
on
a
noob
to
that
that
I,
just
as
we
do
with
the
high
level
kpi
metrics
in
infrastructure,
for
some
of
the
spend
across
you
know,
free
and
and
trial,
and
the
costs
per
mau
and
everything
I
think
the
like
iterations
going
forward
would
be
not
so
much.
I
don't
think
we'd
want
to
focus
so
much
on
budgets,
but
but
basically
like
unit
kind
of
cost
efficiency,
yeah
pis
that
that
could
be
shared.
A
You
know,
by
product
development
and
in
infrastructure,
so
that
over
time
we're
improving
the
like
the
unit
cost
of
these
things
and
and
continuing
to
to
scale
with
that
and
yeah.
That's
it.
A
Let's
look
for
there
any
other
questions.
Anyone
wants
to
verbalize.
A
I
will
note
a
new
view.
You
mentioned
air
budgets,
one
of
the
items
on
on
slide
10,
as
the
scalability
team
is
working
with
along
with
product
and
with
the
stage
groups
to
introduce
air
budgets
to
the
stage
groups.
There
is
an
ama
scheduled
for
later
this
week,
so
as
you're
looking
at
your
calendar
and
everything
like
that,
ama
will
be
interesting
or
if
you
want
to
follow
up
with
the
recording
for
that.
A
And
then,
as
far
as
things
to
point
out,
do
you
want
to
point
out?
The
availability
in
april
was
much
improved
and
that's
not.
I
do
want
to
mention
that's
not
by
accident.
It
is
the
the
outcome
of
a
lot
of
work.
That's
gone
into
rapid
actions
by
the
development
teams,
a
lot
of
reliability,
work
and
infrastructure,
and
a
lot
of
shared
re-prioritization
across
product
development
and
infrastructure.
A
A
I
want
to
thank
you
for
that
and
then
also,
if
you're,
able
to
look
at
seven
and
eight
in
the
in
the
deck
we're
presenting
some
information
around
how
we're
using
what
we
call
tamland,
which
is
forecasting
around
giving
us
awareness
of
where
we
may
have
future
capacity
problems
and
an
iteration
that
we're
working
on
right
now
is
to
not
only
use
this
for
kind
of
the
weekly
views
that
we
get
but
also
incorporate
it
into
a
kpi
because
on
our
the
infrastructure,
kpis
oddly
missing
from
the
long
list
of
kpis,
we
have
is
something
that
deals
with
capacity,
and
that
certainly
is
a
lot
of
the
work
that
we
do
in
infrastructure.
A
So
we're
working
on
iterating
that
into
a
single
kpi.
So
there's
questions
on
that.
Let's
see
it's
like
five
kyle
you've
got
a
question.
E
Yeah,
sorry
that
I'm
just
turned
blurry
all
of
a
sudden.
I
I
just
want
to
shout
out
thanks
for
tracking
deployment
blockers
and
the
epic,
I
link
to
and
curious
where
you
see
the
greatest
opportunities
to
reboot
reduce
blockers
based
on
what
you're,
seeing.
F
Thank
you
for
asking,
and
thanks
for
your
help
with
us,
dr
kyle,
so
I
think
there
are
two
areas
we're
really
focusing
on
around
deployments.
One
is
like,
in
order
to
for
deployments
to
be
more
frequent,
which
is
really
the
goal,
so
one
is
faster
deployments
which
we
are
working
on
by
introducing
a
deployment
slo,
so
we
can
actually
keep
track
of
how
long
the
deployment
pipe
pipelines
take.
Are
there
any
patterns
in
that?
F
Do
we
see
delays
at
certain
times
and
we
can
actually
improve
on
those
and
the
other
one
is
around
recovery
from
incidents.
So
when
we
do
hit
a
blocker
like
tests
fail
or
we
roll
out
something
to
canary
a
production
that
has
unintended
side
effects,
then
the
time
to
recover
from
that
is
incredibly
long.
Part
of
the
is
because
the
pipeline
is
long,
but
there's
also
getting
the
right
help
getting
people
to
approve
things
so
we're
working
on
that
a
bit
with
rollbacks.
F
A
B
B
A
Well,
thank
you
for
that
anoop,
and
I
mean
I've
had
a
similar
feeling
as
far
as
the
effort
that
has
gone
into
this-
and
I
think
I
I
do
want
to
point
out
if,
if
people
are
unfamiliar
with
kind
of
like
some
of
the
changes
that
have
gone
into
some
of
the
product
theme
for
this
year
of
sas
first,
there
really
has
been
a
significant
change
in
like
planning
going
forward
of
of
implementing
features
with
the
intent
of
them
going
into
sas
first
and
being
ready
to
take
on
the
the
scale
of
sas,
which
of
course
then
does
benefit
our
self-managed
customers
as
well.
A
A
There
aren't
additional
questions.
I
think
the
the
last
slide,
if
you
have
a
second
to
look
at,
is
number
12
any
help
that
you
can
provide.
We
are
trying
to
recruit
more
people
to
the
team.
We
definitely
need
some
additional
team
members.
We
have
open
recs
for
site
reliability,
engineers
for
database
reliability,
engineers
and
for
engineering
managers,
so
there
are
open
recs
for
all
of
those.
If
there's
anyone
in
your
network
that
you
know
or
can
help
refer
anyone
that
would
be
greatly.