Linux系统可维护性取决于清晰的目录结构、分层配置和服务职责单一。应遵循FHS规范，应用配置放/etc/appname/，运行时文件放/var/lib/appname/，模板放/usr/local/etc/appname/templates/；服务状态禁存/tmp，改用RuntimeDirectory=或StateDirectory=；用systemd声明式依赖替代shell脚本串启；日志管理优先journald，需logrotate时显式设权限。
Linux 系统可维护性不取决于装了多少监控，而在于目录结构是否清晰、配置是否分层、服务是否职责单一。结构混乱的系统，改一个 /etc 下的文件可能影响三个服务，加个用户权限可能波及日志轮转和备份脚本。
避免把所有配置塞进 /etc 根目录
很多运维习惯把自定义脚本、模板、策略文件全丢进 /etc，比如 /etc/backup.conf、/etc/deploy-hook.sh、/etc/nginx-templates/。这会破坏 FHS（Filesystem Hierarchy Standard）语义，导致 rsync 备份时漏掉非标准路径，rpm 或 dpkg 升级时覆盖或忽略这些文件。
- 应用专属配置统一放
/etc/appname/，例如/etc/prometheus/、/etc/logrotate.d/myapp - 运行时生成的模板或策略文件，应放在
/var/lib/appname/（如/var/lib/ansible/inventory/），而非/etc - 启动前需预处理的配置（如 Jinja2 模板），建议用独立目录
/usr/local/etc/appname/templates/，并由部署脚本注入到/etc/appname/
服务进程不要直接读写 /tmp 或 /var/tmp
/tmp 被 systemd-tmpfiles 清理、/var/tmp 可能被 tmpwatch 扫描删除——若服务把状态文件、锁文件、缓存索引存在这里，重启后就丢失上下文，表现为“服务偶尔起不来”“定时任务重复执行”。
- 临时工作目录应使用
RuntimeDirectory=（systemd）或mktemp -d在启动时动态创建，生命周期绑定服务实例 - 需要跨重启保留的状态，必须存到
/var/lib/servicename/，并确保systemd单元里声明StateDirectory= - 日志类临时输出可走
journald，避免自行轮转；若必须落盘，用LogDirectory=声明位置，让 systemd 自动建目录并设权限
用 systemd 的单元依赖与隔离机制替代 shell 脚本串行启动
用 /etc/rc.local 或自写 start-all.sh 启动多个服务，一旦某个环节失败（比如网络未就绪、数据库没响应），后续服务静默卡住，排查只能靠人工翻日志。而 systemd 提供声明式依赖和失败传播。
易学易用：友好的系统操作界面，无须具备专业知识，即可熟练的使用系统。功能完善：具备新建、修改、明细、审批、导入、导出、删除、批量、打印等功能。模型开发：自定义表单字段选项零代码二次开发，可无限扩展后台功能模块。 维护方便：基于互联网技术B/S体系结构，实施快速，极大的减少系统升级维护工作。售后保证：专业的技术研发团队，可提供可靠的产品迭代、版本升级和技术支持服务。超低成本：一次投入终身使用、用户不
[Unit] Description=My API Service Wants=network-online.target postgresql.service After=network-online.target postgresql.service [Service] Type=simple User=apiuser ExecStart=/opt/myapp/bin/server --config /etc/myapp/config.yaml Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
- 用
Wants=+After=表达弱依赖，避免硬阻塞；用BindsTo=表达强依赖（如 DB 挂了，API 必须停） - 对需要顺序但不依赖状态的服务（如先启 NTP 再启日志转发），用
Before=+After=配合Type=oneshot单元 - 禁止在
ExecStartPre里调用长时命令（如curl -f http://db:5432/health），应改用systemd的 socket 激活或ConditionPathExists=等轻量检查
/var/log 下的日志目录不能只靠 logrotate 管理
单纯靠 /etc/logrotate.d/ 配置，容易出现：新服务上线忘了加规则、不同服务日志混在一个文件导致权限冲突、postrotate 脚本误杀进程。真正可维护的做法是把日志路径、轮转策略、归档行为全部声明化。
- 每个服务日志目录设为
/var/log/servicename/，并用LogDirectory=在 unit 文件中声明，systemd 会自动创建并设属主 - 轮转策略优先用
journald的内置参数：SystemMaxUse=、MaxFileSec=，避免多层轮转逻辑嵌套 - 确需
logrotate时，用create 640 user group显式控制权限，且每条规则末尾加su user group，防止 root 权限写入普通用户日志
结构优化最难的部分不是设计目录，而是说服团队停止往 /root/scripts/ 里扔新脚本、不再手动修改 /etc/profile 加。每次合并 PR 或上线变更时，顺手清理一个历史路径，比一次性重构更可持续。
