Split View: FDE 기술 지도 — 8개 도메인의 최소선, 실무선, 확인 질문

The FDE Skill Map — Baselines, Working Levels, and Check Questions for 8 Domains

• Why You Need a Map
• Linux
• Networking
• Kubernetes
• Databases
• Auth and Security
• Observability
• Cloud and Infrastructure
• Customer Communication
• Practice by Doing

Why You Need a Map

Part 1 pinned down what an FDE is. This part draws the full map of the skills the role demands. The eight domains used here are the same eight that this blog's FDE Career RPG uses as its leveling axes: Linux, networking, Kubernetes, databases, auth and security, observability, cloud and infrastructure, and customer communication. The RPG is designed so that when a domain level rises, the same log reads differently — and reality works exactly that way too.

For each domain I write down three things: why it matters, where the baseline is, and where the working level is. The baseline is not a goal; it is an entry condition. Below it, conversations in the field do not hold together. The working level is where you can handle that domain's problems alone. Almost nobody is at working level in all eight, and nobody needs to be. If you can answer the three check questions without stalling, you are roughly at working level in that domain.

Linux

The floor of a customer server is almost always Linux, and the moment you SSH in, there is no GUI. If you are stuck here, every other domain is unreachable.

• Baseline — the basic concepts of files, processes, and permissions. Moving and searching directories, listing processes, checking disk and memory usage, finding where the logs accumulate.
• Working level — tracking daemon state and restart history through the service manager, distinguishing disk, memory, and file-descriptor exhaustion, and reading and fixing shell scripts someone else wrote.

Check questions. When an alert says the disk is full, in what order do you look? How do you notice that log rotation has stopped working? On a permission-denied error, which do you check first: owner, group, or mode?

Networking

Half of all "I cannot connect" reports end at the network layer. And the customer's network is always more complicated than its documentation.

• Baseline — the concepts of IP, ports, DNS, and firewalls. The ability to verify connectivity step by step from the command line.
• Working level — diagnosing TLS certificate expiry and chain problems, tracing a request path behind proxies and load balancers, and telling timeouts, connection refusals, and resets apart from symptoms alone.

Check questions. The same URL works from the server but not from an office PC — what do you suspect first? How can DNS TTLs delay recovery from an incident? How does a firewall block look different from a dead service, seen from the client?

Kubernetes

The default deployment unit of today's enterprise customer environments. If the product ships as containers, the first screen of any diagnosis is usually here.

• Baseline — the relationship between pods, deployments, and services. The basic commands to list resources, describe them, and read logs.
• Working level — knowing which family of causes CrashLoopBackOff, OOMKilled, and Pending each point to, reading resource requests and limits, and tracing traffic from the ingress down to the pod.

Check questions. What are three typical reasons a pod stays Pending? Where do you confirm that a container was killed for exceeding memory? The service exists but nothing connects — do you look at the selector or the endpoints first?

Databases

Where the customer's data lives, where "it is slow" reports most often converge, and where mistakes cost the most.

• Baseline — SQL queries with joins, a working idea of what an index changes, and the habit of confirming a backup exists before touching anything.
• Working level — reading execution plans to diagnose slow queries, distinguishing lock waits from connection-pool exhaustion, and assessing the risk of a migration.

Check questions. A query that was fast yesterday is slow today — what hypotheses do you form? How do you find the session holding a lock? When does adding an index actually make things worse?

Auth and Security

An FDE handles the keys to someone else's house. Auth problems are among the hardest reports to reproduce, and permission mistakes are the fastest way to destroy trust.

• Baseline — the distinction between authentication and authorization, the lifetimes of tokens, sessions, and API keys, and the principle of least privilege.
• Working level — pinpointing which step of an OAuth or SSO flow broke, narrowing layers using 401 versus 403 as clues, and diagnosing expiry and clock-skew problems.

Check questions. What exactly failed when you see a 401, and when you see a 403? What are the cases where a valid token still fails to authenticate? When the customer offers to hand you full admin rights for convenience, what should you say?

Observability

In an unfamiliar environment, observability is your only pair of eyes. What you would simply know about your own service, here you must dig back out of logs and metrics.

• Baseline — the distinction between logs, metrics, and traces, and the ability to narrow logs by time and pattern from the command line.
• Working level — finding where metrics come from even without a dashboard, mapping log levels and retention policies, and reconstructing system state even when the monitoring itself is down.

Check questions. When the monitoring died first, what do you use to understand system state? Why do you look at percentiles rather than average response time? When error logs run at hundreds of lines per second, where do you start cutting?

Cloud and Infrastructure

Every customer has different cloud terrain, and the FDE works on top of it. Splitting managed-service failures from application failures is the first fork in any diagnosis.

• Baseline — the concepts of VPCs, subnets, and security groups, plus the IAM permission model of one major cloud.
• Working level — checking the state of a managed database or queue separately from app symptoms, reading infrastructure defined as code, and explaining the broad shape of the cost structure.

Check questions. What is the difference between a security group and a network ACL? When you suspect an availability-zone failure, what do you check? When requesting access to a customer's cloud, at what granularity and for what duration do you ask?

Customer Communication

The only one of the eight that is not technical — and the channel through which the other seven get delivered. In the RPG, a low level in this domain makes missions fail even when the diagnosis is right, and reality grades the same way.

• Baseline — listening to the customer while separating facts from interpretation, and sharing progress at the cadence you promised.
• Working level — managing expectations explicitly, delivering bad news without losing trust, and translating technical content into a non-engineer's language.

Check questions. What do you say to "when will it be fixed" while you still do not know? How do you correct a customer who is confident in a wrong cause? What belongs in the first paragraph of an incident report?

Practice by Doing

Once you have located yourself on this map, the fastest way to fill the gaps is by hand.

• FDE Career RPG — the eight domains above are its leveling axes, verbatim. Run missions and see which domain stops you.
• FDE Curriculum Roadmap — a progress-tracked checklist of 65 skills across 10 domains, each with a concrete self-check criterion.

FDE Complete Guide series

• Previous: What Is a Forward Deployed Engineer (FDE) — the Engineer Stationed at the Customer Site
• Next: The First 90 Days as an FDE — Mapping, Solo Tickets, and a Led Mission