劃重點：趙成老師的運維體系管理課精華
我們專欄的四大模塊分別是：
應用運維體系建設
-
爲什麼Netflix沒有運維崗位？
合理的組織架構是保障技術架構落地的必要條件，用技術手段來解決運維過程中遇到的效率和穩定問題纔是根本解決方案。 -
微服務架構時代，運維體系建設爲什麼要以"應用"爲核心？
微服務的架構模式下，我們的運維視角一定要轉到應用這個核心概念上來，一切要從應用的角度來分析和看待問題。 -
標準化體系建設（上）：如何建立應用標準化體系和模型？
標準先行，標準先行，標準先行，於紛繁複雜中抽象出標準規範的東西，是我們後續一系列自動化和穩定性保障的基礎。 -
標準化體系建設（下）：如何建立基礎架構標準化化及服務化體系？
我們要做的事情，可以歸納爲兩步：第一步是基礎架構標準化，第二步是基礎架構服務化。 -
如何從生命週期的視角看待應用運維體系建設？
從生命週期入手，劃分階段，提煉屬性，理清關係，固話基礎信息，實現運維場景。 -
聊聊CMDB的前世今生
新的時期，對於CMDB的理解也要與時俱進，這個時候，思路上的轉變，遠比技術上的實現更重要。 -
有了CMDB，爲什麼還需要應用配置管理？
CMDB是面向資源的管理，是運維的基石，應用配置管理是面向應用的管理，是運維的核心。 -
如何在CMDB中落地應用的概念？
運維能力的體現，一定是整體技術架構能力的體現，割裂兩者單獨去看，都是沒有意義的。 -
如何打造運維組織架構？
運維在這個過程中，就好像串起來一串珍珠的繩子，將整個平臺技術的不同部門，甚至開發團隊給串聯起來，朝着發揮出整體技術架構運維能力的方向演進。 -
谷歌SRE運維模式解讀
SRE是一個崗位，但更是一種運維理念和方法論 -
從谷歌CRE談起，運維如何培養服務意識？
是不是有服務心態，表現在我們的做事方式上，就是我們是否能夠站在對方的角度問題、解決問題。
效率和穩定性最佳實踐
-
持續交付知易行難，想做成這事你要理解幾個關鍵點
配置管理、提交管理、構建和部署發佈是持續交付的重中之重，是關鍵路徑，是從開發代碼開始，到發佈上線的必經之路。 -
持續交付的第一關鍵點：配置管理
勿在浮沙築高臺，我們做工具平臺或系統，一定要重視基礎的建設。 -
如何做好持續糾紛中的多環境配置管理？
環境配置管理主要是針對應用對基礎設施和基礎服務依賴關係的配置管理。 -
開發和測試爭搶環境？是時候進行多環境建設了
我們在線下環境區域內，一般會建設三套環境：集成測試環境，開發測試環境和項目環境。 -
線上環境建設，要扛得住真刀真槍的考驗
預發環境就像是球類運動員，他們平時可以在訓練場進行訓練，但是正式比賽前，一定是要到正式比賽場地提前適應場地或者熱身。 -
人多力量大vs兩個披薩原則，聊聊持續交付中的流水線模式
開發模式的選型原則：一看這幾種模式的適用場景，二看我們實際的使用場景是怎麼樣的。 -
持續交付流水線軟件構建難嗎？有哪些關鍵問題？
容器的高效實用，一定是建立在更加完善和高度標準化的體系之上，否則工具只會越用越亂。 -
持續交付中流水線構建完成後就大公告成了嗎？別忘了質量保障
需要明確的是，在持續交付過程中，我們還要做很多與質量保障相關的工作，比如各類功能測試和非功能測試。 -
做持續交付概念重要還是場景重要？看"笨辦法"如何找到最佳方案
我們所採取的手段，其實都是笨辦法：即找到問題，分析問題，調研解決方案，討論碰撞，然後慢慢探索和實踐，找出最合適我們的方案。 -
極端場景下，我們應該如何做好穩定性保障？
對於穩定性而言，用戶訪問模型纔是關鍵，這個摸不準，只有技術是沒有用的，這就更需要我們才能深入業務，理解業務。 -
穩定性實踐：容量規劃之業務場景分析
容量規劃，就是對複雜業務場景分析，通過一定的技術手段，來達到對資源合理擴容、有效規劃的過程。 -
穩定性實踐：容量規劃之實踐壓測系統建設
壓力測試四維度：壓測粒度、壓測接口及流量構造方式、試壓方式、數據讀寫。 -
穩定性實踐：限流降級
限流降級的難點和關鍵還是在於整體技術棧的統一，以及後期對每個應用限流降級資源策略的準確把握和配置。 -
穩定性實踐：開關和預案
開關，主要是針對單個功能的啓用和停止進行控制，或者將功能狀態在不同版本之間進行切換。預案，可以理解爲讓應用或業務進入到某種特定狀態的複雜方案執行。 -
穩定性實踐：全鏈路跟蹤系統，技術運營能力的體現
我們做全鏈路跟蹤系統，要解決首要問題就是在紛繁複雜的服務調用關係中快速準確定位問題。 -
談談我對故障的理解
系統正常，只是該系統無數異常情況下的一種特例。故障永遠只是表面現象，其背後技術和管理上的問題纔是根因。 -
故障管理：故障定級和定責
我們將故障等級設置爲P0-P4這麼5個級別，P0爲最高，P4爲最低 -
故障管理：鼓勵做事，而不是處罰錯誤
這樣的規則建議通過設定高壓線的方式讓團隊牢記心中，就像酒後不開車一樣，簡單明確。 -
故障管理：故障應急和故障覆盤
凡是沒有演練過的預案，都是耍流氓。功夫要下在平時，注意建設各種工具和平臺，同時要儘可能的考慮和模擬各種故障場景。 -
脣芒齒寒，運維與安全
在雙方（運維與安全）工作的協作上，我一直認爲運維不能只是被動響應，而應該主動與安全合作，共建安全體系，與運維體系融合，把防線建設好，從源頭控制。
雲計算時代的運維實踐
-
爲什麼蘑菇街會選擇上雲？是被動選擇還是主動出擊？
如果想要技術爲業務帶來更多的可能性，擁抱雲計算是最好的選擇。 -
爲什麼混合雲是未來雲計算的主流形態？
不管如何選擇和使用，我們一定還是要以滿足業務場景爲出發點，脫離了這一點，單純追求技術深度和複雜度是沒有意義的。 -
Spring Cloud：面向應用層的雲架構解決方案
Spring Cloud 不僅僅是微服務治理解決方案，他同時還是面向應用層的雲架構解決方案。 -
以絕對優勢立足，從CDN和雲存儲來聊聊雲生態的崛起
利用雲計算的優勢，擁抱變化，才能爲我們業務發展和創新帶來更多的可能性。 -
量體裁衣放得最優解：聊聊頁面靜態化架構和二級CDN建設
公有云也好，雲計算也好，都不能爲我們提供完美的定製解決方案。正所謂具體問題具體分析，找出問題，優化解決路徑，量體裁衣，才能得到最適合我們的“定製方案” -
雲計算時代，我們所說的彈性伸縮，彈的到底是什麼？
對於運維，一定要準確識別出日常運維過程中不同的運維對象，然後再進一步去分析這個對象所對應的運維場景是什麼？進而纔是針對運維場景的分解和開發。
個人成長
-
我是如何走上運維崗位的？
這樣的一個發展過程並不是我刻意設計過多的，機會也不是刻意爭取到的，就是平時多做一點，做的認真一點，確保最終能拿到結構，而且稍微努力一下，儘量拿到比預期好的一些結果。 -
雲計算和AI時代，運維應該如何做好轉型？
不斷的學習和提升自己的技能，保持對於技術發展趨勢的敏銳性，及時作出調整和應對，纔是根本的解決之道。 -
運維需要懂產品和運營嗎？
我們強調的是運維要有產品和運營意識，總結起來最本質的兩點，第一，就是能將需求講清楚，第二，能將產品進行推廣落地。 -
冷靜下來想想，員工離職這事真能防住嗎？
技術管理者，一定要重點關注人，而不僅僅是事情，這點是做技術骨幹和技術管理者之間的最大區別，也是思路轉變的第一步。 -
樹立個人品牌意識：從背景調查談談職業口碑的重要性
背景調查的過程不可控，但是我們自身的表現卻從來都是可控的。