组织架构与分工?
- 各子组织的职责、边界是否明确?
(安装、升级)部署规范?
- 一切非正式启用的任务、文件(夹)、安装资料必须依据实际用途以
bak
、tmp
、test
3类字样标识
不论是测试环境,还是生产环境
/home/sdc/ : 部署路径,假定 该软件企业统一使用具有 sudo 权限的 sdc 用户
/bin/ : 运维脚本
/crontab-scripts : 本项目中的一些定时脚本(状态监测与恢复、自动化清理任务等)
xxxAppMonitor.sh : xxxApp应用模块的监测脚本
sdcServer.sh : 系统统一运维脚本
/backup-data : 应用数据备份路径,例如:数据库、配置文件
/mysql.dbA.dbB.dbC.dbD.at.202109171856.by.johnnyzen.bak
/appA-xxxx.tar.gz.at.202109180945.by.johnnyzen.bak
/... : 应用模块的分类部署路径
/appA : 应用A的部署路径
/appA.at.202109182102.by.johnnyzen.bak : 备份
/appA.at.202109182227.by.johnnyzen.bak
/appB
/appB.at.202109182228.by.johnnyzen.bak
/opt : 第三方软件 存放路径
/SDCInstall : 初次安装的安装包 存放路径
/SDCUpgrades : 升级包存放路径
/20210918/ : 升级部署的日期
/SDCUpgrade
/server : 安装包
运维规范?
- 针对多个软件项目的运维工作,如何低成本、高效率地管理用户/客户的问题和需求?如何以较短时间同步任一问题或需求的最新进展?
解决方法:在线协作文档。1个项目1份Excel的在线文档;N个项目有1份链接到各个项目的链接列表
- 运维期间的状态管理?
私有化部署的软件商业模式,存在哪些问题?
- 如何保证不同项目的【现场环境】与IT软件企业【研发环境】的一致性?(代码版本、环境配置)
- 应对多个项目的IT软件企业的【研发环境】中,如何快速地切换到不同项目的【代码版本/现场环境】?