SegmentFault 技術週刊 Vol.39 – 什麼!伺服器炸了?

NO IMAGE

相信小夥伴們在上網或者玩遊戲的時候一定都遇到過無法訪問的情況。“伺服器炸了”的原因有各種各樣,下面就讓我們來了解一下吧~

運維:為什麼受傷的總是我

經歷不可抗力是一種什麼體驗

知己知彼,百戰不殆,瞭解一下過去那幾年我們所經歷過的各種不可抗離奇事件吧。

  • 一、空調,揮之不去的噩夢
  • 二、易斷的纜線
  • 三、硬體造成的網路中斷
  • 四、波及全國的DNS根域問題
  • 五、地方流量劫持
  • 六、防毒軟體等攔截
  • 七、DDoS

淚說新公司使用雲伺服器後構架的不堪歷史

得出的最大教訓就是:雲伺服器太不穩定了,要以數量取勝,不能同一機櫃。有一次別人的雲伺服器被攻擊,提供商竟然重啟了物理機..然後又諸多悲劇出現。

最大的感恩就是:學到了很多知識。每次事故伺服器我都要被迫親自參與修復,本來不那麼熟悉的,一下子被強迫做了很多事情。

系統上線那點事 – 記一次線上系統故障

該專案是一個微信轉盤遊戲抽獎營銷專案,由於運營營銷時間要求緊迫,開發測試部署上線用了10天不到,有些準備工作並沒有到位。

系統上線那點事續

雖然在家休著但閒著無事開啟監控系統看著有啥問題沒。看了沒幾分鐘,運維同學打電話來,說“上次你說想要的現場來了,連線數又上來了”,馬上登上資料庫機器檢視,cpu usage, load average值跟上次故障如出一轍;但這次有所不同,一是已經有了上次的經驗,二是運維同學這次沒在高速的半路上,可以一起及時處理。

B站運維團隊成長的血淚史

B站運維痛點主要有3個:人手不足、故障多、運維繫統跟不上,針對這三個痛點,B站採用了三種方式進行破冰。

從鹿晗關曉彤戀情事件看運維的節假日準備工作

又是一年國慶,10月8日12點,鹿晗在微博公佈與關曉彤戀情,截至當日14:50, 該微博共收穫462,884次轉發、986,409條評論,2,566,617個點贊。造成微博服務短暫不可用。作為運維同行,對此深表同情和理解。

伺服器:穩住!

QQ億級日活躍業務後臺核心技術揭祕

今天給大家帶來《構造高可靠海量使用者服務-SNG數億級日活躍業務後臺核心技術揭祕》,一起探討怎麼從可用性的維度提升海量服務的可靠性及海量服務的故障處理方式,包括:

  • SNG後臺架構的概覽;
  • 面向海量服務的設計原則。騰訊海量服務的後臺設計一般通用的解決方案是什麼,包括如何提升海量服務的高可用性,如何從架構層、產品層、運維層提升服務的合理性;
  • 後臺服務故障解決思路

餓了麼運維基礎設施進化史

餓了麼成立於2008年,2014年底開始迎來業務的大規模爆發性增長,2015-2016年餓了麼進入高速發展期,業務和伺服器的增長都在數十倍的規模,這種大規模的增長必然帶來很多挑戰,本文將通過餓了麼運維基礎設施的進化史和大家分享不同時期應對挑戰的措施和思路。

雲智慧微課堂:移動創業公司的IT效能優化例項講解

今天和大家分享一下我在公司業務方面故障排查遇到的一些坑,以及進行效能調優的解決方法。

層層考慮可用性的網際網路系統

網際網路系統7*24小時不分晝夜的為人民服務,那麼這樣長時間服務的背後究竟有哪些手段保證呢?這其中包括軟硬體,及基礎設施的保障。IT人的努力:

  • 分散式系統
  • IDC
  • 高可用軟體
  • 儲存
  • 裝置
  • 電力

為什麼炸了?

面對大規模系統工程,看Facebook如何處理故障排查(一)

為了使Facebook的系統在快速變化的情況下保持可靠,專門為其研究了常見的故障模式,並建立抽象理念來解決這些問題。這些理念確保最佳實踐應用於的整個基礎設施。通過建立工具來診斷問題,並建立一種覆盤事故的文化來推動並作出改進,防止未來發生故障。

面對大規模系統故障,看Facebook如何修復(二)

一個伺服器即使有最好的預防措施,但是也會發生一些故障。在停機期間,正確的方式可以迅速解決問題,最大限度地減少故障持續時間。

系統故障、程式失敗和錯誤修正

每一次系統故障多是因為程式執行失敗或錯誤,偶爾也會有因為環境問題,比如:機器掉電、硬體故障、虛擬機器錯誤等。但即便是環境原因引發的系統故障,也是因為程式編寫考慮不足導致的。曾經就碰到因為硬碟故障導致服務假死(掛起)引發的系統故障,這就是程式的編寫並未考慮硬碟 I/O 阻塞導致的掛起問題。

網路故障排查常用命令集

  • 查詢路由表(route)
  • ping閘道器(ping)
  • 查詢DNS伺服器(dig)
  • 查詢DNS解析(nslookup)
  • 檢查路由(traceroute)
  • 檢查遠端埠是否開放(telnet/nmap)
  • 檢查本地(服務端)埠監聽(netstat)
  • 檢視防火牆規則(iptables)
  • 檢視網路頻寬使用(iftop)
  • 抓取資料包(tcpdump)
  • docs

運維人員處理雲伺服器故障的方法總結

遇到伺服器故障,問題出現的原因很少可以一下就想到。我們基本上都會從以下步驟入手:

  • 一、儘可能搞清楚問題的前因後果
  • 二、有誰在?
  • 三、之前發生了什麼?
  • 四、現在在執行的程序是啥?
  • 五、監聽的網路服務
  • 六、CPU 和記憶體
  • 七、硬體
  • 八、IO 效能
  • 九、掛載點 和 檔案系統
  • 十、核心、中斷和網路
  • 十一、系統日誌和核心訊息
  • 十二、定時任務
  • 十三、應用系統日誌
  • 結論

防“炸”手冊

Web如何應對流量劫持?

雖然網際網路經過多年的發展,可是網站使用的底層協議仍是 HTTP,HTTP 作為一種明文傳播協議,所有的傳輸資料都是明文,我們都知道在通訊中使用明文(不加密) 內容可能會被竊聽,同時網站存在被劫持的風險。

面對多種方式的網站劫持,我們應該如何應對?

Web網站壓力及效能測試

在專案上線之前,都需要做壓力測試,目的是看下我們的網站能抗住多少的壓力,能承擔多少併發,如果不做壓力測試,一旦出現大訪問量時,我們的網站會掛掉。

應該對什麼告警?

沒有多少系統的告警是設計得當的。良好的告警設計是一項非常困難的工作。如何知道你收到的告警是糟糕的?多少次你收到了告警之後,立即就關掉了的?是不是成天被這些然而並沒有什麼卵用的東西給淹沒?最常見的告警設定:cpu使用率超過90%,然後告警。這種設定在大部分場合下是沒有辦法提供高質量的告警的。

高質量的告警應該是這樣的:每次收到之後你可以立即評估影響的範圍,並且每一個告警需要你做出分級響應。所謂每個告警都應該是,actionable的。

防雪崩利器:熔斷器 Hystrix 的原理與使用

分散式系統中經常會出現某個基礎服務不可用造成整個系統不可用的情況,這種現象被稱為服務雪崩效應。為了應對服務雪崩,一種常見的做法是手動服務降級。而Hystrix的出現,給我們提供了另一種選擇.

如何不讓一個慢查詢把伺服器搞冒煙

直接說解決方案吧:

  • 縮小查詢範圍,由之前的查詢3天改為查詢1天,量級降到130w 資料。
  • 強制使用索引,一定程度上縮短查詢時間。
  • 寫個指令碼,定時將查詢結果儲存到memcache裡,這個主要是防止高併發情況下,等待寫入mc時造成短時間大量資料庫訪問。
  • 對資料庫讀取結果做快取。
  • 對介面結果做快取。

做了這5步工作,媽媽再也不用擔心我的伺服器會冒煙啦~~

web 安全入門

搞 Web 開發離不開安全這個話題,確保網站或者網頁應用的安全性,是每個開發人員都應該瞭解的事。本篇主要簡單介紹在 Web 領域幾種常見的攻擊手段。

  1. Cross Site Script(XSS, 跨站指令碼攻擊)
  2. SQL Injection (SQL 注入)
  3. Distributed Denial of Service (DDoS, 分散式拒絕服務)
  4. Cross Site Request Forgery (CSRF, 跨站請求偽造)

IT運維必備技能

  • Linux基礎
  • 運維的命令
  • 基礎服務:
  • 安全
  • 指令碼
  • 運維平臺工具 (中級)
  • 網路 (中高階)
  • 底層 (大神級)
  • 其它: 素養/處理方式

    • 安全
    • 責任心
    • 細心
    • 推進/改善
    • 進取心/不斷學習
    • 好記性不如爛筆頭
    • 團隊知識庫

簡單暴力使用 iptables 保護你的伺服器

很多【壞人】僅靠埠掃描就攻破了很多使用者的主機,大量的主機淪為不法分子的肉雞,在網路上充當不法行為的跳板。

而多數這些【被利用】主機的主人,往往都是安全意識不夠,滿滿的僥倖心理,或者技術觀念不強導致的。

而防範大多數攻擊其實並不是什麼非常困難的問題,最簡單的 iptables 防火牆規則,往往就能幫助你防範非常多的安全問題。

使用 NGINX 流控和 fail2ban 防止 CC 攻擊

CC 攻擊:攻擊者通過建立大量請求導致伺服器資源耗盡,主要針對特定服務介面,屬於實現 DoS 攻擊的一種方式(DoS 攻擊更多是針對網路埠,而不是具體服務介面)。

負載均衡中使用Redis實現共享Session

負載均衡:把眾多的訪問量分擔到其他的伺服器上,讓每個伺服器的壓力減少。

如我們第一次訪問 www.baidu.com 這個域名,可能會對應這個IP 111.13.101.208的伺服器,然後第二次訪問,IP可能會變為111.13.101.209的伺服器,這就是百度採用了負載均衡,一個域名對應多個伺服器,將訪問量分擔到其他的伺服器,這樣很大程度的減輕了每個伺服器上訪問量。

但是,這裡有一個問題,如果我們登入了百度的一個賬號,如網頁的百度網盤,但是每次有可能請求的是不同的伺服器,我們知道每個伺服器都會有自己的會話session,所以會導致使用者每次重新整理網頁又要重新登入,這是非常糟糕的體驗,因此,根據以上問題,希望session可以共享,這樣就可以解決負載均衡中同一個域名不同伺服器對應不同session的問題。

伺服器效能優化的正確姿勢

運維工作中除了要維持平臺的穩定執行以外,還得對伺服器的效能進行優化,讓伺服器發揮出良好的工作效能是穩定執行的基礎。騰訊互娛DBA團隊的汪偉(simon)在這一領域裡整理出了一套效能優化的資料為大家在效能優化提供充足的方向。

簡單幾步讓伺服器更安全

對於愛折騰的人來說,在自己的伺服器上搭建部落格是一件很有趣的事情,但從頭開始配置伺服器,完成部落格部署並非一件易事,使用或者配置不恰當更是可能引起伺服器的安全隱患。本文參考了 DigitalOcean 的一篇文章 [1] ,介紹幾個簡單的增強伺服器安全性的方法,希望對你有所幫助。

黑客別動我! 50 個系統防範新方法

本期完
:)


歡迎關注 SegmentFault 微信公眾號 🙂