01 - 從IT運維到IT運營

主動式運維相比被動式運維，其關鍵在于從被動解決問題變為主動防控風險，在于持續總結優化，將運維活動延伸到系統運行全周期，形成改進閉環。
通過總結、反饋、優化等活動避免問題再次發生。

具體體現在從“從IT運維到IT運營”的轉變。

傳統的IT運維管理更多是被動式“維待＇，面向基礎設施、軟硬件等，更關注穩定、安全和可靠，注重故障修復。
隨著傳統信息架 構的變化，需要一種全新的IT支撐模式來解決信息系統異構、數據融合、管理分散造成的新問題，即IT運營。
IT運營相比IT運維，更加主動地對系統進行全面的分析和評價，面向“經營＂、業務、服務，但本質是面向用戶，更加關注體驗、效率和評價。

02 - 互聯網意識

必須站在用戶的視角，基于用戶需要什么來設計產品，對外提供服務。
同時為了快速響應用戶需求（甚至快速試錯與糾錯），內部的IT服務也必須高效敏捷。

03 - 成熟度模型

• 作為判斷組織是否處于一個特定規模和組織需要實現哪些工作
• 定義5個不同的類別來表示在實現持續交付時需要考慮的關鍵方面:文化和組織、設計和架構、構建和部署、測試和驗證、信息和報表
• 識別在每個活動中需要采取的步驟以及所選定的每個時間周期的特定目標，也就是“一定周期內達到的狀態”
• 需要對現有系統進行怎樣的更改？對未來整體業務計劃的影響？
• 合規性：質量、測試閥門、數據安全

04 - 快速響應與實現

## 盡早變更
產品先以一個可視的原型展現，越早發現問題，做出修改的代價就越小。

## 縮小決策范圍
建立一個快速有效的決策機制，讓“一線指戰員能夠呼喚炮火”。
決策的人級別越高，效率就越低。但如果決策的人級別太低，又可能造成大量的意見，不能服眾。
應該讓那些有決策能力的、對產品特別熟悉的人中最低級別的人來做決策。

## 設置優先級
所有的任務都設置優先級，當做出承諾的時候，只承諾高優先級的時間計劃。

# 自動化一切
要做好自動化測試、一鍵發布、灰度發布、故障快速定位跟蹤、故障快速恢復等措施，以應對頻繁變更。

05 - 團隊規模導致的問題

隨著團隊規模的擴大，通常出現的嚴重問題

## 缺乏信任和協作的“墻”
由于人數眾多，難于管理，只能通過制度、流程、規范、績效來做約束。
也許組織的執行力看起來確實很強，員工絕對服從，流程制度上不容易出錯，但是效率卻非常低下。
因為在實現層面，員工都是以KPI為前提的，很難推動那些沒有事先與KPI關聯，但又十分重要的工作。
尤其在跨部門溝通和協調的時候，效率太低。

## 沒有責任感
除了管理者，沒有人愿意去決策和適度跨界，因為一旦失誤將是非常大的責任，所以很多人都是在被動等待。
于是很多人依靠嚴格的流程，嚴守自己的關口，忽視整體效能，否則出了問題自己要“背鍋”。
員工只關心KPI，而KPI是由上級主管一級一級來決定的，所有人都為了“不犯錯”，結果“自賣自夸”的匯報成為了“重中之重”。
結果就會出現大量匯報材料和空泛的文檔，取悅管理層的優先級高于了業務盈利的優先級，而管理者則被推入到“各種決策會議”之中。

## 不尊重專業人士
少數人的“一言堂”，管理層和決策層的話會被過度地仔細推敲，忽略領域專家的觀點。

## 管理層級太深
管理者不知道也無法理解下面的人在干什么，為什么這么干？
只能通過匯報，去了解進度、識別風險、評定績效、實施獎懲等，又導致了很多會議和形式上的匯報文檔。

可行的解決方法：

• 管理層應該在項目和團隊管理工具上直觀地看到事項進度和資源動態，比刻意的匯報內容要更真實快捷
• 整體業務的盈利和卓越的團隊才是真正的效能，啟用“多級評估系數”，例如，個人績效=公司業績系數*部門業績系數*個人績效系數
• 使用項目和團隊管理工具時，區分事項的優先級和重要程度，指定明確的負責人和關聯方，公示事項的判定標準等等
• 評價基于連續性的客觀事實數據（項目和團隊管理工具）
• 啟動“環評”，“誰干的好”應該由和他事項相關人的評價來佐證

06 -