专栏名称: SegmentFault思否
SegmentFault (www.sf.gg)开发者社区,是中国年轻开发者喜爱的极客社区,我们为开发者提供最纯粹的技术交流和分享平台。
目录
相关文章推荐
程序员的那些事  ·  北京大学出的第二份 DeepSeek ... ·  16 小时前  
OSC开源社区  ·  Bun ... ·  昨天  
程序员的那些事  ·  印度把 DeepSeek ... ·  3 天前  
程序员小灰  ·  3个令人惊艳的DeepSeek项目,诞生了! ·  2 天前  
程序猿  ·  “我真的受够了Ubuntu!” ·  4 天前  
51好读  ›  专栏  ›  SegmentFault思否

SegmentFault 技术周刊 Vol.39 - 什么!服务器炸了?

SegmentFault思否  · 公众号  · 程序员  · 2017-12-18 08:00

正文

温馨提示: 本文包含大量外部链接,墙裂建议小伙伴们点击 “ 阅读原文 “ 进行阅读。:)

相信小伙伴们在上网或者玩游戏的时候一定都遇到过无法访问的情况。“服务器炸了”的原因有各种各样,下面就让我们来了解一下吧~

运维:为什么受伤的总是我

经历不可抗力是一种什么体验

知己知彼,百战不殆,了解一下过去那几年我们所经历过的各种不可抗离奇事件吧。

  • 一、空调,挥之不去的噩梦

  • 二、易断的缆线

  • 三、硬件造成的网络中断

  • 四、波及全国的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基础

  • 运维的命令

  • 基础服务:

  • 安全

  • 脚本

  • 运维平台工具 (中级)

  • 网络 (中高级)

  • 底层 (大神级)

  • 其它: 素养/处理方式

  • 安全

  • 责任心

  • 细心

  • 推进/改善

  • 进取心/不断学习







请到「今天看啥」查看全文