運維小哥談規則

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

       總之，閱覽後如獲珍寶。固然，做爲一個運維小哥，如下內容及規則（涉及系統大致）自個兒能駕馭的是少之又少，但絲絕不影響個人向學之心！那是個人工做之心所向，那是我傲嬌之心所追，更是對本身能力提高的同時而注重的自我昇華！

       由於，我命不禁天，莫欺少年窮！

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

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

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

# 勿重複勞做

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

       通常來講，每一個公司都存在重複造輪子的現象，並且許多人都熱衷於此，可能須要用這樣的項目來證實本身，而卻忽略了投入/產出比這個重要的指標。若是可以充分利用社區的成果，利用公司已有的成熟框架，那麼可大大加快本身的項目進度，所以，爲何非要本身作一個呢？也許有些人考慮的是重複造輪子，能夠真正鍛鍊到團隊，畢竟一個從頭開始的項目，所積累的經驗每每比通常項目多得多，有助於我的的成長和公司後續項目。

# 容許出錯

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

       固然，容許出錯並不表示事無鉅細，都可犯錯。容許出錯是創建在大致層面上已儘量的完善了總體制度，規範了運維流程等狀況下出現的無可預知的錯誤！

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

# 設置備用

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

# 定位瓶頸

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

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

       固然，定位瓶頸，單一化的運維知識可能知足不了需求，由於數據可能要通過不少環節，如本地電腦、瀏覽器、DNS服務、負載均衡設備、應用服務器等。

       因此，應該儘量的涉獵不一樣領域的多元化的知識。

# 重視工具/平臺

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

       應用軟件的研發和平臺工具的研發畢竟是不同的，若是基礎不牢，可能形成更大的業務風險。因此長遠來看，使用部分人力（高素質的工程師）作平臺和工具，實際上是節省成本的！

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

# 分工明確

       大規模的系統架構體系的維護，離不開訓練有素的工程師，他們須要有許多知識、經驗和技巧，也必然分工明確，如開發運維平臺的、專門數據操做的、性能調優的、源碼優化的等等。優秀的團隊可能還有項目經理、質量管控、文檔編者、成本分析、培訓教育等各個專業領域的人，不一樣崗位的人員在本身的專業領域發揮優點，各司其職，才能使整個項目的光彩洋溢地淋淋盡致~

# 善於分享

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

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

# 重視例會

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

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

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

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

# 績效束縛

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

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

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

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

# 優化設計

       應該有意識地優化流程設計以提升工做效率和服務質量。隨着公司業務的發展，運維部門也會隨之擴張，若是缺少合理的流程或缺少高層次的人才，那麼每每會出現一個問題：人數增多了，效率反而降低了！由於隨着公司規模的擴大，所管理和維護的資源急劇膨脹，出於安全和其餘因素考慮，設計了各類各樣的流程，以便獲得正確的執行結果，但有時這些流程可能會致使效率降低，部門內部的溝通成本也愈來愈高，這都須要運維人員對流程自己創建反饋和優化的機制，有意識地不斷優化流程！