中小企業DevOps從0到1中小企業DevOps從0到11目錄DevOps雜談1運維知識體系與職業發展2中小企業基于開源的Web架構演變3全鏈路自動化運維體系4QA5目錄DevOps雜談1運維知識體系與職業發展2中小企業基于開2什么是DevOps？什么是DevOps？3DevOps構建的IT服務供應鏈DevOps構建的IT服務供應鏈4DevOps的CALMS文化Culture（文化）

Automation（自動化）Lean（精益）

Measurement（度量）

Sharing（分享）DevOps的CALMS文化5打擊也是一種鼓勵：鼓勵員工“跳槽”你埋怨工資低？為什么不跳槽？打擊也是一種鼓勵：鼓勵員工“跳槽”你埋怨工資低？6中小企業DevOps從0到課件7運維“能力不行”論能力不行之-隊友是個傻X能力不行之-領導是個傻X能力不行之-提問總覺得別人裝X能力不行之-外來的和尚好念經運維“能力不行”論能力不行之-隊友是個傻X8先從自身找原因，能讓你快速的強大起來！先從自身找原因，能讓你快速的強大起來！9目錄DevOs雜談1運維知識體系與職業發展2中小企業基于開源的Web架構演變3全鏈路自動化運維體系4QA5目錄DevOs雜談1運維知識體系與職業發展2中小企業基于開源10不要小看運維之-《運維知識體系》不要小看運維之-《運維知識體系》11不要小看運維之-《運維知識體系》不要小看運維之-《運維知識體系》12不要小看運維之-《運維知識體系》不要小看運維之-《運維知識體系》13不要小看運維之-《運維知識體系》不要小看運維之-《運維知識體系》14不要小看運維之-《運維知識體系》不要小看運維之-《運維知識體系》15運維工作內容運維服務臺：7x24小時運維值班，告警處理。服務部署、項目上線、線上業務的部署更新，版本管理、灰度發布等。負責管理所有數據系統：數據庫、分布式緩存等存儲系統管理。負責整體的安全規范、漏洞檢測、安全防護等。運維平臺建設：環境規劃、運維研發、架構設計、配置管理等。基礎設施建設：網絡、IDC托管、私有云、基礎服務等。值班運維應用運維DBA安全運維系統運維基礎運維運維工作內容運維服務臺：7x24小時運維值班，告警處理。服務16運維技術層次發展把服務運行起來工程師搭建服務讓服務飛起來高級工程師用好服務讓服務戀愛架構師服務關聯讓服務生孩子創業者服務產品化運維技術層次發展把服務運行起來搭建服務讓服務飛起來用好服17運維職業發展多選題：本題70分請在下面列表中，選擇一個或多個職位作為職業規劃目標（）。A.系統架構師B.運維經理、總監C.某一技術領域專家D.云解決方案架構師E.業務運維專家F.培訓講師G.DevOps專家2.簡單題：本題30分如何達到上題中選擇的職位目標？運維職業發展多選題：本題70分D.云解決方案架構師2.簡單題18目錄DevOps雜談1運維知識體系與職業發展2中小企業基于開源的Web架構演變3全鏈路自動化運維體系4QA5目錄DevOps雜談1運維知識體系與職業發展2中小企業基于開19中小企業基于開源的Web架構演變3中小企業基于開源的Web架構演變320中小企業基于開源的Web架構演變3中小企業基于開源的Web架構演變321單機時代單機時代22單機時代-數據庫分離單機時代-數據庫分離23單機時代-組件分離單機時代-組件分離24單機時代-Web性能優化網絡磁盤內存CPUCPU進程數CPU綁定內存JVM設置GC優化大頁內存內存合并ksmd磁盤IOOpenfileSendfileIO調度算法網絡EpoolSocket優化（time_wait）持久連接單機時代-Web性能優化網絡磁盤內存CPUCPU進程數內存J25中小企業基于開源的Web架構演變3中小企業基于開源的Web架構演變326Web集群-HTTP重定向Web集群-HTTP重定向27Web集群-DNS輪詢Web集群-DNS輪詢28Web集群-反向代理負載均衡Web集群-反向代理負載均衡29Web集群-負載均衡+高可用Web集群-負載均衡+高可用30Web集群中Session處理方案SESSION保持Nginx：ip_hashHaproxy：sourceipSESSION復制Tomcat

ClusterSESSION共享PHP：Memcached、RedisDjango：Session框架支持Tomcat：tomcat-x-session-managerWeb集群中Session處理方案SESSION保持Ngin31Web集群-Session共享Web集群-Session共享32Web集群-四層+七層負載均衡Web集群-四層+七層負載均衡33Web集群-SOA單一應用架構當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。此時，用于簡化增刪改查工作量的

數據訪問框架(ORM)

是關鍵。垂直應用架構當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。此時，用于加速前端頁面開發的

Web框架(MVC)是關鍵。分布式服務架構當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用于提高業務復用及整合的

分布式服務框架(RPC)

是關鍵。流動計算架構當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基于訪問壓力實時管理集群容量，提高集群利用率。此時，用于提高機器利用率的

資源調度和治理中心(SOA)是關鍵。來源于：http://dubbo.io/Web集群-SOA單一應用架構來源于：http://dubb34Web集群-SOA和微服務架構來源于：http://dubbo.io/Web集群-SOA和微服務架構來源于：http://dubb35中小企業基于開源的Web架構演變3中小企業基于開源的Web架構演變336文件存儲-Local、DAS、SAN1.本地硬盤2.DAS存儲0.tmpFS3.SAN存儲文件存儲-Local、DAS、SAN1.本地硬盤2.DAS存37文件存儲-共享、分發、同步4.NAS存儲5.文件分發、同步文件存儲-共享、分發、同步4.NAS存儲5.文件分發、同步38文件存儲-分布式文件系統FASTDFS文件存儲-分布式文件系統FASTDFS39中小企業基于開源的Web架構演變3中小企業基于開源的Web架構演變340緩存知識體系緩存知識體系41緩存知識體系緩存知識體系42中小企業基于開源的Web架構演變3中小企業基于開源的Web架構演變343數據存儲-MySQL基于復制的架構3.一主多從，讀寫分離1.一主一從，高可用2.一主一從，讀寫分離數據存儲-MySQL基于復制的架構3.一主多從，讀寫分離2.44數據存儲-MySQL基于復制的架構4.一主多從、負載均衡5.主主復制、雙寫6.主主復制，單寫數據存儲-MySQL基于復制的架構4.一主多從、負載均衡5.45數據存儲-MySQL基于復制的架構7.雙主雙從8.MySQL高可用方案：MHA數據存儲-MySQL基于復制的架構7.雙主雙從8.MySQL46MySQL

ProxyAtlas數據存儲-MySQL

ProxyMySQLProxyAtlas數據存儲-MySQLPro47數據存儲-MySQL

PXCPercona

Xtradb

Cluster數據存儲-MySQLPXCPerconaXtradbC481.Cobar數據存儲-MySQL

DAL2.MyCAT3.客戶端分片（根據UID分庫分表）1.Cobar數據存儲-MySQLDAL3.客戶端分片（根49數據存儲-基于MySQL協議的分布式數據庫TiDBTiDB

是

PingCAP

公司基于

Google

Spanner

/

F1

論文實現的開源分布式

NewSQL

數據庫。數據存儲-基于MySQL協議的分布式數據庫TiDBTiDB50中小企業基于開源的Web架構演變3中小企業基于開源的Web架構演變351中小企業DevOps從0到課件52災備的六個等級災備的六個等級53災備的七個要素序號要素要素的考慮要點1備用基礎設施災備數據中心選址2數據備份系統數據備份范圍；備份技術；3備用數據處理系統數據處理能力；平時的狀態（處于就緒還是運行）；4備用網絡系統備用網絡通信線路通信線路的使用狀態5災難恢復預案完整的災難恢復預案定期的災難恢復演練6運行維護管理能力運維組織架構、人員數量和技術管理制度等7技術支持能力軟件、硬件和網絡等方面的技術支持災備的七個要素序號要素要素的考慮要點1備用基礎設施災備數據中54災備的兩個主要目標RTO：(Recovery

Time

Objective)恢復時間目標:災難發生后，信息系統或業務功能從停頓到必須恢復的時間要求。RPO：

(Recovery

Point

Objective)恢復點目標:災難發生后，系統和數據必須恢復到的時間點要求。災備的兩個主要目標RTO：(RecoveryTimeOb55災備分業務、分層、分階段建設先有，后完善。災備機房非對稱配置。徘徊在“冷備”和“雙活”之間。按業務重要性，先實現重要業務，再實現邊緣業務。按架構分層從下往上實現。不同業務實現不同的災備等級。災備建設1.0版本災備分業務、分層、分階段建設先有，后完善。災備建設1.0版本56目錄DevOps雜談1運維知識體系與職業發展2中小企業基于開源的Web架構演變3全鏈路自動化運維體系4QA5目錄DevOps雜談1運維知識體系與職業發展2中小企業基于開57自動化運維發展歷程自動化運維發展歷程58自動化運維建設要從“痛點”出發痛點案例：原因：03:00-06:00數據庫主庫升級打補丁任務：1.查找所有業務系統中03:00-06:00的所有定時任務，確定哪些定時任務連接需要停機數據庫。查找到的定時任務，都屬于哪個項目、負責人是誰、定時任務誰提交的？是否可以暫停？和相關人員進行協調不能暫停的定時任務，是否可以操作從庫？如果停機維護完畢后，這些定時任務是否需要重新運行？自動化運維建設要從“痛點”出發