初识服务
记起当时在a公司的时候，除了负责大数据集群的维护之外，还需要维护一两个web服务。我们团队分工比较合理，每一个业务都有AB角，虽然角色交叉重叠，但是条理清楚，分工明确。当时我就是其中两个业务的运维B角色( 其实是替补😄 )。老实说，到这时候，我才是刚开始接触web服务。
开始积累
我是从代码更新开始熟悉所管理的整套业务的。2015年的我们是业界所说的脚本时代，代码更新全是执行脚本。
代码放在灰度或者测试环境，从生产环境下线机器，同步代码到已下线机器，重启，检查日志，正常则上线并继续更新余下机器；报错则和研发一起查看问题，能解决则继续，不能则回滚并记录升级失败。当时有很长一段时间都是专门做这一项工作，而且都是半夜三更等大家都睡了的时候才开始（更新只能选晚上流量不大的时候）。这个过程虽然艰苦，但是也积累了不少经验。比如业务逻辑，系统架构，查找问题的方法论等等。
除此之外，当时我们还经常会遇到故障。因为云计算供应商的服务不是很稳定，时不时都会出现网络故障，机器故障等（甚至我们直接使用的物理机也时不时出现磁盘只读）。每次故障我都能学到不少东西，更加明白”养兵千日 用兵一时”的道理。在平时就应该尽量把事情考虑彻底，时刻准备着，才能更好应对突发情况。
开始思考
代码更新令我熟悉整个服务管理流程。这里面的学问其实有很多。
- 服务的搭建（包括测试，灰度和生产环境的协调等细节）
- 服务器权限以及目录的管理（研发帐号，服务帐号，目录路径规范）
- 中间件的配置管理
- 系统参数优化以及中间件调优（主要是JVM调优，内核参数优化）
- 服务的监控（包括主机监控以及服务端口监控，告警通知等）
- 服务所使用的缓存管理
同时，从故障中我也领会到了不少门道。
- 部署环境（尤其生产）一定要考虑高可用
- 监控点必须覆盖全面（从主机到服务）
- 考虑备份服务（视情况而定）
- 尽量避免实施影响服务稳定性的需求（俗话说的不要给自己埋坑）
（这里的总结只是本人的愚见，希望阅读的您能批评指正🙏 ）
开始探索
前文说到的“深夜更新”以及故障处理确实挺艰苦的。为此，我开始思考怎么“偷懒”。😜
首先是对付更新，我在想能不能自动化，让系统自己执行更新命令然后我睡大觉呢。😏然后是对付故障，大家都说防范于未然。那能不能将监控升级一下，监控不止于监控，还具备修复功能。于是，我开始探索实现的手段。接下来就记录几个栗子吧。😄
首先记录的是在缓存方面所做的工作。
除了缓存，还玩了一下docker。
