目前主要負責監控告警，屬於運維開發的範疇。公司有三個以上核心專案，應用服務人數超過萬人。運維人員40人左右，總專案幾百個，資源分配不均。只能集中力量辦大事。
昨天看到一篇文章，客戶和使用者的區別，當然產品是面向to c的，但是我認為所有的概念都是可以相互轉換的。
客戶其實是可以對產品好壞進行評價，具有拍板權，使用者是實際使用產品的，可以對產品進行吐槽，可以從側面影響客戶。但有時候不一定管用。
內部的系統也是這樣，領導說好就是好，具有拍板權，可以認為是客戶，真正使用的可以認為是使用者。
下面進入正題：
40個人維護三百個系統，平均下來乙個人維護差不多十個業務系統，有點風吹草動，就要改東西，我們支撐的有幾個人呢，4個人，如何做？
靈活+自定義，要讓使用者的所有操作都可以在平台上完成，不要直面使用者。就像**購物、餐廳點餐一樣，自己不會直面平台的建設人員。
拿餐廳點餐來說，餐廳有**，**有完全一樣的，也有可以按需打菜的；非**有現做的，各種麵食；
其實個人理解最重要的一點，是有調料、佐料、小料，我覺得這個才是重點，為什麼？因為你很少見有人說，廚師我這一碗少放點鹽，廚師我這一碗多放點鹽，廚師我這一碗多放點醋；
我個人理解原因如下：
1、臉面問題，這種小事當眾說出來，會有人覺得你是個事媽，
2、不好驗證，多放點鹽，少放點鹽，你不一定好驗證，比如廚師說給你放了，但是你覺得沒有，怎麼辦
3、無關緊要的小事，眾口難調，而且餐廳一般配有佐料臺，個人可以按量，酌量新增。
綜上，餐廳解決這一問題，就是靠著放權，充分發揮使用者的主動性，讓使用者自己搭配，一旦搭配錯了，比如放的太鹹了，可以回鍋處理下。但是使用者不能怨別人，只能怨自己手抖鹽放多了。
所以做系統應該給使用者**，最快實現需求；單點，個性化口味，選擇多樣；佐料，錦上添花；
回到系統上，告警簡訊的內容，五花八門。我們用到了zabbix、promethus、自建的告警平台、cmdb、簡訊閘道器，封裝後的zabbix自助平台，還有grafana；
標準：就像餐廳一樣，大公尺、麵條、公尺線、饅頭、餅、這是基本元素，
對應起來，主機、網路裝置、中介軟體、資料庫；
口味：原味、微辣、中辣，型別，
對應起來，效能告警、關鍵字告警、宕機告警
佐料：油鹽醬醋
對應起來，自己可以修改閾值，自定義簡訊模板。
我們這關注的有：
業務、應用、工程、成本中心、機房、一級告警型別、二級告警型別、網元型別；
想辦法按照組合**進行組合
Postfix 佇列監控告警,傳送告警郵件
設定監控的最大佇列數,當postfix佇列數超過設定警戒值自動傳送告警郵件給相關運維管理人員 bin bash 佇列目錄 queue dir naes incoming active bounce defer deferred corrupt hold trace admin 15801509423...
prometheus監控告警終極玩法包教包會的那種
倉庫中包含四個資料夾，分別介紹如下 prometheus prometheus的安裝與相關配置檔案。alert 告警的安裝與相關配置檔案。kube state metrics k8s提供的metrics，不是必須安裝的，僅在用到的情況下安裝即可。rules targets 需要持久化的檔案，包括ru...
配置raid5監控告警
採用megacli sendmail方式 一 背景 伺服器建立了raid5陣列,但是硬碟執行狀態與健康情況無法實時獲取.通過查詢各種解決方案,決定採用megacli sendmail的方式定時獲取磁碟相關資訊 二.伺服器環境與需要安裝的工具 專案詳情 伺服器型號 dell r430 硬碟型別 nas...