运维同学职场成长记

OP小强同学受难记

小强同学是公司的一名OP，日常主要工作就是负责 服务器的稳定和上线 。在公司开始发展阶段，业务不是很多，几台服务器就能够轻松搞定，每次找他上线的开发(RD)和测试(QA)同学，他都能轻松熟练的帮他们进行上线。

随着公司业务发展，服务器日益增多，找他来上线的RD和QA也络绎不绝，平时能够轻松完成上线的小强，发现每次都手动上线，又费时又费力，还经常出错，这样下去总是不行的，得想个办法。于是他就找了RD同学，希望他能够帮自己，写个 自动化脚本 实现一键上线。

RD同学虽然不乐意，但是也考虑到实际情况，就答应帮助小强同学，让小强说一下上线场景。小强想了一下说，上线吗，无非就是替换个包之后，运行起来就可以了。那你就按照：下载新文件→替换旧文件→开启服务这种顺序开发吧。

不到三天，RD同学帮小强开发出了一个程序。只需要填写下载地址，替换路径和开启服务命令，就可以完成 上线自动化 。有了这个神器，小强自然省了不少力气，对开发同学自然也是感激不尽。

到了周末，小强约上自己的女盆友出来约会。

本来两个人开开心心的。结果小强突然收到一条短信，短信提示某个服务突然停掉了。公司最近为了服务器的稳定，对每台服务器都安装了报警提示功能。只要是有服务或者机器发生异常，就会对OP立马进行提示，以便最快的速度进行修复。

是立马解决报警上线问题，还是先好好陪自己的女朋友？小强陷入了两难境地。To be,or not to be,that is a question.

没办法，作为一名职业的OP，问题再小也是问题。简单安抚女盆友之后，立马就赶回家，打开电脑检查问题。得出的结果是，RD同学在周末加班完之后，要进行上线测试。期间必须要关掉正在运行的服务，才能做文件替换。这个报警正是因为服务关掉而触发的。

小强同学很郁闷，这种报警属于 假报警 ，本不应该是值得关心的问题。结果因为这个，搞砸了难得的约会。

第二天刚到公司，立马就来了一个新难题。QA和RD同学都要同时上线。而上线的代码是完全相同的，但是因为一个要部署在测试环境，一个要部署在开发环境，所以要上线两次。小强心里觉得，还好还好，只要上两次而已。但是当他看到源文件的时候…

原因是因为本次上线的文件多达100个。这样通过自动化脚本的时候，光下载那一步就得耽误好久。而且只是因为开发和测试的环境不同，代码一摸一样，却要对每个环境都要上线一次，这不是浪费时间和资源吗？但是没办法，只能硬着头皮上线。小强为了能够提高速度，同时开了多个程序下载。不到一会，服务器就出现了I/O过高的问题。

当他千辛万苦部署好测试环境后，想再次部署开发环境的时候，发现了上线失败。为什么呢？经检查发现，是因为周末RD曾经上线过的文件夹用的是RD名字。本次小强要更新这个文件夹，用自己的名字当然会提示权限失败，当然上线就失败了。哎，没办法，小强只能跟那位RD同学沟通一番了。

结果，一天下来，发现自己啥事情都没有做，仅仅就光完成这两部分上线。

好不容易熬到了周五。为了弥补上周对女盆友的缺憾，小强早早就约了周末再次出去玩，而女盆友也是开心的答应了。结果在周五晨会的时候，经理下达全公司服务器都开始使用Docker。因为Docker容器的概念，能够实现快速部署和节省资源。所以这就需要所有OP同学在短期内，能够迅速把环境搭建好，不影响RD和QA的进度。所以，宣布本周OP要进行加班。不用说，女盆友又是非常的不爽了。

小强看着前几周还能用的自动化部署程序已经很难跟上现在的上线了。心中这叫一个苦。无奈之余，只能苦中作乐的写句歌词了：

明天你是否会想起

昨天失败的日记

明天你是否还惦记

被上线折磨的OP

百度OP和他的独孤九“荐”

小强觉得自己的公司规模还不算很庞大，就把OP已经累的不行了，那如果是大型互联网公司，那些OP应该怎么活呀。他突然想到自己的同学在百度也是一名OP，好像就没有这样的烦心事。那么他们究竟是如何做到的呢？他们的上线脚本究竟强在哪里了？抱着求教的心，找到了在百度工作的同学小李。

小李听到小强的苦恼，称这些问题在百度早已被解决。然后开始教小强如何破解这些难题。

第一“荐” ：下载限速

一台服务器成为下载源的话，那么就会出现很多机器同时要下载这台机器的资源。久而久之，这台机器肯定会出现I/O过高的性能问题。通常的做法是，下载的时候，要进行限速，这样就能避免有的服务下载过快导致I/O飞速增长。

第二“荐”：下载格式

百度内部每次上线的文件也会有很多。所以在上线的时候，要进行统一格式。要把所有的文件统一压缩成一个后缀名为.tar.gz的文件。这样可以达到两个好处：一是下载时间会呈现断崖式下降；二是在写脚本文件的时候，只针对这一种格式进行解压即可。

第三“荐”：多样下载

传统的下载方式是把源文件放在一个固定的机器上。但是如果这个源文件在多个机器上的话，传统的下载方式就不是最优选择。可以通过采取P2P的方式，让有源文件的机器都下载源，这样大幅提高下载效率。

第四“荐”：配置派生

针对不同的环境，要上线不同的源包，这种方式是不可取的，因为会极大消耗资源，推荐的做法是配置派生。具体的做法就是在需要加载的文件后缀名为.template，成为模板。在上线包的某个路径下，存放着一个conf_template.value文件。它的作用是专门匹配所有.template文件的值。这样，不同的环境，就有不同的.template文件，而conf_template.value又会保存不同的值，就可以实现替换。解决了同样的代码在不同的环境需要不同的配置文件问题。

第五“荐”：报警屏蔽

上线过程中会遇到需要停止服务的现象，通常这种情况产生的报警，我们称之为假报警，或者是无用报警，因此就必须要将它进行屏蔽。在报警端可以提供一个API。每一次上线的时候，拼凑参数调用API进行屏蔽。等到上线完成后，再通过另外的参数恢复报警功能。这样就解决了上线过程收到无用报警的问题。

第六“荐”：备份文件

很多情况下，替换完后的文件在执行的时候，并非达到了我们预期后的结果，甚至很多时候都出现了未知问题。所以比较好的做法就是先要备份一个旧文件。如果上线遇到问题，要马上进行回滚操作。

第七“荐”：节约空间

每一次上线，都会产生额外的文件，比如开始的下载包，以及解压后的文件。这些文件如果长期不处理，会给服务器的空间造成不小的负担。所以，切记一定要在部署完成后，将下载后的文件进行清理。

第八“荐”：总览全局

说了这么多，肯定已经很乱了把。每一个步骤都明白，但是连在一起，就是不知道谁先谁后了。其实如果把一个上线流程想象成一个家庭换灯泡过程，那流程马上就能想到了。

我们很容易就写出一套换灯泡的上线流程。如果把获得灯泡类比为下载源文件，关上开关就是停止服务，拿下旧灯泡就是备份文件，打开开关就是开启服务，扔掉包装就是删除下载文件。这样是不是就很容易得出一套完整的上线流程呢？

第九“荐”：自制流程

跟所有的武侠秘笈一样，一旦招数定死了，那么它的威力会大打折扣。这套上线流程也是这样。虽然已经定义了规范上线流程，但是仍然有可能会遇到有用户有特殊的情况满足不了。所以我们要在这套流程的基础上，可以让用户随意更改流程顺序，或者添加流程。

通常的解决办法就是把所有的流程都写入一个文件中，每一步都对应的一个Key，而Value则是对应的函数入口。这样用户想自定义流程，只需要更改Key的位置就可以了。

说完九“荐”之后，小强同学猛然开窍，明白了自己传统脚本跟百度内部脚本之间的差别，也明白了一整套上线流程的规范。不过他还有最后一个问题：

“这套上线流程，适用于目前比较流行的Docker吗？”

“当然适用啦。我们可以把每一个容器当成一个小系统。这套上线流程对系统内上线都是可以用的。百度现在的Matrix单机上线就采用这套方式。“

小强听完小李介绍后，很是羡慕在百度工作的小伙伴。经过多年的经验，百度同学已经将很多已知的问题化于无形，大大提升了工作效率。不禁问到，你们这里现在还招人吗？

小李听到后，哈哈一笑。说，当然有啦。目前2020年的校招已经开始啦！欢迎各位有志之士加入我们~

↓↓ 点击”阅读原文” 【了解更多精彩内容】