• 客户环境中可能存在不少配置类问题

• 之前的模式总是遇到一个问题解决一个问题，问题总是以事故的形式出现

针对实际系统和应用配置，做全面的诊断，尽可能将配置类问题在问题发生前暴露出来，并且给出处理方式

• 对接运维平台

• 使用健康诊断做全面检测

• 根据检测结果进行快速修复

• 发生了内存宕机类问题，由于生产环境，必须要第一时间恢复环境，没有来得及登录到后台输入命令收集宕机信息，导致问题无法定位

• 夜间发生了宕机，由于没有人24h监控，或者由于没有办法触碰到内网环境，导致第二天才能够恢复，导致发生了生产事故

运维平台自动识别宕机情况，并且自动采集宕机信息，采集完信息后，自动重启工程，保证工程持久运行

• 对接运维平台

• 发生内存宕机，自动触发堆栈，histo，dump的采集，并且自动重启系统

• 宕机自动处理对宕机问题进行分析给出可能的原因

• nginx/redis/配置库等问题多，配置修改成本大

• 修改配置操作繁琐，容易改错

• 工程和组件启停操作成本高，需要登录到后台操作

前端可视化界面进行组件的配置修改和启停

• 对接运维平台

• 容器管理页面

• 选择对应的组件进行参数选择和值的修改操作

• 在容器管理页面进行组件的重启让配置生效

• 不少客户都遇到过由于磁盘满而导致的宕机

• 在磁盘满之后，会手动进行一些清理，但是隔了一段时间，再次出现由于磁盘满而导致的宕机

可视化的监控磁盘，并且在占用高的时候给出预警，并且还能够通过运维平台来对资源进行清理

• 集群多个节点，每一个节点的信息获取非常困难，需要一个一个登录到节点后台去拿对应的日志

• 有多个应用，每一个应用发生问题的时候都需要去对应的机器上面查看资源情况，对应需要安排一个单独的运维人员

通过一个运维平台做多个节点/应用的对接，同时能够监控多个环境，任一一个节点/应用出现问题都可以统一预警，也能够通过运维平台方便的获取到信息

• 集群/多个应用对接运维平台

• 可以任意选择想要监控的应用，查看应用运行状态

• 其中一个节点/应用发生负载高的问题时，能够自动触发告警到管理员