LabHub

博客

FDE 技能地图 — 8 个领域的底线、实战线与检验问题

한국어English日本語中文

为什么需要一张地图

第 1 篇讲清了 FDE 是什么职位,这一篇画出这个职位所需技能的全景地图。这里使用的八个领域,与本博客的 FDE 工程师养成 RPG 用作等级轴的八个完全一致:Linux、网络、Kubernetes、数据库、认证与安全、可观测性、云与基础设施、客户沟通。RPG 的设计是领域等级一升,同一份日志就能读出不同的东西——现实的运作方式一模一样。

每个领域写三件事:为什么需要,底线在哪里,实战线在哪里。底线不是目标,而是入场条件。低于它,现场的对话根本无法成立。实战线则是能独自处理该领域问题的水平。八项全部达到实战线的人几乎不存在,也没有必要。三个检验问题若能不卡壳地答出,该领域大致就在实战线上。

Linux

客户服务器的地板几乎总是 Linux,而 SSH 进去的那一刻起就没有 GUI。这里卡住,其他所有领域根本无从下手。

检验问题。收到磁盘已满的告警,按什么顺序排查?如何察觉日志轮转已经停摆?出现权限拒绝错误时,所有者、属组、模式先看哪个?

网络

「连不上」这类报告有一半终结在网络层。而客户环境的网络,永远比文档更复杂。

检验问题。同一个 URL 在服务器上通、在办公电脑上不通,先怀疑什么?DNS 的 TTL 会如何拖慢故障恢复?被防火墙拦住和服务挂掉,在客户端看起来有何不同?

Kubernetes

当今企业客户环境的默认部署单位。如果产品以容器交付,故障诊断的第一屏多半在这里。

检验问题。Pod 停在 Pending 的三个典型原因是什么?容器因内存超限被杀,在哪里确认?Service 存在却连不上,先看选择器还是先看端点?

数据库

客户数据居住的地方,「太慢了」这类报告最常收敛的地方,也是犯错代价最高的地方。

检验问题。昨天还快的查询今天变慢,会立哪些假设?如何找到持有锁的会话?什么情况下加索引反而有害?

认证与安全

FDE 是替别人保管钥匙的人。认证问题属于最难复现的一类故障报告,而权限上的失误是摧毁信任的最短路径。

检验问题。401 和 403 各自意味着什么失败了?令牌有效但认证仍失败,有哪些可能?客户为了省事提出把管理员权限整个给你,应该怎么回答?

可观测性

在陌生环境里,可观测性是唯一的眼睛。换作自家服务你本来就知道的事,在这里必须从日志和指标里重新挖出来。

检验问题。监控先挂了,靠什么掌握系统状态?为什么看分位数而不是平均响应时间?错误日志每秒几百行时,从哪里开始收窄?

云与基础设施

每个客户的云地形都不一样,FDE 就在这片地形上作业。把托管服务的故障与应用故障切分开,是诊断的第一个岔路口。

检验问题。安全组与网络 ACL 有什么区别?怀疑某个可用区故障时查什么?向客户申请云访问权限时,按什么粒度、什么期限申请?

客户沟通

八个领域里唯一不是技术的一个,却是把其余七个交付给客户的通道。RPG 里这个领域等级太低时,即使诊断正确任务也会失败——现实的评分方式一模一样。

检验问题。「什么时候能修好」——还不知道的时候怎么回答?客户笃信一个错误的原因时如何纠正?故障报告的第一段该写什么?

亲手练习

在这张地图上量出自己的位置之后,补空缺最快的方式是动手。

FDE 完全指南系列

评论

还没有评论。

登录后即可发表评论