### 我的核心價值觀（YD）： ##### 所有事以降本增效為目標 ``` 如果你做的工作即不降本，又不增效，那一定會被拒絕，連提都別提 ``` ##### 工作目標：讓公司不需要我 ``` 運維工作不需要運維，才能證明個人的價值 ``` ##### 必須有知識庫 ``` 建立完整的知識庫，讓運維信息不再因為人員變動而丟失 ``` ##### 必須有產出物 ``` 做好運維信息匯總，密碼管理，便于工作交接和分享 ``` ### 工作部分 #### 運維需要一些理論 技術無死角 > 當前涉及技術完全可控，不忽略任何細小變化 知識無死角 > 掌握橫向知識（業務邏輯、工作流程） 經驗無死角 > 問題的處理要進行記錄、整合、分享 溝通無死角 > 領導是對外層級，對內部工作要做到信息共享 #### 怎么對待工作 ``` 追著事情走，別等事情 領導不問，不要說過程 沒有結果前，不要告訴領導任何消息 遇到問題，先微笑 解決單點問題 工作有不確定的， 整體推測一遍后，盡量減少問問題的次數 ``` #### 合并業務時，第三方業務不要和自主業務混合 ``` # 背景 有些老舊業務要整合，希望把所有都整合但被拒絕 # 原因 有漏洞的業務（dicuze） 不要和其他業務混合在一起用 因為如果一點被攻破，所有業務都會影響 ``` #### 當你在工作中沒了目標，看看這篇文章 ``` 關于技術提升 （內容摘自《架構師之路》沈劍老師的一篇文章） 面過不少同學，我必問的一個問題是，“為什么想換工作”，不少同學的回答是： “覺得自己到瓶頸了，原來的公司學不到東西了。” 然而面試聊下來： （1）基本功不牢固（語言，數據結構，算法等）； （2）工具不熟練（數據庫，緩存，隊列等）； （3）業務架構，系統架構不精通； 此時我就非常詫異了，明明有很大空間，為什么會有“學不到東西”的感覺呢？ 很多時候，是行業浮躁，是我們自身浮躁，以為自己很厲害，實際上卻是半吊子。 我們 不妨問問自己：基本功打牢了么？工具熟練了么？業務搞透了么？架構合理么？是公司技術最牛逼的人了么？ 畫外音：都不是公司技術最牛逼的人，怎么能說沒有提升了呢？ 別說工作中用的東西千篇一律， 別說一直在做業務， 別說沒有技術含量， 不妨再問問自己： 監控到位么？自動化程度如何？做類似的業務，擴展性如何？高可用保證了么？知道系統瓶頸在哪里么？ 問過自己之后，或許你會發現，并不是自己沒有提高，而是過于浮躁。不是沒有東西學，而是內心的惰性，不愿意去發覺自己不懂的東西。 真的，腳踏實地的，持續學習和提高吧！ ``` #### 關于招聘 ``` 更好的候選人永遠會有，要耐心等待 不要被表面迷惑，有的看著踏實，實際只是表面功夫 為什么有些公司不愛招女生，擔心懷孕僅此而已 ``` #### 工作中，不要被事情影響情緒 ``` # 這是目標，我并沒有達到 工作中沒有任何事情可以讓我心情起伏 ``` #### 不要想著在工作時間學習 ``` 如果你在工作時間學習，只有兩種可能 1. 你進入了刺猬狀態（我起的名字） - 什么是刺猬狀態？工作中遇到壓力、挫折后想逃避，想跳槽，想學點東西就走人。這時任何打擾你學習的人，都會反感，變成一只刺猬，工作態度變差。這里只有一句話，要有職業素養。 2. 工作基本掌控，別人不會主動找你，可以安心睡覺 ``` #### 新入職工作從哪入手工作 ``` # 應以日常工作為入口 常規任務處理（工單，數據變更） 備份，備份可用性檢查，備份字符集檢查 暫時不要去過多的梳理業務關系 ``` #### 運維中的二八定律 ``` 運維中設計的軟件，20%的參數管理著80%的性能 運維中需要處理的技術工作有兩種：故障和性能問題 運維中，領導更關心原理，因為原理=處理方法，初期不要過度關注性能 ``` #### 基于二八定律，學習一個開源軟件方法 ``` 1. 理論學習 - 了解功能和配套軟件 - 了解大概原理 2. 部署 - 按照最簡單方式部署，能YUM不編譯 - 了解基本使用方法，并測試 3. 研究20%性能參數 - 只關注最重要的20%參數 - 掌握他們的原理 4. 了解軟件的限制和主要的坑 5. 準備測試環境，開始使用 ``` 例：基于ELK的數據收集分析展示系統 ``` 最開始接觸ELK的時候還沒有Beats組件，使用Logstash收集數據，太重。實際學習中，應該關注變化的東西，Beats組件很輕量級，要嘗試。 先不考慮集群，rpm包安裝單實例，不考慮日志過濾，先傳到ES，Kibana展示，看到效果。 下面有兩種選擇：一是研究ES集群和Logstash日志過濾，二是學習Kibana如何出數據，展示數據。 ``` #### 工作中主動推行一個開源軟件 ``` # 請先考慮能否降本增效 1. 了解原理和結構（非常重要） 2. 了解應用場景 3. 搭建并熟悉主要功能（基于當前業務） 4. 進行壓力測試，基于原理，模擬日常運維場景（考慮極限情況） 5. 私下找有興趣的開發參與，并提出需求 6. 編寫技術方案 - 主要體現原理（非常重要） - 根據當前業務量，預估壓力（并發、數據量） - 體現帶來的變化和運維成本（提升了什么、降低了什么） 7. 準備PPT為領導匯報，附帶技術方案 ``` 舉例：Piwik用戶數據收集分析系統（開源分析平臺） ``` 1. 簡單部署 2. 關注核心功能（嵌入js、數據收集展示） 3. 理解原理（數據收集、寫入、展示） 4. 壓測 5. 編寫技術方案 6. 匯報 ``` #### 組員工作出現失誤， 你該怎么做？ ``` # 起因 >梳理服務器，轉換到虛擬化，一臺服務器關停2個月后清理，但清理服務器后發現有一個半年才用一次的邊緣業務在使用，該服務器中的數據庫無備份，但此事無人知曉。 # 過程 > 經過思想斗爭后，組員向領導（技術總監）匯報了此事。 # 這樣做 1. 一起想解決辦法，但數據庫的確不能找回； 2. 一起想重建方法，需要嘗試去找之前的人； 3. 寬慰組員，要去做一些事的時候一定會觸碰到一些東西，造成一些影響，別往心里去，下次注意； 4. 最終通過代碼重建了數據庫 ``` #### 工作先規劃還是先做？ ``` 如果你可以掌控自己的想法，不會跳脫目標之外，建議先規劃。 否則建議你做以下幾件事 1. 確認這項工作是有意義的 2. 確認結果是總體目標中需要的 3. 去做一部分，重復步驟1和步驟2 ``` #### 我怎么帶人和面試 ``` # 不要給沒有干過運維的人研究一個新東西的機會 沒有真正干活底層運維的人（沒手動更新、監控、打包部署、人工管理10臺以上機器），千萬不要讓給他研究一個新東西的機會。 ``` 案例 ``` 客服轉運維，3選1，給了視頻讓他們學習，最終選擇了一個人搞zabbix 部署-->安裝-->配置-->研究功能使用，到了這一步，干不下去了，不想搞了。原因呢？ 1. 他不問我不主動教他。 2. 給他的解決辦法他覺得我在敷衍 3. 覺得學這個沒用。 沒有吃過苦的人，是不會知道能踏實研究一個東西是多么幸福的事情的。 ``` #### 如果領導給你安排任務和工作，請給回應 ``` 難倒你覺得領導是沒事給你安排任務么？ ``` #### 我面試關注的地方 ``` 1. 工作方法，工作態度 2. 學習方法 3. 技能（優先級最低） ``` 面試態度 ``` 寧可招1名運維工程師干一年，但能給運維工作帶來改變的人，也不要來2年，不求上進的人。最終這些人就是負能量的源泉。 ``` 工作中，那些人值得培養 ``` - 有能力（掌握需要的技能），技術放權，激發主動性，深入研究。 - 有執行力（具備學習能力，還沒學會），明確學習路徑，知無不言。 - 有態度（愿意學，不會方法），打牢基礎，完成基本工作，鍛煉耐心。 ``` > ##### 明確一點：有些人是不合適運維的。 #### 請尊重生產環境，哪怕是一臺測試機 ``` 因為上面可能跑著不常用，但重要的業務。 ``` #### 不要為了解決一個問題，引入另外一個問題 ``` 來自：趙舜東，趙班長 ``` #### 我們一直都信奉再好的技術和框架如果不能給企業帶來業務價值，就沒有太大意義。 ``` 摘自《企業IT架構轉型之道》 ``` #### 故障處理方法 單一軟件故障（不緊急） ``` 1. 定位報錯，無明顯報錯，去日志定位 2. 翻譯報錯（本人英文全靠google翻譯） 3. 百度報錯（90%都能找到），找不到就google 4. 從3-5中答案中分析最優可能的解決辦法 - 如何分析？博客準確率最高，基本都是處理過的總結。 - 同樣問題，不同辦法怎么辦？ 看那個有理論依據 - 有些解決方案如果都是相同內容，大家轉載，優先考慮 - 官方文檔查找具體參數 5. 整理文檔，想上級報送故障及解決辦法 6. 修改前記得備份相關配置，切記直接修改 ``` 單一軟件故障（緊急） ``` 1. 定位報錯，無明顯報錯，去日志定位 2. 翻譯報錯（本人英文全靠google翻譯） 3. 百度報錯（90%都能找到），找不到就google 4. 測試環境修改，并重啟，觀察日志，減少影響 5. 報領導批示 ``` 網絡故障 >前提：在運維的每一層都設置監測點，分層定位網絡故障 ```shell 接入設備-->安全設備-->4層反向代理服務器-->7層反向代理服務器-->業務服務器 ``` 業務故障 >前提：能夠“單獨”監控到所有集群的Web服務器（通過定義特殊域名） ``` 區分整體故障還是部分節點故障-->定位Web服務器-->快速擴容-->下線故障設備-->定位原因 ``` ### 個人提升 #### 如何排錯？(2/3/4無先后順序) ``` 1. 看并且看對日志 2. 百度/Google 檢索報錯 3. 通過官方文檔核實 4. 排除了基本故障（防火墻、Selinux、權限） ### 搜索引擎怎么用？ #### 搜索 "服務名稱 + 故障描述 + 報錯的ID + 報錯的主要部分" **注意：用空格隔開；私有內容，不用復制** ``` 例： ```shell Last_SQL_Errno: 1146 Last_SQL_Error: Error 'Table 'mysql.t1' doesn't exist' on query. Default database: 'mydb'. Query: 'insert into mysql.t1 select 1' ``` 搜索內容，注意增加空格，不要寫一句話 ```shell MySQL 復制 1146 Error doesn't exist ``` #### 怎么向別人提問？ ``` 1. 前因（環境） 2. 后果（報錯） 3. 嘗試了哪些處理（如果你沒baidu過，就別問了） 4. 將上面內容整理到文檔中，方便別人查看 5. 別說廢話，別窮嘚瑟（三大忌） - 請xx大神給看看（不好意思，我沒那么自信，你自己等大神吧） - 別@管理員（有事說事，@毛線啊，我沒事讓你@玩的啊） - 別說廢話“請問有人會MySQL么？”（不好意思，沒那么大口氣說自己會，等著會的人吧） 6. 麻煩您問完問題在這候著，別人回復你給個回應，別放個屁就走了 7. 麻煩有結果及時反饋，公布到群里，然后單獨謝謝幫助過你的人 ``` 例：遇到問題怎么問？ ```shell 請教個問題 1.環境描述： - KVM虛擬化 - 操作系統：Centos7 x64 - 橋接網絡 - IP地址192.168.0.100 - 網關192.168.0.1 2.故障描述： - 真機無法連接虛擬機，虛擬機ping不同網關 3.嘗試了哪些： - 防火墻關閉 - 服務器重啟 - 修改過IP地址 4.個人懷疑 Centos7 網卡名稱是隨機的，但是我的KVM安裝后，自動是Eth0，不知道和這個有沒有關系，謝謝。 ``` #### 咨詢解決方案怎么問？ ```shell 1.需求描述 - 核心需求 - 其他需求 2.需求拆解 - 根據核心需求逐漸細化 - 考慮壓力、并發、業務類型 - 考慮硬件（CPU、內存、磁盤IO、網絡IO） - 考慮軟件（系統、軟件選型） - 考慮日常維護成本 - 考慮投入成本 - 各種限制描述（只能選型某種硬件、某種數據庫、某個品牌、不允許使用開源軟件） 3.針對不同需求提出自己的方案 - 獨立思考 - 描述需求，提出解決方案 4.總結自己的解決方案和投入 - 合并需求和解決方案 - 統計經費、各種成本 ``` 想起一句話，能把問題描述清楚，70%問題都已經能解答了 #### 學習技術時如何確定優先級？ ``` 1. 自我驅使學習，只是為了學習技術，優先前者（穩定性和坑）。 2. 領導交辦的研究課題，優先后者（功能和應用場景） ``` . 1