►
From YouTube: Intro Support Engineering bcarranza
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
Before
we
dive
in
I'll,
let
you
know
a
little
bit
about
me.
My
name
is
bree
karanza.
I
am
a
support
engineer
at
gitlab
and
I've
been
here
since
may
of
2020..
My
background
is
in
linux
systems,
administration,
high
performance
computing
and
cyber
security.
Here
at
git
lab,
I
specialize
in
gitlab
cicd,
gitlab,
runner
and
graphql.
A
So
these
are
the
four
things
that
we're
going
to
cover
today.
By
the
end
of
this
brief
presentation,
you
should
have
a
general
understanding
of
what
support
engineering
is
what
I
and
my
colleagues
do
in
our
roles
as
software
engineers,
why
support
is
important
and
some
of
the
skills
that
are
essential
for
becoming
a
support
engineer.
A
Let's
start
with
what
support
engineering
is
so
simplified
support
engineers
help
to
bridge
the
gap
between
the
way
things
should
work
in
theory
and
the
way
that
things
are
actually
working
in
reality.
A
A
A
A
When
the
documentation
has
been
exhausted,
then
support
engineers
come
in
and
play
a
role.
We
might
resolve
tickets
in
one
of
a
number
of
different
ways.
One
common
thing
we
do
is
consult
on
customers
current
configuration
and
help
make
suggestions
on
how
they
can
bring
their
current
configuration
to
their
desired
configuration.
A
We
also
might
create
a
new
bug
report.
I
earlier
today
created
a
bug
report
because
the
customer
reported
something
that
wasn't
working
the
way
they
expected
it
to
looked
into
it.
It's
a
bug,
so
I
made
a
bug
report
and
let
them
know
about
that.
A
Sometimes,
if
we're
lucky
we'll
find
bug
reports
that
already
exist
and
we
can
connect
users
with
those
bug
reports
and
then
sometimes
we
will
identify
that
the
source
of
the
problem
is
outside
of
gitlab.
So,
for
example,
if
someone
is
having
trouble
receiving
notification
emails
from
gitlab,
we
dig
into
the
problem.
We
see
that
gitlab
is
attempting
to
send
the
email,
but
the
smtp
server
is
not
responding
properly.
So
that's
a
situation
where
we'll
help
resolve
the
ticket
by
explaining
what
git
lab
needs.
A
In
order
for
the
emails
to
be
sent,
we
do
lots
of
things
that
are
not
solving
tickets,
though
we
contribute
code
fixes,
we
help
to
improve
the
documentation.
As
I
mentioned,
we
have
lots
of
opportunities
for
professional
development
and
that's
really
great
for
opportunities
to
become
familiar
with
the
technology
before
getting
a
lot
of
tickets
about
it.
So
that's
pretty
exciting.
A
A
So
everyone
organizes
their
time
and
their
work
differently,
but
I
wanted
to
give
you
an
example
of
what
a
day
in
a
support
engineer
could
look
like.
I
tend
to
be
very
calendar
oriented
person,
so
I
try
and
put
everything
that
I'm
planning
on
doing
on
my
calendar,
so
you'll
see
here
the
pairing
sessions
at
nine
and
ten
in
the
group
pairing
at
three.
Those
are
all
opportunities
to
collaborate
with
others
on
tickets.
We
do
those
in
one-on-one
pairing
sessions
and
in
larger
crush
sessions.
With
you
know,
three
or
more
engineers.
A
You'll
also
see
time
for
professional
development,
taking
a
break
because
rest
ethic
is
as
important
as
work
ethic
one-on-one
with
my
manager
and
then
sort
of
wrapping
up
for
the
end
of
the
day.
A
A
So
the
importance
of
support
we
help
people
continue
to
use
gitlab
smoothly
across
the
support
team.
We
want
people
to
have
an
amazing
experience
with
gitlab.
A
We
wind
up
responding
in
situations
that
run
the
gamut
in
terms
of
severity.
So
if
someone
has
a
quick
question
clarifying
how
something
should
work
in
gitlab,
support
is
here
to
help
if
someone's
get
lab
instance
is
down
in
production
they're
experiencing
a
significant
business
impact.
Gitlab
support
is
here
to
help
in
those
situations
as
well.
A
So
we'll
pivot
a
little
bit
to
talk
about
some
of
the
skills
and
technologies
that
are
essential
for
people
in
roles
like
support
engineer,
troubleshooting
troubleshooting
is,
I
think,
the
single
most
important
skill.
We
rely
on
troubleshooting
every
single
day
to
solve
problems
effectively.
We
really
would
be
nowhere
without
the
ability
to
troubleshoot
effectively
digging
into
what
effective
troubleshooting
looks
like
would
be
a
separate
topic,
but
it's
a
really
important
skill,
networking
basics.
So,
for
this
role
I
would
recommend
being
familiar
with
things
like
dns
passing
familiarity
with
the
tcpip
model.
A
So
you
know
what
someone
means
if
they
say
that
a
problem
is
a
layer,
2
problem
versus
a
layer,
7
problem
and
the
nice
thing
about
networking
basics
is
that
will
also
help
you
to
identify
the
the
location
of
a
problem,
understanding
the
way
that
systems
interact
with
one
another
from
a
networking
perspective
will
help
you
to
identify
okay.
The
problem
is
not
in
this
service.
It's
with
this
service.
A
That's
given
weird
requests
or
should
be
able
to
be
connected
to
or
whatever
I
would
also
recommend,
being
comfortable
with
common
command
line
interface
tools,
so
that
would
be
sort
of
like
linux,
basics,
like
cd
ls,
find
tar
and
dig.
Those
are
all
commands
that
you
will
find
useful
in
troubleshooting
a
variety
of
different
systems
and
applications,
and
then,
lastly,
if
you're
looking
at
roles
with
the
title
support,
engineer,
you'll
probably
benefit
from
having
some
of
these
devops
basics,
so
familiarity
with
git
as
a
version.
Control
system
would
be
really
helpful.
A
A
The
response
would
be
helpful
and
related
to
that
being
comfortable,
parsing,
json
and
yaml
you'll
find
responses
are
often
in
json
and
config
files
will
be
in
json
or
yaml
so
being
familiar
with
jq
yq
or
some
other
tool
for
parsing,
jason
or
gamble
content
will
serve
you
well
and
then
someone
in
transition
to
talking
about
skills
that
are
not
purely
technical
skills,
but
that,
I
think,
are
super
helpful
for
a
support
engineering
role.
A
I
encourage
people
in
this
role
to
be
curious
about
what
they
see.
We
gain
so
much
information
about
the
cause
and
nature
of
a
problem
by
asking
questions.
It's
also
really
important,
when
presented
with
a
problem
statement,
to
understand
why
someone
is
making
that
assertion.
So
if
someone
says
oh,
the
server
is
down
it's
important
to
ask:
why
do
you
believe
the
server
is
down
the
server's
down
could
mean
different
things
to
different
people.
Is
it
actually
powered
off?
Is
it
not
connected
to
the
network?
A
Next,
I
recommend
humility,
one
of
the
most
exciting
and
interesting
parts
of
this
kind
of
role
is
that
the
person
that
you're
helping
could
be
relatively
new
to
tech.
They
could
also
be
someone
who
way
surpasses
your
own
technical
expertise
and
that's
okay,
it's
important
to
be
confident
in
what
you
do
know
be
confident
and
have
a
low
level
of
shame
about
what
you
don't
know
and
come
to
the
table
with
a
humble
perspective,
so
that
you
and
the
customer
can
work
together
to
solve
the
problem
organization.
A
Some
organizational
system
is
critical
to
success
in
this
world.
We
wind
up
having
lots
of
tickets
at
one
time,
and
so
it's
important
to
have
some
system
by
which
you
can
distinguish
between
the
details
of
ticket
a
and
ticket
b.
So
when
you're
discussing
that
ticket
in
a
pairing
session
or
writing
back
to
the
customer,
you
know
what
information
is
related
to
the
ticket
at
hand.
A
We
often
want
problems
to
be
solved
immediately
and
sometimes
it's
possible,
but
I
would
not
recommend
relying
on
it
and
so
being
patient
and
staying
the
course
and
working
through
the
problem
diligently
until
you
get
to
a
resolution
is
important.
I
see
that
because
sometimes
it
can
feel
a
little
bit
discouraging
to
you.
I've
worked
on
a
problem
all
day
and
not
have
a
solution.
It's
okay
tomorrow
will
come.
You
will
get
to
the
solution,
have
patience
with
yourself
and
with
the
process.
A
And
lastly,
as
a
parting
thought,
I
wanted
to
leave
you
with
this
sentiment
that
I
gained
from
one
of
my
colleagues
here
at
get
lab
support
in
this
kind
of
role.
It's
not
in
the
only
it's
important
what
you
know,
but
that's
not
the
only
thing,
that's
important.
What
you
can
figure
out
is
really
really
important
too.
We
often
find
ourselves
with
tickets
that
have
components
to
them
that
we
may
have
never
used
before
or
may
have
used
very
sparingly.