系统上线以后，运维的就是主要问题，我们无法保证程序一直是启动的，虽然现在大部分程序都是集群的，宕机一台并不影响系统运行。例如三副本的程序，宕机一台不影响，但是如果不能快速启动，等到第二台，第三台宕机。程序终有不可用的时候。以下几个点可以加固稳定系统。
自动拉起程序
自动拉起程序有多重实现方式，最简单的就是利用systemd去拉起进程，保证程序在宕机后可以快速被拉起，也可以利用k8s或者是定期的脚步扫描都可以。大概流程如下
- 检测进程是否存活/端口是否存活
- 如果程序不正常提供服务，直接调用脚步或者kill -9
- 调用start脚步启动服务
- 定时执行上面步骤
这里需要注意的是进程启动和程序可用是两回事，例如进程夯死的情况，进程的pid一直是在的，但是不能很好的提供服务。这种情况一般是自己编写脚步来定制的，例如定时执行一个轻量级的访问，如果能按时返回，证明程序服务是可用的，如果说超时了，需要告警等机制保障。
探活告警
在有自动拉起程序后，探活告警也是需要有的，针对一些特定的情况，例如物理机的损坏，还有端口被占用等等，我们需要人工快速排查错误。端口冲突是遇到的一个场景，本来有systemd保证程序死亡后被拉起，但是有次一直没启动成功，最终原因是物理机启动了多个服务，一个端口和已经建立的连接的端口冲突，导致端口被占用，程序启动失败，这种意外情况如果没有告警机制，很难及时被发现，这个可以说探活的告警是真个意外的观察者，如果没有这种机制，只能依靠人肉去运维，或者调用方发现，一般这种情况都是事故了。
探活告警不可以太敏感，需要有一定的持续性，例如遇到网络抖动，正好认为程序挂掉了。这种时候例如发出信息，调用人力排查，最终结果可能不是想要的，所以探活的情况必须有持续性，例如持续2分钟等。起码是多次探测都是人为宕机的情况，这种才是真正需要人工介入的时候。
拒绝策略
程序的拒绝策略是为了防止自己被压垮的好手段，一般是策略都包含以下内容。
- 使用内存限制
- 调用频率限制
- 单次调用使用资源的限制
- 调用时长限制
基本第三个和第四个是最常见的，最简单的场景就是sql查询，如果一个写的非常不好的sql，多个表联合查询，返回数据不限制，很容易导致程序oom的，所以在单次调用做时间限制和资源限制，是一个比较好的方式去推进调用方优化自己的业务，毕竟大部分都是场景不合理或者交互不合理导致的。
指标监控
指标监控主要是用来做服务运行探测的，最大的作用是用来事后复盘。虽然有拒绝策略，但是策略总不能完美拒绝到各种情况，虽然单次的限制了，总量限制的比较少，也会压死程序。指标监控在这个方面就有很多的作用
- 查看历史值合理规划资源
- 查看进程挂掉前的各种状态
- 查看最后调用的情况
有了这些数据就可以更好的完善拒绝策略带来的影响。
而且有了监控，可以很好的调整服务的参数，例如线程数，java的gc相关的部分，访问的并发量等等。这些都可以不断的改良。
小结
- 自动拉起程序可以减少人为运维
- 探活告警可以更好的应对，拉起失败情况
- 拒绝策略可保证程序的稳定，不被调用压垮
- 指标监控可以晚睡拒绝的策略