如何設計高可用配置中心

A. 架構高可用高並發系統的設計原則

通過學習《億級流量網站架構核心技術》及《linux就該這么學》學習筆記及自己的感悟：架構設計之高可用高並發系統設計原則，架構設計包括墨菲定律、康威定律和二八定律三大定律，而系統設計包括高並發原則、高可用和業務設計原則等。
架構設計三大定律
墨菲定律 – 任何事沒有表面看起來那麼簡單 – 所有的事都會比預計的時間長 – 可能出錯的事情總會出錯 – 擔心某種事情發生，那麼它就更有可能發生
康威定律 – 系統架構師公司組織架構的反映 – 按照業務閉環進行系統拆分/組織架構劃分，實現閉環、高內聚、低耦合，減少溝通成本 – 如果溝通出現問題，應該考慮進行系統和組織架構的調整 – 適合時機進行系統拆分，不要一開始就吧系統、服務拆分拆的非常細，雖然閉環，但是每個人維護的系統多，維護成本高 – 微服務架構的理論基礎 – 康威定律https://yq.aliyun.com/articles/8611– 每個架構師都應該研究下康威定律http://36kr.com/p/5042735.html
二八定律 – 80%的結果取決於20%的原因
系統設計遵循的原則
1.高並發原則
無狀態
無狀態應用，便於水平擴展
有狀態配置可通過配置中心實現無狀態
實踐: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等
拆分
系統維度：按照系統功能、業務拆分，如購物車，結算，訂單等
功能維度：對系統功能在做細粒度拆分
讀寫維度：根據讀寫比例特徵拆分；讀多，可考慮多級緩存；寫多，可考慮分庫分表
AOP維度： 根據訪問特徵，按照AOP進行拆分，比如商品詳情頁可分為CDN、頁面渲染系統，CDN就是一個AOP系統
模塊維度：對整體代碼結構劃分Web、Service、DAO
服務化
服務化演進: 進程內服務-單機遠程服務-集群手動注冊服務-自動注冊和發現服務-服務的分組、隔離、路由-服務治理
考慮服務分組、隔離、限流、黑白名單、超時、重試機制、路由、故障補償等
實踐：利用Nginx、HaProxy、LVS等實現負載均衡，ZooKeeper、Consul等實現自動注冊和發現服
消息隊列
目的: 服務解耦(一對多消費)、非同步處理、流量削峰緩沖等
大流量緩沖： 犧牲強一致性，保證最終一致性(案例：庫存扣減，現在Redis中做扣減，記錄扣減日誌，通過後台進程將扣減日誌應用到DB)
數據校對: 解決非同步消息機制下消息丟失問題
數據異構
數據異構: 通過消息隊列機制接收數據變更，原子化存儲
數據閉環: 屏蔽多從數據來源，將數據異構存儲，形成閉環
緩存銀彈
用戶層:
DNS緩存
瀏覽器DNS緩存
操作系統DNS緩存
本地DNS服務商緩存
DNS伺服器緩存
客戶端緩存
瀏覽器緩存(Expires、Cache-Control、Last-Modified、Etag)
App客戶緩存(js/css/image…)
代理層：
CDN緩存(一般基於ATS、Varnish、Nginx、Squid等構建,邊緣節點-二級節點-中心節點-源站)
接入層：
Opcache： 緩存PHP的Opcodes
Proxy_cache： 代理緩存,可以存儲到/dev/shm或者SSD
FastCGI Cache
Nginx+Lua+Redis: 業務數據緩存
Nginx為例：
PHP為例：
應用層：
頁面靜態化
業務數據緩存(Redis/Memcached/本地文件等)
消息隊列
數據層：
NoSQL： Redis、Memcache、SSDB等
MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等
系統層：
CPU : L1/L2/L3 Cache/NUMA
內存
磁碟：磁碟本身緩存、dirtyratio/dirtybackground_ratio、陣列卡本身緩存
並發化
2.高可用原則
降級
降級開關集中化管理：將開關配置信息推送到各個應用
可降級的多級讀服務：如服務調用降級為只讀本地緩存
開關前置化：如Nginx+lua(OpenResty)配置降級策略，引流流量；可基於此做灰度策略
業務降級：高並發下，保證核心功能，次要功能可由同步改為非同步策略或屏蔽功能
限流
目的: 防止惡意請求攻擊或超出系統峰值
實踐：
惡意請求流量只訪問到Cache
穿透後端應用的流量使用Nginx的limit處理
惡意IP使用Nginx Deny策略或者iptables拒絕
切流量
目的：屏蔽故障機器
實踐:
DNS: 更改域名解析入口，如DNSPOD可以添加備用IP，正常IP故障時，會自主切換到備用地址;生效實踐較慢
HttpDNS: 為了繞過運營商LocalDNS實現的精準流量調度
LVS/HaProxy/Nginx: 摘除故障節點
可回滾
發布版本失敗時可隨時快速回退到上一個穩定版本
3.業務設計原則
防重設計
冪等設計
流程定義
狀態與狀態機
後台系統操作可反饋
後台系統審批化
文檔注釋
備份
4.總結
先行規劃和設計時有必要的，要對現有問題有方案，對未來有預案;欠下的技術債，遲早都是要還的。
本文作者為網易高級運維工程師

B. 如何在Kubernetes中部署一個高可用的PostgreSQL集群環境

雖然 kubernetes 社區一直在努力使得有狀態應用成為一等公民，也推出了 statefulset 控制器支持 pod 的順序部署，穩定的域名訪問和存儲訪問。但鑒於 MySQL 部署運維的多樣性和復雜性，在 kubernetes 上部署 MySQL 仍然要面臨眾多挑戰。
1、業務流量入口的配置方式
傳統虛擬機環境下，我們通過虛IP的方式，讓業務應用都配置事先定義的一個虛IP為鏈接資料庫的地址，然後由高可用服務保證虛IP始終能被路由到master資料庫。在kubernetes中，出現了一層網路插件屏蔽了底層網路拓撲，高可用服務管理虛IP的方式需要隨之適應調整，比如通過service結合標簽完成虛IP的漂移，但service本身是kubernetes提供的一項功能，其可靠性和性能都取決於kubernetes服務的穩定。以性能來說，service是kubeproxy組件通過配置iptables實現的，當iptables規則較多時不可避免的會產生時延，需要我們針對性的解決。
2、容器隔離帶來的監控視野問題
在 kubernetes 中，如果將 MySQL 製作為 container 運行在一個 pod 中，container 會將 MySQL 進程和運行環境隔離在一個單獨的 namespace 中。監控組件在獲取 MySQL 的一些 metirc 時，可能不得不進入與 MySQL 同一個 namespace 中，在部署和設計監控組件時需要考慮到這些限制。
3、存儲在 kubernetes 中，支持配置各種不同的存儲。
如果使用本地存儲 local persistent volume，則需要綁定 MySQL 在一個固定的節點，這就完全浪費了 kubernetes 靈活調度的天然優勢；而如果使用遠程共享存儲，確實是將 MySQL 進程與其存儲完全解耦，使得 MySQL 進程可以在任意節點調度，然而考慮到高 I/O 吞吐量的情況，就不是那麼美好了。設計時需要考量遠程存儲是否能夠滿足 MySQL 的帶寬要求。
4、高可用/備份恢復
kubernetes 提供的 statefulset 控制器只能提供最基本的部署，刪除功能，無法實現完善的 MySQL 集群高可用/備份恢復操作。對於有狀態應用的部署，仍需要定製開發，所以多數公司提供了定製的 operator 來完成應用容器的管理。比如 etcd operator，MySQL operator，後文將為大家詳述我測試使用 MySQL operator 的一些記錄。

C. 靜脈葯物配置中心如何設計建設

喜格實驗室工程：靜脈葯物配置中心設計建設，如下
1靜脈葯物配置中心的建立
1.1某院PIVAS位於醫院醫技樓六樓，便於葯品運輸和成品配送，便於配製管理和環境控制，水電等基礎條件符合規定。其面積309m2，設計合理，流程順暢。主要功能區域包括排葯、貯葯、充配、信息、核發、更衣、洗潔等;配有6台生物安全櫃和先進的空氣凈化系統。無菌工作間有嚴密的隔離措施及消毒設備，進入工作間，必須經過兩道隔離門，並安裝了空調設備。工程完工後由具有檢測資質的單位對凈化系統進行靜態檢測，沉降菌、微粒、噪音、照度、換氣次數、溫濕度等各項指標達標後，方才投入使用。保證了潔凈室的潔凈度，從而確保臨床用葯安全。
1.2某院PIVAS的管理模式採用以葯為主，由葯劑科負責日常工作管理，護理部負責護理人員的配備，現有葯師5名，護師13名，工友2名，為醫院19個病區進行服務，每天提供約1 500袋靜脈液體。葯學人員主要負責審方、排葯、加葯、核對、葯品管理等;護理人員職責為復核、沖配、幫助排葯;工勤人員需及時運送葯品與打掃衛生等。
1.3信息系統是實現靜脈葯物配製的基礎，分管院長多次召集葯劑科、護理部、醫務處、信息科的相關人員協調工作、統一認識確定電腦程序。電腦信息系統包括處方傳輸、標簽列印、葯費支付、葯品管理、咨詢服務、葯歷生成;標簽內容應包括患者基本信息、葯品處方信息、配製核對信息等，是葯師審核用葯與記錄配製過程的重要憑證。信息管理系統應設置管理許可權，完善數據統計的功能，自動生成批次，實行配置全程化管理。另外還將在系統中嵌入配伍監控系統，對用葯實施合理用葯監控。
2靜脈葯物配置中心工作流程設計
2.1醫生按照《處方管理辦法》有關規定開具靜脈用葯處方，由專人將處方輸入醫院的信息系統中。處方可分為兩類：長期處方與臨時處方。病區負責按規定時間將患者次日需要靜脈輸液的長期處方傳送至PIVAS，臨時處方按照醫院的相關規定和要求傳入PIVAS。
2.2 PIVAS的葯師接收到處方後，逐一核對患者處方信息，審核確認其正確性、合理性與完整性。對於處方存在錯誤的，及時與醫生溝通，請其調整並簽名。對於處方存在錯誤而醫生拒絕不同意修改的，拒絕調配，並報請相關部門協調解決。
2.3經葯師審核通過的處方列印成處方標簽，標簽上需有患者姓名、病區、床號、日期、處方組成、自動生成的編號等內容，且要有各個工序簽名或蓋章的空間，標簽需能貼到輸液瓶(袋)上。
2.4葯師接到審方合格的標簽，應仔細核查標簽內容是否准確、完整，如有錯誤或不全應告知審方葯師校對糾正。葯師根據審核後的標簽上所列葯物的順序，按照其性質、不同的用葯時間，分批次將葯品放置於不同顏色的容器中，並在標簽上簽名或蓋章，按照病區、葯物的不同性質放置於不同的配置間內。
2.5配置間為潔凈間，潔凈級別為萬級，按照配置葯物的種類不同可分為普通葯物與全靜脈營養葯配置間、抗生素與細胞毒性葯物配置間。普通葯物與全靜脈營養葯配置間需配備凈化層流台，使配置環境達到百級，從而保證葯品不被污染。抗生素與細胞毒性葯物配置間主要配置含有抗生素或細胞毒性葯物的處方，本房間配備生物安全櫃，使配置環境的潔凈級別達到百級，且為負壓，從而防止葯品對工作人員的傷害。護士嚴格遵守無菌操作原則及時充配好葯品並在其標簽上簽名或蓋章。
2.6完成沖配的葯物經傳遞窗或傳送帶等方式傳送到成品核對包裝區，進行再次核對與確認，並按照病區分類裝入密閉的容器中，並附成品隨行單，由專人送至各個病區。病區護士接收並核對，無誤後，給患者用葯。盛放葯物的容器需能密封，且定期消毒，避免沖配好的葯物受到二次污染。

D. maxwell如何實現高可用

一旦我們在信息中心的伺服器中實施了虛擬化技術，任何一台物理伺服器的斷電都會導致多個虛擬機停止工作。一個高可用的(HA)集群系統可以幫助我們預防這種情況出現，當主機故障發生後，虛擬機可以在集群系統中迅速重建。舉例來說，假設虛擬化集群中的一個物理節點失效，虛擬機可以迅速遷移到其他節點繼續運行。在這種集群模式下，即使在伺服器宕機的情況下，核心業務系統仍然可以持續地提供服務。
在Xen虛擬機可以被集群系統管理並實現在節點間自由遷移之前，所有節點必須具備訪問虛擬機的配置文件及後端存儲的能力。在本文中，TechTarget中國的特約虛擬化專家Sander van Vugt將講述如何對它們實現共享訪問。
實現對虛擬機配置文件的訪問
實現虛擬機配置文件在所有節點的共享訪問是非常簡單的。首先，把文件存放在SAN系統中的邏輯單元號LUN（logic unitnumber）上；接下來，把LUN中/etc/xen/vm目錄映射給節點中所有相關主機；最後，把配置文件設置為網路共享狀態，使其所在目錄可以被主機動態載入。或者您也可以在配置發生變化後，手動同步文件（而且這種變化並不會經常發生）。然而，為了虛擬機後端存儲的共享訪問，設置方式是完全不同的。

E. Lync伺服器如何做高可用，我們公司大約有8000多用戶，請給點建議。

如果是Lync Server 2013 的話，建議新建一個前端池，在池裡部署3台前端伺服器，使用dns負載均衡和硬體負載均衡混搭的方式實現高可用。

在後端部署3太SQL
伺服器，其中兩台做鏡像，第三台做見證伺服器。

部署2台office
web app servers 來提供PPT共享的功能。
如果要外部訪問Lync，
你需要在DMZ區域部署2台邊緣伺服器實現高可用

F. 如何為高可用集群Hyper-V系統選擇合適的硬體配置

和其他的虛擬機技術環境中不同的是，Hyper-V不能支持內存過分配技術（memory
overcommit
）。因此，當創建的虛擬機所佔用的內存總數大於主機實際的物理內存時，您將無法啟動虛擬機。如果您在分配完可用物理內存之後，嘗試去啟動另外的虛擬機，即
使只是再多分配一台，結果只有一種可能就是返回錯誤提示信息。
如果在一台伺服器環境中，這不會是一個大問題，因為所有的虛擬機啟動過程都是由管理員人工管理的。在帶有自動故障切換技術的集群環境中，這點就會變成一個
很大的障礙。因此，搭建一個擁有足夠的可用物理內存的Hyper-V集群環境就變得非常重要，只有滿足這個條件後主機才可以成功的從發生故障的源節點切換
到集群中的可用目標節點。這也就是說，如果在一個擁有兩個節點的集群中，一半的物理內存必須預留出來；假如擁有四個節點，就意味著需要預留四分之一的物理
內存，以此類推。
簡單錯誤三：缺少支持CSV（Cluster
Shared
Volume，即集群共享卷）技術的備份方式
在Windows
Server
2008
R2中，微軟發布了一項稱為Cluster
Shared
Volume的新技術。它基於現有NTFS格式文件系統基礎上，為Hyper-V虛擬機提供特殊功能支持的技術。您可以把這項技術認為是R2版本的一個屬
性，使得分布在集群中的多個虛擬機可以同時訪問一個共享的LUN。這項新技術解決了集群中的節點失效時，磁碟子系統也作為其一部分而無法工作的情況。允許
必要情況下，虛擬機可以在一個LUN內無縫地遷移。
CSV技術面臨一項潛在的挑戰，那就是：很少有基於虛擬主機的備份產品可以支持。今天，甚至於
微軟的Windows
Server
Backup也無法實現支持。即使這樣，還是有一些像Data
Protection
Manager
2010（仍然只有測試版本）這樣的產品，可以實現對這種工作方式的支持。
簡單錯誤四：對虛擬CPU的過度分配
今天，用戶購買帶有兩個及更多物理CPU的伺服器已經很普遍。擁有更多的CPU意味著多線程應用程序可以在多個CPU之間實現負載均衡。或者當其中一個
CPU被某個單線程應用所佔用時，還可以使用剩餘的CPU來滿足其他應用的需求。這就是為什麼現在幾乎所有的伺服器都有至少兩個甚至有時是四個或更多
CPU的原因。現在的數據中心工作負載需要配備額外的處理器資源以滿足性能以及可用性方面的需求。
在Hyper-V的虛擬化環境中，對虛擬處理器的分配方式是比較特別的。Hyper-V的虛擬機環境中的最佳做法是：在初期只為一台物理機分配一個單獨的虛擬處理器，只有在需要的情況下才去分配額外的處理器資源。
雖然表面看起來增加虛擬處理器數量是一個很好的方式，但實際上這種操作反而會由於調度管理上引起的沖突而降低性能。當多個虛擬處理器被分配給虛擬機後，
這些處理器必須通過調度管理的方式，把它們的使用情況跟實際的物理資源對應起來。假設兩個虛擬處理器分配給一台虛擬機，hypervisor的調度程序
（scheler）必須等待對應的兩個物理處理器都可用後再去分配虛擬處理器。當在多個虛擬機競爭處理資源時，每個請求的響應時間會變得比普通情況長
得多。當物理處理器的個數少於所有虛擬機中分配的虛擬處理器之和時，情況甚至還會變得更糟。（關於這種情況為什麼會產生，您可以參考文章
Microsoft
Developers
Network
site中的Measuring
Processor
Performanc部分。）
還有，請時刻謹記，管理程序（hypervisor）分配的虛擬處理器需要橫跨伺服器上所有可用的物理處理器。這樣，虛擬處理器才可以充分利用所有可用的物理處理器資源。

G. 如何搭建模塊化數據中心

模塊化機房其實就是把機房的所有功能集成到一個模塊化一體化產品中，這個一體化產品可以看成一個機房，把這個產品布置在一個房間內就可以使用了，而房間不用做太多的裝修。

模塊化機房（一體化模塊化產品）含有機櫃、配電櫃、UPS、精密空調、動環監控系統、冷通道、電池櫃等，由這些產品組成一個封閉空間。每個產品可以看成一個模塊，就像搭積木一樣組合起來就成了一個模塊化機房，你可以根據自己的需求增添產品。

傳統機房的規劃設計、運營管理都較為落後，而模塊化機房卻因其高性價比、高可用性的建設模式，獲得眾人熟知並認可，可見「模塊化」理念愈加深入人心。那麼，模塊化機房優點體現在哪？和傳統機房在建設模式上又有那幾點區別呢？

區別之一：模式

傳統機房：常見的UPS&電池房+空調房+IT機房模式。

模塊化機房：批量復制、按需擴展，實行三房歸一，快速部署能力適應發展需求。

模塊化機房

區別之五：管理

傳統機房：專人值守，無完善監控及告警管理。

模塊化機房：本地採集、雲端匯總，實時監控，互動式告警。單模塊監控與集群監控提高運維效率，實現智能管理。

正因以上五點區別，可看出模塊化機房優點：在建設上相較於傳統建設模式更具優勢性。模塊化機房不僅滿足了業務需求，還能減輕企業成本、提高管理效率。

H. 開發自動化運維架構六要素

運維自動化是我們所渴望獲得的，但是我們在一味強調自動化能力時，卻忽略了影響自動化落地的一個關鍵因素。那便是跟運維朝夕相處，讓人又愛又恨的業務架構。
要點一：架構獨立
任何架構的產生都是為了滿足特定的業務訴求，如果我們在滿足業務要求的同時，能夠兼顧運維對架構管理的非功能性要求。那麼我們有理由認為這樣的架構是對運維友好的。
站在運維的角度，所訴求的架構獨立包含四個方面：獨立部署，獨立測試，組件化和技術解耦。
獨立部署
指的是一份源代碼，可以按照便於運維的管理要求去部署、升級、伸縮等，可通過配置來區分地域分布。服務間相互調用通過介面請求實現，部署獨立性也是運維獨立性的前提。
獨立測試
運維能夠通過一些便捷的測試用例或者工具，驗證該業務架構或服務的可用性。具備該能力的業務架構或服務讓運維具備了獨立上線的能力，而不需要每次發布或變更都需要開發或測試人員的參與。
組件規范
指的是在同一個公司內對相關的技術能有很好的框架支持，從而避免不同的開發團隊使用不同的技術棧或者組件，造成公司內部的技術架構失控。
這種做法能夠限制運維對象的無序增加，讓運維對生產環境始終保持著掌控。同時也能夠讓運維保持更多的精力投入，來圍繞著標准組件做更多的效率與質量的建設工作。
技術解耦
指的是降低服務和服務之間相互依賴的關系，也包含了降低代碼對配置文件的依賴。這也是實現微服務的基礎，實現獨立部署、獨立測試、組件化的基礎。
要點二：部署友好
DevOps 中有大量的篇幅講述持續交付的技術實踐，希望從端到端打通開發、測試、運維的所有技術環節，以實現快速部署和交付價值的目標。可見，部署是運維日常工作很重要的組成部分，是屬於計劃內的工作，重復度高，必須提升效率。
實現高效可靠的部署能力，要做好全局規劃，以保證部署以及運營階段的全方位運維掌控。有五個緯度的內容是與部署友好相關的：
CMDB配置
在每次部署操作前，運維需要清晰的掌握該應用與架構、與業務的關系，為了更好的全局理解和評估工作量和潛在風險。
在織雲自動化運維平台中，我們習慣於將業務關系、集群管理、運營狀態、重要級別、架構層等配置信息作為運維的管理對象納管於CMDB配置管理資料庫中。這種管理辦法的好處很明顯，集中存儲運維對象的配置信息，對日後涉及的運維操作、監控和告警等自動化能力建設，將提供大量的配置數據支撐和決策輔助的功效。
環境配置
在運維標准化程度不高的企業中，阻礙部署交付效率的原罪之一便是環境配置，這也是容器化技術主要希望解決的運維痛點之一。
騰訊的運維實踐中，對開發、測試、生產三大主要環境的標准化管理，通過枚舉納管與環境相關的資源集合與運維操作，結合自動初始化工具以實現標准環境管理的落地。
依賴管理
解決應用軟體對庫、運營環境等依賴關系的管理。在織雲實踐經驗中，我們利用包管理，將依賴的庫文件或環境的配置，通過整體打包和前後置執行腳本的方案，解決應用軟體在不同環境部署的難題。業界還有更輕量的容器化交付方法，也是不錯的選擇。
部署方式
持續交付原則提到要打造可靠可重復的交付流水線，對應用軟體的部署操作，我們也強烈按此目標來規劃。業界有很多案例可以參考，如Docker的Build、Ship、Run，如織雲的通過配置描述、標准化流程的一鍵部署等等。
發布自測
發布自測包含兩部分：
應用的輕量級測試；
發布/變更內容的校對。
建設這兩種能力以應對不同的運維場景需求，如在增量發布時，使用發布內容的校對能力，運維人員可快速的獲取變更文件md5，或對相關的進程和埠的配置信息進行檢查比對，確保每次發布變更的可靠。
同理，輕量級測試則是滿足發布時對服務可用性檢測的需求，此步驟可以檢測服務的連通性，也可以跑些主幹的測試用例。
灰度上線
在《日常運維三十六計》中有這么一句話：對不可逆的刪除或修改操作，盡量延遲或慢速執行。這便是灰度的思想，無論是從用戶、時間、伺服器等緯度的灰度上線，都是希望盡量降低上線操作的風險，業務架構支持灰度發布的能力，讓應用部署過程的風險降低，對運維更友好。
要點三：可運維性
運維腦海中最理想的微服務架構，首當其沖的肯定是可運維性強的那類。不具可運維性的應用或架構，對運維團隊帶來的不僅僅是黑鍋，還有對他們職業發展的深深的傷害，因為維護一個沒有可運維性的架構，簡直就是在浪費運維人員的生命。
可運維性按操作規范和管理規范可以被歸納為以下七點：
配置管理
在微服務架構管理中，我們提議將應用的二進制文件與配置分離管理，以便於實現獨立部署的目的。
被分離出來的應用配置，有三種管理辦法：
文件模式；
配置項模式；
分布式配置中心模式。
限於篇幅不就以上三種方式的優劣展開討論。不同的企業可選用最適用的配置管理辦法，關鍵是要求各業務使用一致的方案，運維便可以有針對性的建設工具和系統來做好配置管理。
版本管理
DevOps持續交付八大原則之一「把所有的東西都納入版本控制」。就運維對象而言，想要管理好它，就必須能夠清晰的描述它。
和源代碼管理的要求類似，運維也需要對日常操作的對象，如包、配置、腳本等都進行腳本化管理，以備在運維系統在完成自動化操作時，能夠准確無誤的選定被操作的對象和版本。
標准操作
運維日常有大量重復度高的工作需要被執行，從精益思想的視角看，這里存在極大的浪費：學習成本、無價值操作、重復建設的腳本/工具、人肉執行的風險等等。
倘若能在企業內形成統一的運維操作規范，如文件傳輸、遠程執行、應用啟動停止等等操作都被規范化、集中化、一鍵化的操作，運維的效率和質量將得以極大的提升。
進程管理
包括應用安裝路徑、目錄結構、規范進程名、規范埠號、啟停方式、監控方案等等，被收納在進程管理的范疇。做好進程管理的全局規劃，能夠極大的提升自動化運維程度，減少計劃外任務的發生。
空間管理
做好磁碟空間使用的管理，是為了保證業務數據的有序存放，也是降低計劃外任務發生的有效手段。
要求提前做好的規劃：備份策略、存儲方案、容量預警、清理策略等，輔以行之有效的工具，讓這些任務不再困擾運維。
日誌管理
日誌規范的推行和貫徹需要研發密切配合，在實踐中得出的經驗，運維理想中的日誌規范要包含這些要求：
業務數據與日誌分離
日誌與業務邏輯解耦
日誌格式統一
返回碼及注釋清晰
可獲取業務指標（請求量/成功率/延時）
定義關鍵事件
輸出級別
管理方案（存放時長、壓縮備份等）
當具體上述條件的日誌規范得以落地，開發、運維和業務都能相應的獲得較好的監控分析能力。
集中管控
運維的工作先天就容易被切割成不同的部分，發布變更、監控分析、故障處理、項目支持、多雲管理等等，我們訴求一站式的運維管理平台，使得所有的工作信息能夠銜接起來和傳承經驗，杜絕因為信息孤島或人工傳遞信息而造成的運營風險，提升整體運維管控的效率和質量。
要點四：容錯容災
在騰訊技術運營（運維）的四大職責：質量、效率、成本、安全。質量是首要保障的陣地，轉換成架構的視角，運維眼中理想的高可用架構架構設計應該包含以下幾點：
負載均衡
無論是軟體或硬體的負責均衡的方案，從運維的角度出發，我們總希望業務架構是無狀態的，路由定址是智能化的，集群容錯是自動實現的。
在騰訊多年的路由軟體實踐中，軟體的負載均衡方案被廣泛應用，為業務架構實現高可用立下汗馬功勞。
可調度性
在移動互聯網盛行的年代，可調度性是容災容錯的一項極其重要的運維手段。在業務遭遇無法立刻解決的故障時，將用戶或服務調離異常區域，是海量運營實踐中屢試不爽的技巧，也是騰訊QQ和微信保障平台業務質量的核心運維能力之一。
結合域名、VIP、接入網關等技術，讓架構支持調度的能力，豐富運維管理手段，有能力更從容的應對各種故障場景。
異地多活
異地多活是數據高可用的訴求，是可調度性的前提。針對不同的業務場景，技術實現的手段不限。
騰訊社交的實踐可以參考周小軍老師的文章「2億QQ用戶大調度背後的架構設計和高效運營」。
主從切換
在資料庫的高可用方案中，主從切換是最常見的容災容錯方案。通過在業務邏輯中實現讀寫分離，再結合智能路由選擇實現無人職守的主從切換自動化，無疑是架構設計對DBA最好的饋贈。
柔性可用
「先扛住再優化」是騰訊海量運營思想之一，也為我們在做業務架構的高可用設計點明了方向。
如何在業務量突增的情況下，最大程度的保障業務可用？是做架構規劃和設計時不可迴避的問題。巧妙的設置柔性開關，或者在架構中內置自動拒絕超額請求的邏輯，能夠在關鍵時刻保證後端服務不雪崩，確保業務架構的高可用。
要點五：質量監控
保障和提高業務質量是運維努力追逐的目標，而監控能力是我們實現目標的重要技術手段。運維希望架構為質量監控提供便利和數據支持，要求實現以下幾點：
指標度量
每個架構都必須能被指標度量，同時，我們希望的是最好只有唯一的指標度量。對於業務日趨完善的立體化監控，監控指標的數量隨之會成倍增長。因此，架構的指標度量，我們希望的是最好只有唯一的指標度量。
基礎監控
指的是網路、專線、主機、系統等低層次的指標能力，這類監控點大多屬於非侵入式，很容易實現數據的採集。
在自動化運維能力健全的企業，基礎監控產生的告警數據絕大部分會被收斂掉。同時，這部分監控數據將為高層次的業務監控提供數據支撐和決策依據，或者被包裝成更貼近上層應用場景的業務監控數據使用，如容量、多維指標等。
組件監控
騰訊習慣把開發框架、路由服務、中間件等都統稱為組件，這類監控介於基礎監控和業務監控之間，運維常寄希望於在組件中內嵌監控邏輯，通過組件的推廣，讓組件監控的覆蓋度提高，獲取數據的成本屬中等。如利用路由組件的監控，運維可以獲得每個路由服務的請求量、延時等狀態和質量指標。
業務監控
業務監控的實現方法分主動和被動的監控，即可侵入式實現，又能以旁路的方式達到目的。這類監控方案要求開發的配合，與編碼和架構相關。
通常業務監控的指標都能歸納為請求量、成功率、延時3種指標。實現手段很多，有日誌監控、流數據監控、波測等等，業務監控屬於高層次的監控，往往能直接反饋業務問題，但倘若要深入分析出問題的根源，就必須結合必要的運維監控管理規范，如返回碼定義、日誌協議等。需要業務架構在設計時，前置考慮運維監控管理的訴求，全局規劃好的范疇。
全鏈路監控
基礎、組件、業務的監控手段更多的是聚焦於點的監控，在分布式架構的業務場景中，要做好監控，我們必須要考慮到服務請求鏈路的監控。
基於唯一的交易ID或RPC的調用關系，通過技術手段還原調用關系鏈，再通過模型或事件觸發監控告警，來反饋服務鏈路的狀態和質量。該監控手段屬於監控的高階應用，同樣需要業務架構規劃時做好前置規劃和代碼埋點。。
質量考核
任何監控能力的推進，質量的優化，都需要有管理的閉環，考核是一個不錯的手段，從監控覆蓋率、指標全面性、事件管理機制到報表考核打分，運維和開發可以攜手打造一個持續反饋的質量管理閉環，讓業務架構能夠不斷進化提升。
要點六：性能成本
在騰訊，所有的技術運營人員都肩負著一個重要的職能，就是要確保業務運營成本的合理。為此，我們必須對應用吞吐性能、業務容量規劃和運營成本都要有相應的管理辦法。
吞吐性能
DevOps持續交付方法論中，在測試階段進行的非功能需求測試，其中很重要一點便是對架構吞吐性能的壓測，並以此確保應用上線後業務容量的健康。
在騰訊的實踐中，不僅限於測試階段會做性能壓測，我們會結合路由組件的功能，對業務模塊、業務SET進行真實請求的壓測，以此建立業務容量模型的基準。也從側面提供數據論證該業務架構的吞吐性能是否達到成本考核的要求，利用不同業務間性能數據的對比，來推動架構性能的不斷提高。
容量規劃
英文capacity一詞可以翻譯成：應用性能、服務容量、業務總請求量，運維的容量規劃是指在應用性能達標的前提下，基於業務總請求量的合理的服務容量規劃。
運營成本
減少運營成本，是為公司減少現金流的投入，對企業的價值絲毫不弱於質量與效率的提升。
騰訊以社交、UGC、雲計算、游戲、視頻等富媒體業務為主，每年消耗在帶寬、設備等運營成本的金額十分巨大。運維想要優化運營成本，常常會涉及到產品功能和業務架構的優化。因此，運維理想的業務架構設計需要有足夠的成本意識，
小結
本文純屬個人以運維視角整理的對微服務架構設計的一些愚見，要實現運維價值最大化，要確保業務質量、效率、成本的全面提高，業務架構這塊硬骨頭是不得不啃的。
運維人需要有架構意識，能站在不同角度對業務架構提出建議或需求，這也是DevOps 精神所提倡的，開發和運維聯手，持續優化出最好的業務架構。