猿急送>

其他运维兼职程序员

ID：426675

Liabob

网络运维

公司信息：
百度公司

工作经验：
3年

兼职日薪：
500元/8小时

兼职时间：
可工作日远程

所在区域：
其他
全区

技术能力

我是某211计算机系毕业生，目前从事网络运维工作。坦率地说，计算机专业出身让我有较好的底层知识体系，但网络运维这行，学校里学的东西只是一个起点，真正的本事是在机房、在故障现场、在无数个被报警电话叫醒的深夜里一点点磨出来的。下面我从几个维度梳理自己沉淀下来的技术能力。
一、网络基础设施与路由交换
这是看家本领，没什么好说的。
路由协议：日常工作中大量接触BGP和OSPF，跨域互联、多线BGP接入、路由策略调优、路径操控这些都是常规操作。遇到过BGP路由震荡导致全局抖动，也处理过OSPF区域划分不合理引发的路由环路，踩过的坑都变成了经验。
交换技术：VLAN/SVI、STP/RSTP/MSTP、链路聚合、堆叠与虚拟集群（IRF/VSS），这些基础能力早已内化到本能反应。Trunk放行、Native VLAN这种低级失误，现在已经不可能在我手上发生了。
厂商设备：Cisco（Nexus/ISR/ASR）、Huawei（CE/S系列）、H3C（S系列）均有实际运维经验，CLI操作熟练到可以盲打，能根据设备型号预判不同厂商的默认行为和坑点。
二、网络自动化（核心差异化能力）
这是我和传统“经验型”运维拉开差距的地方，也是计算机系背景给我带来的最大加成。
我始终认为，一个运维的价值不在于能解决多复杂的故障，而在于能让多少故障不再发生，能把多少重复劳动交给机器去做。这个理念驱动着我在自动化这条路上持续深耕。
Python：这是我最顺手的工具。日常用它写巡检脚本（批量ssh/telnet采集设备状态）、配置备份与变更比对、日志异常检测。曾用100多行Python脚本将原本需要2小时的批量配置下发压缩到5分钟内完成，且零手工失误。
Ansible：用Playbook管理设备配置基线，结合Jinja2模板实现多厂商设备的配置渲染，实现网络配置即代码（NaC）的初步落地。配合AWX做定时任务，每周自动生成全网配置合规报告。
NetDevOps工具链：熟悉NAPALM、Netmiko、Scrapli等自动化库，能基于这些开源组件快速搭建内部工具，不做重复造轮子，但也具备在轮子不够用时自己造一个的能力。
Telemetry/SNMP：熟悉gRPC Dial-out订阅机制和SNMP轮询，配合Prometheus+Grafana搭建过全网性能监控面板，能从海量指标中快速

项目经验

项目一：多厂商网络配置合规与自动化变更交付平台（Python + Ansible + NAPALM）
背景与痛点：我接手运维的网络包含Cisco、Huawei、H3C三套体系，日常变更（VLAN扩容、ACL策略调整、BGP邻居新增）全靠手工逐台敲命令。每次变更平均耗时2小时，且曾因手误在核心设备上敲错接口编号导致一次小型中断，被通报批评。
我的行动：利用业余时间，我自主设计了一套基于Python + Netmiko + Ansible + Jinja2的自动化交付平台。核心架构分三层：① 解析层——读取运维工单Excel，自动校验IP地址格式和VLAN ID合法性；② 渲染层——利用Jinja2模板将标准化配置转换为各厂商特有语法，彻底屏蔽命令行差异；③ 执行层——调用Ansible Playbook进行灰度下发（先接入层后核心层），并引入Napalm的compare_config功能做变更前配置备份与回滚预演。我还对接了内部GitLab，每次变更自动打Tag，实现网络配置即代码（NaC）。
量化成果：上线后，单次网络变更时长从平均2小时锐减至8分钟，至今累计执行570+次自动化变更，人为配置失误率归零。这个项目不仅解放了我的日常重复劳动，还被推广到同部门其他运维组复用。
项目二：省级数据中心STP+BGP双重环路故障极速抢修与根因分析
背景与突发：某工作日高峰时段，核心机房突发大面积业务超时。现象是核心交换机CPU利用率瞬间飙升至99%，BGP邻居关系反复振荡（Up/Down交替）。现场一片混乱，此前无人遇到过如此剧烈的连锁反应。
我的行动与思路：到场后我没有盲目重启设备，而是按OODA循环快速收敛。① 观察——通过show process cpu发现STP进程占用异常，同时用嵌入式抓包（Embedded Packet Capture）捕获BGP报文，发现大量重复LSA更新；② 定位——顺着MAC地址漂移日志迅速锁定到一台接入交换机的下联端口存在物理环路（某施工人员误将两根光纤直连），导致BPDU报文成倍放大，进而触发BGP的Hold-time超时震荡；③ 行动与根治——立即shutdown故障端口隔离广播源，同时临时调整BGP路由策略，加入route-damping（路由阻尼）抑制震荡。业务恢复后，我主导编写了详细的RCA（根因分析）报告，并推动全网开启BPDU Guard和Root Guard，从架构层面加固STP域边界。
量化成果：从故障爆发到业务全量恢复用时22分钟，远超SLA要求的1小时标准。事后三个月内，同类环路风险引发的次生故障降为0。
项目三：基于gRPC Telemetry + Kafka的秒级智能监控预警体系搭建
背景与局限：原有基于SNMP轮询的Zabbix监控存在天然短板——轮询间隔最小只能做到15秒，对于微突发（Micro-burst）丢包和队列拥塞完全“看不见”。业务方经常反馈“卡了一下”，但我们的监控曲线一片平坦，运维陷入被动。
我的行动：我主动牵头推进监控架构升级。① 数据采集侧：在核心/汇聚交换机上开启gRPC Dial-out订阅，将接口队列深度、CPU单核利用率、芯片缓存占用率等关键KPI以秒级间隔推送到Kafka消息队列；② 数据处理与存储：编写Python消费者服务，对原始数据进行清洗与聚合，写入InfluxDB时序数据库；③ 可视化与告警：基于Grafana搭建动态仪表盘，并开发独立的Python告警引擎，引入3-Sigma异常检测算法对队列丢包趋势做预测性评分，而非简单固定阈值。
量化成果：新系统上线半年内，成功提前预警3次潜在的链路拥塞风险（均在业务高峰期前完成链路扩容）。网络平均故障发现时间（MTTD）从原来的15分钟骤降至30秒以内，运维模式从“被动挨打式救火”彻底转向“主动防御式巡航”。
这三个项目分别代表了我的工程化交付能力、极限压力下的排障韧性以及架构演进的前瞻视野。如果说前面那一长串技术能力是“兵器库”，那这三个项目就是我用这些兵器实打实打下来的“硬仗”。每个项目背后都有详细的文档、代码片段和排障日志留存，如果后续有机会深入交流，我很乐意展开技术细节或现场推演排障思路。期待与优秀的团队并肩作战。