服务器数量比较少，怎么运维比较好？

运维人员的工作每天基本上都是在检查问题，枯燥但又重要， 要是你的某一个环节出现问题并没有及时发现问题，对于企业来说损失可能非常大，基本上运维人每天的工作我罗列了下，有这几种：

1、负责服务器的硬件配置、软件安装、机房上下架等技术维护工作

2、负责虚拟化技术产品物理机配置、管理和日常运行监控和维护

3、负责独立主机或虚拟应用产品的开通使用、日常维护、故障诊断和排除

4、提供独立主机或虚拟应用客户产品 *** 作和应用方面的技术支持

5、监视分管的服务器，及时发现问题，并积极解决问题

现在信息化数字时代，单靠人工去检查出现错误几率会很大，而且有的运维人还不只管理两台服务器，像我们公司的运维每人至少要管理30台服务器，这样子单靠人工运维耗费的人工成本和时间是非常大的，所以还是推荐你用运维工具吧，比如云帮手（）

1支持跨云商批量管理服务器

2兼容性强大，兼容市面基本所有的云商云主机，兼容 *** 作系统；

3 *** 作简单，可视化界面预览资源、一键修复、一键部署；

4 可以远程登录云主机FTP桌面，处理云主机上的文件；

5监控和资源还有告警功能，这个是挺好的，不用盯着看；

6系统修复功能，这个是挺实用也比较必须的；

7免费使用。总得来说功能还是挺全的，不存在需要又要另外找软件的尴尬。

你好，很高兴回答你这个问题。从运维的角度来讲，服务器的数量少并不意味着我们的运维工作就非常轻松，相反我们更应该重视此阶段的工作。

我们可以从以下几方面来开展我们的运维工作：

1应用服务器

我们可以从当前服务器中找出 至少2个节点装Vsphere虚拟化，建立一个数据中心、集群 ；如果你的服务器有多网卡和SCSI，还可以做一些更高级的应用，如vmotion、负载均衡、高可用等。当虚拟机或服务器故障，可以 实现故障自动转移，有效的避免了单节点的故障，提供服务器的容错率 。

我们可以在新建的虚拟机部署Web、API等各种应用，而且 虚拟机可以在vCenter图形化界面下统一管理 。这一般是中小公司的在服务器方面的解决方案。

当然，我们对docker比较熟悉，可以使用一套docker解决方案，这比Vsphere更能节省一部分资源。当然这个需要的技能要求也比较高，需要我们不断积累。

2数据库服务器

数据库服务器在此我们单独拿出来，是因为数据库对服务器性能、磁盘IO要求比较高，不太建议使用虚拟机，当然这需要根据业务的实际情况来做选择。 数据库我们需要通过一主一从、一主二从的方式实现高可用，来避免数据库单点问 题，我们还可以选择合适的proxy来进行读写分离、读负载均衡等。另外还要考虑数据的本地备份、异地备份，来确保数据可恢复。

3系统监控

当我们在应用服务器和数据库服务器上线一套系统后， 我们需要通过监控掌握从服务器硬件、基础状态、应用、数据库等从下到上的运行状态 ，以便我们能够对告警及时做出响应。考虑到报警的及时性，我们需要监控接入多种报警渠道，如微信、钉钉、邮件、短信等。监控的目的是发现问题、解决访问，因此我们需要踏实的做好这一步，才能为我们的业务保驾护航。

好了，其实不管服务器多少，我们都需要扎实的把基础打好，这样才能以不变应万变面对各种情形。希望我的回答能够帮到你。

题主没有详细说明具体应用系统的功能，比如是否单一的Web服务？有没有微服务、分布式、集群化扩展的潜在需求？

通常来说，建议使用云服务自动化运维。云服务已经成为IT技术的核心基础设施，充分利用云服务带来的d性和分布式优势，赋能自动化运维。

一，自动构建系统

如果需要构建应用，那么就建议配置使用CI/CD持续化集成和自动化部署，比如常用的Jenkins，配置Git代码提交时触发构建，然后自动部署。

二，日志收集处理系统

1，ELK是常见的日志收集管理系统，包括ElasticSearch, LogStash, Kibana三个服务，架构示意图如下：

2，在ELK系统中，Kibana是一个图形化展示工具，配置查询条件，运维人员随时可以搜索指定日志信息，分析处理故障。

三，服务监控

1，云监控CloudMonitor

主流云服务商都将监控功能集成到了基础架构中，以阿里云为例，云监控提供了多种配置，多维度全方位监控。

比如配置CPU使用率到达80%时，自动触发动作，增加服务器实例，同时邮件通知运维人员。

2，应用监控

以监控宝为例，配置服务地址，选择分布在不同地区和运营商的监测点。当监测点不能正常调用配置的服务地址时，将收到警告信息，可以选择邮件、短信、电话等通知方式。

四，潜在的系统扩展需求

1，是否集群化部署？需要AutoScaling自动伸缩吗？

小型化和集群化并不冲突。如果采用集群化部署，可以配置触发条件，满足时自动增加或者释放服务器资源。比如当CPU使用率达到75%或者内存占用率达到75%时，根据配置好的服务器和数量，自动触发。

2，是否使用Docker容器技术？

Docker将应用以及依赖打包到一个可移植的镜像中，可以实现虚拟化，有助于快捷高效的交付应用，结合Docker-compose资源编排，快速实现自动部署更新，不再需要常用的Jenkins构建服务器。

机器数比较小的话，你可以用云的服务器，这样可以节省好多钱。找一个专门的运维，还不如让开发自己来搞，因为机器少运维他也应付得过来。现在都在搞云计算了，把你的机器放上阿里云或者腾讯云，你自己维护好很多，包括网络贷款都很容易扩容。上面这个我说到的只是说建议你如果你已经是自己的机器了。我建议你从我下面所说的来搞。

认为的整个过程的话一般分为三个阶段，第一的话是手工阶段，什么东西都是手工搞。

第2个阶段就是脚本阶段了，本来手工搞的东西全部脚本化。

第3个阶段就是平台化了，平台化了之后，所有东西都在页面上完成系统完成，不需要人工来干预，甚至不用运维来搞。

有一些人说既然认为就是最后的一个阶段，但是这个很不成熟。所以我就不说了。

针对你这个机器数少的，你可以手工认为，或者说用脚本认为都没问题。

在合适的阶段做合适的事情就是最好的。所以我建议你手工运维或者脚本运维。

我们项目用的 wgcloud运维监控系统 ，它前身是开源项目，后来推出的商业版，也有免费版

wgcloud运行很稳定，性能很好，部署和上手容易

wgcloud支持主机各种指标监控(cpu状态/温度，内存状态，磁盘容量/IO，硬盘smart监控，系统负载，网卡流量，硬件系统信息等)，数据可视化，进程应用监控，大屏可视化，服务接口检测，DOCKER监控，自动生成网络拓扑图，端口监控，日志文件监控，web SSH（堡垒机），指令下发执行，告警信息推送（邮件钉钉微信短信等）

可以装虚拟机代替，在同一个局域网情况下

找服务商外包服务，或者网上托管也不贵收费

服务器数量比较少，比如10台服务器，基本可以不设置运维岗位了，后端开发人员 或者架构师就能搞定。

我就是那种曾经在创业的小公司待过的开发人员，开发，运维我都干了。

但是想想如何更科学更高效的运维还是很有必要的。

运维的目的

软件系统的运行时环境：即公司的业务产线，靠它创造业务价值，这个是最核心的功能诉求。

实时监控系统: 任何时候都要对当前公司的产线的压力一清二楚，有问题功能随时解决，有性能问题及时扩容或者回收资源

降低服务器成本：在业务萎缩的情况下，准确评估哪些资源可以回收，降低服务器的支出

这个是当时我认为的运维的三个主要目的。

运维方案

开发半路出家，当时采用的是shell+python+ansible+jekins+elk的方式

首先，我会及时的更新业务产线的物理架构图，根据架构图来规划服务器的资源使用。

比如多少个web服务，数据库多少，zk,kafka,redis集群怎么分布。

集群部署一般是放在多个服务器上的，这个时候ansible就派上用场了。

jekins主要用来自动发布更新程序已经做定时回收磁盘的任务。

elk主要用来做应用的日志系统和监控告警； 可以通过看板随时知道产线的请求数量和并发数量；

以上的运维方案适用于小公司。运维工程师看到了可以补充

搞个zabbix刷

数量少。如果配置好可以虚拟化。然后跑容器

云服务器ecs支持镜像、控制台、API、CLI、远程桌面、系统监控、自动化部署、负载均衡等运维工具。

云服务器 (Cloud Server) 是一种基于互联网技术的服务，允许用户在线使用虚拟机来运行自己的应用程序和存储数据。它是通过远程访问云提供商的数据中心内的硬件资源来实现的，包括 CPU、内存、存储和网络带宽等。

阿里云ECS (Elastic Compute Service) 云服务器支持多种运维工具，具体如下：

1、镜像：支持常用 *** 作系统的预构建镜像，以及用户自定义镜像。

2、控制台：通过web控制台进行创建、配置、管理和监控云服务器。

3、API：通过RESTful API实现对云服务器的自动化管理。

4、CLI：通过命令行接口实现对云服务器的管理。

5、远程桌面：支持通过RDP和VNC连接远程桌面进行 *** 作。

6、系统监控：支持实时监控云服务器的状态，包括CPU、内存、磁盘和网络使用情况等。

7、自动化部署：支持使用脚本自动化部署应用程序。

8、负载均衡：支持使用阿里云SLB实现负载均衡。

云服务器性能三大要素：

云服务器这种产品通常有两个关键维度：CPU和内存。基本上来说，云服务器小型规格为1vCPU和2GB RAM；云服务器中型规格为2vCPU和4GB RAM；云服务器大型规格为4vCPU和8GB RAM。

虽然每一个云服务器都有网络连接性，区别在于云服务提供商如何为其不同规格的云服务器网络带宽打广告。通常你最有可能看到的就是GB以太网连接。

在选择云服务器时，务必确定有多少虚拟服务器可以运行在物理服务器上，以及这个物理服务器该有多少实际的CPU和内存，云服务器实际的网络吞吐量如何，这些决定直接影响你的应用性能。

信息化的发展离不开服务器，像我们访问的各类网站其背后都是有服务器支撑的。而作为网站运营方一般都会将服务器放置在专业的机房进行托管，而很少放在自家或者办公室中，因为专业机房里的环境及标准都是有一定要求的，比如说电力上的保障、带宽稳定性上都具备优势。

但是我们把服务器托管在远程机房后，若服务器出现了问题，有些是需要我们自己解决处理的，而有些只能由机房人员协助处理。下面我整理了服务器可能会出的一些异常及处理方案以供大家参考。

需要由机房处理的异常

1、电力、网络异常

机房的电力及网络都是商业性质的，比民用的要稳定。但也不排除会出现一些问题，比如BAT企业这几家都遇到过机房光缆被挖断的事故。

当我们发现服务器异常停机且没有自动启动、网络中断的时，就需要直接联系机房安排人员查看情况。

2、受到大流量DDoS攻击导致网站访问异常

当我们的站点受到大流量DDoS攻击后，可能会导致上行带宽被占满的情况，此时我们是不好处理的，需要联系机房安排进行流量清洗。

3、服务器硬件故障

服务器是长期不间断运行的，硬件损伤也是比较严重的。特别是那种传统机械硬件的服务器一旦被突然断电，很可能会导致磁盘故障。

需要由服务器运维人员处理的异常

1、网站受到攻击

首先需要确定攻击类型，是流量攻击还是漏洞提权，然后对应的溯源处理。

2、服务器负载较大，CPU及内存被占满

如果并发及流量较大，可能是正常的，这是由于访客激增导致的服务器负载较大；但如果当前访客不多，而CPU及内存都被占满了，则我们需要找到这些资源被哪个进程使用的，Windows系统使用任务管理器可以查看，Linux中使用top、ps等指令来查看。

3、服务器被黑

服务器被黑这个不在机房服务范围之内，需要服务器运维人员去解决。判断服务器是通过哪种途径被黑的，比如说：程序漏洞、系统漏洞、提权、SQL注入等。

最近某司网站主页被篡改了，找师傅帮忙看看怎么回事，师傅没有空就交给我了……我自己这方面没有了解很多。事情结束后，又找师傅问了问关于溯源的技巧经验，于是就有了这篇小结。

看对方的目的是什么，就是最终目标是做什么。然后根据自己经验 看看达到这个目标 需要进行什么 *** 作 逆推回去。看看这些过程都会留下什么日志。

分析网站源码可以帮助我们获取网站被入侵时间, 黑客如何的 IP, 等信息, 对于接下来的日志分析有很大帮助。

可以使用 D 盾查杀是否存在网站后门，如果存在 webshell，记录下该 webshell 的信息。

找到 webshell 后，就可以根据该文件的路径，在日志里查找有关信息，例如访问该文件的 IP、时间等。可以根据这些信息确定网站别入侵的时间，从而缩小搜索范围，运气好了可以直接根据 IP 找到黑客。

diff 工具推荐-diffmerge

可以根据被修改的文件的修改时间，缩小搜索范围。

可以根据文件的排序迅速找到被黑客修改的文件，从而找到入侵时间。

例：查看 10 分钟内修改过的文件

网站日志一般为

根据上一步分析网站源码得到的信息在对日志文件进行筛选分析，因为日志文件会记录很多信息，如果一条一条分析，不是很现实。

web-log 分析工具

系统日志分析

/var/log/wtmp 和/var/run/utmp 两个文件无法直接使用 cat 命令输出，但是可以使用一些命令来查看，比如 w/who/finger/id/last/ac/uptime

该命令查询 /var/log/wtmp 文件并显示 当前 系统中每个用户和它所运行的进程信息：

该命令往回搜索 /var/log/wtmp 文件来显示自从该文件第一次创建以来所有登录过的用户：

如果指明了用户，则该命令只显示该用户的近期活动：

/var/log/lastlog 文件在每次有用户登录时被查询。可以使用 lastlog 命令来检查某特定用户上次登录的时间，并格式化输出上次登录日志 /var/log/lastlog 的内容。它根据 UID 排序显示登录名、端口号（tty）和上次登录时间。如果一个用户从未登录过，lastlog 显示 Never logged(从未登录过)。注意需要以 root 运行该命令：

4 id 用单独的一行打印出当前登录的用户，每个显示的用户名对应一个登录会话。 如果一个用户有不止一个登录会话，那他的用户名将显示相同的次数：

检查服务器是否有黑客留下的木马程序。

指令：ps aux|grep ‘pid’

整理完这篇总结，感觉溯源是一个很细节的事情，需要注意每一个细节，这篇总结也可以是一个备忘，以后在遇到溯源的活，做的时候就可以更系统一些。第一次投稿写的不好，师傅们多多指教哈，嘻嘻。

在网站运维过程中，常会遇到访客反映“服务器正忙，请稍后再试”错误提示，实际上不论是web服务器，游戏服务器，邮件服务器，又或者是软件服务器等，都会遇到诸如“服务器正忙，请稍后再试”类的问题。

这里就详细列举“服务器正忙，请稍后再试”错误现象常见的原因及相应的解决方法：

1本地网络配置问题：

本地网络配置问题，包括本地dns服务器配置，浏览器配置等，如果配置不当，都常会出现“服务器正忙，请稍后再试”的错误提示。

解决方法是：根据访问服务器的情况，正确配置本地dns及浏览器相关选项即可。比如：勾选浏览器Internet选项的“通过代理连接使用>

再比如：如果是玩游戏，或者登录某软件、网站时出现“服务器正忙，请稍后再试”错误提示，我们可以根据游戏服务器或者软件服务器的网络线路，将本地dns服务器设置对应的电信、网通等线路的公共免费DNS服务器地址，就可更好的避免“服务器正忙，请售后再试”状况的反复出现。

2服务器超出大连接数，达到峰值，响应延迟：

这种“服务器正忙，请售后再试”的原因，主要在于网站、游戏或软件服务器的本身资源配置有关。任何台服务器，不论是虚拟服务器（VPS、云主机），还是实体服务器，其CPU、内存、网络等资源配置都有限，当并发请求数，即同时在线数超出了服务器资源配置能够支撑的大连接数、峰值，就会导致服务器延迟响应用户请求的状况，同时发出“服务器正忙，请稍后再试”的提示现象。

解决方法是：相对用户来说，按照提示，稍后再试。当然，比如玩游戏，我们也可以选择在线人数少的时候，登录游戏服务器，避免在线高峰，就能够很好的避免服务器正忙的情况；

对于服务器运维人员来说，可以采取优化服务器软硬件环境，或者升服务器资源配置的方法来避免“服务器正忙，请稍后再试”的状况时常出现。

3服务器遭受CC/DDos等攻击：

任何网络服务器状况的出现，都有可能是遭受攻击的原因。同样，“服务器正忙，请稍后再试”状况的频繁出现，也有可能是因为服务器遭受CC/DOS/DDOS等流量攻击的原因。

解决方法是：对于用户来说，只有种办法，就是等！等攻击停止，等运维人员有效解决被攻击问题，等服务器恢复正常；

对于服务器运维人员或管理员来说，就是能够很好的排查、解决和处理服务器被攻击问题，或者可以选择如快云VPS，快云服务器等高性能服务器，或者增值如快云防护，有效预防CC/DDOS攻击等服务，避免服务器遭受攻击。无论如何，服务器安全防护及监控软件是需要配置和时常关注的。

4服务器相关应用更新、升：

这种原因，般常见于游戏或者软件服务器，当然，些web应用服务器，也常会更新，升。也就是说，游戏、软件或应用需要更新升，或者正在升更新，而关闭了服务器多外响应服务，因此，出现了“服务器正忙，请稍后再试”提示。

解决方法是：对于用户来说，当然还是等，或者咨询相关官方客服，又或者浏览对应官方公告等。

5服务器死机、宕机：

这种原因的出现，常是在第种原因之后，就是在线数达到了服务器资源配置，能够支撑的大限度，从而导致了服务器无法及时响应请求，甚至是直接瘫痪，就是服务器死机、宕机。

解决方法是：对于用户来说，同样的办法，等。同时也可以像相关客服反映情况，以期能够及时解决；

对于服务器运维或管理员来说，同第种原因的解决方法样，及时重启服务器，并能够有效优化服务器软件配置环境，或者更换更高资源配置的服务器，从而更好的避免“服务器正忙，请稍后再试”状况的频繁出现。

说明使用的人太多了，导致系统卡顿，建议晚点再试试

---