本文根據張孝峰老師在〖Gdevops 2017全球敏捷運維峰會廣州站〗現場演講內容整理而成。

講師介紹

張孝峰，AWS資深架構師，20年技術研發經驗。

今天將跟大家分享一下亞馬遜AWS在DevOps方向的一些見解。AWS其實是在亞馬遜整個DevOps沃土中發展起來的一個產品體系，所以在講AWS時，我希望給大家看到的不是一個服務的廣告，而是一些DevOps理念真正的實現。

關於DevOps

大家對DevOps也比較清楚了，我們不希望研發人員直接把程式碼丟給運維，再讓運維去做，因為程式碼的釋出是一次釋出成千上萬個，如果出現問題，我們不知道怎麼去修改，我們的希望是讓整個程式碼釋出、整個運維更加順暢。所以在亞馬遜，DevOps需要管理很多很多方面的問題：包括了基礎設施、IT自動化和配置管理、版本控制的整合、持續整合和持續交付、持續部署、應用和基礎設施的版本管理、監控和日誌管理等。

亞馬遜的DevOps故事

1、亞馬遜開發流程的演進

亞馬遜作為一家非常龐大的電商公司，最早進行開發時也有很多的團隊，把它分在一個程式碼裡去釋出，然後在開發時會用一種很傳統的原始碼編譯、特色生產的過程去做。

這個過程持續了很久，直到2001年，我們的創始人跟一個巨大的運維團隊將裡面越來越多的開發運維進行了改善，所做的就是把整個亞馬遜的服務拆成很多微小的服務。當時在內部有個說法，可以看到就是上圖中的2 pizza teams，即我們希望用兩張披薩餅就可以餵飽每一個承擔這些微服務的團隊，這一點在亞馬遜內部是貫穿始終的。兩個披薩餅、一頓午飯，大概就是說2到10來個人的團隊，這個情況下每個團隊都是在這麼小的一個範圍內，他們能對外提供一個統一的標準化的介面，內部也可以用自己的方法去構建自己的服務，去保證整體的服務是一個統一的整體。

這樣的情況下，我們通過構造一個巨型的面向服務的架構，單一地通過不同的APL呼叫，把整個亞馬遜的各種服務進行一個高度的解耦，最後達到的效果就是每一個團隊都有自己的持續整合、持續交付、持續釋出的靈活情況。

軟體生命期新的管道

這個情況可達到怎麼樣的效果呢？可以達到一年5千萬次的部署，如果按工作日來算，就是平均下來一年裡每11秒就可能會有一個小版本部署上去，這個版本部署可能只有幾十行程式碼的修改，然後2 pizza teams會針對這個版本做自己的迴歸測試、單元測試，保證自己提供出去的APL是穩定可靠的。

總體通過一個巨型的架構，利用中間的微服務APL呼叫來保證我們整體去做，所以可以同時部署在很多不同的伺服器、應用上，這是亞馬遜今天能夠做到的。

我們遮蔽了以前舊的軟體交付方式，可能要用很多不同的版本，甚至用十幾個介質來配適我們的客戶，包括在亞馬遜AWS上的客戶，他們已經可以很好地用新的這種交付方式去做。這裡，亞馬遜想到，除了能夠讓我們自身的團隊變成這樣，其實能不能為我們的客戶去做到這樣一個微服務的架構或持續整合的架構，於是就有了亞馬遜AWS服務體系的誕生。

接下來我會介紹AWS這部分DevOps方向的一些服務，通過這個服務去看到我們如何能夠在一個雲端非常敏捷地實現DevOps，同時也會介紹到一些DevOps的框架和工具。

基於AWS服務實現DevOps的框架和工具

1、AWS對DevOps的全面支援

首先AWS對DevOps是全面支援的，包括從程式碼的提交到各種的FreeWork Test，然後會有SDK去呼叫我們的APL，去使用平臺的各種基礎設施，建立流暢的自動互動渠道，下圖是我們整個持續流程的模型。

這個模型也包括了我們整個域名服務。域名服務很多情況下跟我們整個DevOps的服務是一個最基礎的入口，因為訪問是通過域名去進入的，那麼，我們在域名這一端通過一個智慧DNS可以做到藍綠髮布這樣一些動作，然後通過我們的基礎服務來獲得基礎服務提供的這些服務。這個基礎服務旁邊是各種的原始碼庫，還有專案管理庫會用去構造不同的服務，去自動化地持續整合到我們實際的服務裡去。

持續整合模型

2、AWS CodeCommit

第一步接觸到的是AWS的Codecommit，你可以認為它是一個程式碼管理庫，它在整個AWS Devops服務體系中是處於最左邊的位置，就是在我們的開發、版本管理這個方向，那麼它能夠提供一個怎樣的東西呢？

它其實是一個Git的服務，就像現在大家都會使用Github去管理自己的程式碼，那麼在AWS的Codecommit，它是一個典型AWS微服務的結合，它會用到AWS S3這樣的物件儲存服務去儲存程式碼實際的部分。因為在這種情況下，相比傳統的磁碟，S3會有一個更好的方式去儲存一些大檔案。作為一個海量的程式碼庫，它對一些大的分割槽或者大尺寸檔案的儲存會有更好的優勢，而後我們會使用Amazon的NoSQL服務去作為它的元資料管理。這個在Git裡面，我們的版本控制、各種分支的控制，都可以在這邊去做到，我們也可以通過KMS去加密存在AWS的程式碼，因為相信對很多公司來說，做好自己原始碼的保密性是非常重要的。

有了這樣一個Git的服務之後，我們就很容易會去構造企業私有化的一些倉庫。眾所周知，如果我們使用Github的方式去管理，它的私有化倉庫是要付費的，那在CodeCommit這樣的方式裡，我們是可以提供免費的私有化倉庫，只需要出少量的儲存費用就可以去做，所以這個本身也是一個由亞馬遜自身微服務組合而成的一個組合型服務。

AWS CodeCommit使用方式

關於Git的提交大家也都很熟悉了，其實可以把Codecommit作為我們最常見的一種方式，因為Git的倉庫其實是平行的，所以Codecommit作為我們的遠端倉庫，它可以跟本地一些分發的倉庫平行地去做，可以把需要做雲端的Devops的部分作為一個特殊的Commit許可權，或者叫Push的許可權放到雲端去，同時本地還可以維護這樣的Git倉庫。

3、AWS CodePipeline

有了這個程式碼以後，就需要在雲端去構造一個Pipeline流程，或者說一個持續整合的流程，我們可以通過CodePipeline這樣的視覺化工具去調動雲端的服務，去進行各種自動化的持續整合工作。

AWS CodePipeline管道流程

這個持續整合的工作通常包括了好幾塊，會有程式碼、構建、各種的Staging，我們需要在不同的Staging裡面去做不同的測試，可能我們有些專案裡需要一些人工的審批，確定是否去不到我們實體的生產環境裡去，這一部分無論是自動化的流程還是人工審批的流程，我們都能視覺化地構建在Codepipeline流程裡，去讓它很完善地流動起來，資料也就可以很好地在這上面去做。

這個是CodePipeline介面的截圖，我們可以把Source、Beta階段、QA階段通過一個很好的視覺化工具去做，相信在座的各位應該用過Jenkins，或者別的一些開源工具，都能夠構造出一個很好的Pipeline。在AWS上面，大家可以沿用自己傳統的一些使用工具或已經非常熟悉的工具去做，這些都是支援的，包括我們的Codecommit，也會有相應的Jenkins外掛去整合。如果是初創企業或者新的研發團隊直接使用雲端的資源，也可以大大節省學習成本和部署成本。

4、AWS CodeBuild

有了CodePipeline和CodeCommit以後，我們就有了流程，有了原始碼，這時可能就需要一個很重要的編譯。編譯環境在很多的開發團隊或者說在DevOps過程裡是非常重要的，很多團隊可能會使用Jenkins或者別的一些工具去構造這樣的編譯流程，但AWS CodeBuild是在具有彈性的雲端編譯工具和環境中，它會預先幫大家構造好一些成熟、常見的編譯環境，比如安卓、Java、Golang等各種的編譯，當然JS不算是一種編譯了，但JS的專案通常也需要打包，所以我們就無需重頭去建立這樣的一個編譯環境。

AWS CodeBuilde工作流程

另外還有個非常重要的事情，在很多已經很成熟的團隊裡，可能公司內部已經構造了一些很好的編譯環境，這些我們也已經搭建了，但沒辦法避免的一件事就是我們的本地資源是有限的，很有可能在不同的團隊下面，我們可能剛好有一個大的發版情況，比如說在雙11前我們會集中式地去做一些開發，這時可能同時有好幾個團隊都在編譯，這種情況下，我們的資源就很有可能會不足。但在AWS CodeBuild的過程中，每一個團隊去建立一個CodeBuild例項時，它其實都是在雲端申請了一段新的資源，這時它的資源永遠是不會跟別的團隊去競爭的，這個情況可以大大保證我們的開發團隊整個開發的過程，而不會因為一些開發流程的競爭而導致實際工作被阻塞，這個是雲端一個非常大的好處。我們在雲端去構造比如Jenkins這樣的環境時，其實也很難去構造一個完全彈性的環境，而CodoBuild裡是有一些已經內建好的，當然如果有一些自己的釋出情況，也可以把自己打包成一個Docker的映象，作為一個Customers的Codobuild映象釋出上去。

有了CodePipeline、CodeCommit、CodeBuild以後，我們就能在雲端很容易地構造一個持續整合的完整鏈條。我們的程式碼Commit以後，有一個很常見的開發過程，比如說我們本地有一個開發團隊，他們本地可能使用Gitlab建了自己的一個開發的Git倉庫，本地倉庫進行完一個簡單的單元測試以後，它就可以通過這個團隊的管理員，比如說他是有許可權去把這個程式碼Push到遠端的CodeCommit的倉庫，那麼這個程式碼一旦進到Codecommit倉庫，後面的流程就完全自動化，CodePipeline會發現Codecommit的一些改動，然後會把這個程式碼拖下來，啟動一個Codebuild的環境進行一個編譯，接下來我們還可以持續地結合一些測試的工具進行一個程式碼測試，步入單元測試，或者說一個QA的測試，而生成的程式碼我們可以放在S3上面，這樣就完成了一個持續整合的過程。

AWS 持續整合

這是一個在雲端很順暢的過程，當然，即使我的一些客戶他們也在雲端構建了類似的過程，他們也不一定要使用到亞馬遜的服務，最重要一點是，在雲端的一些資源，因為都是彈性的，在不適用時，Build伺服器其實不會佔著我們的使用費用或開機費用，CodePipeline也會在後面默默地等待Codecommit的儲存，所以在整個開發的過程中，如果我們很多時候可能都沒有動到這一塊，它整個過程是沒有產生任何費用的，只需稍微給一些程式碼儲存的費用，只有當我們的程式碼真正進入到遠端的分支以後，它才會開始啟動AWS雲端的服務，去產生這樣的一個實際的整合。有了持續整合以後，我們就要進行持續地部署了。相比持續交付，持續部署更多的一個情況在於部署過程中，會把人工化儘可能地減少，逐步地做到完全自動化的部署。

持續交付與持續部署的區別

5、AWS CodeDeploy

我們會有CodeDeploy這樣一個服務，CodeDeploy的服務其實是處於AWS整個Devops體系中一個承上啟下的作用，它往後會跟我們的CodePipeline去做整合。

當CodePipeline做了一個測試以後，它就可以往前去呼叫我們的各種基礎設施，去生成一些真正的生產環境或者說藍綠測試的環境，去部署我們的軟體包在上面，並且呼叫一些測試的過程。CodeDeploy能夠很容易地通過一個很視覺化的部署，去把我們的實際的軟體包釋出到不同的環境裡，比如說我們有開發的環境、測試的環境，還有生產的環境，它可以集中化地控制成千上萬臺不同的伺服器，然後做滾動的釋出等各種情況。

這是一個很典型的部署流程，我們可以通過自動化部署直接釋出到實際的應用裡面去，比如說Instance，在亞馬遜上面就是我們實際的例項，可以通過Auto-scaling group去按照我們實際的一個業務流量去擴充套件這個例項，並且這些擴充套件也是可以被自動關聯起來的。

這個是CodeDeploy的一些語法，它使用YAML的方式去定義一個實際的版本控制，在整個Deploy的過程中，我們可以控制它的程式碼在什麼地方，安裝包在什麼地方，安裝成功前後，我們都可以做不同的Staging動作。

此外，我們可以去編排不同的目標組，因為不同的目標組可能會有不同的例項大小，或者例項組。

這個其實在很多的團隊裡都會用到，他們開發的環境會有這樣的一些環境，在我們的生產環境會有更多、更強勁的伺服器去做，這些東西我們都可以通過CodeDeploy的一個描述把他們全部描述完成，有了這樣的部署以後，現在一鍵就可以去創造整個部署的目標，包括CodePipeline也可以直接呼叫這樣的CodeDeploy去做。

還有很重要的一點，就是我們可以在雲端很好地去呼叫雲端彈性的資源，去構造不同的釋出方式。比如說我們在雲端希望保證一個數據的可用性，可以把它變成一次一臺的釋出、一次一半的釋出或者一次全部的釋出。

圖：Codedeploy如何工作

圖：CodeDeploy就地部署

其實在雲端還有一些更好的釋出方式，因為一般來說，雲端的資源像開水龍頭一樣，您可以認為它是無限的，所以我們的Auto Scaling Group會去做一個折算的彈性發布。比如說我們原來的業務在生產系統裡面本來是有三臺機器的，然後需要去擴充套件我們業務或者釋出一個新版本時，我們可以在很短的時間內在雲端產生一臺新的機器，把我們實際的新的版本放到這臺新的機器上面去，再通過剛才說過的域名方式或AWS負載相容器的方式，把一部分的流量往這個地方去釋出，這個情況其實構成了一個藍綠的釋出。

這個藍綠髮布在綠的部分完全是一個新的機器，不會干預到我們實際的生產環境的機器，我們通過這樣域名的方式去把一部分的流量引入到綠方的新發布里去，然後通過雲端的工具去監控綠方這邊的動作。剛才說到的，我們可能會監控它的錯誤碼、訂單下載量等，發現這個綠的部分情況完全沒有問題後，我們可以在雲端逐步地增加綠這邊的流量和它實際的機器數量，最終我們發現在新的版本環境已經完全可以支撐服務了，我們再移步把藍方這邊舊的環境全部給切換掉，把機器也關閉掉，這裡成本幾乎是沒有增加的，增加的只是在這幾個小時的釋出過程中一個雙倍機器的成本，之後我們還是用一樣的機器去支撐一樣的服務，這是一個在雲端藍綠髮布非常好的實踐。

所以，當CodePipeline加上CodeDeploy，我們就可以很好地控制持續部署的流程，後面我還會介紹OpsWorks和Elastic  Beanstalk，折算子的基礎設施即程式碼的服務。這個也是我們希望做到的一點。

6、基礎架構程式碼化

剛才說到了AWS其實是亞馬遜微服務化的過程中的一個產物，在這個過程中我們發現這種經驗不僅僅可以幫助到自己，也可以幫助到我們的客戶，所以我們在2006年就發明了這樣一個公有云的服務。這個公有云服務一個很重要的過程，就是說我們希望公有云上面的一切東西都是一個API，有了這個API以後我們就可以用程式碼去描述我們在公有云上的每一項服務。所以在AWS DevOps服務的右手邊，包括部署、搭建、監控、運維等，這都是一些基礎設施即程式碼的服務，這裡麵包括了我們的Elastic  Beanstalk，就是說如果我們的團隊僅僅是開發一個PHP的整合環境或Tomcat的整合環境，我們並不需要很複雜的互相訪問架構，這時就可以使用Beanstalk；如果是需要描述一些很複雜的互聯方關係，可以使用CloudFormation這樣一個YAML或者JSON放入描述語言，去快速地構造雲端的整個基礎設施。

當然，如果你的團隊在Chef這方面有很深的研究，也可以使用我們的OpsWorks，按照Chef的方式去定義整個環境的各種Layer，而且我們可以直接使用在社群各種Chef的Code去呼叫AWS的環境。

圖：操作AWS服務的三種方式

首先這是AWS服務的三種服務方式，很多人剛剛接觸AWS時，第一個接觸到的一定是左手邊的Web控制檯，Web控制檯是很重要的一個使用者介面，我們可以在Web控制檯上控制大部分的AWS服務，但其實這些Web的控制檯上面的每一項功能，後面都會對應著一個DevOps API或SDK，然後可以通過我們的開發或命令列去操作這樣的DevOps工具，有了這樣的基礎以後，就能做到各種基礎設施即程式碼的服務。

7、Elastic Beanstalk

最簡單最傻瓜的版本就是Elastic Beanstalk。如果我們新建的創業團隊有一個電商或者網際網路的專案需要構造跟微信的對接，會使用一些特定的技術棧，比如我們會使用PHP、MySQL這樣的方式。而現在你只需要在Elastic Beanstalk上面選擇一個這樣的技術棧，一鍵就能幫你去做出這樣一個完整的環境，裡面包括了的語言比如PHP，還有底層的一些資料庫服務，都會安裝好。這樣的情況下團隊馬上就可以投入到開發的工作，而不需要擔心各種的基礎設施的問題。同時我們的應用部署可以自動擴充套件，可以去跟各種的ID做結合，這樣的情況下，程式碼人員純寫程式碼就可以執行到這樣的一個環境。

AWS自身的環境包括了Java、PHP等這些東西，Golang也可以用到。我們一樣可以通過Elastic Beanstalk部署到在持續整合裡，而當經常面對到不同的環境時，比如說我們會有測試、Staging的環境、生產的環境，他們之間可以通過不同的版本去釋出，而不會去互相地影響到，我們也可以調一部分環境去測試。

圖：Elastic Beanstalk構建不同版本環境

8、Cloudformation

接下來如果要構造一些更詳細的服務，我們可以使用CloudFormation。剛才說到AWS所有的資源，無論大小，它在提供時一定會提供API，而且我們會有SDK，在這個基礎上，我們構造了CloudFormation這樣一個組建的工具，可以通過JSON或者YAML的方式去描述你在AWS上面任何一項資源。

這個資源我們是可以通過變數去控制的，比如說常見的一些生產環境和測試環境，它們絕大部分的結構是一樣的，但他們需要的JSON的大小可能不一樣，我們可以通過一個JSON檔案或YAML檔案去備註一下他們的關聯關係，然後通過不同的引數去啟動不同的環境，一旦這個模組檔案產生了改變，我們後臺的程式也會自動根據你的模板程式的改進，去改變你們使用的一些資源跟它們的依賴關係。可以這樣理解，JSON檔案是一個類，它跟模本的程式產生每一個堆疊，這個堆疊就是這個類產生的例項，然後剛剛提到的變數，根據這個變數，這個例項的大小就會不一樣。如果你的類改變，它的例項也會跟著做一定的改變。

圖：CloudFormation元件和技術實現

這樣的情況下，我們就可以做到整個基礎設施平臺的模板化，這對於DevOps是非常有用的，也就是說整個基礎設施可以非常好地管理起來，比如說可以使用AWS的各種程式碼管理工具去管理我們的基礎設施。

圖：基礎平臺模板化

比如下圖中的這個伺服器，原來只是Application到資料庫的，現在要在中間增加一個Redis作為快取，基礎設施的這種改變，可以完全用程式碼的方式描述起來，並且這個改變也可以被Commit到我們的程式碼庫裡，因此我們能夠知道這個改變是什麼時候產生的，為什麼要這樣產生，可以很好地去做這樣一個動作。

圖：基於模板的快速部署

基於這樣的模板就可以產生不同的環境，這些環境可以去做不同的改變，然後我們也可以做到不同的生產測試環境與藍綠部署。

圖：Cloudformation一鍵部署全站

這個也是CloudFormation目前能夠做到的事情，特別是對很多團隊來說，當在中國的業務做大了後、想往海外發展時，我們可以利用在中國積累的經驗，很容易地應用AWS的基礎設施快速地部署到10-20個不同的海外區域，如歐洲、美國、中東甚至東南亞這些地方，這些均可通過一個程式碼、一套程式碼，去一次部署完整個的服務。

9、Opsworks

Opsworks大家可能不太熟悉，但說到Chef，各位可能多少都聽過。Opsworks其實就是AWS提供的一個託管Chef的工具，它完全跟Chef一樣，能把AWS實際的一些資源抽象化成Chef裡面不同的Layer並給大家提供到服務，所以我們就可以利用它在Chef方面的一些經驗去控制到我們在AWS上的這些資源，包括了它的Step以及不同的Layer，比如說資料庫的Layer，No banners這一部分的Layer，還有我們實際Application計算資源的Layer，都可以被控制到。

然後AWS就可以通過每個使用者的Chef Code去產生實際的計算資源，它可能比傳統機房的Chef會更有效，因為對於傳統機房，如果你要把這些Layer抽象化出來，你的機器實際上是開在那裡的，首先你要付出購買機器這個成本，然後你可能還有接電的成本、電費等。但在雲端，你在你的Layer真正產生例項化之前，你是不需要付這個費用的，只需去編寫這些Code就可以了。還有一點很重要的是，本地的資源有可能不足，萬一發現Layer不夠時，我們還要去採購新的資源，這是個漫長的流程。

圖：OpsWorks工作原理

相信很多Opsworks的團隊，都會有這樣的深切體驗，我們的整個業務可能來不及去支撐發展，而我們的運維也來不及支撐業務的發展，但這個在雲端是能夠進行改善的，Opsworks就是這樣的一個情況，它可以改造這樣不同的Layer，可以通過我們已經積累的Code知識去構造Chef的Layer，所以我們能夠部署整個Setup、Configure、Deploy、undeploy和shutdown各種不同的階段，這是我們Chef的一個介面的截圖，大家有興趣可以去看到。

圖：使用內建Chef Recipe或定製Chef Recipes配置應用

• 第三方工具整合

前面也反覆說過了，我們的團隊現在已有很多DevOps方面的知識了，比如我們可能已在用Github去管理程式碼，可能部署了Jenkins，可能部署了Pipie各種的環境、Chef，這些東西已有現成的經驗，可以不急於丟棄掉，我們雲端的資源完全支援大家把現有的經驗往雲端去整合，而缺乏經驗的部分，也可以拿雲端的一些資源直接使用起來，這是我們的情況。

10、貫穿始終的安全與監控

安全是非常重要的，在雲端，我們只要用好了服務，其安全性很有可能會比在本地更加安全，這裡就好比錢存在自己錢包裡安全還是存在銀行安全一樣。但存在銀行裡是要遵守一定的守則，都會有一些安全的最佳實踐。

11、無伺服器優化

DevOps，剛才我們說到了從程式碼開始的持續整合、持續釋出，到基礎設施即程式碼，這整個部分都是一個過程，最終實現的目的是希望我們的開發人員可以直接去支撐到業務，這個是非常重要的，我們的運維人員可能是隱身的、自動化的，這是最好的情況，那有沒有可能達到這樣的過程呢？我們覺得是有機會的，目前AWS也在做這一方面的嘗試，就是無伺服器的優化。

在無伺服器方面，大家接觸最多的大概說我們不需要去看到伺服器資源，希望能夠自動化的，首先大家都知道Docker，這裡AWS也提供相應的Docker的服務，叫Elastic Container Service的服務，它算是一個Docker的管理器，會同時幫你管理AWS上的雲資源去跟你各種不同的Docker映象的一個編排，最重要的一點就是最右邊的這個Lambda。

它是一個無伺服器架構的函式（就是說它希望達到的一個狀態），實際上它已經實現出來了，現在開發人員只需要去編寫一段程式碼，就是一個事件響應的程式碼，開發人員響應了程式碼以後，我們只需要把事件部署上去，就可以在這個事件觸發時執行這個程式碼，而不需要去管理這個程式碼執行在哪，也不需要管理這個程式碼是否會有成千上萬個併發，這些東西甚至不需要運維了，AWS的基礎設施會自動幫你去擴充套件。

舉個例子，假設我現在有一個服務，Java或者IOS這種開發，它通過Internet去訪問一個API，這個API Gateway是可以通過我們Swagger的方式去描述一個API標準的API，這個API並不需要連線到真正的伺服器，而是連線到Lambda上，剛剛也說了，它就是一段程式碼，就是一個事件相應的結構，你可以用Java編寫，可以去JS的方式去編寫，然後它可以呼叫其它AWS服務，比如資料庫，直接產生一個響應，這個情況下我們在這個流程中根本沒有接觸到任何的伺服器，所以也沒有很詳細的運維可言，這是未來的方向，當然它不能替代所有的產品，因為還是存在一些情況。

API Gateway這裡也稍微說一下。你可以認為它是一個AWS無伺服器化的一部分，作為一個API  Gateway，它在AWS端是運維了這樣的伺服器，但它可以通過你的編寫生成一個近乎無線擴充套件能力的API，這裡麵包括了各種的指標監控，去調動Lambda的動作。

再舉個例子來說，我們很多的手機廠商都會做這樣的相簿服務，會涉及到上傳，我們可以使用Lambda的方式去做一個當S3上傳後自動觸發的一個動作，比如說這個相簿可能做人臉檢測，或者是變大小、變顏色，甚至是各種自動美顏優化，這個東西都可以自動觸發地需做，我們放入開發人員可能只需要寫的這部分的程式碼，實現裡面的邏輯，中間的運維階段可以完全把它遮蔽掉，這就是未來或者說現已實現的無伺服器化的方向。

小結

這就是今天介紹的整體的內容， AWS DevOps服務的總體框架其實包括了從開發、構建、部署，搭建、監控、運維的整個範圍，所以在座的各位，可以很容易地註冊到一個AWS的帳號，開始去試用這樣的服務，在雲端試用的成本是非常低的，包括您和您的團隊，都可以去試用雲端的這種方法。

而今天我介紹的這個服務，未必是馬上可以適應你的團隊，你們可以先把團隊現有的一些經驗往雲端去搬遷，這種情況下雲端最大的優勢就是它的資源是彈性的，彈性會包括兩個方面，第一個就是試錯的成本會變得非常低，比如說現在有一些AI的團隊需要一些很龐大的GPU資源，但購買這樣的GPU資源非常貴，在雲端可能只需要幾塊錢、十幾塊錢的成本，就可以用它一個小時，你可以把你的模型在上面跑，在DevOps的環境也是一樣，我們馬上就可以去測試雲端的東西是否適合我，如果真的不適合，你付出的可能只是幾塊錢的成本，但如果適合，我們馬上就可以把整個團隊的敏捷性大大地提高，這個就是我們開發運維的DevOps的經驗，這裡面涉及到了整個公司文化、組織這方面的理念，AWS在DevOps上面的實踐也非常多，歡迎大家一起探討這方面的問題。我今天的分享就到這裡，謝謝大家！

原文來自微信公眾號：DBAplus社群