在 Cisco 当 FDE，考核看升级工单而不是代码

设想这样一个场景：一家大客户刚把全公司的 Web 流量迁到云代理上。第二天一早，某个分支机构的员工在登录一个内部应用时陷入无限循环。客户的 IT 团队认定是你们产品的问题；你们自己的工程团队则要先看到证据才肯认账。

夹在两方之间的，正是 Cisco 在 Duo Security 名下发布的安全服务边缘（SSE）方向前线部署工程师（FDE）岗位所描述的工作。

招聘启事要求 FDE 全权负责复杂的升级工单，让客户保持合理预期，并提供精确、可复现的技术证据。

值得关注的原因在于 FDE 这个头衔。这个岗位由 Palantir 带火，很多人一听到“FDE”就立刻联想到 AI 或数据。Cisco 这份启事展示的却是一个截然不同的变体：重网络、重安全、重事故处理纪律。

如果你的目标是基础设施方向的 FDE 岗位，认真读懂这份启事，就能得到一份未来几年的练习清单。

读完启事，你会发现三份工作

第一是负责客户。启事写明，FDE 将主导一组预先分配的大型或战略级 SSE 客户的技术关系。换句话说，你有自己的客户名单，他们一出问题，第一个打电话找的就是你。

第二是处理升级工单，按跨时区的“日不落”模式轮值。第三用启事原话来说：客户反复遇到的问题，必须以具体需求的形式反馈到产品和工程路线图中。

这三项工作都伴随着不轻松的工作条件：启事要求最多 50% 的时间出差，范围包括美国国内和海外，去客户办公室和工程中心。第一轮面试就要问清楚出差和值班安排。

经验门槛也写得很直白：7 年以上网络或安全经验，并有直接负责客户的经历。

网络第一，代码第二

启事列出的技术要求包括 DNS、路由、IPsec 隧道、TLS、SAML、安全 Web 网关（SWG）/Web 代理和云网络，外加 5 年以上企业环境中的身份认证与 SSO 集成经验（SAML/OIDC、SCIM）。

在 SSE 产品里，每一项都是可能出故障的地方：DNS 和路由决定流量是否经过服务，IPsec 把分支机构连到云端，TLS 是做内容检查的环节，SAML 负责身份认证。

这些要求全是协议和基础设施，而不是编程语言。在这类岗位上，最有用的代码通常是用来诊断和复现故障的小脚本，比如下面这个：

import socket, ssl

DOMAINS = ["app.example.com", "login.example.com"]

for host in DOMAINS:
    try:
        ip = socket.gethostbyname(host)
        ctx = ssl.create_default_context()
        with socket.create_connection((host, 443), timeout=5) as s:
            with ctx.wrap_socket(s, server_hostname=host) as t:
                issuer = dict(x[0] for x in t.getpeercert()["issuer"])
        print(host, ip, "证书签发方:", issuer.get("organizationName"))
    except socket.gaierror as e:
        print(host, "DNS 错误:", e)
    except ssl.SSLError as e:
        print(host, "TLS 错误:", e)
    except OSError as e:
        print(host, "连接错误:", e)

如果证书签发方是代理的 CA 而不是公共 CA，就说明流量正在被解密检查。仅凭这一个细节，就能把一起登录事故拆成两条排查线索。

一份干净的升级工单长什么样？

落到实践中，启事要求的“精确、可复现的技术证据”指的是日志、pcap、去掉敏感信息的配置，以及复现故障的步骤。回到开头的登录循环，一份干净的升级工单可以这样写：

标题：开启 TLS 检查后，分支 B 出现 SAML 循环
范围：仅分支 B，部分用户受影响；分支 A 正常
开始时间：配置变更后立即出现（附时间和变更工单）
已验证：
  - 客户端 pcap：IdP 站点的证书由代理的 CA 签发
  - 在实验室中对 IdP 域名关闭检查 -> 故障消失（附复现步骤）
未验证：
  - 会话 cookie 在代理处被剥离的假设（AI 根据日志给出的建议，pcap 尚未证实）
附件：代理日志、pcap、已脱敏配置
诉求：确认 IdP 域名的预期行为；客户目前使用临时例外规则

“未验证”这一栏很多人会跳过，恰恰它最重要。启事允许用 AI 分析日志，但要求判断可靠，任何未经验证的结论都不能交给任何人，无论是客户还是工程团队。

从第三张工单到一条路线图需求

假设你名单上的第三个客户遇到了一模一样的故障。这时，逐个客户修补已经不够了。启事要求 FDE 把这类重复出现的模式变成具体需求，而抱怨和具体需求有三点区别：

产品团队能排进路线图的，是范围清楚、验证方法清楚的事情。PostHog 的员工手册描述了另一家公司的同一原则：当客户被只有产品团队才能解决的问题卡住时，FDE 要把问题交给负责的团队；有些团队更喜欢异步的书面说明，有些则希望你参加他们的站会。

所以在发出任何东西之前，先问接收团队喜欢哪种形式，然后自己把问题范围界定清楚，并写下如何验证修复。

如何准备

先搭一个小实验环境：两台通过 IPsec 隧道相连的云虚拟机、一个自托管且开启 TLS 解密的代理，以及一个通过 SAML 登录的应用。逐层故意制造故障，抓 pcap，再为你刚制造的故障写一份升级工单。启事要求的可复现证据，就是这样练出来的。

接下来是简历。启事强调“直接负责客户”，所以别写“支持企业客户”这种泛泛的话。写清楚你负责过多少个客户、一次你从头跟到尾的升级工单，以及一条你推进进路线图的产品需求。

这种端到端的负责并非 Cisco 独有。Nexus IT Group 的 FDE 职业指南写道，架构听起来没问题并不代表工作完成，只有系统在客户环境里跑起来才算完成。

如果你只有三四年经验，就把这份启事当作未来几年的路线图，挑那些能让客户记住你名字的工作去做。

让优秀候选人折戟的错误

要避免的一个错误是，看到“FDE”就以为是 AI 岗位。启事列出的技能围绕 TLS、SAML 这类内容展开；AI 只是作为辅助读日志的工具被提及，前提是判断可靠。

另一个错误是把事故经历讲成个人英雄故事，却说不清自己是如何区分已验证事实和猜测的。

第三个错误看似小，杀伤力却一样大：发出未脱敏、仍带客户信息的原始配置。对安全产品来说，在升级工单里泄露客户数据，会彻底毁掉你的信誉。

一个 45 分钟的练习

用上面的脚本检查两个你常登录的域名，一次在家庭网络下运行，一次开启 VPN 或公司代理后运行。如果证书签发方变了，就把它当作一起“事故”，用上面的模板写一份升级工单：范围、证据、复现步骤，“未验证”一栏至少写一行。

然后把这份说明交给同事。如果对方一个问题都不用问就明白发生了什么，你写出的就是这个岗位需要的升级工单。

在这个岗位上，你最大的价值是值得信任：工程团队打开你的升级工单，马上就知道不必从头重做这些工作。