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

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

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技术的核心基础设施，充分利用云服务带来的弹性和分布式优势，赋能自动化运维。

一，自动构建系统

如果需要构建应用，那么就建议配置使用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刷

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

运维开发工程师的职责是：负责日常运维工作；推动及开发高效的自动化运维、管理工具，提升运维工作效率；制定和优化运维解决方案，包括但不限于柔性容灾、智能调度、弹性扩容与防攻击；探索、研究新的运维技术方向。

运维开发工程师的任职要求是：1、本科及以上学历，年龄在18周岁以上；2、熟悉常见应用服务的配置和优化；3、能熟练使用常用的监控软件；4、善于分析思考问题，有责任心；5、服从工作安排，身体健康。

我们都知道，java编程无论是在软件开发或者是说其他编程方面，使用范围都是非常广泛的，所以，今天java课程http://www.kmbdqn.cn/就一起来了解一下，java编程开发语言与其他编程语言的区别和优势都有哪些。

现代JavaWeb开发

因为JavaWeb服务器与Web一样老，因此在JavaWeb上长期存在的成功传统和实践很快就要扔掉，现在可能是一个好的时候来解释这一系列中“现代”意思。

在本文中，我说“现代”的意思，就是“与现代主流软件开发趋势一致”。这些趋势并不是完全任意的堆砌，他们一个一个契合在一起。出现于这个期间大量小型快速发展的创业公司更偏爱精益开发方法。这些都要求一个更好使用，更少安装、部署和配置，集开发和运维于一体的工具。广受欢迎的云计算通过资源管理，也就虚拟化(无论是工具上还是在系统级)鼓励这些方法。系统级部署和资源分配也支持异构架构的发展。所谓异构架构就是指寻找适合的工具(也有可能是不同的工具)做合适的事。

传统的JavaWeb服务器，也就是典型的应用服务器，都有一个特别的特性：支持在一个JVM上运行多个应用。这个应用服务器提供能分开应用的运行时环境，而且升级，安装和启动都是独立的。一个应用可能运行在一个配置好的，已经运行的环境中，这种方法很多时候都工作良好，你也有理由继续使用这种方案，但是这种方案，离“现化”太远了。在不同的应用中分配不同的资源这件事是并不简单，而且在一定程度上跟现在使用hypervisor和os容器来运行应用的方案是矛盾的。因为现在针对hypervisor和os容器设计的工具和技术在多应用服务器上效率并不高，即使这些多应用服务器只是用来运行一个应用，而且这些多应用服务器的运维也不“现代”：安装配置web或者app服务器是不可缺少的，部署应用需要很多步，每一步可能都很麻烦。

现代的方法，就是在其它语言和运行平台使用的方法--单应用服务器。单应用服务器中，web容器是嵌入到应用中(而不是把应用部署到web容嚣中)。这样做就可以简单的部署，管理，配置和在系统级进行资源的分配。这就是为什么，一但现代的方法被引入Java中，传统的应用服务器(我的意思是任何打算运行多个应用的servlet或者全功能的J2e服务器)就死了。

在这里，我们调研的工具和技术并非覆盖全部的的领域。特别是在web和web相关的领域中，开发，工具，库和框架激增。这种增长部分原因是，不像嵌入式开发和大型机开发，web开发在初创公司和开发爱好者中广受欢迎。这类人是新技术的早期采纳者和体验者，有时也会为了探索技术的边界，或者学习，还有自我证明发明一种新的择术。这样的结果就是数以百计的库被发明出来，全都为了解决同样的目标，只是使用的方法略有不同。这种事情发生在Java的世界里，也发生在其他的语言生态中。

同时，我们不会讨论那种有巨大的MVC结构，模板系统或者设计来就是在服务器端渲染html的“全功能”的web框架。有很多理由不这么做，一个就是，我从来没有使用过那种框架，所以我不会评论他们的适用性或“现化化”，二，这个主题就非常复杂，需要更多的讨论，而在别的地方已经有了(这里,这里),三，web开发正在朝客户端渲染和SPA方向发展(如angular)，本质上正在朝着以前c/s的架构发展，数据和命令都通过http对服务器进行交互。这种转变没太完全，特别的，它依靠手机浏览器的js效率的提升，但是可以肯定的讲，我们将会看到越来越少HTML在服务器端生成。因此，我们会只讨论http“数据”服务的库和框架。

http服务和JAX-RS与Dropwizard

Java与其他语言不同的一点是JCP(JavaCommunityProcess)的工作，它的工作是标准化API(即使对于不属于语言规范或甚至标准运行时的库)也是如此，然后由各种商业或开源组织实现。这些JSR(JavaSpecificationRequests)是由专家组制作的，它能把一项技术从普遍变成成熟并成为标准。当JSR通过时，就会非常有用，因为几乎所有迎合相关领域的库都将实现这个标准API，这使得切换实现不那么痛苦。

对于服务器实现(代码中框架更为普遍)来说，标准对于客户端(每个调用或多或少都是独立的并且可以被替换)而言更重要。您可以使用三个不同的HTTP客户端和3个不同的JDBCAPI，但是您的服务器通常运行在单个框架中。出于这个原因，。单纯的API美学不应该倾向于支持非标准的API。

相比于客户端(每次请求或多或少比较独立和能被替代)，标准化对服务器应用更重要(因为框架代码无处不在)。你可以使用三个不同的http客户端和三个不同的JDDCapi在同一个方法中，但是你的服务器通常运行在一个框架中。出于这个原因，你应该更喜欢标准服务器API而不是非标准服务器API，除非非标准服务器API为你的应用提供了一些非常重要的优势，或者更适合您的特定用例。单纯的API美学不应该倾向于支持非标准的API。

---