diff --git a/ydb/docs/en/core/_includes/fault-tolerance.md b/ydb/docs/en/core/_includes/fault-tolerance.md
deleted file mode 100644
index ca629fa3cd45..000000000000
--- a/ydb/docs/en/core/_includes/fault-tolerance.md
+++ /dev/null
@@ -1,5 +0,0 @@
-{% note info %}
-
-YDB cluster is fault tolerant. Temporarily shutting down a node doesn't affect the cluster availability. For details, see [{#T}](../cluster/topology.md).
-
-{% endnote %}
diff --git a/ydb/docs/en/core/administration/production-storage-config.md b/ydb/docs/en/core/administration/production-storage-config.md
deleted file mode 100644
index 6e2a89f39ecc..000000000000
--- a/ydb/docs/en/core/administration/production-storage-config.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# BlobStorage production configurations
-
-To ensure the required fault tolerance of {{ ydb-short-name }}, configure the [cluster disk subsystem](../concepts/cluster/distributed_storage.md) properly: select the appropriate [fault tolerance mode](#fault-tolerance) and [hardware configuration](#requirements) for your cluster.
-
-## Fault tolerance modes {#fault-tolerance}
-
-We recommend using the following [fault tolerance modes](../cluster/topology.md) for {{ ydb-short-name }} production installations:
-
-* `block-4-2`: For a cluster hosted in a single availability zone.
-* `mirror-3-dc`: For a cluster hosted in three availability zones.
-
-A fail model of {{ ydb-short-name }} is based on concepts such as fail domain and fail realm.
-
-Fail domain
-
-: A set of hardware that may fail concurrently.
-
-  For example, a fail domain includes disks of the same server (as all server disks may be unavailable if the server PSU or network controller is down). A fail domain also includes servers located in the same server rack (as the entire hardware in the rack may be unavailable if there is a power outage or some issue with the network hardware in the same rack).
-
-  Any domain fail is handled automatically, without shutting down the system.
-
-Fail realm
-
-: A set of fail domains that may fail concurrently.
-
-  An example of a fail realm is hardware located in the same data center that may fail as a result of a natural disaster.
-
-Usually a fail domain is a server rack, while a fail realm is a data center.
-
-When creating a [storage group](../concepts/databases.md#storage-groups), {{ ydb-short-name }} groups VDisks that are located on PDisks from different fail domains. For `block-4-2` mode, a PDisk should be distributed across at least 8 fail domains, and for `mirror-3-dc` mode, across 3 fail realms with at least 3 fail domains in each of them.
-
-## Hardware configuration {#requirements}
-
-If a disk fails, {{ ydb-short-name }} may automatically reconfigure a storage group so that, instead of the VDisk located on the failed hardware, a new VDisk is used that the system tries to place on hardware that is running while the group is being reconfigured. In this case, the same rule applies as when creating a group: a VDisk is created in a fail domain that is different from the fail domains of any other VDisk in this group (and in the same fail realm as that of the failed VDisk for `mirror-3-dc`).
-
-This causes some issues when a cluster's hardware is distributed across the minimum required amount of fail domains:
-
-* If the entire fail domain is down, reconfiguration no longer makes sense, since a new VDisk can only be located in the fail domain that is down.
-* If part of a fail domain is down, reconfiguration is possible, but the load that was previously handled by the failed hardware will only be redistributed across hardware in the same fail domain.
-
-If the number of fail domains in a cluster exceeds the minimum amount required for creating storage groups at least by one (that is, 9 domains for `block-4-2` and 4 domains in each fail realm for `mirror-3-dc)`, in case some hardware fails, the load can be redistributed across all the hardware that is still running.
-
-The system can work with fail domains of any size. However, if there are few domains and a different number of disks in different domains, the amount of storage groups that you can create will be limited. In this case, some hardware in fail domains that are too large may be underutilized. If the hardware is used in full, significant distortions in domain sizes may make reconfiguration impossible.
-
-> For example, there are 15 racks in a cluster with `block-4-2` fault tolerance mode. The first of the 15 racks hosts 20 servers and the other 14 racks host 10 servers each. To fully utilize all the 20 servers from the first rack, {{ ydb-short-name }} will create groups so that 1 disk from this largest fail domain is used in each group. As a result, if any other fail domain's hardware is down, the load can't be distributed to the hardware in the first rack.
-
-{{ ydb-short-name }} can group disks of different vendors, capacity, and speed. The resulting characteristics of a group depend on a set of the worst characteristics of the hardware that is serving the group. Usually the best results can be achieved if you use same-type hardware. When creating large clusters, keep in mind that hardware from the same batch is more likely to have the same defect and fail simultaneously.
-
-Therefore, we recommend the following optimal hardware configurations for production installations:
-
-* **A cluster hosted in 1 availability zone**: It uses `block4-2` fault tolerance mode and consists of 9 or more racks with the same amount of identical servers in each rack.
-* **A cluster hosted in 3 availability zones**: It uses `mirror3-dc` fault tolerance mode and is distributed across 3 data centers with 4 or more racks in each of them, the racks being equipped with the same amount of identical servers.
-
-See also [{#T}](#reduced).
-
-## Redundancy recovery {#rebuild}
-
-Auto reconfiguration of storage groups reduces the risk of data loss in the event of multiple failures that occur within intervals sufficient to recover the redundancy. By default, reconfiguration is done one hour after {{ ydb-short-name }} detects a failure.
-
-Once a group is reconfigured, a new VDisk is automatically populated with data to restore the required storage redundancy in the group. This increases the load on other VDisks in the group and the network. To reduce the impact of redundancy recovery on the system performance, the total data replication speed is limited both on the source and target VDisks.
-
-The time it takes to restore the redundancy depends on the amount of data and hardware performance. For example, replication on fast NVMe SSDs may take an hour, while on large HDDs more than 24 hours. To make reconfiguration possible in general, a cluster should have free slots for creating VDisks in different fail domains. When determining the number of slots to be kept free, factor in the risk of hardware failure, the time it takes to replicate data and replace the failed hardware.
-
-## Simplified hardware configurations {#reduced}
-
-If it's not possible to use the [recommended amount](#requirements) of hardware, you can divide servers within a single rack into two dummy fail domains. In this configuration, a failure of 1 rack means a failure of 2 domains and not a single one. In [both fault tolerance modes](#fault-tolerance), {{ ydb-short-name }} will keep running if 2 domains fail. If you use the configuration with dummy fail domains, the minimum number of racks in a cluster is 5 for `block-4-2` mode and 2 in each data center for `mirror-3-dc` mode.
-
-## Fault tolerance level {#reliability}
-
-The table below describes fault tolerance levels for different fault tolerance modes and hardware configurations of a {{ ydb-short-name }} cluster:
-
-Fault tolerance<br>mode | Fail<br>domain | Fail<br>realm | Number of<br>data centers | Number of<br>server racks | Fault tolerance<br>level
-:--- | :---: | :---: | :---: | :---: | :---
-`block-4-2` | Rack | Data center | 1 | 9 or more | Can stand a failure of 2 racks
-`block-4-2` | ½ a rack | Data center | 1 | 5 or more | Can stand a failure of 1 rack
-`block-4-2` | Server | Data center | 1 | Doesn't matter | Can stand a failure of 2 servers
-`mirror-3-dc` | Rack | Data center | 3 | 4 in each data center | Can stand a failure of a data center and 1 rack in one of the two other data centers
-`mirror-3-dc` | Server | Data center | 3 | Doesn't matter | Can stand a failure of a data center and 1 server in one of the two other data centers
diff --git a/ydb/docs/en/core/changelog-server.md b/ydb/docs/en/core/changelog-server.md
index 890cef609d1f..917abea2d8c8 100644
--- a/ydb/docs/en/core/changelog-server.md
+++ b/ydb/docs/en/core/changelog-server.md
@@ -23,7 +23,7 @@ Release date: October 12, 2023.
 * A new option `PostgreSQL` has been added to the query type selector settings, which is available when the `Enable additional query modes` parameter is enabled. Also, the query history now takes into account the syntax used when executing the query.
 * The YQL query template for creating a table has been updated. Added a description of the available parameters.
 * Now sorting and filtering for Storage and Nodes tables takes place on the server. To use this functionality, you need to enable the parameter `Offload tables filters and sorting to backend` in the experiments section.
-* Buttons for creating, changing and deleting [topics](https://ydb.tech/ru/docs/concepts/topic) have been added to the context menu.
+* Buttons for creating, changing and deleting [topics](concepts/topic.md) have been added to the context menu.
 * Added sorting by criticality for all issues in the tree in `Healthcheck`.
 
 **Performance:**
@@ -155,7 +155,7 @@ Release date: May 5, 2023. To update to version 23.1, select the [Downloads](dow
 
 * Added [initial table scan](concepts/cdc.md#initial-scan) when creating a CDC changefeed. Now, you can export all the data existing at the time of changefeed creation.
 * Added [atomic index replacement](dba/secondary-indexes.md#atomic-index-replacement). Now, you can atomically replace one pre-defined index with another. This operation is absolutely transparent for your application. Indexes are replaced seamlessly, with no downtime.
-* Added the [audit log](cluster/audit-log.md): Event stream including data about all the operations on {{ ydb-short-name }} objects.
+* Added the [audit log](security/audit-log.md): Event stream including data about all the operations on {{ ydb-short-name }} objects.
 
 **Performance:**
 
diff --git a/ydb/docs/en/core/cluster/index.md b/ydb/docs/en/core/cluster/index.md
deleted file mode 100644
index 6ae4da5f7359..000000000000
--- a/ydb/docs/en/core/cluster/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# {{ ydb-short-name }} cluster management overview
-
-This section provides information about deploying, configuring, maintaining, monitoring, and performing diagnostics of multi-node [{{ ydb-short-name }} clusters](../concepts/cluster/index.md).
-
-* [{#T}](../deploy/index.md).
-* [{#T}](../maintenance/embedded_monitoring/index.md).
-* [{#T}](../maintenance/manual/index.md).
-* [{#T}](../devops/manual/system-views.md).
-* [{#T}](../administration/monitoring.md).
-* [{#T}](../administration/upgrade.md).
diff --git a/ydb/docs/en/core/cluster/logs.md b/ydb/docs/en/core/cluster/logs.md
deleted file mode 100644
index db3eb2468686..000000000000
--- a/ydb/docs/en/core/cluster/logs.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Logs
-Each YDB component writes messages to logs at different levels. They can be used to detect severe issues or identify the root causes of issues.
-
-## Logging setup {#log_setup}
-You can configure logging for the various components of the YDB [monitoring system](../maintenance/embedded_monitoring/logs.md#change_log_level).
-
-There are currently two options for running YDB logging.
-
-### Manually {#log_setup_manually}
-YDB provides standard mechanisms for collecting logs and metrics.
-Logging is done to standard `stdout` and `stderr` streams and can be redirected using popular solutions. We recommend using a combination of Fluentd and Elastic Stack.
-
-### Using systemd {#log_setup_systemd}
-Default logs are written to `journald` and can be retrieved via
-```
-journalctl -u ydbd
-```
diff --git a/ydb/docs/en/core/cluster/system-requirements.md b/ydb/docs/en/core/cluster/system-requirements.md
deleted file mode 100644
index 63f6fc4ba141..000000000000
--- a/ydb/docs/en/core/cluster/system-requirements.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# System requirements and recommendations
-
-This section provides recommendations for deploying {{ ydb-short-name }}.
-
-## Hardware configuration {#hardware}
-
-The number of servers and disks is determined by the fault-tolerance requirements. For more information, see [{#T}](topology.md).
-
-* **Processor**
-
-   A {{ ydb-short-name }} server can only run on x86-64 processors with AVX2 instruction support: Intel Haswell (4th generation) and later, AMD EPYC and later.
-
-   The ARM architecture is currently not supported.
-
-* **RAM**
-
-   We recommend using error-correcting code (ECC) memory to protect against hardware failures.
-
-* **Disk subsystem**
-
-   A {{ ydb-short-name }} server can run on servers with any disk type (HDD/SSD/NVMe). However, we recommend using SSD/NVMe disks for better performance.
-
-   {% include [_includes/storage-device-requirements.md](../_includes/storage-device-requirements.md) %}
-
-   {{ ydb-short-name }} does not use a file system to store data and accesses disk volumes directly. Don't mount a file system or perform other operations with a partition that uses {{ ydb-short-name }}. We also do not recommend sharing the block device with other processes because this can lead to significant performance degradation.
-
-   {{ ydb-short-name }} health and performance weren't tested on any types of virtual or network storage devices.
-
-   When planning space, remember that {{ ydb-short-name }} uses some disk space for its own internal needs. For example, on a medium-sized cluster of 8 nodes, you can expect approximately 100 GB to be consumed for a static group on the whole cluster. On a large cluster with more than 1500 nodes, this will be about 200 GB. There are also logs of 25.6 GB on each Pdisk and a system area on each Pdisk. Its size depends on the size of the Pdisk, but is no less than 0.2 GB.
-
-## Software configuration {#software}
-
-A {{ ydb-short-name }} server can be run on servers running a Linux operating system with kernel 4.19 and higher and libc 2.30 (Ubuntu 20.04, Debian 11, Fedora34). YDB uses the [TCMalloc](https://google.github.io/tcmalloc) memory allocator. To make it effective, [enable](https://google.github.io/tcmalloc/tuning.html#system-level-optimizations) Transparent Huge Pages and Memory overcommitment.
-
-If the server has more than 32 CPU cores, to increase YDB performance, it makes sense to run each dynamic node in a separate taskset/cpuset of 10 to 32 cores. For example, in the case of 128 CPU cores, the best choice is to run four 32-CPU dynamic nodes, each in its taskset.
-
-MacOS and Windows operating systems are currently not supported for running {{ ydb-short-name }} servers.
diff --git a/ydb/docs/en/core/cluster/toc_i.yaml b/ydb/docs/en/core/cluster/toc_i.yaml
deleted file mode 100644
index 2b4297cc9ab7..000000000000
--- a/ydb/docs/en/core/cluster/toc_i.yaml
+++ /dev/null
@@ -1,27 +0,0 @@
-items:
-- name: Deployment
-  include: { mode: link, path: ../deploy/toc_p.yaml }
-- name: Access management
-  href: access.md
-- name: Managing a cluster's disk subsystem
-  include: { mode: link, path: ../maintenance/manual/toc_p.yaml }
-- name: Embedded UI
-  include: { mode: link, path: ../maintenance/embedded_monitoring/toc_p.yaml }
-- name: Cluster system views
-  href: ../devops/manual/system-views.md
-- name: Audit log
-  href: audit-log.md
-- name: Short access control notation
-  href: short-access-control-notation.md
-- name: Monitoring
-  items:
-    - name: Setting up monitoring for a local YDB cluster
-      href: ../administration/monitoring.md
-    - name: Grafana dashboards
-      href: ../administration/grafana-dashboards.md
-- name: Updating YDB
-  href: ../administration/upgrade.md
-- name: Changing an actor system's configuration
-  href: ../maintenance/manual/change_actorsystem_configs.md
-- name: Updating configurations via CMS
-  href: ../maintenance/manual/cms.md
diff --git a/ydb/docs/en/core/concepts/auth.md b/ydb/docs/en/core/concepts/auth.md
index d90bd462f9d7..09a9be04a8f3 100644
--- a/ydb/docs/en/core/concepts/auth.md
+++ b/ydb/docs/en/core/concepts/auth.md
@@ -54,7 +54,7 @@ Authentication by username and password includes the following steps:
 
 To enable username/password authentication, use `true` in the `enforce_user_token_requirement` key of the cluster's [configuration file](../deploy/configuration/config.md#auth).
 
-To learn how to manage roles and users, see [{#T}](../cluster/access.md).
+To learn how to manage roles and users, see [{#T}](../security/access-management.md).
 
 <!-- ### API получения токенов IAM {#token-refresh-api}
 
diff --git a/ydb/docs/en/core/concepts/toc_i.yaml b/ydb/docs/en/core/concepts/toc_i.yaml
index eae2d485a1d3..e925c625f955 100644
--- a/ydb/docs/en/core/concepts/toc_i.yaml
+++ b/ydb/docs/en/core/concepts/toc_i.yaml
@@ -17,6 +17,8 @@ items:
   items:
   - name: Overview
     href: cluster/index.md
+  - name: Topology
+    href: topology.md
   - name: General YDB schema
     href: cluster/common_scheme_ydb.md
   - name: Disk subsystem of a cluster
diff --git a/ydb/docs/en/core/cluster/topology.md b/ydb/docs/en/core/concepts/topology.md
similarity index 100%
rename from ydb/docs/en/core/cluster/topology.md
rename to ydb/docs/en/core/concepts/topology.md
diff --git a/ydb/docs/en/core/contributor/load-actors-storage.md b/ydb/docs/en/core/contributor/load-actors-storage.md
index b36d6354c38f..a6c5a2861746 100644
--- a/ydb/docs/en/core/contributor/load-actors-storage.md
+++ b/ydb/docs/en/core/contributor/load-actors-storage.md
@@ -146,4 +146,4 @@ StorageLoad: {
     }
 }
 ```
-Calculated percentiles will only represent the requests of the main load cycle and won't include write requests sent during the initial data allocation. The [graphs in Monitoring](../administration/grafana-dashboards.md) should be of interest, for example, they allow to trace the request latency degradation caused by the increasing load.
+Calculated percentiles will only represent the requests of the main load cycle and won't include write requests sent during the initial data allocation. The [graphs in Monitoring](../reference/observability/metrics/grafana-dashboards.md) should be of interest, for example, they allow to trace the request latency degradation caused by the increasing load.
diff --git a/ydb/docs/en/core/contributor/manage-releases.md b/ydb/docs/en/core/contributor/manage-releases.md
index a467d2aa7f46..1b7635d76286 100644
--- a/ydb/docs/en/core/contributor/manage-releases.md
+++ b/ydb/docs/en/core/contributor/manage-releases.md
@@ -21,7 +21,7 @@ Thus, {{ ydb-short-name }} server major version is a combination of the first tw
 
 ### Compatibility {#server-compatibility}
 
-{{ ydb-short-name }} maintains compatibility between major versions to ensure a cluster can operate while its nodes run two adjacent major versions of the YDB server executable. You may refer the [Updating {{ ydb-short-name }}](../administration/upgrade.md) article to learn more about the cluster upgrade procedure.
+{{ ydb-short-name }} maintains compatibility between major versions to ensure a cluster can operate while its nodes run two adjacent major versions of the YDB server executable. You may refer the [Updating {{ ydb-short-name }}](../devops/manual/upgrade.md) article to learn more about the cluster upgrade procedure.
 
 Given the above compatibility target, major releases go in pairs: odd numbered releases add new functionality switched off by feature flags, and even numbered releases enable that functionality by default.
 
diff --git a/ydb/docs/en/core/dba/toc_p.yaml b/ydb/docs/en/core/dba/toc_p.yaml
index 94ce11086840..10239b707f4b 100644
--- a/ydb/docs/en/core/dba/toc_p.yaml
+++ b/ydb/docs/en/core/dba/toc_p.yaml
@@ -1,4 +1,6 @@
 items:
 - name: Overview
   href: index.md
-- include: { mode: link, path: toc_i.yaml }
\ No newline at end of file
+- include:
+    mode: link
+    path: toc_i.yaml
\ No newline at end of file
diff --git a/ydb/docs/en/core/deploy/_includes/index.md b/ydb/docs/en/core/deploy/_includes/index.md
index f5d4b4adb6a3..17f7cde55544 100644
--- a/ydb/docs/en/core/deploy/_includes/index.md
+++ b/ydb/docs/en/core/deploy/_includes/index.md
@@ -1,13 +1,12 @@
-# Deploying YDB clusters
+# Deploying {{ ydb-short-name }} clusters
 
-This section provides information on deploying and configuring multi-node YDB clusters that serve multiple databases.
+This section provides information on deploying and configuring multi-node {{ ydb-short-name }} clusters that serve multiple databases.
 
-* [{#T}](../../cluster/system-requirements.md).
-* [{#T}](../../cluster/topology.md).
+* [{#T}](../../devops/system-requirements.md).
+* [{#T}](../../concepts/topology.md).
 * [Deployment with Ansible](../../devops/ansible/index.md).
 * [Deployment with Kubernetes](../../devops/kubernetes/index.md).
 * [Deployment on virtual and physical servers](../manual/deploy-ydb-on-premises.md).
 * [Configuration](../configuration/config.md).
-* [BlobStorage production configurations](../../administration/production-storage-config.md).
 
 Step-by-step scenarios for rapidly deploying a local single-node cluster for development and testing are given in the [Quick start](../../quickstart.md) section.
diff --git a/ydb/docs/en/core/deploy/configuration/config.md b/ydb/docs/en/core/deploy/configuration/config.md
index a41fa70b3e3f..b0b74d1a64f2 100644
--- a/ydb/docs/en/core/deploy/configuration/config.md
+++ b/ydb/docs/en/core/deploy/configuration/config.md
@@ -1,4 +1,4 @@
-# Cluster configuration
+# {{ ydb-short-name }} cluster configuration
 
 The cluster configuration is specified in the YAML file passed in the `--yaml-config` parameter when the cluster nodes are run.
 
@@ -147,7 +147,7 @@ This section defines one or more types of storage pools available in the cluster
 - Data encryption (on/off)
 - Fault tolerance mode
 
-The following [fault tolerance modes](../../cluster/topology.md) are available:
+The following [fault tolerance modes](../../concepts/topology.md) are available:
 
 | Mode | Description |
 --- | ---
@@ -389,7 +389,7 @@ You can set up your actor system either [automatically](#autoconfig) or [manuall
 
 Automatic configuring adapts to the current system workload. It is recommended in most cases.
 
-You might opt for manual configuring when a certain pool in your actor system is overwhelmed and undermines the overall database performance. You can track the workload on your pools on the [Embedded UI monitoring page](../../maintenance/embedded_monitoring/ydb_monitoring.md#node_list_page).
+You might opt for manual configuring when a certain pool in your actor system is overwhelmed and undermines the overall database performance. You can track the workload on your pools on the [Embedded UI monitoring page](../../reference/embedded-ui/ydb-monitoring.md#node_list_page).
 
 ### Automatic configuring {#autoconfig}
 
@@ -479,6 +479,86 @@ blob_storage_config:
 
 For a configuration located in 3 availability zones, specify 3 rings. For a configuration within a single availability zone, specify exactly one ring.
 
+## BlobStorage production configurations
+
+To ensure the required fault tolerance of {{ ydb-short-name }}, configure the [cluster disk subsystem](../../concepts/cluster/distributed_storage.md) properly: select the appropriate [fault tolerance mode](#fault-tolerance) and [hardware configuration](#requirements) for your cluster.
+
+### Fault tolerance modes {#fault-tolerance}
+
+We recommend using the following [fault tolerance modes](../../concepts/topology.md) for {{ ydb-short-name }} production installations:
+
+* `block-4-2`: For a cluster hosted in a single availability zone.
+* `mirror-3-dc`: For a cluster hosted in three availability zones.
+
+A fail model of {{ ydb-short-name }} is based on concepts such as fail domain and fail realm.
+
+Fail domain
+
+: A set of hardware that may fail concurrently.
+
+  For example, a fail domain includes disks of the same server (as all server disks may be unavailable if the server PSU or network controller is down). A fail domain also includes servers located in the same server rack (as the entire hardware in the rack may be unavailable if there is a power outage or some issue with the network hardware in the same rack).
+
+  Any domain fail is handled automatically, without shutting down the system.
+
+Fail realm
+
+: A set of fail domains that may fail concurrently.
+
+  An example of a fail realm is hardware located in the same data center that may fail as a result of a natural disaster.
+
+Usually a fail domain is a server rack, while a fail realm is a data center.
+
+When creating a [storage group](../../concepts/databases.md#storage-groups), {{ ydb-short-name }} groups VDisks that are located on PDisks from different fail domains. For `block-4-2` mode, a PDisk should be distributed across at least 8 fail domains, and for `mirror-3-dc` mode, across 3 fail realms with at least 3 fail domains in each of them.
+
+### Hardware configuration {#requirements}
+
+If a disk fails, {{ ydb-short-name }} may automatically reconfigure a storage group so that, instead of the VDisk located on the failed hardware, a new VDisk is used that the system tries to place on hardware that is running while the group is being reconfigured. In this case, the same rule applies as when creating a group: a VDisk is created in a fail domain that is different from the fail domains of any other VDisk in this group (and in the same fail realm as that of the failed VDisk for `mirror-3-dc`).
+
+This causes some issues when a cluster's hardware is distributed across the minimum required amount of fail domains:
+
+* If the entire fail domain is down, reconfiguration no longer makes sense, since a new VDisk can only be located in the fail domain that is down.
+* If part of a fail domain is down, reconfiguration is possible, but the load that was previously handled by the failed hardware will only be redistributed across hardware in the same fail domain.
+
+If the number of fail domains in a cluster exceeds the minimum amount required for creating storage groups at least by one (that is, 9 domains for `block-4-2` and 4 domains in each fail realm for `mirror-3-dc)`, in case some hardware fails, the load can be redistributed across all the hardware that is still running.
+
+The system can work with fail domains of any size. However, if there are few domains and a different number of disks in different domains, the number of storage groups that you can create will be limited. In this case, some hardware in fail domains that are too large may be underutilized. If the hardware is used in full, significant distortions in domain sizes may make reconfiguration impossible.
+
+For example, there are 15 racks in a cluster with `block-4-2` fault tolerance mode. The first of the 15 racks hosts 20 servers and the other 14 racks host 10 servers each. To fully utilize all the 20 servers from the first rack, {{ ydb-short-name }} will create groups so that 1 disk from this largest fail domain is used in each group. As a result, if any other fail domain's hardware is down, the load can't be distributed to the hardware in the first rack.
+
+{{ ydb-short-name }} can group disks of different vendors, capacity, and speed. The resulting characteristics of a group depend on a set of the worst characteristics of the hardware that is serving the group. Usually the best results can be achieved if you use same-type hardware. When creating large clusters, keep in mind that hardware from the same batch is more likely to have the same defect and fail simultaneously.
+
+Therefore, we recommend the following optimal hardware configurations for production installations:
+
+* **A cluster hosted in 1 availability zone**: It uses `block4-2` fault tolerance mode and consists of 9 or more racks with the same amount of identical servers in each rack.
+* **A cluster hosted in 3 availability zones**: It uses `mirror3-dc` fault tolerance mode and is distributed across 3 data centers with 4 or more racks in each of them, the racks being equipped with the same amount of identical servers.
+
+See also [{#T}](#reduced).
+
+### Redundancy recovery {#rebuild}
+
+Auto reconfiguration of storage groups reduces the risk of data loss in the event of multiple failures that occur within intervals sufficient to recover the redundancy. By default, reconfiguration is done one hour after {{ ydb-short-name }} detects a failure.
+
+Once a group is reconfigured, a new VDisk is automatically populated with data to restore the required storage redundancy in the group. This increases the load on other VDisks in the group and the network. To reduce the impact of redundancy recovery on the system performance, the total data replication speed is limited both on the source and target VDisks.
+
+The time it takes to restore the redundancy depends on the amount of data and hardware performance. For example, replication on fast NVMe SSDs may take an hour, while on large HDDs more than 24 hours. To make reconfiguration possible in general, a cluster should have free slots for creating VDisks in different fail domains. When determining the number of slots to be kept free, factor in the risk of hardware failure, the time it takes to replicate data and replace the failed hardware.
+
+### Simplified hardware configurations {#reduced}
+
+If it's not possible to use the [recommended amount](#requirements) of hardware, you can divide servers within a single rack into two dummy fail domains. In this configuration, a failure of 1 rack means a failure of 2 domains and not a single one. In [both fault tolerance modes](#fault-tolerance), {{ ydb-short-name }} will keep running if 2 domains fail. If you use the configuration with dummy fail domains, the minimum number of racks in a cluster is 5 for `block-4-2` mode and 2 in each data center for `mirror-3-dc` mode.
+
+### Fault tolerance level {#reliability}
+
+The table below describes fault tolerance levels for different fault tolerance modes and hardware configurations of a {{ ydb-short-name }} cluster:
+
+Fault tolerance<br>mode | Fail<br>domain | Fail<br>realm | Number of<br>data centers | Number of<br>server racks | Fault tolerance<br>level
+:--- | :---: | :---: | :---: | :---: | :---
+`block-4-2` | Rack | Data center | 1 | 9 or more | Can stand a failure of 2 racks
+`block-4-2` | ½ a rack | Data center | 1 | 5 or more | Can stand a failure of 1 rack
+`block-4-2` | Server | Data center | 1 | Doesn't matter | Can stand a failure of 2 servers
+`mirror-3-dc` | Rack | Data center | 3 | 4 in each data center | Can stand a failure of a data center and 1 rack in one of the two other data centers
+`mirror-3-dc` | Server | Data center | 3 | Doesn't matter | Can stand a failure of a data center and 1 server in one of the two other data centers
+
+
 ## Sample cluster configurations {#examples}
 
 You can find model cluster configurations for deployment in the [repository](https://github.com/ydb-platform/ydb/tree/main/ydb/deploy/yaml_config_examples/). Check them out before deploying a cluster.
diff --git a/ydb/docs/en/core/deploy/manual/deploy-ydb-on-premises.md b/ydb/docs/en/core/deploy/manual/deploy-ydb-on-premises.md
index 3dd4f96843a4..51c6eeb1ba40 100644
--- a/ydb/docs/en/core/deploy/manual/deploy-ydb-on-premises.md
+++ b/ydb/docs/en/core/deploy/manual/deploy-ydb-on-premises.md
@@ -6,7 +6,7 @@ This document describes how to deploy a multi-tenant {{ ydb-short-name }} cluste
 
 ### Prerequisites {#requirements}
 
-Review the [system requirements](../../cluster/system-requirements.md) and the [cluster topology](../../cluster/topology.md).
+Review the [system requirements](../../devops/system-requirements.md) and the [cluster topology](../../concepts/topology.md).
 
 Make sure you have SSH access to all servers. This is required to install artifacts and run the {{ ydb-short-name }} executable.
 
@@ -17,7 +17,7 @@ The network configuration must allow TCP connections on the following ports (the
 * 19001, 19002: Interconnect for intra-cluster node interaction
 * 8765, 8766: HTTP interface of {{ ydb-short-name }} Embedded UI.
 
-Distinct ports are necessary for GRPC, Interconnect and HTTP interface of each dynamic node when hosting multiple dynamic nodes on a single server.
+Distinct ports are necessary for gRPC, Interconnect and HTTP interface of each dynamic node when hosting multiple dynamic nodes on a single server.
 
 Make sure that the system clocks running on all the cluster's servers are synced by `ntpd` or `chrony`. We recommend using the same time source for all servers in the cluster to maintain consistent leap seconds processing.
 
@@ -34,7 +34,7 @@ Run each static node (data node) on a separate server. Both static and dynamic n
 
 {% endnote %}
 
-For more information about hardware requirements, see [{#T}](../../cluster/system-requirements.md).
+For more information about hardware requirements, see [{#T}](../../devops/system-requirements.md).
 
 ### Preparing TLS keys and certificates {#tls-certificates}
 
@@ -403,7 +403,7 @@ Run additional dynamic nodes on other servers to ensure database scalability and
 
 If authentication mode is enabled in the cluster configuration file, initial account setup must be done before working with the {{ ydb-short-name }} cluster.
 
-The initial installation of the {{ ydb-short-name }} cluster automatically creates a `root` account with a blank password, as well as a standard set of user groups described in the [Access management](../../cluster/access.md) section.
+The initial installation of the {{ ydb-short-name }} cluster automatically creates a `root` account with a blank password, as well as a standard set of user groups described in the [Access management](../../security/access-management.md) section.
 
 To perform initial account setup in the created {{ ydb-short-name }} cluster, run the following operations:
 
@@ -455,7 +455,7 @@ To check access to the {{ ydb-short-name }} built-in web interface, open in the
 
 In the web browser, set as trusted the certificate authority that issued certificates for the {{ ydb-short-name }} cluster. Otherwise, you will see a warning about an untrusted certificate.
 
-If authentication is enabled in the cluster, the web browser should prompt you for a login and password. Enter your credentials, and you'll see the built-in interface welcome page. The user interface and its features are described in [{#T}](../../maintenance/embedded_monitoring/index.md).
+If authentication is enabled in the cluster, the web browser should prompt you for a login and password. Enter your credentials, and you'll see the built-in interface welcome page. The user interface and its features are described in [{#T}](../../reference/embedded-ui/index.md).
 
 {% note info %}
 
diff --git a/ydb/docs/en/core/deploy/toc_i.yaml b/ydb/docs/en/core/deploy/toc_i.yaml
index 3dc62997242f..1ea4a7aea439 100644
--- a/ydb/docs/en/core/deploy/toc_i.yaml
+++ b/ydb/docs/en/core/deploy/toc_i.yaml
@@ -3,6 +3,4 @@ items:
   href: manual/deploy-ydb-on-premises.md
 - name: Configuration
   href: configuration/config.md
-- name: BlobStorage production configurations
-  href: ../administration/production-storage-config.md
 
diff --git a/ydb/docs/en/core/deploy/toc_p.yaml b/ydb/docs/en/core/deploy/toc_p.yaml
index 2b153d64d3fb..94ce11086840 100644
--- a/ydb/docs/en/core/deploy/toc_p.yaml
+++ b/ydb/docs/en/core/deploy/toc_p.yaml
@@ -1,10 +1,4 @@
 items:
 - name: Overview
   href: index.md
-- name: System requirements and recommendations
-  href: ../cluster/system-requirements.md
-- name: Logging
-  href: ../cluster/logs.md
-- name: Topology
-  href: ../cluster/topology.md
 - include: { mode: link, path: toc_i.yaml }
\ No newline at end of file
diff --git a/ydb/docs/en/core/dev/batch-upload.md b/ydb/docs/en/core/dev/batch-upload.md
index 34863e4f07f2..e111b6d24b44 100644
--- a/ydb/docs/en/core/dev/batch-upload.md
+++ b/ydb/docs/en/core/dev/batch-upload.md
@@ -1,6 +1,6 @@
 # Uploading data to {{ ydb-short-name }}
 
-This section provides recommendations on how to efficiently upload data to {{ ydb-short-name }}.
+This section provides recommendations on efficiently uploading data to {{ ydb-short-name }}.
 
 There are anti-patterns and non-optimal settings for uploading data. They don't guarantee acceptable data uploading performance.
 To accelerate data uploads, consider the following recommendations:
@@ -10,20 +10,20 @@ To accelerate data uploads, consider the following recommendations:
    The acceptable size for splitting a table shard is 2 GB. As the number of shards grows, the data upload bandwidth increases, but it remains low for some time at first.
    Therefore, when uploading a large amount of data for the first time, we recommend initially creating a table with the desired number of shards. You can calculate the number of shards based on 1 GB of data per shard in a resulting set.
 * Insert multiple rows in each transaction to reduce the overhead of the transactions themselves.
-   Each transaction in {{ ydb-short-name }} has some overhead. To reduce the total overhead, you should make transactions that insert multiple rows. Good performance indicators terminate a transaction when it reaches 1 MB of data or 100,000 rows.
-   When uploading data, avoid transactions that insert a single row.
-* Within each transaction, insert rows from the primary key-sorted set to minimize the number of shards that the transaction affects.
-   In {{ ydb-short-name }}, transactions that span multiple shards have higher overhead compared to transactions that involve exactly one shard. Moreover, this overhead increases with the growing number of table shards involved in the transaction.
+   Each transaction in {{ ydb-short-name }} has some overhead. It is recommended to make transactions that insert multiple rows to reduce the total overhead. Good performance indicators terminate a transaction when it reaches 1 MB of data or 100,000 rows.
+    When uploading data, avoid transactions that insert a single row.
+* Within each transaction, insert rows from the primary key-sorted set to minimize the number of shards affected by each transaction.
+   In {{ ydb-short-name }}, transactions that span multiple shards have a higher overhead compared to transactions that involve exactly one shard. Moreover, this overhead increases with the growing number of table shards involved in the transaction.
    We recommend selecting rows to be inserted in a particular transaction so that they're located in a small number of shards, ideally, in one.
 * If you need to push data to multiple tables, we recommend pushing data to a single table within a single query.
 * If you need to push data to a table with a synchronous secondary index, we recommend that you first push data to a table and, when done, build a secondary index.
 * You should avoid writing data sequentially in ascending or descending order of the primary key.
-   Writing data to a table with a monotonically increasing key causes all new data to be written to the end of the table, since all tables in YDB are sorted by ascending primary key. As YDB splits table data into shards based on key ranges, inserts are always processed by the same server that is responsible for the "last" shard. Concentrating the load on a single server will result in slow data uploading and inefficient use of a distributed system.
-* Some use cases require writing the initial data (often large amounts) to a table before enabling OLTP workloads. In this case, transactionality at the level of individual queries is not required and you can use ```BulkUpsert``` calls in the API and SDK. Since no transactionality is used, this approach has much lower overhead as compared to YQL queries. In case of a successful response to the query, the ```BulkUpsert``` method guarantees that all data added within this query is committed.
+   Writing data to a table with a monotonically increasing key causes all new data to be written to the end of the table since all tables in YDB are sorted by ascending primary key. As YDB splits table data into shards based on key ranges, inserts are always processed by the same server responsible for the "last" shard. Concentrating the load on a single server will result in slow data uploading and inefficient use of a distributed system.
+* Some use cases require writing the initial data (often large amounts) to a table before enabling OLTP workloads. In this case, transactionality at the level of individual queries is not required, and you can use `BulkUpsert` calls in the [CLI](../reference/ydb-cli/export-import/tools-restore.md), [SDK](../reference/ydb-sdk/recipes/bulk-upsert.md) and API. Since no transactionality is used, this approach has a much lower overhead than YQL queries. In case of a successful response to the query, the `BulkUpsert` method guarantees that all data added within this query is committed.
 
 {% note warning %}
 
-The ```BulkUpsert``` method isn't supported for tables with secondary indexes.
+The `BulkUpsert` method isn't supported for tables with secondary indexes.
 
 {% endnote %}
 
@@ -34,4 +34,4 @@ We recommend the following algorithm for efficiently uploading data to {{ ydb-sh
 2. Sort the source data set by the expected primary key.
 3. Partition the resulting data set by the number of shards in the table. Each part will contain a set of consecutive rows.
 4. Upload the resulting parts to the table shards concurrently.
-5. Make a ```COMMIT``` after every 100,000 rows or 1 MB of data.
+5. Make a `COMMIT` after every 100,000 rows or 1 MB of data.
diff --git a/ydb/docs/en/core/dev/example-app/_includes/index.md b/ydb/docs/en/core/dev/example-app/_includes/index.md
index 8a7c040bc7e3..299f8e98168f 100644
--- a/ydb/docs/en/core/dev/example-app/_includes/index.md
+++ b/ydb/docs/en/core/dev/example-app/_includes/index.md
@@ -12,6 +12,12 @@ This section describes the code of same-type test apps implemented using {{ ydb-
 - [Node.js](../example-nodejs.md)
 - [Python](../python/index.md)
 
+{% node info %}
+
+Additional information on how these example applications work is available in [{{ ydb-short-name }} SDK reference documentation](../../../reference/ydb-sdk/index.md).
+
+{% endnote %}
+
 A test app performs the following steps:
 
 {% include [init.md](steps/01_init.md) %}
diff --git a/ydb/docs/en/core/dev/getting-started.md b/ydb/docs/en/core/dev/getting-started.md
index 11c1bb3c1b7f..aade8cd0a2a0 100644
--- a/ydb/docs/en/core/dev/getting-started.md
+++ b/ydb/docs/en/core/dev/getting-started.md
@@ -22,7 +22,7 @@ Choose the specific programming language you'll be using. [Install the respectiv
 Additionally, you'd want to set up at least one of the available ways to run ad-hoc queries for debugging purposes. Choose at least one according to your preferences:
 
 * [YDB CLI](../reference/ydb-cli/install.md)
-* [Embedded UI](../maintenance/embedded_monitoring/index.md)
+* [Embedded UI](../reference/embedded-ui/index.md)
 * Any SQL IDE that supports [JDBC](https://github.com/ydb-platform/ydb-jdbc-driver)
 * [psql](https://www.postgresql.org/docs/14/app-psql.html) or [pgAdmin](https://www.pgadmin.org/) for the PostgreSQL-compatible route.
 
diff --git a/ydb/docs/en/core/dev/index.md b/ydb/docs/en/core/dev/index.md
index 6a46eba89559..b54924c81928 100644
--- a/ydb/docs/en/core/dev/index.md
+++ b/ydb/docs/en/core/dev/index.md
@@ -1,6 +1,6 @@
 # {{ ydb-short-name }} for Application Developers / Software Engineers
 
-This section of {{ ydb-short-name }} documentation covers everything you need to know to develop applications interacting with YDB.
+This section of {{ ydb-short-name }} documentation covers everything you need to know to develop applications interacting with {{ ydb-short-name }}.
 
 Main resources:
 
@@ -10,5 +10,11 @@ Main resources:
 - [{#T}](batch-upload.md)
 - [{#T}](paging.md)
 - [{#T}](timeouts.md)
+- Reference:
+  - [{#T}](../yql/reference/index.md)
+  - [{#T}](../reference/ydb-sdk/index.md)
+  - [{#T}](../reference/ydb-cli/index.md)
+  - [{#T}](../postgresql/intro.md)
+  - [{#T}](../reference/kafka-api/index.md)
 
 If you're interested in developing {{ ydb-short-name }} core or satellite projects, refer to the [documentation for contributors](../contributor/index.md).
\ No newline at end of file
diff --git a/ydb/docs/en/core/dev/yql-tutorial/_includes/index/intro.md b/ydb/docs/en/core/dev/yql-tutorial/_includes/index/intro.md
index d6c6b823f19a..f8059dd84d9d 100644
--- a/ydb/docs/en/core/dev/yql-tutorial/_includes/index/intro.md
+++ b/ydb/docs/en/core/dev/yql-tutorial/_includes/index/intro.md
@@ -1,12 +1,4 @@
----
-title: YQL tutorial. Basic operations
-description: From this tutorial, you will learn how to perform basic operations with data and get familiar with the YQL syntax.
-keywords:
-  - yql
-  - yql tutorial
-  - yql basic operations
----
 # YQL Tutorial - Overview
 
-From this tutorial, you will learn how to perform basic operations with data in {{ ydb-short-name }} and get familiar with the YQL syntax.
+From this tutorial, you will learn how to perform basic operations with data in {{ ydb-short-name }} and get familiar with the YQL syntax. A detailed description of this syntax is also available in the [YQL reference documentation](../../../../yql/reference/index.md).
 
diff --git a/ydb/docs/en/core/devops/_includes/fault-tolerance.md b/ydb/docs/en/core/devops/_includes/fault-tolerance.md
new file mode 100644
index 000000000000..1de987495ad8
--- /dev/null
+++ b/ydb/docs/en/core/devops/_includes/fault-tolerance.md
@@ -0,0 +1,5 @@
+{% note info %}
+
+{{ ydb-short-name }} cluster is fault tolerant. Temporarily shutting down a node doesn't affect the cluster availability. For details, see [{#T}](../../concepts/topology.md).
+
+{% endnote %}
diff --git a/ydb/docs/en/core/_includes/warning-configuration-error.md b/ydb/docs/en/core/devops/_includes/warning-configuration-error.md
similarity index 100%
rename from ydb/docs/en/core/_includes/warning-configuration-error.md
rename to ydb/docs/en/core/devops/_includes/warning-configuration-error.md
diff --git a/ydb/docs/en/core/devops/ansible/initial-deployment.md b/ydb/docs/en/core/devops/ansible/initial-deployment.md
index 572a9fe73a0c..0473d451e866 100644
--- a/ydb/docs/en/core/devops/ansible/initial-deployment.md
+++ b/ydb/docs/en/core/devops/ansible/initial-deployment.md
@@ -219,7 +219,7 @@ The sequence of role executions and their brief descriptions:
 
 {% endcut %}
 
-As a result of executing the playbook, a {{ ydb-short-name }} cluster will be created, with a test database named `database`, a `root` user with maximum access rights created, and [Embedded UI](../../maintenance/embedded_monitoring/index.md) running on port 8765. To connect to the Embedded UI, you can set up SSH tunneling. For this, execute the command `ssh -L 8765:localhost:8765 -i <ssh private key> <user>@<first-ydb-static-node-ip>` on your local machine. After successfully establishing the connection, you can navigate to the URL [localhost:8765](http://localhost:8765):
+As a result of executing the playbook, a {{ ydb-short-name }} cluster will be created, with a test database named `database`, a `root` user with maximum access rights created, and [Embedded UI](../../reference/embedded-ui/index.md) running on port 8765. To connect to the Embedded UI, you can set up SSH tunneling. For this, execute the command `ssh -L 8765:localhost:8765 -i <ssh private key> <user>@<first-ydb-static-node-ip>` on your local machine. After successfully establishing the connection, you can navigate to the URL [localhost:8765](http://localhost:8765):
 
 ![ydb-web-ui](../../_assets/ydb-web-console.png)
 
@@ -238,7 +238,7 @@ You can check the state of the storage group in the `storage` section – [http:
 
 ![ydb-storage-gr-check](../../_assets/ydb-storage-gr-check.png)
 
-The `VDisks` indicators should be green, and the `state` status (found in the tooltip when hovering over the Vdisk indicator) should be `Ok`. More about the cluster state indicators and monitoring can be read in the article [{#T}](../../maintenance/embedded_monitoring/ydb_monitoring.md).
+The `VDisks` indicators should be green, and the `state` status (found in the tooltip when hovering over the Vdisk indicator) should be `Ok`. More about the cluster state indicators and monitoring can be read in the article [{#T}](../../reference/embedded-ui/ydb-monitoring.md).
 
 ## Cluster Testing { #testing }
 
diff --git a/ydb/docs/en/core/devops/index.md b/ydb/docs/en/core/devops/index.md
index 28ce24976442..b422dcf730ab 100644
--- a/ydb/docs/en/core/devops/index.md
+++ b/ydb/docs/en/core/devops/index.md
@@ -4,4 +4,6 @@ This section of {{ ydb-short-name }} documentation covers everything you need to
 
 * **[Ansible](ansible/index.md)**: for deployments on bare metal and virtual machines.
 * **[Kubernetes](kubernetes/index.md)**: for containerized deployments.
-* **[Manual](../cluster/index.md)**: generic instructions.
+* **[Manual](manual/index.md)**: generic instructions.
+
+Regardless of the chosen infrastructure management method, it is recommended to familiarize yourself with [{{ ydb-short-name }} system requirements](system-requirements.md) first.
\ No newline at end of file
diff --git a/ydb/docs/en/core/devops/kubernetes/initial-deployment.md b/ydb/docs/en/core/devops/kubernetes/initial-deployment.md
index f0155313bf4a..e9439163a928 100644
--- a/ydb/docs/en/core/devops/kubernetes/initial-deployment.md
+++ b/ydb/docs/en/core/devops/kubernetes/initial-deployment.md
@@ -135,7 +135,7 @@ Use `helm` to deploy the {{ ydb-short-name }} {{ k8s }} operator to the cluster:
 
 ### Deploy storage nodes
 
-{{ ydb-short-name }} supports a number of [storage topologies](../../cluster/topology.md). {{ ydb-short-name }} {{ k8s }} operator comes with a few sample configuration files for the most common topologies. This guide uses them as-is, but feel free to adjust them as needed or implement a new configuration file from scratch.
+{{ ydb-short-name }} supports a number of [storage topologies](../../concepts/topology.md). {{ ydb-short-name }} {{ k8s }} operator comes with a few sample configuration files for the most common topologies. This guide uses them as-is, but feel free to adjust them as needed or implement a new configuration file from scratch.
 
 Apply the manifest for creating storage nodes:
 
@@ -171,7 +171,7 @@ The cluster configuration is static. The controller won't process any changes wh
 
 ### Create a database and dynamic nodes
 
-{{ ydb-short-name }} database is a logical entity that is served by a number of dynamic nodes. A sample manifest that comes with {{ ydb-short-name }} {{ k8s }} operator creates a database named `database-sample` with 3 dynamic nodes. As with storage nodes, feel free to adjust the configuration as needed.
+{{ ydb-short-name }} database is a logical entity that is served by a set of dynamic nodes. A sample manifest that comes with {{ ydb-short-name }} {{ k8s }} operator creates a database named `database-sample` with 3 dynamic nodes. As with storage nodes, feel free to adjust the configuration as needed.
 
 Apply the manifest for creating a database and dynamic nodes:
 
diff --git a/ydb/docs/en/core/administration/decommissioning.md b/ydb/docs/en/core/devops/manual/decommissioning.md
similarity index 72%
rename from ydb/docs/en/core/administration/decommissioning.md
rename to ydb/docs/en/core/devops/manual/decommissioning.md
index 12d6fb0f98bd..0db66541eda8 100644
--- a/ydb/docs/en/core/administration/decommissioning.md
+++ b/ydb/docs/en/core/devops/manual/decommissioning.md
@@ -20,18 +20,18 @@ To cancel decommissioning, just change the disk status to `DECOMMIT_NONE`. In th
 
 By managing the `DECOMMIT_PENDING` and `DECOMMIT_IMMINENT` states, you can perform cluster decommissioning in parts.
 
-> For example, you need to move equipment from data center-1 (DC-1) to data center-2 (DC-2):
->
-> 1. The DC-2 hosts buffer equipment to transfer the first chunk of data to.
-> 1. Switch the status of all DC-1 disks to `DECOMMIT_PENDING` so that no data can be moved inside the DC-1.
-> 1. Switch the status of all DC-1 disks to `DECOMMIT_IMMINENT` on the equipment that is equivalent to the buffer one.
->
->    Wait until all the disks in the `DECOMMIT_IMMINENT` status are released.
-> 1. Move the released equipment from the DC-1 to the DC-2 and switch the status of its disks to `DECOMMIT_NONE`.
->
-> Repeat the above steps for the next set of equipment in the DC-1 until all the equipment is moved.
-
-To set the desired state of disk decommissioning, use the [{{ ydb-short-name }} DSTool](../reference/ydb-dstool/index.md) utility. The command below sets the `DECOMMIT_IMMINENT` status for the disk with the ID `1000` on the node with the ID `1`:
+For example, you need to move equipment from data center-1 (DC-1) to data center-2 (DC-2):
+
+1. The DC-2 hosts buffer equipment to transfer the first chunk of data to.
+1. Switch the status of all DC-1 disks to `DECOMMIT_PENDING` so that no data can be moved inside the DC-1.
+1. Switch the status of all DC-1 disks to `DECOMMIT_IMMINENT` on the equipment that is equivalent to the buffer one.
+
+   Wait until all the disks in the `DECOMMIT_IMMINENT` status are released.
+1. Move the released equipment from the DC-1 to the DC-2 and switch the status of its disks to `DECOMMIT_NONE`.
+
+Repeat the above steps for the next set of equipment in the DC-1 until all the equipment is moved.
+
+To set the desired state of disk decommissioning, use the [{{ ydb-short-name }} DSTool](../../reference/ydb-dstool/index.md) utility. The command below sets the `DECOMMIT_IMMINENT` status for the disk with the ID `1000` on the node with the ID `1`:
 
 ```bash
 ydb-dstool -e  <bs_endpoint> pdisk set --decommit-status DECOMMIT_IMMINENT --pdisk-ids "[1:1000]"
diff --git a/ydb/docs/en/core/devops/manual/index.md b/ydb/docs/en/core/devops/manual/index.md
new file mode 100644
index 000000000000..cce6006c6857
--- /dev/null
+++ b/ydb/docs/en/core/devops/manual/index.md
@@ -0,0 +1,12 @@
+# Manual {{ ydb-short-name }} cluster management overview
+
+This section provides information about deploying, configuring, maintaining, monitoring, and performing diagnostics of multi-node [{{ ydb-short-name }} clusters](../../concepts/cluster/index.md).
+
+Main resources:
+
+- [{#T}](../../deploy/index.md)
+- [{#T}](../../maintenance/manual/index.md)
+- [{#T}](../../devops/manual/monitoring.md)
+- [{#T}](../../reference/embedded-ui/index.md)
+- [{#T}](system-views.md)
+- [{#T}](logging.md)
\ No newline at end of file
diff --git a/ydb/docs/en/core/devops/manual/logging.md b/ydb/docs/en/core/devops/manual/logging.md
new file mode 100644
index 000000000000..27c4b6ecd305
--- /dev/null
+++ b/ydb/docs/en/core/devops/manual/logging.md
@@ -0,0 +1,18 @@
+# Logging in {{ ydb-short-name }}
+
+Each {{ ydb-short-name }} component writes messages to logs at different levels. They can be used to detect severe issues or identify the root causes.
+
+## Logging setup {#log_setup}
+
+You can configure logging for the various components of the YDB in the [Embedded UI](../../reference/embedded-ui/logs.md#change_log_level).
+
+There are currently two options for running YDB logging: manually or using systemd.
+
+### Manually {#log_setup_manually}
+
+YDB provides standard mechanisms for collecting logs and metrics.
+Logging is done to standard `stdout` and `stderr` streams and can be redirected using popular solutions.
+
+### Using systemd {#log_setup_systemd}
+
+Default logs are written to `journald` and can be retrieved via `journalctl -u ydbd`.
diff --git a/ydb/docs/en/core/administration/monitoring.md b/ydb/docs/en/core/devops/manual/monitoring.md
similarity index 83%
rename from ydb/docs/en/core/administration/monitoring.md
rename to ydb/docs/en/core/devops/manual/monitoring.md
index 099f526df20e..c71901722e2f 100644
--- a/ydb/docs/en/core/administration/monitoring.md
+++ b/ydb/docs/en/core/devops/manual/monitoring.md
@@ -1,6 +1,6 @@
 # Setting up monitoring for a local {{ ydb-short-name }} cluster
 
-This page provides instructions on how to set up monitoring for a local YDB cluster that is deployed using [Quick start](../quickstart.md).
+This page provides instructions on how to set up monitoring for a local YDB cluster that is deployed using [Quick start](../../quickstart.md).
 
 {{ ydb-short-name }} has multiple system health sensors. Instant sensor values are available in the web interface:
 
@@ -30,9 +30,9 @@ http://localhost:31002/counters/counters=<servicename>/prometheus
 
 * `<servicename>`: Sensor subgroup name.
 
-To visualize data, use any system that supports Prometheus, such as [Zabbix]{% if lang == "ru" %}(https://www.zabbix.com/ru/){% endif %}{% if lang == "en" %}(https://www.zabbix.com/){% endif %}, [Amazon CloudWatch]{% if lang == "ru" %}(https://aws.amazon.com/ru/cloudwatch/){% endif %}{% if lang == "en" %}(https://aws.amazon.com/cloudwatch/){% endif %}, or [Grafana](https://grafana.com/):
+To visualize data, use any system that supports Prometheus, such as [Zabbix](https://www.zabbix.com/), [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/), or [Grafana](https://grafana.com/):
 
-![grafana-actors](../_assets/grafana-actors.png)
+![grafana-actors](../../_assets/grafana-actors.png)
 
 ## Setting up monitoring with Prometheus and Grafana {#prometheus-grafana}
 
@@ -45,4 +45,4 @@ To set up monitoring for a local single-node {{ ydb-short-name }} cluster using
 
    To upload dashboards, use the Grafana UI [Import](https://grafana.com/docs/grafana/latest/dashboards/export-import/#import-dashboard) tool or run a [script](https://github.com/ydb-platform/ydb/tree/main/ydb/deploy/grafana_dashboards/local_upload_dashboards.sh). Please note that the script uses [basic authentication](https://grafana.com/docs/grafana/latest/http_api/create-api-tokens-for-org/#authentication) in Grafana. For other cases, modify the script.
 
-   Review the dashboard [metric reference](grafana-dashboards.md).
+   Review the dashboard [metric reference](../../reference/observability/metrics/grafana-dashboards.md).
diff --git a/ydb/docs/en/core/administration/state-storage-move.md b/ydb/docs/en/core/devops/manual/state-storage-move.md
similarity index 58%
rename from ydb/docs/en/core/administration/state-storage-move.md
rename to ydb/docs/en/core/devops/manual/state-storage-move.md
index fdd309dbb01f..d05023011711 100644
--- a/ydb/docs/en/core/administration/state-storage-move.md
+++ b/ydb/docs/en/core/devops/manual/state-storage-move.md
@@ -1,6 +1,6 @@
 # Moving a State Storage
 
-To decommission a {{ ydb-short-name }} cluster host that accommodates a part of a [State Storage](../deploy/configuration/config.md#domains-state), you need to move the group to another host.
+To decommission a {{ ydb-short-name }} cluster host that accommodates a part of a [State Storage](../../deploy/configuration/config.md#domains-state), you need to move the group to another host.
 
 {% include [warning-configuration-error](../_includes/warning-configuration-error.md) %}
 
@@ -19,9 +19,9 @@ domains_config:
 ...
 ```
 
-The [static node](../deploy/configuration/config.md#hosts) of the cluster that serves a part of State Storage is set up and running on the host with `node_id:1`. Suppose that you want to decommission this host.
+The [static node](../../deploy/configuration/config.md#hosts) of the cluster that serves a part of State Storage is set up and running on the host with `node_id:1`. Suppose that you want to decommission this host.
 
-To replace `node_id:1`, we [added](../maintenance/manual/cluster_expansion.md#add-host) to the cluster a new host with `node_id:10` and [deployed](../maintenance/manual/cluster_expansion.md#add-static-node) a static node in it.
+To replace `node_id:1`, we [added](../../maintenance/manual/cluster_expansion.md#add-host) to the cluster a new host with `node_id:10` and [deployed](../../maintenance/manual/cluster_expansion.md#add-static-node) a static node in it.
 
 To move State Storage from the `node_id:1` host to the `node_id:10` host:
 
@@ -42,5 +42,5 @@ To move State Storage from the `node_id:1` host to the `node_id:10` host:
    ```
 
 1. Update the `config.yaml` configuration files for all the cluster nodes, including dynamic nodes.
-1. Use the [rolling-restart](../maintenance/manual/node_restarting.md) procedure to restart all the cluster nodes (including dynamic nodes but excluding static nodes on the hosts with `node_id:1` and  `node_id:10`).
+1. Use the [rolling-restart](../../maintenance/manual/node_restarting.md) procedure to restart all the cluster nodes (including dynamic nodes but excluding static nodes on the hosts with `node_id:1` and  `node_id:10`).
 1. Stop static cluster nodes on the hosts with `node_id:1` and `node_id:10`.
diff --git a/ydb/docs/en/core/administration/static-group-move.md b/ydb/docs/en/core/devops/manual/static-group-move.md
similarity index 66%
rename from ydb/docs/en/core/administration/static-group-move.md
rename to ydb/docs/en/core/devops/manual/static-group-move.md
index ea307081fa17..51cd15f7f9a1 100644
--- a/ydb/docs/en/core/administration/static-group-move.md
+++ b/ydb/docs/en/core/devops/manual/static-group-move.md
@@ -1,10 +1,10 @@
 # Moving a static group
 
-To decommission a {{ ydb-short-name }} cluster host that accommodates a part of a [static group](../deploy/configuration/config.md#blob_storage_config), you need to move the group to another host.
+To decommission a {{ ydb-short-name }} cluster host that accommodates a part of a [static group](../../deploy/configuration/config.md#blob_storage_config), you need to move the group to another host.
 
 {% include [warning-configuration-error](../_includes/warning-configuration-error.md) %}
 
-As an example, let's take a {{ ydb-short-name }} cluster where you set up and launched a [static node](../deploy/configuration/config.md#hosts) on a host with `node_id:1`. This node serves a part of the static group.
+As an example, let's take a {{ ydb-short-name }} cluster where you set up and launched a [static node](../../deploy/configuration/config.md#hosts) on a host with `node_id:1`. This node serves a part of the static group.
 
 Fragment of the static group configuration:
 
@@ -30,7 +30,7 @@ blob_storage_config:
 ...
 ```
 
-To replace `node_id:1`, we [added](../maintenance/manual/cluster_expansion.md#add-host) to the cluster a new host with `node_id:10` and [deployed ](../maintenance/manual/cluster_expansion.md#add-static-node) a static node in it.
+To replace `node_id:1`, we [added](../../maintenance/manual/cluster_expansion.md#add-host) to the cluster a new host with `node_id:10` and [deployed ](../../maintenance/manual/cluster_expansion.md#add-static-node) a static node in it.
 
 To move a part of the static group from the `node_id:1` host to the `node_id:10` host:
 
@@ -64,6 +64,6 @@ To move a part of the static group from the `node_id:1` host to the `node_id:10`
    Edit the `path` and `pdisk_category` for the disk if these parameters are different on the host with `node_id: 10`.
 
 1. Update the `config.yaml` configuration files for all the cluster nodes, including dynamic nodes.
-1. Use the [rolling-restart](../maintenance/manual/node_restarting.md) procedure to restart all the static cluster nodes.
-1. Go to the Embedded UI monitoring page and make sure that the VDisk of the static group is visible on the target physical disk and its replication is in progress. For details, see [{#T}](../maintenance/embedded_monitoring/ydb_monitoring.md#static-group).
-1. Use the [rolling-restart](../maintenance/manual/node_restarting.md) procedure to restart all the dynamic cluster nodes.
+1. Use the [rolling-restart](../../maintenance/manual/node_restarting.md) procedure to restart all the static cluster nodes.
+1. Go to the Embedded UI monitoring page and make sure that the VDisk of the static group is visible on the target physical disk and its replication is in progress. For details, see [{#T}](../../reference/embedded-ui/ydb-monitoring.md#static-group).
+1. Use the [rolling-restart](../../maintenance/manual/node_restarting.md) procedure to restart all the dynamic cluster nodes.
diff --git a/ydb/docs/en/core/devops/manual/toc_p.yaml b/ydb/docs/en/core/devops/manual/toc_p.yaml
index 3ecf84f5d7d5..b7350f6d9f2a 100644
--- a/ydb/docs/en/core/devops/manual/toc_p.yaml
+++ b/ydb/docs/en/core/devops/manual/toc_p.yaml
@@ -1,6 +1,23 @@
 items:
-- include:
+- name: Overview
+  href: index.md
+- name: Deployment
+  include:
     mode: link
-    path: ../../cluster/toc_p.yaml
+    path: ../../deploy/toc_p.yaml
+- name: Managing a cluster's disk subsystem
+  include:
+    mode: link
+    path: ../../maintenance/manual/toc_p.yaml
+- name: Monitoring
+  href: monitoring.md
+- name: Updating YDB
+  href: upgrade.md
+- name: Changing an actor system's configuration
+  href: ../../maintenance/manual/change_actorsystem_configs.md
+- name: Updating configurations via CMS
+  href: ../../maintenance/manual/cms.md
 - name: System views
   href: system-views.md
+- name: Logging
+  href: logging.md
diff --git a/ydb/docs/en/core/administration/upgrade.md b/ydb/docs/en/core/devops/manual/upgrade.md
similarity index 77%
rename from ydb/docs/en/core/administration/upgrade.md
rename to ydb/docs/en/core/devops/manual/upgrade.md
index 8188ae63d095..63eeb7332bdc 100644
--- a/ydb/docs/en/core/administration/upgrade.md
+++ b/ydb/docs/en/core/devops/manual/upgrade.md
@@ -9,10 +9,10 @@ The basic scenario is updating the executable file and restarting each node one
 1. Updating and restarting storage nodes.
 1. Updating and restarting dynamic nodes.
 
-The shutdown and startup process is described on the [Safe restart and shutdown of nodes](../maintenance/manual/node_restarting.md) page.
-You must update {{ ydb-short-name }} nodes one by one and monitor the cluster status after each step in [{{ ydb-short-name }} Monitoring](../maintenance/embedded_monitoring/ydb_monitoring.md): make sure the `Storage` tab has no pools in the `Degraded` status (as shown in the example below). Otherwise, stop the update process.
+The shutdown and startup process is described on the [Safe restart and shutdown of nodes](../../maintenance/manual/node_restarting.md) page.
+You must update {{ ydb-short-name }} nodes one by one and monitor the cluster status after each step in [{{ ydb-short-name }} Monitoring](../../reference/embedded-ui/ydb-monitoring.md): make sure the `Storage` tab has no pools in the `Degraded` status (as shown in the example below). Otherwise, stop the update process.
 
-![Monitoring_storage_state](../maintenance/embedded_monitoring/_assets/monitoring_storage_state.png)
+![Monitoring_storage_state](../../reference/embedded-ui/_assets/monitoring_storage_state.png)
 
 ## Version compatibility {#version-compatability}
 
@@ -23,7 +23,7 @@ All minor versions within a major version are compatible for updates. Major vers
 * X.Y.* → X.Y+2.*: Update is impossible, major versions are inconsistent.
 * X.Y.* → X.Y-2.*: Update is impossible, major versions are inconsistent.
 
-A list of available versions can be found on the [download page](https://ydb.tech/en/docs/downloads/). The YDB release policy is described in more details in the [Release management](../contributor/manage-releases.md) article of the YDB development documentation.
+A list of available versions can be found on the [download page](../../downloads/index.md). The YDB release policy is described in more details in the [Release management](../../contributor/manage-releases.md) article of the YDB development documentation.
 
 {% note warning %}
 
diff --git a/ydb/docs/en/core/devops/system-requirements.md b/ydb/docs/en/core/devops/system-requirements.md
new file mode 100644
index 000000000000..de37b62663e4
--- /dev/null
+++ b/ydb/docs/en/core/devops/system-requirements.md
@@ -0,0 +1,37 @@
+# {{ ydb-short-name }} system requirements and recommendations
+
+This section provides recommendations for deploying {{ ydb-short-name }} clusters that are relevant regardless of the chosen deployment method ([Ansible](./ansible/index.md), [Kubernetes](./kubernetes/index.md), or [manual](./manual/index.md)).
+
+## Hardware configuration {#hardware}
+
+The fault-tolerance requirements determine the necessary number of servers and disks. For more information, see [{#T}](../concepts/topology.md).
+
+* **Processor (CPU)**
+
+ A {{ ydb-short-name }} server can only run on x86-64 processors with AVX2 instruction support: Intel Haswell (4th generation) and later, AMD EPYC and later.
+
+ The ARM architecture is currently not supported.
+
+* **RAM**
+
+ We recommend using error-correcting code (ECC) memory to protect against hardware failures.
+
+* **Disk subsystem**
+
+ A {{ ydb-short-name }} server can run on servers with any disk type (HDD/SSD/NVMe). However, we recommend using SSD/NVMe disks for better performance.
+
+ {% include [_includes/storage-device-requirements.md](../_includes/storage-device-requirements.md) %}
+
+ {{ ydb-short-name }} works with disk drives directly and does not use any filesystem to store data. Don't mount a file system or perform other operations with partitions used by {{ ydb-short-name }}. Also, avoid sharing the {{ ydb-short-name }}'s block device with the operating system and different processes, which can lead to significant performance degradation.
+
+ Prefer to use physical local disk drives for {{ ydb-short-name }} instead of virtual or network storage devices.
+
+ Remember that {{ ydb-short-name }} uses some disk space for internal needs when planning disk capacity. For example, on a medium-sized cluster of 8 nodes, you can expect approximately 100 GB to be consumed for a static group on the whole cluster. On a large cluster with more than 1500 nodes, this will be about 200 GB. There are also 25.6 GB of logs on each Pdisk and a system area on each Pdisk. Its size depends on the size of the Pdisk but is no less than 0.2 GB.
+
+## Software configuration {#software}
+
+A {{ ydb-short-name }} server can be run on servers with a Linux operating system, kernel 4.19 and higher, and libc 2.30. For example, Ubuntu 20.04, Debian 11, Fedora 34, or newer releases. {{ ydb-short-name }} uses the [TCMalloc](https://google.github.io/tcmalloc) memory allocator. To make it efficient, [enable](https://google.github.io/tcmalloc/tuning.html#system-level-optimizations) Transparent Huge Pages and Memory overcommitment.
+
+If the server has more than 32 CPU cores, to increase {{ ydb-short-name }} performance, run each dynamic node in a separate taskset/cpuset of 10 to 32 cores. For example, in the case of 128 CPU cores a viable approach would be to run four 32-CPU dynamic nodes, each in a dedicated taskset.
+
+MacOS and Windows operating systems are currently unsupported for running production {{ ydb-short-name }} servers. However, running {{ ydb-short-name }} in a [Docker container](../quickstart.md) on them is acceptable for development and functional testing.
\ No newline at end of file
diff --git a/ydb/docs/en/core/devops/toc_p.yaml b/ydb/docs/en/core/devops/toc_p.yaml
index aa8b686ce610..ff6215059ea4 100644
--- a/ydb/docs/en/core/devops/toc_p.yaml
+++ b/ydb/docs/en/core/devops/toc_p.yaml
@@ -1,6 +1,8 @@
 items:
 - name: Overview
   href: index.md
+- name: System requirements
+  href: system-requirements.md
 - name: Ansible
   include:
     mode: link
@@ -12,4 +14,4 @@ items:
 - name: Manual
   include:
     mode: link
-    path: manual/toc_p.yaml
\ No newline at end of file
+    path: manual/toc_p.yaml
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/toc_p.yaml b/ydb/docs/en/core/maintenance/embedded_monitoring/toc_p.yaml
deleted file mode 100644
index 94ce11086840..000000000000
--- a/ydb/docs/en/core/maintenance/embedded_monitoring/toc_p.yaml
+++ /dev/null
@@ -1,4 +0,0 @@
-items:
-- name: Overview
-  href: index.md
-- include: { mode: link, path: toc_i.yaml }
\ No newline at end of file
diff --git a/ydb/docs/en/core/maintenance/manual/balancing_load.md b/ydb/docs/en/core/maintenance/manual/balancing_load.md
index f4bcc76c3082..0cbdf2a385c1 100644
--- a/ydb/docs/en/core/maintenance/manual/balancing_load.md
+++ b/ydb/docs/en/core/maintenance/manual/balancing_load.md
@@ -7,11 +7,11 @@
 
 ## Distribute the load evenly across groups {#reassign-groups}
 
-At the bottom of the [Hive web-viewer](../embedded_monitoring/hive.md#reassign_groups) page, there is a button named "Reassign Groups".
+At the bottom of the [Hive web-viewer](../../reference/embedded-ui/hive.md#reassign_groups) page, there is a button named "Reassign Groups".
 
 ## Distribute VDisks evenly across block store volumes {#cluster-balance}
 
-As a result of some operations, such as [decommissioning](../../administration/decommissioning.md), VDisks can be distributed across block store volumes unevenly. You can distribute them more evenly in one of the following ways:
+As a result of some operations, such as [decommissioning](../../devops/manual/decommissioning.md), VDisks can be distributed across block store volumes unevenly. You can distribute them more evenly in one of the following ways:
 
 * [Move VDisks](moving_vdisks.md#moving_vdisk) one by one from overloaded block store volumes.
 * Use [{{ ydb-short-name }} DSTool](../../reference/ydb-dstool/index.md). The command below moves a VDisk from an overloaded block store volume to a less loaded one:
diff --git a/ydb/docs/en/core/maintenance/manual/cluster_expansion.md b/ydb/docs/en/core/maintenance/manual/cluster_expansion.md
index 41b8faf42481..8dcc4dbc60d0 100644
--- a/ydb/docs/en/core/maintenance/manual/cluster_expansion.md
+++ b/ydb/docs/en/core/maintenance/manual/cluster_expansion.md
@@ -21,7 +21,7 @@ By adding dynamic nodes, you can expand the available computing resources (CPU
 
 To add a dynamic node to the cluster, run the process that serves this node, passing to it, in the command line options, the name of the served database and the addresses of any three static nodes of the {{ ydb-short-name }} cluster, as shown in the [cluster deployment instructions](../../deploy/manual/deploy-ydb-on-premises.md#start-dynnode).
 
-Once you have added the dynamic node to the cluster, the information about it becomes available on the [cluster monitoring page in the built-in UI](../embedded_monitoring/ydb_monitoring.md).
+Once you have added the dynamic node to the cluster, the information about it becomes available on the [cluster monitoring page in the built-in UI](../../reference/embedded-ui/ydb-monitoring.md).
 
 To remove a dynamic node from the cluster, stop the process on the dynamic node.
 
@@ -45,7 +45,7 @@ To add static nodes to the cluster, perform the following steps:
 
 1. Start the processes that serve the new static nodes in the cluster, on the appropriate servers.
 
-1. Make sure that all the new static nodes now show up on the [cluster monitoring page in the built-in UI](../embedded_monitoring/ydb_monitoring.md).
+1. Make sure that all the new static nodes now show up on the [cluster monitoring page in the built-in UI](../../reference/embedded-ui/ydb-monitoring.md).
 
 1. Issue an authentication token using the {{ ydb-short-name }} CLI, for example:
 
@@ -96,11 +96,11 @@ To add static nodes to the cluster, perform the following steps:
    * `ydbd-token-file`: File name of the previously issued authentication token.
    * `2135`: Port number of the gRPCs service for the static nodes.
    * `ca.crt`: Name of the file with the certificate authority certificate.
-   * `/Root/testdb` : Full path to the database.
+   * `/Root/testdb`: Full path to the database.
    * `ssd:1`: Name of the storage pool and the number of storage groups allocated.
 
-3. Make sure that all the new storage groups now show up on the [cluster monitoring page in the built-in UI](../embedded_monitoring/ydb_monitoring.md).
+3. Make sure that all the new storage groups now show up on the [cluster monitoring page in the built-in UI](../../reference/embedded-ui/ydb-monitoring.md).
 
-To remove a static node from the {{ ydb-short-name }} cluster, use the [documented decommissioning procedure](../../administration/decommissioning.md).
+To remove a static node from the {{ ydb-short-name }} cluster, use the [documented decommissioning procedure](../../devops/manual/decommissioning.md).
 
 If the server running the static cluster node is damaged or becomes irreparable, deploy the unavailable static node on a new server with the same or higher number of disks.
diff --git a/ydb/docs/en/core/maintenance/manual/index.md b/ydb/docs/en/core/maintenance/manual/index.md
index 3e2ed00044f9..0b434029f056 100644
--- a/ydb/docs/en/core/maintenance/manual/index.md
+++ b/ydb/docs/en/core/maintenance/manual/index.md
@@ -6,15 +6,15 @@ Managing a cluster's disk subsystem includes the following actions:
 
    * [{#T}](cluster_expansion.md)
    * [{#T}](adding_storage_groups.md)
-   * [{#T}](../../administration/state-storage-move.md)
-   * [{#T}](../../administration/static-group-move.md)
+   * [{#T}](../../devops/manual/state-storage-move.md)
+   * [{#T}](../../devops/manual/static-group-move.md)
 
 * Maintenance:
 
    * [{#T}](node_restarting.md)
    * [{#T}](scrubbing.md)
    * [{#T}](selfheal.md)
-   * [{#T}](../../administration/decommissioning.md)
+   * [{#T}](../../devops/manual/decommissioning.md)
    * [{#T}](moving_vdisks.md)
 
 * Troubleshooting:
diff --git a/ydb/docs/en/core/maintenance/manual/moving_vdisks.md b/ydb/docs/en/core/maintenance/manual/moving_vdisks.md
index 6a6f6711bb83..fcd392f4b45b 100644
--- a/ydb/docs/en/core/maintenance/manual/moving_vdisks.md
+++ b/ydb/docs/en/core/maintenance/manual/moving_vdisks.md
@@ -28,7 +28,7 @@ ydbd admin bs config invoke --proto 'Command { ReassignGroupDisk { GroupId: <Sto
 
 If SelfHeal is disabled or fails to move VDisks automatically, you'll have to run this operation manually:
 
-1. Go to [monitoring](../../maintenance/embedded_monitoring/ydb_monitoring.md) and make sure that the VDisk has actually failed.
+1. Go to [monitoring](../../reference/embedded-ui/ydb-monitoring.md) and make sure that the VDisk has actually failed.
 1. Get the appropriate `[NodeId:PDiskId]` using [{{ ydb-short-name }} DSTool](../../reference/ydb-dstool/index.md):
 
    ```bash
@@ -45,7 +45,7 @@ If SelfHeal is disabled or fails to move VDisks automatically, you'll have to ru
 
 To enable the VDisk back after reassignment:
 
-1. Go to [monitoring](../../maintenance/embedded_monitoring/ydb_monitoring.md) and make sure that the VDisk is actually operable.
+1. Go to [monitoring](../../reference/embedded-ui/ydb-monitoring.md) and make sure that the VDisk is actually operable.
 1. Get the appropriate `[NodeId:PDiskId]` using [{{ ydb-short-name }} DSTool](../../reference/ydb-dstool/index.md):
 
    ```bash
diff --git a/ydb/docs/en/core/maintenance/manual/node_restarting.md b/ydb/docs/en/core/maintenance/manual/node_restarting.md
index 3b743bb52da1..230992b8f309 100644
--- a/ydb/docs/en/core/maintenance/manual/node_restarting.md
+++ b/ydb/docs/en/core/maintenance/manual/node_restarting.md
@@ -34,7 +34,7 @@ After replication is complete, you can safely shut down the node.
 
 To make sure that disabling the dynamic node doesn't affect query handling, drain the tablets from this node first.
 
-Go to the [Hive web-viewer](../embedded_monitoring/hive.md) page.
+Go to the [Hive web-viewer](../../reference/embedded-ui/hive.md) page.
 Click "View Nodes" to see a list of all nodes.
 
 Before disabling the node, first disable the transfer of tablets through the Active button, then click Drain, and wait for all the tablets to be moved away.
diff --git a/ydb/docs/en/core/maintenance/manual/toc_i.yaml b/ydb/docs/en/core/maintenance/manual/toc_i.yaml
index 8ed403ccbf12..5ef78404a30b 100644
--- a/ydb/docs/en/core/maintenance/manual/toc_i.yaml
+++ b/ydb/docs/en/core/maintenance/manual/toc_i.yaml
@@ -4,9 +4,9 @@ items:
 - name: Adding storage groups
   href: adding_storage_groups.md
 - name: Moving a State Storage
-  href: ../../administration/state-storage-move.md
+  href: ../../devops/manual/state-storage-move.md
 - name: Moving a static group
-  href: ../../administration/static-group-move.md
+  href: ../../devops/manual/static-group-move.md
 - name: Safe restart and shutdown of nodes
   href: node_restarting.md
 - name: Enabling/disabling Scrubbing
@@ -14,7 +14,7 @@ items:
 - name: Working with SelfHeal
   href: selfheal.md
 - name: Decommissioning a cluster part
-  href: ../../administration/decommissioning.md
+  href: ../../devops/manual/decommissioning.md
 - name: Moving VDisks
   href: moving_vdisks.md
 - name: Staying within the failure model
diff --git a/ydb/docs/en/core/maintenance/toc_i.yaml b/ydb/docs/en/core/maintenance/toc_i.yaml
index 9156024acc24..4ce3544597ea 100644
--- a/ydb/docs/en/core/maintenance/toc_i.yaml
+++ b/ydb/docs/en/core/maintenance/toc_i.yaml
@@ -6,7 +6,7 @@ items:
 - name: Cluster maintenance
   items:
   - name: Embedded UI
-    include: { mode: link, path: embedded_monitoring/toc_p.yaml }
+    include: { mode: link, path: ../reference/embedded-ui/toc_p.yaml }
   - name: Managing a cluster's disk subsystem
     include: { mode: link, path: manual/toc_p.yaml }
   - name: Changing an actor system's configuration
diff --git a/ydb/docs/en/core/postgresql/intro.md b/ydb/docs/en/core/postgresql/intro.md
index cdfc6ee241f8..af6788a01f70 100644
--- a/ydb/docs/en/core/postgresql/intro.md
+++ b/ydb/docs/en/core/postgresql/intro.md
@@ -1,4 +1,4 @@
-# Overview
+# {{ ydb-short-name }} compatibility with PostgreSQL
 
 {% include [./_includes/alert.md](./_includes/alert_preview.md) %}
 
diff --git a/ydb/docs/en/core/quickstart.md b/ydb/docs/en/core/quickstart.md
index 640aa5a3f044..550db788083f 100644
--- a/ydb/docs/en/core/quickstart.md
+++ b/ydb/docs/en/core/quickstart.md
@@ -2,7 +2,7 @@
 
 In this guide, you will install a single-node local [{{ ydb-short-name }} cluster](concepts/databases.md#cluster) and execute simple queries against your [database](concepts/databases.md#database).
 
-Normally, {{ ydb-short-name }} stores data on multiple SSD/NVMe or HDD raw disk devices without any filesystem. However, for simplicity, this guide emulates disks in RAM or using a file in a regular filesystem. Thus, this setup is unsuitable for any production usage or even benchmarks. See the [cluster management documentation](cluster/index.md) to learn how to run {{ ydb-short-name }} in a production environment.
+Normally, {{ ydb-short-name }} stores data on multiple SSD/NVMe or HDD raw disk devices without any filesystem. However, for simplicity, this guide emulates disks in RAM or using a file in a regular filesystem. Thus, this setup is unsuitable for any production usage or even benchmarks. See the [documentation for DevOps Engineers](devops/index.md) to learn how to run {{ ydb-short-name }} in a production environment.
 
 ## Install and start {{ ydb-short-name }} {#install}
 
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/_assets/monitoring_main_page.png b/ydb/docs/en/core/reference/embedded-ui/_assets/monitoring_main_page.png
similarity index 100%
rename from ydb/docs/en/core/maintenance/embedded_monitoring/_assets/monitoring_main_page.png
rename to ydb/docs/en/core/reference/embedded-ui/_assets/monitoring_main_page.png
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/_assets/monitoring_storage_state.png b/ydb/docs/en/core/reference/embedded-ui/_assets/monitoring_storage_state.png
similarity index 100%
rename from ydb/docs/en/core/maintenance/embedded_monitoring/_assets/monitoring_storage_state.png
rename to ydb/docs/en/core/reference/embedded-ui/_assets/monitoring_storage_state.png
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/charts.md b/ydb/docs/en/core/reference/embedded-ui/charts.md
similarity index 100%
rename from ydb/docs/en/core/maintenance/embedded_monitoring/charts.md
rename to ydb/docs/en/core/reference/embedded-ui/charts.md
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/hive.md b/ydb/docs/en/core/reference/embedded-ui/hive.md
similarity index 100%
rename from ydb/docs/en/core/maintenance/embedded_monitoring/hive.md
rename to ydb/docs/en/core/reference/embedded-ui/hive.md
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/index.md b/ydb/docs/en/core/reference/embedded-ui/index.md
similarity index 85%
rename from ydb/docs/en/core/maintenance/embedded_monitoring/index.md
rename to ydb/docs/en/core/reference/embedded-ui/index.md
index 6635bc453d41..04b099f040f1 100644
--- a/ydb/docs/en/core/maintenance/embedded_monitoring/index.md
+++ b/ydb/docs/en/core/reference/embedded-ui/index.md
@@ -7,7 +7,7 @@ description: "The article will tell you about the tools for monitoring and deter
 
 {{ ydb-short-name }} provides tools for monitoring and determining system health:
 
-* [{{ ydb-short-name }} Monitoring](ydb_monitoring.md): The main monitor of the cluster. It shows the health of nodes and storage groups.
-* [Interconnect overview](interconnect_overview.md): The state of cluster interconnects.
+* [{{ ydb-short-name }} Monitoring](ydb-monitoring.md): The main monitor of the cluster. It shows the health of nodes and storage groups.
+* [Interconnect overview](interconnect-overview.md): The state of cluster interconnects.
 * [Logs](logs.md): Each {{ ydb-short-name }} component writes messages to logs of different levels. They can be used to detect severe issues or identify the root causes of issues.
 * [Charts](charts.md): {{ ydb-short-name }} collects a range of metrics that can be used to determine the health of the entire system or of a specific component.
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/interconnect_overview.md b/ydb/docs/en/core/reference/embedded-ui/interconnect-overview.md
similarity index 100%
rename from ydb/docs/en/core/maintenance/embedded_monitoring/interconnect_overview.md
rename to ydb/docs/en/core/reference/embedded-ui/interconnect-overview.md
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/logs.md b/ydb/docs/en/core/reference/embedded-ui/logs.md
similarity index 100%
rename from ydb/docs/en/core/maintenance/embedded_monitoring/logs.md
rename to ydb/docs/en/core/reference/embedded-ui/logs.md
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/overview.md b/ydb/docs/en/core/reference/embedded-ui/overview.md
similarity index 100%
rename from ydb/docs/en/core/maintenance/embedded_monitoring/overview.md
rename to ydb/docs/en/core/reference/embedded-ui/overview.md
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/toc_i.yaml b/ydb/docs/en/core/reference/embedded-ui/toc_i.yaml
similarity index 81%
rename from ydb/docs/en/core/maintenance/embedded_monitoring/toc_i.yaml
rename to ydb/docs/en/core/reference/embedded-ui/toc_i.yaml
index 94d33b803412..93e12aa1c56c 100644
--- a/ydb/docs/en/core/maintenance/embedded_monitoring/toc_i.yaml
+++ b/ydb/docs/en/core/reference/embedded-ui/toc_i.yaml
@@ -6,11 +6,11 @@ items:
   href: viewer.md
   when: false
 - name: YDB Monitoring
-  href: ydb_monitoring.md
+  href: ydb-monitoring.md
 - name: Hive web-viewer
   href: hive.md
 - name: Connections overview
-  href: interconnect_overview.md
+  href: interconnect-overview.md
 - name: Logs
   href: logs.md
 - name: Charts
diff --git a/ydb/docs/en/core/cluster/toc_p.yaml b/ydb/docs/en/core/reference/embedded-ui/toc_p.yaml
similarity index 100%
rename from ydb/docs/en/core/cluster/toc_p.yaml
rename to ydb/docs/en/core/reference/embedded-ui/toc_p.yaml
diff --git a/ydb/docs/en/core/maintenance/embedded_monitoring/ydb_monitoring.md b/ydb/docs/en/core/reference/embedded-ui/ydb-monitoring.md
similarity index 100%
rename from ydb/docs/en/core/maintenance/embedded_monitoring/ydb_monitoring.md
rename to ydb/docs/en/core/reference/embedded-ui/ydb-monitoring.md
diff --git a/ydb/docs/en/core/administration/grafana-dashboards.md b/ydb/docs/en/core/reference/observability/metrics/grafana-dashboards.md
similarity index 94%
rename from ydb/docs/en/core/administration/grafana-dashboards.md
rename to ydb/docs/en/core/reference/observability/metrics/grafana-dashboards.md
index a2552187d1f2..e1fabb92e68d 100644
--- a/ydb/docs/en/core/administration/grafana-dashboards.md
+++ b/ydb/docs/en/core/reference/observability/metrics/grafana-dashboards.md
@@ -1,6 +1,6 @@
-# Grafana dashboards
+# Grafana dashboards for {{ ydb-short-name }}
 
-This page describes Grafana dashboards for {{ ydb-short-name }}. For information about how to install dashboards, see [{#T}](monitoring.md#prometheus-grafana).
+This page describes Grafana dashboards for {{ ydb-short-name }}. For information about how to install dashboards, see [{#T}](../../../devops/manual/monitoring.md#prometheus-grafana).
 
 ## DB status {#dbstatus}
 
diff --git a/ydb/docs/en/core/reference/observability/metrics/toc_p.yaml b/ydb/docs/en/core/reference/observability/metrics/toc_p.yaml
new file mode 100644
index 000000000000..d87e1c479b3e
--- /dev/null
+++ b/ydb/docs/en/core/reference/observability/metrics/toc_p.yaml
@@ -0,0 +1,5 @@
+items:
+- name: Metrics reference
+  href: index.md
+- name: Grafana dashboards
+  href: grafana-dashboards.md
\ No newline at end of file
diff --git a/ydb/docs/en/core/reference/observability/toc_p.yaml b/ydb/docs/en/core/reference/observability/toc_p.yaml
index 2175b824d839..e9488703efa5 100644
--- a/ydb/docs/en/core/reference/observability/toc_p.yaml
+++ b/ydb/docs/en/core/reference/observability/toc_p.yaml
@@ -1,3 +1,5 @@
 items:
-- name: Metrics reference
-  href: metrics/index.md
+- name: Metrics
+  include:
+    mode: link
+    path: metrics/toc_p.yaml
\ No newline at end of file
diff --git a/ydb/docs/en/core/reference/toc_p.yaml b/ydb/docs/en/core/reference/toc_p.yaml
index ab0514de2446..a41a72f4acb7 100644
--- a/ydb/docs/en/core/reference/toc_p.yaml
+++ b/ydb/docs/en/core/reference/toc_p.yaml
@@ -7,6 +7,10 @@ items:
   include:
     mode: link
     path: ../postgresql/toc_p.yaml
+- name: Embedded UI
+  include:
+    mode: link
+    path: embedded-ui/toc_p.yaml
 - name: Integrations
   include: 
     mode: link
diff --git a/ydb/docs/en/core/cluster/access.md b/ydb/docs/en/core/security/access-management.md
similarity index 100%
rename from ydb/docs/en/core/cluster/access.md
rename to ydb/docs/en/core/security/access-management.md
diff --git a/ydb/docs/en/core/cluster/audit-log.md b/ydb/docs/en/core/security/audit-log.md
similarity index 98%
rename from ydb/docs/en/core/cluster/audit-log.md
rename to ydb/docs/en/core/security/audit-log.md
index ccd7d44e0eef..7e2a6af72ce1 100644
--- a/ydb/docs/en/core/cluster/audit-log.md
+++ b/ydb/docs/en/core/security/audit-log.md
@@ -4,7 +4,7 @@ _An audit log_ is a stream that includes data about all the operations that trie
 
 * Database: Creating, editing, and deleting databases.
 * Directory: Creating and deleting.
-* Table: Creating or editing table scheme, changing the number of partitions, backup and recovery, copying and renaming, and deleting tables.
+* Table: Creating or editing table schema, changing the number of partitions, backup and recovery, copying and renaming, and deleting tables.
 * Topic: Creating, editing, and deleting.
 * ACL: Editing.
 
@@ -18,7 +18,7 @@ You can use any of the listed destinations or their combinations.
 
 If you forward the stream to a file, access to the audit log is set by file-system rights. Saving the audit log to a file is recommended for production installations.
 
-Forwarding the audit log to the standard error stream (`stderr`) is recommended for test installations. Further stream processing is determined by the {{ ydb-short-name }} cluster [logging](./logs.md) settings.
+Forwarding the audit log to the standard error stream (`stderr`) is recommended for test installations. Further stream processing is determined by the {{ ydb-short-name }} cluster [logging](../devops/manual/logging.md) settings.
 
 ## Audit log events {#events}
 
diff --git a/ydb/docs/en/core/security/index.md b/ydb/docs/en/core/security/index.md
new file mode 100644
index 000000000000..f2e66d74a795
--- /dev/null
+++ b/ydb/docs/en/core/security/index.md
@@ -0,0 +1,12 @@
+# {{ ydb-short-name }} for Security Engineers
+
+This section of {{ ydb-short-name }} documentation covers security-related aspects of working with {{ ydb-short-name }}. It'll be useful for compliance purposes too.
+
+Main resources:
+
+- [{#T}](access-management.md)
+- [{#T}](audit-log.md)
+- [{#T}](short-access-control-notation.md)
+- Concepts:
+    - [{#T}](../concepts/auth.md)
+    - [{#T}](../concepts/connect.md)
\ No newline at end of file
diff --git a/ydb/docs/en/core/cluster/short-access-control-notation.md b/ydb/docs/en/core/security/short-access-control-notation.md
similarity index 100%
rename from ydb/docs/en/core/cluster/short-access-control-notation.md
rename to ydb/docs/en/core/security/short-access-control-notation.md
diff --git a/ydb/docs/en/core/security/toc_p.yaml b/ydb/docs/en/core/security/toc_p.yaml
new file mode 100644
index 000000000000..42b2e104c888
--- /dev/null
+++ b/ydb/docs/en/core/security/toc_p.yaml
@@ -0,0 +1,9 @@
+items:
+- name: Overview
+  href: index.md
+- name: Access management
+  href: access-management.md
+- name: Audit log
+  href: audit-log.md
+- name: Short access control notation
+  href: short-access-control-notation.md
\ No newline at end of file
diff --git a/ydb/docs/en/core/toc_i.yaml b/ydb/docs/en/core/toc_i.yaml
index 77e474af50ba..f72ac803570c 100644
--- a/ydb/docs/en/core/toc_i.yaml
+++ b/ydb/docs/en/core/toc_i.yaml
@@ -19,6 +19,10 @@ items:
   include:
     mode: link
     path: dev/toc_p.yaml
+- name: For Security Engineers
+  include:
+    mode: link
+    path: security/toc_p.yaml
 - name: For Contributors
   include:
     mode: link
diff --git a/ydb/docs/en/core/toc_p.yaml b/ydb/docs/en/core/toc_p.yaml
index b3bc4402e07b..5c74373d6143 100644
--- a/ydb/docs/en/core/toc_p.yaml
+++ b/ydb/docs/en/core/toc_p.yaml
@@ -1,4 +1,6 @@
 title: YDB
 href: index.yaml
 items:
-- include: { mode: link, path: toc_i.yaml }
\ No newline at end of file
+- include:
+  mode: link
+  path: toc_i.yaml
\ No newline at end of file
diff --git a/ydb/docs/redirects.yaml b/ydb/docs/redirects.yaml
index ac162de7ee38..860ea90dd062 100644
--- a/ydb/docs/redirects.yaml
+++ b/ydb/docs/redirects.yaml
@@ -19,6 +19,24 @@ common:
     to: /quickstart.md
   - from: /getting_started/self_hosted/ydb_minikube.md
     to: /quickstart.md
+  - from: /getting_started/index.md
+    to: /quickstart.md
+  - from: /getting_started/quickstart/index.md
+    to: /quickstart.md
+  - from: /cluster/topology.md
+    to: /concepts/topology.md
+  - from: /getting_started/yql.md
+    to: /yql/reference/index.md
+  - from: /concepts/datatypes.md
+    to: /yql/reference/types/index.md
+
+# DevOps-related redirects
+  - from: /getting_started/kubernetes.md
+    to: /devops/kubernetes/initial-deployment.md
+  - from: /getting_started/ansible.md
+    to: /devops/ansible/initial-deployment.md
+  - from: /troubleshooting/system_views_cluster.md
+    to: /devops/manual/system-views.md
   - from: /ops/devslice-user-guide-k8s-baremetal-host.md
     to: /ops/devslice-setup-kikimr-slice.md
   - from: /deploy/orchestrated/concepts.md
@@ -29,18 +47,26 @@ common:
     to: /devops/kubernetes/initial-deployment.md
   - from: /deploy/orchestrated/operate.md
     to: /devops/kubernetes/initial-deployment.md
-  - from: /getting_started/index.md
-    to: /quickstart.md
-  - from: /getting_started/kubernetes.md
-    to: /devops/kubernetes/initial-deployment.md
-  - from: /getting_started/ansible.md
-    to: /devops/ansible/initial-deployment.md
-  - from: /getting_started/yql.md
-    to: /yql/reference/index.md
-  - from: /troubleshooting/system_views_cluster.md
-    to: /devops/manual/system-views.md
-  - from: /concepts/datatypes.md
-    to: /yql/reference/types/index.md
+  - from: /cluster/system-requirements.md
+    to: /devops/system-requirements.md
+  - from: /cluster/index.md
+    to: /devops/index.md
+  - from: /cluster/logs.md
+    to: /devops/manual/logging.md
+  - from: /administration/grafana-dashboards.md
+    to: /reference/observability/metrics/grafana-dashboards.md
+  - from: /administration/production-storage-config.md
+    to: /deploy/configuration/config.md
+  - from: /administration/decommissioning.md
+    to: /deploy/manual/decommissioning.md
+  - from: /administration/monitoring.md
+    to: /deploy/manual/monitoring.md
+  - from: /administration/state-storage-move.md
+    to: /deploy/manual/state-storage-move.md
+  - from: /administration/static-group-move.md
+    to: /deploy/manual/static-group-move.md
+  - from: /administration/upgrade.md
+    to: /deploy/manual/upgrade.md
 
 # DBA-related redirects
   - from: /db/index.md
@@ -128,6 +154,14 @@ common:
   - from: /reference/ydb-sdk/example/python/index.md
     to: /dev/example-app/python/index.md
 
+# Security-related redirects
+  - from: /cluster/access.md
+    to: /security/acess-management.md
+  - from: /cluster/audit-log.md
+    to: /security/audit-log.md
+  - from: /cluster/short-access-control-notation.md
+    to: /security/short-access-control-notation.md
+
 # Contributors-related redirects
   - from: /development/build-ya.md
     to: /contributor/build-ya.md
@@ -172,6 +206,22 @@ common:
   - from: /administration/ydb-dstool-setup.md
     to: /reference/ydb-dstool/install.md
 
+# Redirects for Embedded UI
+  - from: /maintenance/embedded_monitoring/ydb_monitoring.md
+    to: /reference/embedded-ui/ydb-monitoring.md
+  - from: /maintenance/embedded_monitoring/overview.md
+    to: /reference/embedded-ui/overview.md
+  - from: /maintenance/embedded_monitoring/hive.md
+    to: /reference/embedded-ui/hive.md
+  - from: /maintenance/embedded_monitoring/logs.md
+    to: /reference/embedded-ui/logs.md
+  - from: /maintenance/embedded_monitoring/interconnect_overview.md
+    to: /reference/embedded-ui/interconnect-overview.md
+  - from: /maintenance/embedded_monitoring/charts.md
+    to: /reference/embedded-ui/charts.md
+  - from: /maintenance/embedded_monitoring/index.md
+    to: /reference/embedded-ui/index.md
+
 # Redirects from export_import to export-import   
   - from: /reference/ydb-cli/export_import/s3_conn.md
     to: /reference/ydb-cli/export-import/auth-s3.md
diff --git a/ydb/docs/ru/core/_includes/fault-tolerance.md b/ydb/docs/ru/core/_includes/fault-tolerance.md
deleted file mode 100644
index e3e7bcb26d28..000000000000
--- a/ydb/docs/ru/core/_includes/fault-tolerance.md
+++ /dev/null
@@ -1,5 +0,0 @@
-{% note info %}
-
-Кластер YDB является отказоустойчивым. Временное выключение узла не приводит к недоступности кластера. Подробнее см. [{#T}](../cluster/topology.md).
-
-{% endnote %}
diff --git a/ydb/docs/ru/core/administration/production-storage-config.md b/ydb/docs/ru/core/administration/production-storage-config.md
deleted file mode 100644
index d476eae3cf0a..000000000000
--- a/ydb/docs/ru/core/administration/production-storage-config.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# Промышленные конфигурации BlobStorage
-
-Для обеспечения необходимой отказоустойчивости {{ ydb-short-name }} нужно правильно сконфигурировать [дисковую подсистему кластера](../concepts/cluster/distributed_storage.md): выбрать подходящий [режим отказоустойчивости](#fault-tolerance) и [аппаратную конфигурацию](#requirements) кластера.
-
-## Режимы отказоустойчивости {#fault-tolerance}
-
-Для промышленных инсталляций {{ ydb-short-name }} рекомендуется использовать следующие [режимы отказоустойчивости](../cluster/topology.md):
-
-* `block-4-2` — если кластер расположен в одной зоне доступности.
-* `mirror-3-dc` — если кластер расположен в трех зонах доступности.
-
-В модели отказа {{ ydb-short-name }} различаются понятия домена отказа и области отказа.
-
-Домен отказа (fail domain)
-
-: Набор оборудования, для которого вероятен одновременный отказ.
-
-  Например, доменом отказа можно считать диски одного сервера (в связи с вероятной недоступностью всех дисков сервера при отказе блока питания или сетевого контроллера сервера). Также доменом отказа можно считать серверы, расположенные в одной серверной стойке (в связи с вероятной недоступностью всего оборудования в стойке при проблемах с питанием или сетевым оборудованием, расположенным в той же стойке).
-
-  Обработка любых отказов домена осуществляется автоматически, без остановки работы системы.
-
-Область отказа (fail realm)
-
-: Набор доменов отказа, для которого вероятен одновременный отказ.
-
-  Например, областью отказа можно считать оборудование, расположенное в одном центре обработки данных (ЦОД), который может выйти из строя в результате стихийного бедствия.
-
-Обычно под доменом отказа подразумевается серверная стойка, а под областью отказа – ЦОД.
-
-При создании [групп хранения](../concepts/databases.md#storage-groups) {{ ydb-short-name }} объединяет в группы VDisk, расположенные на PDisk из разных доменов отказа. Таким образом, для режима `block-4-2` необходимо распределение PDisk по не менее чем 8 доменам отказа, а для режима `mirror-3-dc` — по 3 областям отказа с не менее чем 3 доменами отказа в каждой.
-
-## Аппаратная конфигурация {#requirements}
-
-При отказе диска {{ ydb-short-name }} может автоматически переконфигурировать группу хранения так, чтобы вместо расположенного на отказавшем оборудовании VDisk использовался новый VDisk, который система пытается расположить на работающем в момент реконфигурации оборудовании. При этом соблюдается то же правило, что и при создании группы — VDisk создается в домене отказа, отличном от доменов отказа всех остальных VDisk этой группы (и в той же области отказа, что и отказавший VDisk для `mirror-3-dc`).
-
-Это вызывает ряд проблем в случе, когда оборудование кластера распределено по минимально необходимому количеству доменов отказа:
-
-* при отказе всего домена реконфигурация теряет смысл т.к. новый VDisk может быть расположен только в отказавшем домене отказа;
-* при отказе части домена реконфигурация возможна, но при этом нагрузка, которая раньше обрабатывалась отказавшим оборудованием будет перераспределена только по оборудованию в том же домене отказа.
-
-Если же в кластере доступно хотя бы на 1 домен отказа больше, чем минимально необходимо для создания групп хранения (9 доменов для `block-4-2` и по 4 домена в каждой области отказа для `mirror-3-dc)`, то при отказе части оборудования нагрузка может быть перераспределена по всему оставшемуся в строю оборудованию.
-
-Система может работать с доменами отказа любого размера, однако при малом количестве доменов и неодинаковом количестве дисков в разных доменах количество групп хранения, которые возможно будет создать, окажется ограничено. При этом часть оборудования в слишком больших доменах отказа может оказаться недоутилизированной. В случае полной утилизации оборудования существенный перекос в размерах доменов может сделать невозможной реконфигурацию.
-
->Например, в кластере с режимом отказоустойчивости `block-4-2` имеется 15 стоек. В первой из 15 стоек расположено 20 серверов, а в остальных 14 стойках — по 10. Для полноценной утилизации всех 20 серверов из первой стойки {{ ydb-short-name }} будет создавать группы так, что в каждой из них будет участвовать 1 диск из этого самого большого домена отказа. В результате при выходе из строя оборудования в любом другом домене отказа нагрузка не сможет быть распределена на оборудование в первой стойке.
-
-{{ ydb-short-name }} может объединять в группу диски разных производителей, различной емкости и скорости. Результирующие характеристики группы определяются набором наихудших характеристик оборудования, которое ее обслуживает. Обычно лучших результатов удается добиться при использовании однотипного оборудования. При создании больших кластеров следует учитывать и то, что оборудование из одной партии с большей вероятностью может иметь одинаковый дефект и отказать одновременно.
-
-Таким образом, в качестве оптимальных аппаратных конфигураций для промышленного применения рекомендуются следующие:
-
-* **Кластер в 1 зоне доступности** — использует режим отказоустойчивости `block4-2` и состоит из 9 или более стоек с равным количеством одинаковых серверов в каждой.
-* **кластер в 3 зонах доступности** — использует режим отказоустойчивости `mirror3-dc` и  расположен в 3 ЦОД с 4 или более стойками в каждом, стойки укомплектованы равным количеством одинаковых серверов.
-
-Смотрите также [{#T}](#reduced).
-
-## Восстановление избыточности {#rebuild}
-
-Автоматическая реконфигурация групп хранения снижает вероятность потери данных при возникновении множественных отказов, возникающих с достаточными для завершения восстановления избыточности интервалами. По умолчанию реконфигурация происходит через 1 час после того, как {{ ydb-short-name }} выявляет отказ.
-
-После реконфигурации новый VDisk автоматически наполняется данными для восстановления требуемой избыточности хранения в группе. При этом возникает повышенная нагрузка на остальные VDisk группы и на сеть. Для снижения влияния восстановления избыточности на производительность системы суммарная скорость репликации данных ограничивается как на стороне VDisk-источника так и на стороне VDisk-получателя.
-
-Время восстановления избыточности при этом зависит от объема данных и от производительности оборудования. Например, репликация на быстрых NVMe SSD может завершиться за час, а на больших HDD репликация может длиться более суток.  Для того, чтобы реконфигурация в принципе была возможной, в кластере должны быть свободные слоты для создания VDisk в разных доменах отказа. При расчете количества оставляемых свободными слотов следует учитывать вероятность отказа оборудования, длительность репликации, время, необходимое на замену отказавшего оборудования.
-
-## Упрощенные аппаратные конфигурации {#reduced}
-
-В случаях, когда невозможно использовать [рекомендованное количество](#requirements) оборудования, можно разделить серверы одной стойки на 2 фиктивных домена отказа. В такой конфигурации отказ 1 стойки будет означать отказ не 1, а сразу 2 доменов. В [обоих режимах](#fault-tolerance) отказоустойчивости {{ ydb-short-name }} сохранит работоспособность при отказе 2 доменов. При использовании конфигурации с фиктивными доменами отказа минимальное количество стоек в кластере для режима `block-4-2` составляет 5, для `mirror-3-dc` — по 2 в каждом ЦОД.
-
-## Уровень отказоустойчивости {#reliability}
-
-В таблице приведены уровни отказоустойчивости для различных режимов отказоустойчивости и аппаратных конфигураций кластера {{ ydb-short-name }}:
-
-Режим<br>отказоустойчивости | Домен<br>отказа | Область<br>отказа | Количество<br>ЦОД | Количество<br>серверных стоек | Уровень<br>отказоустойчивости
-:--- | :---: | :---: | :---: | :---: | :---
-`block-4-2` | Стойка | ЦОД | 1 | 9 или более | Переживает отказ 2 стоек
-`block-4-2` | ½ стойки | ЦОД | 1 | 5 или более | Переживает отказ 1 стойки
-`block-4-2` | Сервер | ЦОД | 1 | Не важно | Переживает отказ 2 серверов
-`mirror-3-dc` | Стойка | ЦОД | 3 | По 4 в каждом ЦОД | Переживает отказ ЦОД и 1 стойки в одном из двух других ЦОД
-`mirror-3-dc` | Сервер | ЦОД | 3 | Не важно | Переживает отказ ЦОД и 1 сервера в одном из двух других ЦОД
diff --git a/ydb/docs/ru/core/changelog-server.md b/ydb/docs/ru/core/changelog-server.md
index 3d276a60eec1..01cc43451ff0 100644
--- a/ydb/docs/ru/core/changelog-server.md
+++ b/ydb/docs/ru/core/changelog-server.md
@@ -23,7 +23,7 @@
 * В настройках селектора типа запроса добавлена новая опция `PostgreSQL`, которая доступна при включении параметра `Enable additional query modes`. Также в истории запросов теперь учитывается синтаксис, используемый при выполнении запроса.
 * Обновлен шаблон YQL-запроса для создания таблицы. Добавлено описание доступных параметров.
 * Сортировка и фильтрация для таблиц Storage и Nodes вынесена на сервер. Необходимо включить параметр `Offload tables filters and sorting to backend` в разделе экспериментов, чтобы использовать данный функционал.
-* В контекстное меню были добавлены кнопки для создания, изменения и удаления [топиков](https://ydb.tech/ru/docs/concepts/topic).
+* В контекстное меню были добавлены кнопки для создания, изменения и удаления [топиков](concepts/topic.md).
 * Добавлена сортировка по критичности для всех issues в дереве в `Healthcheck`.
 
 **Производительность:**
@@ -155,7 +155,7 @@
 
 * Добавлено [первоначальное сканирование таблицы](concepts/cdc.md#initial-scan) при создании потока изменений CDC. Теперь можно выгрузить все данные, которые существуют на момент создания потока.
 * Добавлена возможность [атомарной замены индекса](dba/secondary-indexes.md#atomic-index-replacement). Теперь можно атомарно и прозрачно для приложения подменить один индекс другим заранее созданным индексом. Замена выполняется без простоя.
-* Добавлен [аудитный лог](cluster/audit-log.md) — поток событий, который содержит информацию обо всех операциях над объектами {{ ydb-short-name }}.
+* Добавлен [аудитный лог](security/audit-log.md) — поток событий, который содержит информацию обо всех операциях над объектами {{ ydb-short-name }}.
 
 **Производительность:**
 
diff --git a/ydb/docs/ru/core/cluster/index.md b/ydb/docs/ru/core/cluster/index.md
deleted file mode 100644
index 5f19cf21180a..000000000000
--- a/ydb/docs/ru/core/cluster/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Обзор управления кластером {{ ydb-short-name }}
-
-В этом разделе описано развертывание, конфигурирование, обслуживание, мониторинг и диагностика многоузловых [кластеров {{ ydb-short-name }}](../concepts/cluster/index.md).
-
-* [{#T}](../deploy/index.md).
-* [{#T}](../maintenance/embedded_monitoring/index.md).
-* [{#T}](../maintenance/manual/index.md).
-* [{#T}](../devops/manual/system-views.md).
-* [{#T}](../administration/monitoring.md).
-* [{#T}](../administration/upgrade.md).
-* [{#T}](../maintenance/maintenance-without-outages.md).
diff --git a/ydb/docs/ru/core/cluster/logs.md b/ydb/docs/ru/core/cluster/logs.md
deleted file mode 100644
index a364ad6ef7e8..000000000000
--- a/ydb/docs/ru/core/cluster/logs.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Логирование
-Каждый компонент YDB пишет сообщения в логи разного уровня. По ним можно детектировать критические проблемы или разобраться в причинах неполадок.
-
-## Настройка логирования {#log_setup}
-Настройку логирования у отдельных компонентов можно произвести в [системе мониторинга](../maintenance/embedded_monitoring/logs.md#change_log_level) YDB
-
-На данный момент есть два варианта для запуска логирования YDB
-
-### Вручную {#log_setup_manually}
-Для удобства YDB предоставляет стандартные механизмы сбора логов и метрик.
-Логирование осуществляется в стандартные каналы `stdout` и `stderr` и может быть перенаправлено при помощи популярных решений. Мы рекомендуем использовать комбинацию из Fluentd и Elastic Stack.
-
-### С использованием systemd {#log_setup_systemd}
-Логи по-умолчению пишутся в `journald` и достать их можно через 
-```
-journalctl -u ydbd
-```
diff --git a/ydb/docs/ru/core/cluster/toc_i.yaml b/ydb/docs/ru/core/cluster/toc_i.yaml
deleted file mode 100644
index 1285a09c5e3d..000000000000
--- a/ydb/docs/ru/core/cluster/toc_i.yaml
+++ /dev/null
@@ -1,43 +0,0 @@
-items:
-- name: Развертывание
-  include: { mode: link, path: ../deploy/toc_p.yaml }
-- name: Управление доступом
-  href: access.md
-- name: Управление дисковой подсистемой кластера
-  include: { mode: link, path: ../maintenance/manual/toc_p.yaml }
-- name: Встроенный UI
-  include: { mode: link, path: ../maintenance/embedded_monitoring/toc_p.yaml }
-- name: Аудитный лог
-  href: audit-log.md
-- name: Краткая запись управления доступом
-  href: short-access-control-notation.md
-- name: Мониторинг
-  items:
-    - name: Настройка мониторинга локального кластера YDB
-      href: ../administration/monitoring.md
-    - name: Дашборды Grafana
-      href: ../administration/grafana-dashboards.md
-    - name: Справочник метрик
-      href: ../reference/observability/metrics/index.md
-    - name: Трассировка
-      include: { mode: link, path: ../reference/observability/tracing/toc_p.yaml }
-- name: Обновление
-  href: ../administration/upgrade.md
-- name: Изменение конфигурации актор-системы
-  href: ../maintenance/manual/change_actorsystem_configs.md
-- name: Управление конфигурацией кластера
-  items:
-  - name: Обзор конфигурации
-    href: ../maintenance/manual/config-overview.md
-  - name: Статическая конфигурация кластера
-    href: ../deploy/configuration/config.md
-  - name: Динамическая конфигурация кластера
-    href: ../maintenance/manual/dynamic-config.md
-  - name: DSL конфигурации кластера
-    href: ../maintenance/manual/dynamic-config-selectors.md
-  - name: Временная конфигурация
-    href: ../maintenance/manual/dynamic-config-volatile-config.md
-  - name: Изменение конфигураций через CMS
-    href: ../maintenance/manual/cms.md
-- name: Обслуживание кластера без потери доступности
-  href: ../maintenance/maintenance-without-outages.md
diff --git a/ydb/docs/ru/core/concepts/auth.md b/ydb/docs/ru/core/concepts/auth.md
index c7558bd40c04..cb50cc00938e 100644
--- a/ydb/docs/ru/core/concepts/auth.md
+++ b/ydb/docs/ru/core/concepts/auth.md
@@ -54,7 +54,7 @@
 
 Для включения аутентификации по логину и паролю укажите значение `true` для ключа `enforce_user_token_requirement` в [конфигурационном файле](../deploy/configuration/config.md#auth) кластера.
 
-Об управлении ролями и пользователями читайте в [{#T}](../cluster/access.md).
+Об управлении ролями и пользователями читайте в [{#T}](../security/access-management.md).
 
 <!-- ### API получения токенов IAM {#token-refresh-api}
 
diff --git a/ydb/docs/ru/core/concepts/toc_i.yaml b/ydb/docs/ru/core/concepts/toc_i.yaml
index 1dcebe645495..7ec3a52c3e04 100644
--- a/ydb/docs/ru/core/concepts/toc_i.yaml
+++ b/ydb/docs/ru/core/concepts/toc_i.yaml
@@ -19,6 +19,8 @@ items:
   items:
   - name: Обзор
     href: cluster/index.md
+  - name: Топология
+    href: topology.md
   - name: Общая схема YDB
     href: cluster/common_scheme_ydb.md
   - name: Дисковая подсистема кластера
diff --git a/ydb/docs/ru/core/cluster/topology.md b/ydb/docs/ru/core/concepts/topology.md
similarity index 98%
rename from ydb/docs/ru/core/cluster/topology.md
rename to ydb/docs/ru/core/concepts/topology.md
index ea10c204400d..783e0955d213 100644
--- a/ydb/docs/ru/core/cluster/topology.md
+++ b/ydb/docs/ru/core/concepts/topology.md
@@ -1,4 +1,4 @@
-# Топология
+# Топология кластера {{ ydb-short-name }}
 
 Кластер {{ ydb-short-name }} состоит из статических и динамических узлов:
 
diff --git a/ydb/docs/ru/core/contributor/load-actors-storage.md b/ydb/docs/ru/core/contributor/load-actors-storage.md
index 54a94d696bbb..2c817addc594 100644
--- a/ydb/docs/ru/core/contributor/load-actors-storage.md
+++ b/ydb/docs/ru/core/contributor/load-actors-storage.md
@@ -146,5 +146,5 @@ StorageLoad: {
 }
 ```
 
-Рассчитанные перцентили скорости чтения/записи относятся только к запросам основного цикла нагрузки, запросы начальной записи в них не учитываются. Представляют интерес [графики в Monitoring](../administration/grafana-dashboards.md), например, по ним можно проследить, как ухудшается время отклика системы по мере роста нагрузки.
+Рассчитанные перцентили скорости чтения/записи относятся только к запросам основного цикла нагрузки, запросы начальной записи в них не учитываются. Представляют интерес [графики в Monitoring](../reference/observability/metrics/grafana-dashboards.md), например, по ним можно проследить, как ухудшается время отклика системы по мере роста нагрузки.
 
diff --git a/ydb/docs/ru/core/contributor/manage-releases.md b/ydb/docs/ru/core/contributor/manage-releases.md
index b38bd7fe9184..913feed916af 100644
--- a/ydb/docs/ru/core/contributor/manage-releases.md
+++ b/ydb/docs/ru/core/contributor/manage-releases.md
@@ -21,7 +21,7 @@
 
 ### Совместимость {#server-compatibility}
 
-{{ ydb-short-name }} поддерживает совместимость между мажорными версиями таким образом, чтобы гарантировать, что кластер может работать, когда на его узлах выполняются две смежные мажорные версии исполняемого файла сервера {{ ydb-short-name }}. Вы можете обратиться к статье [Обновление {{ ydb-short-name }}](../administration/upgrade.md) для информации о процедуре обновления кластера.
+{{ ydb-short-name }} поддерживает совместимость между мажорными версиями таким образом, чтобы гарантировать, что кластер может работать, когда на его узлах выполняются две смежные мажорные версии исполняемого файла сервера {{ ydb-short-name }}. Вы можете обратиться к статье [Обновление {{ ydb-short-name }}](../devops/manual/upgrade.md) для информации о процедуре обновления кластера.
 
 Учитывая вышеуказанную цель совместимости, мажорные релизы выпускаются парами, в основном с добавлением в нечетных версиях новой функциональности, отключенной feature-флагами, и включением этой функциональности по-умолчанию в четных.
 
diff --git a/ydb/docs/ru/core/dba/query-plans-optimization.md b/ydb/docs/ru/core/dba/query-plans-optimization.md
index 60d668afc740..b053637af578 100644
--- a/ydb/docs/ru/core/dba/query-plans-optimization.md
+++ b/ydb/docs/ru/core/dba/query-plans-optimization.md
@@ -42,7 +42,7 @@ SELECT season_id, episode_id
 
 - Embedded UI
 
-  План запроса также можно получить через [Embedded UI](../maintenance/embedded_monitoring/ydb_monitoring.md). Для этого необходимо перейти на страницу базы данных в раздел `Query` и нажать `Explain`:
+  План запроса также можно получить через [Embedded UI](../reference/embedded-ui/ydb-monitoring.md). Для этого необходимо перейти на страницу базы данных в раздел `Query` и нажать `Explain`:
 
   ![explain_ui](../_assets/explain_ui.png)
 
diff --git a/ydb/docs/ru/core/dba/toc_p.yaml b/ydb/docs/ru/core/dba/toc_p.yaml
index 3e62ad228bcc..53203600f791 100644
--- a/ydb/docs/ru/core/dba/toc_p.yaml
+++ b/ydb/docs/ru/core/dba/toc_p.yaml
@@ -1,4 +1,6 @@
 items:
 - name: Обзор
   href: index.md
-- include: { mode: link, path: toc_i.yaml }
\ No newline at end of file
+- include:
+    mode: link
+    path: toc_i.yaml
\ No newline at end of file
diff --git a/ydb/docs/ru/core/deploy/_includes/index.md b/ydb/docs/ru/core/deploy/_includes/index.md
index a9b520ae870e..74d33aa88130 100644
--- a/ydb/docs/ru/core/deploy/_includes/index.md
+++ b/ydb/docs/ru/core/deploy/_includes/index.md
@@ -1,13 +1,12 @@
-# Развертывание кластеров YDB
+# Развертывание кластеров {{ ydb-short-name }}
 
-В данном разделе представлена информация по развертыванию и конфигурации многоузловых кластеров YDB, обслуживающих множество баз данных.
+В данном разделе представлена информация по развертыванию и конфигурации многоузловых кластеров {{ ydb-short-name }}, обслуживающих множество баз данных.
 
-* [{#T}](../../cluster/system-requirements.md).
-* [{#T}](../../cluster/topology.md).
+* [{#T}](../../devops/system-requirements.md).
+* [{#T}](../../concepts/topology.md).
 * [Развертывание в Ansible](../../devops/ansible/index.md).
 * [Развертывание в Kubernetes](../../devops/kubernetes/index.md).
 * [Развертывание на виртуальных и железных серверах](../manual/deploy-ydb-on-premises.md).
 * [Конфигурирование](../configuration/config.md).
-* [Промышленные конфигурации BlobStorage](../../administration/production-storage-config.md).
 
 Пошаговые сценарии быстрого развертывания локального одноузлового кластера для целей разработки и тестирования функциональности приведены в разделе [Быстрый старт](../../quickstart.md).
diff --git a/ydb/docs/ru/core/deploy/configuration/config.md b/ydb/docs/ru/core/deploy/configuration/config.md
index 14ce715ae000..1316e0e5441e 100644
--- a/ydb/docs/ru/core/deploy/configuration/config.md
+++ b/ydb/docs/ru/core/deploy/configuration/config.md
@@ -147,7 +147,7 @@ domains_config:
 - Шифрование данных (вкл/выкл)
 - Режим отказоустойчивости
 
-Доступны следующие [режимы отказоустойчивости](../../cluster/topology.md):
+Доступны следующие [режимы отказоустойчивости](../../concepts/topology.md):
 
 Режим | Описание
 --- | ---
@@ -178,7 +178,7 @@ domains_config:
 
 ### Конфигурация State Storage {#domains-state}
 
-State Storage (хранилище состояний) -- это независимое хранилище в памяти для изменяемых данных, поддерживающее внутренние процессы YDB. Оно хранит реплики данных на множестве назначенных узлов.
+State Storage (хранилище состояний) — это независимое хранилище в памяти для изменяемых данных, поддерживающее внутренние процессы YDB. Оно хранит реплики данных на множестве назначенных узлов.
 
 Обычно State Storage не требует масштабирования в целях повышения производительности, поэтому количество узлов в нём следует делать как можно меньшим с учетом необходимого уровня отказоустойчивости.
 
@@ -387,7 +387,7 @@ domains_config:
 
 Автоматическое конфигурирование является адаптивным, т.е. подстраивается под текущую нагрузку системы. Его рекомендуется использовать в большинстве случаев.
 
-Ручное конфигурирование может быть полезно в случае, когда какой-либо пул акторной системы в процессе работы оказывается перегружен и это влияет на общую производительность БД. Отслеживать нагрузку пулов можно на [странице мониторинга в Embedded UI](../../maintenance/embedded_monitoring/ydb_monitoring.md#node_list_page).
+Ручное конфигурирование может быть полезно в случае, когда какой-либо пул акторной системы в процессе работы оказывается перегружен и это влияет на общую производительность БД. Отслеживать нагрузку пулов можно на [странице мониторинга в Embedded UI](../../reference/embedded-ui/ydb-monitoring.md#node_list_page).
 
 ### Автоматическое конфигурирование {#autoconfig}
 
@@ -519,6 +519,86 @@ auth_config:
 `ldap_authentication_domain` | Идентификатор, прикрепляемый к имени пользователя, позволяющий отличать пользователей из LDAP каталога от пользователей аутентифицируемых с помощью других провайдеров. Значение по умолчанию `ldap`
 `refresh_time` | Определяет время, когда будет попытка обновить информацию о пользователе. Конкретное время обновления будет лежать в интервале от `refresh_time/2` до `refresh_time`
 
+## Промышленные конфигурации BlobStorage
+
+Для обеспечения необходимой отказоустойчивости {{ ydb-short-name }} нужно правильно сконфигурировать [дисковую подсистему кластера](../../concepts/cluster/distributed_storage.md): выбрать подходящий [режим отказоустойчивости](#fault-tolerance) и [аппаратную конфигурацию](#requirements) кластера.
+
+### Режимы отказоустойчивости {#fault-tolerance}
+
+Для промышленных инсталляций {{ ydb-short-name }} рекомендуется использовать следующие [режимы отказоустойчивости](../concepts /topology.md):
+
+* `block-4-2` — если кластер расположен в одной зоне доступности.
+* `mirror-3-dc` — если кластер расположен в трех зонах доступности.
+
+В модели отказа {{ ydb-short-name }} различаются понятия домена отказа и области отказа.
+
+Домен отказа (fail domain)
+
+: Набор оборудования, для которого вероятен одновременный отказ.
+
+  Например, доменом отказа можно считать диски одного сервера (в связи с вероятной недоступностью всех дисков сервера при отказе блока питания или сетевого контроллера сервера). Также доменом отказа можно считать серверы, расположенные в одной серверной стойке (в связи с вероятной недоступностью всего оборудования в стойке при проблемах с питанием или сетевым оборудованием, расположенным в той же стойке).
+
+  Обработка любых отказов домена осуществляется автоматически, без остановки работы системы.
+
+Область отказа (fail realm)
+
+: Набор доменов отказа, для которого вероятен одновременный отказ.
+
+  Например, областью отказа можно считать оборудование, расположенное в одном центре обработки данных (ЦОД), который может выйти из строя в результате стихийного бедствия.
+
+Обычно под доменом отказа подразумевается серверная стойка, а под областью отказа – ЦОД.
+
+При создании [групп хранения](../../concepts/databases.md#storage-groups) {{ ydb-short-name }} объединяет в группы VDisk, расположенные на PDisk из разных доменов отказа. Таким образом, для режима `block-4-2` необходимо распределение PDisk по не менее чем 8 доменам отказа, а для режима `mirror-3-dc` — по 3 областям отказа с не менее чем 3 доменами отказа в каждой.
+
+### Аппаратная конфигурация {#requirements}
+
+При отказе диска {{ ydb-short-name }} может автоматически переконфигурировать группу хранения так, чтобы вместо расположенного на отказавшем оборудовании VDisk использовался новый VDisk, который система пытается расположить на работающем в момент реконфигурации оборудовании. При этом соблюдается то же правило, что и при создании группы — VDisk создается в домене отказа, отличном от доменов отказа всех остальных VDisk этой группы (и в той же области отказа, что и отказавший VDisk для `mirror-3-dc`).
+
+Это вызывает ряд проблем в случе, когда оборудование кластера распределено по минимально необходимому количеству доменов отказа:
+
+* при отказе всего домена реконфигурация теряет смысл т.к. новый VDisk может быть расположен только в отказавшем домене отказа;
+* при отказе части домена реконфигурация возможна, но при этом нагрузка, которая раньше обрабатывалась отказавшим оборудованием будет перераспределена только по оборудованию в том же домене отказа.
+
+Если же в кластере доступно хотя бы на 1 домен отказа больше, чем минимально необходимо для создания групп хранения (9 доменов для `block-4-2` и по 4 домена в каждой области отказа для `mirror-3-dc)`, то при отказе части оборудования нагрузка может быть перераспределена по всему оставшемуся в строю оборудованию.
+
+Система может работать с доменами отказа любого размера, однако при малом количестве доменов и неодинаковом количестве дисков в разных доменах количество групп хранения, которые возможно будет создать, окажется ограничено. При этом часть оборудования в слишком больших доменах отказа может оказаться недоутилизированной. В случае полной утилизации оборудования существенный перекос в размерах доменов может сделать невозможной реконфигурацию.
+
+Например, в кластере с режимом отказоустойчивости `block-4-2` имеется 15 стоек. В первой из 15 стоек расположено 20 серверов, а в остальных 14 стойках — по 10. Для полноценной утилизации всех 20 серверов из первой стойки {{ ydb-short-name }} будет создавать группы так, что в каждой из них будет участвовать 1 диск из этого самого большого домена отказа. В результате при выходе из строя оборудования в любом другом домене отказа нагрузка не сможет быть распределена на оборудование в первой стойке.
+
+{{ ydb-short-name }} может объединять в группу диски разных производителей, различной емкости и скорости. Результирующие характеристики группы определяются набором наихудших характеристик оборудования, которое ее обслуживает. Обычно лучших результатов удается добиться при использовании однотипного оборудования. При создании больших кластеров следует учитывать и то, что оборудование из одной партии с большей вероятностью может иметь одинаковый дефект и отказать одновременно.
+
+Таким образом, в качестве оптимальных аппаратных конфигураций для промышленного применения рекомендуются следующие:
+
+* **Кластер в 1 зоне доступности** — использует режим отказоустойчивости `block4-2` и состоит из 9 или более стоек с равным количеством одинаковых серверов в каждой.
+* **кластер в 3 зонах доступности** — использует режим отказоустойчивости `mirror3-dc` и  расположен в 3 ЦОД с 4 или более стойками в каждом, стойки укомплектованы равным количеством одинаковых серверов.
+
+Смотрите также [{#T}](#reduced).
+
+### Восстановление избыточности {#rebuild}
+
+Автоматическая реконфигурация групп хранения снижает вероятность потери данных при возникновении множественных отказов, возникающих с достаточными для завершения восстановления избыточности интервалами. По умолчанию реконфигурация происходит через 1 час после того, как {{ ydb-short-name }} выявляет отказ.
+
+После реконфигурации новый VDisk автоматически наполняется данными для восстановления требуемой избыточности хранения в группе. При этом возникает повышенная нагрузка на остальные VDisk группы и на сеть. Для снижения влияния восстановления избыточности на производительность системы суммарная скорость репликации данных ограничивается как на стороне VDisk-источника так и на стороне VDisk-получателя.
+
+Время восстановления избыточности при этом зависит от объема данных и от производительности оборудования. Например, репликация на быстрых NVMe SSD может завершиться за час, а на больших HDD репликация может длиться более суток.  Для того, чтобы реконфигурация в принципе была возможной, в кластере должны быть свободные слоты для создания VDisk в разных доменах отказа. При расчете количества оставляемых свободными слотов следует учитывать вероятность отказа оборудования, длительность репликации, время, необходимое на замену отказавшего оборудования.
+
+### Упрощенные аппаратные конфигурации {#reduced}
+
+В случаях, когда невозможно использовать [рекомендованное количество](#requirements) оборудования, можно разделить серверы одной стойки на 2 фиктивных домена отказа. В такой конфигурации отказ 1 стойки будет означать отказ не 1, а сразу 2 доменов. В [обоих режимах](#fault-tolerance) отказоустойчивости {{ ydb-short-name }} сохранит работоспособность при отказе 2 доменов. При использовании конфигурации с фиктивными доменами отказа минимальное количество стоек в кластере для режима `block-4-2` составляет 5, для `mirror-3-dc` — по 2 в каждом ЦОД.
+
+### Уровень отказоустойчивости {#reliability}
+
+В таблице приведены уровни отказоустойчивости для различных режимов отказоустойчивости и аппаратных конфигураций кластера {{ ydb-short-name }}:
+
+Режим<br>отказоустойчивости | Домен<br>отказа | Область<br>отказа | Количество<br>ЦОД | Количество<br>серверных стоек | Уровень<br>отказоустойчивости
+:--- | :---: | :---: | :---: | :---: | :---
+`block-4-2` | Стойка | ЦОД | 1 | 9 или более | Переживает отказ 2 стоек
+`block-4-2` | ½ стойки | ЦОД | 1 | 5 или более | Переживает отказ 1 стойки
+`block-4-2` | Сервер | ЦОД | 1 | Не важно | Переживает отказ 2 серверов
+`mirror-3-dc` | Стойка | ЦОД | 3 | По 4 в каждом ЦОД | Переживает отказ ЦОД и 1 стойки в одном из двух других ЦОД
+`mirror-3-dc` | Сервер | ЦОД | 3 | Не важно | Переживает отказ ЦОД и 1 сервера в одном из двух других ЦОД
+
+
 ## Примеры конфигураций кластеров {#examples}
 
 В [репозитории](https://github.com/ydb-platform/ydb/tree/main/ydb/deploy/yaml_config_examples/)  можно найти модельные примеры конфигураций кластеров для самостоятельного развертывания. Ознакомьтесь с ними перед развертыванием кластера.
diff --git a/ydb/docs/ru/core/deploy/manual/deploy-ydb-on-premises.md b/ydb/docs/ru/core/deploy/manual/deploy-ydb-on-premises.md
index bac3bba7c8d4..c58d0dc4c344 100644
--- a/ydb/docs/ru/core/deploy/manual/deploy-ydb-on-premises.md
+++ b/ydb/docs/ru/core/deploy/manual/deploy-ydb-on-premises.md
@@ -6,7 +6,7 @@
 
 ### Требования {#requirements}
 
-Ознакомьтесь с [системными требованиями](../../cluster/system-requirements.md) и [топологией кластера](../../cluster/topology.md).
+Ознакомьтесь с [системными требованиями](../../devops/system-requirements.md) и [топологией кластера](../../concepts/topology.md).
 
 У вас должен быть SSH доступ на все сервера. Это необходимо для установки артефактов и запуска исполняемого файла {{ ydb-short-name }}.
 
@@ -17,7 +17,7 @@
 * 19001, 19002: Interconnect для внутрикластерного взаимодействия узлов;
 * 8765, 8766: HTTP интерфейс {{ ydb-short-name }} Embedded UI.
 
-При размещении нескольких динамических узлов на одном сервере потребуются отдельные порты для GRPC, Interconnect и HTTP интерфейса каждого динамического узла в рамках сервера.
+При размещении нескольких динамических узлов на одном сервере потребуются отдельные порты для gRPC, Interconnect и HTTP интерфейса каждого динамического узла в рамках сервера.
 
 Убедитесь в том, что системные часы на всех серверах в составе кластера синхронизированы с помощью инструментов `ntpd` или `chrony`. Желательно использовать единый источник времени для всех серверов кластера, чтобы обеспечить одинаковую обработку секунд координации (leap seconds).
 
@@ -34,7 +34,7 @@
 
 {% endnote %}
 
-Подробнее требования к оборудованию описаны в разделе [{#T}](../../cluster/system-requirements.md).
+Подробнее требования к оборудованию описаны в разделе [{#T}](../../devops/system-requirements.md).
 
 ### Подготовка ключей и сертификатов TLS {#tls-certificates}
 
@@ -403,7 +403,7 @@ sudo chmod 700 /opt/ydb/certs
 
 Если в файле настроек кластера включен режим аутентификации, то перед началом работы с кластером {{ ydb-short-name }} необходимо выполнить первоначальную настройку учетных записей.
 
-При первоначальной установке кластера {{ ydb-short-name }} автоматически создается учетная запись `root` с пустым паролем, а также стандартный набор групп пользователей, описанный в разделе [Управление доступом](../../cluster/access.md).
+При первоначальной установке кластера {{ ydb-short-name }} автоматически создается учетная запись `root` с пустым паролем, а также стандартный набор групп пользователей, описанный в разделе [Управление доступом](../../security/access-management.md).
 
 Для выполнения первоначальной настройки учетных записей в созданном кластере {{ ydb-short-name }} выполните следующие операции: 
 
@@ -455,7 +455,7 @@ sudo chmod 700 /opt/ydb/certs
 
 В Web-браузере должно быть настроено доверие в отношении центра регистрации, выпустившего сертификаты для кластера {{ ydb-short-name }}, в противном случае будет отображено предупреждение об использовании недоверенного сертификата.
 
-Если в кластере включена аутентификация, в Web-браузере должен отобразиться запрос логина и пароля. После ввода верных данных аутентификации должна отобразиться начальная страница встроенного web-интерфейса. Описание доступных функций и пользовательского интерфейса приведено в разделе [{#T}](../../maintenance/embedded_monitoring/index.md).
+Если в кластере включена аутентификация, в Web-браузере должен отобразиться запрос логина и пароля. После ввода верных данных аутентификации должна отобразиться начальная страница встроенного web-интерфейса. Описание доступных функций и пользовательского интерфейса приведено в разделе [{#T}](../../reference/embedded-ui/index.md).
 
 {% note info %}
 
diff --git a/ydb/docs/ru/core/deploy/toc_i.yaml b/ydb/docs/ru/core/deploy/toc_i.yaml
index 1aa93984007b..da80e48c12d3 100644
--- a/ydb/docs/ru/core/deploy/toc_i.yaml
+++ b/ydb/docs/ru/core/deploy/toc_i.yaml
@@ -3,6 +3,3 @@ items:
   include: { mode: link, path: manual/toc_p.yaml }
 - name: Конфигурация
   href: configuration/config.md
-- name: Промышленные конфигурации BlobStorage
-  href: ../administration/production-storage-config.md
-
diff --git a/ydb/docs/ru/core/deploy/toc_p.yaml b/ydb/docs/ru/core/deploy/toc_p.yaml
index b4d76795d43c..3e62ad228bcc 100644
--- a/ydb/docs/ru/core/deploy/toc_p.yaml
+++ b/ydb/docs/ru/core/deploy/toc_p.yaml
@@ -1,10 +1,4 @@
 items:
 - name: Обзор
   href: index.md
-- name: Системные требования и рекомендации
-  href: ../cluster/system-requirements.md
-- name: Логирование
-  href: ../cluster/logs.md
-- name: Топология
-  href: ../cluster/topology.md
 - include: { mode: link, path: toc_i.yaml }
\ No newline at end of file
diff --git a/ydb/docs/ru/core/dev/batch-upload.md b/ydb/docs/ru/core/dev/batch-upload.md
index b1c903c73007..d854cfbec34b 100644
--- a/ydb/docs/ru/core/dev/batch-upload.md
+++ b/ydb/docs/ru/core/dev/batch-upload.md
@@ -19,11 +19,11 @@
 * Если требуется залить данные в таблицу с синхронным вторичным индексом, то рекомендуется сначала залить данные в таблицу и после завершения заливки данных построить вторичный индекс.
 * Следует избегать записи последовательно в порядке возрастания или убывания первичного ключа.
   Запись в таблицу данных с монотонно возрастающим ключом приведет к тому, что все новые данные будут записываться в конец таблицы, поскольку все таблицы в YDB отсортированы по возрастанию первичного ключа. Так как YDB разделяет таблицы на шарды по диапазонам ключей, вставки будут обрабатываться одним конкретным сервером, отвечающим за "последний" шард. Сосредоточение нагрузки на одном сервере приведет к медленной загрузке данных и не эффективному использованию распределенной системы.
-* В некоторых сценариях требуется записать в таблицу первоначальные данные (зачастую большого объема) прежде чем включать OLTP-нагрузку. В таком случае не требуется транзакционность на уровне отдельных запросов и можно воспользоваться вызовом ```BulkUpsert``` в API и SDK. За счёт отказа от транзакционности такой подход  имеет значительно меньшие накладные расходы по сравнению с YQL запросами. В случае успешного ответа на запрос, метод ```BulkUpsert``` гарантирует фиксацию всех данных, записанных в рамках данного запроса.
+* В некоторых сценариях требуется записать в таблицу первоначальные данные (зачастую большого объема) прежде чем включать OLTP-нагрузку. В таком случае не требуется транзакционность на уровне отдельных запросов и можно воспользоваться вызовом `BulkUpsert` в [CLI](../reference/ydb-cli/export-import/tools-restore.md), [SDK](../reference/ydb-sdk/recipes/bulk-upsert.md) и API. За счёт отказа от транзакционности такой подход  имеет значительно меньшие накладные расходы по сравнению с YQL запросами. В случае успешного ответа на запрос, метод `BulkUpsert` гарантирует фиксацию всех данных, записанных в рамках данного запроса.
 
 {% note warning %}
 
-Метод ```BulkUpsert``` не поддерживается для таблиц со вторичными индексами.
+Метод `BulkUpsert` не поддерживается для таблиц с вторичными индексами.
 
 {% endnote %}
 
@@ -34,4 +34,4 @@
   2. Отсортируйте исходный набор данных по предполагаемому первичному ключу.
   3. Разделите полученный набор данных на части по количеству шардов таблицы. Каждая часть будет состоять из набора последовательно расположенных строк.
   4. Полученные части загружайте в шарды таблицы параллельно.
-  5. Делайте ```COMMIT``` после каждых 100000 строк или 1 МБ данных.
+  5. Делайте `COMMIT` после каждых 100000 строк или 1 МБ данных.
diff --git a/ydb/docs/ru/core/dev/example-app/_includes/index.md b/ydb/docs/ru/core/dev/example-app/_includes/index.md
index 87c21afcbe1b..56ec602a45a5 100644
--- a/ydb/docs/ru/core/dev/example-app/_includes/index.md
+++ b/ydb/docs/ru/core/dev/example-app/_includes/index.md
@@ -11,6 +11,12 @@
 - [Node.js](../example-nodejs.md)
 - [Python](../python/index.md)
 
+{% node info %}
+
+Дополнительную информацию о том, как работают эти примеры приложений, можно найти в [справочной документации {{ ydb-short-name }} SDK](../../../reference/ydb-sdk/index.md).
+
+{% endnote %}
+
 Тестовое приложение выполняет следующие шаги:
 
 {% include [init.md](steps/01_init.md) %}
diff --git a/ydb/docs/ru/core/dev/getting-started.md b/ydb/docs/ru/core/dev/getting-started.md
index 669edd089d58..f2910cddd8d4 100644
--- a/ydb/docs/ru/core/dev/getting-started.md
+++ b/ydb/docs/ru/core/dev/getting-started.md
@@ -22,7 +22,7 @@
 Кроме того, рекомендуется настроить хотя бы один из доступных способов запуска произвольных запросов в целях отладки. Выберите часть из них по своим предпочтениям:
 
 * [YDB CLI](../reference/ydb-cli/install.md)
-* [Встроенный пользовательский интерфейс](../maintenance/embedded_monitoring/index.md)
+* [Встроенный пользовательский интерфейс](../reference/embedded-ui/index.md)
 * Любая среда разработки SQL, поддерживающая [JDBC](https://github.com/ydb-platform/ydb-jdbc-driver).
 * [psql](https://www.postgresql.org/docs/14/app-psql.html) или [pgAdmin](https://www.pgadmin.org/) для пути совместимости с PostgreSQL.
 
diff --git a/ydb/docs/ru/core/dev/index.md b/ydb/docs/ru/core/dev/index.md
index 8448bd1070ba..a570e5d58cb9 100644
--- a/ydb/docs/ru/core/dev/index.md
+++ b/ydb/docs/ru/core/dev/index.md
@@ -10,5 +10,12 @@
 - [{#T}](batch-upload.md)
 - [{#T}](paging.md)
 - [{#T}](timeouts.md)
+- Справка:
+  - [{#T}](../yql/reference/index.md)
+  - [{#T}](../reference/ydb-sdk/index.md)
+  - [{#T}](../reference/ydb-cli/index.md)
+  - [{#T}](../postgresql/intro.md)
+  - [{#T}](../reference/kafka-api/index.md)
+
 
 Если же вам интересная разработка ядра {{ ydb-short-name }} или сопутствующих проектов, обратитесь к [документации для контрибьюторов](../contributor/index.md).
\ No newline at end of file
diff --git a/ydb/docs/ru/core/dev/yql-tutorial/_includes/index/intro.md b/ydb/docs/ru/core/dev/yql-tutorial/_includes/index/intro.md
index ff2cb58bb257..bcd0294bed20 100644
--- a/ydb/docs/ru/core/dev/yql-tutorial/_includes/index/intro.md
+++ b/ydb/docs/ru/core/dev/yql-tutorial/_includes/index/intro.md
@@ -1,13 +1,4 @@
----
-title: Туториал по YQL. Базовые операции
-description: Из этого туториала вы узнаете, как выполнять базовые операции с данными и познакомитесь с синтаксисом YQL.
-keywords:
-  - yql
-  - туториал yql
-  - базовые операции yql
----
+# Туториал по YQL - Обзор
 
-# Туториал YQL - Обзор
-
-Из этого туториала вы узнаете, как выполнять базовые операции с данными в {{ ydb-short-name }}, и познакомитесь с синтаксисом YQL. 
+Из этого туториала вы узнаете, как выполнять базовые операции с данными в {{ ydb-short-name }}, и познакомитесь с синтаксисом YQL. Подробное описание этого синтаксиса находится в [справочной документации по YQL](../../../../yql/reference/index.md).
 
diff --git a/ydb/docs/ru/core/devops/_includes/fault-tolerance.md b/ydb/docs/ru/core/devops/_includes/fault-tolerance.md
new file mode 100644
index 000000000000..f2cd3ec1034b
--- /dev/null
+++ b/ydb/docs/ru/core/devops/_includes/fault-tolerance.md
@@ -0,0 +1,5 @@
+{% note info %}
+
+Кластер {{ ydb-short-name }} является отказоустойчивым. Временное выключение узла не приводит к недоступности кластера. Подробнее см. [{#T}](../../concepts/topology.md).
+
+{% endnote %}
diff --git a/ydb/docs/ru/core/_includes/warning-configuration-error.md b/ydb/docs/ru/core/devops/_includes/warning-configuration-error.md
similarity index 100%
rename from ydb/docs/ru/core/_includes/warning-configuration-error.md
rename to ydb/docs/ru/core/devops/_includes/warning-configuration-error.md
diff --git a/ydb/docs/ru/core/devops/ansible/initial-deployment.md b/ydb/docs/ru/core/devops/ansible/initial-deployment.md
index 04e1dcddec88..da209911f821 100644
--- a/ydb/docs/ru/core/devops/ansible/initial-deployment.md
+++ b/ydb/docs/ru/core/devops/ansible/initial-deployment.md
@@ -1,6 +1,6 @@
 # Развертывание {{ ydb-short-name }} кластера с помощью Ansible
 
-В инструкции изложен процесс развертывания {{ ydb-short-name }} кластера на группе серверов с помощью Ansible. {{ ydb-short-name }} может быть развернут на любом желаемом количестве серверов, но минимальное количество серверов в кластере не должно быть меньше восемь штук для модели избыточности `block-4-2` и девяти серверов для модели избыточности `mirror-3-dc`. О моделях избыточности можно узнать из статьи [{#T}](../../cluster/topology.md).
+В инструкции изложен процесс развертывания {{ ydb-short-name }} кластера на группе серверов с помощью Ansible. {{ ydb-short-name }} может быть развернут на любом желаемом количестве серверов, но минимальное количество серверов в кластере не должно быть меньше восемь штук для модели избыточности `block-4-2` и девяти серверов для модели избыточности `mirror-3-dc`. О моделях избыточности можно узнать из статьи [{#T}](../../concepts/topology.md).
 
 В процессе эксплуатации кластер может быть [расширен](../../maintenance/manual/cluster_expansion.md) без приостановки доступа пользователей к базам данных.
 
@@ -234,7 +234,7 @@ static-node-9 static-node-9.ydb-cluster.com
 
 ![ydb-storage-gr-check](../../_assets/ydb-storage-gr-check.png)
 
-Индикаторы `VDisks` должны быть зелеными, а статус `state` (находится в сплывающей подсказке при наведении на индикатор Vdisk) должен быть `Ok`. Подробнее о показателях состояния кластера и мониторинге можно прочитать в статье [{#T}](../../maintenance/embedded_monitoring/ydb_monitoring.md).
+Индикаторы `VDisks` должны быть зелеными, а статус `state` (находится в сплывающей подсказке при наведении на индикатор Vdisk) должен быть `Ok`. Подробнее о показателях состояния кластера и мониторинге можно прочитать в статье [{#T}](../../reference/embedded-ui/ydb-monitoring.md).
 
 ## Тестирование кластера { #testing }
 
diff --git a/ydb/docs/ru/core/devops/index.md b/ydb/docs/ru/core/devops/index.md
index d1eb1dc17e67..2acdcf0b5c17 100644
--- a/ydb/docs/ru/core/devops/index.md
+++ b/ydb/docs/ru/core/devops/index.md
@@ -4,4 +4,6 @@
 
 * **[Ansible](ansible/index.md)**: для развертываний на физическом оборудовании и виртуальных машинах.
 * **[Kubernetes](kubernetes/index.md)**: для развёртываний в контейнерах.
-* **[Вручную](../cluster/index.md)**: общие инструкции.
\ No newline at end of file
+* **[Вручную](manual/index.md)**: общие инструкции.
+
+Вне зависимости от выбранного способа управления инфраструктурой, перед началом работы рекомендуется ознакомиться с [системными требованиями {{ ydb-short-name }}](system-requirements.md).
\ No newline at end of file
diff --git a/ydb/docs/ru/core/devops/kubernetes/initial-deployment.md b/ydb/docs/ru/core/devops/kubernetes/initial-deployment.md
index 182826e68819..638381c46030 100644
--- a/ydb/docs/ru/core/devops/kubernetes/initial-deployment.md
+++ b/ydb/docs/ru/core/devops/kubernetes/initial-deployment.md
@@ -146,7 +146,7 @@ Helm-чарт устанавливает [YDB Kubernetes Operator](https://githu
 
 ### Разверните узлы хранения
 
-{{ ydb-short-name }} поддерживает различные [топологии хранения данных](../../cluster/topology.md). {{ ydb-short-name }} {{ k8s }} оператор имеет несколько примеров конфигураций для типовых топологий. В данной инструкции они используются без изменений, но их можно подстраивать под свои нужды или написать новый конфигурационный файл с нуля.
+{{ ydb-short-name }} поддерживает различные [топологии хранения данных](../../concepts/topology.md). {{ ydb-short-name }} {{ k8s }} оператор имеет несколько примеров конфигураций для типовых топологий. В данной инструкции они используются без изменений, но их можно подстраивать под свои нужды или написать новый конфигурационный файл с нуля.
 
 Примените манифест для создания узлов хранения:
 
diff --git a/ydb/docs/ru/core/administration/decommissioning.md b/ydb/docs/ru/core/devops/manual/decommissioning.md
similarity index 74%
rename from ydb/docs/ru/core/administration/decommissioning.md
rename to ydb/docs/ru/core/devops/manual/decommissioning.md
index ed73e3c5adcb..0321ee27c285 100644
--- a/ydb/docs/ru/core/administration/decommissioning.md
+++ b/ydb/docs/ru/core/devops/manual/decommissioning.md
@@ -20,18 +20,18 @@
 
 Управление состояниями `DECOMMIT_PENDING` и `DECOMMIT_IMMINENT` позволяют провести декомиссию кластера по частями.
 
->Например, нужно переместить оборудование из ЦОД-1 в ЦОД-2:
->
->1. В ЦОД-2 размещается буферное оборудование, на которое будет перемещена первая порция данных.
->1. Все диски ЦОД-1 переводятся в состояние `DECOMMIT_PENDING`, чтобы исключить перемещение данных внутри ЦОД-1.
->1. В ЦОД-1 все диски оборудования, эквивалентного буферному, переводятся в состояние `DECOMMIT_IMMINENT`.
->
->    Необходимо дождаться освобождения всех дисков в состоянии `DECOMMIT_IMMINENT`.
->1. Освободившееся оборудование из ЦОД-1 перемещается в ЦОД-2, его диски переводятся в состояние `DECOMMIT_NONE`.
->
->Описанные шаги повторяются для следующего набора оборудования в ЦОД-1 до тех пор, пока все оборудование не будет перемещено.
-
-Чтобы задать нужное состояние декомиссии диска, воспользуйтесь утилитой [{{ ydb-short-name }} DSTool](../reference/ydb-dstool/index.md). Следующая команда задаст статус `DECOMMIT_IMMINENT` диску с ID `1000` на ноде с ID `1`:
+Например, нужно переместить оборудование из ЦОД-1 в ЦОД-2:
+
+1. В ЦОД-2 размещается буферное оборудование, на которое будет перемещена первая порция данных.
+1. Все диски ЦОД-1 переводятся в состояние `DECOMMIT_PENDING`, чтобы исключить перемещение данных внутри ЦОД-1.
+1. В ЦОД-1 все диски оборудования, эквивалентного буферному, переводятся в состояние `DECOMMIT_IMMINENT`.
+
+    Необходимо дождаться освобождения всех дисков в состоянии `DECOMMIT_IMMINENT`.
+1. Освободившееся оборудование из ЦОД-1 перемещается в ЦОД-2, его диски переводятся в состояние `DECOMMIT_NONE`.
+
+Описанные шаги повторяются для следующего набора оборудования в ЦОД-1 до тех пор, пока все оборудование не будет перемещено.
+
+Чтобы задать нужное состояние декомиссии диска, воспользуйтесь утилитой [{{ ydb-short-name }} DSTool](../../reference/ydb-dstool/index.md). Следующая команда задаст статус `DECOMMIT_IMMINENT` диску с ID `1000` на ноде с ID `1`:
 
 ```bash
 ydb-dstool -e  <bs_endpoint> pdisk set --decommit-status DECOMMIT_IMMINENT --pdisk-ids "[1:1000]"
diff --git a/ydb/docs/ru/core/devops/manual/index.md b/ydb/docs/ru/core/devops/manual/index.md
new file mode 100644
index 000000000000..babaa66c4141
--- /dev/null
+++ b/ydb/docs/ru/core/devops/manual/index.md
@@ -0,0 +1,12 @@
+# Обзор управления кластером {{ ydb-short-name }} вручную
+
+В этом разделе описано развертывание, конфигурирование, обслуживание, мониторинг и диагностика многоузловых [кластеров {{ ydb-short-name }}](../../concepts/cluster/index.md).
+
+Основные материалы:
+
+- [{#T}](../../deploy/index.md)
+- [{#T}](../../maintenance/manual/index.md)
+- [{#T}](../../devops/manual/monitoring.md)
+- [{#T}](../../reference/embedded-ui/index.md)
+- [{#T}](system-views.md)
+- [{#T}](logging.md)
\ No newline at end of file
diff --git a/ydb/docs/ru/core/devops/manual/logging.md b/ydb/docs/ru/core/devops/manual/logging.md
new file mode 100644
index 000000000000..57b51807e552
--- /dev/null
+++ b/ydb/docs/ru/core/devops/manual/logging.md
@@ -0,0 +1,18 @@
+# Логирование в {{ ydb-short-name }}
+
+Каждый компонент {{ ydb-short-name }} пишет сообщения разного уровня в логи (журналы). По ним можно детектировать критические проблемы или разобраться в причинах неполадок.
+
+## Настройка логирования {#log_setup}
+
+Настройку логирования у отдельных компонентов можно произвести во [встроенном интерфейсе](../../reference/embedded-ui/logs.md#change_log_level) {{ ydb-short-name }}.
+
+На данный момент есть два варианта для запуска логирования {{ ydb-short-name }}: вручную и с использованием systemd.
+
+### Вручную {#log_setup_manually}
+
+Для удобства YDB предоставляет стандартные механизмы сбора логов и метрик.
+Логирование осуществляется в стандартные каналы `stdout` и `stderr` и может быть перенаправлено при помощи популярных решений.
+
+### С использованием systemd {#log_setup_systemd}
+
+По умолчению пишутся в `journald` и достать их можно через `journalctl -u ydbd`.
diff --git a/ydb/docs/ru/core/administration/monitoring.md b/ydb/docs/ru/core/devops/manual/monitoring.md
similarity index 86%
rename from ydb/docs/ru/core/administration/monitoring.md
rename to ydb/docs/ru/core/devops/manual/monitoring.md
index 83a8f0581367..193bd7373442 100644
--- a/ydb/docs/ru/core/administration/monitoring.md
+++ b/ydb/docs/ru/core/devops/manual/monitoring.md
@@ -1,6 +1,6 @@
 # Настройка мониторинга локального кластера {{ ydb-short-name }}
 
-На этой странице рассказано, как настроить мониторинг локального однонодового кластера YDB, запущенного с помощью инструкции по [Быстрому началу работы](../quickstart.md).
+На этой странице рассказано, как настроить мониторинг локального однонодового кластера YDB, запущенного с помощью инструкции по [Быстрому началу работы](../../quickstart.md).
 
 {{ ydb-short-name }} предоставляет множество сенсоров состояния системы. Мгновенные значения сенсоров можно посмотреть в веб-интерфейсе:
 
@@ -30,9 +30,9 @@ http://localhost:31002/counters/counters=<servicename>/prometheus
 
 * `<servicename>` — имя подгруппы сенсоров.
 
-Визуализировать данные можно с помощью любой системы, которая поддерживает формат Prometheus, например [Zabbix]{% if lang == "ru" %}(https://www.zabbix.com/ru/){% endif %}{% if lang == "en" %}(https://www.zabbix.com/){% endif %}, [Amazon CloudWatch]{% if lang == "ru" %}(https://aws.amazon.com/ru/cloudwatch/){% endif %}{% if lang == "en" %}(https://aws.amazon.com/cloudwatch/){% endif %} или [Grafana](https://grafana.com/):
+Визуализировать данные можно с помощью любой системы, которая поддерживает формат Prometheus, например [Zabbix](https://www.zabbix.com/ru/), [Amazon CloudWatch](https://aws.amazon.com/ru/cloudwatch/) или [Grafana](https://grafana.com/):
 
-![grafana-actors](../_assets/grafana-actors.png)
+![grafana-actors](../../_assets/grafana-actors.png)
 
 ## Настройка мониторинга с помощью Prometheus и Grafana {#prometheus-grafana}
 
@@ -45,4 +45,4 @@ http://localhost:31002/counters/counters=<servicename>/prometheus
 
     Вы можете загрузить дашборды с помощью инструмента [Import](https://grafana.com/docs/grafana/latest/dashboards/export-import/#import-dashboard) Grafana UI или выполнить [скрипт](https://github.com/ydb-platform/ydb/tree/main/ydb/deploy/grafana_dashboards/local_upload_dashboards.sh). Обратите внимание, что скрипт использует [базовую аутентификацию](https://grafana.com/docs/grafana/latest/http_api/create-api-tokens-for-org/#authentication) в Grafana. Для других случаев модифицируйте скрипт.
 
-    Ознакомьтесь со [справочником метрик](grafana-dashboards.md) дашбордов.
+    Ознакомьтесь со [справочником по дашбордам Grafana](../../reference/observability/metrics/grafana-dashboards.md).
diff --git a/ydb/docs/ru/core/administration/state-storage-move.md b/ydb/docs/ru/core/devops/manual/state-storage-move.md
similarity index 60%
rename from ydb/docs/ru/core/administration/state-storage-move.md
rename to ydb/docs/ru/core/devops/manual/state-storage-move.md
index 3512144bd105..6c8912bd6ba2 100644
--- a/ydb/docs/ru/core/administration/state-storage-move.md
+++ b/ydb/docs/ru/core/devops/manual/state-storage-move.md
@@ -1,6 +1,6 @@
 # Перемещение State Storage
 
-Если нужно вывести из эксплуатации хост кластера {{ ydb-short-name }}, на котором располагается часть [State Storage](../deploy/configuration/config.md#domains-state), необходимо переместить  ее на другой хост.
+Если нужно вывести из эксплуатации хост кластера {{ ydb-short-name }}, на котором располагается часть [State Storage](../../deploy/configuration/config.md#domains-state), необходимо переместить  ее на другой хост.
 
 {% include [warning-configuration-error](../_includes/warning-configuration-error.md) %}
 
@@ -19,9 +19,9 @@ domains_config:
 ...
 ```
 
-На хосте с `node_id:1` сконфигурирован и запущен [статический узел](../deploy/configuration/config.md#hosts) кластера, который обслуживает часть State Storage. Предположим, нам нужно вывести из эксплуатации этот хост.
+На хосте с `node_id:1` сконфигурирован и запущен [статический узел](../../deploy/configuration/config.md#hosts) кластера, который обслуживает часть State Storage. Предположим, нам нужно вывести из эксплуатации этот хост.
 
-Для замены `node_id:1` мы [добавили](../maintenance/manual/cluster_expansion.md#add-host) в кластер новый хост с `node_id:10` и [развернули](../maintenance/manual/cluster_expansion.md#add-static-node) на нем статический узел.
+Для замены `node_id:1` мы [добавили](../../maintenance/manual/cluster_expansion.md#add-host) в кластер новый хост с `node_id:10` и [развернули](../../maintenance/manual/cluster_expansion.md#add-static-node) на нем статический узел.
 
 Чтобы переместить State Storage с хоста `node_id:1` на `node_id:10`:
 
@@ -42,5 +42,5 @@ domains_config:
     ```
 
 1. Обновите конфигурационные файлы `config.yaml` для всех узлов кластера, в том числе и динамических.
-1. С помощью процедуры [rolling-restart](../maintenance/manual/node_restarting.md) перезапустите все узлы кластера, включая динамические, кроме статических узлов на хостах с `node_id:1` и `node_id:10`.
+1. С помощью процедуры [rolling-restart](../../maintenance/manual/node_restarting.md) перезапустите все узлы кластера, включая динамические, кроме статических узлов на хостах с `node_id:1` и `node_id:10`.
 1. Запустите статические узлы кластера на хостах `node_id:1` и `node_id:10`.
diff --git a/ydb/docs/ru/core/administration/static-group-move.md b/ydb/docs/ru/core/devops/manual/static-group-move.md
similarity index 68%
rename from ydb/docs/ru/core/administration/static-group-move.md
rename to ydb/docs/ru/core/devops/manual/static-group-move.md
index 41a432b675b3..20cc0a58438e 100644
--- a/ydb/docs/ru/core/administration/static-group-move.md
+++ b/ydb/docs/ru/core/devops/manual/static-group-move.md
@@ -1,10 +1,10 @@
 # Перемещение статической группы
 
-Если нужно вывести из эксплуатации хост кластера {{ ydb-short-name }}, на котором располагается часть [статической группы](../deploy/configuration/config.md#blob_storage_config), необходимо переместить ее на другой хост.
+Если нужно вывести из эксплуатации хост кластера {{ ydb-short-name }}, на котором располагается часть [статической группы](../../deploy/configuration/config.md#blob_storage_config), необходимо переместить ее на другой хост.
 
 {% include [warning-configuration-error](../_includes/warning-configuration-error.md) %}
 
-В качестве примера рассмотрим кластер {{ ydb-short-name }}, в котором на хосте с `node_id:1` сконфигурирован и запущен [статический узел](../deploy/configuration/config.md#hosts). Этот узел обслуживает часть статической группы.
+В качестве примера рассмотрим кластер {{ ydb-short-name }}, в котором на хосте с `node_id:1` сконфигурирован и запущен [статический узел](../../deploy/configuration/config.md#hosts). Этот узел обслуживает часть статической группы.
 
 Фрагмент конфигурации статической группы:
 
@@ -30,7 +30,7 @@ blob_storage_config:
 ...
 ```
 
-Для замены `node_id:1` мы [добавили](../maintenance/manual/cluster_expansion.md#add-host) в кластер новый хост с `node_id:10` и [развернули](../maintenance/manual/cluster_expansion.md#add-static-node) на нем статический узел.
+Для замены `node_id:1` мы [добавили](../../maintenance/manual/cluster_expansion.md#add-host) в кластер новый хост с `node_id:10` и [развернули](../../maintenance/manual/cluster_expansion.md#add-static-node) на нем статический узел.
 
 Чтобы переместить часть статической группы с хоста `node_id:1` на `node_id:10`:
 
@@ -64,6 +64,6 @@ blob_storage_config:
     Измените путь `path` и категорию `pdisk_category` диска, если на хосте с `node_id: 10` они отличаются.
 
 1. Обновите конфигурационные файлы `config.yaml` для всех узлов кластера, в том числе и динамических.
-1. С помощью процедуры [rolling-restart](../maintenance/manual/node_restarting.md) перезапустите все статические узлы кластера.
-1. Перейдите на страницу мониторинга Embedded UI и убедитесь, что VDisk статической группы появился на целевом физическом диске и реплицируется. Подробнее см. [{#T}](../maintenance/embedded_monitoring/ydb_monitoring.md#static-group).
-1. С помощью процедуры [rolling-restart](../maintenance/manual/node_restarting.md) перезапустите все динамические узлы кластера.
+1. С помощью процедуры [rolling-restart](../../maintenance/manual/node_restarting.md) перезапустите все статические узлы кластера.
+1. Перейдите на страницу мониторинга Embedded UI и убедитесь, что VDisk статической группы появился на целевом физическом диске и реплицируется. Подробнее см. [{#T}](../../reference/embedded-ui/ydb-monitoring.md#static-group).
+1. С помощью процедуры [rolling-restart](../../maintenance/manual/node_restarting.md) перезапустите все динамические узлы кластера.
diff --git a/ydb/docs/ru/core/devops/manual/toc_p.yaml b/ydb/docs/ru/core/devops/manual/toc_p.yaml
index df0e4d41e093..92b88e9492b3 100644
--- a/ydb/docs/ru/core/devops/manual/toc_p.yaml
+++ b/ydb/docs/ru/core/devops/manual/toc_p.yaml
@@ -1,6 +1,35 @@
 items:
-- include:
+- name: Обзор
+  href: index.md
+- name: Развертывание
+  include:
     mode: link
-    path: ../../cluster/toc_p.yaml
+    path: ../../deploy/toc_p.yaml
+- name: Управление дисковой подсистемой кластера
+  include:
+    mode: link
+    path: ../../maintenance/manual/toc_p.yaml
+- name: Мониторинг
+  href: monitoring.md
+- name: Обновление
+  href: upgrade.md
+- name: Изменение конфигурации актор-системы
+  href: ../../maintenance/manual/change_actorsystem_configs.md
+- name: Управление конфигурацией кластера
+  items:
+  - name: Обзор конфигурации
+    href: ../../maintenance/manual/config-overview.md
+  - name: Статическая конфигурация кластера
+    href: ../../deploy/configuration/config.md
+  - name: Динамическая конфигурация кластера
+    href: ../../maintenance/manual/dynamic-config.md
+  - name: DSL конфигурации кластера
+    href: ../../maintenance/manual/dynamic-config-selectors.md
+  - name: Временная конфигурация
+    href: ../../maintenance/manual/dynamic-config-volatile-config.md
+  - name: Изменение конфигураций через CMS
+    href: ../../maintenance/manual/cms.md
 - name: Системные таблицы
   href: system-views.md
+- name: Логирование
+  href: logging.md
diff --git a/ydb/docs/ru/core/administration/upgrade.md b/ydb/docs/ru/core/devops/manual/upgrade.md
similarity index 81%
rename from ydb/docs/ru/core/administration/upgrade.md
rename to ydb/docs/ru/core/devops/manual/upgrade.md
index e3bbe56b89d6..3d14f8410f07 100644
--- a/ydb/docs/ru/core/administration/upgrade.md
+++ b/ydb/docs/ru/core/devops/manual/upgrade.md
@@ -9,10 +9,10 @@
 1. Обновление и рестарт storage узлов;
 1. Обновление и рестарт динамических узлов.
 
-Процесс остановки и запуска описан на странице [Безопасные рестарт и выключение узлов](../maintenance/manual/node_restarting.md).
-Узлы {{ ydb-short-name }} следует обновлять последовательно по одному, после каждого шага контролировать состояние кластера через [{{ ydb-short-name }} Monitoring](../maintenance/embedded_monitoring/ydb_monitoring.md) - на вкладке `Storage` не должно быть пулов в состоянии `Degraded` (как на примере ниже). В противном случае обновление необходимо остановить.
+Процесс остановки и запуска описан на странице [Безопасные рестарт и выключение узлов](../../maintenance/manual/node_restarting.md).
+Узлы {{ ydb-short-name }} следует обновлять последовательно по одному, после каждого шага контролировать состояние кластера через [{{ ydb-short-name }} Monitoring](../../reference/embedded-ui/ydb-monitoring.md) - на вкладке `Storage` не должно быть пулов в состоянии `Degraded` (как на примере ниже). В противном случае обновление необходимо остановить.
 
-![Monitoring_storage_state](../maintenance/embedded_monitoring/_assets/monitoring_storage_state.png)
+![Monitoring_storage_state](../../reference/embedded-ui/_assets/monitoring_storage_state.png)
 
 ## Совместимость версий {#version-compatability}
 
@@ -29,7 +29,7 @@
 
 {% endnote %}
 
-Список доступных версий можно получить на [странице загрузки](https://ydb.tech/ru/docs/downloads/). Релизная политика YDB описана более детально в статье [Управление релизами](../contributor/manage-releases.md) в разделе документации для разработчиков YDB.
+Список доступных версий можно получить на [странице загрузки](../../downloads/index.md). Релизная политика YDB описана более детально в статье [Управление релизами](../../contributor/manage-releases.md) в разделе документации для разработчиков YDB.
 
 ### Примеры совместимости версий
 
diff --git a/ydb/docs/ru/core/cluster/system-requirements.md b/ydb/docs/ru/core/devops/system-requirements.md
similarity index 69%
rename from ydb/docs/ru/core/cluster/system-requirements.md
rename to ydb/docs/ru/core/devops/system-requirements.md
index c4599642a3b6..dce454c981eb 100644
--- a/ydb/docs/ru/core/cluster/system-requirements.md
+++ b/ydb/docs/ru/core/devops/system-requirements.md
@@ -1,12 +1,12 @@
-# Системные требования и рекомендации
+# Системные требования и рекомендации для {{ ydb-short-name }}
 
-В данном разделе приводятся рекомендации для развертывания {{ ydb-short-name }}.
+В данном разделе приводятся рекомендации для развертывания кластеров {{ ydb-short-name }}, применимые вне зависимости от выбранного способа управления инфраструктурой ([Ansible](ansible/index.md), [Kubernetes](kubernetes/index.md), или [вручную](manual/index.md)).
 
 ## Аппаратная конфигурация {#hardware}
 
-Необходимое количество серверов и дисков определяется требованиями к отказоустойчивости. Подробнее читайте в разделе [{#T}](topology.md).
+Необходимое количество серверов и дисков определяется требованиями к отказоустойчивости. Подробнее читайте в разделе [{#T}](../concepts/topology.md).
 
-* **Процессор**
+* **Процессор (CPU)**
 
   {{ ydb-short-name }} сервер может быть запущен только на процессорах с архитектурой x86-64 с поддержкой AVX2 инструкций: Intel Haswell (4 поколение) и более поздние, AMD EPYC и более поздние.
 
@@ -30,8 +30,8 @@
 
 ## Программная конфигурация {#software}
 
-{{ ydb-short-name }} сервер может быть запущен на серверах с операционной системой Linux с ядром 4.19 и выше и libc 2.30 (Ubuntu 20.04, Debian 11, Fedora34). YDB использует аллокатор памяти [TCMalloc](https://google.github.io/tcmalloc), для его эффективной работы мы рекомендуем [включить](https://google.github.io/tcmalloc/tuning.html#system-level-optimizations) Transparent Huge Pages и Memory overcommitment.
+{{ ydb-short-name }} сервер может быть запущен на серверах с операционной системой Linux с ядром 4.19 и выше и libc 2.30. Например, Ubuntu 20.04, Debian 11, Fedora34, или более свежие их версии. {{ ydb-short-name }} использует аллокатор памяти [TCMalloc](https://google.github.io/tcmalloc), для его эффективной работы мы рекомендуем [включить](https://google.github.io/tcmalloc/tuning.html#system-level-optimizations) Transparent Huge Pages и Memory overcommitment.
 
-Если сервер имеет более 32 ядер CPU, для повышения производительности YDB динноды следует запускать в раздельных taskset/cpuset, размером от 10 до 32 ядер. Например, в случае 128 ядер лучше всего запустить 4 динноды: каждую в своем taskset, размером 32 ядра.
+Если сервер имеет более 32 ядер CPU, для повышения производительности {{ ydb-short-name }} динноды следует запускать в раздельных taskset/cpuset, размером от 10 до 32 ядер. Например, в случае 128 ядер лучше всего запустить 4 динноды: каждую в своем taskset, размером 32 ядра.
 
-Операционные системы macOS и Windows в данный момент не поддерживаются для запуска серверной части {{ ydb-short-name }}.
+Операционные системы macOS и Windows в данный момент не поддерживаются для запуска серверной части {{ ydb-short-name }}. Тем не менее, для целей разработки и функционального тестирования допустимо запускать {{ ydb-short-name }} на них в [Docker контейнере](../quickstart.md).
diff --git a/ydb/docs/ru/core/devops/toc_p.yaml b/ydb/docs/ru/core/devops/toc_p.yaml
index c226875d7971..9bd8ea8bf0e3 100644
--- a/ydb/docs/ru/core/devops/toc_p.yaml
+++ b/ydb/docs/ru/core/devops/toc_p.yaml
@@ -1,6 +1,8 @@
 items:
 - name: Обзор
   href: index.md
+- name: Системные требования
+  href: system-requirements.md
 - name: Ansible
   include:
     mode: link
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/toc_p.yaml b/ydb/docs/ru/core/maintenance/embedded_monitoring/toc_p.yaml
deleted file mode 100644
index 3e62ad228bcc..000000000000
--- a/ydb/docs/ru/core/maintenance/embedded_monitoring/toc_p.yaml
+++ /dev/null
@@ -1,4 +0,0 @@
-items:
-- name: Обзор
-  href: index.md
-- include: { mode: link, path: toc_i.yaml }
\ No newline at end of file
diff --git a/ydb/docs/ru/core/maintenance/manual/balancing_load.md b/ydb/docs/ru/core/maintenance/manual/balancing_load.md
index afecc00bbf80..2dc077f4dbdd 100644
--- a/ydb/docs/ru/core/maintenance/manual/balancing_load.md
+++ b/ydb/docs/ru/core/maintenance/manual/balancing_load.md
@@ -7,11 +7,11 @@
 
 ## Распределить нагрузку равномерно по группам {#reassign-groups}
 
-На странице [Hive web-viewer](../embedded_monitoring/hive.md#reassign_groups), в нижней части экрана есть кнопка "Reassign Groups".
+На странице [Hive web-viewer](../../reference/embedded-ui/hive.md#reassign_groups), в нижней части экрана есть кнопка "Reassign Groups".
 
 ## Распределить VDisk'и равномерно по устройствам {#cluster-balance}
 
-В результате некоторых операций, например [декомиссии](../../administration/decommissioning.md), VDisk'и могут быть распределены на блочных устройствах неравномерно. Улучшить равномерность распределения можно одним из способов:
+В результате некоторых операций, например [декомиссии](../../devops/manual/decommissioning.md), VDisk'и могут быть распределены на блочных устройствах неравномерно. Улучшить равномерность распределения можно одним из способов:
 
 * [Перевезти VDisk'и](moving_vdisks.md#moving_vdisk) по одному с перегруженных устройств.
 * Воспользоваться утилитой [{{ ydb-short-name }} DSTool](../../reference/ydb-dstool/index.md). Следующая команда перевезет VDisk с перегруженного устройства на менее нагруженное:
diff --git a/ydb/docs/ru/core/maintenance/manual/cluster_expansion.md b/ydb/docs/ru/core/maintenance/manual/cluster_expansion.md
index 22deedf7b92e..5e131fa24cdb 100644
--- a/ydb/docs/ru/core/maintenance/manual/cluster_expansion.md
+++ b/ydb/docs/ru/core/maintenance/manual/cluster_expansion.md
@@ -21,7 +21,7 @@
 
 Для добавления динамического узла в кластер достаточно запустить процесс, обслуживающий этот узел, передав ему в параметрах командной строки путь к конфигурационному файлу кластера, имя обслуживаемой базы данных и адреса любых трех статических узлов кластера кластера {{ ydb-short-name }}, как показано в [инструкции по развертыванию кластеров](../../deploy/manual/deploy-ydb-on-premises.md#start-dynnode).
 
-После успешного добавления динамического узла в кластер информация о нем будет доступна на [странице мониторинга кластера во встроенном UI](../embedded_monitoring/ydb_monitoring.md).
+После успешного добавления динамического узла в кластер информация о нем будет доступна на [странице мониторинга кластера во встроенном UI](../../reference/embedded-ui/ydb-monitoring.md).
 
 Для вывода динамического узла из кластера достаточно выполнить остановку процесса динамического узла.
 
@@ -45,7 +45,7 @@
 
 1. Запустить процессы, обслуживающие новые статические узлы кластера, на соответствующих серверах.
 
-1. Убедиться в том, что новые статические узлы отображаются на [странице мониторинга кластера во встроенном UI](../embedded_monitoring/ydb_monitoring.md).
+1. Убедиться в том, что новые статические узлы отображаются на [странице мониторинга кластера во встроенном UI](../../reference/embedded-ui/ydb-monitoring.md).
 
 1. Получить токен аутентификации для выполнения административных команд с помощью {{ ydb-short-name }} CLI, например:
 
@@ -99,8 +99,8 @@
     * `/Root/testdb` - полный путь к базе данных;
     * `ssd:1` - имя пула хранения и количество выделяемых групп хранения.
 
-3. Убедиться, что добавленные группы хранения отображаются [странице мониторинга кластера во встроенном UI](../embedded_monitoring/ydb_monitoring.md).
+3. Убедиться, что добавленные группы хранения отображаются [странице мониторинга кластера во встроенном UI](../../reference/embedded-ui/ydb-monitoring.md).
 
-Вывод статических узлов из кластера {{ ydb-short-name }} производится в соответствии с [документированной процедурой декомиссии](../../administration/decommissioning.md).
+Вывод статических узлов из кластера {{ ydb-short-name }} производится в соответствии с [документированной процедурой декомиссии](../../devops/manual/decommissioning.md).
 
 В случае повреждения и невозможности ремонта сервера, на котором работает статический узел кластера, необходимо разместить недоступный статический узел на новом сервере, содержащем аналогичное или большее количество и объем дисков.
diff --git a/ydb/docs/ru/core/maintenance/manual/index.md b/ydb/docs/ru/core/maintenance/manual/index.md
index 4e241b6a7ee4..6d2f6d1c383e 100644
--- a/ydb/docs/ru/core/maintenance/manual/index.md
+++ b/ydb/docs/ru/core/maintenance/manual/index.md
@@ -6,15 +6,15 @@
 
   * [{#T}](cluster_expansion.md).
   * [{#T}](adding_storage_groups.md).
-  * [{#T}](../../administration/state-storage-move.md)
-  * [{#T}](../../administration/static-group-move.md)
+  * [{#T}](../../devops/manual/state-storage-move.md)
+  * [{#T}](../../devops/manual/static-group-move.md)
 
 * Обслуживание:
 
   * [{#T}](node_restarting.md).
   * [{#T}](scrubbing.md).
   * [{#T}](selfheal.md).
-  * [{#T}](../../administration/decommissioning.md).
+  * [{#T}](../../devops/manual/decommissioning.md).
   * [{#T}](moving_vdisks.md).
   * [{#T}](replacing_nodes.md).
 
diff --git a/ydb/docs/ru/core/maintenance/manual/moving_vdisks.md b/ydb/docs/ru/core/maintenance/manual/moving_vdisks.md
index aaa734915b36..e1e53990b77d 100644
--- a/ydb/docs/ru/core/maintenance/manual/moving_vdisks.md
+++ b/ydb/docs/ru/core/maintenance/manual/moving_vdisks.md
@@ -28,7 +28,7 @@ ydbd admin bs config invoke --proto 'Command { ReassignGroupDisk { GroupId: <ID
 
 В случае, если SelfHeal выключен или не перевозит VDisk'и автоматически, перевоз нужно выполнить вручную:
 
-1. Откройте [мониторинг](../../maintenance/embedded_monitoring/ydb_monitoring.md) и убедитесь, что VDisk в нерабочем состоянии.
+1. Откройте [мониторинг](../../reference/embedded-ui/ydb-monitoring.md) и убедитесь, что VDisk в нерабочем состоянии.
 1. Получите `[NodeId:PDiskId]` нужного диска с помощью утилиты [{{ ydb-short-name }} DSTool](../../reference/ydb-dstool/index.md):
 
     ```bash
@@ -45,7 +45,7 @@ ydbd admin bs config invoke --proto 'Command { ReassignGroupDisk { GroupId: <ID
 
 Чтобы вернуть PDisk после развоза:
 
-1. Откройте [мониторинг](../../maintenance/embedded_monitoring/ydb_monitoring.md) и убедитесь, что PDisk в рабочем состоянии.
+1. Откройте [мониторинг](../../reference/embedded-ui/ydb-monitoring.md) и убедитесь, что PDisk в рабочем состоянии.
 1. Получите `[NodeId:PDiskId]` нужного диска с помощью утилиты [{{ ydb-short-name }} DSTool](../../reference/ydb-dstool/index.md):
 
     ```bash
diff --git a/ydb/docs/ru/core/maintenance/manual/node_restarting.md b/ydb/docs/ru/core/maintenance/manual/node_restarting.md
index fd871c0e258a..f81b118bc977 100644
--- a/ydb/docs/ru/core/maintenance/manual/node_restarting.md
+++ b/ydb/docs/ru/core/maintenance/manual/node_restarting.md
@@ -32,7 +32,7 @@
 
 Чтобы отключение динамического узла не оказало влияние на обработку запросов, необходимо перед отключением выполнить мягкий перенос (drain) таблеток с этого узла.
 
-Стоит перейти на страницу [Hive web-viewer](../embedded_monitoring/hive.md).
+Стоит перейти на страницу [Hive web-viewer](../../reference/embedded-ui/hive.md).
 После нажатия на кнопку "View Nodes" отобразится список всех узлов.
 
 Перед отключением узла, сначала требуется отключить перевоз таблеток через кнопку Active, после чего нажать Drain и дождаться увоза всех таблеток.
diff --git a/ydb/docs/ru/core/maintenance/manual/toc_i.yaml b/ydb/docs/ru/core/maintenance/manual/toc_i.yaml
index cf7146c01307..0400cedda1ba 100644
--- a/ydb/docs/ru/core/maintenance/manual/toc_i.yaml
+++ b/ydb/docs/ru/core/maintenance/manual/toc_i.yaml
@@ -4,9 +4,9 @@ items:
 - name: Добавление групп хранения
   href: adding_storage_groups.md
 - name: Перемещение State Storage
-  href: ../../administration/state-storage-move.md
+  href: ../../devops/manual/state-storage-move.md
 - name: Перемещение статической группы
-  href: ../../administration/static-group-move.md
+  href: ../../devops/manual/static-group-move.md
 - name: Безопасный рестарт и выключение узлов
   href: node_restarting.md
 - name: Включение и выключение Scrubbing
@@ -14,7 +14,7 @@ items:
 - name: Работа с SelfHeal
   href: selfheal.md
 - name: Декомиссия части кластера
-  href: ../../administration/decommissioning.md
+  href: ../../devops/manual/decommissioning.md
 - name: Перевоз VDisk'ов
   href: moving_vdisks.md
 - name: Замена FQDN узла
diff --git a/ydb/docs/ru/core/maintenance/toc_i.yaml b/ydb/docs/ru/core/maintenance/toc_i.yaml
index 30b3414b4f1a..c187b0077f92 100644
--- a/ydb/docs/ru/core/maintenance/toc_i.yaml
+++ b/ydb/docs/ru/core/maintenance/toc_i.yaml
@@ -6,11 +6,13 @@ items:
 - name: Обслуживание кластера
   items:
   - name: Встроенный UI
-    include: { mode: link, path: embedded_monitoring/toc_p.yaml }
+    include: { mode: link, path: ../reference/embedded-ui/toc_p.yaml }
   - name: Управление дисковой подсистемой кластера
     include: { mode: link, path: manual/toc_p.yaml }
   - name: Изменение конфигурации актор-системы
     href: manual/change_actorsystem_configs.md
+  - name: Обслуживание кластера без потери доступности
+    href: maintenance-without-outages.md
   - name: Управление конфигурацией кластера
     items:
     - name: Обзор конфигурации
diff --git a/ydb/docs/ru/core/postgresql/intro.md b/ydb/docs/ru/core/postgresql/intro.md
index 5c3e4d16223e..9992741169a4 100644
--- a/ydb/docs/ru/core/postgresql/intro.md
+++ b/ydb/docs/ru/core/postgresql/intro.md
@@ -1,4 +1,4 @@
-## Введение
+## Совместимость {{ ydb-short-name }} с PostgreSQL
 
 {% include [./_includes/alert.md](./_includes/alert_preview.md) %}
 
diff --git a/ydb/docs/ru/core/quickstart.md b/ydb/docs/ru/core/quickstart.md
index 68ed7e642790..1db344e5c235 100644
--- a/ydb/docs/ru/core/quickstart.md
+++ b/ydb/docs/ru/core/quickstart.md
@@ -2,7 +2,7 @@
 
 В этом руководстве вы установите одноузловой локальный [кластер {{ ydb-short-name }}](concepts/databases.md#cluster) и выполните простые запросы к вашей [базе данных](concepts/databases.md#database).
 
-Обычно {{ ydb-short-name }} хранит данные напрямую на нескольких дисковых устройствах SSD/NVMe или HDD без использования файловой системы. Однако для простоты данное руководство эмулирует диски в оперативной памяти или с использованием файла в обычной файловой системе. Таким образом, эта конфигурация не подходит для использования в промышленном окружении и даже для проведения тестов производительности. Ознакомьтесь с [документацией по управлению кластерами](cluster/index.md) для запуска {{ ydb-short-name }} в промышленном окружении.
+Обычно {{ ydb-short-name }} хранит данные напрямую на нескольких дисковых устройствах SSD/NVMe или HDD без использования файловой системы. Однако для простоты данное руководство эмулирует диски в оперативной памяти или с использованием файла в обычной файловой системе. Таким образом, эта конфигурация не подходит для использования в промышленном окружении и даже для проведения тестов производительности. Ознакомьтесь с [документацией для DevOps-инженеров](devops/index.md) для запуска {{ ydb-short-name }} в production окружении.
 
 ## Установите и запустите {{ ydb-short-name }} {#install}
 
@@ -235,5 +235,5 @@ FLATTEN LIST BY keys AS key
 
 * Пройдите более подробный [курс по YQL](yql/reference/index.md), который сосредоточен на написании запросов.
 * Попробуйте создать свое первое приложение для хранения данных в {{ ydb-short-name }} с использованием [одного из SDK](reference/ydb-sdk/index.md).
-* Узнайте, как настроить [развертывание {{ ydb-short-name }} в готовую к промышленной эксплуатации среду](cluster/index.md).
+* Узнайте, как настроить [развертывание {{ ydb-short-name }} в готовую к промышленной эксплуатации среду](devops/index.md).
 * Почитайте об используемых в {{ ydb-short-name }} [концепциях](concepts/index.md).
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/_assets/monitoring_main_page.png b/ydb/docs/ru/core/reference/embedded-ui/_assets/monitoring_main_page.png
similarity index 100%
rename from ydb/docs/ru/core/maintenance/embedded_monitoring/_assets/monitoring_main_page.png
rename to ydb/docs/ru/core/reference/embedded-ui/_assets/monitoring_main_page.png
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/_assets/monitoring_storage_state.png b/ydb/docs/ru/core/reference/embedded-ui/_assets/monitoring_storage_state.png
similarity index 100%
rename from ydb/docs/ru/core/maintenance/embedded_monitoring/_assets/monitoring_storage_state.png
rename to ydb/docs/ru/core/reference/embedded-ui/_assets/monitoring_storage_state.png
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/charts.md b/ydb/docs/ru/core/reference/embedded-ui/charts.md
similarity index 100%
rename from ydb/docs/ru/core/maintenance/embedded_monitoring/charts.md
rename to ydb/docs/ru/core/reference/embedded-ui/charts.md
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/hive.md b/ydb/docs/ru/core/reference/embedded-ui/hive.md
similarity index 100%
rename from ydb/docs/ru/core/maintenance/embedded_monitoring/hive.md
rename to ydb/docs/ru/core/reference/embedded-ui/hive.md
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/index.md b/ydb/docs/ru/core/reference/embedded-ui/index.md
similarity index 91%
rename from ydb/docs/ru/core/maintenance/embedded_monitoring/index.md
rename to ydb/docs/ru/core/reference/embedded-ui/index.md
index cd51c7e8f39d..1354c9f68869 100644
--- a/ydb/docs/ru/core/maintenance/embedded_monitoring/index.md
+++ b/ydb/docs/ru/core/reference/embedded-ui/index.md
@@ -7,7 +7,7 @@ description: "Из статьи вы узнаете о инструментах
 
 {{ ydb-short-name }} предоставляет инструменты для мониторинга и определения состояния системы:
 
-* [{{ ydb-short-name }} Monitoring](ydb_monitoring.md) — основной обозреватель кластера. Показывает состояние узлов, групп хранения.
-* [Interconnect overview](interconnect_overview.md) — состояние соединений узлов кластера друг с другом.
+* [{{ ydb-short-name }} Monitoring](ydb-monitoring.md) — основной обозреватель кластера. Показывает состояние узлов, групп хранения.
+* [Interconnect overview](interconnect-overview.md) — состояние соединений узлов кластера друг с другом.
 * [Логи](logs.md) — каждый компонент {{ ydb-short-name }} пишет сообщения в логи разного уровня. По ним можно детектировать критические проблемы или разобраться в причинах неполадок.
 * [Графики](charts.md) — {{ ydb-short-name }} собирает множество метрик, по которым можно определить состояние системы либо конкретного компонента.
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/interconnect_overview.md b/ydb/docs/ru/core/reference/embedded-ui/interconnect-overview.md
similarity index 100%
rename from ydb/docs/ru/core/maintenance/embedded_monitoring/interconnect_overview.md
rename to ydb/docs/ru/core/reference/embedded-ui/interconnect-overview.md
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/logs.md b/ydb/docs/ru/core/reference/embedded-ui/logs.md
similarity index 100%
rename from ydb/docs/ru/core/maintenance/embedded_monitoring/logs.md
rename to ydb/docs/ru/core/reference/embedded-ui/logs.md
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/overview.md b/ydb/docs/ru/core/reference/embedded-ui/overview.md
similarity index 100%
rename from ydb/docs/ru/core/maintenance/embedded_monitoring/overview.md
rename to ydb/docs/ru/core/reference/embedded-ui/overview.md
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/toc_i.yaml b/ydb/docs/ru/core/reference/embedded-ui/toc_i.yaml
similarity index 82%
rename from ydb/docs/ru/core/maintenance/embedded_monitoring/toc_i.yaml
rename to ydb/docs/ru/core/reference/embedded-ui/toc_i.yaml
index 2bb60d054003..81bd30331cfd 100644
--- a/ydb/docs/ru/core/maintenance/embedded_monitoring/toc_i.yaml
+++ b/ydb/docs/ru/core/reference/embedded-ui/toc_i.yaml
@@ -6,11 +6,11 @@ items:
   href: viewer.md
   when: false
 - name: YDB Monitoring
-  href: ydb_monitoring.md
+  href: ydb-monitoring.md
 - name: Hive web-viewer
   href: hive.md
 - name: Обзор соединений
-  href: interconnect_overview.md
+  href: interconnect-overview.md
 - name: Логи
   href: logs.md
 - name: Графики
diff --git a/ydb/docs/ru/core/cluster/toc_p.yaml b/ydb/docs/ru/core/reference/embedded-ui/toc_p.yaml
similarity index 100%
rename from ydb/docs/ru/core/cluster/toc_p.yaml
rename to ydb/docs/ru/core/reference/embedded-ui/toc_p.yaml
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/ydb_monitoring.md b/ydb/docs/ru/core/reference/embedded-ui/ydb-monitoring.md
similarity index 100%
rename from ydb/docs/ru/core/maintenance/embedded_monitoring/ydb_monitoring.md
rename to ydb/docs/ru/core/reference/embedded-ui/ydb-monitoring.md
diff --git a/ydb/docs/ru/core/reference/kafka-api/auth.md b/ydb/docs/ru/core/reference/kafka-api/auth.md
index 1a97fc4d0eb5..696541c48d22 100644
--- a/ydb/docs/ru/core/reference/kafka-api/auth.md
+++ b/ydb/docs/ru/core/reference/kafka-api/auth.md
@@ -2,8 +2,8 @@
 В Kafka API аутентификация выполняется через механизмы `SASL_PLAINTEXT/PLAIN` или `SASL_SSL/PLAIN`.
 
 Для аутентификации необходимы:
-* `<user-name>` — имя пользователя. Об управлении пользователями читайте в разделе [Управление доступом](../../cluster/access.md).
-* `<password>` — пароль пользователя. Об управлении пользователями читайте в разделе [Управление доступом](../../cluster/access.md).
+* `<user-name>` — имя пользователя. Об управлении пользователями читайте в разделе [Управление доступом](../../security/access-management.md).
+* `<password>` — пароль пользователя. Об управлении пользователями читайте в разделе [Управление доступом](../../security/access-management.md).
 * `<database>` — [путь базы данных](../../concepts/connect#database).
 
 Из этих параметров формируются:
diff --git a/ydb/docs/ru/core/reference/kafka-api/read-write.md b/ydb/docs/ru/core/reference/kafka-api/read-write.md
index 9bddf74b5122..b8bc7751390d 100644
--- a/ydb/docs/ru/core/reference/kafka-api/read-write.md
+++ b/ydb/docs/ru/core/reference/kafka-api/read-write.md
@@ -5,7 +5,7 @@
 Перед выполнением примеров:
 1. [Создайте топик](../ydb-cli/topic-create.md).
 1. [Добавьте читателя](../ydb-cli/topic-consumer-add.md).
-1. [Создайте пользователя](../../cluster/access.md#users).
+1. [Создайте пользователя](../../security/access-management.md#users).
 
 В примерах используются:
 
diff --git a/ydb/docs/ru/core/administration/grafana-dashboards.md b/ydb/docs/ru/core/reference/observability/metrics/grafana-dashboards.md
similarity index 97%
rename from ydb/docs/ru/core/administration/grafana-dashboards.md
rename to ydb/docs/ru/core/reference/observability/metrics/grafana-dashboards.md
index a1eccc341318..5dbdc76a7a43 100644
--- a/ydb/docs/ru/core/administration/grafana-dashboards.md
+++ b/ydb/docs/ru/core/reference/observability/metrics/grafana-dashboards.md
@@ -1,6 +1,6 @@
-# Дашборды Grafana
+# Grafana дашборды для {{ ydb-short-name }}
 
-На этой странице представлено описание дашбордов Grafana для {{ ydb-short-name }}. Как установить дашборды читайте в разделе [{#T}](monitoring.md#prometheus-grafana).
+На этой странице представлено описание дашбордов Grafana для {{ ydb-short-name }}. Как установить дашборды читайте в разделе [{#T}](../../../devops/manual/monitoring.md#prometheus-grafana).
 
 ## DB status {#dbstatus}
 
diff --git a/ydb/docs/ru/core/reference/observability/metrics/index.md b/ydb/docs/ru/core/reference/observability/metrics/index.md
index 8bdffe075c74..aaacfb2e1919 100644
--- a/ydb/docs/ru/core/reference/observability/metrics/index.md
+++ b/ydb/docs/ru/core/reference/observability/metrics/index.md
@@ -1,5 +1,11 @@
 # Справка по метрикам
 
+{% note info %}
+
+См. также [{#T}](grafana-dashboards.md).
+
+{% endnote %}
+
 ## Метрики использования ресурсов {#resources}
 
 Имя метрики<br/>Тип, единицы измерения | Описание<br/>Метки
diff --git a/ydb/docs/ru/core/reference/observability/metrics/toc_p.yaml b/ydb/docs/ru/core/reference/observability/metrics/toc_p.yaml
new file mode 100644
index 000000000000..e4bcb437cb5e
--- /dev/null
+++ b/ydb/docs/ru/core/reference/observability/metrics/toc_p.yaml
@@ -0,0 +1,5 @@
+items:
+- name: Справка по метрикам
+  href: index.md
+- name: Grafana дашборды 
+  href: grafana-dashboards.md
\ No newline at end of file
diff --git a/ydb/docs/ru/core/reference/observability/toc_p.yaml b/ydb/docs/ru/core/reference/observability/toc_p.yaml
index b9a22a9f082e..c92ddc9d33a5 100644
--- a/ydb/docs/ru/core/reference/observability/toc_p.yaml
+++ b/ydb/docs/ru/core/reference/observability/toc_p.yaml
@@ -1,3 +1,9 @@
 items:
-- name: Справка по метрикам
-  href: metrics/index.md
+- name: Метрики
+  include:
+    mode: link
+    path: metrics/toc_p.yaml
+- name: Трассировка
+  include:
+    mode: link
+    path: tracing/toc_p.yaml
\ No newline at end of file
diff --git a/ydb/docs/ru/core/reference/observability/tracing/setup.md b/ydb/docs/ru/core/reference/observability/tracing/setup.md
index f47d2fd7634f..b7d2a7976ea7 100644
--- a/ydb/docs/ru/core/reference/observability/tracing/setup.md
+++ b/ydb/docs/ru/core/reference/observability/tracing/setup.md
@@ -251,7 +251,7 @@ tracing_config:
 
 ### Уровни детализации {#tracing-levels}
 
-Как и в [случае с логами](../../../maintenance/embedded_monitoring/logs.md), для диагностирования большинства проблем с системой не требуется наличие максимально подробной трассы, поэтому в {{ ydb-short-name }} каждый спан имеет свой уровень, описываемый целым числом от 0 до 15 включительно. Каждое правило в секции `sampling` должно включать в себя уровень детализации генерируемой трассы (`level`), в нее будут включаться спаны с уровнем меньшим, либо равным `level`.
+Как и в [случае с логами](../../../reference/embedded-ui/logs.md), для диагностирования большинства проблем с системой не требуется наличие максимально подробной трассы, поэтому в {{ ydb-short-name }} каждый спан имеет свой уровень, описываемый целым числом от 0 до 15 включительно. Каждое правило в секции `sampling` должно включать в себя уровень детализации генерируемой трассы (`level`), в нее будут включаться спаны с уровнем меньшим, либо равным `level`.
 
 В разделе об [архитектуре {{ ydb-short-name }}](../../../concepts/_includes/index/how_it_works.md#ydb-architecture) приводится разделение системы на 5 слоев:
 
diff --git a/ydb/docs/ru/core/reference/toc_p.yaml b/ydb/docs/ru/core/reference/toc_p.yaml
index b1faf930907c..3bc4f934834f 100644
--- a/ydb/docs/ru/core/reference/toc_p.yaml
+++ b/ydb/docs/ru/core/reference/toc_p.yaml
@@ -7,6 +7,10 @@ items:
   include:
     mode: link
     path: ../postgresql/toc_p.yaml
+- name: Встроенный UI
+  include:
+    mode: link
+    path: embedded-ui/toc_p.yaml
 - name: Интеграции
   include: 
     mode: link
diff --git a/ydb/docs/ru/core/cluster/access.md b/ydb/docs/ru/core/security/access-management.md
similarity index 100%
rename from ydb/docs/ru/core/cluster/access.md
rename to ydb/docs/ru/core/security/access-management.md
diff --git a/ydb/docs/ru/core/cluster/audit-log.md b/ydb/docs/ru/core/security/audit-log.md
similarity index 99%
rename from ydb/docs/ru/core/cluster/audit-log.md
rename to ydb/docs/ru/core/security/audit-log.md
index 57ed280664ca..6404691aaa73 100644
--- a/ydb/docs/ru/core/cluster/audit-log.md
+++ b/ydb/docs/ru/core/security/audit-log.md
@@ -18,7 +18,7 @@ _Аудитный лог_ — это поток, который содержит
 
 В случае направления в файл доступ к аудитному логу задается правами на уровне файловой системы. Сохранение аудитного лога в файл рекомендуется для использования в промышленных инсталляциях.
 
-Направление аудитного лога в стандартный вывод ошибок `stderr` рекомендуется для тестовых инсталляций. Дальнейшая обработка данных потока определяется настройками [логирования](./logs.md) кластера {{ ydb-short-name }}.
+Направление аудитного лога в стандартный вывод ошибок `stderr` рекомендуется для тестовых инсталляций. Дальнейшая обработка данных потока определяется настройками [логирования](../devops/manual/logging.md) кластера {{ ydb-short-name }}.
 
 ## События аудитного лога {#events}
 
diff --git a/ydb/docs/ru/core/security/index.md b/ydb/docs/ru/core/security/index.md
new file mode 100644
index 000000000000..93dbde0a7fef
--- /dev/null
+++ b/ydb/docs/ru/core/security/index.md
@@ -0,0 +1,12 @@
+# {{ ydb-short-name }} для инженеров по безопасности
+
+В этом разделе документации {{ ydb-short-name }} рассматриваются аспекты работы с {{ ydb-short-name }}, связанные с безопасностью. Также он будет полезнен для целей обеспечения compliance.
+
+Основные материалы:
+
+- [{#T}](access-management.md)
+- [{#T}](audit-log.md)
+- [{#T}](short-access-control-notation.md)
+- Концепции:
+    - [{#T}](../concepts/auth.md)
+    - [{#T}](../concepts/connect.md)
\ No newline at end of file
diff --git a/ydb/docs/ru/core/cluster/short-access-control-notation.md b/ydb/docs/ru/core/security/short-access-control-notation.md
similarity index 100%
rename from ydb/docs/ru/core/cluster/short-access-control-notation.md
rename to ydb/docs/ru/core/security/short-access-control-notation.md
diff --git a/ydb/docs/ru/core/security/toc_p.yaml b/ydb/docs/ru/core/security/toc_p.yaml
new file mode 100644
index 000000000000..c4dd5231b798
--- /dev/null
+++ b/ydb/docs/ru/core/security/toc_p.yaml
@@ -0,0 +1,9 @@
+items:
+- name: Обзор
+  href: index.md
+- name: Управление доступом
+  href: access-management.md
+- name: Аудитный лог 
+  href: audit-log.md
+- name: Краткая запись управления доступом
+  href: short-access-control-notation.md
\ No newline at end of file
diff --git a/ydb/docs/ru/core/toc_i.yaml b/ydb/docs/ru/core/toc_i.yaml
index 80c59e4db517..8ff0bc835988 100644
--- a/ydb/docs/ru/core/toc_i.yaml
+++ b/ydb/docs/ru/core/toc_i.yaml
@@ -19,11 +19,14 @@ items:
   include:
     mode: link
     path: dev/toc_p.yaml
+- name: Для инженеров безопасности
+  include:
+    mode: link
+    path: security/toc_p.yaml
 - name: Для контрибьюторов
   include:
     mode: link
     path: contributor/toc_p.yaml
-
 - name: Справка
   include:
     mode: link
diff --git a/ydb/docs/ru/core/toc_p.yaml b/ydb/docs/ru/core/toc_p.yaml
index b3bc4402e07b..5c74373d6143 100644
--- a/ydb/docs/ru/core/toc_p.yaml
+++ b/ydb/docs/ru/core/toc_p.yaml
@@ -1,4 +1,6 @@
 title: YDB
 href: index.yaml
 items:
-- include: { mode: link, path: toc_i.yaml }
\ No newline at end of file
+- include:
+  mode: link
+  path: toc_i.yaml
\ No newline at end of file