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

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

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刷

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

新手远程管理Win2003服务器技巧

我目前远程管理着多台服务器，并且经常需要远程连接到客户的系统上解决问题或是向客户演示如何去完成特殊的任务，其中有些客户的系统位于200英里以外的地方。

在过去，我一直使用Virtual Network Computing来连接这种服务器或客户机，不过使用VNC需要在防火墙上打开某些特定的端口，这需要涉及防火墙和内部网络的配置，以及在防火墙上建立端口映射。因此，虽然VNC是免费软件并且也有很好的跨平台性能，但它仍需要我在网络的可访问性上花费不少时间。

使用类似VNC 这种远程控制软件的另一点不足就是你必须在远程系统中安装服务器端程序，并在自己的机器上安装客户端程序。这在通常情况下都是可以实现的，但如果你不得不使用公用电脑或出于其它某些原因无法安装相应的远程管理软件，此时远程桌面Web连接(Remote Desktop Web Connection ，RDWC)就成为了一个很好的选择。

虽然RDWC仍然无法避免在防火墙上打开特定端口的问题，但它完全避免了远程访问客户端软件的问题。下面我就来介绍一下RDWC是如何工作的，如何用它管理你的服务器和工作站以及如何配置防火墙才能正常使用RDWC。

关于远程桌面Web连接的说明

RDWC集成在Windows Server 2003 以及Windows XP系统中。带有RDWC的系统可以启动终端服务Web客户端(Terminal Services Web Client)的计算机，以便Web浏览器可以访问。换句话说，客户端系统不需要运行远程桌面连接程序或终端服务(Terminal Services)客户端程序来连接远程系统，而只需要使用常用的Web浏览器就可以进行连接了。

RDWC是由一个 ActiveX控件、几个简单的Web页面以及可以运行IIS40或以上版本进行远程连接服务的文件构成的。因此不论是Windows Server 2003、Windows NT、Windows 2000，或是Windows XP，都可以作为被远程控制的系统。而实现远程控制的客户端必须采用运行Internet Explorer 50或以上版本的浏览器的Windows平台。

对于远程控制来说，RDWC是一个很好的解决方案，同时，对于远程管理以及远程技术支持来说，RDWC也非常合适。另外，对于需要远程访问数据的业务伙伴、移动办公用户以及其他不愿意安装客户端程序的用户来说，RDWC也是很好的选择。

那么RDWC是如何工作的呢当你安装RDWC时，安装程序会在目标服务器的Administration Web站点上安装一个Tsweb虚拟目录。当担任远程控制任务的电脑连接到这个目标服务器上时，远程电脑中的IE浏览器会自动下载一个CAB文件包，用来安装RDWC所需的ActiveX控件。如果远程电脑中已经带有这个控件，只是版本与目标服务器的版本不符，那么IE也会自动下载新的。自动安装好 ActiveX控件后，连接页面就会出现。稍后我会介绍从客户端系统的连接过程。现在我们先安装RDWC。在本文中，我假定你使用Windows Server 2003。当然，如果你使用上面提到的任何一种平台也是一样的。

在Windows Server 2003上配置RDWC 虽然RDWC包含在Windows Server 2003中，不过默认情况下它并不会被安装。要手动安装RDWC，你需要在控制面板中点开“添加删除程序项。然后点击“添加/删除Windows组件，激活Windows组件向导。点击“应用服务器(Application Server)，然后点击“详细资料，添加“互联网信息服务(IIS)。依次点击“详细资料/“>

网络的计算模式

〖主要内容〗C/S模式的形成和发展及特点,B/S模式的形成和发展及特点

〖教学重点〗C/S模式的中间件,B/S模式的技术特征

随着计算机技术和计算机网络的发展,以客户机/服务器(C/S)的计算模式逐渐取代了以大型主机为中心的计算机模式,成为企业网首选的计算模式

网络计算模式的发展

以大型机为中心的计算模式

以大型机为中心的计算模式即分时共享模式,是指将不具备资源的终端通过硬件连线直接连接到主机或终端控制器上,利用主机的能力来运行应用程序,并将运行结果在终端显示出来的计算结构

特点:终端通过硬件连线直接连接到主机或终端控制器上;系统提供专用的用户界面;所有用户击键和光标位置被传入主机;所有从主机返回的结果包括光标位置和字符串等都显示在屏幕的特定位置;系统采用严格的控制和广泛的系统管理,性能管理机制

以服务器为中心的计算模式

以服务器为中心的计算模式即资源共享模式,是指PC机工作站与大型机连接成局域网,从而使资源得以共享的计算结构

特点:向用户提供了灵活的服务;管理控制和系统维护工作较弱;主要用于共享共同的应用,数据以及打印机

客户机/服务器计算模式

客户机/服务器计算模式,简称C/S模式,是指前端客户部分(微机或工作站)通过应用程序运行服务器上的程序并得到结果,后端服务器部分(微机或大型机)运行客户机请求的应用程序,并将运行结果返回给客户机的计算结构

浏览器/服务器计算模式

浏览器/服务器计算模式,简称B/S模式,是指基于浏览器,>

B/S模式继承和共融了传统C/S模式中的网络软,硬件平台和应用,所不同的是更加开放,与软,硬件平台无关,应用开发速度快,生命周期长,应用扩充和系统维护升级方便等

客户机/服务器模式

C/S技术特点:系统使用了客房机和服务器双方的智能,资源和计算机能力来执行一个特定的任务,即一个任务由客房机和服务器双方共同承担

C/S特点

在C/S模式下,一个或更多的客户机和一个或更多的服务器以及支持客户机和服务器进程通信的网络 *** 作系统共同组成了一个支持分布计算,分析和表示的系统,在该模式下,应用分为前端的客户应用部分和服务器应用部分客户方发出请求,网络通信系统将请求的内容传到服务器,服务器根据请求完成预订的 *** 作,然后把结果送回客户

客户机的特点

提供了一个用户界面,负责完成用户命令和数据的输入,并根据用户要求提供所得到的结果

同一系统中每个客户机要有一致的用户界面

客户机使用结构化查询语言SQL发送命令到服务器

客户机利用OS的进程间通信机制和服务器进行通信,并把查询结果或命令传到服务器

客户机对服务器送回的查询或命令结果数据进行分析处理,然后把它们提交给用户

服务器的特点

服务器向客户机提供由客户机/服务器系统决定特定服务

服务器负责响应来自客户机的查询或命令,但不是主动的,而是作为一个信息的存储者或服务的提供者

C/S特点

桌面上的智能

最优化地共享服务器资源

优化网络利用率

在底层OS和通信系统之上提供一个抽象的层次,允许应用程序有较好的可维护性和可移植性

C/S与资源共享模式的比较:

资源共享模式:

客户机通过应用程序请求服务器通过网络发送合适的数据文件,客户机收到数据表后对数据作进一步处理(如:修改)再将结果送回到服务器上客户机可共享服务器上的资源(应用软件,数据库,打印机等)

C/S模式:

客户机通过应用程序中的SQL命令(结构化查询语言)向服务器发出请求,服务器根据请求自行对数据库进行处理,再通过网络将处理结果送回到客户端即客户机与服务器之间只是传送服务请求命令和命令 *** 作结果,而不需要传送任何数据库文件

客户机前端处理用户界面和交互,服务器后端负责处理请求

C/S的优点

减少了网络的流量:传输的只是必要的信息,如师更新的数据而不是整个数据表

响应时间较短:因为所有的数据运算和处理工作是在服务器上完成的

充分利用客户机和服务器双方的能力组成了一个分布式应用环境

保证了数据的安全性和完整性,服务器对客户要进行鉴别或授权等的识别

客户机更加灵活,只要连接到网络用户都可以进行访问

C/S模式的中间件

C/S的优点并没有使基于C/S的应用软件大量出现,原因在于程序员编写应用程序要面对底层网络协议,从而难于编写和维护,其移植性也较差为了解决应用程序对网络过分依赖问题,引用了中间件

中间件:是指客户机和服务器之间的软件(类似OS作用)

利用中间件提供的简单的,较高层次的应用程序编程接口API,把下层网络技术屏蔽起来,这样程序员把精力集中在应用方面,而不是通信问题上

中间件功能:把应用和网络屏蔽开从应用的角度看,中间件对网络的作用和OS对本地计算机资源(硬盘,外设,内存)的作用是一样的中间件为程序员提供了高层的,跨越多种平台和协议的接口,使得在客户机/服务器模式下的应用程序编写变得简单和有效

浏览器/服务器计算模式

B/S计算模式确定与特点

C/S计算模式

B/S计算模式

结构

以分散的,多层次的和具有图形用户接口GUI的PC作为客户机,用户在客户机以事件驱动方式一对多地访问应用服务器上的资源

一种平面型多层次的网状结构,网络用户在基于浏览器的客户机上以网络用户界面NUI多对多地访问应用服务器上的资源;用户访问应用服务器资源以动态交互或互相合作的方式进行

数据处理

在客户机上

在服务器上

*** 作平台

要求统一平台

与软件,硬件平台无关

程序语言

取决于客户机的使用

取决于服务器的使用

硬件要求

多功能的客户机

最基本的客户机

B/S计算模式的发展

静态Web技术

动态Web技术

实时Web技术

时间

1997年前

1997～1998年

1998年至今

结构

连接Internet

建立Intranet

Internet,Intranet,Extranet

技术

HTML

>

静态Web服务

基本安全

配置各类服务器

防火墙

浏览器/Web/DBMS

Java

网络基础设施带宽延时等实时性保证

新的/改进的协议和工具

虚拟技术

更高的安全性

应用

电子邮件

信息发布

信息共享

访问数据库

多媒体信息交互

交谈/讨论

工作流/工作日程

虚拟现实各种应用

电子商务

协同工作

事物处理

基于Web技术的B/S计算模式特征

采用面向对象技术OOP

虚拟现实标志语言VRML(具有三维动画超媒体技术)

B/S计算模式应用系统平台特点

分散应用与集中管理,跨平台兼容性,交互性和实时性,协同工作,系统易维护性

它使企业能够开发、部署和集成新一代电子商务应用(如 B2B 的电子交易)，并且支持从简单的 Web 发布到企业级事务处理的商务应用。WAS 转变了企业对客户、合作伙伴及雇员之间关系的管理方式。例如您可以通过它提高站点传输数据的数量和质量，从而大幅提升您的Web应用的性能，并将扩展的应用程序与移动设备相结合，让销售队伍能够为客户提供更快捷的服务，或者构建电子市场以降低资源获取的成本。 这个平台的基础是 WebSphere Application Server ，它有三个版本，具有为满足您最严格的业务需要而设计的专业化配置。它通过一个简单的 Java引擎来驱动，当需求改变时，您可以容易地把应用程序移植到不同的平台上。
标准版：通过使用 servlet、JavaServer Page 以及 XML，快速地将静态 Web 站点转换为富有勃勃生机的动态站点。 高级版：包含高性能企业级 Java Bean 组件的服务器。 企业版：集成了 EJB 和 CORBA 技术，为构建流量高、容量大的电子商务应用提供可靠的保证。 WebSphere应用服务器架构图
基于WebSphere应用服务器在企业内部应用的核心地位，如何保证其正常高效运行就显得非常重要。 运行在WebSphere应用服务器上的应用随时可能出现性能问题，如何智能地分析这些问题是一项挑战。当关键的J2EE业务应用出现问题时，系统和服务器管理员需要尽快识别问题的原因。使用内置管理控制台进行手工分析是十分不方便的，并且需要大量的应用服务器专业知识，并且传统的监控软件在监控websphere方面存在着很大的缺点：不能监控；监控的深度和广度不够；没有清晰的可视化效果；不能监控WebSphere应用服务器的集群。
Mocha BSM对WebSphere应用服务器监控的优势 摩卡业务服务管理(Mocha Business Service Management，简称Mocha BSM)为系统管理员提供一个关于WebSphere应用服务器性能的图形化视图；通常在用户意识到问题之前即提供可快速识别和排除这些问题所需要的关键细节信息。 1．以独特的可视化方式展现WebSphere应用服务器架构、服务器和应用中的实时活动。
2．实时性能诊断 Mocha BSM以直观的图形用户界面方式提供WebSphere应用服务器集群，服务器和应用中活动和流程的细节信息，显示服务器中的活动，当问题出现时，通过这些活动可以识别出问题的根源。您可以方便的查看集群，服务器和应用组件的当前状态，如响应时间、堆使用情况、线程池、JDBC连接池、Servlet、JSP和EJB的使用情况等。从摘要信息到组件的详细信息，并且提供了直观灵活的导航功能。
3．在一个窗口中显示所有关键组件并可深入分析更为详尽的信息 。 4．以不断的状态更新和警告通知等方式突出显示有问题的地方 。 主要特点 快速安装 安装快速，无干扰。允许WebSphere应用服务器管理员立即开始监测服务器活动并在恶化之前消除潜在的性能问题。 实时的性能视图 实时显示性能，当应用处理最终用户请求的过程时，管理员可以看到问题的发展变化情况。产品按照WebSphere应用服务器的处理流程，检查集群，服务器和应用中的瓶颈。 统一的中心控制台 通过精心优化设计的控制台，可主动的发现问题，显示相关应用组件和处理流程。当资源达到危险警告值时给管理员发出警告，将J2EE资源间的连接和使用情况展现为易于理解的应用状态图。 智能的深入诊断引导分析者深入诊断，找到引起瓶颈的组件。

Web服务器的基本功能就是提供Web信息浏览服务。它只需支持>