- 博客(125)
- 收藏
- 关注
RSS订阅原创 【Python】（六）Python 面向对象入门 + 常用库推荐：找到你的学习方向（新手友好版）
不用记复杂语法，先看一个完整例子：定义 “人” 的类，包含 “姓名、年龄” 属性和 “说话” 方法，再创建具体的人（小明、小红）。# 1. 定义类（用class关键字，类名首字母大写，这是约定）# __init__是“构造方法”：创建对象时自动执行，用来初始化属性# self必须放在第一个参数，代表“当前创建的对象”# 给对象绑定属性：self.属性名 = 参数self.name = name # 姓名属性self.age = age # 年龄属性。
2025-11-28 09:45:00
786
原创 【Python】（五）Python 函数与模块：让代码 “复用” 不重复写（进阶基础篇）
函数的语法就像 “制作工具盒”：先明确 “工具需要什么输入（参数）”“工具能产出什么（返回值）”，再写工具的使用逻辑（函数体）。def定义参数时给一个默认值，调用时如果不传入该参数，就用默认值；def print_info(name, age=18): # age默认值18print(f"姓名：{name}，年龄：{age}")# 不传入age，用默认值18print_info("小刚") # 输出：姓名：小刚，年龄：18# 传入age，覆盖默认值。
2025-11-27 07:30:00
453
原创 【Python】（三）Python 流程控制：让代码 “选着走”“重复走”（新手实操版）
上一篇文章里，我们学会了用变量和数据类型存储信息，比如记录成绩、姓名。但如果只让代码从上到下死板执行，根本满足不了实际需求 —— 比如 “成绩≥90 评优秀，≥80 评良好”“重复打印 10 次‘打卡成功’”“让用户反复输入密码直到输对”。这就需要 Python 的 “流程控制” 功能：它能让代码像我们做事一样，“选着走”（满足 A 条件做 A 事，满足 B 条件做 B 事）或 “重复走”（一件事做 N 遍，直到满足要求）。
2025-11-25 07:15:00
665
原创 【Python】（二）Python 基础：变量与数据类型 —— 存储数据的 “快递盒”
1. 定义变量（赋值）：变量名 = 数据（=是赋值符号，不是“等于”）height = 1.75 # 身高1.75米is_student = True # 是否是学生（True表示“是”）# 2. 使用变量：打印变量的值print("身高：", height) # 输出：身高： 1.75print("是否是学生：", is_student) # 输出：是否是学生： True# 3. 修改变量：重新赋值（覆盖原来的值）height = 1.76 # 身高更新为1.76米。
2025-11-24 08:15:00
462
原创 【Python】（一）Python 入门：为什么选它？怎么搭环境？（新手友好版）
刚学的时候，我甚至觉得 “这不像代码，像在写笔记”—— 这种易读性，能让你把精力放在 “逻辑” 上，而不是 “记符号” 上。这部分是 “实操核心”，我会按 “Windows 系统” 和 “macOS 系统” 分别说（Linux 用户大多有基础，暂时不展开），每一步都标清楚 “注意事项”，避免你踩坑。虽然 “Hello World” 很简单，但这代表你已经打通了 “写代码→运行代码” 的全流程 —— 这是编程入门最重要的一步。这些场景不用学很深，掌握基础就能实现，很容易获得 “学会了就能用” 的成就感。
2025-11-23 17:55:47
724
原创 【Hadoop】Hadoop 生态工具——Sqoop 数据迁移工具实战（ 打通 Hadoop 与传统数据库的桥梁）
Sqoop（SQL-to-Hadoop）是基于 Hadoop 的分布式数据迁移工具，核心定位是 “批量数据传输中介”—— 它能将关系型数据库（MySQL、Oracle、SQL Server）中的结构化数据导入到 HDFS、Hive、HBase 等 Hadoop 生态组件，也能将 Hadoop 中的数据导出回关系型数据库，底层通过 MapReduce 实现分布式并行传输，支持亿级数据高效迁移。
2025-11-19 09:30:00
949
原创 【Hadoop】Hadoop 生态工具——HBase 列式数据库安装与 Shell 操作（PB 级数据的分布式存储方案）
HBase 是一个高可靠、高性能、面向列、可伸缩的分布式数据库，核心定位是 “分布式 NoSQL 数据库”—— 它打破了传统关系型数据库的行存储模式，采用列族存储，适合存储稀疏数据（如部分字段频繁更新、部分字段偶尔查询），支持随机读写和批量处理，数据最终存储在 HDFS，计算依赖 Hadoop 生态。这一期我们完成了 HBase 集群的安装配置，掌握了表管理、数据读写、批量操作等核心 Shell 命令。
2025-11-18 09:15:00
1291
原创 【Hadoop】Hadoop 生态工具——Zookeeper 分布式协调服务（Hadoop 生态的 “高可用基石”）
Zookeeper 是一个分布式协调服务，它不存储业务数据，而是存储集群的 “元数据”（如服务地址、节点状态、配置信息），并提供一套简单的 API，帮助分布式系统解决 “一致性” 问题。简单说，Zookeeper 就像分布式集群的 “通讯录 + 调度台”，让各个节点知道彼此的状态，协同完成任务。这一期我们掌握了 Zookeeper 的核心概念（Leader/Follower、Znode、Watcher）、3 节点集群安装配置，以及 Znode 操作、分布式锁等实操。
2025-11-17 07:00:00
720
原创 【Hadoop】Hadoop 生态工具——Hive 数据仓库搭建与基础使用（用 SQL 玩转大数据分析）
Hive 是 Facebook 开源的构建在 Hadoop 之上的数据仓库工具，核心定位是 “SQL 接口 + 数据仓库”—— 它将 HDFS 上的结构化数据映射成 “数据表”，支持用 HQL（类 SQL）语句进行查询、统计、分析，底层自动翻译成 MapReduce/YARN 任务执行，最终结果存储在 HDFS 或本地文件系统。这一期我们完成了 Hive 的完整搭建（MySQL 元数据库 + Hive 服务），并通过 SQL 实操掌握了数据库、数据表、数据加载、查询、导出等核心操作。
2025-11-16 08:15:00
851
原创 【Hadoop】Hadoop 生态工具——Pig 安装与 Pig Latin 脚本入门 （大数据批处理的 “效率神器”）
Pig 是 Apache 开源的大数据批处理工具，核心定位是 “数据流处理引擎”—— 它提供了一套类 SQL 的脚本语言（Pig Latin），允许用户通过一系列操作步骤描述数据处理流程，Pig 会自动将脚本翻译成 MapReduce 任务，在 Hadoop 集群上执行。
2025-11-15 07:45:00
740
原创 【Hadoop】HDFS 文件系统深度解析与 Shell 操作 —— 大数据存储的核心实战
这一期我们深入解析了 HDFS 的核心概念（数据块、副本机制、读写流程），并通过大量实操掌握了 HDFS Shell 命令的核心用法 —— 这些命令是后续所有 Hadoop 生态工具的基础，无论是 MapReduce 任务读取数据源，还是 Hive 存储数据表，都离不开 HDFS 的操作。下一期我们将学习 Hadoop 生态中的 “批处理脚本工具”——Pig。Pig 能通过简单的脚本语言（Pig Latin）处理大规模数据，无需编写复杂的 MapReduce 代码，大幅提升数据处理效率。
2025-11-14 08:45:00
652
原创 【Hadoop】Hadoop 2.0 集群环境搭建（下）—— 核心配置与集群启动
删除默认内容（localhost），添加以下3个节点（hadoop1也作为DataNode）hadoop1hadoop2hadoop3注意：主节点 hadoop1 同时担任 NameNode 和 DataNode，适合小规模集群；生产环境建议 NameNode 与 DataNode 分离部署。这一期我们完成了 Hadoop 2.0 集群的核心搭建，从配置文件修改、集群分发到启动验证，每一步都围绕 “环境一致性” 和 “服务可用性” 展开。
2025-11-13 07:00:00
636
原创 【Hadoop】Hadoop 2.0 集群环境搭建（上）—— 环境准备与基础配置
这一期我们完成了 Hadoop 集群搭建的 “基础准备工作”，核心是确保 “环境一致性” 和 “节点间通信通畅”—— 包括固定 IP、配置 host 映射、关闭防火墙、SSH 免密登录、JDK 安装。这些步骤看似简单，但却是集群稳定运行的关键，很多初学者踩坑都出在 “权限不对”“IP 变化”“免密登录失败” 等基础问题上。下一期，我们将进入核心环节：Hadoop 安装与配置。
2025-11-12 07:45:00
997
原创 【Hadoop】Hadoop核心基础——YARN 框架架构与运行机制（Hadoop 集群的 “资源管家”）
这一期我们拆解了 YARN 的核心架构和运行机制 —— 它的核心价值在于 “解耦” 和 “开放”：解耦了资源管理与任务调度，解决了 Hadoop 1.x 的单点瓶颈；开放了资源接口，让 Hadoop 从 “单一计算框架” 升级为 “分布式计算平台”。有了 YARN 的支撑，Hadoop 生态才能容纳 MapReduce、Spark、Flink 等多样化的计算框架，成为大数据领域的 “基础设施”。
2025-11-11 09:09:49
1321
原创 【Hadoop】Hadoop核心基础——MapReduce 编程模型与数据流（手把手拆解分布式计算的核心逻辑）
Map 函数：负责 “拆分与标记”—— 把输入数据拆分成最小处理单元（如单词），并为每个单元标记 “计数 1”；Reduce 函数：负责 “聚合与计算”—— 把相同标记（如相同单词）的计数结果汇总，得到最终统计值；无需关心分布式逻辑：代码中没有任何 “节点通信”“任务分配” 的逻辑 —— 这些都由 Hadoop 框架自动完成。
2025-11-03 07:45:00
844
原创 【Hadoop】Hadoop核心基础—— 起源与核心组件解析 （大数据时代的分布式基石）
Hadoop 的核心价值，在于它用 “普通硬件 + 分布式架构”，解决了 “海量数据存储与分析” 的痛点 —— 不需要昂贵的小型机，用几十台普通服务器组成的集群，就能处理传统数据库难以承载的 PB 级数据。对于初学者来说，理解 Hadoop 的 “存储 - 计算 - 资源调度” 三位一体架构，是后续学习集群搭建、生态工具（Pig/Hive/HBase）的基础。
2025-11-02 21:01:32
594
原创 Grafana 实战指南：从数据可视化到监控告警，让冰冷数据 “会说话”
在仪表盘页面点击右上角「Add panel」→「Add visualization」；选择数据源为 “Prometheus-Server”，在「Query」栏输入 PromQL 表达式（计算内存使用率）：配置面板样式：点击「Visualization」标签，选择 “Gauge”（仪表盘）；在「Options」中设置阈值（如 “Warning: 80”“Critical: 90”，超过 80 显示黄色，超过 90 显示红色）；在「General」中设置面板标题为 “内存使用率”；
2025-10-30 07:15:00
649
原创 Prometheus 详解：从原理到实战，打造企业级云原生监控体系
Prometheus（中文名 “普罗米修斯”）诞生于 2012 年，最初是 SoundCloud（音乐分享平台）为解决内部监控需求开发的工具，2015 年开源，2018 年成为 CNCF 继 Kubernetes 后的第二个毕业项目。开源的时序数据监控与告警系统，专门用于收集、存储、查询和分析 “按时间顺序排列的指标数据”（比如每 10 秒记录一次服务器 CPU 使用率、每 5 秒统计一次接口调用量）。让你能实时掌握系统 / 应用的运行状态，提前发现故障，快速定位问题。
2025-10-29 22:16:27
846
1
原创 Linux 网络包的一生（第 4 期）：出口篇 —— 从内核到用户空间：Socket 与应用的 “最后交接”
而完成这 “最后一公里” 交接的核心，就是我们常说的 Socket（套接字）。这一期我们就拆解这个交接过程：Socket 到底是什么？内核如何通过 Socket 给应用传递数据？TCP 和 UDP 的 Socket 处理有什么区别？运维中遇到的 “应用收不到数据”“Socket 缓冲区满” 等问题，又该如何定位？
2025-10-27 06:30:00
919
原创 Linux 网络包的一生（第 3 期）：内核篇（下）——Netfilter/iptables：数据包的 “安检站”
位置：数据包经过 PREROUTING 钩子，完成 “路由判断” 后，确定是 “交给本机的包”（不是转发包），在进入传输层（TCP/UDP）之前。作用：最常用的 “入站过滤”—— 控制哪些外部 IP / 端口能访问本机应用，比如 “允许 192.168.1.0/24 网段访问 22 端口（SSH）”“拒绝所有 IP 访问 3306 端口（MySQL）”。生效路径：仅入站本地包（转发包、出站包不经过此钩子）。这是运维中最常配置的钩子点。
2025-10-26 07:45:00
852
原创 Linux 网络包的一生（第 2 期）：内核篇（上）—— 数据包在协议栈的 “分层旅行”
sk_buff（链路层）→ 解析以太网帧头 → 判断本地包 → 解析 IP 头 → 路由判断（确认给本机）→ 解析 TCP/UDP 头 → 找到对应 Socket → 放入接收缓冲区链路层：ARP 缓存错误、MAC 地址冲突会导致包无法被正确识别；网络层：路由缺失、TTL 耗尽、分片失败会导致包被丢弃；传输层：端口未监听、连接状态异常会导致包无法交付应用。
2025-10-25 08:30:00
581
原创 Linux 网络包的一生（第 1 期）：数据包如何 “进入” Linux 系统？从网卡到驱动的底层逻辑
互联网数据包→网线→网卡硬件接收（校验 + 过滤）→存入 Ring Buffer→触发中断通知内核→DMA 拷贝到系统内存→驱动程序封装成 sk_buff→交给内核协议栈这一步是网络包处理的 “第一关”—— 如果网卡丢包、驱动不兼容，后续的路由、iptables、Socket 处理都无从谈起。下一期，我们会继续跟进 sk_buff 的旅程，看看它在 Linux 内核协议栈（链路层→网络层→传输层）里会经历哪些处理。
2025-10-24 08:30:00
475
原创 【计算机网络】第 5 期：实战篇 —— 面试中怎么答网络协议题？从基础到场景的全攻略
结合场景：别只说 “TCP 可靠”，要说 “TCP 适合文件传输，因为丢包会导致文件损坏”；逻辑清晰：用 “首先、其次、最后” 或 “第一步、第二步” 分点，别东拉西扯；主动关联：比如答 DNS 时，主动提 “DNS 默认用 UDP，因为数据量小”，体现知识串联能力。
2025-10-21 08:00:00
691
原创 【计算机网络】第 4 期：应用篇 —— 我们用的 APP，背后靠什么协议？拆透 HTTP/HTTPS、DNS 与应用层逻辑
上一期我们搞懂了传输层的核心：TCP 靠 “确认 + 重传” 抗丢包，UDP 靠 “放弃抗丢包” 换实时性。但最终，这些底层能力都要服务于 “应用”—— 你刷的网页、发的微信、查的地图，背后都是应用层协议在 “翻译” 需求。这一期我们聚焦 TCP/IP 模型的最上层 ——，拆透 3 个最常用的协议：HTTP/HTTPS（网页与接口通信）、DNS（域名找 IP），以及应用层如何 “利用底层协议解决实际问题”，最后整理应用层的高频面试题。
2025-10-20 07:15:00
1132
原创 【计算机网络】第 3 期：核心篇 —— 传输层的 “可靠” 与 “快速” 怎么选？拆透 TCP 与 UDP
答题思路：先解释 “窗口大小是双方约定的‘一次最多发多少包’”，再讲过程（一次发 N 个包，等 N 个 ACK 再发下一批），最后说作用（平衡可靠性和效率，减少往返等待时间）。
2025-10-19 07:45:00
651
原创 【计算机网络】第 2 期：底层篇 —— 数据怎么从硬件传出去？拆透 MAC、IP 与 ARP
答案是不能。因为 A 一开始不知道 B 的 MAC 地址，没法 “单播”（单播需要知道目标 MAC），只能通过 “广播” 让所有设备听到，再让 B 单独回应 —— 这是 ARP 协议的核心逻辑，也是它的局限性（广播会占用局域网带宽，所以 ARP 缓存表会缓存一段时间，减少广播次数）。
2025-10-18 07:30:00
978
原创 【计算机网络】第一期：入门篇 —— 网络协议到底是什么？
如果你是刚接触计算机网络的应届生，或者面试时被 “请解释一下网络协议” 问得慌，别担心 —— 这篇文章会用最生活化的例子，帮你搞懂网络协议的本质，以及为什么我们总说 “TCP/IP 模型”。
2025-10-17 08:15:00
575
原创 【Ansible】第八期：Ansible 自定义能力扩展：模块、插件与 API 对接，突破原生边界
在企业级自动化落地过程中，Ansible 原生模块（如yumk8saliyun_ecs）能覆盖 80% 的通用场景，但面对企业内部个性化需求场景 1：需对接企业自研的运维平台 API（如内部资产管理系统、工单系统），原生模块无适配能力；场景 2：需执行复杂业务逻辑（如 “根据服务器 CPU 使用率动态调整应用实例数”），原生模块组合无法满足；场景 3：需自定义 Ansible 执行输出（如将结果格式化为 JSON 供 ELK 日志系统分析，或推送至企业 IM 工具），原生回调输出格式固定。
2025-10-16 09:30:00
1166
原创 【Ansible】第七期：Ansible 企业级落地：权限控制、加密与监控，保障自动化安全可靠
权限混乱：如何避免开发人员误操作生产环境？如何让不同角色（如运维、开发、测试）仅能执行指定任务？敏感信息泄露：Playbook 中明文存储的数据库密码、云厂商 AccessKey、SSH 密钥，可能因代码泄露或日志暴露导致安全风险；缺乏审计与监控：自动化任务执行失败后无法快速定位原因，谁执行了任务、执行结果如何，没有可追溯的记录。本文围绕 “权限控制→敏感信息加密→自动化监控与审计” 三大维度，提供可直接落地的企业级方案，确保 Ansible 自动化在 “安全、可控、可追溯” 的前提下运行。需求场景。
2025-10-15 09:30:00
1454
原创 【面经分享】2025.10.12-美团-运维开发工程师-AI面试
整个过程问的问题不算很难，算是比较基础的，涉及大模型的好像每次都会问到（看其他同学分享的面经中也有大模型），面试的每个题都会给15s思考时间，可以思考好了再答，会根据你的答案进行追问，所以自己不懂得点就不要提到；面完之后暂时还没有收到二面的通知，如果有幸能通过，会再发二面面经，后续也会发运维岗的相关面经，如果有需要的同学可以关注，都是亲身经历！先对数据进行预处理，将数据提供给大模型，大模型采集、整合数据，进行分类、排列，核心分析后，通过规则转化为运维人员可操作的任务。解决：先排查故障原因，设计解决方案；
2025-10-15 09:15:00
864
原创 【Ansible】第六期：Ansible 进阶实战：批量管理 K8s 集群 / 云主机，适配企业级场景
在掌握 Ansible 基础语法（Playbook、模块、Inventory）后，企业级场景的核心需求是将自动化能力与实际业务绑定—— 例如批量运维 K8s 容器集群、高效管理云厂商资源（如阿里云 ECS）、实现定时重复性任务的自动化执行。本文聚焦 “云资源 / 容器集群” 两大核心场景，通过 “场景定义→环境准备→核心模块解析→完整 Playbook 实战→问题排查” 的闭环流程，带您落地可直接复用的企业级自动化方案，解决 “手动操作效率低、多节点一致性差、重复任务耗人力” 的痛点。
2025-10-14 07:45:00
1667
原创 【Ansible】第五期：Ansible Roles：将 Playbook 拆分为 “模块化组件”
当一个 Role 依赖另一个 Role 时（如 WordPress Role 依赖 MySQL Role），可在中定义依赖关系，Ansible 会自动先执行依赖的 Role，无需手动调整顺序。单一职责原则：一个 Role 只负责一个功能（如apacheRole 只部署 Apache，mysqlRole 只部署 MySQL），避免一个 Role 包含多个不相关服务。变量分层管理：存放可被覆盖的默认值（如端口、数据库名）；：存放固定配置（如文件路径、服务名称），不允许外部修改；
2025-10-13 09:30:00
696
原创 【Ansible】第四期：Ansible 变量与模板：让 Playbook 从 “固定脚本” 变成 “灵活模板”
Inventory 变量是 “按主机或组批量定义变量” 的常用方式，支持两种写法：直接在 Inventory 文件中定义，或通过group_varshost_vars目录管理（推荐，更易维护）。写法 1：Inventory 文件中直接定义在[web-dev] # 开发环境 web 组192.168.1.101 # 开发环境机器192.168.1.102 nginx_port=8081 # 单个主机特殊变量（覆盖组变量）# 给 web-dev 组定义统一变量。
2025-10-12 11:00:00
1442
原创 【Ansible】第三期：Ansible Playbook：用 “剧本” 串联复杂任务，实现流程自动化
Playbook 价值：解决 Ad-Hoc 无法串联多任务、无法保存流程的问题，实现 “复杂流程自动化”；YAML 语法：严格缩进（2 空格）、键值对（键: 值）、列表（），避免常见格式错误；核心结构：一个 Play 包含hosts（目标）、tasks（任务列表）、become（提权）等要素，任务通过 “模块 + 参数” 定义操作；实战技巧：用notifyhandlers实现 “配置变更后重启服务”，用when做条件判断，用--check预执行验证。
2025-10-11 09:45:00
686
原创 【Ansible】第二期：Ansible 核心组件：Inventory、模块与 Ad-Hoc 命令，搞定 “单任务自动化”
如果机器 IP 或主机名是连续的（如 web01~web05），无需逐行写，用# IP范围：192.168.1.101 ~ 192.168.1.105[web]# 主机名范围：web01 ~ web05（需解析为对应IP）[web-test]Inventory：是 Ansible 的 “主机通讯录”，支持静态分组、变量配置、动态拉取（云环境），解决 “管理哪些机器” 的问题；模块：是 Ansible 的 “功能积木”，每个模块对应一个具体操作（如copy推送文件、yum。
2025-10-10 08:45:00
940
原创 【Ansible】第一期：从 “手动运维” 到 “自动化神器” 的第一步
Ansible 是由 Red Hat（红帽）主导开发的开源自动化运维工具批量执行命令（如查看所有机器的 CPU 使用率）；批量安装 / 卸载软件（如给 100 台机器装 Docker）；批量配置文件（如统一推送 Nginx 配置到所有 Web 节点）；自动化部署服务（如从 “拉取代码→编译→启动服务” 全流程自动化）。
2025-10-09 08:15:00
529
原创 【Kubernetes】（二十三）ArgoCD——让 GitOps 落地更简单，实现集群配置的 “版本化与自动化”
Git 是唯一数据源：集群中所有应用的配置（Deployment、Service、ConfigMap 等）都存储在 Git 仓库中，Git 的提交记录就是配置的 “版本历史”；声明式定义目标状态：通过 Git 仓库定义 “集群应该是什么样”（目标状态），而非手动执行 “要做什么操作”（命令式）；自动同步与差异检测：工具（如 ArgoCD）持续监控 Git 仓库与集群的状态差异，一旦 Git 仓库有更新，自动将集群状态同步到 “目标状态”，无需人工干预。可视化界面友好。
2025-10-08 07:45:00
750
原创 【Kubernetes】（二十二）HPA——让 Pod 实现 “弹性伸缩自由”
对于 “请求密集型服务”（如 API 网关、Web 服务），仅靠 CPU / 内存指标可能不够精准 —— 比如某些场景下 CPU 使用率不高，但 QPS 已达到服务瓶颈，此时需要基于 “每秒请求数（QPS）” 伸缩。要实现自定义指标伸缩，需要先部署Prometheus（采集 QPS 指标）和keda（或，将 Prometheus 指标转换为 K8s 可识别的自定义指标）。部署 KEDA（参考KEDA 官方文档。
2025-10-07 08:30:00
1063
原创 【Kubernetes】（二十一）PriorityClass
业务对齐：将 “服务重要程度” 转化为 K8s 可识别的 “优先级权重”，让资源分配贴合业务需求；风险可控：资源不足时，优先保护核心服务，减少业务中断风险；灵活适配：通过等配置，适配不同场景的资源调度需求。先梳理服务优先级：和业务团队一起明确 “核心 / 一般 / 非核心” 服务清单，避免拍脑袋配置；从小范围试点：先在非核心服务集群验证 PriorityClass 的驱逐逻辑，再推广到生产核心集群；结合资源限制使用：PriorityClass 配合，既能保障核心服务，又避免资源浪费。
2025-10-06 08:15:00
1610
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人