從聊天說(shuō)起
有一次和朋友聊天冯遂，他說(shuō)他們有一次部署出事了，影響還挺大谒获，那次事故后蛤肌，他們公司對(duì)于部署流程增加了更多的審批。
當(dāng)朋友說(shuō)完前半句時(shí)批狱，我已經(jīng)猜到下半句裸准，那是很多公司或個(gè)人會(huì)做出的反應(yīng)。至于為什么會(huì)做出這樣的反應(yīng)赔硫，我也不知道炒俱。
我問(wèn)：為什么那次部署會(huì)“出事”？
他說(shuō)：當(dāng)時(shí)部署的人忘記了那臺(tái)機(jī)器上有一條 Iptable 規(guī)則，導(dǎo)致了事故权悟。
我就在想砸王，如果有人審批，那次事故就不會(huì)發(fā)生嗎峦阁？審批的人就知道那臺(tái)機(jī)器上有一條規(guī)則導(dǎo)致事故的發(fā)生谦铃？然后駁回這次部署嗎？連一線的開(kāi)發(fā)和運(yùn)維都忘記了的 Iptable 規(guī)則榔昔，“高高在上的審批領(lǐng)導(dǎo)”就更不知道了驹闰。
題外話：增加審批流程并不能避免這次事故，只不過(guò)當(dāng)出現(xiàn)事故時(shí)撒会，可以更好的定責(zé)嘹朗。然而我又好奇了，這種“審批”是為了解決問(wèn)題诵肛，解決什么問(wèn)題屹培？，還是為了逃避責(zé)任怔檩？誰(shuí)逃避了責(zé)任惫谤？誰(shuí)又有責(zé)任？
對(duì)于這類問(wèn)題珠洗，我心里已經(jīng)有數(shù)了，但想知道這位朋友的回答若专，就接著問(wèn)：那么怎么杜絕這類問(wèn)題呢许蓖？
他說(shuō)：因?yàn)槟菞l Iptable 規(guī)則的設(shè)置太久遠(yuǎn)了，是誰(shuí)都記不起调衰。如果能把每次部署的步驟記錄下來(lái)膊爪，這樣下次部署的時(shí)候，過(guò)一下以前的部署記錄嚎莉，就會(huì)知道那個(gè) Iptable 規(guī)則了米酬。（作者：大概原意，已經(jīng)記不清原話）
這位朋友說(shuō)的做法趋箩，我之前待的一個(gè)團(tuán)隊(duì)的做法也差不多：會(huì)有一個(gè)頁(yè)面專門(mén)記錄下每次部署的步驟赃额，步驟由開(kāi)發(fā)人員寫(xiě)，然后由運(yùn)維人員執(zhí)行叫确。只是我不知道他們會(huì)不會(huì)回顧之前所有針對(duì)這臺(tái)機(jī)器的部署步驟跳芳。
這個(gè)團(tuán)隊(duì)里有某某大型互聯(lián)網(wǎng)公司來(lái)的架構(gòu)師和某財(cái)務(wù)軟件公司來(lái)的運(yùn)維，所以竹勉，我不負(fù)責(zé)地推測(cè)飞盆，我們這個(gè)行業(yè)很多公司對(duì)于配置的管理還沒(méi)有達(dá)到足夠的重視，也沒(méi)有正確的看待。
我笑了吓歇，接著問(wèn)朋友：那我要知道當(dāng)前機(jī)器的“最終狀態(tài)”孽水，是不是要找出所有部署記錄，還要過(guò)濾出對(duì)這次部署有影響的每一個(gè)細(xì)節(jié)城看？比如那條 Iptable 規(guī)則女气。
接下來(lái)的對(duì)話細(xì)節(jié)已經(jīng)記不清，也不重要了析命。重要的是找出針對(duì)這類運(yùn)維事故根本原因及解決辦法主卫。
我個(gè)人認(rèn)為這類問(wèn)題的根本原因在于：
- 配置管理的失控：
已經(jīng)沒(méi)有人完整知道線上環(huán)境配置是什么了？要了解時(shí)鹃愤，只能一個(gè)個(gè)查簇搅。 - 測(cè)試環(huán)境與生產(chǎn)環(huán)境的配置不一致：
如果那位倒霉的同學(xué)在測(cè)試環(huán)境部署出現(xiàn)這樣的問(wèn)題，到生產(chǎn)環(huán)境部署時(shí)软吐，自然就會(huì)注意相關(guān)配置項(xiàng)了瘩将。
以上只是我個(gè)人認(rèn)為的，不一定正確凹耙，歡迎各位讀者討論姿现。
那如何杜絕這類問(wèn)題呢？
這兩個(gè)原因可以看作一個(gè)肖抱，也可以看作兩個(gè)备典。但方法都是一樣的：
- 使用聲明式的配置管理方法，而不是腳本式
- 版本化這些聲明的配置
- 所有環(huán)境使用同一套裝配置管理方法
使用聲明式的配置管理方法意述，而不是腳本式的
腳本式的配置管理是這樣的：
apt-get install build-essential
apt-get install libtool
cd /usr/local/src
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.37.tar.gz
tar -zxvf pcre-8.37.tar.gz
cd pcre-8.34
./configure
make
make install
而聲明式的配置管理是這樣的：
# ./ansible-nginx/tasks/install_nginx.yml
# 使用這個(gè)7-0.el7版本的yum包
- name: NGINX | Installing NGINX repo rpm
yum:
name: http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm
# 當(dāng)前機(jī)器的nginx的狀態(tài)應(yīng)該是最新版本
- name: NGINX | Installing NGINX
yum:
name: nginx
state: latest
# 當(dāng)前機(jī)器的 nginx service 的狀態(tài)應(yīng)該是已經(jīng)啟動(dòng)的提佣。至于如何確保 nginx 這個(gè) service，當(dāng)前是什么狀態(tài)的荤崇，又是如何啟動(dòng)的拌屏，我們不需要關(guān)心。
- name: NGINX | Starting NGINX
service:
name: nginx
state: started
聲明式的配置里寫(xiě)的是當(dāng)前環(huán)境的“狀態(tài)”术荤，語(yǔ)意上倚喂，聲明式的配置不論你執(zhí)行多少次，你得到最終的“狀態(tài)”就是你所聲明的瓣戚，這也就實(shí)現(xiàn)了《持續(xù)交付》里說(shuō)的：
確保部署流程是冪等的
無(wú)論開(kāi)始部署時(shí)目標(biāo)環(huán)境處于何種狀態(tài)端圈，部署流程應(yīng)該總是令目標(biāo)環(huán)境達(dá)到同樣（正確）的狀態(tài)，并以之為結(jié)束點(diǎn)子库。
這樣枫笛，你就不用在第1000次部署時(shí)，根據(jù)前999次部署腳本找出對(duì)這一次部署有影響的細(xì)節(jié)了刚照。
具體實(shí)踐時(shí)刑巧，我發(fā)現(xiàn) Ansible 就能很好的做到這點(diǎn)喧兄。
版本化這些聲明式的配置
將這些配置版本化的好處，就不需要重點(diǎn)說(shuō)明了啊楚。
所有環(huán)境使用同一套裝配置管理方法
具體一點(diǎn)的說(shuō)就是所有環(huán)境都使用相同的聲明配置吠冤，具體到不同環(huán)境時(shí)，使用變量替換恭理。這樣就可以保證所有環(huán)境的一致性了拯辙。
具體實(shí)踐方法，還需要根據(jù)所在團(tuán)隊(duì)調(diào)整颜价。你也可以通過(guò)本文附錄里鏈接涯保，參考其他人是如何實(shí)踐的。
小結(jié)
- 關(guān)于銀彈：如果真的按照以上方法就可以確保運(yùn)維萬(wàn)無(wú)一失了嗎周伦？很遺憾夕春，答案是否定的。就連亞馬遜這樣的行業(yè)標(biāo)桿都沒(méi)有辦法做到萬(wàn)無(wú)一失专挪。
- 關(guān)于定責(zé)：見(jiàn)過(guò)一些企業(yè)凡事都講究“定責(zé)”及志。定責(zé)可以有，但是定責(zé)了寨腔，是否真的能解決問(wèn)題了速侈？是值得討論的。
- 關(guān)于配置：團(tuán)隊(duì)對(duì)于“配置”的理解達(dá)成共識(shí)很重要
- 關(guān)于成本：要實(shí)現(xiàn)以上所說(shuō)的實(shí)踐成本高嗎迫卢？是不是需要一個(gè)DevOps團(tuán)隊(duì)倚搬？
說(shuō)實(shí)話，找到懂這些并有實(shí)踐經(jīng)驗(yàn)的人很難乾蛤，從這一方面看每界，成本很高。但是這并不是我們不朝這個(gè)方向發(fā)展的借口幻捏。另，對(duì)于軟件工程的“成本”命咐，大家沒(méi)有統(tǒng)一的定義篡九，所以也就更不好討論下去了。
附錄
關(guān)于配置管理
多環(huán)境配置管理
