运维本身是弹性较大的东西，但不管怎么样，他的地位越来越重要了。
我不是专业运维，我是专业看运维成长的。
发布方向：
最原始，硬写代码，没有版本。上线使用ftp，谁误改代码完全不知道。
然后，svn，git版本管理，提交记录有处查。继续使用ftp上线。
然后，接入jenkins打包工具，使用yum源安装包。全部配置自己！
然后，安装时替换配置文件，使测试环境与线上环境隔离开来。
安装集群环境，从一台台安装到使用for进行机器包的复制安装，到salt命令进行批量安装，批量操作。
然后，使用定制化的jenkins工具，进行打包部署，进行页面点击就进行部署操作。
然后，支持各个环境部署，指定版本部署，灰度发布，版本回滚等等。
各个上线步骤填写，各个上线资料填写，统一使用进行操作记录保留，以待后续查看。
权限申请，界面操作。
容器创建，界面操作。
工具导航，界面操作。
自动化测试，ruby自动化测试。
压力测试工具，jmeter，hp loadrunner。
容器方向：
最开始用物理机，一个服务一台。功能倒是很全，但同时只能一个团队在上面搞。
后来用虚拟机，一个物理机上搞多个虚拟机，机器占用稍微少点，可以多几个项目跑。
再后来，使用docker，一个机器上部署n个docker，而且采用复制环境的方式，让新建环境更快速更好。
监控方向：
最初，我们凭感觉排查问题，发现问题巨慢。
然后，我们打了各个访问点的日志，如果发现访问断了，那么就是这里有问题了。开始，我们不敢打太多日志，怕打太多无用日志，会导致服务器被撑爆。后来有了定时清理日志脚本，然后我们随便打日志了。
日志是事后处理，且有比较长的滞后性，于是有了埋点监控，当有异常情况时，向监控中心发送报警信息，cat。于是能够及时发现问题，根据堆栈信息可立马定位问题。
集群后，有些难的问题，需要查找整个访问过程日志，但是由于日志分散，无法有效截取信息，于是有了日志中心。
对于机器的运行情况，如内存，cpu，io等等，我们需要实时掌握，如有问题，及时处理，于是我们有了zabbix，grafana。
对服务调用情况监控，于是有了服务治理。
工具，是为解决问题而生。可能只有在遇到问题之后，才会想到去生产工具，所以工具其实是被动的。不过，了解过后，这些套路大可以指导自己提前规划。