# Xops Platform Design

> Спроектировать общие возможности платформы, их эксплуатационные границы, ответственность, путь внедрения и компромиссы. Использовать для существенных платформенных решений, а не каждого развёртывания приложения.

- Skill: `fbakiyev/xops-platform-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fbakiyev/xops-platform-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fbakiyev/xops-platform-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fbakiyev (https://skillmd.com/u/fbakiyev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/fbakiyev/xops-platform-design

---


# Проектирование платформы xOps

## Установи потребность

- Определи потребителей платформы, их нагрузки и ограничения, а также возможность, которую платформа должна упростить. Отличай подтверждённую потребность от предполагаемого списка будущих функций.
- Укажи цели сервиса, допущения о масштабе, требования к изоляции, эксплуатационный персонал и существующие обязательства. Неизвестные требования должны оставаться допущениями с указанием влияния на решение.
- Обозначь границы управления, данных, идентификации, развёртывания и восстановления. Установи общие зависимости, отказ которых может повлиять на иначе изолированные нагрузки.

## Сравни варианты

1. Сравни существующий подход с реалистичными управляемыми сервисами, самостоятельным размещением или более простыми альтернативами. Учитывай постоянную ответственность, обновления, восстановление и стоимость выхода, а не только исходный набор возможностей.
2. Определи контракт потребителя: входные данные для выделения ресурсов, разделение ответственности, модель доступа, поддерживаемые изменения и поведение при сбое. Успешная демонстрация не подтверждает наличие поддерживаемого сервиса.
3. Разбери репрезентативную нагрузку и значимые сценарии отказа по описанию или в разрешённом прототипе. Проверяй потерю мощности, отказ зависимости, взаимное влияние арендаторов и потерю административного доступа там, где они влияют на проект.
4. Опиши внедрение, миграцию и шаги отката или выхода. Выяви необратимые зависимости данных или API и то, что нужно доказать до более широкого развёртывания.
5. Зафиксируй существенные компромиссы и доказательства, которые изменили бы выбор. Не добавляй компонент только потому, что он встречается на стандартной схеме платформы.

## Результат

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

Прежде чем назвать платформу готовой к использованию, установи владельца, работоспособный доступ, проверки уровня сервиса и путь восстановления. Для задачи только на проектирование отмечай непроверенные эксплуатационные допущения, не подразумевая развёртывание или готовность. Не включай значения секретов в проектные артефакты.