1、初識(shí) DevOps
對(duì) DevOps 有這樣一個(gè)解釋?zhuān)?ldquo; DevOps 是一套實(shí)踐方法，在保證高質(zhì)量的前提下，縮短從提交對(duì)系統(tǒng)的變更到部署到生產(chǎn)環(huán)境的時(shí)間”，這是引用了我翻譯的這本書(shū)里的概念。我們看一下這個(gè)概念里有哪些值得注意的關(guān)鍵點(diǎn)：
我們?cè)诓渴鹣到y(tǒng)的時(shí)候，質(zhì)量是非常重要的。我們部署的系統(tǒng)，你不能因?yàn)樽兏膯?wèn)題導(dǎo)致業(yè)務(wù)中斷，這是不可接受的問(wèn)題。
要求交付機(jī)制也是高質(zhì)量的，就是你的交付過(guò)程。比如說(shuō)你交付到測(cè)試環(huán)境，交付到生產(chǎn)環(huán)境里面，也應(yīng)該是一個(gè)高質(zhì)量的。
在里面規(guī)劃了兩個(gè)時(shí)間周期：一是開(kāi)發(fā)完成的時(shí)間；第二是把代碼開(kāi)發(fā)完成到部署到線上的時(shí)間。
在這個(gè)定義里面強(qiáng)調(diào)了 DevOps 是一種以目標(biāo)作為導(dǎo)向的，它并沒(méi)有強(qiáng)調(diào)我們采取什么樣的形式的實(shí)踐，或者使用什么樣的工具。
目標(biāo)并不限于 DevOps 用于測(cè)試和部署的實(shí)踐，它其實(shí)是把整個(gè)流程都包含在里面。
我們看到在 DevOps 的定義里面，最主要的一點(diǎn)還是講到從代碼開(kāi)發(fā)完成到上線的過(guò)程。這也是行業(yè)內(nèi)對(duì) DevOps 理解比較多的一點(diǎn)。
這個(gè)圖來(lái)自企業(yè) DevOps 白皮書(shū)，這是對(duì) DevOps 理解的一個(gè)擴(kuò)展。相對(duì)于前面說(shuō)的那個(gè)概念，它講到從開(kāi)發(fā)到部署的過(guò)程，但是在這個(gè)圖里我們可以看到，它其實(shí)是把流程進(jìn)行了前置和延伸。
比如說(shuō)計(jì)劃、需求、設(shè)計(jì)，以及后面的運(yùn)維過(guò)程，它都把它納入到 DevOps 流程里面去了。這其實(shí)是講一個(gè)什么東西呢？一個(gè)產(chǎn)品或者一個(gè)業(yè)務(wù)有了想法之后，它就會(huì)進(jìn)行下面這樣的流程，從這個(gè)圖里面我們看到，它強(qiáng)調(diào)的是價(jià)值交付的過(guò)程。
從產(chǎn)品和業(yè)務(wù)來(lái)講，它開(kāi)始有些想法在里面，怎么通過(guò)技術(shù)手段、流程，快速的把這個(gè)想法變成一個(gè)產(chǎn)品，變成在實(shí)際場(chǎng)景中投放給客戶的產(chǎn)品，這是一個(gè)價(jià)值流的過(guò)程。
只有當(dāng)你的想法真正投入到里面去的時(shí)候，它才產(chǎn)生價(jià)值，你做的計(jì)劃也好，你做的開(kāi)發(fā)代碼也好，在沒(méi)有投放到生產(chǎn)之前，其實(shí)對(duì)用戶來(lái)講是沒(méi)有任何意義的。
上面這部分主要是講這個(gè)流程，在下面我們可以看到，其實(shí)它核心的理論支撐是精益和豐田生產(chǎn)系統(tǒng)。我們?cè)谡麄€(gè)流程中需要非常關(guān)注的一點(diǎn)就是持續(xù)改進(jìn)的過(guò)程，不管我們現(xiàn)在的流程是什么樣的，或者說(shuō)你已經(jīng)做到什么地步了，其實(shí)都是有一些可以改進(jìn)的方向，包括這個(gè)精益也是告訴我們要持續(xù)不斷地做一些改進(jìn)。
2、建構(gòu)組織文化
在這里面我想強(qiáng)調(diào)一點(diǎn)，不管 DevOps 的定義是什么，它都是一個(gè)價(jià)值流的交付。從產(chǎn)品或者是業(yè)務(wù)的想法開(kāi)始，把它快速地、高質(zhì)量的交付給用戶。但是在實(shí)現(xiàn) DevOps 的過(guò)程中，很重要的一點(diǎn)是文化。不管組織的類(lèi)型是什么，大部分組織都是懼怕變化的，所以采用 DevOps 這個(gè)新方法論可能是極具挑戰(zhàn)的。
在構(gòu)建組織文化的過(guò)程中，需要關(guān)注三個(gè)主要的原則：溝通、協(xié)作、集成。在這里面要強(qiáng)調(diào)一點(diǎn)，我們現(xiàn)在各個(gè)部門(mén)在協(xié)作過(guò)程中，可能還存在一些部門(mén)利益沖突的問(wèn)題，這也是一個(gè)很現(xiàn)實(shí)的問(wèn)題。
另外一個(gè)就是我們要倡導(dǎo)一種免責(zé)文化，大家都說(shuō)運(yùn)維背黑鍋，這個(gè)其實(shí)是不對(duì)的，關(guān)鍵的一點(diǎn)是我們是以?xún)r(jià)值流交付作為一個(gè)整體的目標(biāo)，倡導(dǎo)一種對(duì)事不對(duì)人的工作態(tài)度。
我們?cè)跇?gòu)建組織文化過(guò)程中要注意四個(gè)方面：
第一是團(tuán)隊(duì)內(nèi)的協(xié)作；
第二是團(tuán)隊(duì)之間的親和性；
第三是要使用一定的工具來(lái)加速流程的落地；
第四是伸縮性，隨著組織規(guī)模的擴(kuò)大， DevOps 流程也要做相應(yīng)的變化，
大家想想在我們的組織內(nèi)部，是不是有這樣的一些問(wèn)題，我們?cè)趥鹘y(tǒng)的開(kāi)發(fā)、測(cè)試、運(yùn)維過(guò)程中是什么樣的情況？開(kāi)發(fā)把代碼丟給測(cè)試去測(cè)，測(cè)試測(cè)好之后，又把這個(gè)包丟給運(yùn)維部署到現(xiàn)場(chǎng)，中間可能有相關(guān)的文檔，這本身就是一種筒倉(cāng)思維的表現(xiàn)。
筒倉(cāng)思維的英文叫 Silo，它就像是在沙漠里面，或者是大型的場(chǎng)地里面有這樣一個(gè)個(gè)存儲(chǔ)物品的倉(cāng)庫(kù)，每一個(gè)都是獨(dú)立、封閉的個(gè)體，它們之間是沒(méi)有溝通的，它們的利益也都是有沖突的。
這里講一個(gè)小故事，我們?cè)瓉?lái)有一個(gè)同事是來(lái)自國(guó)企的，他是做財(cái)務(wù)的。有一天他跟他的領(lǐng)導(dǎo)說(shuō)，我們現(xiàn)在很多的工作還是手動(dòng)的，我們是不是可以引入一些自動(dòng)化的計(jì)算機(jī)系統(tǒng)來(lái)做這些事情？領(lǐng)導(dǎo)就問(wèn)他，這樣做有什么好處呢？他說(shuō)，我們可以節(jié)省很多人力。
領(lǐng)導(dǎo)說(shuō)，節(jié)省人力不行，你節(jié)省人力了，我這事就沒(méi)有人管了。大家有沒(méi)有理解這個(gè)意思？就是說(shuō)在體制內(nèi)，領(lǐng)導(dǎo)比較關(guān)注他的權(quán)力的分配，而不是說(shuō)從整體角度提高工作效率。
還有一個(gè)與之類(lèi)似的例子，在上海有一家基金公司，我有個(gè)同事去那里應(yīng)聘，當(dāng)然級(jí)別也比較高，他發(fā)現(xiàn)他們?cè)诓渴鸬臅r(shí)候還是手工去部署的，有幾個(gè)同事專(zhuān)門(mén)做部署的工作。
他就想去推動(dòng)這些自動(dòng)化部署的工具，但是他的領(lǐng)導(dǎo)說(shuō)，我們還是要手工去布，這樣的話領(lǐng)導(dǎo)才會(huì)重視我這一塊，你全自動(dòng)化了，把我隱藏起來(lái)了，我這個(gè)經(jīng)理就沒(méi)用了，這就是很明顯的筒倉(cāng)思維。
包括我們?cè)谶\(yùn)營(yíng)一些產(chǎn)品或者業(yè)務(wù)的時(shí)候會(huì)發(fā)現(xiàn)，開(kāi)發(fā)和運(yùn)維之間互相踢皮球的事情，這也是一種筒倉(cāng)思維。比如說(shuō)開(kāi)發(fā)肯定是要求快速上線，而運(yùn)維要求穩(wěn)定，大家的利益產(chǎn)生了沖突，這必然會(huì)對(duì)我們的價(jià)值流產(chǎn)生負(fù)面的作用。大家可以想想我們生活中或者是在工作里面是否也有這樣的筒倉(cāng)思維的表現(xiàn)。
我們?cè)跇?gòu)建 DevOps 的過(guò)程中，必須要打破這種筒倉(cāng)，形成合力，讓大家圍繞價(jià)值流一致的目的共同努力。
3、架構(gòu)技術(shù)體系
在構(gòu)建組織文化過(guò)程中有三點(diǎn)：溝通、協(xié)作、集成。集成肯定是一種自動(dòng)化集成，而不是說(shuō)手工對(duì)接的過(guò)程。這就要求我們?cè)陂_(kāi)發(fā)、測(cè)試和運(yùn)維整個(gè)鏈條里面，在每個(gè)環(huán)節(jié)上要能實(shí)現(xiàn)一定程度的自動(dòng)化，不能說(shuō)沒(méi)有對(duì)應(yīng)的運(yùn)維自動(dòng)化系統(tǒng)來(lái)對(duì)接前面的需求，完全是通過(guò)公開(kāi)的形式去做發(fā)布、部署，其實(shí)是不符合快速交付這樣一個(gè)理念的。
關(guān)于自動(dòng)化運(yùn)維這一塊，我可以簡(jiǎn)單說(shuō)一下我們盛大游戲是怎么做的。大家知道盛大游戲目前是國(guó)內(nèi)比較領(lǐng)先的游戲發(fā)行公司，它創(chuàng)立的時(shí)間比較早，在1999年這個(gè)公司就成立了，到目前已經(jīng)有18年的歷史。
它現(xiàn)在面臨的問(wèn)題，在運(yùn)營(yíng)方面主要表現(xiàn)為幾個(gè)：一是服務(wù)器操作系統(tǒng)異構(gòu)；另外一個(gè)是我們的服務(wù)器數(shù)量特別多，在高峰期的時(shí)候，我們的服務(wù)器達(dá)到2萬(wàn)臺(tái)的規(guī)模。
因?yàn)槊恳粋€(gè)游戲代理過(guò)來(lái)的時(shí)候，游戲的開(kāi)發(fā)商（比如說(shuō)美國(guó)、韓國(guó)、日本）服務(wù)器的偏好不一樣，面對(duì)這樣的挑戰(zhàn)，我們?cè)趯?shí)現(xiàn)自動(dòng)化集成的過(guò)程中，我們是怎么構(gòu)建自動(dòng)化運(yùn)維平臺(tái)的呢？
從這個(gè)圖可以看到，我們有一臺(tái)中央控制機(jī)器，它從 CMDB 里面讀寫(xiě)數(shù)據(jù)，根據(jù)不同的服務(wù)器的類(lèi)型和操作內(nèi)容，把這個(gè)命令分發(fā)到對(duì)應(yīng)的服務(wù)器上面去。
我們可以看一下這里面的幾個(gè)特點(diǎn)：
第一，我們這個(gè)平臺(tái)是采用 BS 架構(gòu)的，不需要在電腦上裝軟件，現(xiàn)在在家里都可以操作，完成這個(gè)運(yùn)維任務(wù)；
第二，我們使用的是通用的協(xié)議來(lái)管理著所有的異構(gòu)系統(tǒng)，比如說(shuō)我們?cè)?windows 下面，大家知道以前管理 windows 是比較困難的，現(xiàn)在有很多公司在這一塊也是依靠手工去操作的，這樣會(huì)很麻煩，也有可能造成一些遺漏或者是錯(cuò)誤的過(guò)程。
對(duì)于 windows 管理，我們也是采用了 SSH 的方法去做，這樣就可以讓所有服務(wù)器以相同的方式管理起來(lái)，比如說(shuō)它們的安全策略，公鑰和私鑰的管理，另外還有一些審計(jì)，都可以?xún)?nèi)置在這個(gè)操作平臺(tái)里面。
關(guān)于自動(dòng)化運(yùn)維平臺(tái)這一塊，還要注意做一些并發(fā)的設(shè)置，以及超時(shí)和重試的機(jī)制，都需要考慮到里面去，不能因?yàn)橐恍╉樞虻膱?zhí)行，某臺(tái)服務(wù)器的故障，或者是連接服務(wù)器的問(wèn)題，導(dǎo)致它無(wú)法連接，導(dǎo)致整個(gè)任務(wù)延遲。
現(xiàn)在我們?cè)谧隽硗庖粋€(gè)系統(tǒng)是作業(yè)編排系統(tǒng)，如果知道 Ansible playbooks 的話，可以看一下它的方式和方法。我們知道 playbooks 是通過(guò)聲明一些配置項(xiàng)，然后把它編排起來(lái)，把所有的人工分類(lèi)的步驟做進(jìn)一個(gè)配置里面，讓它順序執(zhí)行。
比如說(shuō)我們做游戲維護(hù)的時(shí)候：
第一步，是先把服務(wù)器上的游戲服停掉；
第二步，停數(shù)據(jù)庫(kù)；
第三步，更新程序；
第四步，還要更新數(shù)據(jù)庫(kù)的一些表結(jié)構(gòu)；
第五步，把前面的游戲服務(wù)器啟動(dòng)起來(lái)，或者數(shù)據(jù)庫(kù)啟動(dòng)起來(lái)；
通過(guò)一些作業(yè)編排，就能更大地減少這個(gè)運(yùn)維的重復(fù)勞動(dòng)的過(guò)程，它的理念其實(shí)是基于場(chǎng)景的自動(dòng)化運(yùn)維。我們可以想想在運(yùn)維過(guò)程中有哪些工作可以串聯(lián)起來(lái)，這樣你就不需要對(duì)著一個(gè)文本的東西去做，因?yàn)槟阍趯?duì)著它做的過(guò)程中很容易造成遺漏。
比如說(shuō)你做游戲維護(hù)的時(shí)候，沒(méi)有把前面的關(guān)閉，你就直接維護(hù)數(shù)據(jù)庫(kù)了，這時(shí)候可能會(huì)導(dǎo)致玩家數(shù)據(jù)丟失的情況。通過(guò) playbook 編排系統(tǒng)，就可以避免這個(gè)事情，它是固化的，沒(méi)有辦法繞過(guò)前面的步驟去進(jìn)行后面的操作。
4、案例研究
剛剛說(shuō)過(guò)，大家在不同的行業(yè)里面，在不同的業(yè)務(wù)里面，它對(duì)應(yīng)的發(fā)布方式還不一樣，我相信目前我們?cè)谧模到y(tǒng)里面也有一些人是用手工發(fā)布的方法上線。我知道一個(gè)比較大的公司，它的部署也是很落后的方式，因?yàn)樗懊嬗胸?fù)載均衡，它布的時(shí)候還是要登一些腳本，把負(fù)載均衡上的東西剔除，然后再更新，它需要更新多個(gè)腳本，這是很浪費(fèi)時(shí)間和精力的過(guò)程。
看看我們以前面臨的問(wèn)題。這是我們的某個(gè)平臺(tái)，主要是支付相關(guān)的。大家知道我們除了游戲服務(wù)器之外，還有相關(guān)的登錄、認(rèn)證和計(jì)費(fèi)的平臺(tái)。我們第一個(gè)選取的案例是在支付平臺(tái)這邊做的一些 DevOps 實(shí)踐。
隨著公司業(yè)務(wù)的發(fā)展，日積月累，你這個(gè)模塊可能會(huì)越來(lái)越多，部署了之后會(huì)有測(cè)試，測(cè)試了之后交給運(yùn)維，但是測(cè)試的模塊名和運(yùn)維的模塊名可能是不一樣的，這里面存在一個(gè)協(xié)調(diào)的問(wèn)題。因?yàn)橛腥斯f(xié)調(diào)的過(guò)程，不然導(dǎo)致這個(gè)部署需要排期，原來(lái)部署和測(cè)試系統(tǒng)是割裂的，它們之間沒(méi)有對(duì)應(yīng)的關(guān)系。
我們是怎么改進(jìn)的呢？現(xiàn)在已經(jīng)做的工作是：
第一，我們建立在部署流水線上不同環(huán)節(jié)的模塊對(duì)應(yīng)關(guān)系，首先把它映射好。比如說(shuō)測(cè)試和運(yùn)維這邊的部署系統(tǒng)，它們之間的對(duì)應(yīng)關(guān)系要映射到數(shù)據(jù)庫(kù)里面去，這樣就可以實(shí)現(xiàn)從前端出發(fā)的部署動(dòng)作。
第二，后端的部署系統(tǒng)，它需要提供對(duì)應(yīng)的功能接口。比如說(shuō)它需要上游的系統(tǒng)提供一個(gè)模塊對(duì)應(yīng)哪些服務(wù)器的接口，當(dāng)上游需要部署某個(gè)模塊的時(shí)候，它就知道在測(cè)試環(huán)境里面需要部署哪些服務(wù)器，在正式環(huán)境，灰度發(fā)布的時(shí)候需要先部署哪些，再部署哪些。
第三，建立對(duì)應(yīng)的授權(quán)機(jī)制，我們可以把部分模塊的授權(quán)前置給開(kāi)發(fā)上線，或者是由運(yùn)維從內(nèi)部平臺(tái)直接部署上線，取得的效果是非常明顯的。在2016年12月份的時(shí)候我們做了一個(gè)統(tǒng)計(jì)，當(dāng)時(shí)有900多次的部署，其中50%以上通過(guò)新平臺(tái)自動(dòng)部署，大約10%的模塊可以由開(kāi)發(fā)自主上線，不涉及到核心功能的，開(kāi)發(fā)簡(jiǎn)單測(cè)試一下就直接上去了。非核心模塊的部署，我們可以在5分鐘內(nèi)完成，不再需要一些配置管理員進(jìn)行上線的排期和編排。
這是我們部署的系統(tǒng)的界面，它會(huì)選擇對(duì)應(yīng)的版本，選擇你是灰度發(fā)布，還是部署到生產(chǎn)環(huán)節(jié)里面，這個(gè)動(dòng)作很多情況下已經(jīng)不需要運(yùn)維去做了，直接測(cè)試完成之后就可以上線了，這時(shí)候就把運(yùn)維的工作解放出來(lái)了。
這是我們的部署過(guò)程，對(duì)于自動(dòng)部署，銀行和金融機(jī)構(gòu)有要求，開(kāi)發(fā)和運(yùn)維要分離，我們現(xiàn)在做的是讓開(kāi)發(fā)和測(cè)試都可以上線。
我們的底層部署是通過(guò)配置一些項(xiàng)目，比如說(shuō)模塊對(duì)應(yīng)的目錄、配置文件、執(zhí)行腳本，對(duì)應(yīng)的用戶，這個(gè)用戶主要是指啟動(dòng)程序時(shí)的用戶，以及對(duì)應(yīng)的某個(gè)模塊在不同的服務(wù)器上的IP列表，這些都會(huì)在系統(tǒng)里面進(jìn)行相關(guān)的配置，這樣配置之后就可以對(duì)前面的系統(tǒng)進(jìn)行相關(guān)調(diào)用。
這個(gè)案例也告訴我們一點(diǎn)，我們?cè)谶M(jìn)行部署設(shè)計(jì)的時(shí)候，暗含了對(duì)架構(gòu)的要求。
這里簡(jiǎn)單介紹三點(diǎn)：
第一，模塊化，可獨(dú)立部署，微服務(wù)有一個(gè)類(lèi)似的概念。如果你是一個(gè)大一統(tǒng)的體系，你很難集中發(fā)布這個(gè)東西，你還要協(xié)調(diào)很多資源，如果你做成模塊化，你自己上線，不影響他人，通過(guò)接口去調(diào)用，對(duì)自動(dòng)部署是非常有好處的；
第二，重試機(jī)制。作為一些后端的服務(wù)，它在部署的時(shí)候，不應(yīng)該影響前端的調(diào)用服務(wù)，前端的調(diào)用服務(wù)必須有一些重試機(jī)制，失敗的時(shí)候要能夠重連，這應(yīng)該集成在調(diào)用方的架構(gòu)設(shè)計(jì)里面，如果沒(méi)有重試機(jī)制，肯定是會(huì)影響業(yè)務(wù)的，這也沒(méi)辦法達(dá)到高質(zhì)量交付的目的；
第三，負(fù)載均衡與多實(shí)例的應(yīng)用。這里也講到，如果你的某一個(gè)功能只有一個(gè)模塊，你在部署的時(shí)候，不管它的時(shí)間窗口是什么，你必然會(huì)影響業(yè)務(wù)，有些請(qǐng)求會(huì)丟掉或者是失敗。通過(guò)負(fù)載均衡和多實(shí)例的方法，就可以包括你在部署部分服務(wù)器的時(shí)候不影響前面調(diào)用的結(jié)果。
總結(jié)
DevOps 的目的是打造持續(xù)增量的價(jià)值流并杜絕浪費(fèi)。我曾經(jīng)有一句話「任何不以消除浪費(fèi)為目的的 DevOps 實(shí)踐都是假的 DevOps」，我們實(shí)踐 DevOps 的目的，是實(shí)現(xiàn)從一個(gè)想法到真正把這個(gè)想法形成產(chǎn)品、形成服務(wù)，提供給用戶去用的流程。
縮短這個(gè)過(guò)程的時(shí)間，提高這個(gè)過(guò)程的效率是 DevOps 實(shí)踐的一個(gè)最重要的目的。我們要讓每一個(gè)步驟，每一個(gè)過(guò)程的價(jià)值都是遞增的，而不是說(shuō)產(chǎn)生等待，或者說(shuō)產(chǎn)生依賴(lài)，比如對(duì)配置管理的依賴(lài)，對(duì)人員的依賴(lài)，這都是有悖于這個(gè)目的的。
所以我把這句話送給大家：DevOps 的目的，最重要的一點(diǎn)就是加速高質(zhì)量的交付，提升用戶價(jià)值。但是在實(shí)踐過(guò)程中，我們可以從各個(gè)子環(huán)節(jié)的自動(dòng)化流程作為一個(gè)起點(diǎn)，很多時(shí)候你可能沒(méi)辦法一次性把整個(gè)部署流水線構(gòu)建那么完美，我們就可以分析是不是在每個(gè)子環(huán)節(jié)里面已經(jīng)實(shí)現(xiàn)了足夠程度的自動(dòng)化。
比如說(shuō)自動(dòng)化發(fā)布，現(xiàn)在是不是還是要靠人工去操作，這些是最基本的動(dòng)作，做好這些之后，你才有能力或者有條件和上下游進(jìn)行對(duì)接。只有完成的每個(gè)環(huán)節(jié)的自動(dòng)化之后，我們才有可能去構(gòu)建整個(gè)部署流水線。
也就是說(shuō)我們?cè)诼涞氐臅r(shí)候可以想想整個(gè)業(yè)務(wù)流程里面的痛點(diǎn)，比如說(shuō)你是部署沒(méi)有完成自動(dòng)化，還是測(cè)試沒(méi)有完成自動(dòng)化，導(dǎo)致了這個(gè)流水線沒(méi)有辦法流傳下去。然后以每個(gè)環(huán)節(jié)的自動(dòng)化作為一個(gè)開(kāi)始，然后把它們集成起來(lái)，就可以實(shí)現(xiàn)整個(gè)價(jià)值流的快速交付。
第三十六屆CIO班招生
國(guó)際CIO認(rèn)證培訓(xùn)
首席數(shù)據(jù)官（CDO）認(rèn)證培訓(xùn)
責(zé)編：content
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來(lái)自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，請(qǐng)及時(shí)通知本站，予以刪除。
搶沙發(fā)
