业务和功能介绍
1. 立项背景和目标
原医疗服务器监控工具存在告警不及时的问题，无法满足医疗业务对服务器稳定运行的高要求。若服务器故障不能及时发现，可能导致医疗系统如 HIS（医院信息系统）、影像存储系统等出现异常，影响患者就医流程和医疗数据安全。因此，立项将 Zabbix 升级作为主监控工具，目标是实现对 10 余台医疗服务器的全面、及时且准确的监控，确保医疗业务系统稳定运行，提升故障预警能力，减少因服务器问题引发的业务中断。
2. 软件功能、核心功能模块的介绍
Zabbix 具备强大的监控功能，能够对服务器的各项指标进行实时采集与监控。核心功能模块方面，Zabbix Server 作为核心管理模块，负责接收、处理 Zabbix Agent 采集的监控数据，并进行存储（依托 MySQL 数据库）与告警触发等操作；Zabbix Web 端则是用户交互模块，提供直观的界面，方便管理人员查看服务器监控状态、配置监控项与告警规则等；自定义监控 Key 模块（通过 Shell 脚本实现），可针对医疗业务特色，如 HIS 服务运行状态、影像文件存储使用率等进行定制化监控，满足医疗场景的特殊监控需求；Zabbix Agent 模块部署在各医疗服务器上，负责采集服务器的基础指标（如 CPU、内存、磁盘等）以及自定义监控项数据，并上报给 Zabbix Server。
3. 业务流程、功能路径描述
业务流程起始于 Zabbix Agent 在各医疗服务器上采集数据，包括服务器基础指标和通过自定义 Shell 脚本 Key 采集的 HIS 服务、影像存储等医疗相关指标。采集到的数据通过网络传输至 Zabbix Server，Zabbix Server 对数据进行分析，并与预设的阈值进行对比。当数据超出阈值时，触发告警流程，通过指定的方式（如邮件、短信等）向相关人员发送告警信息。同时，Zabbix Web 端实时展示监控数据与告警状态，管理人员可通过 Web 端查看服务器运行情况、历史告警记录，并对监控配置进行调整。此外，借助 Ansible 批量部署 Zabbix Agent，简化了多台服务器 Agent 部署的操作流程，提升了部署效率。
原医疗服务器监控工具存在告警不及时的问题，无法满足医疗业务对服务器稳定运行的高要求。若服务器故障不能及时发现，可能导致医疗系统如 HIS（医院信息系统）、影像存储系统等出现异常，影响患者就医流程和医疗数据安全。因此，立项将 Zabbix 升级作为主监控工具，目标是实现对 10 余台医疗服务器的全面、及时且准确的监控，确保医疗业务系统稳定运行，提升故障预警能力，减少因服务器问题引发的业务中断。
2. 软件功能、核心功能模块的介绍
Zabbix 具备强大的监控功能，能够对服务器的各项指标进行实时采集与监控。核心功能模块方面，Zabbix Server 作为核心管理模块，负责接收、处理 Zabbix Agent 采集的监控数据，并进行存储（依托 MySQL 数据库）与告警触发等操作；Zabbix Web 端则是用户交互模块，提供直观的界面，方便管理人员查看服务器监控状态、配置监控项与告警规则等；自定义监控 Key 模块（通过 Shell 脚本实现），可针对医疗业务特色，如 HIS 服务运行状态、影像文件存储使用率等进行定制化监控，满足医疗场景的特殊监控需求；Zabbix Agent 模块部署在各医疗服务器上，负责采集服务器的基础指标（如 CPU、内存、磁盘等）以及自定义监控项数据，并上报给 Zabbix Server。
3. 业务流程、功能路径描述
业务流程起始于 Zabbix Agent 在各医疗服务器上采集数据，包括服务器基础指标和通过自定义 Shell 脚本 Key 采集的 HIS 服务、影像存储等医疗相关指标。采集到的数据通过网络传输至 Zabbix Server，Zabbix Server 对数据进行分析，并与预设的阈值进行对比。当数据超出阈值时，触发告警流程，通过指定的方式（如邮件、短信等）向相关人员发送告警信息。同时，Zabbix Web 端实时展示监控数据与告警状态，管理人员可通过 Web 端查看服务器运行情况、历史告警记录，并对监控配置进行调整。此外，借助 Ansible 批量部署 Zabbix Agent，简化了多台服务器 Agent 部署的操作流程，提升了部署效率。
项目实现
1. 整体架构和设计思路，不同模块使用的技术栈
项目采用Zabbix Server-Agent 分布式监控架构，结合自动化与定制化技术栈实现。核心模块及技术栈如下：
控制层：部署 Zabbix Server（负责数据接收、处理与告警触发）和 Zabbix Web 端（提供可视化管理界面），采用MySQL存储监控历史数据与配置信息，保障数据持久化与可查询性；
采集层：在 10 + 台医疗服务器部署Zabbix Agent，采集 CPU、内存、磁盘等基础指标；通过Shell 脚本自定义监控 Key，覆盖 HIS 服务运行状态、影像文件存储使用率等医疗专属业务指标；
自动化层：使用Ansible编写 Playbook，实现 Zabbix Agent 的批量部署与配置，减少重复手动操作。
2. “我” 的负责模块和结果（尽可能量化）
我主要负责Zabbix 服务端部署、自定义监控开发、Agent 自动化部署三大模块：
Zabbix Server 与 Web 端部署：完成服务端安装、MySQL 数据库对接及 Web 界面权限配置，确保监控数据链路通畅；
自定义监控 Key 开发：编写 5 + 个 Shell 脚本（如 HIS 服务进程检测、影像存储磁盘使用率统计），为每个监控项设置多级阈值（如磁盘使用率 85% 预警、90% 严重告警）；
Ansible 批量部署 Agent：编写自动化 Playbook，覆盖 10 + 台异构医疗服务器（含 CentOS、Ubuntu 等系统），相比手动配置减少 60% 的时间成本。
结果层面，项目上线后预警准确率达 95%，累计提前识别并修复 8 处潜在故障（如 3 次磁盘即将写满、2 次 Tomcat 内存泄漏、3 次 HIS 服务异常重启），保障了医疗业务系统的 7×24 小时稳定运行。
3. “我” 遇到的难点、坑，和解决方案
难点 ：异构服务器 Agent 部署兼容性差
坑：不同医疗服务器的操作系统版本（CentOS 7/8、Ubuntu 20.04）、端口占用情况不一致，导致 Agent 默认配置无法通用（如部分服务器 50000 端口被医疗影像服务占用）。
解决方案：用 Ansible 的facts模块提前采集服务器环境信息，在 Playbook 中加入端口预检与自动适配逻辑（检测 50000 端口占用，若被占用则动态调整为 50001 - 50010 区间的可用端口），同时针对不同系统编写差异化的 Agent 安装与启动任务。
项目采用Zabbix Server-Agent 分布式监控架构，结合自动化与定制化技术栈实现。核心模块及技术栈如下：
控制层：部署 Zabbix Server（负责数据接收、处理与告警触发）和 Zabbix Web 端（提供可视化管理界面），采用MySQL存储监控历史数据与配置信息，保障数据持久化与可查询性；
采集层：在 10 + 台医疗服务器部署Zabbix Agent，采集 CPU、内存、磁盘等基础指标；通过Shell 脚本自定义监控 Key，覆盖 HIS 服务运行状态、影像文件存储使用率等医疗专属业务指标；
自动化层：使用Ansible编写 Playbook，实现 Zabbix Agent 的批量部署与配置，减少重复手动操作。
2. “我” 的负责模块和结果（尽可能量化）
我主要负责Zabbix 服务端部署、自定义监控开发、Agent 自动化部署三大模块：
Zabbix Server 与 Web 端部署：完成服务端安装、MySQL 数据库对接及 Web 界面权限配置，确保监控数据链路通畅；
自定义监控 Key 开发：编写 5 + 个 Shell 脚本（如 HIS 服务进程检测、影像存储磁盘使用率统计），为每个监控项设置多级阈值（如磁盘使用率 85% 预警、90% 严重告警）；
Ansible 批量部署 Agent：编写自动化 Playbook，覆盖 10 + 台异构医疗服务器（含 CentOS、Ubuntu 等系统），相比手动配置减少 60% 的时间成本。
结果层面，项目上线后预警准确率达 95%，累计提前识别并修复 8 处潜在故障（如 3 次磁盘即将写满、2 次 Tomcat 内存泄漏、3 次 HIS 服务异常重启），保障了医疗业务系统的 7×24 小时稳定运行。
3. “我” 遇到的难点、坑，和解决方案
难点 ：异构服务器 Agent 部署兼容性差
坑：不同医疗服务器的操作系统版本（CentOS 7/8、Ubuntu 20.04）、端口占用情况不一致，导致 Agent 默认配置无法通用（如部分服务器 50000 端口被医疗影像服务占用）。
解决方案：用 Ansible 的facts模块提前采集服务器环境信息，在 Playbook 中加入端口预检与自动适配逻辑（检测 50000 端口占用，若被占用则动态调整为 50001 - 50010 区间的可用端口），同时针对不同系统编写差异化的 Agent 安装与启动任务。
示例图片视频
相似推荐
RPG玩法框架
1.深耕现有团队积累细分RPG强交互方向，利用工业化迭代，洗长尾BT硬核手Q自然量，保证收入，每次不断尝试，买量测试，那个版本数据比较好，重点优化，冲击爆款。
2.目前先专注平面战斗表现（目前利用AI绘画至少节省2倍成本，已经找到不错的表现参考）
3.找到前期轻度玩法，转强交互RPG玩法，匹配的轻度玩法，在小游戏找买量合作方，不断的尝试 （已经初步尝试，24年3月左右线上测试）
4.实时关注时长最新爆火新品类玩法 如果发现的比较早，并且该玩法，在工业化迭代中积累的美术，代码资源，支持可以快速抄袭，则尽量百分百快速 还原，抢占新品类红利，线上不断测试迭代优化，建起壁垒。 如果发现的比较晚，或现有资源不能快速抄袭，抢占先机，思考是否可以有独特的创新，创新可以在玩法，表现等，有 就做，没有继续做原来的事情
大千修仙录
1.三族角色养成系统：包含人族（均衡适配）、妖族（肉身爆发）、仙族（法修天花板）三大种族，开局随机根骨、悟性等 7 项先天属性，衍生属性与隐藏属性由基础属性实时计算，隐藏属性全程不可改变，完美契合种族特色。
2.有本地存档系统，玩家做的任何决定都可以本地存档，并且已经加入bgm，bgm可自由关闭；
3.境界突破系统：覆盖炼气、筑基、金丹、元婴、化神等 14 大境界，每个境界分初 / 中 / 后 / 大圆满 4 个小阶，突破需满足修为与材料要求，成功后全属性按倍率成长，失败则扣除部分修为。
4.属性加成体系：7 项基础属性（根骨、悟性、身法等）每 + 1 点对应固定衍生属性 / 隐藏属性加成，三族叠加专属倍率，实现 “根骨影响修炼、肉身决定坦度、颜值提升社交” 的差异化养成。
5.大荒北城剧情玩法：以 “大荒北城出现天地异象，有机缘现世” 为核心剧情，玩家从凡境起步，通过修炼、探索、战斗逐步提升境界，解锁御剑飞行、神识探宝、法宝碰撞等修仙核心玩法，最终目标是飞升成仙。
6.UI / 背包系统：底部固定显示 UI 状态栏，背包模块实时展示原石、材料等资源，屏幕中间预留剧情对话与操作区域，符合移动端操作习惯。
ai文字冒险-游戏
1.目前市面上缺少与ai相关的游戏，大部分文字冒险游戏均为预设，且不支持用户自主自定义，我做一款完全可用户自定义世界观及主角的文字冒险rpg，然后ai会先进行世界观创造保存到世界观里，然后再根据创造世界观来给用户游玩
"Protocol: Deception" – Gravity & Portal Puzzle Game
🔧引擎级问题解决能力
独立定位并修复 UE5 渲染线程内存竞态，涵盖节点断点调试、内存地址追踪，具备扎实的多线程底层分析能力。
⚡ 全栈引擎子系统实现经验
单人完成渲染、物理（Chaos 扩展）、输入/摄像机、AI、PCG 等 40+ 模块，覆盖引擎核心子系统。
🎮 C++ 多线程与性能意识
使用 C++20 + Unreal Insights 进行帧率/内存分析，具备 GPU 调试基础及资源加载策略优化经验。
🚀 高效迭代与工程自驱力
4 个月内独立交付完整可玩 Demo，AI 辅助调试工作流将引擎源码检索效率提升约 90%。
抖音开放平台恐怖点击拖动类解谜小程序游戏-日常异象录
业务功能介绍
已实现功能模块
1.点击解密类小游戏完整客户端
·通过点击场景中的物品或选项推动剧情、解开谜题。
·广告点位（提示）与玩法结合自然
·设计了丰富多样的关卡，难度循序渐进，兼顾休闲与动脑的乐趣。
2.存档以及数据同步系统
·通过用户数据进行快速的数据保存，确保用户可以从断点继续游玩
3.CDN动态加载资源管理系统
·所有数据通过动态的CDN加载，节省完整加载时间，节省用户设备资源
帮助文档
Copyright @ 2021-2024 程聚宝 | 浙ICP备2021014372号
人工客服