# 节点托管类型

虽然开发团队会逐步和尽量让节点的软件安装、监控更为自动化，但是作为互联网设备，不可避免会存在问题需要处理，所以每个节点存在一定的运维管理工作。

而不同节点的技术储备也各不相同，比如有的节点可能本身就提供过互联网服务，有服务器和技术人力，有的节点可能根本不懂技术。但是为了保证HyperGraph网络的整体稳定性并给HyperGraph用户提供一致的服务，对服务的响应速度和质量，以及标准化程度都有相当的要求，所以针对这种情况，对节点的托管以及服务等级做出界定。

## 节点托管类型

#### 1、全托管

全托管是节点报名之后，协商采购完成服务器，除了硬件升级需要继续参与之外，对于软件的安装维护、服务的稳定性监控，完全不需要参与管理，甚至都不需要登录服务器。

但节点仍可以通过节点的后台查看节点的统计，也可以可选获得云平台子账户，通过分配的子账户在云服务器后台来获得服务器的配置以及运行状况，为了避免对服务造成不稳定因素和留下安全隐患，不能登录服务器和管理服务器。

在这种托管类型下，节点只需要关注自己的统计与业务量，而不需要关心服务器的运行情况，因此也不需要技术人员，节点发起人也不需要懂技术。

目前对于服务器全托管，开发团队不收取额外技术支持费用。

#### 2、半托管

半托管是有一定云平台使用经验的节点，自行在指定的机构区域采购节点，所以加入网络的方式，也可以统一采购，通过分配子账户的方式得到服务器。因为涉及到同RPC节点大量的数据交互，所以必须在RPC节点相近的位置采购节点，否则节点将无法运转。采购完成后， 就由开发团队接手，对软件进行安装，对运维进行管理。双方均可以登录和管理节点服务器，节点可以自行对设备进行扩容，可以自行重启和停止服务器。

节点通过节点的后台查看节点的统计，也可以获得云平台子账户或者自行通过云平台，在云服务器后台来获得服务器的配置以及运行状况，但为了避免对服务造成不稳定因素和留下安全隐患，不能随便动服务器的设置，更不能随意重启服务器，哪怕是扩容，也要有开发团队的参与和支持。

在这种托管类型下，节点既可以关注自己的统计与业务量，也可以了解服务器的运行情况，服务配置情况，因此节点发起方需要有人需要对Linux的运维有一定的了解，了解云平台的操作，懂重互联网服务稳定的重要性，并保证该联络技术人员24小时电话能畅通，以联合处理问题，当然，常规的设备情况都会加入自动监控，一般情况下不会有什么问题。

#### 3、全自助管理

全自助管理是指节点服务器从采购到提供服务，全程自助，开发者团队只提供安装程序与脚本，提供软件升级和必要的监控等服务，但是不需要开发者团队有账户，来登录服务器和管理程序，这类操作由节点方技术配合开发方进行。

节点通过节点的后台查看节点的统计，自行了解服务器的配置以及运行状况，但为了避免对服务造成不稳定因素和留下安全隐患，一旦提供线上服务，不要随便动服务器的设置，更不能随意重启服务器，哪怕是扩容，也要有开发团队的参与和支持。

在这种类型下，开发方没有权限登录和管理节点服务器，所以节点全权负责配置升级、扩容和服务管理。因此需要节点方有技术人员能够熟练地操作Linux数据库、Postgres数据库、Nodejs系列开发工具等软件，也了解云平台的操作和配置、扩容等操作，更懂得互联网服务稳定的重要性，节点方必须24小时有人可以接电话来处理问题。

因此为了保证服务质量的稳定性，除非是有经验的节点，否则原则不要全自助管理。

## 服务质量要求

提供互联网服务，7\*24小时，遇到问题，难以避免，但是遇到问题，要能快速地恢复，或者让用户不可察觉，或者有问题影响小，都是处理互联网问题的原则。所以在HyperGraph 服务上，包括但不限于做到以下几点：

1. 所有服务器核心资源，包括CPU、负载、磁盘空间，超过阈值，每5分钟邮件报警。
2. 所以核心的服务进程，包括ipfs、graph-node、geth等进程，每分钟监控进程运行情况，如果进程丢失，则自动启动并邮件和短信报警
3. 对于重点的用户，建议做备份查询部署，对于子图部署在两个以上的节点上，做部署和数据冗余，一旦一个出现问题，建议可以立即切换上线
4. 对于所有节点的网络连接通，子图查询，以及RPC和子图健康状况，做监控和每分钟邮件和短信报警

做到这些以满足以下服务要求，第一步做到99.9%可靠性的标准，并朝着99.99%的可靠性而努力。这里解释一下这两个数据是什么意思。

在互联网服务领域，有一个词叫SLA，英文是 Service Level Assurance，可以翻译为服务级别。也可以理解为服务的可靠性，一般用百分数来描述这种可靠性。

99.9%的意思是：在99.9%的情况下是可以用的，这是什么概念呢，一年有365天，那么1/1000的情况不可以用，也就是1/3天将不可以用，一天只允许出现8个小时不可以用，算到一天的话，一天86400秒，一天只允许有86.4秒，也就是1分半钟不可以用，其他时间都要求能正常提供服务。这是一个不高的标准，但是也不容易达成。99.99%则属于比较高的标准了，一年只允许不到一个小时的宕机时间。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.hg.network/network-jie-dian-wang-luo/jie-dian-tuo-guan-lei-xing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
