掌握财富密码，运维还要了解这些技术

环境部署

一开始世界是开发的，然后才是运维的。

开发实现产品逻辑，将产品开发完成后，然后提交运维进行部署。此时允许就需要准备好部署环境，如部署在Linux服务器上，安装相应的软件，如Apache、Nginx、tomcat、JDK、PHP、MySQL等等。

除了软件，还需要看看具体是哪个版本，java 7 和java 8 的差别还是有点的，php5和php7也有些语法不兼容。把软件都安装好了，就可以上线了？还是不行。还需要测试吧，那就还需要部署一套测试环境。有些时候，开发环境也是需要运维来部署的。

事情从来都不是一帆风顺的。

上线没多久，服务就502了，老板要疯狂输出。尽管你有一肚子小委屈，我只是个运维，代码不是我写的，为什么要我来背这锅？！委屈归委屈，服务访问不了了，就是运维的事。尽快定位问题，解决问题才是王道。怎么来定位问题呢？最简单直接的办法就是看日志，看系统日志，看软件相关的日志，结合故障现象和经验，快速地进行定位和恢复。然后就是总结经验，吸取教训，写事故报告。OK，现在你知道，需要对系统环境需要进行一定的调优操作，不再做背锅侠。

相关技术: top, vmstat, iftop, awk, sed, sar, iostat, strace, ...

做最好的计划，做最坏的打算。

前不久的gitlab删库事件的教训犹在眼前，丢失了几小时的数据，虽然大部分的备份策略都失效了，但还是挽救了几小时前的一个备份，才没有造成更大的数据丢失和公司损失。我们需要对设备进行备份冗余，需要对数据库进行备份及离线备份，需要对网站静态进行备份冗余，需要对机房进行备用，能做到双活，那是更好的啦。

相关技术: rsync, crontab, lvm快照, mysqldump, extrabackup, 完全备份, 差异备份, 增量备份, 离线异地备份, ...

没有永垂不朽，我们不能保证硬件24小时在线，但需要保障服务24小时在线。

出现故障后，如果做好高可用和冗余，故障自动切换，移除故障节点，那样也就保障了服务的实时在线。在老板和用户不知情的情况下，悄么的把故障处理好的，KPI算是保住了，奖金也许就会有的吧。

相关技术: F5, Nginx, LVS, HA-proxy, MHA, Zookeeper, 各种其他分布式集群方案, ...

运维工程师的第一次解放运动。

时刻担心网站挂掉，一年365天、每周7天、每天24小时，时刻保持精神高度紧张，就算你是神仙都会撑不住的。我们需要一个机器来监督其他的机器工作，我们需要解放我们自己。当有故障发生的时候，通过短信、微信、钉钉、邮件等等通知对应的运维工程师来处理，甚至是自动切换或摘除故障节点，然后我们离线对故障节点进行问题排查。

相关技术：Zabbix, Nagios, Cacti, Prometheus, open-falcon, Ganglia, sar, ...

安全和审计

狂奔在互联网的高速大道，不过有些人是在裸奔。

不安全的网络环境和服务器配置，无异于在网络世界裸奔，任何人都可以窥探你的隐私。你的应用是否做了SQL防注入？你的防火墙是否开启？是否还在用root+密码的方式登录服务器？网站开启了https么？是否对系统操作进行审计？

相关技术: iptables, firewalld, waf, auditd, 各服务的正确配置, ...

运维工程师的第二次解放运动。

偷懒是社会进步的第一动力。聪明的我们怎么会让自己一直在重复枯燥的事情上浪费时间，装系统、部署环境、发版本、批量操作，把这一切交给程序去实现吧，我们需要的是享受生活。

相关技术: shell, python, go, rundeck, ansible, saltstack, puppet, chef, cobbler, fabric, ...

虚拟化和云服务正在发生的一场运维革命。