產出的價值無非2點(無論是小事還是大事，有價值的事情，就必須要去做，方法和工具都是靈活的。
1.節約成本。
2.724小時保證業務不間斷運行。
1）成本預算必須要做，否則當業務收支平穩的時候，boss就非常關心了:
1.機器配置統一化,業務也知道配置的選擇，而不是迷茫，獅子大開口。
2.業務人數評估(正常量和突發量)
3.各業務產品功能和邏輯梳理，包括使用場景。前期怎麼做，後期擴展的方案有哪些？slb-web-cache-db-storage等
4.機器性能對比，包括整體使用率和可用率，否則拿來指標讓開發信服
5.對於某些業務，繁多但是使用率居多，可不可以考慮複用？複用的隔離，優缺點在哪，事先要考慮好
6.資產收集庫:互聯網公司無論大還是小，都應該有自己的獨立資產庫，雖說這準確率不能達到100%，但是至少也能給你在服務器成本，還有當前的類型中有個清晰的思路，也方便你以後真正做裝機＋dns整合開發的時候用吧。
7.發佈:單純運維60%的工作都浪費到這裏，因爲每家運維的人數大多數比開發少，但是又不可能堆人吧，這時候能有效的解決發佈效率，讓開發自由發佈，但是權限和安全口子都是由運維把關。
2)保證業務可持續運行，穩定:
1.監控方案，開源，自源，還是組合？業務只要清楚出問題，運維和對應業務線的開發能第一時間知道，哪怕網絡抖動一點點，還要考慮好報警狂轟濫炸，怎麼做收斂？(運維沒有完善的監控和收斂機制，就是瞎子過河)
2.集羣調度方案，調度的算法需要和業務開發碰，有可能調度的算法，當前業務無法支持，還有整個調度的鏈路，具體到某臺主機去執行用戶處理了，開發可以不知道，但是運維必須要知道，自研，還是開源的工具去做跟蹤彙報，自己去衡量。
3.按照業務不同邏輯拆開方案，公司越大，產品功能就越多，業務邏輯需要集中化，但是也要細化，集中化是知道一個大業務包含多少子業務，模塊，細化是精確到某個LB，哪些機房，節點，包括監控清晰的命名等等。
4.主機命名規範:主機命名最好按照能簡單理解，拆分的方式，因爲機器多了，內部dns解析也會派上用場，這時候，還是N多的localhost，你會很頭疼。
5.日誌集中式管理，日誌第一要解決的是格式統一化，有的開發輸出字符串，有的json，有的list等，這很頭疼，剩下的纔去考慮從請求－接收－彙總-集合－存儲等過程。
6.突發高峯，自動伸/縮對應配置機器，秒殺，高併發的公司，可能某個推廣或者熱門的消息，就可能導致pcu增多，而負載均衡，db，服務器抗壓的峯值都是有一定瓶頸，這時候自動快速構建機器和服務啓動標準，就有很大方便了，但是pcu減少了，又不想浪費成本，這時候，整個調度會根據多方面緯度閥值進行對臨時主機的銷燬，而且保證服務的穩定性。
7.事故降級，切換方案，事故的經驗如果沒有的公司，可以慢慢積累，並且可以內部把故障設爲多個等級，每個等級處理和上報的層級對象有哪些，S級別的故障，比如機房癱瘓了，被***了，備用機房或者多機房擴容和切換？
8.安全預知和防護的方案，除了系統基礎的防護，還有最前端的調度可以讓外部訪問到，一切只允許內部互相調用，而且還要考慮防止誤調用，業務故障現象，防火牆還是安全組的規則定義這就需要好好劃分和管理了，一定是集中式的，否則太痛苦維護了。
9.新技術選型優缺點衡量，做開發還是運維，如果不能與時俱進，早晚被淘汰，但是一切皆爲穩定的情況下進行研究，測試，最後觀察沒問題，才能替換新技術方案。
10.團隊配合，溝通，簡單的說明：你說的話，無論運維，開發都能知道你想要幹嘛，而且需要他們做些啥，而不是互相扯皮，糊里糊塗的。
本文摘自師兄符哥，供自己收藏