DevOps - DevOps精要 - 變革

時間 2019-11-16

標籤 devops 變革简体版

原文原文鏈接

如何以DevOps爲中心對架構進行變革，成功實施DevOps？數據庫

DevOps的核心要素編程

土壤---》組織---》人員的構建與培養
思想---》文化---》意識的造成
方法---》流程---》規則的創建
工具---》操做與配置---》自動化、智能化的演進

1 - 應用程序

1.1 借鑑已有的實踐模式

在DevOps土壤上，將當前業務與DevOps思想、方法和工具結合時，最好參照已有的最佳實踐模式來指導實踐活動。
這將會實現規避掉一部分可能的問題，主要的時間和精力不該該花費在一個又一個問題上。後端

The Twelve-Factor App緩存

https://12factor.net/zh_cn/
軟件一般會做爲一種服務來交付，12-Factor 爲構建以下的 SaaS 應用提供了方法論，適用於任意語言和後端服務（數據庫、消息隊列、緩存等）開發的應用程序。

- 使用標準化流程自動配置，從而使新的開發者花費最少的學習成本加入這個項目。
    - 和操做系統之間儘量的劃清界限，在各個系統中提供最大的可移植性。
    - 適合部署在現代的雲計算平臺，從而在服務器和系統管理方面節省資源。
    - 將開發環境和生產環境的差別降至最低，並使用持續交付實施敏捷開發。
    - 能夠在工具、架構和開發流程不發生明顯變化的前提下實現擴展。

1.2 微服務

微服務架構是一種將單個應用做爲一套小型服務來開發的方法。
微服務的9個特徵：服務組件化、以業務功能爲中心組織團隊、作產品的態度、服務端點、分佈式治理、分佈式數據管理、基礎設施自動化和容錯和演進式設計。
每一個小服務都以業務功能爲單位來構建，採用自動化部署機制進行獨立部署，並以獨立的進程運行，不一樣進程之間使用輕量HTTP資源API等方式進行通訊。
各個進程相互獨立，所以在保持最低限度的集中式管理前提下，每一個服務均可以採起不一樣的編程語言和存儲來實現。
簡而言之，微服務架構以業務功能爲單位把一個大的服務拆分爲多個小的進程，由這些小進程的集合構成一個完整的服務，能夠輕鬆地對各個小進程進行功能的添加、修改和重複使用等操做。
對應的在組織架構上，每一個單獨的進程是由包含不一樣技能人員的一個團隊來實現。服務器

2 - 基礎設施架構

2.1 不可變基礎設施（immutable infrastructure）

顧名思義，其主要含義就是在基礎設施構建完成後就再也不進行任何變動。
若是想對環境進行操做時，須要先銷燬現有的基礎設施，而後再建立新的基礎設施。
也就是說，可以捨棄原有的基礎設施並能夠從零開始從新構建出和原來同樣的基礎設施。架構

其主要優勢負載均衡

防止意外發生：保持乾淨狀態的環境，從根源上避免錯誤的配置和操做
便於管理：不須要對已運行環境的配置和狀態進行管理
強制實現基礎設施即代碼：代碼的最新狀態實時反饋到基礎設施上
統一故障處理和配置變動的工做步驟：都歸結爲自動化的「從新構建」

須要特別關注的地方運維

通常狀況下，不可變基礎設施只適用於無狀態服務器（不包含不斷變化的數據或配置），不適用於相似DB這種有狀態服務器。
特殊需求下須要保留基礎設施，例如進行分析調查故障緣由等
從新構建基礎設施時，與服務器相關的監控等配置也須要進行對應的操做
選擇工具和制定解決方案依據具體的實際的應用場景

2.2 藍綠部署（Blue-Green Deployment）

藍綠部署是爲了解決傳統發佈方式的問題而出現的。編程語言

發佈時須要暫停服務，影響可用性
發佈失敗後須要花費很長時間來修復

原理上，藍綠部署是經過冗餘來解決問題。分佈式

生產環境由藍色環境和綠色環境組成，同一時間只能使用一個
在沒有使用的環境中實施發佈操做和業務測試，測試經過後經過DNS、負載均衡器、反向代理、路由等方式快速完成環境切換。
若是發生故障，也能夠經過負載均衡器、反向代理、路由等方式快速回退到先前版本

藍綠部署的切換速度快，即便發生故障，也能容易回退版本，幾乎不影響用戶的使用。
但也有一些限制，就是須要保持雙重的基礎設施，並且不適用於有狀態服務器。

2.3 本地部署和雲

DevOps的實現並不要求特定類型的環境，而是建議根據具體條件因地制宜。

本地部署

購入或租賃硬件資源，放置在數據中心，並自行負責維護，幾乎全部的工做都在公司內部完成
自主性強，對設備和業務有徹底的把控
須要投入足夠的人力、物力、財力來構建和維護

公有云

由雲服務提供商管理的雲計算IaaS（Infrastructure as a Service，基礎設施即服務）
能夠快速獲取資源、應對高負載
方便管理，當前主流平臺都提供了API 、命令行工具、管理控制檯等工具
必須按照提供商的規定和計劃來構建和使用服務
故障處理只限於公有云平臺的虛擬機層面

私有云

在本地部署環境中使用OpenStack等雲計算平臺實現不可變基礎設施，
前提須要如今本地部署環境中構建一個IaaS的基礎設施，實現有難度、也要花費時間和成本

2.4 軟件即服務（Software as a Service，SaaS）

對於和服務不直接相關的非核心功能，能夠選擇基於互聯網服務來實現，完全削減非核心部分的成本。
例如，在持續集成範圍，就有CircleCI和Travis CI等。
若是SaaS服務提供的功能越重要，就越須要在使用以前進行嚴密的驗證並制定相應的應急計劃（災害、故障的應對計劃）

SaaS的好處

服務器的運維基本由服務商負責
操做和配置直觀簡單
及時提供中間件等相關的支持

SaaS的缺點

沒法對出現故障的SaaS服務進行控制
很難提供個性化定製
價格和服務由服務商設定

2.5 日誌收集

在DevOps中，日誌除了被收集和存儲，還應該積極地用於分析。
在使用不可變基礎設施的狀況下，最爲理想的方式是實時進行日誌收集、處理和輸出展示。
使用ELK技術棧（Elasticsearch、Logstash和Kibana）、能夠快速完成日誌的傳輸、分析和可視化（信息的數值化和圖形化），有助於進行客觀的判斷。
經過持續地日誌分析和可視化，認真地對現狀加以思考和檢討，經過迭代式的改進最終達到長期的目標。

Elasticsearch：具備良好實時性和可擴展性的基於 JSON 的分佈式搜索和分析引擎，做爲 ELK 的核心，集中存儲數據
Logstash：動態數據收集管道，以多種方式收集和處理數據並以多種形式輸出和傳輸，能夠將數據導入到可視化工具中
Kibana：ELK 的用戶界面，彙總、分析和搜索 Logstash 和 ElasticSearch 提供的數據並將其可視化，並提供配置和管理 ELK 的界面

3 - 團隊

3.1 敏捷開發（agile development）與DevOps

敏捷開發是一種經過改善開發方法和團隊結構，持續對最終成果進行改善的方法。
開發成功與否並不在因而否按計劃準時發佈了服務，而在於服務的的開發是否能應對變化，是否產生了商業價值。
在以迅速應對變化爲目標的敏捷開發中，計劃、設計、開發、測試以及發佈等相關工做均由一個小型團隊完成。
經過在短時間內不斷重複這一系列的工做，接受外界對服務和產品的反饋，從而持續進行改善。
全部成員都要對服務和產品負責，須要理解彼此的業務，天然而然地就造成了DevOps所須要的模式。

3.2 Ticket驅動

在軟件開發過程當中使用JIRA、Redmine和Trac等缺陷跟蹤系統或問題跟蹤系統，以ticket爲單位對問題、缺陷以及敏捷開發中的用戶故事等進行管理的方法。
做爲DevOps實踐的一個良好補充，解決了文檔式管理的信息分散問題，能夠支持從瀑布開發到Scrum開發。
在DevOps中，經過ticket爲單位進行信息共享以及任務管理，將會使內外部之間的協調變得簡單，信息也更易於集中管理。

在具體實現上，就是全部任務包括代碼改動都以ticket方式進行管理，與具體事項和相關人員進行關聯，同步更新狀態。
ticket中能夠包含各種日期、負責人、詳細內容和討論記錄等信息。
提供儀表盤功能(Dashboard)，能夠從項目管理、工做量估算和進度管理等角度把握開發總體狀況。