简历

面试官，你好，我是某某，目前从事9年的运维工程师经验。擅长linux服务器业务应用搭建、中间件、数据库部署和管理，公司内网系统搭建（jira、confluence、域名管理系统、导航栏、制品库等）

自动化流水线部署、监控搭建和设置、日志平台、shell、python脚本编写、问题排查，熟悉系统、网络、安全和存储。介绍前面两份工作经历，在aa科技有限公司，公司是做b端产品，负责银行

智能问答和智能外呼产品的服务器管理和维护、版本功能发布、脚本编写、版本发布文档编写，问题排查等，在公司做过的项目有智能外呼和智能问答国产化双中心改造，我在这个项目中主要负责

各个功能基础环境搭建和应用部署，验证功能完整性、解决运维相关的疑难问题。在bb科技有限公司，负责公司所有产品应用维护，服务器管理和维护，云平台管理、应用搭建，问题排查等，在公司

做的项目有量化回测平台和saas平台，我在这个项目负责服务器创建，应用流水线部署配置，配置监控，日志收集等。我个人比较喜欢ai技术，有关注和使用国外和国内ai大模型的习惯，喜欢编写技术文档，

有个人的技术博客，有一个Kubernetes cka的认证

面试官，您好，我是某某，一名拥有9年经验的高级运维工程师。
我擅长Linux服务器应用搭建、中间件和数据库的部署与管理，以及公司内网系统的构建（如Jira、Confluence、域名管理系统等）。在自动化流水线部署、监控系统搭建、日志平台管理、Shell和Python脚本编写、以及系统、网络、安全和存储方面都有丰富的经验。

在我的职业历程中，我曾在aa科技有限公司负责银行智能问答和智能外呼产品的服务器管理与维护。在一个国产化双中心改造项目中，我负责基础环境搭建与应用部署，成功缩短了系统部署时间20%，并通过自动化脚本显著减少了故障排查时间。此外，我还在bb科技有限公司负责量化回测平台和SaaS平台的运维工作，优化了流水线部署流程，提升了系统稳定性，降低了30%的运维成本。

我个人对AI技术有浓厚兴趣，经常关注国内外AI大模型的发展，并且拥有Kubernetes CKA认证。我也喜欢通过技术博客分享经验，持续提升自己的技术水平。

我希望在未来的工作中，能够继续深耕运维领域，结合AI和云原生技术，推动公司技术架构的持续优化和创新。

k8s问题排查经验：https://blog.yufenglab.cn/categories/kubernetes/2024/12/05/k8s%E6%95%85%E9%9A%9C%E6%8E%92%E6%9F%A5-%E7%BD%91%E7%BB%9C%E8%BD%AC%E5%8F%91

影响深刻的技术问题

1.线上mysql proxy层vip出现故障

监控出现交易量下降，业务验证问答出现超时

排查问答接口日志，出现数据库插入数据报错，联系系统组排查数据库

数据库出现锁表，数据有往主和从都有写入，排查mysql proxy节点有异常进程，杀掉恢复，结果是mysql proxy有版本bug，后续联系厂商支持解决。

2.版本程序崩溃

看日志，使用工具拿内存崩溃日志

3.录音不全

抓包拿数据到wireshark分析

4.版本问题解决

浏览器F12，根据接口服务排查对应日志

5.一般问题排查步骤

网络、系统资源、中间件、应用日志、数据库

6.k8s调度问题排查

业务反馈：在高峰期某个接口功能出现访问缓慢

同一个节点不同程序在高峰期出现资源抢夺。解决方法，将程序部署到其它节点

排查步骤：

Kubernetes应用性能问题解决步骤

1. 问题初步排查与资源配置优化

操作步骤：

  1. 调整资源分配
    • 关键点
      requests应接近日常平均负载，limits设置需留有弹性空间避免频繁资源争抢。

修改Deployment/Pod的YAML文件，合理设置requests和limits，示例如下：

resources:
  requests:
    cpu: "500m"   # 基准需求
    memory: "512Mi"
  limits:
    cpu: "2000m"  # 峰值上限
    memory: "2048Mi"

检查现有资源配置

kubectl describe pod <pod-name> -n <namespace> | grep -i "requests\|limits"
kubectl get deployments -n <namespace> -o yaml | grep resources -A5

确认应用的 requests/limits 是否与真实负载匹配，是否存在明显低估（如CPU限流或OOM崩溃）。

2. 节点负载均衡与调度器调优

操作步骤：

  1. 调整Kubernetes调度策略
    • 修改调度器权重：优化负载感知
      修改调度器配置文件（如自定义调度器Profile），增加NodeResourcesBalancedAllocation插件权重。

部署资源重平衡工具（如Descheduler）
定期清理不均衡的Pod，触发重新调度：

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  RemovePodsViolatingNodeAffinity:
    enabled: true

污点与容忍：为过载节点打污点，迁移非核心Pod

kubectl taint nodes <node-name> overload=true:NoSchedule

设置节点反亲和性：避免同类Pod扎堆

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: app
              operator: In
              values: [my-app]
        topologyKey: "kubernetes.io/hostname"

诊断节点资源分布

kubectl top nodes          # 查看节点实时负载
kubectl describe nodes | grep -A10 "Allocated resources" # 看资源分配占比

3. 解决应用间资源竞争

操作步骤：

  1. 隔离高资源消耗应用

优先级调度（PriorityClass）
为关键应用配置高优先级，抢占资源时占优：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000

资源配额（ResourceQuota）：限制资源的过度占用

apiVersion: v1
kind: ResourceQuota
metadata:
  name: per-ns-quota
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi

基于节点分组：将关键应用调度到专用节点池

nodeSelector:
  dedicated: high-priority

4. 应用性能深度调优

操作步骤：

  1. 性能剖析与基准测试
    • CPU/内存火焰图：使用pprof或perf抓取热点函数。
    • 数据库优化：检查慢查询日志，添加索引或分库分表。
    • 网络分析：通过kubectl trace或tcpdump检查跨Pod通信延迟。
  2. 调整应用参数
    • Java应用优化JVM参数（堆大小、GC策略）。
    • 微服务场景下启用连接池（如HikariCP）、熔断器（如Sentinel）。

服务网格（Service Mesh）调优
启用Istio链路级超时和重试控制：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
    - route:
        - destination:
            host: my-svc
      timeout: 5s
      retries:
        attempts: 3
        perTryTimeout: 2s

5. 验证与长期防护

操作步骤：

  1. 扩缩容策略加固
    • 启用Cluster Autoscaler自动伸缩节点池。
  2. 监控与告警增强
    在Prometheus中配置关键阈值（如Pod重启次数、节点CPU>90%持续5分钟），联动Slack/邮件告警。

根据监控指标（CPU/内存/QPS）配置HPA：

kubectl autoscale deployment my-app --cpu-percent=70 --min=3 --max=10

压力测试验证

# 使用Vegeta或Locust发起负载测试
echo "GET http://my-app" | vegeta attack -duration=300s | vegeta report

最终效果

通过上述步骤，最终实现：

  1. 节点间负载差异从±40%降低到±15%
  2. 应用P99延迟从2s降至200ms
  3. 尖峰时段自动扩容耗时从10分钟缩短至2分钟

附件示例
可附上kube-scheduler自定义配置片段、HPA策略YAML模板等辅助工具文件（如有需要可补充）。