FDE mảng SSE ở Cisco: 7+ năm mạng, bảo mật và những escalation tái hiện được

Thử hình dung: một khách hàng lớn vừa chuyển traffic web của toàn công ty sang proxy đám mây. Sáng hôm sau, nhân viên ở một chi nhánh bị kẹt trong vòng đăng nhập vô tận vào ứng dụng nội bộ. Đội IT bên khách hàng đổ lỗi cho sản phẩm của bạn, còn đội kỹ thuật bên bạn thì muốn có bằng chứng rồi mới chịu nhận.

Đứng giữa hai bên đó chính là việc mà Cisco mô tả trong tin tuyển Forward Deployed Engineer cho mảng Secure Services Edge (SSE), đăng dưới tên Duo Security.

Tin yêu cầu FDE chịu trách nhiệm trọn vẹn với những escalation phức tạp, giữ kỳ vọng của khách hàng ở mức thực tế và đưa ra bằng chứng kỹ thuật chính xác, tái hiện được.

Lý do để bạn quan tâm là cái nhãn FDE. Vai trò này được Palantir phổ biến, và nhiều người nghe chữ FDE là nghĩ ngay tới AI hay dữ liệu. Tin của Cisco cho thấy một biến thể khác hẳn: nặng về mạng, bảo mật và kỷ luật khi xử lý sự cố.

Nếu bạn nhắm tới các vị trí FDE làm hạ tầng, đọc tin này đúng cách sẽ cho bạn danh sách việc cần luyện trong vài năm tới.

Đọc tin tuyển dụng, bạn thấy ba công việc

Việc đầu tiên là phụ trách khách hàng. Tin viết rằng FDE sẽ dẫn dắt quan hệ kỹ thuật với một nhóm tài khoản SSE lớn hoặc chiến lược đã được chỉ định trước. Nghĩa là bạn có danh sách khách hàng của riêng mình, và khi họ gặp chuyện, người đầu tiên họ gọi là bạn.

Việc thứ hai là xử lý escalation, theo mô hình trực luân phiên theo múi giờ (follow-the-sun). Việc thứ ba nằm ngay trong câu chữ của tin: những vấn đề khách hàng gặp đi gặp lại phải được đưa ngược về roadmap của sản phẩm và kỹ thuật dưới dạng yêu cầu cụ thể.

Cả ba việc đều đi kèm điều kiện làm việc khá nặng: tin yêu cầu đi công tác tới 50% thời gian, trong nước Mỹ lẫn quốc tế, tới văn phòng khách hàng và các trung tâm kỹ thuật. Bạn nên hỏi rõ lịch đi lại và lịch trực ngay từ vòng phỏng vấn đầu tiên.

Ngưỡng kinh nghiệm cũng được ghi thẳng: 7+ năm làm mạng hoặc bảo mật và đã trực tiếp phụ trách khách hàng.

Mạng trước, code sau

Danh sách kỹ thuật trong tin gồm DNS, routing, đường hầm IPsec, TLS, SAML, SWG/proxy web và mạng đám mây, cộng thêm 5+ năm tích hợp danh tính và SSO (SAML/OIDC, SCIM) trong môi trường doanh nghiệp.

Ở một sản phẩm SSE, mỗi thứ là một chỗ có thể hỏng: DNS và routing quyết định traffic có đi qua dịch vụ hay không, IPsec nối chi nhánh lên đám mây, TLS là nơi diễn ra việc kiểm tra nội dung, còn SAML lo phần danh tính.

Các yêu cầu kỹ thuật vừa kể đều là giao thức và hạ tầng, không phải ngôn ngữ lập trình. Với một vai trò như vậy, code hữu ích nhất thường là những script nhỏ để chẩn đoán và dựng lại lỗi, kiểu như dưới đây:

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:", issuer.get("organizationName"))
    except socket.gaierror as e:
        print(host, "DNS error:", e)
    except ssl.SSLError as e:
        print(host, "TLS error:", e)
    except OSError as e:
        print(host, "connection error:", e)

Nếu bên cấp chứng chỉ là CA của proxy chứ không phải CA công khai, bạn biết traffic đang bị giải mã để kiểm tra. Chỉ riêng chi tiết đó đã đủ để chia một sự cố đăng nhập thành hai nhánh điều tra.

Một escalation sạch trông thế nào?

Yêu cầu “bằng chứng kỹ thuật chính xác, tái hiện được” trong tin, khi đem ra thực tế, có nghĩa là log, pcap, cấu hình đã che thông tin nhạy cảm và các bước dựng lại lỗi. Quay lại tình huống vòng đăng nhập ở đầu bài, một bản escalation sạch có thể trông như sau:

Tiêu đề: Vòng lặp SAML tại chi nhánh B sau khi bật TLS inspection
Phạm vi: chỉ chi nhánh B, một số người dùng bị; chi nhánh A bình thường
Bắt đầu: ngay sau thay đổi cấu hình (kèm thời điểm và ticket thay đổi)
Đã kiểm chứng:
  - pcap phía client: chứng chỉ của trang IdP do CA của proxy cấp
  - Tắt inspection cho domain IdP trong lab -> hết lỗi (bước tái hiện đính kèm)
Chưa kiểm chứng:
  - Giả thuyết cookie phiên bị loại bỏ ở proxy (AI gợi ý từ log, chưa có pcap xác nhận)
Đính kèm: log proxy, pcap, cấu hình đã che thông tin
Yêu cầu: xác nhận hành vi mong đợi với domain IdP; khách đang dùng tạm ngoại lệ

Mục “Chưa kiểm chứng” là chỗ nhiều người bỏ qua, nhưng lại quan trọng nhất. Tin cho phép dùng AI để phân tích log nhưng đòi hỏi óc phán đoán chắc tay, và không được đưa kết luận chưa kiểm chứng cho bên nào, cả khách hàng lẫn đội kỹ thuật.

Từ ticket thứ ba thành yêu cầu roadmap

Giả sử đến tài khoản thứ ba trong danh sách của bạn cũng gặp đúng lỗi này. Lúc đó, sửa cho từng khách không còn đủ nữa. Tin yêu cầu FDE biến những mẫu lặp lại như vậy thành yêu cầu cụ thể, và một lời phàn nàn khác một yêu cầu cụ thể ở ba chỗ:

Đội sản phẩm xếp được vào roadmap những thứ có phạm vi rõ và cách kiểm tra rõ. Sổ tay của PostHog mô tả cùng nguyên tắc ở một công ty khác: khi khách bị chặn bởi thứ chỉ đội sản phẩm sửa được, FDE chuyển giao cho đội sở hữu, và có đội thích bản viết async, có đội muốn bạn vào dự standup.

Vì thế, trước khi gửi đi, hãy hỏi đội nhận thích hình thức nào, rồi tự khoanh phạm vi và viết sẵn cách kiểm tra.

Tự chuẩn bị thế nào?

Bắt đầu bằng một lab nhỏ: hai máy ảo trên đám mây nối với nhau bằng một đường hầm IPsec, một proxy tự dựng có giải mã TLS, và một ứng dụng đăng nhập bằng SAML. Cố tình làm hỏng từng lớp, bắt pcap, rồi viết escalation cho chính lỗi mình vừa gây ra. Đó là cách luyện thứ bằng chứng tái hiện được mà tin tuyển dụng đòi hỏi.

Tiếp theo là CV. Tin nhấn vào cụm từ “direct customer ownership”, tức trực tiếp chịu trách nhiệm về khách hàng, nên đừng viết chung chung “hỗ trợ khách hàng doanh nghiệp”. Hãy ghi rõ bạn phụ trách bao nhiêu tài khoản, một escalation bạn đã dẫn từ đầu đến cuối, và một yêu cầu sản phẩm bạn đã đẩy được vào roadmap.

Tinh thần chịu trách nhiệm tới cùng này không riêng gì Cisco. Hướng dẫn của Nexus IT Group về nghề FDE viết rằng việc chưa xong khi kiến trúc nghe có vẻ đúng, mà chỉ xong khi hệ thống chạy được trong môi trường của khách hàng.

Nếu bạn mới có ba hay bốn năm kinh nghiệm, cứ coi tin này là bản đồ cho mấy năm tới, và chọn những công việc cho bạn đứng tên trước khách hàng.

Những lỗi khiến ứng viên giỏi vẫn trượt

Một lỗi nên tránh là thấy chữ FDE rồi mặc định đây là vai trò AI. Các kỹ năng được nêu trong tin xoay quanh những thứ như TLS và SAML, còn AI được nhắc tới như công cụ hỗ trợ đọc log, kèm điều kiện phải phán đoán chắc tay.

Một lỗi khác là kể về sự cố như kể chuyện anh hùng, mà không trình bày được bạn đã tách phần đã kiểm chứng khỏi phần phỏng đoán như thế nào.

Lỗi thứ ba nhỏ hơn nhưng gây hại không kém: gửi cấu hình thô còn nguyên thông tin của khách hàng. Với một sản phẩm bảo mật, để lộ dữ liệu khách trong chính bản escalation là tự làm mất uy tín.

Một bài tập trong 45 phút

Chạy script ở trên với hai domain bạn hay đăng nhập, một lần trên mạng nhà và một lần sau khi bật VPN hoặc proxy công ty. Nếu bên cấp chứng chỉ thay đổi, coi đó là một “sự cố” và viết escalation theo đúng khuôn mẫu ở trên: phạm vi, bằng chứng, cách tái hiện, và ít nhất một dòng trong mục “Chưa kiểm chứng”.

Sau đó đưa bản viết cho một đồng nghiệp đọc. Nếu họ hiểu được chuyện gì xảy ra mà không phải hỏi lại bạn câu nào, bạn đã viết đúng loại escalation mà vị trí này cần.

Ở vị trí này, giá trị lớn nhất của bạn là được tin cậy: đội kỹ thuật mở escalation của bạn ra và biết ngay mình không phải làm lại phần việc đó từ đầu.