|

网络设备故障应急预案

文档版本： 1.0
生效日期： 2025年8月27日
最后修订： 2025年8月27日
编制部门： IT运维部 / 网络安全部
审核： [相关负责人姓名/职位]
批准： [相关负责人姓名/职位]

1. 目的

本预案旨在建立一套系统化、标准化的响应流程，以应对核心网络设备（包括但不限于核心/汇聚/接入交换机、路由器、防火墙、负载均衡器）发生故障时的紧急情况。通过快速、有序地响应，最大限度地减少网络中断时间，保障关键业务系统的连续性，降低对业务运营和用户的影响，并确保故障得到有效诊断和恢复。

2. 适用范围

本预案适用于公司内部所有核心网络设备（交换机、路由器、防火墙、负载均衡器）发生的计划外故障、性能严重下降或安全事件导致的网络中断或服务不可用。

3. 应急原则

  • 业务优先： 优先恢复对关键业务系统和用户影响最大的网络服务。
  • 快速响应： 建立7x24小时响应机制，确保故障被及时发现和处理。
  • 最小影响： 在故障处理过程中，采取措施将对正常业务的影响降至最低。
  • 安全第一： 所有操作需符合安全规范，避免引入新的安全风险。
  • 信息透明： 及时、准确地向相关方通报故障状态和处理进展。
  • 持续改进： 故障解决后进行复盘，总结经验教训，优化预案和预防措施。

4. 组织与职责

  • 应急指挥小组 (EIC - Emergency Incident Command):
    • 成员： IT总监/CTO、网络主管、系统主管、安全主管、关键业务部门代表。
    • 职责： 负责应急响应的总体指挥、资源协调、重大决策（如是否切换至灾备、是否对外发布信息）、对外沟通。在重大故障时启动。
  • 网络应急响应小组 (NER - Network Emergency Response Team):
    • 成员： 网络工程师（主责）、系统工程师（支持）、安全工程师（支持）、值班工程师。
    • 职责： 负责故障的初步诊断、定位、执行恢复操作、信息收集与上报、执行预案步骤。是故障处理的核心执行团队。
  • 支持与沟通组：
    • 成员： IT服务台、行政/公关部门。
    • 职责： 负责接收用户报障、内部信息通报、对外（客户、合作伙伴）沟通协调、发布公告。

5. 预警与监测

  • 监控系统：
    • 部署专业的网络监控系统（如 Zabbix, Nagios, PRTG, SolarWinds, 或云厂商监控服务），对所有核心网络设备的：
      • 连通性 (Ping/ICMP)
      • CPU/内存利用率
      • 端口状态 (Up/Down)
      • 端口流量 (In/Out)
      • 关键进程/服务状态 (如 BGP, OSPF, HSRP/VRRP, 防火墙策略引擎)
      • 日志告警 (Syslog)
      • 设备温度、电源、风扇状态
    • 设置合理的阈值告警（如 CPU > 80% 持续5分钟，端口Down，关键进程停止）。
  • 日志审计：
    • 集中收集所有网络设备的系统日志(Syslog)和安全日志，进行分析，识别潜在异常模式。
  • 用户报障：
    • 建立清晰的用户报障渠道（如IT服务台电话、邮箱、工单系统）。

6. 应急响应流程

6.1 故障发现与报告

  1. 监控告警： 监控系统触发告警，自动通知NER成员（短信、邮件、电话）。
  2. 用户报障： 用户通过服务台报障，服务台记录详细信息（现象、影响范围、时间）并立即升级至NER。
  3. 主动巡检： 值班工程师在巡检中发现异常。
  4. NER确认： NER成员收到信息后，立即登录监控系统和设备，初步确认故障属实。

6.2 初步评估与分级

  • NER根据故障影响范围、业务关键性、持续时间进行初步故障分级：
    • 一级（重大）： 核心设备（如核心交换机、出口路由器、主防火墙）完全宕机或关键链路中断，导致大部分或全部业务中断，影响范围广，业务损失巨大。立即启动最高级别响应。
    • 二级（严重）： 汇聚/重要接入交换机、关键业务区域防火墙/负载均衡故障，导致关键业务系统部分或全部中断。立即响应。
    • 三级（一般）： 接入层设备故障、非关键链路中断、性能下降，影响局部用户或非核心业务。尽快响应。
    • 四级（轻微）： 设备单板/电源故障但冗余正常、端口误码率高但未中断，有潜在风险。记录并安排后续处理。
  • 评估内容： 影响哪些业务系统？影响哪些用户群体？预计恢复时间？是否有备用/冗余路径？

6.3 应急处置 (按设备类型)

通用步骤 (所有设备)

  1. 信息收集：
    • 记录故障发生时间、现象。
    • 登录设备（Console口优先，或管理口/跳板机），查看系统状态 (show version, show inventory, show environment)。
    • 检查关键进程/服务状态 (show processes cpu/memory, show ip bgp summary 等)。
    • 查看系统日志 (show logging)，寻找故障前后的错误、告警信息。
    • 检查配置变更历史（确认近期是否有变更）。
    • 检查物理连接（光纤/网线、指示灯）。
  2. 隔离与保护：
    • 如果怀疑是配置错误导致，立即备份当前配置。
    • 如有必要且安全，将故障设备或端口从网络中隔离（如关闭端口），防止问题扩散。
  3. 尝试快速恢复：
    • 重启服务/进程： 尝试重启故障相关的服务或进程（谨慎操作）。
    • 切换主备/冗余： 如果设备是HA集群（如防火墙、负载均衡、堆叠/虚拟化交换机、双机热备路由器），立即执行主备切换。这是最快速的恢复手段。
    • 重启设备： 作为最后手段，在确认无更好办法且业务急需恢复时，可尝试重启设备。务必先备份配置！ 重启前评估风险（如无状态切换的设备重启可能导致短暂中断）。

特定设备补充措施

  • 交换机 (Switch):
    • 检查端口状态 (show interface status, show interface <int>)，看是否有大量CRC错误、冲突、丢包。
    • 检查STP状态 (show spanning-tree)，看是否有根桥切换或阻塞端口异常。
    • 检查VLAN配置和Trunk状态。
    • 检查堆叠/虚拟化状态 (show stack, show virtual-chassis)。
    • 如果是接入层，检查是否环路（端口大量流量、CPU飙升）。
  • 路由器 (Router):
    • 检查路由表 (show ip route)，看关键路由是否丢失。
    • 检查邻居状态 (show ip bgp neighbors, show ip ospf neighbor)。
    • 检查NAT、ACL配置是否正确。
    • 检查WAN链路状态和协议（如PPPoE, MPLS）。
  • 防火墙 (Firewall):
    • 安全第一！ 任何操作需评估安全影响。
    • 检查安全策略、NAT规则是否生效。
    • 检查会话表 (show conn, show session)，看是否有异常连接或耗尽。
    • 检查IPS/IDS、防病毒等安全引擎状态。
    • 检查HA同步状态和主备切换。
    • 严禁在故障排查中随意放宽安全策略！
  • 负载均衡器 (Load Balancer):
    • 检查虚拟服务（Virtual Server）状态。
    • 检查池（Pool）和池成员（Pool Member）的健康状态。
    • 检查监控（Monitor）是否正常。
    • 检查SSL证书状态（是否过期）。
    • 检查HA状态和主备切换。
    • 检查连接数、并发数是否达到上限。

6.4 升级与协作

  • 如果NER在规定时间内（如30分钟内）无法定位或恢复一级/二级故障，立即升级至应急指挥小组(EIC)。
  • EIC协调更多资源（如厂商技术支持、高级专家）、决策是否启动灾备方案、批准高风险操作。
  • 需要系统、安全团队配合时，及时沟通协作。

6.5 信息通报

  • 内部通报：
    • NER及时向EIC和支持沟通组通报故障状态、影响、处理进展。
    • 支持沟通组（IT服务台）向受影响的用户/部门发布简明扼要的故障通告（避免过多技术细节）。
    • 重大故障需向管理层定期汇报。
  • 外部通报 (如适用)：
    • 由公关/行政部根据EIC决策，向客户、合作伙伴发布官方声明（如SaaS服务中断）。

6.6 恢复验证

  • 故障处理后，必须进行验证：
    • 确认监控系统显示设备状态正常。
    • 从不同位置测试关键业务系统访问是否正常。
    • 检查网络性能（延迟、丢包）是否恢复正常。
    • 确认所有冗余/HA机制已恢复正常状态。
  • 只有验证通过，才能宣布故障解决。

6.7 后续处理

  1. 故障关闭： 在工单系统中关闭故障工单，记录最终解决方案。
  2. 根本原因分析 (RCA - Root Cause Analysis): 组织相关工程师进行深入分析，查明根本原因（硬件故障？软件Bug？配置错误？外部攻击？环境问题？）。
  3. 撰写报告： 编写详细的故障报告，包含：时间线、现象、影响、处理过程、根本原因、解决方案、经验教训。
  4. 预案修订： 根据RCA结果，修订本应急预案，补充新的处理步骤或预防措施。
  5. 预防措施： 实施改进措施，如：
    • 更新设备固件/软件。
    • 优化配置。
    • 增加监控项。
    • 补充备件。
    • 加强变更管理流程。
    • 组织培训或演练。
  6. 知识库更新： 将故障案例和解决方案更新到IT知识库。

7. 预防措施

  • 冗余设计： 关键设备（核心、防火墙、负载均衡）必须部署高可用（HA）方案（主备、主主、堆叠、虚拟化）。
  • 定期维护：
    • 定期进行设备健康检查（巡检）。
    • 定期备份配置文件（自动化脚本）。
    • 制定并执行设备固件/软件升级计划（在维护窗口进行）。
  • 变更管理： 严格执行变更管理流程，所有配置变更需审批、测试、备份、记录。
  • 备件管理： 建立关键设备的备件库（如电源、风扇、主控板、整机）。
  • 环境保障： 确保机房环境（温度、湿度、电力、UPS）符合要求。
  • 文档完善： 维护最新的网络拓扑图、IP地址规划、设备清单、配置文档、联系人列表。
  • 培训与演练： 定期对NER成员进行技术培训和应急预案演练（如模拟主备切换、断电恢复），确保熟练掌握流程。

8. 附录

  • 附录A：关键网络设备清单及位置
  • 附录B：网络拓扑图
  • 附录C：联系人列表 (内部 & 厂商技术支持)
  • 附录D：常用诊断命令速查表 (按厂商：Cisco, H3C, Huawei, Juniper, F5, Palo Alto等)
  • 附录E：配置备份脚本/工具说明
  • 附录F：故障报告模板

重要提示：

  • 定制化： 此预案为通用框架，必须根据您组织的实际网络架构、设备型号、业务流程和人员结构进行详细填充和调整。特别是附录部分。
  • 演练： 预案的有效性依赖于定期的演练。至少每年进行一次桌面推演或实战演练。
  • 更新： 网络环境是动态变化的，预案需要定期（如每年）审查和更新，确保其时效性。
  • 权限： 明确各角色的操作权限，特别是涉及高风险操作（如重启核心设备、修改防火墙策略）的授权流程。

通过实施和不断完善此预案，可以显著提升组织应对网络设备故障的能力，保障业务的稳定运行。

|

安装包下载路径
https://www.oracle.com/cn/database/technologies/oracle-database-software-downloads.html#19c

一、安装前准备

1.关闭防火墙，禁止防火墙开机自启

systemctl stop firewalld.service --关闭防火墙
systemctl disable firewalld.service -- 禁止防火墙开机启动
systemctl status firewalld.service  -- 查看防火墙状态

关闭防火墙

2.关闭selinux

vi /etc/selinux/config -- 编辑文件
SELINUX=disabled  --修改

|

一,主库前期操作

两台服务器,一台主库,一台从库

01,配置主库hosts

cat /etc/hosts
192.168.0.31 node12c01
192.168.0.32 node12c02

|

Oracle12C–DG Far Sync 部署(前提为搭建好12C的DG)

一,理解同步异步模式

01, 使用LGWR 进程的SYNC 方式

1）Primary Database 产生的Redo 日志要同时写到日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（Network Server Process），再由LNSn（LGWR Network Server process）进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。

2）LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database 上的事务才能提交，这也是SYNC的含义所在。

3）Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。

4）Primary Database的日志切换也会触发Standby Database 上的日志切换，即Standby Database 对Standby Redo Log的归档，然后触发Standby Database 的MRP或者LSP 进程恢复归档日志。

|

Hey ChatGPT, can you write iRules?

iRules allow you to parse the payload of the data passing through the BIG-IP and, at wire speed, execute an entire script of commands on that traffic.
They allow you to log and redirecting traffic, modify the URI or port or to rewrite the payload itself.
iRules and their almost endless capabilities to customize the behavior of F5 Networks’ BIG-IP are one the unique selling point of BIG-IP.
Many users of devcentral ask for help with their iRules, consultants who can write or troubleshoot iRules are sought after by many of F5s’ customers.
I was wondering how well the new cool kid in town, ChatGPT, performs at writing iRules and how many of the most seen iRules questions on devcentral it can actually answer.
Find the most requested iRules
I tried to figure out what challenges devcentral users most often look for help with and came up with a list of usual iRule code questions.

|

Accessing TCP Options from iRules

I’ve written several articles on the TCP profile and enjoy digging into TCP. It’s a beast, and I am constantly re-learning the inner workings. Still etched in my visual memory map, however, is the TCP header format, shown in Figure 1 below.

Since 9.0 was released, TCP payload data (that which comes after the header) has been consumable in iRules via the TCP::payload and the port information has been available in the contextual commands TCP::local_port/TCP::remote_port and of course TCP::client_port/TCP::server_port. Options, however, have been inaccessible. But beginning with version 10.2.0-HF2, it is now possible to retrieve data from the options fields.