新服务器做数据库服务器用，如何测试

通过在新服务器上检查这些步骤，您可以确保它们至少具有针对最常见攻击的基本保护。

1 - 用户配置

如果它不是您的操作系统设置的一部分，您要做的第一件事就是更改root密码。这应该是不言而喻的，但在例行服务器设置期间可能会被忽略。密码应至少为8个字符，使用大写和小写字母，数字和符号的组合。如果要使用本地帐户，还应设置密码策略，以指定老化，锁定，历史记录和复杂性要求。在大多数情况下，您应该完全禁用root用户，并为需要提升权限的用户创建具有sudo访问权限的非特权用户帐户。

2 - 网络配置

您需要做的最基本配置之一是通过为服务器分配IP地址和主机名来启用网络连接。对于大多数服务器，您将需要使用静态IP，因此客户端始终可以在同一地址找到资源。如果您的网络使用VLAN，请考虑服务器段的隔离程度以及最适合的位置。如果您不使用IPv6，请将其关闭。设置主机名，域和DNS服务器信息。应使用两个或多个DNS服务器进行冗余，您应该测试nslookup以确保名称解析正常工作。

3 - 软件包管理

据推测，您正在为特定目的设置新服务器，因此如果它们不属于您正在使用的分发版，请确保安装可能需要的任何软件包。这些可以是PHP，MongoDB，ngnix等应用程序包，也可以是pear等支持包。同样，应删除系统上安装的任何无关软件包以缩小服务器占用空间。所有这一切都应该通过您的分销包管理解决方案来完成，例如yum或apt，以便在未来更轻松地进行管理。

4 - 更新安装和配置

一旦在服务器上安装了正确的软件包，就应该确保一切都已更新。不仅包括您安装的软件包，还包括内核和默认软件包。除非您需要特定版本，否则应始终使用最新的生产版本来保证系统的安全。通常，您的包管理解决方案将提供最新的支持版本。您还应该考虑在程序包管理工具中设置自动更新，如果这样做适用于您在此服务器上托管的服务

5 - NTP配置

配置服务器以将其时间同步到NTP服务器。如果您的环境具有这些服务器，则可以是内部NTP 服务器，也可以是可供任何人使用的外部时间服务器。重要的是防止时钟漂移，服务器的时钟偏离实际时间。这可能会导致许多问题，包括在授予访问权限之前测量服务器和身份验证基础结构之间的时间偏差的身份验证问题。这应该是一个简单的调整，但它是可靠基础设施的关键点。

6 - 防火墙和iptables

根据你的发行版，iptables可能已被完全锁定并要求你打开你需要的东西，但无论默认配置如何，你都应该看看它并确保它按照你想要的方式设置。请记住始终使用最小权限原则，并且只打开那些服务器上的服务绝对需要的端口。如果您的服务器位于某种专用防火墙后面，请务必否认所有内容，但也有必要。假设您的iptables /防火墙在默认情况下是限制性的，请不要忘记打开您的服务器完成其工作所需的内容！

7 - 保护SSH

SSH是Linux发行版的主要远程访问方法，因此应该得到适当的保护。您应该远程禁用root的远程SSH功能，即使您禁用了该帐户，以防万一由于某种原因在服务器上启用了root，它仍然无法远程利用。如果您有一组将要连接的固定客户端IP，您还可以将SSH限制为某些IP范围。或者，您可以更改默认的SSH端口以“隐藏”它，但老实说，简单的扫描会向想要找到它的任何人显示新的开放端口。最后，您可以完全禁用密码身份验证，并使用基于证书的身份验证来进一步降低SSH利用的可能性。

8 - 守护程序配置

您已经清理了软件包，但在重新启动时将正确的应用程序设置为自动启动也很重要。务必关闭任何不需要的守护进程。安全服务器的一个关键是尽可能减少活动占用空间，因此可用于攻击的唯一表面区域是应用程序所需的区域。完成此操作后，应尽可能加强剩余服务以确保弹性。

9 - SELinux和进一步硬化

如果您曾经使用过Red Hat发行版，那么您可能熟悉SELinux，这是一种保护系统免受各种操作影响的内核强化工具。SELinux非常善于防止未经授权的使用和访问系统资源。它在打破应用程序方面也很出色，因此请确保在启用SELinux的情况下测试配置，并使用日志确保没有任何合法内容被阻止。除此之外，您还需要研究强化MySQL或Apache等任何应用程序，因为每个应用程序都有一套最佳实践可供遵循。

10 - 日志记录

最后，您应确保已启用所需的日志记录级别，并且您有足够的资源。您最终将对此服务器进行故障排除，因此请立即帮忙，并构建您需要快速解决问题的日志记录结构。大多数软件都具有可配置的日志记录，但您需要一些试验和错误才能在信息不足和过多之间找到适当的平衡点。有许多第三方日志记录工具可以帮助处理从聚合到可视化的所有内容，但是每个环境都需要首先考虑其需求。然后，您可以找到有助于填充它们的工具。

这些步骤中的每一步都需要一些时间来实施，尤其是第一次。但是，通过建立初始服务器配置例程，您可以确保环境中的新计算机具有弹性。如果您的服务器可能是攻击的目标，则不采取任何这些步骤可能会导致相当严重的后果。

做好这些并不能保证足够安全， 但它确实使恶意行为者变得更加困难，并且需要一定程度的技术能力来克服。

提到服务器性能测试，不得不提到很多术语。为了让大家更容易理解，举个生活中的例子：

你中午去“海底捞”吃饭。

我们可以把“海底捞”这个酒楼看成一个被测系统。

你去吃饭，就是对这个被测系统发起请求，对这个系统造成了一定的负载。你带去的人越多，那么这个餐馆就越繁忙，可以说餐馆承受的负载就越大。

你开始点菜。这个时候你隔壁桌的人也开始点菜。那么你们两个对这个系统产生了并发的请求。同时，其他桌有的在吃菜，有的在等菜，这些都是并发进行的事务。一个完整的吃饭事务可以定义成包括：点菜，下单，上菜，买单四个步骤。对于一个C/S的系统来说，可以对应于：建立连接，发送请求，接受应答，断开连接。

影响一个餐馆生意好坏的一个重要原因是上菜速度。上菜速度体现在两个方面：

很多因素会影响上菜速度，比如服务员的个数、厨师的个数。对于一个C/S的系统，服务员相当于是接入层，厨师相当于是后台服务。假如服务员太少，下单很慢，后面的厨师都闲着，那么上菜速度也快不了；假如服务员够多，下单足够快，但是厨师太少，下的单来不及做，同样上菜速度也很慢；如果服务员很多，厨师也很多，但是来的客人很少，那么大部分的服务员和厨师都闲着，资源全部浪费掉了。因此，接入层和后台服务进程个数、以及资源配比，都是需要根据实际情况进行调优的。

来多少顾客，这是酒楼自己无法控制的，但是酒楼的上菜速度、餐位多少都会制约客流量。一定有一个峰值客流量，当来的客人超过了这个峰值，那么这些客人就会等位，或者是上菜速度超慢让客人无法容忍。容量测试就是通过工具模拟足够多的顾客来吃饭的事务，希望找到这样一个客流量对酒楼产生一定的负载，这个时候酒楼既能接待最多的客户同时也能保证最短的等待时间。更多的，还可以对这个酒楼人员配置和餐位设置等进行调优，以期达到一个最理想的资源利用率和效率。

客流量跟进来的客人多少有关，也跟餐馆的接待能力有关。单方面增加来就餐的顾客，遭到投诉的可能性就越大，上错菜的可能性也越大。

1一个顾客请求的处理耗时，从下单到上菜中间等待的时间，我们称之为响应时间。

2这个餐馆同时为多名顾客上菜的频率，我们称之为吞吐量。

在对服务器配置进行测试时，使用AWS Spot Instances可以帮助企业应对不同的配置而不影响预算。

在云计算之前，管理员们不得不在投资服务器之前先猜测应用程序所需的CPU核数目和RAM的大小。自动化的配置可能会运行大量的服务器，导致花费巨大。使用Spot Instances可以帮助管理员在服务器配置上找到最佳切入点，而不会让整个预算变得让人难以接受。

假设有一家必须要运行大型分析作业的企业，它将会运行混有第三方编写的代码和各种代码库。管理员也许无法确定需要多少内存和CPU。他们可以选择一个高内存，CPU经过优化的高成本的实例，但是那不总是正确的解决方法。这种做法也许对一两个作业有效，但不会是一个长期的策略。

压力测试：有两个方案，都是用同步的思想，一个是开多进程与多线程，同时向服务器发送NTP包，如果机器好的话，会平均给你反回NTP包，你可以用抓包工具查看，注意，这里的发包是不加延时的，只是程序运行的时间，如果算法好的话，你可将时间缩得很小，这个方法我叫触发。

方案二，在方案一的基础上加上延时，200ums发一包是相当快的了，但是NTP里面的却可以做到收到立即响应，时间间隔相当小，只有100ums左右，。程序你可以及网上找上。其实就是一个用一个socket发一个NTP包，但是你要是想做好的话，还是要一些基础。需要用到多进程与多线程，socket编程，NTP协议。

我觉得从压力测试就可以看到性能与稳定性了，不过稳定性还要求开机时间的长短，你可以尝试，测试端与被测试机同时着，不断往被测试机发包，发他几天几夜的，同时打开抓包工具监测，这种的测试，你可以考虑用延时，每隔几ms发一次，个体自己定。

对于客户端，主要是时间同步吧？还有一个是接收包的处理能力，个人认为，这个与服务器测试没有多大的区别。

贴一篇我们内部的文章：

随着浏览器功能的不断完善，用户量不断的攀升，涉及到web服务的功能在不断的增加，对于我们测试来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么性能测试都要做些什么呢？我们该怎样进行性能测试呢？

性能测试一般会围绕以下这些问题而进行：

1 什么情况下需要做性能测试？

2 什么时候做性能测试？

3 做性能测试需要准备哪些内容？

4 什么样的性能指标是符合要求的？

5 性能测试需要收集的数据有哪些？

6 怎样收集这些数据？

7 如何分析收集到的数据？

8 如何给出性能测试报告？

性能测试的执行过程及要做的事儿主要包含以下内容：

1 测试评估阶段

在这个阶段，我们要评估被测的产品是否要进行性能测试，并且对目前的服务器环境进行粗估，服务的性能是否满足条件。

首先要明确只要涉及到准备上线的服务端产品，就需要进行性能测试。其次如果产品需求中明确提到了性能指标，那也必须要做性能测试。

测试人员在进行性能测试前，需要根据当前的收集到的各种信息，预先做性能的评估，收集的内容主要包括带宽、请求包大小、并发用户数和当前web服务的带宽等

2 测试准备阶段

在这个阶段，我们要了解以下内容：

a 服务器的架构是什么样的，例如：web服务器是什么？是如何配置的？数据库用的是什么？服务用的是什么语言编写的？；

b 服务端功能的内部逻辑实现；

c 服务端与数据库是如何交互的，例如：数据库的表结构是什么样的？服务端功能是怎样操作数据库的？

d 服务端与客户端之间是如何进行交互的，即接口定义；

通过收集以上信息，测试人员整理出服务器端各模块之间的交互图，客户端与服务端之间的交互图以及服务端内部功能逻辑实现的流程图。

e 该服务上线后的用户量预估是多少，如果无法评估出用户量，那么可以通过设计测试执行的场景得出这个值；

f 上线要部署到多少台机器上，每台机器的负载均衡是如何设计的，每台机器的配置什么样的，网络环境是什么样的。

g 了解测试环境与线上环境的不同，例如网络环境、硬件配置等

h 制定测试执行的策略，是需要验证需求中的指标能否达到，还是评估系统的最大处理能力。

i 沟通上线的指标

通过收集以上信息，确定性能测试用例该如何设计，如何设计性能测试用例执行的场景，以及上线指标的评估。

3 测试设计阶段

根据测试人员通过之前整理的交互图和流程图，设计相应的性能测试用例。性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数量测试，网络性能测试，服务器性能测试，具体编写的测试用例要更具实际情况进行裁减。

用例编写的步骤大致分为：

a 通过脚本模拟单一用户是如何使用这个web服务的。这里模拟的可以是用户使用web服务的某一个动作或某几个动作，某一个功能或几个功能，也可以是使用web服务的整个过程。

b 根据客户端的实际情况和服务器端的策略，通过将脚本中可变的数据进行参数化，来模拟多个用户的操作。

c 验证参数化后脚本功能的正确性。

d 添加检查点

e 设计脚本执行的策略，如每个功能的执行次数，各个功能的执行顺序等

4 测试执行阶段

根据客户端的产品行为设计web服务的测试执行场景及测试执行的过程，即测试执行期间发生的事儿。通过监控程序收集web服务的性能数据和web服务所在系统的性能数据。

在测试执行过程中，还要不断的关注以下内容：

a web服务的连接速度如何？

b 每秒的点击数如何？

c Web服务能允许多少个用户同时在线？

d 如果超过了这个数量，会出现什么现象？

e Web服务能否处理大量用户对同一个页面的请求？

f 如果web服务崩溃，是否会自动恢复？

g 系统能否同一时间响应大量用户的请求？

h 打压机的系统负载状态。

5 测试分析阶段

将收集到的数据制成图表，查看各指标的性能变化曲线，结合之前确定的上线指标，对各项数据进行分析，已确定是否继续对web服务进行测试，结果是否达到了期望值。

6 测试验证阶段

在开发针对发现的性能问题进行修复后，要再执行性能测试的用例对问题进行验证。这里需要关注的是开发在解决问题的同时可能无意中修改了某些功能，所以在验证性能的同时，也要关注原有功能是否受到了影响。

想看原文或者有测试其他相关的问题可以关注下 搜狗测试 微信公众号，我们上面有不少关于性能测试分享~