作爲一名互聯網產品運維，對什麼是好的產品（技術架構角度）有自己的感悟（我負責運維的產品高峯日訪問量在10個億，機器分佈在全國不同機房，雖也有大小問題，但整體運行不錯）。產品運維是一個既要和開發又要和各基礎運維打交道的職務，要考慮到結構、擴容、容災、高可用和優化等各方面的事宜，又要研究產品的邏輯本身（排障時需要），工作中發現，一個好的互聯網產品不僅在優秀的代碼本身，更體現在後期的易運維性、可擴展性、高可用性等。隨着用戶量的變化、機房的變化甚至員工的離職，可能隨時需要彈性的調整資源改變策略來應對各種問題，而這就是體現產品是否足夠優秀的時候。
如果是新產品，在設計階段運維就有必要參與進來了，因爲做出來的產品最終都要交付上線，放到服務器上給用戶提供服務，一是運維更加了解線上環境，研發階段簡易的demo開發環境放到線上會遇到各種問題；二是開發過程如果缺少運維意識，上線後在做資源彈性調整及其它策略改變可能會遇到各種麻煩；另外運維人員會根據模塊屬於不同的IO消耗型、cpu消耗型、內存消耗型等需求提出更加合理的上線服務器環境，提前參與產品中也可對節省成本的同時提高性能有很大幫助。根據經驗，我總結了4個要素，同樣如果對於已經做好的產品，從優化的角度去提升產品性能同時減少故障，也是從這“4要素”出發：
一、整個系統的功能要模塊化（微服務），單個模塊高內聚低耦合；
大型互聯網應用面對全國乃至世界範圍的使用，要面對開發分工、迭代、擴容等各種場景，使用中要保證優秀的用戶體驗、良性的迭代升級和業務擴展，一定要使用微服務的架構設計思想進行模塊拆分，一個沒有模塊劃分的系統是不可能完成這項任務的，想想幾百號人圍繞着一套代碼轉是個什麼樣子。一個優秀的大型互聯網應用會在設計之初就進行模塊化，每個模塊各司其職，模塊間通過HTTP API或者消息隊列進行通信，各模塊根據工作量和難度分給不同項目組負責，最後單個模塊形成高內聚、模塊之間形成低耦合的模型，該是誰的事兒就找誰，當然功能模塊怎麼劃分更加科學，就需要做研討了，研討中要從當前開發的科學性和後期上線可運維性兩個維度來做考慮。
二、每個功能模塊相對獨立易部署、所需資源彈性可擴展；
要應對線上變化的環境、用戶量的自然及突發性增長、開發者的人員變動，每個功能模塊在做到功能獨立高內聚的同時，要做到運維的可交付、資源的可彈性擴展。
運維的可交付體現在模塊的易部署（越簡單越好），部署過程不依賴修改源代碼，所需的配置文件、代碼可以做到統一下發。
資源的彈性擴展是爲了應對用戶量的自然及突發性增長，比如說要做一個活動，訪問量會突發翻倍，這時模塊要能做到易擴展，可以彈性的通過簡單的擴容服務器來增加系統吞吐量，不至於造成系統瓶頸，每個模塊做到了彈性可擴展，整個應用纔會變成一個彈性可伸縮的強大產品。
三、每個功能模塊無單點故障點，如遇後端依賴故障可以降級服務；
爲了讓開發和運維人員能夠睡個好覺，一個好產品的每個模塊必須能夠做到服務器間容災且無單點故障，就是說一臺服務器掛了不會影響到模塊服務，進而影響到整個應用的癱瘓，每臺服務器模塊都是一個獨立的個體，互不影響，當某臺服務器掛了之後剩餘的服務器能把活兒接起來，當然這是最理想的模型，如果實在無法做到熱備，最起碼得做到無需人工干預的冷備。
模塊之間都是協同工作的，每個模塊都可能承上啓下相互依賴，在向前端輸出任務處理結果時也依賴後端其它模塊的處理結果，這時就要考慮到萬一依賴的後端模塊掛了或者超時怎麼辦的情況，以防出現雪崩的連鎖反應，這時模塊就有必要設置降級預案機制，比如說當那不到結果或爲空時向前端返回一個默認的或最近處理的結果，應付一下用戶，總比返回錯誤信息要強，然後騰出時間解決問題，再比如是個新聞類應用，可以返回一個近期的靜態頁面。
四、每個模塊的日誌健全，做到可分析、可監控。
日誌的健全性很重要，日誌可以及時的發現問題、分析問題、分析模塊的性能、故障點等等，總之日誌可以反應出各種問題，其包含但不限於操作系統日誌、業務日誌（訪問、超時、錯誤）、後端資源依賴日誌等，分析的結果同時正向反饋到下一步的產品迭代研發中去。
對於監控，也分爲了基礎監控、應用軟件監控、業務監控、依賴監控四個層面，簡單介紹一下，基礎監控指服務器各種基本指標包含cpu、負載、io、內存使用、網卡流量等的監控，應用軟件只nginx、tomcat、php-fpm等應用軟件本身性能的監控，業務監控是指訪問後或對於任務處理情況的日誌監控，比如說nginx的訪問日誌，依賴監控是指其依賴模塊或資源的監控，比如說MC、redis等。
寫在最後：如果一個大型互聯網應用能夠做到這“4要素”，這個產品就是一個很高級的妖怪了，能夠抵抗狂風暴雨。（所說“產品”是技術層面產品，並不是爲網民設計的接入層用戶體驗類邏輯產品）
自建個人原創站運維網咖社(www.net-add.com)，新的博文會在網咖社更新，歡迎瀏覽。