Ok, so I’ve roughly talked about
jobs and career development in AWS.
Now let’s turn to Mark.
Hello, everyone, this is Mark.
Thank you, Tim, for talking about AWS Support.
As for myself, I’ve been working for AWS Support
for nearly four years.
Initially I was a Cloud Support Engineer.
What makes me different from Tim is that, just as mentioned,
I keep staying on the engineer path.
Let me talk about my last job.
I was in charge of R&D
in a security control company called VIVOTEK.
I worked on the underlying network and process development
for IP cameras.
I also built back-end servers with Golang,
including RESTful API servers, or
WebRTC signal server.
In Amazon, I am in charge of
network content and CDN services.
I also handle WAF issues,
such as SQL injection,
or cross-site script,
or DDOS related issues.
Ok.
Wait a second, ok.
Now, as for me,
I am actually a Cloud Support Engineer
all along this career.
So I want to use the
job grade system for our Cloud Support Engineers to
share with you something that
many people are curious about.
What do cloud support engineers do?
Let’s begin from CSA on the left.
CSA actually refers to
Cloud Support Associate.
The CSA role is mostly for those with 1-2 years of work
experience or university graduates.
They’re not proficient enough.
So we would ask them to handle basic cases to
enhance their proficiency.
We will not let CSAs handle
enterprise support customers.
I want to add something
regarding the enterprise support.
There are different plans for
the AWS technical support.
There are mainly three paid plans,
Developer,
Business, and Enterprise.
For enterprise clients, they are usually bigger in size,
and their issues are more diversified and more complicated.
So at the CSA stage,
we focus on single-aspect services,
or more basic technical issues.
When CSAs gain sufficient level of proficiency,
they will be
assessed in our internal process to
decide on the promotion to CSE,
which means Cloud Support Engineer.
This process usually takes about 6 months to a year.
CSE is a stage where you can
quickly gain lots of knowledge.
As a CSE, you will encounter
various types of cases,
no matter the severity level.
As we’ve mentioned, we
offer different Support Plans. The cases submitted by clients also
have different severity levels,
from 1 to 5.
5 is the most urgent.
For level 5, we usually respond within 15 minutes.
At this point, CSEs will handle
various severe or not severe issues
or issues requiring more skills.
They will quickly gain knowledge.
They will also gain experience
in one service within their own technical area.
When you accumulate enough knowledge in one
single service,
you’ll need to take the Subject-
Matter Expert (SME) internal exam
and certification, which Tim
has just mentioned.
Once you pass this exam, you will
be deemed an expert in this service.
For example, I am actually an
SME for ELB, meaning
Elastic Load Balancing.
After passing the exam and becoming an ELB expert,
I will get more challenging tasks.
Because I might do some
Support Ops tasks, as we just mentioned.
I will also get ELB cases
that other engineers are not able to handle, and
they will escalate them to me.
Aside from these challenges, we’ll
also get more opportunities,
because I can join the global ELB forum, where you
can find Support Engineers for global ELB SMEs,
and also our ELB development team.
We hold regular discussions, or
we have training meetings, every week or every month,
to understand the latest client feedback on ELB,
and the latest ELB technology,
and when to launch new features.
And in addition to these,
we are also in charge of global education training
to help our Support Engineers get familiar
with this ELB product.
So besides more challenges,
you also have the opportunity to know more about this service.
Other than this part of job,
as a CSE
you will work as a Support Ops,
like what we just mentioned.
You may need to handle
some escalated cases,
When a case is escalated,
it usually means this case
is in fact more urgent.
The client may have a production plan
And you need to have more expertise and know
how to reassure the clients, and
let the clients know how we
are helping them solve their issues in the fastest possible way.
So you may need to work with
several internal teams to
quickly find the solution to
the client’s issue.
After this process,
you will enter the next level,
what we called CSE II internally.
During CSE II,
besides a single area of expertise,
you’ll be proficient in more areas,
and more services.
Specifically, you will not be only specialized in ELB service.
You may also be specialized in,
for example, it’s network for me.
For network, I may be specialized
in BDOS, for example,
or WAF, or other technical areas.
Why do we want people in CSE II
to be proficient in more areas?
It’s because for a typical client case,
it may actually involve
various types of AWS network services.
For example, the client’s structure may contain
Crown Font CDN at the front end,
an ELB in the middle,
an EKS at the back,
which can be a container.
When there is an issue with the client’s services,
if you know these
three elements very well,
you can actually see the big picture on
this issue so that
you can solve it more quickly.
We expect people in CSE II to be able to do this kind of tasks.
When you are specialized in more than one or two services,
you will eventually become a
Senior Cloud Support Engineer.
As a Senior Cloud Support Engineer, you will be
specialized in the entire domain,
such as the network domain.
You will also be in charge of tech
issues without any clear direction.
By this time, you will also join
some global projects that
aim at improving the Cloud Support Engineer’s
ability to serve some of the clients’ projects.
So after the introduction of the CSE job grades,
to describe the CSE job
in one sentence,
I would say it helps our AWS users to know more
how to use AWS.
Why is that? Because there are actually various
types of clients on AWS Cloud.
As mentioned, we have Developer and Enterprise clients,
no matter whether they are small or big,
and no matter their industries.
For example, we’ve got e-commerce and blockchain clients,
and many other clients that use our AWS services.
And AWS Support aims to help the clients understand what
services they should use,
or what the best practice is for the circumstance where
they use the service.
We get this question:
do you only do troubleshooting?
Actually it’s not true.
In addition to troubleshooting,
we also help clients with architecture planning.
For example,
we also helped an online ticketing system to
optimize its DynamoDB to
greatly reduce the latency for ticket sales.
We also helped a flash sales
website to figure out what the
bottleneck was during flash sales,
and helped them plan for some resources in advance so that the
flash sales can run more smoothly.
You can see there is a QR Code here below.
It is linked to some of
our customers’ testimonies.
Scan it to read them if you are interested.
The middle one is linked to our support plan subscription.
As I’ve mentioned earlier,
we have four support plans.
If you want to know about these support plans,
scan the one in the middle.
I think the DDoS Case Sharing on
the right side is very worthwhile.
It’s our Cloud Support Engineers
sharing how we helped the clients solve their
DDoS issues, and
how to help them mitigate DDoS attacks, and
how we helped them bring the service back to normal.
Ok, now that we know
the scope of duties for Cloud Support Engineers,
let’s look at the technical depth.
I want to start with
the things that people would
want to point out when they first start their job here.
The first one is:
Only after starting working here
do I realize why they asked such difficult questions at the interview.
Take my past work experience in R&D for example.
At my previous job, I was
actually very focused on how to write the code well, and
how to make the code scalable.
But when I want to use a protocol,
for example, a TCP or a WebSocket,
I actually don’t need to know how its underlying protocol works.
I usually only need to know how to call this API,
or how to use a specific function to call it.
But when you start working here,
you realize that you need to solve a technical issue for the clients.
For example,
if a client says that he cannot access a certain EC2 today,
which is our virtual machine, we
may need him to intercept packets,
or collect HAR files.
In order to intercept packets,
we actually need to understand
how PCP actually works.
Because only when you understand how PCP actually works,
can you analyze these packets.
Then you are able to help the clients understand what
the issue is, and what he should do to solve it.
Second one, there are always new services and features in AWS
every day, more than I can learn.
Indeed, when I first started here,
there were only over 100 services.
But today at AWS we have actually
more than 200 services. The number has doubled.
Besides increase of services,
the features in each service
have also been evolving.
So there are always new customer
scenarios or new features to learn.
The third one is,
when I call customer service,
I feel like a difficult customer
because we are used to handle things based on the AWS
Support standards.
In fact,
the goal of AWS Support, even of the entire Amazon,
is to become the Earth’s
most customer-centric company.
So when we make a decision on the Support side, or
a decision on the Product side,
most of our decisions are
based on customer feedback,
or ideas from customers, so that
our technology can keep evolving.
Ok, next we will take a look at FAQs.
Do cloud support engineers focus
only on infrastructure?
As you can see,
Tim and I are not really experts in infrastructure.
I am more in Browsing Networking
I am in the development.
Tim is more familiar with Big Data.
So it’s not strictly required that
you need to know, for example, the underlying networking, or
that you must be proficient in
how to assemble machines, etc.
What skills do candidates need to have?
Do they need to have cloud knowledge?
Actually when we look at the candidate profiles,
each profile is different.
If you have some cloud knowledge,
it would be a plus.
But it’s ok if you don’t.
We actually prefer people with
an in-depth knowledge in one
specific area to someone who has
extensive, not in-depth, knowledge.
You need to like to solve
issues through learning.
For example, what we like more is a person
who is specialized in HTTP, or maybe PCP, but
who may not be familiar with DNS, for example,
or with the underlying VPN, but it is not a problem,
because you’re really good at HTTP.
What we are looking for is someone who enjoys in-depth learning,
or who likes to dig deep before finding a solution to an issue.
Ok.