回望2017年，笔者觉得自己是幸运的，也是不幸的。幸运的是从一个网络管理员上升到了运维工程师，收入也有所增加，不过也才是刚好深圳的平均工资水平，还需努力。不幸的是新公司年底没年会，其他福利可以自行脑补，我能说的是能想到的基本都没有。公司的性质是盈利的，而员工与公司应该是互利，然而在职场上都是一个萝卜一个坑，公司只会不断的压榨员工（下一份工作我应该找一家国企或8年以上的上市公司，至少福利方面不会太烂，至少会有年会）。原本想着来创业公司来成长一下，后来才发现在创业公司里更加难以成长，也许是目前公司停滞不前的原因，又或者是高管不重视技术团队的原因，让我感觉这一点都不“创业”、更别说“互联网”了。重点是在这样的“创业”公司里，完全靠自己摸索，虽然说网络上有丰富的资源，但毕竟参差不齐，往往在筛选及测试上就消耗了不少时间。吐槽完毕，笔者更期望有的时一个可以共同成长的团队，因为我一直坚信一个人再厉害，单凭自己一个人是干不大事的。不过凡事都有利弊，再多的大道理都是别人经验。
2018年的春节假期过得格外轻松，期间无收到报警信息或紧急事件需要及时处理的。这得多亏了在假期前的检查，大概内容如下：
1、通过Grafana检查系统近两周的资源使用情况，此处针对于CPU与内存资源，对于可能存在的瓶颈进行提前扩容。由于业务场景在某个时间点存在高并发的情况，所以使用了阿里云的ECS定时弹性扩展功能，并在假期期间提升可扩展数量的上线。
2、磁盘资源检查。这是一个容易出问题的点。由于在该问题上吃过亏了，所以现在做得更加仔细。原先的方式是在节前统做一次磁盘空间的清理，后来依然会出问题。现在的处理方式如下：
2.1、系统盘与数据盘分离；
2.2、增量数据(如日志)做转移处理，一般服务器上只保留当天的增量数据，隔天数据将被转移到存储服务器上或阿里云的OSS，需要查看特定时间得日志再去下载。如果增量数据不重要则只保留3天内的数据量，超过的进行删除；
2.3、利用脚本紧急释放磁盘空间，触发条件是磁盘空间低于某一阈值，可能做如下操作，删除缓存数据、删除增量数据(非重要)、转移增量数据甚至某一服务，其目的都是为了保证线上业务不受到影响；
3、实时监控重要服务，并能自处理简单问题。笔者是把把任何能影响核心业务的服务都定义为重要的，会使用脚本来监控该服务是否在线，一般是监控其进程和端口号（所以如果进程和端口号是正常的又不能提供服务的情况就暂且处理不了，有更好的方案欢迎赐教），然后定期进行检查，检查频率是分钟级的，如果检查出现异常则会进行服务重启处理，并且判断服务重启后的返回日志，如果重启失败还可能会做如下处理（依据返回日志信息）：释放内存空间、杀死某进程、重置配置文件等，并再次进行重启。如果以上操作还未恢复服务的话讲会发出紧急报警信息给对应负责人。
4、数据备份及容灾。对于运维来说，只要数据在，什么问题都不是问题（这是带笔者入行的领导讲的，一直受用）。因为是使用MySQL存储数据，所以热备和冷备都在使用，也很方便，这里不详讲。
以上事务笔者在节前做的检查事项，这些自处理也应该常态化，只是在特殊假期前还需要人工在核查一遍，因为脚本所能处理的问题也不是面面俱到的，所以还需要不断的进行完善。
以下是笔者对2018年的目标，人还是应该要有目标的，而达到目标的过程是计划，不过最终还是要落地执行，希望到2019年的时候，下方事项的状态都是已完成。
2018年的目标(技术方面)：
一、为业务系统接入ELK日志管理系统，开发人员可以直接在上面查看日志，减少对服务器的操作（已完成2018-04-06）；
二、学习Python编程，期望往人工智能方面发展；（已完成2018-05-30）
三、将部分服务迁移到Docker上，并接入K8S（因K8S还是个人摸索阶段所以还不敢下结论，但毕竟是一个趋势）；
四、完善自动化运维平台（结合Python和Sonarqube，我不介意把大部分的测试工作都做了O(∩_∩)O~~）（已完成2018-05-05）；
五、加深对网络基础理论的学习（越来越发现不够用，特别是学习Docker、K8S之后）。
二零一八年二月二十四号
网友评论