前言
大概在16-21年这个阶段非常流行综合性运维管理平台这个概念, 大部分的运维开发或者说 devops, 都在主推运维平台这个概念；
简单来说就是将一些运维操作都合并到web平台上来，减少直接线上cli操作;
但是存在很多的问题:
- 灵活性不足, 每接入一个新服务或新中间件可能就要大改;
- 功能少了就不好用，功能多了就操作繁琐；
- 效率不足, 点来点去，操作半天不如一个自动化脚本几秒就执行完成;
- 也还是容易误操作;
- 学习成本, 第三方学习这个平台的使用也需要较高的成本;
所以目前来说除非特别大的公司, 如国企和一些集团公司在资源足够的情况下搞运维平台还是可以的;
普通中小企业完全没有必要搞这个;
一个基本可用的运维平台, 至少要占用一个运维开发的全部时间;
一个完善的运维管理平台功能 = 阿里云控制台 + 自有业务的管理模块;
以下是以前我整理了一些功能点;
完善的运维管理平台核心功能
- 统一入口: 确保这个系统是真正的运维入口;
- 核心功能：能解决真正痛点问题的核心功能；
- 高频功能：来保证会有人经常使用;
应用运维子系统
- 基础设施管理: 开关机, 装机系统
- 虚拟机: 克隆主机, 创建删除实例, 模板制作
- 堡垒机部分: 登陆, 文件上传下载等
- 资管管理: 资产统计, 成本管理, CMDB的功能
- 调度发布: 服务的CI/CD, 发布，回退
- job作业系统: 定时任务或临时任务
- 配置系统: 操作系统配置文件，应用程序配置文件
- 数据库系统: 创建调度数据库实例, 数据查询
- 备份子系统: 全备，和上线前的临时备份
- 网关子系统: 流量调度
- 监控系统: 基础设施监控, 业务监控, 链路监控
- 工单系统: 资源, 权限，变更, 公告 等流程管理
- 人员管理: 权限管理
- 域名管理子系统
- docker 容器管理平台
- 业务验证模块: 上线完成后顺手点一下, 自动化模拟用户身份进行一次核心业务操作, 验证业务流程是否正常;
其它功能
- 故障自愈能力和故障干预能力
运维管理平台建设关键
- 标准先行: 抽象那些共性特征;
- 快速迭代；一个功能如果不好，马上更换新方法
- 不追求完美；好东西是演化出来的，不是一步到位的
- 占据入口: 提高覆盖面，开始阶段可以只是一个导航页面，但一定要占据用户入口
- 模块化: 方便多个开发人员并行作业
风险事项
- 功能是否有经过严格的测试
- 对于一些删除或者修改类的操作，是否有二次检查和回滚措施
- 灰度策略：即先在小范围运行，再全量运行；
- 所有操作是否有记录和审计
- 危险操作是否有通知或告警
- 是否有权限分级和接口鉴权能力
- 是否有解决高频的痛点问题
- 是否是标准化先行
agent
是否需要 agent
部分场景需要
- 某些国企对ssh协议限制非常严, 很难给开网络策略; 自有agent可以采用私有协议和端口进行通信;
- 不能装太多监控、日志采集、数据采集, 想一个agent搞定所有客户端任务;
无agent的模式
- 采集和监控等都使用开源标准组件;
- 任务下发统一使用ansible或ssh下发脚本执行的方式;
一般来说开发人员资源不足时, 尽量不要去做agent;
agent的功能
- 插件化：支持通过插件扩展agent的功能
- 私有通信协议: 推荐 websocket + mTLS 来做;
- 资源监控：push/pull 方式获取监控数据
- 网络监控：到本机房、跨机房、跨区域的网络连通性
- 资产采集：初始化时采集 和 重启时比对如有差异再上报更新，以配合CMDB
- 日志采集：即可以将本地日志发送到远端日志服务器
- 文件传输：即支持服务器下发或拉取文件
- 环境配置：服务器可以下发配置文件, 或远程命令执行, 如用户创建删除;
- 应用管理：支持启动/停止/更新/回退/健康检查，本地的应用
- 资源占用低: 对CPU内存带宽等占用低
- 自动更新: 保持版本在最合适的新版本
- 系统预装：可以随操作系统安装时安装
- 自修复: 能检查到自己出现故障，上报，并试图更新或回退自己；具有自启动或自重启能力;