►
From YouTube: 2021 06 24 Sharding Timeline Discussion
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).
B
A
A
A
Okay,
sorry
pour
everybody
together.
I
want
to
make
sure
that
the
plan
represent
the
team
feels
comfortable
with
that.
I
don't
want
to
speak
for
the
team
without
acknowledging
team
or
get
a
you
know,
approval
or
agreement
from
the
team.
So
that's
why
I
put
everybody,
but
if
you
have
other
urgencies,
please
feel
free
to
drop
any
time.
A
So
here's
the
follow
up
items.
I
called
out
here
after
the
all
the
sync
discussions
yesterday,
so
first
of
all
the
context
of
why
initially
we
were
asked
to
develop
a
plan
for
october.
So
that's
the
we
discovered
the
context
here
in
the
stand
up
yesterday.
So
if
you
haven't
read
that
please
write
that
read
that
really
quickly,
so
the
that's
the
background.
A
Why
initially
we
were
asked
for
a
glance
for
october,
then
I
talked
to
many
people
yesterday
and
looked
through
our
recordings
and
notes.
So
today
there
will
be
a
meeting
in
the
afternoon
that
christopher
eric,
steve,
lloyd
will
be
hell.
Will
help
will
hold
to
discuss
the
need
by
date
of
sharding
from
a
business
perspective,
but
we
we
do
need
to
provide
a
sharing
plan
to
give
a
rough
idea
how
this
project
will
go
from
now.
A
So
I
I
drafted
this
this
plan.
Hopefully
everybody
had
read
through
it
had
you
know,
had
read
through
it
with
proposal
the
just
the
highlight
the
proposal
basically
asked
for
three
more
sres
and
two
more
bes
to
add
to
the
team
or
to
add
to
the
project
by
in
a
week
I
mean
as
soon
as
possible.
Of
course,
we
already
have
work
to
do.
A
We
know
that
there
are
work
to
do
right
now,
so
so
I'm
giving
it
a
week,
but
we'll
see
how
fast
we
can
assemble
those
those
team
members
if
it
gets
approved
this
first
of
all,
I
would
like
to
ask
for
your
opinions.
Does
this
that
makes
sense?
A
A
Does
that
sound
close
to
everybody's
estimation
or
is
too
bold
or
is
too
conservative.
C
So
I
think
I
think
the
first
thing
is
to
thank
you
for
taking
the
time
to
do
this.
I
think
my
we
should
talk
about
it
a
little
bit.
I
think
the
first
thing
is
if
the
initial
like
haste
was
based
on
this
october
timeline
right
then,
and
the
october
timeline
is
no
longer
valid,
we
have
a
different
timeline
now.
C
Why
like
do?
We
still
have
to
you
know
make
these
make
this
go
at
three
times
the
the
pace
as
initially
planned.
That
feels
like
I'm,
not
sure
if
that's
even
needed,
so
that's
sort
of
my
first
question.
C
The
second
thing
is
that
I
I
have
quite
a
few
concerns
regarding
sort
of
this
adding
more
people
and
it
will
magically
go
faster,
but
I
think
it
is
probably
going
to
be
more
productive
to
outline
what
we've
done,
especially
for
the
sres
and
when
and
I
think,
the
pattern
that
was
established
by
craig
in
sort
of
hey.
We
need
a
like
a
stable
counterpart,
because
we
have
questions
right.
Can
you
help
us
with?
C
That
is
maybe
a
little
bit
like
easier
than
just
having
three
people
from
from
next
week,
and
it's
also
like
I
I'm
not
sure
if
we
can
parallelize
all
of
these
things
as
neatly
as
we
as
we
make
it
out
here
right,
but
that
is
something
for
for
for
others
to
contribute
to
as
well.
So
this
feels
very
optimistic
to
me.
It
feels
like
we
can,
just
like
add
more
people
and
reduce
the
the
timeline
significantly.
C
I
do
think
some
things
can
be
parallelized.
For
example,
we
could
stand
up
a
post
with
cluster
in
production.
If
that
was
a
thing,
I'm
not
sure,
but
I'm
that
we've
just
started
working
on
this
in
earnest
really.
So
there
are
like
many
unknowns
in
it,
and
I
think
that
is
my
concern
that
if
we
give
the
impression
that
if
we
just
add
more
it'll,
you
know
linearly
get
faster,
but
I'm
not
sure
about
that.
A
Let's
go
through
each
of
your
questions,
the
first
one
why?
Why?
Because
even
now
the
tipping
point
is
projected
to
be
next
to
march,
why
do
we
still
need
to
rush
to
accelerate?
But
I
think
the
first
bullet?
That's
the
context
why
we
need.
There
is
a
kind
of
urgency
and
I
think
that's
what
eric
explained.
I
major
concern
is
probably
due
to
some
unknown
unexpected
events
like
if
some
competitor,
just
the
eol
their
product,
we
may
see
a
10x
increase
on
our
load.
C
Yeah,
so
I
I
think
the
first
like
to
respond
here.
I
I'm
actually
not
sure
the
report
says
we're
going
to
tip
over
in
nine
months
like
the
way
I
interpret
the
language
is,
it
says,
like
we
have
confidence
that
this
will
not
happen
in
nine
months
and
after
this
you
know
it
doesn't
say
like
on
march
we're
going
to
like
fall
over.
I
think
that's
that's
not
the
case
right.
As
far
as
I
I
know,
I
think
that's
slightly
different.
A
Yeah
fabian,
I
understand
your
concern,
but
the
information
we
received
from
the
executive
leaders,
especially
eric,
is
let's
accelerate
the
steeping
point.
It's
good
to
have
to
see
that
we
have
still
have
headroom
based
on
regular
price
or
regular
increase
of
the
system,
but
let's
accelerate.
I
think
that's
the
that's.
What
eric.
A
Yeah,
okay,
the
second
question
you
had
is:
can
you
just
repeat
it.
C
Briefly,
I
think
my
question
is
this:
to
me:
reads
like
a
proposal
where
the
like
ask
for
acceleration
is
primarily
achieved
by
adding
more
people,
and
I
think
in
some
areas
you
know
that
may
not
actually
lead
to
the
desired
acceleration
and
I
think
the
other.
The
other
thing
is
that
for
specifically
for
the
sres,
I
think
this
is
also
voiced
by
marin.
C
C
Can
you
help
us
get
this
done
faster
right?
It's
going
to
be
maybe
more
more
useful,
but
it
still
feels
to
me
a
little
bit
sort
of
optimistic
in,
like
I
think
the
team
is
already
doing
this
as
fast
as
they
can,
but
nothing,
I'm
wondering
where
like
if
this
is
going
to
accelerate
it
significantly.
D
Yeah,
I
would
out
there
sort
of
out
of
the
in
the
dock,
but
I
think
if
we
add
the
proposed
number
of
people
was
a
total
of
like
eight
or
something,
oh
sorry,
five.
D
So
two
back
and
three
s
orbes.
I
think
first.
D
You
know
we
might
occasionally
need
some
test
database
and
stuff,
but
you
don't
need
three
people
dedicated.
You
know
five
days
a
week,
just
kind
of
sitting
around
doing
nothing
and
when
it
comes
to
back
end,
I
I
think
we're
at
a
point
where
we
already
have
quite
a
few
people.
I
think
it
was
at
five
or
six
in
total,
adding
more.
D
I
think
at
this
point
will
actually
make
us
less
productive,
because
I
found,
for
example
like
when
I
look
at
the
shutting
issues
to
do
it's
actually
difficult
for
me
to
pick
out
where
to
start
because
the
easier
things
like
the
low
balancer
and
that's
what
I
think-
people
already
looking
into
that
and
a
lot
of
that
work
overlaps.
So
you
might
have
saved
three
issues
but
they're
all
kind
of
related,
and
so
you
say
thong
does
two
of
them.
D
When
I
come
in
and
do
the
third
that
might
be
the
sort
of
synchronization
issues
where
I
go
off
doing
things
one
way
and
he's
like
oh
that
actually
collides
with
them
with
what
I'm
doing
and
so
theoretically,
if
you
had
all
the
work
planned
out,
you
know
you
could
do
all
of
that
individually
in
parallel
and
yes,
adding
more
people
would
help,
but
we're
not.
At
that
point,
I
think
we're
at
a
point
where
the
the
opposite
happens.
D
We
have
more
people,
we
become
less
productive
as
there's
more
synchronization
needed
more
more
meetings,
more
time
zone
issues.
Basically,
I
think
in
theory,
even
five
is
probably
stretching
it
like.
Assuming
again,
we
knew
what
had
to
be
done.
C
And
I
think
one
thing
here
that
I
like
this
is
my
personal
belief,
so
I
may
be
wrong.
It's
like,
I
don't
think
we
are
at
the
point.
We
could
sit
down
and
make
a
six
month
delivery
plan
with
all
of
the
individual
tasks,
because
I
think
there
is
just
a
lot
that
is
still
unknown
when
people
are
figuring
out
how
to
do
it,
and
so
I
think
this
is
the.
A
E
E
I
think
we
have
to
like
a
lot
of
let's
say,
low
hanging
fruits
that
could
be
done
by
others
and
like
it's,
I
think,
would
also
apply
for
a
series
and
also
for
the
bucket
engineers
right
now.
We
just
have
so
many
fundamental
things
that
we
need
to
like
figure
out
how
they're
gonna
feel
that,
like
we
simply
have
too
many
meetings
about
all
of
these
fundamental
things
and
like
too
little
focus
on
actually
doing
that,
so
adding
more
people
will
create
even
more
meetings
and
even
less
focus.
E
So
my
perception
of
time
is
like.
I
think
your
plan
is
great,
but
not
next
week,
like
let's
say
like
in
one
month
for
one
or
one
and
a
half
month
from
now,
and
actually
have
like
a
lot
of
these
fundamental
pieces
in
place,
and
we
actually
have
low
hanging
fruits
to
solve,
where
we
can
focus
on
like
on
the
main,
like
goal,
which
is
like
moving
all
the
tables
but
they're
gonna,
be
like,
let's
say,
fixing
some
features,
creating
some
some
follow-ups
things.
E
That's
basically,
I
think,
would
be
to
some
extent
like
pretty
pretty
isolated
and
pretty
well
defined,
because,
like
for
us
like
to
use
these
extra
people,
we
need
to
have
things
that
are
certain
isolated
and
well-defined,
because,
like
the
primary
goal
that
I
see
there
is
like
we
want
to
ensure
that
it
doesn't
eat.
Like
a
lot
of
of
our
focus
on
like
keeping
extra
team
members
occupied
and
right
now,
we
are
still
in
this
guys
that,
like
we
still
are
figuring
out
these
fundamental
things.
E
So
that's
I
think
my
perception
that,
like
right
now
like
we
will
just
simply
slow
down
by
adding
more
people,
it
will
not
make
it
faster.
We
can
make
it
faster
like
when
we
have
these
fundamental
pieces
in
place,
which
is
like
we
migrate
at
the
first
table.
We
have
some
general
understanding
about
how
to
perform
migration.
We
know
like
a
general
pieces
needed
for
like
infrastructure
steps.
E
We
actually
have
some
infrastructure
for
many
databases,
some
initial
support
for
the
load,
balancing
we
actually
at
the
moment
that
we
are
strike
dissecting,
the
poc
for
the
ci.
Once
we
start
dissecting
poc
for
this
yeah
they're
gonna
be
like
a
lot
of
low
hanging
fruits
that
could
could
be
picked
by
other
people.
E
A
Okay,
what
I'm
hearing
is,
oh
janice,
you
have
something
to
say.
F
We
may
not
need
the
backend
engineers,
but
we
may
need
someone
to
help
us
on
the
on
the
migration
part.
So,
for
example,
in
order
to
do
the
to
perform
the
upgrade
of
postgres
11
to
postgres
12,
a
big
part
of
the
sre
team
was
working
on
how
to
do
that
and
they
had
a
plan
on
how
to
do
logical,
replication
and
move
the
tables
and
et
cetera,
et
cetera.
F
F
From
my
perspective,
I
think
that
it
will
be
great
if
we
had
more
confidence
on
that
migration
working
and
also,
even
though
we
are,
we
know
about
databases
and
it's
joric
here
and
the
adam,
and
we
know
our
stuff
on
higher
level.
There
are
a
lot
of
details
on
the
low
level
like,
for
example,
the
patron
suites
and
other
things
that
sr.
F
And
maybe
having
somebody
embedded
from
the
get-go
will
help
us
also
define
what
we
are
going
to
do
and
go
go
towards
the
correct
path
so,
for
example,
dylan
and
adam
already
work
on
how
to
do
the
migration.
We
have
some
ideas.
F
E
F
E
Like
like,
we
need
like
we
need
a
survey
to
help
us
like
with
all
these
infrastructure
stuff
like
to
figure
out
all
the
dependencies
steps
like
work,
exactly
what
is
feasible.
What
is
not
visible
ask
for
the
migration,
and
I
I
think
this
was
like
our
primary
ask
for
the
last
few
days
and
I
think
it's
to
some
extent
for
fear
to
like
stable
counterpart.
But
then
the
question
is
like
how
much
capacity?
E
A
So,
okay,
I'm
hearing
what
I'm
hearing
is
any
all
five
people
now
will
not
help
too
much
will
not
have
a
lot,
maybe
a
drag.
Even
so
I
I
think.
Maybe
we
can
optimize
that
plan
and-
and
also
I
heard
there-
is
something
that
migration
and
I
say
on
the
sre
part
can
be
worked
on
right
now.
A
So
maybe
I
was
I
mean,
I'm
I'm
thinking
proposing
a
pro
a
plan
to
add
sre,
one
sre
now
to
work
on
the
known
scenes
that
we
already
know,
and
then
the
two
sre
and
to
be
is
later
lagging
up
august.
What
I'm
thinking
here
is
also
to
address
marin's
question.
I'm
going
to
reply
the
thread
I
shared
the
select
thread
there
discussion
there
in
our
doc
here.
So
basically,
I
think
we
need
to
change
the
mentality
that
charting
group
will
articulate
everything
for
every
group.
A
Then
they
start
work
on.
That's
not
going
to
work,
that's
not
going
to
scale.
The
thing
is:
sharding
group
identifies
what
we
need
to
work
on,
describe
the
scenario
as
best
as
we
can,
then
those
responsible
work,
those
stakeholders
or
the
experts
will
figure
out
exactly
what
needs
to
happen.
That's
the,
I
think,
that's
the
right
mode.
That's
why
I'm
asking
for
dedicated
sre
to
discover
and
explore
together
with
us
to
find
the
solutions
we
need
to
find
the
things
we
need
to
build
and
to
find
the
things
we
need
to
run
or
drive
test.
A
So
that's
my
mentality,
where
I
came
from
that's
why
I'm
asking
for
dedicated
sre
instead
of
this
shutting
group
to
plot
out
everything
in
detail.
What
needs
to
be
done
so
I
think
what
marian
is
asking
is
tell
me
what
we
need
to
do
we'll.
Do
it?
That's
exactly
what
dylan
was
concerned
in
that
slex
thread.
We
want
you.
We
know
this
needs
to
be
done.
A
A
We
don't
have
access
to
the
production
environment
and
we,
we
probably
don't,
have
knowledge
in
some
other
product
feature
domains.
So
that's
where
it
came
from.
So
I
think
we
need
dedicated
sre,
but
we
can
stage
it
like
asking
for
one
now
and
then
two
more
later
or
even
more
later.
But
I
need
your
opinion
here
to
see
to
say
that
when
we
needed
extra
sres,
but
it
feels
like
we
need
one
now,
because
we
know
there
are
something
to
do
already.
B
Do
we
have
specifics
on
what
we
are
asking
the
early
sre
involvement
to
be
and
answer
camille's
question
right
now?
It's
it's
part
time
jose
right
because
he's
the
one
dbre
until
we
there's
another
one's
going
to
start
in
a
month
or
two
but
jose
is
not
dedicated.
I
have
an
outstanding
question
to
steve
lloyd
about.
Can
we
use
nick's
time
because
there
is
an
expanded
contract
with
next
time,
but
steve
has
other
considerations
on
a
completely
understaffed,
sre
department
that
will
be
discussed
later
on
today.
B
That's
the
opportunity
cost
thread
that
was
brought
up,
but
back
to
the
first
question,
are
there
specific
things
that
we
can
list
out
that
we
could
have
sre
working
on
right
now?
I
know
there's
the
environment
that
we
need
set
up
so
that
we
can
actually
start
testing
the
migrations
and
testing
replication,
but
are
there
other
items
that
we
can
list
out
and
say
yep
we
need
sre
focus
and
here
are
the
things
that
we
would
like
them
to
focus
on
and
work
with
us
on.
E
This
is
something
that
I
think
on
the
chat
and-
and
there
are
these
are
except
like
migration
stuff,
which
is
like
these
are,
like,
I
think,
like
general
old
mice
like
we
need
to
create
database
cluster,
we
need
to
configure
that
somehow
then
I
guess,
like
the
next
steps
we
need
to
migrate,
we
need
to
monitor
that
we
need
to
figure
out
what
is
the
procedure
of
like
deploying
all
of
that
to
the
production.
E
So
I
I
think,
like
these
are
really
like
the
issues
to
answer
like
how
it
would
be
done
like
someone
would
have
to
go
and
like
create
some
kind
of
outline
of
the
dependency
steps
to
do
it
start
doing
that.
Maybe,
on
the
let's
say,
on
the
side,
because
by
creating
database,
cluster
is
needed
for
them
testing
migration
stuff
right.
So
this
would
be
like
the
next
step
I
like
to
concur
on
stuff,
but.
B
Stepping
on
each
other,
so
this
is
the
epic
that
camille
was
referencing.
E
Various
also
and
and
and
we
have
also
this
migration
plan
for
moving
sidetables
on
github.com,
which
is
like,
I
think
one
epic
is
like,
like
figuring
out
figuring
out
like
how
to
deal
like
this
infrastructure
aspect.
E
The
second
one
is
like
how
we
can
execute
migration
plan,
because
we're
gonna
have
to
execute
that
on
the
on
the
on
some
infrastructure
on
github.com,
so
srf
help
would
be
like
to
help
with
this
infrastructure,
rollout
new
nodes
and
figuring
out
how
we
can
actually
build
like
this
migration
plan
test
that
tried
many
times
using
that
infrastructure.
This
would
be,
I
think,
my
primary
goals
for
the
srm
and,
like
this
initial
survey,
would
be
like
on
figuring
out.
E
I
guess
dependencies
roughly
steps
figuring
out,
maybe
some
some
like
how
many
srs
we
would
need
then
like
to
help
out
with
this
initiatives,
because
there
will
be
more
work
related
because
we
will
be
at
some
point
have
to
do
it
on
staging
then
kind
of
start
working
on
the
production
we
have
to
like
migrate
it
on
staging
as
well
following
our
migration
plan,
but
we
need
to
also
might
be
the
migration
plan,
and
this
has
to
be
working
with
the
sr
and
then
it's
also
like
aspect
of
like
the
timelines
doing
windows
for
these
migrations,
and
all
of
these
like
like
how
you
can
actually
run
that
on
github.com,
which
is
like
the
later
stuff.
E
But
I
think
all
of
that
that
we
figure
out
needs
to
be
like
executed,
probably
a
few
times
on
staging.
So
this
would
be
like
work
for
the
sr.
E
Later
after
we
figure
out
the
steps
dependencies,
people,
machines,
technologies,
configurations,
run
books,
monitoring,
graphing,
alerting
spreading
the
knowledge
about
the
new
other
databases,
cloning,
migrating
data
measuring
the
impact
validating
all
of
that
things
that
are
really
like
infrastructure
related.
A
Yeah,
so
there
are
definitely
a
lot
of
things
to
explore
and
discover.
I
believe
we
have
a
lot
of
topics
we
can
just
describe
and
sre
can
help
you
leverage
their
expertise
to
discover
that
to
describe
articulate
all
the
works
necessary
along
together
with
us.
We
need
to
collaborate
closely
collaborate
because
those
tasks
may
have
dependencies
on
what
the
development
team
can
deliver.
C
Yeah,
I
need
to
drop
some,
but
I
think
one
thing
that
would
be
important
for
me
to
to
convey
as
well
is
that
I
think
it
is
my
understanding
that
the
team,
as
it
is,
works
on
delivering
the
cid
composition
as
fast
as
possible
right,
it's
that's
their
main
priority
right
now
and
so
the
the
plans
that
we
we
have
presented.
C
C
Okay,
how
can
we
make
sure
that
we
don't
get
blocked
right,
because
maybe
we
don't
actually
have
sres
at
the
right
point
in
time
or
enough
support,
but
I
think
what
is
not
going
to
accelerate
it
is
to
try
and
reduce
the
the
delivery
time
by
50
right
by
adding
like
more
complexity
and
more
things
on
top
of
it.
I
think
that
will
not
necessarily
help.
So
I
think
it's
more
of
a
question:
it's
like.
C
Not
the
other
way
around
of
saying:
please
deliver
it
in
50
of
the
time,
because
I
don't
think
that
will
necessarily
lead
to
an
acceleration,
because
I
think
we
are
already
working
at
it
at
pace,
and
I
think
that
is-
and
I
trust
trust
the
team
to
with
the
expertise
to
to
make
those
decisions
in
a
way
that
that
makes
sense
and
to
articulate
when
there
is
a
blocker,
but
like
with
this
one
sre
where
people
say
like
hey,
we
need
we
need
someone.
C
A
So
yeah,
I'm
honestly
in
the
same
line
with
you,
so
we
need
some
sre
now,
not
all
of
them.
We
don't
want
srs,
free
spinning
or
what
they
are
working
on,
has
a
heavy
dependency
on
what
we
have
not
delivered
yet
so
we
don't
want
them
to
be
free,
spinning
yeah,
I'm
in
line
with
you,
so
we
need
to
carefully
develop
the
plan
when
we
need
how
many
sre-
and
I
can
factor
that
in
the
plan
to
present
to
the
leaders
say
this
is
a
schedule.
A
So
does
that
make
sense
that
we
asked
what
dedicated
sre
in
july,
I
mean
basically
right
now
then
adding
two
more
sres
in
august,
or
we
want
one
more
in
august
and
one
more
in
september.
C
If,
if
I
understood
the
team
correctly,
one
sre
now
with
support
makes
sense,
I'm
not
sure
we
know
exactly
the
time
when
we
would
need
more
support,
because
I
think
that
depends
a
little
bit
on
the
development,
but
it
I
foresee
this
having
to
happen.
You
know
in
the
next
couple
of
months,
or
so
maybe
a
little
bit
after,
given
the
timeline
of
trying
to
get
this
into
production
by
the
end
of
the
year
or
the
end
of
q4.
E
E
We
might
be
like
approach
that,
like
with
like
some
kind
of
wiggle
room
like
we
know
that
we
need
one
sre
right
now
for
sure
we
know
that
it's
very
likely
that
we
need
another
serve
in
august,
which
is
let's
say
for
75,
and
we
may
need
another
sre
later,
but
we
don't
know
if
we
need
another
sre
later
by
august,
because
we
see
like
how
much
work
is
there
and
like,
for
example,
also
will
also
tell
us
so,
let's
say
75
percent
of
on
adding
another
person
in
august,
but
50
percent
confidence
that
we
need
another
person,
let's
say
the
september
and
and
then
like
the
closer
to
that
diet.
E
We
gonna
know
with
more
confidence
if
we
need
or
don't
need,
but
like
kind
of
like
anticipating
that
this
is
something
that
may
be
needed,
and
maybe
this
is
our
messaging
like
that.
We
know
that
this
is
required.
There
is
like
big
chance
that
we're
gonna
need
more,
and
this
is
our
confidence
level
that
we
need
more
people
later.
A
I
like
that
idea,
but
I'm
concerned
about
how
sre
or
infrastructure
can
plan
that
for
us.
I
think
this
is
a
yeah.
This
is
a
planning
challenge
for
the
sre.
If
we
are
not
certain
about
our
ask
and
keep
it
floating
so
and
also.
I
also
want
to
add
that
this
is
our
probably
our
only
time
only
chance
to
tweak
this
plan
now.
This
is
a
just
a
a
deal.
We
probably
won't
have
another
opportunity
to
ask
for
a
deal,
so
we
need
to
carefully
build
this
plan.
A
B
Me,
let
me
I'm
sorry,
I'm
kind
of
doing
drive
by
here
different
proposal.
Instead
of
saying
we
need
one
two,
three
four,
however
many
sres
we
need,
can
we
just
outline
and
say
we're
gonna
need
dedicated,
sre
assistance
for
this
project
on
this
timeline,
and
that
might
be
too
specific,
say
we
need
sre
to
deploy
our
testing
environment
or
our
production
environment
to
align
with
our
timeline.
B
When
we
expect
development
to
be
done,
I
feel
like
we're
getting
pushback
from
sre
when
we're
saying
we
need
one
person,
but
we're
not
telling
them
what
the
work
is.
So
maybe
we
shift
positions
and
say
we
need
to
deliver
x
by
august.
Let's
say
we
need
to
deliver
to
production
by
august,
and
this
is
what
we
think
we
need
from
sre
and
then
let
them
contribute
to
the
plan
rather
than
us,
telling
them
how
many
people
we
need.
B
A
D
I
I
think
the
the
problem
with
that
approach
is
based
on
where
we
are
currently.
If
we
start
with
one
sre,
probably
through
the
next
month,
they're
not
going
to
be
doing
a
whole
lot
like
yes,
they
can
try
and
help
figure
out.
You
know
what
to
do,
but
that's
not
going
to
be
a
five-day
like
a
that's,
not
going
to
be
an
amount
of
work,
equaling,
five
work
days
a
week.
D
I,
I
will
say
there
at
least
historically,
if
you
tell
a
team
like
hey,
you
know
this
needs
to
be
done
with
me.
Some
point
in
time.
In
the
future,
my
experience
has
been
that
it
generally
gets
pushed
towards
the
end
of
whatever
deadline
you
give
and
then
it's
like.
Oh,
we,
you
know,
we
need
an
extra
this
many
weeks
months,
whatever
so
there's
this
sort
of
yeah
balance,
that's
difficult
to
find.
D
I
I
would
say
like
at
this
stage
it
is
very
difficult
to
give
sort
of
an
estimate
of
you
know
how
how
much
work
these
people
will
be
doing
and
if
we
even
need
them
in
the
next,
let's
say
two
to
four
weeks
other
than
maybe
you
know
get
some
feedback,
some
basic
stuff,
I
would
say
after
a
month
we
probably
know
more,
and
so
that's
where
I
think
what
might
be
a
better
approach
is,
instead
of
reserving
a
person
now
we
sort
of
have
them
on
standby
in
some
way,
where
you
say
hey,
you
know,
for
the
next
month,
you
know
continue
doing
whatever
you're
doing
just
expect
to
be
pulled
into
once.
D
You
know
every
now
and
then
and
then,
after
that
we
have
to
see
okay.
Now
that
we've
discovered
more,
we
know
more.
Maybe
we've
built
some
things,
and
now
we
can
really
see.
Okay,
do
we?
Actually,
you
know,
need
this
person
full
time.
Do
we
maybe
need
more
or
less
you
know,
etc?
I
think
in
the
current
states,
it's
just
too
early
to
just
say
how
much
and
who
we
need.
A
Okay,
I
hear
we
feel
we
probably
don't
have
a
very
clear
tasks
for
them
to
do
in
the
next
months.
A
I'll
think
about
it,
but
I
I
think
keeping
this
plan
kind
of
uncertain
is
not
going
to
work
for
sre
or
for
infrastructure.
Speaking
of
the
plan,
I
mean
we
just
gotta
get
one
chance
to
ask
for
what
we
need,
so
I
will
find
a
way
to
I
would
I
will
I'll
think
about
the
plan.
What
do
we
ask
at
this
point?
I
I
don't
think
the
the
you
know,
this
flexible
plan
will
work
out
with
as
the
executives
and
also
for
our
team.
G
I
think
the
challenge,
though,
is,
is
that
given
where
we're
at,
if
you
know,
and
the
problem
set
up
where,
where
you
know
this
is
a
critical
project
for
the
company.
We
all.
We
all
know
that
and
if
we
only
get
one
chance
to
ask
what
we
need
we're
just
going
to
over
rotate
on
what
we
need.
That's
the
only
possible
answer
right,
like
you
know
like
if
you're
saying
what
do
you
need
just
has
to
deliver
it
as
soon
as
pop.
G
A
Need
yeah,
I
can
do
this.
I
can
show
one
fix
the
plan,
but
also
ask
how
much
flexibility
we
have
in
the
future
to
ask
more
so
that
we
can
optimize
the
plan,
but
we
prepare
a
worst
case
plan
that
even
some
people
will
be
free,
spinning
or
have
no
clear
direction.
What
to
do
they
need
to
discover
themselves.
We
want
them
to
be
with
us,
that's
the
worst
case
scenario,
but
we
I
can
ask
for
how
much
flexibility
we
have
in
the
future.
G
You
know
we'll
give
you
the
soonest
and
the
most
number
of
people
we
think
we'll
need.
We
don't
know
for
sure
whether
we're
going
to
need
that
if
we
plan
for
that-
and
we
don't
end
up
needing
it,
then
it's
open.
It's
okay,
right,
like
we
just
have
more
capacity,
but
as
far
as
capacity
planning
for
downstream
teams,
sre
and
others,
it
might
be
helpful
to
know
what
we
think
like
the
high
water
mark
would
be,
and
then
we
can
plan
for
the
worst
case
scenario.
G
As
far
as
staffing
goes
right
and
just
communicate
that
that
you
know
you
know
we
can
call
the
people
in
when
we
need
them.
D
G
A
This
sounds
good.
Okay,
I
think
we
discussed
a
lot
about
this
more
people,
any
more
points
or
thoughts
to
share
here
before
we
move
on
to
the
next
bullet.
G
B
Impressions,
it's
supporting
information
to
buy
us
more
headroom,
but
they're
really
looking
for
us
to
deliver
this
solution.
This
is
the
one
big
bang
right
to
get
us
the
multiplier
in
headroom.
So,
while
it's
nice
and
supportive
data,
the
concerns
expressed
by
the
executive
branch
on
this
one
is
that
they
they
want
to
see
this
delivered.
B
E
Can
you
can
we
somehow,
like?
Let's
say,
maybe
it's
like
still
like
planning
about
maybe
like
going
away
from
the
quarter
school?
Let's
say
milestones
like
see
like
how
many
people
we
could
use
like
in
the
given
myself,
like
understanding
like
what
would
be
our
like.
The
primary
focus
is
like
even
milestones
because,
like
we
effectively
have
like
around
six
milestones,
we
like
to
to
figure
out.
E
So
maybe
if
we
could
like
go
mice
and
by
myself,
defining
like
the
key
key
result
that
we
are
looking
in
the
given
milestone
and
seeing
like
people
that
we
need
like
different
people,
let's
say
the
quantity
of
the
people
that
we
would
need
from
the
back
end
and
sre
because,
like
the
the
fact
is
like
that,
the
proportion
of
like
our
needs
gonna
be
shifting
on
the
mice.
The
closer
we
are
to
deploying
to
the
production,
we'll
be
more
dependent
on
the
infrastructure
side.
E
A
I
like
that
idea,
we
can
develop
that
but
depends
on
how
much
flexibility
we
can
you
know
timing
is
a
problem
right
now
today
we
need
this
plan
to
be
presented,
so
I
need
to
assemble
this
plan
today.
A
I
don't
think
we
have
enough
time
to
develop
that
plan
what
you
described,
but
if
we
do,
if
I
do
get
the
flexibility
from
the
executives,
then
we
can
work
on
that
later,
and
I
say,
maybe,
a
month
later,
we'll
have
a
much
clearer
picture
when
we
need
what
people
and
how
many,
but
today
we
just
need
a
plan
to.
B
E
E
And
now
we
actually
like
right
now,
yeah,
I
think,
before
people
working
on
that.
But
it's
like
our
second.
E
D
F
E
Okay,
right
now,
we
are
also
deploying
requests
right.
This
is
actually,
I
think,
our
focus
right
now
investigating.
E
E
I
think
this
is
the
moment
that
we
start
the
second
ci
plc
moving
some
tigers.
This
is
like
the
moment
for
that.
Adding
support
for
omnibus
cmg.
E
B
E
E
Defining
14.3,
I
think
this
is
the
bulk
we
work
on
disconnecting
choice,
ci,
which
is
like
the
features
affected.
F
F
B
F
F
E
I
think
this
is
might
be
like
the
headlines
that
I
can
feel
that
they
are
still
like
very
optimistic,
because,
like
any
like
anything
that
we
like
make
us,
let's
say
because
of
various
reasons
we
like
to
make
this
move,
but
these
are
the
things
that
I'm
known
that
we
need
to
do
at
some
point.
These
are
the
things
that
we
it's
part
of
our
epics.
E
So
it's
not
detailed
because,
like
you
cannot
really
like
start
working
on
them,
but
I
think
these
are
the
things
that
we
know
that
we
need
to
do
at
some
point.
E
I'm
actually
like,
I
think
for
me,
like
development
parts
like
I
have
pretty
good
perspective,
I
I
have
very
little
like
understanding
of
all
the
infrastructure
dependencies
that
we
will
need
to
solve,
after
basically,
I'm
like
starting
from
the
14
23,
which
is
like
what
how
we
kind
of
build
confidence
in
this
like
migration,
how
we
validate
that?
E
How
it
does
that,
how
we
test
like
the
resiliency
of
this
process.
So
there
is
like
a
lot
of
unknowns
in
in
that
part
on
the
infrastructure
side,
and
this
is
why
we
need
sre
because
they
have
their
way
of
working
on
this
stuff.
They
have
the
procedures,
documentation,
run
books
that
they
need
to
update,
so
maybe
continue
testing
your
application
first
payloads
recovery.
I
don't
know.
D
So
looking
at
the
the
table
would
it
help
perhaps
for
our
planning
if
we
move
things
like
gdk
and
such
to
like
the
very
end,
because
I'm
thinking
that
excuse
me
that
until
we've
sort
of
actually
made
the
split
so
to
speak,
I
think
the
only
people
who
would
be
interested
in
this
separate
database
setup
would
be
the
people
in
the
sharding
group
people
outside
of
that
wouldn't
really
be
affected
by
it
until
we
say
hey,
you
know
these
tables
are
now
going
to
live
in
this
separate
database.
D
D
What
we
can,
then,
maybe
do
is,
let's
say,
the
the
item
ci
joining,
for
example.
We
can
move
that
earlier
because
I
think,
if
we're
looking
at
the
sort
of
pressure
to
come
up
with
basically
a
sort
of
waterfall
style
plan
like
hey
by
this
point
in
time,
we
are
here
versus
the
amount
of
unknowns.
D
I
think
it
might
be
more
beneficial
if
we
start
with
kind
of
the
sort
of
inverse
we
say:
hey
all
the
the
actual
shipping
stuff
like
configuration
and
gdk,
etc.
We
do
that
last
we're
just
gonna.
Do
the
technical
things
and
then
figure
out.
Okay.
D
Can
we
do
this?
How
who
etc,
because.
D
What
we
might
find
is
we
extend
gdk,
all
nimbus,
etc,
and
two
months
later,
we
find
out
oh
shoot.
We
need
to
do
this
completely
different
thing.
E
E
It
may
be
a
slightly
inconvenience,
but
actually
guarding
this,
like
our
work
to
ensure
that
this
is
like
not
a
moving
target.
That's
that's
that's.
I
think
this
is
really
like
my
perception
why
you
should
try
to
embrace
like
gdk
early
and
like
try
to
like
say
I
mean
like
still.
We
move
tables,
it's
still
not
gonna
affect
anyone
still
remove
like
the
I
don't
know,
class
models
and
things
like
that.
Still
we
don't
configure
like
this
database.
E
Maybe
it's
like.
We
just
talked
to
the
speech
at
some
point.
We
just
can
keep
doing
database
for
the
development,
but
I
think,
like
the
second
aspect
like
is
this
all
disabled
joints
and
like
things
that
we
know
that
simply
will
not
work.
We
need
to
somehow
start
embracing
that
early
to
kind
of,
let's
say,
document
that
and
start
adding
places
in
a
code
that
we
know
that
it's
not
working
that
will
not
work
so.
D
So
so
I'm
basically,
I
think
what
I
would
propose
is
as
a
starting
point.
Like
we've
already
sort
of
decided,
hey
ci
is
going
to
be
the
thing
we
focus
on.
I
think
a
starting
point.
There,
perhaps
a
controversial
one,
is
that
we
say
from
this
point
forward.
You
cannot
add
new
columns
indexes
foreign
keys
whatever
to
the
ci
tables.
E
D
Right,
but
I
you
know
this,
this
is
why
I
mentioned
it
might
be
more
controversial
decision.
We
are
running
a
bit
out
of
time,
but
given
the
pressure
from
upstairs,
basically
and
given
the
complexity,
I
personally
would
say
this
warrants
a
freeze
where
you
say
ciao.
We
are
because
we're
looking
into
it
because
we're
gonna
move
it
around,
and
we
can't
do
that
when
it's
changing
we're
not
gonna,
allow
changing
it
now.
We
probably
can't
do
that
today,
so
we
need
a
slightly
more
clear
estimate
for
hey.
E
I'm
kind
of
thinking
that
problem
is
not
like
reason
schema.
The
problem
is
like
figuring
out
how
we
move
the
tables,
because,
as
soon
as
you
move
table,
you
need
to
ensure
the
consistency
between
tables
and,
like
I
think
in
general,
it
can
be
pretty
tricky
like
to
move
all
tables
at
once.
So
we
need
probably
to
do
it
like
in
like
a
few
other
time
and
then,
like
figuring
out
that,
like
this,
was
the
question
from
andreas
on
the
ci
decomposition
on
cmn
mars.
E
Many
databases
like
how
we
ensure,
like
the
schema
constituency
between
these
two
databases,
because
this
is
this-
is
like
becoming
a
major
problem
that
we
need
people
like
to
adhere
to
these,
like
guidelines
automatically.
So.
A
If
we
need
to
freeze
the
schema,
we
can
give
the
ci
team
a
heads-up.
I
think
one
month
should
work
when
released
ahead
should
work.
All
the
ci
team
is
working
on.
Now
is
basically
paying
off
like
that.
The
infradab
issues,
all
those
performance,
tweaks
and
scalability
pro
tweaks.
So
I
doubt
there
are
adding
new
features.
So
then
they
probably
won't
need
to
make
schema
more
schema
changes
or
adding
new
table.
A
They
are
adding
a
new
table
because
of
the
same
queueing,
but
if
we
give
them
a
one
month
notice,
they
just
get
all
the
changes
necessary
in
that
one
month.
Then
we
can
freeze
it.
D
D
I
do
think
we
all
agree
that,
having
at
least
one
sre
be
available
in
some
capacity
in
the
let's
say
the
next
month
month
or
two
is
beneficial
for
that
we
have
to
figure
okay.
What
would
this
person
actually
be
doing
there?
We
should
also
probably
look
at
you
know.
How
much
is
that
going
to
be
because
if
it's
only
a
couple
of
days,
we
probably
don't
need
a
dedicated
person
for
an
entire
quarter,
yeah
and
then
the
last
thing
is
probably
not
this.
D
We
need
to
provide
a
plan
upstairs
basically,
and
I
think
that's
where
the
opinions
are
still
a
little
divided.
Maybe
it
helps
if,
for
example,
I
can
meet
on
some
of
the
others,
perhaps
continue
afterwards,
so
that
we
don't
have
to
keep
everybody
in
here
and
try
and
sort
of
develop
a
better
understanding
of.
Let's
say
what
we
can
do,
at
least
in
the
coming
month,
that
isn't
the
low
balancer
and
the
real
six
shouting
stuff,
because
that's
already
ongoing
and
I
think
there
if
we
can
at
least
give
something
for
the
next
month.
D
I
think
we
can
probably
take
a
lot
of
the
pressure
off
because
then
people
at
least
know
oh,
hey,
there's!
This
is
what
we
sort
of
expect,
instead
of
it
just
being
this
black
box
yeah.
Please
please
correct
me.
If
I'm
wrong.
B
I
like
camille's
table,
I
think
it
it
helps
support
some
of
the
requests
and
it
will
it'll
allow
sre
to
give
some
feedback
too
of
okay,
I
see
what
you're
asking
for,
and
it's
not
necessarily
two
or
three
people
100
of
the
time,
so
they
can't
do
anything
else.
Then
they
can
work
it
in
with
the
other
things
that
they're
defining.
So
while
it
may
not
be
a
hundred
percent
accurate,
I
think
it
gives
a
good
big
picture
and
yeah
milestones
for
us
to
work
towards
where
we
can
kind
of
say.
B
A
I,
like
this
community,
quick
question
for
this,
to
call
these
two
cells
four
to
six,
so
that
means
we
need
extra
b's
temporarily
and
for
all
the
cells
that
have
four.
That
means.
Basically,
the
starting
group
is
sufficient.
A
E
A
E
E
A
E
I'm
I'm
I'm
not
it's.
It
usually
helps,
but
I
don't
think
that
this
is
really
like
a
strong
requirement
on
that
because,
like
the
features
that
okay,
there
are
maybe
some
features
that
will
have
to
be
fixed
from
the
perspective
teams,
but
probably
half
of
them
are
pretty
generic
things
to
solve
that.
If
someone
like
understands
like
how
to
deal
with
database
and
how
to
write
waste
code,
it's
gonna
be
fine
with
fixing
them.
C
E
I
think
my
only
counselor
I
saw
security
feature
being
affected,
so
we
may
need
someone
from
the
security
team
specifically
as
for
the
ci,
I'm
not
sure
this
is
strongly
needed.
I
think
they
have
enough
power
like
things
that
work
on
concurrently,
that
we
could
basically
use
someone
different
who
can
write
db
and
raise
stuff.
A
Okay,
thank
you
all
right.
Also.
I
just
want
to
remind
everybody
before
we
go,
so
I
also
added
one
item
like
if
we
find
out
the
work
that
can
be
find
out
to
feature
teams.
We
want
commitment
from
those
teams
to
take
on
and
execute
and
work
on
that,
according
to
our
upon
our
request.
So
that's
another
way
to
get
extra,
be
be
bandwidth
for
us,
so
I
I
will
keep
that.
That's
the
ask
I
want
to
raise
so
when
necessary.
A
E
So
we
could
focus
on
the,
not
omnibus,
because
this
could
be
handled
by
the
like
team,
but
we
would
focus
on
the
main
story
so
for
the
14.2
that
could
this
could
be
useful.
F
There,
this
is
how
we
work
also
on
the
database
group.
So
we
build
the
tools
we
set
up
the
way
to
work
and
then
its
feature
team
is
responsible
and
helps
us
on
on
their
future,
because
they
also
know
better
their
future.
F
A
Okay,
thank
you,
everyone.
We
are
over
time
we're
over
time,
but
thank
you
very
much
for
your
help
to
get
this
plan
to
this
I'll
clean
up.
This
is
a
very
good
information,
helps
me
to
form
our
proposal,
and
I
will
also
ask
for
how
much
flexibility
we
have
to
tweak
it
further.
I
want
to
try,
as
best
as
I
can,
to
reserve
that
capability.