[TOC]

Markdown写博客比较简单，之前专门做了一个博客网站，用的hexo，直接上传MD格式文件即可。为了对Markdown有更深入的了解，看哪些工具更适合MD编辑，于是又进行了一番探索。

Texts

免费，安装后还需要补装一个Paddoc的插件。用Texts打开已写完的一个md文档，发现其将原有格式都改了，改的更加复杂了。

Typora

被很多大神举荐，但是要收费。破解不好搞，尝试下一个试试。

Markdown 的应用场景

技术文档编写

在软件开发领域，Markdown 已成为技术文档的标准格式。它特别适合：

• API 文档：清晰的标题层次和代码块展示，让 API 说明既专业又易读。许多 API 文档生成工具（如 Swagger）都支持 Markdown 格式的描述。
• 项目说明：从安装指南到使用手册，Markdown 能够有效组织技术信息。代码示例、配置文件、命令行操作都能得到恰当的展示。
• 开发规范：团队的编码规范、设计准则、工作流程等都可以用 Markdown 编写，方便团队成员查阅和更新。

博客文章创作

现代的博客平台和静态网站生成器大多支持 Markdown：

• 内容管理：博主可以专注于内容创作，而不必担心复杂的 HTML 编码。文章的格式化通过简单的标记即可完成。
• 平台迁移：使用 Markdown 编写的文章可以轻松在不同平台间迁移，不会因为平台特有的格式而被锁定。
• 离线编写：可以在任何文本编辑器中离线编写文章，然后批量发布，提高了写作的灵活性。

GitHub README 文件

GitHub 平台广泛使用 Markdown，特别是项目的 README 文件：

• 项目介绍：清晰展示项目的目的、特性、使用方法等关键信息。
• 安装指南：通过代码块和列表，提供详细的安装和配置步骤。
• 贡献指南：说明如何参与项目开发，包括代码规范、提交流程等。
• 问题跟踪：在 Issues 和 Pull Requests 中，开发者使用 Markdown 来描述问题、提供解决方案。

笔记记录和知识管理

Markdown 正成为数字笔记的首选格式：

• 学习笔记：支持数学公式、代码高亮、图表等多种内容类型，适合技术学习和知识整理。
• 会议记录：清晰的标题结构和列表格式，让会议要点一目了然。
• 知识库建设：企业和个人都在使用 Markdown 构建知识库，通过链接和标签组织信息。

在线写作平台

越来越多的写作平台开始支持 Markdown：

• GitHub、简书、知乎：这些平台的编辑器支持 Markdown 语法，让创作者能够快速格式化文章。
• GitBook、Notion：专业的文档和笔记平台，原生支持 Markdown，提供强大的组织和协作功能。
• 静态博客生成器：Jekyll、Hugo、Hexo 等工具让用户能够用 Markdown 创建专业的网站。

有用的书籍

《了不起的Markdown》

Markdown 编辑器

工欲善其事，必先利其器，选择一个合适的编辑器对学习 Markdown 至关重要：

1、专业代码编辑器

Visual Studio Code：微软开发的免费编辑器，通过安装 Markdown 相关扩展，可以获得强大的编辑和预览功能。

VScode 安装教程：https://www.runoob.com/vscode/vscode-tutorial.html

VScode 支持 Markdown 的扩展包括：

• Markdown All in One：提供快捷键、目录生成、数学公式支持
• Markdown Preview Enhanced：增强的预览功能，支持图表和演示模式
• markdownlint：语法检查和格式规范

Sublime Text：轻量级但功能强大的编辑器，通过包管理器可以安装 Markdown 相关插件。

Atom：GitHub 开发的编辑器（已停止维护），但仍有丰富的 Markdown 插件生态。

2、专门的 Markdown 编辑器

• Mark Text：开源的实时预览 Markdown 编辑器，界面简洁，功能完整。下载地址：https://github.com/marktext/marktext/
• Zettlr：学术写作导向的 Markdown 编辑器，支持引用管理和论文写作功能。下载地址：https://github.com/Zettlr/Zettlr
• Joplin：免费开源的支持 markdown 免费的笔记应用 – https://joplinapp.org/

3、在线编辑器

• Markdown 在线编辑器：https://www.jyshare.com/front-end/712/。
• Dillinger：https://dillinger.io/，功能齐全的在线 Markdown 编辑器，支持云同步和多种导出格式。
• StackEdit：https://stackedit.io/，基于浏览器的编辑器，与 Google Drive、Dropbox 等云服务集成。
• 简书、语雀编辑器：国内平台提供的在线 Markdown 编辑环境。

在 Linux系统中，查看端口使用情况是运维和故障排查的常见操作。

以下是几种常用的命令和方法：

1 使用 netstat 命令（经典方法）

⚠️ 注意：netstat 已逐渐被 ss 取代，但在大多数系统上仍可用。

1
2
3
4
5
6
7
8

#查看所有监听的TCP/UDP端口
netstat -tuln

#查看所有连接（包括监听和已建立的连接）
netstat -tunlp

#查看特定端口（如80）
netstat -tunlp | grep :80

参数说明：

-t：显示 TCP 端口 -u：显示 UDP 端口 -l：仅显示监听状态的端口（LISTEN）
-n：以数字形式显示地址和端口（不解析域名） -p：显示占用端口的进程（需 root
权限）

2 使用 ss 命令（推荐，更高效）

ss 是 netstat 的现代替代品，速度更快。

1
2
3
4
5
6
7
8

#查看所有监听的TCP端口
ss -tuln

#查看所有连接
ss -tunlp

#查看特定端口（如3306）
ss -tunlp | grep :3306

参数与 netstat 类似，但执行效率更高。

3 使用 lsof 命令（功能强大）

1
2
3
4
5
6
7
8

#查看所有监听端口
lsof -i -P -n | grep LISTEN

#查看特定端口（如22）
lsof -i :22

#查看特定协议（如TCP）
lsof -i tcp

优点： 可以精确查看某个端口被哪个进程占用。

4 查看端口是否被占用（快速检查）

=================================

1
2
3
4
5

#检查80端口是否被占用
lsof -i :80

#或使用 netstat/ss
ss -tuln | grep :80

5 查看防火墙开放的端口（系统级）

=================================

对于 firewalld（CentOS/RHEL 7+）

1
2
3

#查看已开放的端口
firewall-cmd --list-ports
firewall-cmd --list-all

对于 ufw（Ubuntu）

1

ufw status

对于 iptables

1

iptables -L -n

6 使用 nmap 扫描本地或远程端口（需安装）

=========================================

1
2
3
4
5
6
7
8

#扫描本机开放端口
nmap localhost

#扫描远程服务器
nmap 192.168.1.100

#扫描特定端口范围
nmap -p 1-1000 localhost

实用示例

1
2
3
4
5
6
7
8

#查看谁在占用3000端口
lsof -i :3000

#查看所有监听端口及对应进程（需root）
sudo ss -tulnp

#仅查看TCP监听端口
ss -tnl

总结

🔐 提示：部分命令（如显示进程信息）需要 root 或 sudo 权限。

通过这些命令，你可以轻松掌握 Linux 系统中端口的使用情况。

网络设备故障应急预案

文档版本： 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.

体验用Markdown来写一篇博客文章

安装完hexo后，这发布文章得用命令来操作，查了Markdown才知道这种简易格式。