運維小哥談規則

       作為一個IT小哥，在閱覽技術書籍時，看到作者對運維規則的總結，反覆閱讀幾遍後，發現其內容言簡而意賅，質樸而真諦。些許認知是我自個兒明白，而無法用言語總結的；些許是讓我自個兒從無知到認知的；些許是我想要做而目前作為一個運維小哥而無法做到的~~

       總之，閱覽後如獲珍寶。當然，作為一個運維小哥，以下內容及規則（涉及系統大體）自個兒能駕馭的是少之又少，但絲毫不影響我的向學之心！那是我的工作之心所向，那是我傲嬌之心所追，更是對自己能力提升的同時而注重的自我昇華！

       因為，我命不由天，莫欺少年窮！

       以下是本人根據書籍內容及些許的自我認同而提煉出的部分精髓（至少自己是這樣認為，^_^），個人感覺，有一部分適用於運維人員，而有一部分適用於技術管理人員。相信也存在許多像我一樣的IT小哥哥小姐姐，所以希望做個分享，希望能讓有需之人觀後有感！為啥我要總結出這兩種人群的適應內容呢？呃，畢竟，不想當將軍的士兵不是好士兵~

       對於運維而言，平臺、工具、知識、經驗，意識等都固然重要，其都在某種程度上決定了運維質量。而對於運維規則，也不可小覷，整好了也許會有四兩撥千斤的效果哦！

       以下內容是本人摘錄技術書籍內容，同時加上了些許個人感知及個人言語，不喜勿噴哦！

# 勿重複勞作

       不要重複勞動力，也不要什麼都從外部獲取，如工具、程式碼、框架等。需要考慮的是在合適的時間以合適的成本切入，投資回報率也是需要考慮的。

       一般來說，每個公司都存在重複造輪子的現象，而且許多人都熱衷於此，可能需要用這樣的專案來證明自己，而卻忽略了投入/產出比這個重要的指標。如果能夠充分利用社群的成果，利用公司已有的成熟框架，那麼可大大加快自己的專案進度，因此，為什麼非要自己做一個呢？也許有些人考慮的是重複造輪子，可以真正鍛鍊到團隊，畢竟一個從頭開始的專案，所積累的經驗往往比一般專案多得多，有助於個人的成長和公司後續專案。

# 允許出錯

       人非聖賢，孰能無過，運維也是如此！出錯並不可怕，關鍵是要建立機制，讓錯誤能夠儘可能快速地被修復，限制錯誤影響的範圍，同時要歸納總結，從錯誤中讓個人成長，讓組織成長。

       當然，允許出錯並不表示事無鉅細，均可犯錯。允許出錯是建立在大體層面上已儘可能的完善了整體制度，規範了運維流程等情況下出現的無可預知的錯誤！

       只要存在硬體載體，就必然伴隨著各種各樣的故障。有時為了追求高可用性，設計複雜的架構，或者準備過多的冗餘設施，往往會導致解決方案的成本劇增，而解決方案的複雜性，也會為後期的改造及維護增加難度。國內眾多公司都號稱可用性高達99.99%，甚至高精度的小數點後面多加好幾個9。然而，某巨頭企業的雲產品導致小公司資料丟失，某巨頭企業應對活動日出現頁面異常等等場景，讓我們情不自禁的感嘆~~

# 設定備用

       備用角色在運維工作中可能只被人看到日常運維的價值，而當主要角色因事請假、過度勞累、因故離職等時期，備用角色價值凸顯，他可讓正在進行的專案不被打斷，正在進行的工作不陷入被動。高效培養備用角色，其需文件、流程和規範的支援，故運維規範等也是重中之重！

# 定位瓶頸

       不監控，無運維。此話說明監控的重要性，對於一些資源的爭用，通過監控系統能夠直觀的反映。而對於一些隱藏較深的資源瓶頸和系統瓶頸，往往需要利用工具，靠經驗去分析和判斷。作為運維，需要有意識的儘可能地通過監控系統去發現問題，讓監控系統變得越來越智慧，越來越少地依賴於人的經驗。

       高階工程師和初級工程師有一個很大的區別，高工知道如何去定位瓶頸所在。他們不僅知道如何使用工具，還知道何時、何地、為什麼要使用這個工具。這樣，才可能在問題爆發之前，就定位到瓶頸所在。

       當然，定位瓶頸，單一化的運維知識可能滿足不了需求，因為資料可能要經過很多環節，如本地電腦、瀏覽器、DNS服務、負載均衡裝置、應用伺服器等。

       所以，應該儘可能的涉獵不同領域的多元化的知識。

# 重視工具/平臺

       許多網際網路公司都有基礎平臺的技術部門，專門負責開發基礎平臺、工具和服務，提供給各個應用研發團隊使用。但這往往是一個短期內難以見到效益的事情。對於業務規模不大的公司來說，更多的時候是在做一些技術儲備的事情。基礎平臺部門往往是伴隨著公司的高速發展而壯大的，研發出來的產品如果沒人用，自然就得不到改進，然後就更加沒有人使用，如此惡性迴圈。其情境往往考驗高層的決心，考慮是否需要繼續堅持保留適當比例的底層平臺開發人員呢？

       應用軟體的研發和平臺工具的研發畢竟是不一樣的，如果基礎不牢，可能造成更大的業務風險。所以長遠來看，使用部分人力（高素質的工程師）做平臺和工具，其實是節省成本的！

       矽谷的一些公司，讓優秀的人去做平臺和工具，並提供最好的待遇，給予足夠的尊重，對於他們的衡量標準也應該不同！

# 分工明確

       大規模的系統架構體系的維護，離不開訓練有素的工程師，他們需要有許多知識、經驗和技巧，也必然分工明確，如開發運維平臺的、專門資料操作的、效能調優的、原始碼優化的等等。優秀的團隊可能還有專案經理、質量管控、文件編者、成本分析、培訓教育等各個專業領域的人，不同崗位的人員在自己的專業領域發揮優勢，各司其職，才能使整個專案的光彩洋溢地淋淋盡致~

# 善於分享

       應該多參與業內技術交流，對於一些問題，也許有些公司能有更好的解決方案，如果你分享了經驗，同行們也會分享經驗。從某種角度上看，兩者是競爭者的關係，但是如果需要發展，就要看看業內的競爭對手在做什麼，要跳出公司的格局去看待技術和管理問題。

       同時，參與業內的技術論壇不僅僅是關注行業技術趨勢的一種手段，也是一種招聘方式，通過認識更多人，擴大影響力，吸引更多人加入自己所在公司。自我人脈擴充套件的同時也充實了公司的發展，何樂而不為呢？

# 重視例會

       許多管理者忽略了週會與例會的重要性。若長期不重視，整個團隊就可能變得鬆散，沒有凝聚力。

       週會的一個重要作用是討論分工。隨著機器規模的擴大，人員的增加，團隊管理者都需要分工明確，責任到人，才能促使員工儘可能的恪盡職守。

       週會也可討論彼此的工作進度、交流未完成工作的對策、互相瞭解團隊成員的工作狀態、傳達上層領導的指示、交流技術與分享等等~~~

       總之，每個人的工作飽和度及個性等差異化，如果沒有有效的溝通，關係可能就會像從果核中慢慢腐爛到表皮的水果，彼此互有抱怨。因此，固定一段時間進行正式的交流併成為習慣是值得推薦的溝通方式，同時也可使得同事關係融洽，人員氛圍優升~

# 績效束縛

       關鍵績效指標（KPI）是指用於評測組織中與關鍵目標或關鍵成功因素，許多公司到了一定規模後，都把KPI考核作為一項主要的管理工具。

       而事實是績效是一種工具，人卻是複雜的，管理人更是一件複雜的事情，要想面面俱到，很難靠績效這個工具來簡化所有的問題。當然，很多東西量化之後，就顯得比較好管理。對於產品經理、運營人員、銷售人員等等而言，量化指標，往往是看的見的數字。而對於運維及部分職位，可能就很難有一個量化指標！

       績效的設計應該是幫助個人發展，幫助員工贏的尊重的，而不是用於桎梏個人的。當個人的價值觀和企業的價值觀起些許衝突時，但凡一個好企業，往往具有包容性；而當衝突嚴重時，同時個人又不能妥協時，可以考慮換個環境，避免繼續在一起的雙方損失。

       在書《贏》中，管理大師傑克·韋爾奇運用績效造就了偉大的文化，而不容忽視的背景是，他花了許多年創立了坦誠溝通的企業文化。如果沒有坦誠、沒有溝通、績效可能會成為破壞企業文化的殺手。在推動工作進展的時候，不是去考慮對公司是否真的有幫助，而是主要去考慮自己的績效，是一個非常不好的傾向。自己現有的工作成果，工作輸出，決定了自己後續的工作方向~~~

# 優化設計

       應該有意識地優化流程設計以提高工作效率和服務質量。隨著公司業務的發展，運維部門也會隨之擴張，如果缺乏合理的流程或缺乏高層次的人才，那麼往往會出現一個問題：人數增多了，效率反而下降了！因為隨著公司規模的擴大，所管理和維護的資源急劇膨脹，出於安全和其他因素考慮，設計了各種各樣的流程，以便得到正確的執行結果，但有時這些流程可能會導致效率下降，部門內部的溝通成本也越來越高，這都需要運維人員對流程本身建立反饋和優化的機制，有意識地不斷優化流程！