具体摘设备、传新备老代码、重启java容器、回滚代码的工作我都写好脚本了,就这样还因为麻痹大意而出了几次高负载或丢步骤的情况。
如果能运维自动化的东西,必然能写shell脚本搞定,如果用shell脚本搞不定的东西,“运维自动—挂”。
运维自动化优化
老生常谈,运维应该眼界高一些,不要总是忙着优化手头的工作,而要想手头的工作有没有必要。
有朋友肯定要说我的工作不到家,上线居然还需要人力判断,我承认这是问题,但这问题在架构不在运维。如果上线不需要人工干预,为什么不直接让开发执行?甚至更进一步,让应用服务器定期去svn上检测有没有新代码?在测试环境我们也会用hudson和maven让开发自己搞,但我肯定做好一个系统镜像保证他们把系统玩坏了也能快速恢复。
在生产环境里,运维该做的不应该是纠结一步人肉操作该用shell还是python代劳,而是说好好去推动一下,能不能多上几台服务器,能不能降低一下耦合度,不要让我们手动盯着上线工作了。
我现在的公司后台做的不好,很多业务相关的sql修改都要开发写好语句给运维执行。如果这个时候我给mysql安装个phpadmin就是本末倒置,写个脚本能自动传sql过去还是本末倒置,我实际该做的是催促公司尽快做出来企业管理后台可以让运营和客服人员直接去改业务数据。
我们写多少牛逼的python脚本,不如做一个稳定到单机房断电都不会宕机的架构;用好运维自动化很牛逼吗?是的,就跟用好某种文本编辑器一样牛逼。
运维自动化背后的利益推动
鼓吹自动化的大师里,很多位其实是运维开发两条腿都很短的杂鱼。
我曾经看到过一个运维自动化的教程,作者很认真的教我们,如何用某种自动化工具调用本地shell,用sed命令将crontab里的ntpdata任务时间给变更了。看到这一段,我被他的执着蠢哭了,所谓的自动化居然是用ntpdate更新系统时间。
我也见过某大师写的自动化代码,朋友告诉我他的python水平只值6k—连异常都不处理,我用半瓶醋的水平仔细看了一下他的源码我真的笑出来了,每隔几行必然能看到一个os.system(“shell命令”)。
在工作环境里,我用“tar/var/aaa/bbb/ccc/*.jpg”这类通配符匹配出来目标文件,写了个10行的脚本,将某高手用perl写了100多行