Rapiz (姜學連)
0、 聲明
本人是個鹹魚，剛剛走上這條頭髮的不歸路髮量與實力成反比的不歸路，所以個人看法可能有一定的偏激和誤解，還希望各位大佬糾正，目前唯一的自信可能就是髮量了。
1、 什麼是雲效
這個問題在我體驗阿里雲的雲效項目之前我也是很迷，所以讓我們來看一下官方的說法吧：作為一站式企業協同研發雲，雲效提供從“需求->開發->測試->發佈->運維->運營”端到端的協同服務和研發工具支撐。同時雲效與其它常用的雲產品緊密集成，提供以應用為核心的一站式研發體驗。
附上一張大圖：
雲效,給我這個小白的理解可能就是將雲端應用的集中化，提供了一系列的相關功能，將之前的獨立功能整合到一起，解決用戶的各種雲端需求。
2、為什麼需要雲效來集成各個雲產品？
重複的概念
目前阿里雲提供了大量的優秀的雲產品，比如ECS，SLB，雲監控，日誌服務，幫助用戶進行線上服務的部署，運維，監控，告警。
但實際用起來之後，你會發現一個很明顯的問題。那就是有些概念，比如機器分組，會在多個產品中重複實現。假設我現在有一個線上的Web應用，包含了5臺機器。那麼我需要在日誌服務中將這5臺機器配置到一個分組，然後再在雲監控中把同樣的5臺機器分到雲監控的分組，再把這5臺機器掛在某個SLB下。不過這個事情其實也容易理解，因為缺乏了一個基礎的公共概念，那就是應用。
而云效作為一個研發協同平臺，天生就是以應用為核心的。應用下面有不同的環境，每個環境對應一個機器組，使用這個機器組的概念，就可以將各個雲產品的機器組的概念統一起來。通過Open API的方式，雲效可以在創建應用的同時，就把上述的這些相關服務配置好。同時應用也會成為一個訪問其他各個雲產品的快捷入口。
不一致的配置
讓我們再進入到單獨的一個雲產品來看看。比如日誌服務。日誌服務需要配置日誌收集的路徑。一般來講用戶會對每個應用單獨的、重複的進行配置。有些應用的配置可能是相同的，有些可能是不同的。設想一下，如果所有應用的日誌路徑配置都是相同的，或者說起碼是有規律的（比如阿里巴巴內部的大多數應用的日誌都會放在/home/admin/<應用名>/logs這個目錄下），那麼雲效就可以在您創建應用時候，就自動將收集路徑配置好。那麼如何才能做到應用的日誌路徑是一致的呢，雲效的方案很簡單，那就是使用代碼模板。通過雲效的一站式解決方案嚮導創建的出來的代碼庫中就包含了標準的日誌配置（比如logback.xml）。
機器上除了應用的日誌之外，您可能還需要關心Web Server（Nginx/Apache）及應用容器（Tomcat）的日誌。這些日誌的位置就不是代碼模板可以解決的了。雲效提供的解決方案是ECS模板。您可以自定義ECS模板，也可以使用雲效默認提供的模板。有了模板，那麼Web Server和應用容器的日誌的位置也就確定下來了，雲效也可以自動的幫您創建出來。
來源於阿里內部的解決方案
上面提到的這些問題，僅僅是一部分。而上面提到的解決方案也恰恰是阿里內部的思路。雲效的阿里內部版本服務了整個集團幾萬人的的研發人員。把應用的整個生命週期與各個相關的服務（日誌，監控，VIP等）有機的串接起來，最大限度的減少重複性的工作。一個阿里的同學創建一個新的應用，基本上都感覺不到這些服務的存在，只有當機器真的出現問題時候，你才會收到告警。這種體驗，說真的，真是棒極了。
我們也非常期待使用這套理念來服務更多的雲上用戶。
3、 基於雲產品進行更多的場景化
上面主要是講解如何以應用為核心來串接各個雲產品。在此基礎上我們就能做更多的場景化的事情，比如藍綠髮布和動態伸縮。下面用藍綠髮布這個場景舉個例子。
藍綠髮布
藍綠髮布是業界常用的實踐。基於阿里雲的SLB我們也可以手動的實現藍綠髮布，無非也就是：
- 創建並部署新的機器
- 將SLB的流量手動切換到新部署的機器
- 如果出現問題，則手動再切換回到舊的那一批機器
- 如果沒問題，則銷燬舊的那一批機器
當然每次手動做這件事情，也是非常痛苦的。所以雲效能做的事情，就是在SLB等基礎設施的基礎上編排場景。幫助您屏蔽這些細節。
4、 阿里云云效在遠程協同研發方便有哪些優勢？
這次疫情云為響應國家號召，眾多企業選擇在家遠程辦公。然而研發團隊彼此不見面， “如何快速瞭解每位成員的開發進度”“如何確保研發任務高效推進”等問題困擾著軟件研發團隊的Leader。雲端產品的最大用處可能就是在遠程的協同辦公上，對於互聯網公司那就無異於是遠程協調研發上面。所以，讓我們來看一下阿里云云效在這個方面究竟是有什麼優勢。
比較提倡工作方式：分支模式具備了持續交付的特質
比如：
- 分支中引入持續集成和項目環境，隨著分支代碼的提交，可以自動的進行單元測試、基於項目環境的集成測試等。
- 構建和部署自動化，分支一旦提交到集成，後續的代碼合併、構建、部署、集成測試會自動完成。 同時分支模式有一些明顯的優點或者是便利，愛不釋手：
- 在開發階段不同的開發同學互不干擾，集成階段可以快速的集成和退出相關的分支。在某種程度上保證集成環境可以快速恢復。
- 可以選擇階段部署，只要有權限，代碼可以直接到正式環境發佈。而不需要經過日常、預發、灰度、beta等環節
還是比較適合研發遠程辦公的，對於研發人員 DevOps這塊可以嘗試下
每個個體都在服務於“兩種團隊”- “項目團隊”和“職能團隊”。
項目團隊主要關注的是項目的整體進度是否順利，是否存在風險影響項目目標達成。
職能團隊主要關注的是團隊的資源分配，團隊通常支持多個項目，如何最大化利用團隊的資源。
下面將分別從這兩種團隊的維度闡述如何提高遠程辦公效率。
1、晨會上團隊基於精益看板進行需求、任務對齊，完成任務指派；
2、開發同學根據特性開發，創建變更分支；
3、通過線下或雲端開發環境進行編程工作，然後提交代碼；
4、代碼自動觸發自動的代碼掃描，併發送給指定的代碼評審員進行評審；
5、完成評審的代碼自動觸發集成發佈流水線，自動化的完成構建，生成Docker鏡像，分別在開發環境、集成環境及預發環境進行部署，完成相應的驗證工作；驗證完之後處於待發布狀態，觸發上線審核流程，運維完成審核發佈上線；
6、遵循Nonewsisgoodnews的原則，過程中任何問題，通過釘釘及時反饋到指定負責人，做到準確反饋、即時響應，快速恢復。儘量避免垃圾短信式反饋，過多的噪音，反而會降低協作的效率。
DevOps集文化理念、實踐和工具於一身。
可以提高組織交付應用程序和服務的能力。與使用傳統軟件和基礎設施管理流程相比，能夠幫助組織更快的發展和改進產品。
這種速度使組織更好的服務其客戶，並在市場上高效的參與競爭。
DevOps產生之處就是在解決這個問題。所謂的持續集成、持續交付這些都是之前提出來的，但也是DevOps的一種實踐經驗。
【雲效官網】https://www.aliyun.com/product/yunxiao?channel=zhibo
【雲效開發者俱樂部】釘群：34532418
