►
From YouTube: Infrastructure Group Conversation
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
My
apologies
so
welcome
again
to
the
infrastructure
group
conversation.
Another
chat
message
perfect
and
that's
it.
This
is
the
first
one
for
2019
for
us,
so
we're
excited
to
share
the
work
that
we're
focusing
on
this
quarter.
I'll
talk
a
little
bit
about
focus
on
strategy.
I
will
also
speak
about
how
we're
growing
the
team
then
go
back
and
talk
about
how
we're,
hopefully
improving
the
communications
for
infrastructure
and
how
we're
managing
the
workload
and
finally
I'll
get
some
highlights
on
this
quarter
so
PRS.
A
So
in
terms
of
focusing
strategy,
this
is
a
another
iteration
of
a
slide
that
you've
probably
seen
before,
where
we
just
want
to
make
gitlab
calm
rock-solid.
We
want
to
make
sure
that
it's
ready
for
mission,
critical
customer
workloads,
and
so
that
entails
ensuring
that
the
the
work
that
we
do
on
the
site,
the
work
that
we
do
on
github
comm
is
as
predictable
as
possible
when
it
was
just
the
sre
teams,
we
were
really
focused
on
essentially
making
sure
that
we
failed
as
little
as
possible.
A
That's
the
mean
time
between
failures
go
into
infinity
and
that
if
we
fail,
we
could
recover
as
quickly
as
possible.
Now
we're
layering
the
delivery
team,
who
is
tasked
with
implementing
CI
CD
for
get
low
calm
and
essentially
how
we
develop
can't
give
lap,
which
is
a
key
component
for
us
to
be
able
to
essentially
achieve
the
reliability
goals
of
fail
as
little
as
possible
that
recover
as
quickly
as
possible.
When
we
do
fail
in
terms
of
growing
the
infrastructure
team,
you
have
two
new
members
that
join
in
January
Casey
and
Anthony
Casey's.
A
A
A
We
also
adding
new
roles
to
infrastructure.
The
environment
is,
is
growing,
the
complexity
of
the
environment
is
growing,
and
that
also
means
that
we're
consuming
more
resources
and
more
money.
So
we
want
to
make
sure
that
we
optimize
those
those
two.
So
we've
added
an
operation
analyst.
This
person
is
focused
on
resource
utilization
and
forecasting
and
has
to
understand
financial
models,
and
it's
also
responsible
for
the
management
of
the
poorer
mental
KPIs.
How
many
points
you
know?
A
Where's
our
speed
of
work,
service
levels
and
our
budgets
additionally,
we're
adding
some
back-end
engineering
to
the
team,
there's
a
lot
of
work
that
happens
in
engineering
that
is
geared
towards
towards
our
product
features,
and
there
is
a
significant
amount
of
work
that
is
geared
towards
reliability.
We
want
to
make
sure
we
have
some
internal
resources.
They
are
solely
focusing
on
optimization
of
resources
of
infrastructure
resources
from
an
application
point
of
view,
so
these
two
positions
will
report
to
Marin,
but
they
will
be
separate
from
the
livery.
A
A
We're
still
seeing
the
title
slide
still
see
in
the
title
site:
okay,
all
right
now,
I'll
speak
about
communications
and
workload
management.
We
need
more
to
essentially
make
sure
that
you
manage
expectations
better
and
to
do
that.
We're
trying
to
work
on
how
we
communicate
with
the
rest
of
the
company.
So
we
want
to
make
sure
that
people
can
find
the
information
they
need
about
infrastructure
and
we
want
to
make
sure
that
we
have
some
guarantee
channels.
You
know
there
is
always
slack,
but
there
are
some
other
ways
in
which
we
communicate
it.
A
Synchronously
don't
require
slack.
So
in
terms
of
documents,
we've
been
working
on
these
these
two
types
of
documents,
blueprints
and
design
blueprints,
essentially
scope
problems
and
provide
options
on
how
we
might
solve
a
problem,
and
they
provide
some
background
on
the
work
that
we
may
have
done
on
this
problem
already
and
then
those
will
actually
deal
at
a
sign
document,
which
is
how
we
intend
so
to
actually
solve
the
problem
that
we
scoped
on
the
blueprint
they're,
not
complex
or
long
documents.
A
They're,
not
90
pates,
essentially
super
detail
documents,
but
they
do
intend
to
set
the
path
that
we
intend
to
follow
to
solve.
Some
of
the
difficult
problems
were
working
on.
I
also
wanted
to
talk
about,
for
weekly
meetings
are
happening
in
infrastructure.
The
first
one
is
the
infrastructure
call
which
we
rebound
about
two
or
three
weeks
ago.
We
felt
we
needed
to
give
it
a
slightly
different
angle.
Now
that
things
were
more
stable,
you'll
hear
the
usual
announcements,
but
we're
also
going
to
announce
and
discuss
some
of
the
updates.
A
The
important
updates
that
we're
doing
to
the
handbook
on
any
being
given
week,
production
event,
discussions
in
terms
of
incidents,
changes
and
deltas,
and
then
the
usual
open
agenda
for
folks
to
add
items
that
they
would
like
to
discuss.
The
DNA
meaning
is
a
new
meeting.
We
started
this
meeting
two
weeks
ago.
Dna
stands
for
the
sign
and
animation
and
is
a
purely
technical
meaning.
A
The
nutrients
and
the
signs
are
the
input
into
this
meeting.
So
once
we've
written
these
some
of
these
documents,
we
bring
them
to
the
meeting
so
that
we
have
essentially
what
to
discuss
when
we're
seeking
feedback
from
teammates.
Obviously,
some
of
this
happens
during
the
EMR
conversation,
but
sometimes
it's
just
good
to
have
three
or
four
people
in
real
time
be
talking
and
discussing
technical
technical
problems.
A
A
Every
every
team
in
infrastructure
has
their
own
staff,
meaning
they
tend
to
happen
early
in
the
week,
so
that
the
team
can
organize
itself
for
the
week
and
then
managers
also
meet
on
a
weekly
basis
to
essentially
discuss
items
at
the
infrastructure
level.
I
did
want
to
mention
for
the
DNA
meeting.
Currently,
the
invitation
only
includes
infrastructure
staff,
but
anyone
is
welcome
in
this
meeting.
As
long
as
you
want
to
hear
and
participating
technical
conversations,
the
meeting
is
open
for
anyone
who
wants
to
join
and
we
we
welcome
anyone
who
can
contribute
to
these
conversations.
A
The
agenda
is
purposed,
so
if
there's
some
area
that
you're
familiar
with
and
want
to
join
the
conversation
by
all
means
do
so
in
terms
of
workload
management
again,
another
iteration
and
how
we
use
okrs,
we're
now
tracking
them
as
epics
and
gift
of
itself
and
one
of
the
items
you
know.
I
spoke
about
blueprints.
All
of
our
key
results
now
have
blueprints,
so
we
do
write
some
documents
for
the
kr
s
to
make
sure
that
we're
scoping
them
correctly
and
that
we
know
what
we
intend
to
deliver.
A
Chaos
are
supposed
to
be
these
very
measurable
things,
we're
still
in
our
infancy
on
how
we
use
them,
so
we
tend
to
have
them
very
project
focus
we
intend
to
iterate
and
improve
on
that.
But
for
now
we
do
feel
that
having
this
Brookins
helped
us
to
scope.
What
the
K
ARS
need
to
you.
I
also
wanted
to
highlight
infrastructure
as
a
whole
works
with
milestones.
Every
team
in
infrastructure
has
their
own
milestone,
and
these
have
a
we
can
cadence.
A
A
Finally,
there's
the
site
project
called
blocker.
It
essentially
is
a
tool
that
we're
writing
to
traverse
the
epochs
that
we're
creating.
Now
that
we
have
parent-child
epochs,
essentially,
objectives
have
key
results,
key
results
have
epochs
and
then
those
epochs
contain
issues.
So
the
idea
is
that
from
a
given
master,
okay
are
we
can
go
all
the
way
down
to
the
issues
and
through
issue
its,
we
can
calculate
how
we're
evolving
through
the
quarter.
So
there
is
some
more
more
data
on
the
handbook
about
this.
A
Finally,
just
some
highlights
on
the
work
that
we're
doing
in
this
quarter
andrew
is
focusing
on
distributed
pacing
and
Puma,
which
are
quite
exciting.
To
have
this
work
finally
happened:
delivery
has
their
work
cut
up
for
them
because
they
intend
to
merge
the
Cee
and
eco
basis.
Marion
has
written
an
amazing
design
document
on
how
they
intend
to
deliver
this
and
they're
also
doing
some
improvements
to
improve
our
ability
to
roll
back
changes
that
go
sideways.
A
Anthony's
reliability
team
is
focused
on
our
budgets
and
creating
testing
environments
are
more
closely
aligned
with
the
scale
of
production.
Dave's
reliability
team
is
working
on
Foundation,
also
subsystems
such
as
kubernetes
and
storage.
We
intend
to
avoid
CFS
to
use
some
of
the
snapshot
and
cloning
features
to
provide
higher
availability
and
these
die
directly
into
the
testing
environments.
This
is
how
we
intend
to
to
provide
production
scale,
data
at
a
reasonable
cost
to
the
testing
environments
and,
finally,
who
says
team
is
focused
on
improving
database
operations,
vacuuming
and
packing
and
stuff.