第一章：RD/OP 實(shí)際上在寫同一個(gè)分布式系統(tǒng)

1、每個(gè)應(yīng)用都是集群的一部分，每個(gè)RD都有一套自己的集群管理方式

有的設(shè)計(jì)得非常簡(jiǎn)單：一個(gè)配置文件，讀取一下數(shù)據(jù)庫(kù)的ip和端口

有的設(shè)計(jì)得非常復(fù)雜：使用zookeeper這樣的名字服務(wù)，自己做監(jiān)控，自己部署代碼，自己做服務(wù)發(fā)現(xiàn)等

RD的視角很少考慮運(yùn)維的問題，RD視角出發(fā)的集群管理基本上是以程序能夠運(yùn)行起來(lái)為標(biāo)準(zhǔn)的。

RD沒法不考慮集群管理，因?yàn)闆]有這個(gè)，程序是無(wú)法獨(dú)立運(yùn)行的。

RD沒法太多的去考慮集群管理，因?yàn)榇蟛糠值膽?yīng)用的開源的，無(wú)法假設(shè)實(shí)際的運(yùn)維工具棧。

2、每個(gè)運(yùn)維系統(tǒng)都是在給應(yīng)用打補(bǔ)丁，每個(gè)OP都在給RD擦屁股

運(yùn)維系統(tǒng)與分布式應(yīng)用沒有什么區(qū)別。運(yùn)維系統(tǒng)實(shí)際上是在做adapter，把每個(gè)接入的應(yīng)用建模成一樣的分布式應(yīng)用。

OPDEV實(shí)際上不是在寫運(yùn)維自動(dòng)化系統(tǒng)，他們?cè)趯懙氖且粋€(gè)分布式系統(tǒng)的集群管理模塊。

OP實(shí)際上不是在接入系統(tǒng)，而是在把各種亂七八糟，半拉子的分布式應(yīng)用改造成可運(yùn)維的模式。

一堆互相做法不同的系統(tǒng)，每個(gè)系統(tǒng)又由RD/OP兩種角色的人各搞半拉子工程拼接而來(lái)。

=================

第二章：面向場(chǎng)景面向過程的思維

發(fā)布：新的版本上線

變更：所有對(duì)已有版本的改動(dòng)

配置更新：變更的一種，用某種接口修改配置使其生效

擴(kuò)容縮容：變更的一種，增加機(jī)器

開區(qū)合服：變更的一種，增加一個(gè)業(yè)務(wù)上的set

故障處理：變更的一種，修復(fù)線上機(jī)器的故障

過程，傳文件：需要一種通用的文件傳輸機(jī)制

過程，執(zhí)行腳本：需要一種通用的獲取ip，腳本執(zhí)行機(jī)制

過程，調(diào)用API：需要一種通用的調(diào)用云服務(wù)的api的機(jī)制

過程，組合：面向每個(gè)場(chǎng)景的每個(gè)操作，都要有一個(gè)過程。更大的組合是對(duì)一堆過程拼裝。

結(jié)果是一大堆無(wú)法重用的腳本，無(wú)法審查，無(wú)法驗(yàn)證。bash/ant 等語(yǔ)言不是唯一問題，沒有足夠好的人來(lái)寫腳本也不是唯一問題。為什么需要這么多大體上是重復(fù)腳本，才是問題。

unscalable thinking

==============

第三章：對(duì)狀態(tài)進(jìn)行建模

idea：對(duì)狀態(tài)進(jìn)行建模。比對(duì)實(shí)際的狀態(tài)和預(yù)期的狀態(tài)得出動(dòng)作。

想法很好，但是實(shí)踐起來(lái)發(fā)現(xiàn)這個(gè)事情其實(shí)很坑：

問題1，從上往下事無(wú)巨細(xì)的描述狀態(tài)：從最上層的每個(gè)機(jī)器上運(yùn)行多少個(gè)進(jìn)程，到最底層的有幾個(gè)文件，都有什么內(nèi)容。

問題2，靜態(tài)地描述全局：需要描述有多少個(gè)ip地址，每個(gè)ip上都部署了什么，每個(gè)配置文件里的依賴項(xiàng)都是靜態(tài)確定的

問題3，動(dòng)作非常難搞對(duì)：無(wú)法測(cè)試這個(gè)部署腳本。很多時(shí)候在一個(gè)空機(jī)器上運(yùn)行會(huì)掛掉，但是在我的機(jī)器上運(yùn)行就是成功。

問題4，跑起來(lái)太慢了，而且不可靠：需要從外網(wǎng)下載一堆東西，很慢。即便不用下載，運(yùn)行一堆a(bǔ)pt-get也快不到哪里去

================

第四章：docker

docker解決的問題是狀態(tài)可以是一個(gè)很大粒度的東西。不用細(xì)粒度到文件級(jí)別，可以把一個(gè)進(jìn)程的所有依賴打包成一個(gè)黑盒。apt-get還是yum，就沒關(guān)系了。

================

第五章：名字服務(wù)，服務(wù)注冊(cè)，服務(wù)發(fā)現(xiàn)

smartstack做的事情其實(shí)是名字服務(wù)的統(tǒng)一化。構(gòu)建一個(gè)進(jìn)程和服務(wù)級(jí)別的名字服務(wù)（大部分運(yùn)維出發(fā)的CMDB，都是IP級(jí)別的），然后把所有人的名字服務(wù)全部統(tǒng)一成一個(gè)，可以網(wǎng)絡(luò)依賴問題。

================

第六章：marathon & helix 

這兩項(xiàng)工具其實(shí)干的事情是類似的。與其事無(wú)巨細(xì)地描述預(yù)期的狀態(tài)，不如給一定一些規(guī)則，讓系統(tǒng)去自動(dòng)決定最佳的狀態(tài)是什么。給定5臺(tái)機(jī)器不同負(fù)載，上面要跑10個(gè)進(jìn)程，marathon會(huì)幫我搞定每臺(tái)機(jī)器上跑哪些進(jìn)程。

helix也是類似，告訴helix需要多少個(gè)partition，都應(yīng)該是什么狀態(tài)，由helix去分配。

==================

第七章：detc

現(xiàn)狀：一堆互相做法不同的系統(tǒng)，每個(gè)系統(tǒng)又由RD/OP兩種角色的人各搞半拉子工程拼接而來(lái)。用一大堆腳本，以過程化的思維去管理系統(tǒng)。

預(yù)期：一堆系統(tǒng)雖然功能不同，但是用完全一致的方式來(lái)管理。接管所有RD/OP承擔(dān)的集群管理工作，全盤地處理問題。以面向狀態(tài)地思維去建模，雖然仍然有腳本，但是都是原子化可復(fù)用的。