运维人的 KPI 救赎!(运维人的初夕夜新闻稿)

网友投稿 1375 2022-09-23

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。

运维人的 KPI 救赎!(运维人的初夕夜新闻稿)

第1条

变更要有回滚,在同样的环境测试过

也是运维最繁琐,最苦逼的地方——所有的变更都必须有回滚的办法,在同样的环境下测试过。

没有做过的东西,总是会在你意想不到的地方给你一次痛击,多年运维经验告诉我们:所有没有做过的变更,出错的概率最大。

所以,我们需要给变更以回滚的可能,在各个步骤可能出错的情况下,考虑回滚到最初状态。优秀的运维人员对不考虑回滚的的操作都是敬而远之的。从某种意义上来说,运维是一门经验的学科,是一门试错的学科。

第2条

对破坏性的操作谨慎小心

破坏性的操作有哪些列?

对数据库来说有:DROP Table, Drop database, truncate table, delete all data; 这些操作做完了以后几乎无法考虑怎么把数据都回滚回去了。

就算回滚,代价也是非常大的。执行这样的语句非常简单,但回滚恢复数据缺非常困难。操作时就要更加谨慎了。

第3条

设置好命令提示

时刻知道你在操作哪个数据库,知道你在哪个目录下。开多个标签页的话,如果每个标签页的标题上内容一样,我们切来切去就有可能在错误的标签页上做操作,设置了这个以后,这个问题概率就会小很多。

第4条

备份并验证备份有效性

是人总会出错,是机器总可能会有突然崩溃的那一天。怎么办?我们需要准备备份。

备份有了,是否就可以高枕无忧了?还是不行。你需要验证备份的有效性。所以,备份并不只是备份,它还包括备份的验证,它如果不能恢复出正确的数据,就只是浪费空间而已。

第5条

交接和休假易出故障,变更需谨慎

这个是经验之谈。我们在总结故障的情况时,发现在公司部门有变化时,工作交接、故障的出现频率会比正常情况下多50%以上。有人说,这是因为机器或者应用是有感情的,舍不得离开运维者。

我们不谈感情,简单的理性分析一下。公司或者部门难免会做一些调整,变化是世界上唯一不变的事情。而运维人员是一线做事情的人,部门调整或者领导的更换可能导致工作的着重点不同,做事的方式和评测的标准变了,适应过程中难免会出现一些考虑不周到的地方,出故障也是情理之中了。

所以,运维部门和运维人员对变化需要尽量放平心态,接手别人的工作要一而再再而三地确认变更方案。请教人并不见得就是能力不行的表现;休假前最好各种可以做好的事情,准备一份文档,指明在什么情况下怎么做和联系哪些人。在别人放假的时候接手工作,“能拖则拖”,实在需要执行:必须不厌其烦地跟原运维者确认各个操作细节。

第6条

搭建报警,及时获得出错信息

报警可以让你及时知道系统出现了什么异常。性能监控可以让你了解系统的历史性能信息。分析故障发生时的各种现象,确认故障的真正原因;了解变化趋势,发现故障的苗头,及早优化和调整。报警和性能监控其实不不完全独立的,很多性能的监控项也可以报警出来。

转自:中科同向

上一篇:AIOps 实践思考:AIOps 如何与 APM 结合?(AIops社区)
下一篇:PHP 开发中的外围资源性能分析(二)
相关文章

 发表评论

暂时没有评论,来抢沙发吧~