原创 如何從零構建你的自動化運維體系?——從制度到技術

前記:所謂幹一行愛一行,人生處處是《圍城》這是人性,但在改變那一刻之前,自應全心全意研究本行,全心投入,不計回報,用心在當下,寫到體系就像是前面所有博客的一個帽子,現在把他總結整理出來,希望對你有所啓迪。自動化運維體系是一步步發展過來的,構

原创 詳解Http與Dns劫持污染的技術原理和排查預防

負責過互聯網系統建設和質量保障的基本都會遇到一個問題——劫持,所謂劫持就是把請求通過技術手段引導到指定的服務器代理一遍,通俗點講就是過一遍手,過一遍手可做的文章就大了,可以監聽信息、緩存內容也可以篡改內容,甚至拿到用戶的登陸權限,如果別有用

原创 像這樣管理https證書,你還擔心證書過期忘記更新?

由於證書的實效限制,因證書過期忘記更換出現的故障屢見不鮮,而且影響都比較嚴重,用戶量越大,災難性越強。既然大家都知道證書的破壞力,那麼爲什麼過期問題還是前仆後繼的出現呢?分析看,一來證書是一個正常時期少有人關注的東西,只有過期了才知道他的破

原创 ATS代理緩存工作機制流程圖(自畫)

 爲了方便了解學習ats的代理緩存工作機制,抽時間畫了一張單node節點的工作流程圖,分享出來交流學習,此圖經過了多次修改,畫工一般,包涵見諒!!!注:ATS直接讀寫裸盤,不需要格式化掛盤。650) this.width=650;" sr

原创 ATS巧玩兒緩存策略增加動態服務吞吐量

先看一下策略調整後瞬間的流量圖:650) this.width=650;" src="http://s4.51cto.com/wyfs02/M02/7D/34/wKiom1biPgniuMbYAABokJ_0Sig253.png" sty

原创 說說爲什麼要有CNAME

    做互聯網、CDN都少不了去和CNAME打交道,工作中也遇到很多關於CNAME的知識,現在對CNAME做一個總結,爲什麼要有CNAME,以及CNAME存在的價值是什麼,拋磚引玉,純屬個人理解!!!1、降低多域名、多服務器、多業務的運

原创 調整ATS日誌處理機制及相關腳本

    在ATS的嘗試使用中,日誌處理是很重要的一環,我在研究這個時候花了不少精力,首先我們測試用的ATS是5.3.2版本,默認打印的是二進制日誌squid.blog,一天一切割,當然也可以變爲文本日誌,不過ATS自帶的很牛逼的分析tra

原创 大型系統的運維要從哪些方面抓起——從被動到主動

一個大型的互聯網系統,意味着大用戶量、業務模塊多、服務器多、各種資源佔用多,在拿到一個大型的互聯網應用,運維保障工作應該從哪些方面抓起呢?首先還是先看運維的目標,追求更高的SLA、更低的成本。所有事情都是以這個目標爲出發點,SLA指更高的服

原创 Logstash對nginx的access/error.log日誌清洗並數據可視化監控設計

Nginx有兩套日誌,一套access.log一套error.log,access.log用戶可以自定義,兩套日誌處理好,業務的質量就瞭然於心了,另外,日誌關鍵指標可視化分析我認爲是運維中最重要的事情了,沒有之一。對於後期的可視化監控,核心

原创 shell腳本——爬取域名一級頁面元素並判斷其可緩存性

   來了一個域名如何判斷其緩存與否,高大上的專業爬蟲當然可以做分析,如果不是很嚴謹的分析,通過shell腳本也可以實現,來看看我這個一層頁面的小爬吧,哈哈哈,先腳本執行後的結果圖:在處理的時候,會用elinks把頁面上所有的元素爬出來,

原创 漫談運維服務體系的建設和發展——從制度到技術

前記:所謂幹一行愛一行,人生處處是《圍城》這是人性,但在改變那一刻之前,自應全心全意研究本行,全心投入,不計回報,用心在當下,寫到體系就像是前面所有博客的一個帽子,現在把他總結整理出來,希望對你有所啓迪。任何崗位都有其業務職能,全部職能梳理

原创 WebService之nginx+(php-fpm)結構模型剖析及優化

  隨着php腳本語言使用的普及,目前webserice服務大部分都在用nginx+(php-fpm)的結構,瞭解了其工作過程後纔可以在各個方面想辦法做調整優化和故障排查,從以下幾點總結一下這種模型。一、nginx和php-fpm的關係和分

原创 nginx多條件if判斷後rewrite,減輕後端php工作壓力(隨筆)

先說下我對nginx配置文件的認識:      nginx的配置文件可以看成是一個程序,一個按照程序員思維習慣進行語法設置的nginx配置程序,編寫簡單便於理解,而且配合着各種變量和if判斷等指令可以靈活的做各種策略設置。      工作中

原创 十幾萬連接幾M的流量,嚇死“寶寶”了

    某局點升級(nginx變ats,同時去掉前端的nginx負載層),升級之後服務就不正常,硬生生的看着十幾萬連接,沒有流量,各種排錯,可謂是把心提到嗓子眼驚心動魄的半小時,雖然做了很好的業務機制,服務不正常用戶可以直接回源,不過對於我

原创 ELK之ES2.4.1雙實例平滑升級調優至5.2.1踩坑並supervisor管理記

  ES老集羣用的2.4.1版本,跑的比較好就一直沒動,最近看資料ES5.X已經穩定,並且性能有較大提升,心裏就發癢了,但由於業務要保持高可用的屬性,就得想一個平滑升級的方案,最後想到了多實例過度的辦法,5.X版本網上介紹配置變化較大,也做