►
Description
The TechOps Core Unit has a vision of providing support to the MakerDAO infrastructure layer, enabling a secure, reliable, and transparent ecosystem in order to improve MakerDAO’s agility and resilience.
Links:
MIP39c2-SP29: Adding TechOps Core Unit (TOCU-001): https://forum.makerdao.com/t/mip39c2-sp29-adding-techops-core-unit-tocu-001/12070
MIP40c3-SP54: TechOps Core Unit MKR Budget: https://forum.makerdao.com/t/mip40c3-sp54-techops-core-unit-mkr-budget/12079
MIP40c3-SP53: TechOps Core Unit DAI Budget: https://forum.makerdao.com/t/mip40c3-sp53-techops-core-unit-dai-budget/12072
MIP41c4-SP31: TechOps Core Unit Facilitator Onboarding - Simon Kelada-Polupanov: https://forum.makerdao.com/t/mip41c4-spxx-techops-core-unit-facilitator-onboarding-simon/12073
MIP41c4-SP30: TechOps Core Unit Facilitator Onboarding - Dumitru Zavrotschi: https://forum.makerdao.com/t/mip41c4-sp30-techops-core-unit-facilitator-onboarding-dumitru-zavrotschi/12074
A
A
A
B
Juan
hello,
everyone
thanks
for
coming,
happy
to
be
here
very
exciting
times.
Indeed,
so
we
are
tech,
ops,
co-units
presenting
to
you
by
myself
and
dimitri,
so
I
will
kick
it
off
and
dimitra
will
jump
in
towards
the
end.
Please
feel
free
to
interrupt
if
you
have
any
questions,
yeah
happy
to
discuss
any
points
as
we
go
along
so
straight
away.
What
is
our
mission
so
there's
a
few
definitions
for
the
mission
from
organization
to
organization.
B
So,
just
as
an
overview
of
the
areas
we'll
cover
today,
we'll
have
a
look
at
the
team
of
the
few
potential
future
tech
obscure
unit
division
around
this.
The
strategy,
how
we're
going
to
tackle
some
of
the
challenges
that
we
identified
as
a
team,
the
services
we
provide
and
the
budget
that
we
proposed
as
part
of
ami
as
well.
B
This
is
the
real
team,
so
you
can
find
us
on
discord
with
these
icons
dmitry
and
I
are
proposing
to
be
the
facilitators
so
two
facilitators
to
go
with
our
no
single
point
of
failure,
set
it
up
and
covering
multiple
time
zones
as
well.
So
dimitri
is
in
eu
and
myself
in
apac,
so
around
the
clock,
but
starting
with
christy,
so
we
we're
all
coming
from
the
foundation
originally
and
most
have
done
a
few
years
with
the
project
already
christie
as
a
newest
member.
B
He
enjoys
software
defined
everything
and
zero
trust
security
and,
of
course,
environmentally
sustainable
dementoru
is
our
quality.
Well,
he
was
quality
assurance
lead
with
the
maker
foundation
and
he
is
responsible
for
the
monitoring
and
alerting
setup
that
we
got
going
as
well,
which
we
can
have
a
look
a
little
bit
later
as
well.
B
So
jeanette
is
our
us-based
member
she's,
almost
three
years
with
the
project
will
be
coming
up
at
the
end
of
this
month.
So
george,
he
was
a
technical
team
lead
with
the
maker
foundation
and
the
former
lead
developer
with
the
sip
zach's.
I
believe
it's
called.
I
think
it's
a
voice
over
ip
project
and
he's
a
triathlete
as
well
he's
got
a
very
cool
looking
bike.
B
Becoming
as
it
takeoff's
co-unit
so
again,
the
definition
of
division
is
a
little
bit
of
a
longer
description
than
the
mission.
What
an
organization
aspires
to
become
so
we
will
be
looking
to
passionately
support,
secure,
reliable
and
transparent
infrastructure
in
order
to
continue
and
improve
mcada's
collaboration,
agility
and
resilience.
B
So
from
there
there's
kind
of
two
themes
develop.
One
is
infrastructure
and
one
collaboration.
So
let's
look
at
those
in
a
little
bit
more
detail,
so
we're
in
the
business
of
infrastructure
engineering.
That
is,
I
guess
you
could
say,
a
main
product,
so
the
infrastructure
we
deliver
is
reinforced
by
reliability,
support
and
transparency.
B
Reliability
is
obvious:
we
strive
for
high
service
reliability,
robust
monitoring
and
regular
safe
deployments
when
it
comes
down
to
support.
We
provide
24,
7
detection
and
incident
response.
A
high
level
of
redundancy
between
critical
components
and
the
team
itself,
as
we've
seen
previously,
and
transparency
is
something
that
we
will
be
bringing
to
the
core
unit
as
well,
so
regularly
informing
stakeholders
about
the
study
of
infrastructure,
cost
structure.
That's
involved
in
running
such
infrastructure
and
trade-offs
involved
in
that
as
well.
B
B
With
any
new
information,
we
serve
as
a
point
of
contact
being
first
line
of
support
for
external
researchers
and
maker
system
participants
as
well.
So
we
try
as
new
requests
coming
in
and
deal
with
them.
Accordingly,
and
then
we
worked
on
integration
of
the
maker
components
into
other
services
as
well,
which
we'll
have
a
look
in
the
in
a
little
bit
as
well
so
yeah.
We
basically
maintain
a
list
of
scripts
and
recipes
and
look
after
and
make
access
make
it
accessible
to
others.
B
B
B
Collaboration
and
communication
with
this
with
the
stakeholders,
so
as
the
number
of
projects
increases
we
contact,
switching
yeah
is
really
becomes
a
problem,
so
yeah
we've.
We
realized
that
that's
a
challenge
and
we
yeah
deal
with
that
today.
By
keeping
the
timelines
in
sync
and
prioritizing
projects,
we
will
yeah
cover
some
of
these
solutions
in
the
next
few
slides
all
right.
B
B
All
the
stakeholders
of
a
macadamia
ecosystem,
not
just
technical
core
units,
so
let's
have
a
look
at
each
of
those
steps
and
break
it
down
a
little
bit
so
starting
at
the
top
left.
With
the
plan
this
step,
we
mainly
target
challenges
regarding
knowledge,
sharing
and
incoming
work
prioritization,
as
we've
seen
in
the
challenges
slide.
B
We
do
the
usual
sprint
kind
of
cycle
as
other
development
teams,
and
that
lets
us
reconcile
and
prioritize
with
the
team
and
adjust
the
backlog
as
needed,
and
the
progress
of
these
gets
reviewed
at
our
daily.
Follow
the
sun
meetings
more
critical
work
as
it
comes
in,
gets
reprioritized
and
put
in
the
current
sprint,
if
necessary,
so
yeah.
Some
of
the
things
that
that
system
brings
to
us
is
establishing
clear
priorities,
limit
work
and
progress.
B
So
again
that
context,
switching
and
therefore
improving
quality
of
work
because
you
don't
have
to
you
know,
has
been
proven.
If
you
work
on
10
different
things,
none
of
them
are
going
to
come
out.
Very
nice
nicely
conduct
p
code
reviews,
so
each
code
change
goes
through
all
the
other
team
members
that
we
introduce
and
knowledge
sharing
sessions.
B
C
B
B
B
B
Full
set
of
monitoring
tools
not
only
includes
matrix,
but
also
logs
and
dashboards,
that
we're
going
to
see
at
a
few
in
in
a
bit.
Dashboards
are
particularly
useful
for
knowledge,
sharing
and
transparency
within
the
team
and
outside,
and
of
course,
we
need
a
loading
to.
Let
us
know
if
there's
any
issue,
24
7
support
team
is
there
to
try
in
incidents,
and
you
know
coordinate
request
as
it
comes
in.
B
Now
the
budget,
so
obviously
all
of
this
is
available
in
our
mip
on
forums.
So
please,
if
you
need
more
detail,
we
spent
a
lot
of
time
and
making
sure
everything
is
right
there,
but
I
can
take
you
guys
through
line
by
line
briefly.
So
these
these
are
monthly
and
quarterly
figures
annually
is
available
on
the
forum
as
well,
starting
at
the
top
people
cost
is
the
biggest
costs
as
in
any
organization.
B
B
So
that
is
a
compensation
for
5.7
ft
for
next
year.
Other
people
costs,
as
you
can
see,
little
asterisks.
That
is
a
cost
factor.
We
are
starting
a
new
venture,
so
costs
like
benefits,
taxes,
fees
and
so
on
and
might
creep
up.
So
there
is
scaled
by
25
percent
and
the
second
biggest
cost
after
people
are
infrastructure
and
tools.
B
B
B
So
there's
a
number
of
other
line
items,
so
r
d
and
proof
of
concept.
R
d
stands
for
research
and
development,
so
as
systems
evolve
and
new
solutions
come
to
surface
engineers
will
need
to
keep
up
to
date,
and
this
is
reflected
in
the
conferences
and
education,
but
also
you
know
in
our
industry.
You
learn
by
doing
so.
B
Again.
This
is
a
budget
cap
as
as
states
states
here
it
doesn't
mean
that
we
will
be
spending
all
of
these
numbers
as
they
come
in.
We
will
reevaluate
the
cap
that
we
got
top
up
and
return
and
spend
to
the
protocol
so
moving
moving
on
dell
third-party
integrations,
as
mentioned
previously,
we
work
with
a
number
of
projects
where
we
integrate
it
maker
components
into
their
tools.
B
And
so
audits
audits
not
only
related
to
smart
contracts,
but
it's
also
healthy
for
the
infrastructure
as
well.
So
next
year
we
might
reach
out
to
a
professional
third
party
to
look
over
our
infrastructure
and
never
never
enough
eyes.
You
know
for
the
security
again.
This
is
a
new
venture,
so
accounting
recruiting
and
legal
consultancy
fees
are
all
pretty
standard,
travel,
budget
and
conferences
again
yeah.
B
We
all
know
how
crucial
conferences
are
to
meet
like-minded
engineer
engineers
in
the
space
and
also
if
one
of
our
timbers
would
like
to
present
something
that
they've
been
working
on.
It's
also
encouraged
as
well
hardware
as
well
optional
for
for
new
hires.
We
might
need
to
use
this
line
item
mainly
for
tests.
So
with
ethereum
two
around
the
corner,
we
might
need
some
specialized
hardware
to
test
some
of
the
nodes
locally
and
contingency
representing
five
percent
of
the
total
budget
cap.
That
is
pretty
standard.
B
B
B
B
And
infrastructure
for
other
core
units
again
more
details
available
on
the
map.
We
put
a
lot
of
time
into
that
monitoring
and
alerting
so
dashboards
responses
and
reports
that
are
sitting
on
top
of
the
infrastructure
we
host
24
7,
followed
sun
support,
always
available
team
development
and
qa,
so
we
can
help
with
infrastructure,
design,
cicd
pipeline
design
and
any
kind
of
staging
environments
and
production,
provisioning
tools,
administration,
so
certified
services,
administration
and
management.
B
B
Oracle
network,
so
we
host
a
few
nodes.
We
monitor
those
and
do
upgrades
and
collateral
on
boardings
as
well,
when
that
happens
and
maker
keepers
as
well.
For
those
who
know
a
keeper
is
the
little
service
that
constantly
triggers
some
of
the
operations
that
make
a
protocol
requires
from
time
to
time.
So
we
have
host
a
number
of
those,
and
the
plan
is
to
yeah,
standardize
and
open
source.
Some
of
that,
so
other
players
in
the
ecosystem
can
do
so
themselves.
C
C
So
if,
if
there
is
a
deviation
above
a
certain
threshold
for
any
of
the
collaterals,
we
are
notified
and
we
have
a
good
collaboration
with
the
oracle's
oracle's
team
now,
where
we
also
notified
them
about
that,
because
they
need
to
be
aware
so
yeah
all
collaterals
have
this
kind
of
analytics
data
and
with
the
growing
number
of
collateral
types
yeah.
This
is
the
dashboard
is
increasing
and
becoming
bigger
and
yeah.
If
you
can
go
to
the
next
slide,
simon,
please
yeah.
So
these
are
oracles.
C
Oracle
feeds
dashboard,
another
another
dashboard
built
in
this
analytics
tools
that
shows
the
feeds
how
they
are,
how
they
are
reporting
and
yeah.
This
is
mainly
done
to
to
monitor
and
ensure
that
all
the
feeds
are
reporting
correctly
and
their
functionality
is,
is
correct
and
then,
if,
if
there
is
below
60
below
specific
limit
of
defeats
that
are
reporting,
we
are
notified
about
that
yeah.
So.
B
D
C
Yeah,
the
the
liquidations
dashboard,
the
third
thing
that
we
build
and
it
the
main
thing
it
reports
is
yeah
amount
of
diet
that
is
needed
to
liquidate
on
the
next
osm
price.
So
if
it's
again
above
a
specific
certain
limit,
then
we
are
notifying
correspondent,
team
members
and
also
other
teams
about
that
and
yeah
next
slide,
please.
C
So
what
now
interesting
part
is
what
happens
when
yeah
when
something
bad
happens.
So
we
we
built
this
alerting
tool
and
we
are
using
dollars
in
to
to
notify
us
and
team
members
and
based
on
the
criticality
of
the
alerts
we
have.
We
split
them
into
three
different
priorities
where
priority
one
is
something
where
we
need
to
react
immediately,
something
that
wakes
us
up
and
the
priority
two
is
kind
of
mid-critical
alerts
where
we
have
some
time
to
investigate
and
and
basically
give
a
response
about.
The
reason.
C
Then
priority
three
alerts
is
something
that
is
not
critical
and
we
look
at
it
whenever
we
have
time
so
yeah.
Based
on
these
three
priorities.
We
we
built
this
alerting
tool
that
notifies
us.
We
have
specific
on-call
schedules
where
we
we
make
sure
that
at
least
two
team
members
are
always
on
and
looking
at
everything
that
everything
is
working
properly
and
yeah.
In
case
something
happens.
C
According
to
the
rules,
we
are
notified
using
different
means,
like
phone
calls,
phone
alerts,
mobile
notifications
coming
from
the
app
or
sms
messages
or
emails.
If
something
is
not
very
critical,
so
we
are
monitoring
many
parts
of
infrastructure
and
many
projects
and
the
parts
of
the
maker
ecosystem.
C
I
think
the
latest
figures
is
around
200
monitoring
tests
on
monitoring
checks
that
we
are
doing
constantly
24,
7
and
yeah
again,
based
on
the
the
criticality.
We
run
them
either
more
or
less
frequent,
but
yeah
everything
is
done
constantly
on
on
different
environments
as
well.
So
we
have
also
the
test
running
on
staging.
E
C
B
Thanks
dmitry
and
believe
it
or
not
as
being
a
development
team,
it's
very
hard
to
find
visual
examples
of
our
work.
So
we've
chose
a
few
of
those
something
to
show
you
there's
a
lot
more
so
yeah.
Thank
you
guys,
there's
our
discord
forum
tag
for
our
co-units,
the
mips
on
rfc
right
now.
So
if
you
have
any
questions,
concerns
please
reach
out
to
us
with
any
of
your
comments
and
questions,
so
I
believe
there's
a
week
or
so
before
full
formal
submission
at
the
end
of
the
month.
B
D
C
C
It
runs
the
test
either
more
or
less
frequent
software
for
very
critical
scenarios
like
emergency
shutdown
triggered
or
things
like
that
that
affect
the
whole
maker
ecosystem.
They
run
every
five
minutes.
I
delete
these
checks
and
yeah.
So
if
anything
happens,
it
notifies
us
immediately
or
close
to
immediately.
C
How
do
we
verify
it?
We
have
some
processes
around
verifying
that
the
actual
monitoring
test,
that
they
are
performing
correctly,
that
they
are
running
and
verifying
what
they
need
to
verify.
We
have
monthly
meetings
where
we
meet
and
and
actually
test
the
monitoring
system
that
we
built
for
high
critical
high
critical
scenarios
like
emergency
shutdown
triggered
or
some
some
movements
of
mkr
between
between
hat
and
other
proposals,
so
yeah,
something
like
that.
E
C
E
I
can
yeah
george
so
for
related
to
epns.
We
know
that
the
governance
in
the
dax
team
they
are
looking
to
integrate
such
so
definitely
something
on
our
list.
We
lately
we
focused
on
the
notifications
that
we
provide
on
on
the
channels
like
discord,
but
yeah
we'll
look
into
expanding
that
together
into
other
communications
channels,
okay,
not
sure
exactly
about
the
email,
because
that
means
like
retaining
data.
So
there
are
some
aspects
that
need
to
be
considered
before
before
adding
new
channels.
C
Yeah,
but
definitely,
as
george
said,
we
try
to
to
do
it
in
a
transparent
way,
and
actually
this
week
we
introduced
some
new
notifications
in
the
community
maker
discord
so
that
the
community
is
aware
about
different
events
like
mkr
liquidity
alert,
for
example.
That
has
been
added
last
friday,
but
we
also
tried
to
to
add
some
more
things
notifications
to
be
sent
to
the
community
and
if
you
feel
like
you,
have
ideas
about
the
way
the
community
should
receive.
C
E
Yeah
another
way
is
like
we
can
onboard
like
delegates
as
opposed
voters,
and
we
cannot
board
them
into
the
pagerduty
system,
so
they
could
receive
directly.
The
notifications
like
in
real-time
notifications
on
phone
and
other
other
devices,
but
yes,
something
that
we
have
to.
We
have
to
elaborate
on,
and
that's
related
to.
The
second
point
that
you
said
the
describing
how
we
manage
incidents.
C
B
C
D
Thank
you.
I
was
going
to
hop
in
and
kind
of
asked
real
briefly
about
prioritization
within,
like
core
unit
requests.
I
think
I
know
from
I
said:
go
valve
you
guys
are
really
responsive
and
really
help
us
get
things
out
quick,
but
obviously,
as
we
get
more
and
more
core
units
kind
of
curious,
have
you
thought
about
how
you
will
be
prioritizing
requests
between
them.
C
Yeah,
we
actually
thought
about
that
and
that
indeed
that
becomes
a
kind
of
a
problem,
because
in
the
past
there
were
no,
not
so
many
requests
and
we
tried
to
execute
them
instantly
or
closely
instantly,
because
we
felt
like
doing
everything
quickly.
We
can
manage
that,
but
with
the
growing
number
of
core
units
of
community
members
and
other
actors,
we
we
kind
of
introduced
a
new
way
of
managing
this
request.
C
B
C
C
C
We
have
a
tech,
ops
request
channel,
but
we
thought
that
this
is
not
very
scalable
and
we
need
a
way
to
to
get
requests
in
a
kind
of
hidden
way
so
that
people
report
or
ask
questions
without
everyone
else,
seeing
them
and
also
yeah
a
way
to
to
get
this
kind
of
requests
so
yeah,
most
probably
that
would
that
process
will
change
in
the
future,
but
yeah
we
haven't,
we,
we
don't
have
any
details
yet
but
again
yeah.
This
is
something
that
will
happen
once
we
have
a
core
unit
created.
B
A
I
wanted
to
ask
related
to
to
pro's
question:
how
do
you
guys
like
right
now
the
budget
you're
getting
it's
mainly
from
the
dao
to
to
service
other
core
units
needs?
So
how
do
you
manage
the
since
you're,
not
asking
for
a
budget?
How
do
you
prevent,
like
a-
I,
don't
know
some
low
priority
core
unit
coming
and
saying
I
need
three
full
archive
notes
and
I'm
not
going
to
even
use
them
or
or
some
crazy
request
without
charging
for
a
budget.
B
B
B
But
yes,
it
will
be
have
to
be
discussion
if
it's
critical
or
not
again,
if
the,
if
the
protocol
needs
it
and
the
community
decides
that
it
is
a
critical
infrastructure,
then
we'll
have
to
scale
the
resources
and
the
budget
will
reflect
that
accordingly,
as
well,
so
we're
here
to
help
the
protocol.
We
are
here
to
grow
the
team.
Accordingly,
yeah.
A
D
So
I'm
jeanette
rigger
and
I'm
devops
engineer
and
my
video
is
not
coming
on
right
now,
so
you
just
have
to
do
without
my
video.
I
look
just
like
the
picture
in
the
in
the
in
the
icon
over
there
anyhow.
So
I
wanted
to
expand
on
that.
When
we
did
the
migrations,
there
were
a
lot
of
infrastructure
that
was
moved
with
core
units
and
they
had
included
their
infrastructure
costs
as
part
of
their
own
core
unit
budget
and
us
as
tech
ops
have
been
helping
manage
that
right.
D
So
the
developers
are
not
expected
to
know
all
of
the
ins
and
outs
of
infrastructure
and
the
ci
cd
and
things
like
that.
So
we're
we're
there
to
help
them
and
that
that
has
also
worked
where
the
core
units
include
the
infrastructure
as
part
of
their
own
budget,
because
it's
part
of
their
own
project.
D
Yeah
real
quickly,
I
know
you're
scaling
to
seven,
I
believe
you
said
seven
or
nine
employees,
so
I
was
wondering
what's
your
strategy
to
onboarding
the
extra
three
four
five
folks
and
how
do
you?
How
do
you
deal
with-
and
I
did
ask
this
at
the
forum
you
know
with
regards
to
burnout,
but
how
do
you
make
adjustments
and
team
size?
You
know,
especially
with
the
work
times
and
I'm
pretty
sure
you
guys
are
working
long
hours
so
yeah.
B
So
the
onboarding
procedure
is
pretty
standard
in
the
industry.
We
try
to
document
as
much
as
possible
and
all
of
the
components
that
we
manage.
So
we
have
a
data.
The
knowledge
sharing
database
that
we
keep
up
to
date
so
we'll
just
basically
throw
that
at
them
and
get
them
to
read
it.
No
and
yeah
regular
onboarding
meetings
being
infrastructure
being
managed
as
code.
It's
relatively
easy
to
get
the
new
person
to
start
working
on
something
small
start
looking
over
the
code
base
and
then
review
their
changes
again.
B
B
E
Also
to
this
point,
integration
with
forta
is
also
important
for
us,
because
we
want
to
make
this
in
a
decentralized
way.
We
want
to
accommodate
all
the
alarms
or
almost
all,
of
the
the
monitoring
that
we
have
in
place
in
this
decentralized
framework.
So
we
are.
We
are
working
with
the
forta
guys
to
to
accomplish
this.
So
again,
openness
is
one
of
the
the
first
points
in
our
roadmap
and
I
think
one
of
the
most
important
ones.
D
Yeah
totally,
I
would
love
to
see
the
roadmap,
especially
if
you
can
give
us
an
idea
of
decentralization
right,
really
excited
about
that
and
getting
some
of
that
infrastructure,
decentralized
and
yeah.
I
think
the
community
needs
that
we
need
to
see
like
a
road
map
to
what
exactly
the
goals
are,
even
if
you're
late,
you
know
a
month
or
two
whatever
at
least
we
have
something
right.
So
thank
you
for
the
for
the
presentation
and
the
answer.
Thanks.
E
And
there
is
another
aspect
of
that,
so
the
the
ongoing
services
that
indeed
do
not
have
a
roadmap
right,
because
it
is
making
sure
that
the
services
keep
they
keep
up
and
running.
They
are
up
to
date,
but
of
course,
for
that
part
of
the
job
there
is
there's
kpis.
There's,
there's
metrics
that
are
tracked
to
to
measure
the
quality
and
there
are.
There
are
goals
in
in
that
regard.
B
E
E
C
Yeah
we
have,
we
do
have
a
status
page
for
maker,
dao
and
yeah.
We
we
verify
multiple
systems,
so
you
can
see
the
uptime
of
many
systems,
but
we
also
the
specific
things
we
measure
is
vulcanized
dp,
the
external
partner
points,
the
events,
the
tour
line
so
yeah.
This
is
something
that
you
can
see
and
verify
historical
data
for
it,
and
this
is
already
available
externally
to
anyone.