相信小伙伴们在上网或者玩游戏的时候一定都遇到过无法访问的情况。“服务器炸了”的原因有各种各样，下面就让我们来了解一下吧~
运维：为什么受伤的总是我
知己知彼，百战不殆，了解一下过去那几年我们所经历过的各种不可抗离奇事件吧。
- 一、空调，挥之不去的噩梦
- 二、易断的缆线
- 三、硬件造成的网络中断
- 四、波及全国的DNS根域问题
- 五、地方流量劫持
- 六、杀毒软件等拦截
- 七、DDoS
得出的最大教训就是：云服务器太不稳定了，要以数量取胜，不能同一机柜。有一次别人的云服务器被攻击，提供商竟然重启了物理机..然后又诸多悲剧出现。最大的感恩就是：学到了很多知识。每次事故服务器我都要被迫亲自参与修复，本来不那么熟悉的，一下子被强迫做了很多事情。
该项目是一个微信转盘游戏抽奖营销项目，由于运营营销时间要求紧迫，开发测试部署上线用了10天不到，有些准备工作并没有到位。
虽然在家休着但闲着无事打开监控系统看着有啥问题没。看了没几分钟，运维同学打电话来，说“上次你说想要的现场来了，连接数又上来了”，马上登上数据库机器查看，cpu usage, load average值跟上次故障如出一辙；但这次有所不同，一是已经有了上次的经验，二是运维同学这次没在高速的半路上，可以一起及时处理。
B站运维痛点主要有3个：人手不足、故障多、运维系统跟不上，针对这三个痛点，B站采用了三种方式进行破冰。
又是一年国庆，10月8日12点，鹿晗在微博公布与关晓彤恋情，截至当日14:50, 该微博共收获462,884次转发、986,409条评论，2,566,617个点赞。造成微博服务短暂不可用。作为运维同行，对此深表同情和理解。
服务器：稳住！
今天给大家带来《构造高可靠海量用户服务-SNG数亿级日活跃业务后台核心技术揭秘》，一起探讨怎么从可用性的维度提升海量服务的可靠性及海量服务的故障处理方式，包括：
- SNG后台架构的概览；
- 面向海量服务的设计原则。腾讯海量服务的后台设计一般通用的解决方案是什么，包括如何提升海量服务的高可用性，如何从架构层、产品层、运维层提升服务的合理性；
- 后台服务故障解决思路
饿了么成立于2008年，2014年底开始迎来业务的大规模爆发性增长，2015-2016年饿了么进入高速发展期，业务和服务器的增长都在数十倍的规模，这种大规模的增长必然带来很多挑战，本文将通过饿了么运维基础设施的进化史和大家分享不同时期应对挑战的措施和思路。
今天和大家分享一下我在公司业务方面故障排查遇到的一些坑，以及进行性能调优的解决方法。
互联网系统7*24小时不分昼夜的为人民服务，那么这样长时间服务的背后究竟有哪些手段保证呢？这其中包括软硬件，及基础设施的保障。IT人的努力：
- 分布式系统
- IDC
- 高可用软件
- 存储
- 设备
- 电力
为什么炸了？
面对大规模系统工程，看Facebook如何处理故障排查(一）
为了使Facebook的系统在快速变化的情况下保持可靠，专门为其研究了常见的故障模式，并建立抽象理念来解决这些问题。这些理念确保最佳实践应用于的整个基础设施。通过建立工具来诊断问题，并创建一种复盘事故的文化来推动并作出改进，防止未来发生故障。
一个服务器即使有最好的预防措施，但是也会发生一些故障。在停机期间，正确的方式可以迅速解决问题，最大限度地减少故障持续时间。
每一次系统故障多是因为程序运行失败或错误，偶尔也会有因为环境问题，比如：机器掉电、硬件故障、虚拟机错误等。但即便是环境原因引发的系统故障，也是因为程序编写考虑不足导致的。曾经就碰到因为硬盘故障导致服务假死（挂起）引发的系统故障，这就是程序的编写并未考虑硬盘 I/O 阻塞导致的挂起问题。
- 查询路由表(route)
- ping网关(ping)
- 查询DNS服务器(dig)
- 查询DNS解析(nslookup)
- 检查路由(traceroute)
- 检查远程端口是否开放(telnet/nmap)
- 检查本地(服务端)端口监听(netstat)
- 查看防火墙规则(iptables)
- 查看网络带宽使用(iftop)
- 抓取数据包(tcpdump)
- docs
遇到服务器故障，问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手：
- 一、尽可能搞清楚问题的前因后果
- 二、有谁在?
- 三、之前发生了什么?
- 四、现在在运行的进程是啥?
- 五、监听的网络服务
- 六、CPU 和内存
- 七、硬件
- 八、IO 性能
- 九、挂载点 和 文件系统
- 十、内核、中断和网络
- 十一、系统日志和内核消息
- 十二、定时任务
- 十三、应用系统日志
- 结论
防“炸”手册
虽然互联网经过多年的发展，可是网站使用的底层协议仍是 HTTP，HTTP 作为一种明文传播协议，所有的传输数据都是明文，我们都知道在通信中使用明文(不加密) 内容可能会被窃听，同时网站存在被劫持的风险。面对多种方式的网站劫持，我们应该如何应对？
在项目上线之前，都需要做压力测试，目的是看下我们的网站能抗住多少的压力，能承担多少并发，如果不做压力测试，一旦出现大访问量时，我们的网站会挂掉。
没有多少系统的告警是设计得当的。良好的告警设计是一项非常困难的工作。如何知道你收到的告警是糟糕的？多少次你收到了告警之后，立即就关掉了的？是不是成天被这些然而并没有什么卵用的东西给淹没？最常见的告警设置：cpu使用率超过90%，然后告警。这种设置在大部分场合下是没有办法提供高质量的告警的。高质量的告警应该是这样的：每次收到之后你可以立即评估影响的范围，并且每一个告警需要你做出分级响应。所谓每个告警都应该是，actionable的。
分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况，这种现象被称为服务雪崩效应。为了应对服务雪崩，一种常见的做法是手动服务降级。而Hystrix的出现，给我们提供了另一种选择.
直接说解决方案吧：
- 缩小查询范围，由之前的查询3天改为查询1天，量级降到130w+数据。
- 强制使用索引，一定程度上缩短查询时间。
- 写个脚本，定时将查询结果保存到memcache里，这个主要是防止高并发情况下，等待写入mc时造成短时间大量数据库访问。
- 对数据库读取结果做缓存。
- 对接口结果做缓存。
做了这5步工作，妈妈再也不用担心我的服务器会冒烟啦~~
搞 Web 开发离不开安全这个话题，确保网站或者网页应用的安全性，是每个开发人员都应该了解的事。本篇主要简单介绍在 Web 领域几种常见的攻击手段。
- Cross Site Script（XSS， 跨站脚本攻击)
- SQL Injection （SQL 注入）
- Distributed Denial of Service （DDoS， 分布式拒绝服务）
- Cross Site Request Forgery (CSRF， 跨站请求伪造)
- Linux基础
- 运维的命令
- 基础服务：
- 安全
- 脚本
- 运维平台工具 (中级)
- 网络 (中高级)
- 底层 (大神级)
其它: 素养/处理方式
- 安全
- 责任心
- 细心
- 推进/改善
- 进取心/不断学习
- 好记性不如烂笔头
- 团队知识库
很多【坏人】仅靠端口扫描就攻破了很多用户的主机，大量的主机沦为不法分子的肉鸡，在网络上充当不法行为的跳板。而多数这些【被利用】主机的主人，往往都是安全意识不够，满满的侥幸心理，或者技术观念不强导致的。
而防范大多数攻击其实并不是什么非常困难的问题，最简单的 iptables 防火墙规则，往往就能帮助你防范非常多的安全问题。
使用 NGINX 流控和 fail2ban 防止 CC 攻击
CC 攻击：攻击者通过创建大量请求导致服务器资源耗尽，主要针对特定服务接口，属于实现 DoS 攻击的一种方式（DoS 攻击更多是针对网络端口，而不是具体服务接口）。
负载均衡：把众多的访问量分担到其他的服务器上，让每个服务器的压力减少。如我们第一次访问 www.baidu.com 这个域名，可能会对应这个IP 111.13.101.208的服务器，然后第二次访问，IP可能会变为111.13.101.209的服务器，这就是百度采用了负载均衡，一个域名对应多个服务器，将访问量分担到其他的服务器，这样很大程度的减轻了每个服务器上访问量。
但是，这里有一个问题，如果我们登录了百度的一个账号，如网页的百度网盘，但是每次有可能请求的是不同的服务器，我们知道每个服务器都会有自己的会话session，所以会导致用户每次刷新网页又要重新登录，这是非常糟糕的体验，因此，根据以上问题，希望session可以共享，这样就可以解决负载均衡中同一个域名不同服务器对应不同session的问题。
运维工作中除了要维持平台的稳定运行以外，还得对服务器的性能进行优化，让服务器发挥出良好的工作性能是稳定运行的基础。腾讯互娱DBA团队的汪伟（simon）在这一领域里整理出了一套性能优化的资料为大家在性能优化提供充足的方向。
对于爱折腾的人来说，在自己的服务器上搭建博客是一件很有趣的事情，但从头开始配置服务器，完成博客部署并非一件易事，使用或者配置不恰当更是可能引起服务器的安全隐患。本文参考了 DigitalOcean 的一篇文章 [1] ，介绍几个简单的增强服务器安全性的方法，希望对你有所帮助。
本期完
:）
欢迎关注 SegmentFault 微信公众号 :)
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。