# Три слоя без пересечений

> Инфраструктура, сервисы, край площадки. Правило нулевого перекрытия между ними — не эстетика, а способ понять, кто виноват, когда что-то сломалось.

Source: https://naasson.com/ru/blog/tri-sloya-bez-peresecheniy/
Published: 2026-07-12
Language: ru
Product: Naasson Cloud (https://naasson.com/ru/products/naasson-cloud/)
Publisher: Naasson — https://naasson.com

---
Инструмент делит инфраструктуру на три слоя: инфраструктура, сервисы, край. И задаёт между ними правило нулевого перекрытия — каждый объект принадлежит ровно одному слою.

Правило выглядит бюрократическим. Оно решает конкретную проблему: понять, кто владеет объектом, когда объект сломался.

## Слой инфраструктуры

Машины, сети, кластеры, тома. То, что предоставляет облако или железо.

Владелец на производственном треке — Cluster API. Инструмент оркестрирует, но жизненным циклом ресурса управляет оператор в кластере, и состояние живёт в etcd.

## Слой сервисов

Всё, что работает в кластере: приложения, базы, вспомогательные компоненты.

Владелец — ArgoCD. Инструмент не делает установку в кластер напрямую: он пишет желаемое состояние в репозиторий, коммитит и отправляет канонический GitOps-источник, после чего применяет ArgoCD.

Это принципиально. Команда установки приложения не означает «поставить сейчас», она означает «записать, что оно должно быть». Разница видна в момент, когда кто-то удалит приложение из кластера руками: слой сервисов вернёт его обратно, потому что владелец — репозиторий.

## Слой края

Физическая площадка: устройства, кабели, порты, питание, слаботочка, зоны, шкафы.

У этого слоя другая природа. Он не «применяется» — он описывается, проверяется и экспортируется. Опасные живые действия здесь заблокированы до появления доказанного бэкенда, модели полномочий, резервного копирования и откатной процедуры.

## Почему перекрытие запрещено

Представьте объект, который принадлежит и слою инфраструктуры, и слою сервисов. Тогда у него два владельца с правом приводить его к своему представлению о желаемом состоянии.

Дальше начинается борьба сверок: один владелец меняет, другой возвращает, оба считают себя правыми. Симптом со стороны — объект «мигает», и разбирательство занимает дни, потому что каждый слой по отдельности ведёт себя корректно.

Правило нулевого перекрытия убирает этот класс отказов конструктивно.

## Что делать, когда объект похож на два слоя

Такое бывает. Балансировщик — это инфраструктура или сервис. Секрет — это сервис или край.

Ответ всегда один: выбрать слой и записать выбор в описание проекта. Не «зависит от контекста» и не «оба». Владелец должен быть определён до того, как объект появился, а не в момент разбирательства.

Практическое следствие: часть решений при заведении проекта неприятны, потому что требуют определённости там, где хочется гибкости. Это та же цена, что и у требования git, и платится она в том же месте — на старте.

## Как это связано с журналом

Раз у каждого объекта один владелец, у каждого изменения один источник. Журнал аудита собирается из нескольких мест — записи инструмента, история git, состояние кластера, — но запрос к нему единый, и в нём нет двух конкурирующих версий события.

Без правила слоёв единый журнал был бы невозможен: пришлось бы объяснять, почему один и тот же объект изменялся дважды разными системами в одну секунду.