如果是新產品，在設計階段運維就有必要參與進來了，因為做出來的產品最終都要交付上線，放到服務器上給用戶提供服務，一是運維更加了解線上環境，研發階段簡易的demo開發環境放到線上會遇到各種問題；二是開發過程如果缺少運維意識，上線后在做資源彈性調整及其它策略改變可能會遇到各種麻煩；另外運維人員會根據模塊屬于不同的IO消耗型、cpu消耗型、內存消耗型等需求提出更加合理的上線服務器環境，提前參與產品中也可對節省成本的同時提高性能有很大幫助。根據經驗，我總結了4個要素，同樣如果對于已經做好的產品，從優化的角度去提升產品性能同時減少故障，也是從這“4要素”出發：

一、整個系統的功能要模塊化（微服務），單個模塊高內聚低耦合；

  大型互聯網應用面對全國乃至世界范圍的使用，要面對開發分工、迭代、擴容等各種場景，使用中要保證優秀的用戶體驗、良性的迭代升級和業務擴展，一定要使用微服務的架構設計思想進行模塊拆分，一個沒有模塊劃分的系統是不可能完成這項任務的，想想幾百號人圍繞著一套代碼轉是個什么樣子。一個優秀的大型互聯網應用會在設計之初就進行模塊化，每個模塊各司其職，模塊間通過HTTP API或者消息隊列進行通信，各模塊根據工作量和難度分給不同項目組負責，最后單個模塊形成高內聚、模塊之間形成低耦合的模型，該是誰的事兒就找誰，當然功能模塊怎么劃分更加科學，就需要做研討了，研討中要從當前開發的科學性和后期上線可運維性兩個維度來做考慮。

二、每個功能模塊相對獨立易部署、所需資源彈性可擴展；

    要應對線上變化的環境、用戶量的自然及突發性增長、開發者的人員變動，每個功能模塊在做到功能獨立高內聚的同時，要做到運維的可交付、資源的可彈性擴展。

    運維的可交付體現在模塊的易部署（越簡單越好），部署過程不依賴修改源代碼，所需的配置文件、代碼可以做到統一下發。

    資源的彈性擴展是為了應對用戶量的自然及突發性增長，比如說要做一個活動，訪問量會突發翻倍，這時模塊要能做到易擴展，可以彈性的通過簡單的擴容服務器來增加系統吞吐量，不至于造成系統瓶頸，每個模塊做到了彈性可擴展，整個應用才會變成一個彈性可伸縮的強大產品。

三、每個功能模塊無單點故障點，如遇后端依賴故障可以降級服務；

    為了讓開發和運維人員能夠睡個好覺，一個好產品的每個模塊必須能夠做到服務器間容災且無單點故障，就是說一臺服務器掛了不會影響到模塊服務，進而影響到整個應用的癱瘓，每臺服務器模塊都是一個獨立的個體，互不影響，當某臺服務器掛了之后剩余的服務器能把活兒接起來，當然這是最理想的模型，如果實在無法做到熱備，最起碼得做到無需人工干預的冷備。

    模塊之間都是協同工作的，每個模塊都可能承上啟下相互依賴，在向前端輸出任務處理結果時也依賴后端其它模塊的處理結果，這時就要考慮到萬一依賴的后端模塊掛了或者超時怎么辦的情況，以防出現雪崩的連鎖反應，這時模塊就有必要設置降級預案機制，比如說當那不到結果或為空時向前端返回一個默認的或最近處理的結果，應付一下用戶，總比返回錯誤信息要強，然后騰出時間解決問題，再比如是個新聞類應用，可以返回一個近期的靜態頁面。

四、每個模塊的日志健全，做到可分析、可監控。

    日志的健全性很重要，日志可以及時的發現問題、分析問題、分析模塊的性能、故障點等等，總之日志可以反應出各種問題，其包含但不限于操作系統日志、業務日志（訪問、超時、錯誤）、后端資源依賴日志等，分析的結果同時正向反饋到下一步的產品迭代研發中去。

    對于監控，也分為了基礎監控、應用軟件監控、業務監控、依賴監控四個層面，簡單介紹一下，基礎監控指服務器各種基本指標包含cpu、負載、io、內存使用、網卡流量等的監控，應用軟件只nginx、tomcat、php-fpm等應用軟件本身性能的監控，業務監控是指訪問后或對于任務處理情況的日志監控，比如說nginx的訪問日志，依賴監控是指其依賴模塊或資源的監控，比如說MC、redis等。

    寫在最后：如果一個大型互聯網應用能夠做到這“4要素”，這個產品就是一個很高級的妖怪了，能夠抵抗狂風暴雨。（所說“產品”是技術層面產品，并不是為網民設計的接入層用戶體驗類邏輯產品）