标签： 云服务器

预算每月 50 刀
用来 LoL 指点 观战6 条回复 • 2021-09-15 16:37:35 +08:00
Puteulanus 1
Puteulanus 22 天前
以前用 AWS 的显卡 EC2 串流打过 GTA，不需要长时间使用的话可以看看竞价机型，价格会比正常的实惠很多
cjpjxjx 2
cjpjxjx 22 天前
某宝搜挂机宝，650 显卡机器的机器一个月一百多
binux 3
binux 22 天前 via Android
gforce now + 个便宜的 VPS ？
pacexy1 4
pacexy1 22 天前
感谢楼上各位的回复，这些方案我都看了下，因为需要长期托管，也不需要太高的稳定性，感觉还是远程主机比较合适
fengci 5
fengci 15 天前
https://start.qq.com/index.html
rosees 6
rosees 14 天前
@fengci 这个东西不能用来挂机，主机掉线云端基本马上掉

*近没事儿就够购买了台阿里云虚拟服务器，本想安装个 wordpress 研究一下网站部署。没想到一起都部署好了，晚上吃完饭回来就无法访问了。通过工单平台提交了问题，大概一个小时工程师反馈查不到 IP 地址。由于晚上正在打排位赛，计划第二天解决。

早上起来后，就继续和客服反馈，客服查了半天就给了我官方的回答

您好，您购买的虚拟主机是 h 海外服务器，服务器会经过国际链路和运营商国际路由节点，会受到到国际链路拥塞，以及运营商出境路由限制，部分大陆地区容易出现网络链路拥塞，访问不稳定，甚至无法正常访问的情况。跨境连接访问无法连接的现象时有发生，这个目前还没有较好的办法完全避免掉。

如果是小白肯定就接受了，但是有经验的人就能品味出推卸责任。也是我用 aws 上的新加坡和美国的服务器都是测试一下，根本无法访问。

客服只能继续解决，折腾了一段时间后，又给我了官方回答

您好，这边后台查看您服务器 x.x.x.2x 于 2021-07-24 21:52:55 遭受 ddos 攻击进行黑洞，默认的黑洞时长是 2.5 小时，黑洞期间不支持解封；实际黑洞时长视攻击情况而定，从 30 分钟到 24 小时不等；触发黑洞后会对被黑洞的服务器外网限制。黑洞时间结束后如果系统探测到大流量攻击仍然持续，还会继续黑洞处理，如果攻击停止，系统会自动解封。

我的天，刚购买的服务器就遇到这个问题，阿里云也太坑了吧

黑洞 服务器 国际链路 访问44 条回复 • 2021-07-30 18:43:25 +08:00
scukmh 1
scukmh 15 天前
想起来某学长对我说过的一句话，别人有没有问题？如果别人没问题的话，那就是你自己的问题。
dorothyREN 2
dorothyREN 15 天前
被 DDOS 跟阿里雲有什麼關係。
wangdazhitech 3
wangdazhitech 15 天前
@dorothyREN 刚购买服务器就 DDOS，也太搞笑了吧。aws 和腾讯云从来没有遇到过这个问题
dorothyREN 4
dorothyREN 15 天前 ❤️ 4
@wangdazhitech #3 只能說你還沒碰到，不表示沒有這個問題
dorothyREN 5
dorothyREN 15 天前
@dorothyREN #4 另外，阿里雲是真的垃圾。
eason1874 6
eason1874 15 天前
确定不是你的原因引起，可以要求更换 IP，换一个干净 IP 应该就没问题了
Rheinmetal 7
Rheinmetal 15 天前
@dorothyREN 之前这个 ip 是干菠菜等容易被 d 的
回收给你用就倒霉了
levelworm 8
levelworm 15 天前
云服务无非就是现代的 Mainframe 。知道云服务商会怎么搞了吧。
delectate 9
delectate 15 天前 ❤️ 27
#1 的语言真恶毒，和我遇到的那些校园霸凌却袒护坏孩子的老师一模一样：
“他怎么只打你，不打别人？你照照自己的原因”

所以，在此，我非实名的正式郑重反对 1 楼的言论。

再说说阿里云，之所以它叫套路云、坑爹云，是黑历史满满的：
1 、价格贵（都比腾讯云贵得多）
2 、套餐差（各种搭配不合理）
3 、套路多（宣传永久免费，分分钟收你费用，而且贵上天）
4 、稳定性差（看楼主的遭遇）
5 、接入困难（此处专指某些物联网套件，明明有轮子，非要自己重造一套，而且和任何标准不兼容，你爱用不用）
6 、恶意收费（暂时没办法印证，只是亲身经历。刚买几天 ok，突然间就出现了所谓的 ddos 、共计，不买他们的防火墙套餐就永久封禁状态，买了之后马上可用。以为是个人个案，后来发现很多人都有这个遭遇，不得不怀疑，他们居心叵测！）
7 、抄袭成瘾（自己没有 ip 库？抄一个 ipip 的！）

综上，要么用国外的大厂比如 linode 、vultr，要么用良心云，总而言之别用阿里。
wangbenjun5 10
wangbenjun5 15 天前
阿里云为了节省成本对于资源也是划分级别的，对于大客户分配优质资源保证质量，对于那些散户就没那个待遇的，出点问题正常。

SgtPepper 11
SgtPepper 14 天前 ❤️ 3
这个站确实很多人嘴巴很毒 碰到过很多次了 就不知道网上嘴巴这么毒生活中也这样？
SgtPepper 12
SgtPepper 14 天前
我买过腾讯云的轻量云香港节点，挺便宜一年 300 多好像，刚买那几天碰到过高峰 ping 不通。找客服要求换 IP，谁知道客服说轻量云不支持换 IP 。。。

好在后续这台服务器还算给力，很少有 ping 不通的情况了。

如需购买轻量云的朋友可要注意了。。
stimw 13
stimw 14 天前 via Android
@delectate 腾讯除了便宜点其他也没什么区别。。。有些甚至更甚。国内云服务都一个鸟样。
hazy 14
hazy 14 天前
估计是开到了别人被打之后刚换下的 IP ？
opengps 15
opengps 14 天前
你这个问题，在任何一家服务商都会有同样的情况出现
gamexg 16
gamexg 14 天前
> 通过工单平台提交了问题，大概一个小时工程师反馈查不到 IP 地址
> 跨境连接访问无法连接的现象时有发生，这个目前还没有较好的办法完全避免掉。
> 这边后台查看您服务器 x.x.x.2x 于 2021-07-24 21:52:55 遭受 ddos 攻击进行黑洞

三次回答理由完全不一样
iseki 17
iseki 14 天前
虽然反对一楼的逻辑混乱发言，但是你这个问题多半是开到有问题的 IP 了，小厂还能和客服商量商量，阿里这种···
henvm 18
henvm 14 天前
虚拟主机不是独立 IP 吧，是共享 IP 吧，估计是其他的用户的网站被 DDOS 了，导致这个 IP 被黑洞了
ttyn 19
ttyn 14 天前
好像可以 3 天无理由退款
kiddyu 20
kiddyu 14 天前
*近一段时间阿里云的网络就是有很大问题，国内连不上国外、国外连不上国内
proxychains 21
proxychains 14 天前 ❤️ 4
@scukmh 你被强暴了但是发现大街上很少有人被强暴的经历,此时要不要考虑下是不是自己的问题?
sakuraSou 22
sakuraSou 14 天前 via iPhone
@scukmh 什么伟人学长?
yanzhiling2001 23
yanzhiling2001 14 天前
轻量云路过，有几次被攻击 + 被波及污染，都发工单给免费解决了
guanyin8cnq12 24
guanyin8cnq12 14 天前
你需要良心云 vultr，https://vps.gitbook.io/discount/
swulling 25
swulling 14 天前
阿里的客服为了降低成本，都是外包，一个月几千块，懂个 P 的云，基本上只能照搬手册。

但是说实话，一个懂业务的高级客服，月工资怎么也得上万。说句难听的，你月消费只有几千块，别人都懒得搭理你。

公有云上的小客户，纯粹就是为了教育市场，养成潜在客户的使用习惯的。
lscho 26
lscho 14 天前 ❤️ 4
“如果是小白肯定就接受了，但是有经验的人就能品味出推卸责任”

你这句话说反了，如果有经验的人就知道这是事实，只有小白才会不接受。

不管你什么时间买的服务器，ip 还是之前别人用过的 ip，机房还是那个机房，运营商还是那个运营商。

国际节点容易出问题是事实，你的 ip 持续被人攻击也是有可能的，甚至上用这个 ip 的人。

无非是你运气不好，刚开就遇到了，这没得办法，只能换一个了。
jiuhuicinv 27
jiuhuicinv 14 天前 ❤️ 2
无理由退款再开
jeeyong 28
jeeyong 14 天前
亲, 改成弹性公网 IP, 然后换一个 IP 不可以嘛?
AngryPanda 29
AngryPanda 14 天前 via iPhone
@kiddyu 不是阿里云的问题，我们托管在网易的服务器也这样
murmur 30
murmur 14 天前
ddos 是倒霉，国内的服务器只要 ddos 要么高防要么拒*服务，就是不跟你玩了
cco 31
cco 14 天前
@wangdazhitech 之前买 linode 、vultr 、DO 基本上开机就被攻击，很正常，和服务商没什么关系。开启后还是得配置好安全策略。防火墙，fail2ban 之类的还是有些用的。
xuanbg 32
xuanbg 14 天前
楼主还是图样，有经验的直接就退款了。
haiyan 33
haiyan 14 天前
香港的买 10 个能有 3 个能用就算运气好，这些 IP 还不是我们自己搞坏的
wangyzj 34
wangyzj 14 天前
晚上正在打排位赛

很真实
oldphper 35
oldphper 14 天前
/t/789633 换个 IP 试试？或者试试腾讯云轻量？
vueli 36
vueli 14 天前
你刚买服务器就被 ddos????? 你这个黑洞我遇到过. 我自己的服务器做压测的时候就被自己搞成黑洞了
killerv 37
killerv 14 天前
@scukmh 「为什么期末考试别人都过了，就你挂了？」这个时候你可以按照你学长的话理解；
「为什么大街上别人都没被强奸就你被强奸了？」你还能这么理解？你那个学长的话只在某些场景下是适用的，你就当做人生信条了。。。
zhurong 38
zhurong 13 天前
*近被 ddos 的有点多，有好多客户的 eip 被黑洞清洗
wangdazhitech 39
wangdazhitech 13 天前
@jiuhuicinv 这是个非常好的办法
wangdazhitech 40
wangdazhitech 13 天前
@xuanbg 的确是，之前都是帮公司购买的云服务器，没有考虑过成本，遇到问题都是找大客户经理。如今自己搞，才遇到这个问题
wangdazhitech 41
wangdazhitech 13 天前
@wangyzj *近小学生有些多，比较难打
proxychains 42
proxychains 13 天前 via Android
@wangdazhitech 快进到打一夜没拿到首胜
scukmh 43
scukmh 10 天前
啊，不好意思，这句话有个上下文，是在我买了某云服务器后装一个软件死活装不上的情况下。我学长对我说的。 @killerv @proxychains @SgtPepper @delectate
cherryas 44
cherryas 9 天前
@wangdazhitech 那只是你没遇到罢了。 我之前用腾讯云的 vps 也遇到过刚开机就进黑洞的。

http://www.gzidc.com ， 这个网站上的服务器和虚拟机怎么样啊，靠谱么

gzidc 服务器 中心 数据8 条回复 • 2017-11-20 15:14:45 +08:00
isCyan 1
isCyan 2017-11-20 11:28:25 +08:00 via Android
关于配合公安部“一键关停”应急演练行动通知
codeeer 2
codeeer 2017-11-20 11:29:34 +08:00 via iPhone
关于配合公安部“一键关停”应急演练行动通知
xidadada 3
xidadada 2017-11-20 13:13:43 +08:00
关于配合公安部“一键关停”应急演练行动通知
xidadada 4
xidadada 2017-11-20 13:13:59 +08:00
http://www.gzidc.com/FrontCms/getArticleShow/cat_id/33/art_id/997.html
stabc 5
stabc 2017-11-20 13:26:07 +08:00
>此次“一键关停”专项行动为公安机关的应急演练，被关停的网站将在关闭后 2 小时内恢复。

牛逼！！！！
SourceMan 6
SourceMan 2017-11-20 13:28:02 +08:00
看楼上，不靠谱，大家注意远离这个云服务商
（感觉楼主做了一波负面的 SEO，真是 666，还没法删帖）
est 7
est 2017-11-20 14:47:24 +08:00
关于配合公安部“一键关停”应急演练行动通知
SakuraKuma 8
SakuraKuma 2017-11-20 15:14:45 +08:00
那个，我想说，不是正常吗。
那天很多 IDC 都要啊。
https://www.google.com/search?q=%E4%B8%80%E9%94%AE%E5%85%B3%E5%81%9C&oq=%E4%B8%80%E9%94%AE%E5%85%B3%E5%81%9C&aqs=chrome..69i57.20508j0j7&sourceid=chrome&ie=UTF-8

我搞了个小程序，上周五的时候，用户只有几百。 今天日打开次数达到了一百多万，api 调用量 200 多万，数据库数据几个表合计上百万条。 今天下午的时候，云服务商没承受住压力，宕机了。 其实昨天晚上我就在筹备，备个腾讯云的版本出来，但是昨天的访问量 30 万，我想，不至于吧，明天会上百万？ 而且我对服务器的了解不是很多，一直在搞前端和移动端的工作，参与的后端接口开发，只是接口开发，没碰过部署及运维之类的工作。

现在恨只恨自己技术太渣，这样的量级该怎么配置服务器都不知道。 希望大家给个建议。

现在的量级：今天是两百万级别的 api 调用量，预计本周内达到千万级，顶点在哪儿我不知道。

对于该如何配置服务器，希望大家给个建议。

拜托了！

API 服务器 量级 调用8 条回复 • 2018-04-27 17:33:58 +08:00
subliyou 1
subliyou 2018-01-17 22:24:52 +08:00
好吧，沉了。。。
GooMS 2
GooMS 2018-01-17 23:26:01 +08:00 via Android
单纯的请求数没有意义，要根据业务取舍调整。不过大体的手段也就那几种，简单到上缓存。
CEBBCAT 3
CEBBCAT 2018-01-17 23:38:53 +08:00 via Android
哇噻，楼主这是什么小程序？你这 API 大体是干嘛的？是 IO 不够吗？
subliyou 4
subliyou 2018-01-18 16:23:09 +08:00
已经委托云服务商在解决了。他们比我专业，希望可以挺过去。
@GooMS
@CEBBCAT
whx20202 5
whx20202 2018-01-19 14:18:26 +08:00
@subliyou 可以性能分析一下瓶颈在哪里
gomars 6
gomars 2018-02-01 09:08:53 +08:00
是什么小程序这么火
miqiqi 7
miqiqi 2018-02-17 10:32:10 +08:00
https://s1.ax1x.com/2018/01/21/pRh5VA.jpg
顶住了
iamdqncoder 8
iamdqncoder 2018-04-27 17:33:58 +08:00 via Android
什么小程序。。这么恐怖的吗。。

越来越多企业选择将业务部署到云环境中，并不是意味着每个人都应采用云环境，而是因为它是一种更灵活处理 IT 资源的*佳方法。由于无需备案、CN2 高速访问等优势，越来越多意图开拓跨境外贸市场的企业将其在线业务转移到恒创科技香港云服务器。但是，尽管云服务器在适应性、灵敏性和可用性方面具有优势，但其实你在将业务迁移至云服务器时要考虑以下因素：

一、迁移准备

在为将大规模业务迁移至云服务器做准备的时候，你需要考虑的是：你的公司员工是否了解这项重大举措的风险?你的员工是否具备管理全新的云服务器、云环境的知识和技能?此外，由于大规模迁移包含大量的数据和信息，你的安全框架是否在迁移期间能够规避潜在的安全隐患? 你的团队能否应对将资源放入云服务器中从而引起的变化?

二、迁移目的

将业务迁移至云服务器背后的目的：作为业务所有者，您应该对 “为什么要将业务迁移到云服务器” 背后的解释及其含义具有明确的了解。*有说服力的原因是：需要满足您的业务不断增长的对 IT 资源弹性分配的需求，这将促使更显著的盈利能力。其他原因可能包括：权威性举措的差异或需要重新校准库存的业务结构的变化。

三、云迁移的成本问题

不同的企业团队使用不同的成本计算方法。对少数人来说，由于业务规模较大，一次性投入大量资金来订购云服务器，从长远来看，是一种风险投资，他们希望对 IT 资源进行无限制的监督。但对其他人来说，难以接受一次性的入门成本，因此仅采用渐进式的云环境解决方案，运营成本更加合适。对于在一个月到一个月的前提中不断变化的 IT 资源需求场景下，这种选择可能非常合理，因为传统的服务器租用服务无法为他们提供这样快速灵活的适应性。无论采用哪种方法，在选择通常合适的云服务器之前，都必须考虑一下特定成本。*好的选择是从配置较低的低端云服务器开始入门，根据你的工作负载，按需扩展云服务器配置来应对日趋繁忙的流量高峰。

业务迁移到云服务器要考虑哪些因素

四、安全性和可用性

由于明显的安全性和可访问性问题，将您的大多数重要数据和信息移交给开放式的云服务器供应商可能会不堪重负。你需要确定你选择的云服务器供应商必须遵守严格的数据保护和保密约定，并且由于云服务器供应商拥有更多可访问的资源，因此与本地企业相比，它们可以实现并保持更高的安全级别。

五、迁移的必要性

在迁移到云服务器时，您需要关注每一个细微的地方，例如，哪些特定的数据、服务器或应用程序应当重新部署?您的业务是否需要大规模完全迁移，还是将您的一小部分数据迁移到云中?或者你是否可以将数据库放在本地存储，而将应用程序等计算性能交由云服务器供应?或许某些需求，在不需要迁移到云服务器的情况下就能得到解决。

六、IT 员工的顾虑

IT 环境中的任何变化都会使员工感到焦虑。您可能会这种转变会带来直接或间接的利益和技术优势，但真正的问题在于日后管理云服务器和云环境下所有应用和数据的 IT 团队。你需要确定你的 IT 团队已经具备完全无碍地管理云服务器和内部数据的技能和知识，你需要确保他们接受合理的培训，并为迁移过程中出现的任何问题预备解决方案。

七、日志分析和指标收集

将业务迁移到云服务器的企业*终不得不应对新的环境和条件，这需要另一种日志检查和指标收集。或许之前你经常遇到的服务器问题，在迁移到云服务器后将完全消失，或者以前在传统服务器上没有遇到的问题，在迁移到云服务器之后会出现新的困难和挑战。总之，你需要为这些适应全新环境而产生的不可控因素提前做好准备。

总之，公共云服务器的明显缺点是安全风险和控制失控。云服务器集成的众多智能化的一键式操作，在提升工作效率和智能化程度的同时，也很容易在 IT 员工的误操作之下造成恶劣影响。到目前为止，大多数支持云服务器的企业，都将获得更高的安全性、灵活性和可用性。但关键在于你的团队能够准备合理的运用云服务器并充分发挥其独特优势。

导语：现在云服务器是很多用户会选择的网站空间，和传统的服务器相比，云服务器出现的时间相对较短，有些技术性的问题可能还有用户不太清楚，下面我们看一下在使用中，云主机会出现的问题。

Linux云服务器数据盘如何进行分区和格式化
新购买的Linux云服务器，数据盘必须做分区和格式化才能使用，否则是无法正常使用的。Linux云服务器数据盘格式化可以通过脚本格式化和手动格式化两种方式进行。

（1）格式化后，数据盘中的数据会被全部清空。所以在格式化之前，一定要确保数据盘中没有数据或对重要数据已进行备份。

（2）为避免服务发生异常，格式化前请确保云服务器已停止对外服务。

云服务器如何重启
（1）只有状态为“运行中”的服务器，才能够进行重启。

（2）云服务器重启期间，将无法正常提供服务，因此在重启之前，确保云服务器已暂停业务请求。

点击要重启的云服务器后的“重启”按钮，弹出“重启服务器”弹框，确认后点击“确定”，即可进行重启。

我们团队为Ucloud云计算服务提供专家技术支持,每天都要碰到无数的用户故障,毕竟IAAS涉及比较底层的东西,不管设计的是大客户也好还是小客户,有了问题就必须要解决,也要要是再赶上修复时间紧、奇葩的技术平台、缺少信息和文档，基本上这过程都会惨痛到让我们留下深刻的记忆。也记录一点心得供各位奋斗在一线的运维人员提供一点帮助

遇到服务器故障，问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手：

一、尽可能搞清楚问题的前因后果
不要一下子就扎到服务器前面，你需要先搞明白对这台服务器有多少已知的情况，还有故障的具体情况。不然你很可能就是在无的放矢。

必须搞清楚的问题有：

故障的表现是什么？无响应？报错？

故障是什么时候发现的？

故障是否可重现？

有没有出现的规律（比如每小时出现一次）

*后一次对整个平台进行更新的内容是什么（代码、服务器等）？

故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)?

基础架构（物理的、逻辑的）的文档是否能找到?

是否有监控平台可用? （比如Munin、Zabbix、 Nagios、 New Relic… 什么都可以）

是否有日志可以查看?. （比如Logstack系统笔记的云日志服务）

*后两个是*方便的信息来源，特别是日志系统,作为运维人员要善于和擅长查看日志,日志往往是你在没有头绪的时候给你*大的帮助,其实很多问题都在日志系统中暴露出来,比较方便的是使用系统笔记

二、有谁在?
$ w
$ last
用这两个命令看看都有谁在线，有哪些用户访问过。这不是什么关键步骤，不过*好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。（ne cook in the kitchen is enough.）

三、之前发生了什么?
$ history
查看一下之前服务器上执行过的命令。看一下总是没错的，加上前面看的谁登录过的信息，应该有点用。另外作为admin要注意，不要利用自己的权限去侵犯别人的隐私哦。

到这里先提醒一下，等会你可能会需要更新 HISTTIMEFORMAT 环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令，同样会令人抓狂的。

四、现在在运行的进程是啥?
$ pstree -a
$ ps aux
这都是查看现有进程的。 ps aux 的结果比较杂乱， pstree -a 的结果比较简单明了，可以看到正在运行的进程及相关用户。

五、监听的网络服务
$ netstat -ntlp
$ netstat -nulp
$ netstat -nxlp
我一般都分开运行这三个命令，不想一下子看到列出一大堆所有的服务。netstat -nalp倒也可以。不过我*不会用 numeric 选项 （鄙人一点浅薄的看法：IP 地址看起来更方便）。

找到所有正在运行的服务，检查它们是否应该运行。查看各个监听端口。在netstat显示的服务列表中的PID 和 ps aux 进程列表中的是一样的。

如果服务器上有好几个Java或者Erlang什么的进程在同时运行，能够按PID分别找到每个进程就很重要了。

通常我们建议每台服务器上运行的服务少一点，必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着，那还是做个记录，回头有空的时候清理一下，重新组织一下服务器。

六、CPU 和内存
$ free -m
$ uptime
$ top
$ htop
注意以下问题:

还有空余的内存吗? 服务器是否正在内存和硬盘之间进行swap?

还有剩余的CPU吗? 服务器是几核的? 是否有某些CPU核负载过多了?

服务器*大的负载来自什么地方? 平均负载是多少?

七、硬件
$ lspci
$ dmidecode
$ ethtool
有很多服务器还是裸机状态，可以看一下：

找到RAID 卡 (是否带BBU备用电池?)、 CPU、空余的内存插槽。根据这些情况可以大致了解硬件问题的来源和性能改进的办法。
网卡是否设置好? 是否正运行在半双工状态? 速度是10MBps? 有没有 TX/RX 报错?

八、IO 性能
$ iostat -kx 2
$ vmstat 2 10
$ mpstat 2 10
$ dstat –top-io –top-bio
这些命令对于调试后端性能非常有用。

检查磁盘使用量：服务器硬盘是否已满?

是否开启了swap交换模式 (si/so)?

CPU被谁占用：系统进程? 用户进程? 虚拟机?

dstat 是我的*爱。用它可以看到谁在进行 IO： 是不是MySQL吃掉了所有的系统资源? 还是你的PHP进程?

九、挂载点 和 文件系统
$ mount
$ cat /etc/fstab
$ vgs
$ pvs
$ lvs
$ df -h
$ lsof +D / /* beware not to kill your box */
一共挂载了多少文件系统?

有没有某个服务专用的文件系统? (比如MySQL?)

文件系统的挂载选项是什么： noatime? default? 有没有文件系统被重新挂载为只读模式了？

磁盘空间是否还有剩余?

是否有大文件被删除但没有清空?

如果磁盘空间有问题，你是否还有空间来扩展一个分区？

十、内核、中断和网络
$ sysctl -a | grep …
$ cat /proc/interrupts
$ cat /proc/net/ip_conntrack /* may take some time on busy servers */
$ netstat
$ ss -s
你的中断请求是否是均衡地分配给CPU处理，还是会有某个CPU的核因为大量的网络中断请求或者RAID请求而过载了？

SWAP交换的设置是什么？对于工作站来说swappinness 设为 60 就很好, 不过对于服务器就太糟了：你*好永远不要让服务器做SWAP交换，不然对磁盘的读写会锁死SWAP进程。

conntrack_max 是否设的足够大，能应付你服务器的流量?

在不同状态下(TIME_WAIT, …)TCP连接时间的设置是怎样的？

如果要显示所有存在的连接，netstat 会比较慢， 你可以先用 ss 看一下总体情况。

你还可以看一下 Linux TCP tuning 了解网络性能调优的一些要点。

十一、系统日志和内核消息
$ dmesg
$ less /var/log/messages
$ less /var/log/secure
$ less /var/log/auth
查看错误和警告消息，比如看看是不是很多关于连接数过多导致？

看看是否有硬件错误或文件系统错误?

分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。如果你有多台机器,看起来很不方便,可以事先把日志存储在系统笔记的云日志服务器上,支持全文模糊查找,

十二、定时任务
$ ls /etc/cron* + cat
$ for user in $(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done
是否有某个定时任务运行过于频繁?

是否有些用户提交了隐藏的定时任务?

在出现故障的时候，是否正好有某个备份任务在执行？

十三、应用系统日志
这里边可分析的东西就多了, 不过恐怕你作为运维人员是没功夫去仔细研究它的。关注那些明显的问题，比如在一个典型的LAMP（Linux+Apache+Mysql+Perl）应用环境里:

Apache & Nginx; 查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。

这里查看了下,并没有503的,只有403的错误.所以可以跳过

MySQL; 在mysql.log找错误消息，看看有没有结构损坏的表， 是否有innodb修复进程在运行，是否有disk/index/query 问题.

PHP-FPM; 如果设定了 php-slow 日志, 直接找错误信息 (php, mysql, memcache, …)，如果没设定，赶紧设定。

Varnish; 在varnishlog 和 varnishstat 里, 检查 hit/miss比. 看看配置信息里是否遗漏了什么规则，使*终用户可以直接***你的后端？

HA-Proxy; 后端的状况如何？健康状况检查是否成功？是前端还是后端的队列大小达到*大值了？

结论
经过这5分钟之后，你应该对如下情况比较清楚了：

在服务器上运行的都是些啥？

这个故障看起来是和 IO/硬件/网络 或者 系统配置 (有问题的代码、系统内核调优, …)相关。

这个故障是否有你熟悉的一些特征？比如对数据库索引使用不当，或者太多的apache后台进程。

你甚至有可能找到真正的故障源头。就算还没有找到，搞清楚了上面这些情况之后，你现在也具备了深挖下去的条件。继续努力吧！