目前主要負責監控告警，屬於運維開發的範疇。公司有三個以上核心項目，應用服務人數超過萬人。運維人員40人左右，總項目幾百個，資源分配不均。只能集中力量辦大事。
昨天看到一篇文章，客戶和用戶的區別，當然產品是面向TO C的，但是我認爲所有的概念都是可以相互轉換的。
客戶其實是可以對產品好壞進行評價，具有拍板權，用戶是實際使用產品的，可以對產品進行吐槽，可以從側面影響客戶。但有時候不一定管用。
內部的系統也是這樣，領導說好就是好，具有拍板權，可以認爲是客戶，真正使用的可以認爲是用戶。
下面進入正題：
40個人維護三百個系統，平均下來一個人維護差不多十個業務系統，有點風吹草動，就要改東西，我們支撐的有幾個人呢，4個人，如何做？
靈活+自定義，要讓用戶的所有操作都可以在平臺上完成，不要直面用戶。就像淘寶購物、餐廳點餐一樣，自己不會直面平臺的建設人員。
拿餐廳點餐來說，餐廳有套餐，套餐有完全一樣的，也有可以按需打菜的；非套餐有現做的，各種麪食；
其實個人理解最重要的一點，是有調料、佐料、小料，我覺得這個纔是重點，爲什麼？因爲你很少見有人說，廚師我這一碗少放點鹽，廚師我這一碗多放點鹽，廚師我這一碗多放點醋；
我個人理解原因如下：
1、臉面問題，這種小事當衆說出來，會有人覺得你是個事媽，
2、不好驗證，多放點鹽，少放點鹽，你不一定好驗證，比如廚師說給你放了，但是你覺得沒有，怎麼辦
3、無關緊要的小事，衆口難調，而且餐廳一般配有佐料臺，個人可以按量，酌量添加。
綜上，餐廳解決這一問題，就是靠着放權，充分發揮用戶的主動性，讓用戶自己搭配，一旦搭配錯了，比如放的太鹹了，可以回鍋處理下。但是用戶不能怨別人，只能怨自己手抖鹽放多了。
所以做系統應該給用戶套餐，最快實現需求；單點，個性化口味，選擇多樣；佐料，錦上添花；
回到系統上，告警短信的內容，五花八門。我們用到了zabbix、promethus、自建的告警平臺、CMDB、短信網關，封裝後的zabbix自助平臺，還有grafana；
標準：就像餐廳一樣，大米、麪條、米線、饅頭、餅、這是基本元素，
對應起來，主機、網絡設備、中間件、數據庫；
口味：原味、微辣、中辣，類型，
對應起來，性能告警、關鍵字告警、宕機告警
佐料：油鹽醬醋
對應起來，自己可以修改閾值，自定義短信模板。
我們這關注的有：
業務、應用、工程、成本中心、機房、一級告警類型、二級告警類型、網元類型；
想辦法按照組合套餐進行組合