Единый каталог клиентских сайтов: готовый шаблон для веб-студии

4 августа 2026 · 17 мин чтения

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

Рабочий каталог должен за несколько минут ответить:

• обслуживает ли студия этот сайт сейчас;
• кто принимает техническое и клиентское решение;
• что на сайте критично для бизнеса;
• от каких поставщиков и интеграций он зависит;
• какие проверки включены;
• где находится инструкция по восстановлению;
• кому и на каком основании выданы права;
• какие риски и исключения ещё открыты.

Это не таблица с паролями и не энциклопедия архитектуры. Это навигационная карта ответственности.

Коротко

Чтобы создать единый каталог:

1. присвойте каждому проекту неизменяемый идентификатор;
2. соберите общий реестр активных, приостановленных и завершаемых проектов;
3. назначьте владельца со стороны студии и контакт со стороны клиента;
4. зафиксируйте класс критичности и бизнес-функции;
5. перечислите основные зависимости и их владельцев;
6. свяжите карточку с мониторингом, регламентами, бэкапами и хранилищем секретов;
7. укажите дату последней проверки и событие следующего обновления;
8. регулярно сверяйте каталог с договорами, биллингом и мониторингом.

В каталоге хранится метаинформация о доступах, но не сами пароли, приватные ключи, recovery-коды или токены.

Зачем каталог нужен даже небольшой студии

Без единого реестра знания обычно разбросаны между:

• CRM;
• чатом с клиентом;
• задачами;
• личной почтой;
• панелью мониторинга;
• таблицей доменов;
• менеджером паролей;
• памятью разработчика;
• старой проектной документацией.

Каждая система может быть полезной. Проблема появляется, когда нет одной точки, откуда понятно, какие сведения являются актуальными и где искать подробности.

Типичные последствия:

• алерт приходит, но дежурный не знает границы поддержки;
• SSL контролируется, а срок самого домена — нет;
• бэкап существует, но неизвестно, кто отвечает за восстановление;
• бывший сотрудник остаётся единственным владельцем аккаунта;
• клиент считает интеграцию критической, а студия не включает её в мониторинг;
• завершённый проект остаётся в платных сервисах и хранилищах;
• общий сбой провайдера разбирается по одному сайту за раз;
• отчёт строится из разных списков с разным составом.

NIST Cybersecurity Framework относит инвентаризацию систем, программного обеспечения, сервисов и внешних услуг к управлению активами. Для веб-студии это не требование сертификации, а полезный принцип: нельзя управлять риском объекта, существование и важность которого неизвестны.

Чем каталог не является

Не хранилище паролей

В каталоге допустимо записать:

Хранилище: коллекция «Клиент Север», объект `srv-prod-main`
Владелец доступа: технический директор
Последний пересмотр: 2026-07-15

Недопустимо:

root / SuperSecret123 / приватный SSH-ключ

Секреты должны находиться в специально предназначенном защищённом хранилище с разграничением доступа и аудитом.

Не Helpdesk

Каталог хранит устойчивый контекст. Helpdesk хранит работу и историю обращений. В карточке проекта есть ссылка на очередь, но не копия каждого тикета.

Не система мониторинга

Каталог объясняет, что должно наблюдаться и кто реагирует. Система мониторинга выполняет проверки и хранит события. Между ними нужна ссылка или стабильный идентификатор.

Не подробная архитектурная документация

Карточка содержит основные зависимости и ссылки на схемы. Не переносите в одну строку все конфигурационные файлы и журналы.

Не CRM

CRM отвечает за коммерческие отношения и контактную историю. Каталог — за техническую ответственность и операционный контекст. Для небольшой студии они могут жить в одном инструменте, но поля и владельцы должны различаться.

Два уровня каталога

Практичная структура состоит из общего реестра и карточки проекта.

Уровень 1. Портфельный реестр

Одна строка на проект. Он используется для фильтрации, сверки и портфельного риска.

Минимальные поля:

Поле	Пример
project_id	WEB-0042
Проект	Интернет-магазин «Север»
Production URL	https://shop.example.ru
Статус	Активен
Класс	A
Пакет поддержки	Расширенный, 24/7 для P1
Владелец студии	Иван Петров
Резерв	Мария Орлова
Контакт клиента	Операционный директор
Стек	1С-Битрикс, PHP, MySQL
Хостинг/облако	Поставщик X
Профиль мониторинга	shop-a-v3
Следующий риск	Тест восстановления до 30.09
Последняя проверка карточки	01.08.2026
Ссылка на карточку	Внутренняя ссылка

Уровень 2. Паспорт проекта

Подробная карточка отвечает на вопросы во время приёма, релиза, инцидента, отчёта и offboarding.

Разделы карточки:

1. идентификация и статус;
2. границы ответственности;
3. бизнес-контекст и критичность;
4. владельцы и коммуникация;
5. технический контур;
6. зависимости и потоки данных;
7. мониторинг и алерты;
8. резервное копирование и восстановление;
9. доступы и секреты;
10. изменения, риски и исключения;
11. жизненный цикл проекта;
12. история проверки карточки.

Обязательные поля паспорта

1. Идентификация

Поле	Зачем
Уникальный ID	Связать разные системы без неоднозначного названия
Официальное название	Понять, какой договор и клиент относятся к проекту
Production URL	Не перепутать основной адрес с тестовым
Дополнительные домены	Увидеть редиректы, зеркала, API и служебные адреса
Статус	Отличить активный проект от приостановленного и закрываемого
Дата начала/окончания	Управлять onboarding и offboarding
Ссылка на договорённости	Быстро проверить границы услуги

Не используйте домен как единственный идентификатор: домен может измениться, а проект и его история сохраняются.

2. Границы ответственности

Запишите по каждой области:

• студия отвечает;
• клиент отвечает;
• внешний подрядчик отвечает;
• ответственность совместная;
• не входит в услугу;
• владелец пока не установлен.

Области:

• приложение и CMS;
• сервер или хостинг;
• домен и регистратор;
• DNS;
• CDN/WAF;
• корпоративная почта;
• формы и CRM;
• платёжный сервис;
• 1С и обмен;
• резервные копии;
• безопасность;
• контент;
• аналитика;
• сторонние лицензии.

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

3. Бизнес-контекст

Укажите:

• назначение сайта;
• основные аудитории;
• критические бизнес-пути;
• периоды повышенной нагрузки;
• допустимое влияние;
• согласованный класс;
• клиентские ожидания по связи;
• ограничения безопасного тестирования.

Вместо «интернет-магазин» лучше:

Критические функции:
1. Просмотр каталога и актуальных цен.
2. Добавление в корзину.
3. Оформление заказа без реального списания в тестовой проверке.
4. Передача заказа в 1С.
5. Доставка уведомления менеджеру.

Пиковый период: будни 09:00–18:00 МСК, сезонный пик в ноябре.

4. Владельцы и контакты

Нужны роли, а не только фамилии:

• владелец услуги со стороны студии;
• основной технический владелец;
• резервный инженер;
• аккаунт-менеджер;
• бизнес-владелец клиента;
• технический контакт клиента;
• контакт по безопасности;
• контакт хостинга или интегратора;
• лицо, которое может одобрить экстренное изменение.

Для каждого контакта:

• канал;
• часы доступности;
• резерв;
• условия эскалации;
• дата проверки.

Личный Telegram сотрудника не должен быть единственной аварийной точкой.

5. Технический контур

Достаточный минимум:

• CMS/фреймворк и существенная версия;
• язык и runtime;
• СУБД;
• тип размещения;
• production, staging и другие контуры;
• репозитории;
• CI/CD;
• CDN/WAF;
• очередь и фоновые задачи;
• важные модули и лицензии;
• местонахождение логов;
• схема резервного копирования;
• ссылка на подробную архитектуру.

Не копируйте значения секретов из конфигурации. Фиксируйте тип, владельца и безопасную ссылку.

6. Зависимости

Для каждой зависимости полезны:

Поле	Содержание
Сервис	DNS, почта, 1С, платёж, CRM, доставка, CDN
Поставщик	Юридическое или понятное рабочее название
Функция	Что перестанет работать при отказе
Направление	Входящий, исходящий или двусторонний поток
Критичность	Влияние на пользовательский путь
Владелец	Кто может менять и эскалировать
Наблюдаемость	Какая проверка показывает отказ
Резерв	Обходной путь или отсутствие резерва
Инструкция	Ссылка на runbook

NIST CSF рекомендует учитывать не только собственные системы, но и внешние сервисы поставщиков. Для студии особенно важны DNS, регистратор, хостинг, почта, CDN, платёжные и интеграционные платформы.

7. Мониторинг

Запишите:

• профиль мониторинга и его версию;
• обязательные проверки;
• исключения;
• частоту;
• регионы;
• окно плановых работ;
• основной и резервный каналы;
• правила подтверждения;
• связь с Helpdesk;
• последний тест алерта;
• ответственного за актуальность.

Паспорт не должен вручную дублировать состояние каждой проверки. Сохраняйте ссылку на актуальную панель и перечень ожидаемого покрытия.

8. Резервное копирование и восстановление

Минимальные поля:

• что копируется;
• где хранится;
• кто управляет;
• расписание;
• срок хранения;
• шифрование и владелец ключа;
• ожидаемые RPO/RTO;
• последняя успешная копия;
• последняя проверка восстановления;
• ссылка на пошаговую инструкцию;
• ограничения и незакрытые риски.

Поле «бэкап: есть» не доказывает восстановимость. Используйте протокол тестового восстановления.

9. Доступы

В каталоге храните:

• систему;
• владельца аккаунта;
• тип учётной записи;
• роль студии;
• наличие MFA;
• идентификатор записи в менеджере секретов;
• одобрившего доступ;
• дату выдачи и пересмотра;
• процедуру аварийного доступа;
• событие отзыва.

Не храните:

• пароль;
• TOTP seed;
• recovery-код;
• приватный ключ;
• действующий API-токен;
• cookie или сессию;
• полный конфигурационный файл с секретами.

10. Риски и исключения

Каждая запись содержит:

• описание;
• возможное влияние;
• почему не устранено сейчас;
• временную меру;
• владельца решения;
• принявшего риск со стороны клиента, если требуется;
• срок пересмотра;
• ссылку на задачу.

Пример:

Риск: регистратор не поддерживает индивидуальные роли, используется общая учётная запись.
Влияние: невозможно надёжно атрибутировать изменение домена.
Временная мера: доступ ограничен двумя сотрудниками, MFA включена, вход фиксируется.
Решение: перенос домена к регистратору с ролевым доступом.
Владелец: аккаунт-менеджер.
Пересмотр: 15.09.2026.

11. Жизненный цикл

Статус проекта должен управлять действиями.

Статус	Что означает	Обязательное действие
Кандидат	Обсуждается приём	Предварительная инвентаризация
Onboarding	Ответственность передаётся	Проверка полей, доступов и исходного состояния
Активен	Услуга оказывается	Мониторинг и регулярный review
Приостановлен	Работа временно ограничена	Зафиксировать, что продолжает действовать
Завершение	Идёт передача	Offboarding и экспорт истории
Архив	Ответственность завершена	Отзыв прав, отключение платных проверок, срок хранения

Не удаляйте историю закрытого проекта без политики. Но закройте доступы и автоматические расходы.

Готовый Markdown-шаблон паспорта

Скопируйте его в репозиторий, базу знаний или Helpdesk.

---
project_id: "WEB-0000"
project_name: ""
production_url: ""
status: "onboarding"
service_class: ""
monitoring_profile: ""
monitoring_profile_version: ""
studio_owner: ""
studio_backup_owner: ""
client_owner: ""
last_reviewed: "YYYY-MM-DD"
next_review: "YYYY-MM-DD"
---

# Паспорт проекта: [название]

## 1. Назначение и границы

- Назначение сайта:
- Договор/пакет:
- Часы поддержки:
- Входит в поддержку:
- Не входит:
- Ссылка на договорённости:

## 2. Критические функции

| Функция | Влияние отказа | Допустимый тест | Владелец |
|---|---|---|---|
| | | | |

## 3. Владельцы и коммуникация

| Роль | Основной | Резерв | Канал | Когда эскалировать |
|---|---|---|---|---|
| Студия: технический владелец | | | | |
| Студия: аккаунт | | | | |
| Клиент: бизнес-владелец | | | | |
| Клиент: технический контакт | | | | |
| Security-контакт | | | | |

## 4. Контуры и стек

- Production:
- Staging:
- CMS/фреймворк:
- Runtime и СУБД:
- Хостинг/облако:
- Репозиторий:
- CI/CD:
- Логи:
- Архитектурная схема:

## 5. Домены и инфраструктура

| Объект | Поставщик | Владелец | Срок/состояние | Мониторинг |
|---|---|---|---|---|
| Домен | | | | |
| DNS | | | | |
| SSL | | | | |
| CDN/WAF | | | | |
| Хостинг | | | | |

## 6. Зависимости

| Сервис | Функция | Влияние | Владелец | Проверка | Runbook |
|---|---|---|---|---|---|
| | | | | | |

## 7. Мониторинг и алерты

- Профиль и версия:
- Панель Pingvera:
- Обязательные проверки:
- Исключения:
- Срочный канал:
- Резервный канал:
- Helpdesk:
- Последний тест доставки:

## 8. Бэкап и восстановление

- Состав копии:
- Расписание:
- Хранилище:
- Владелец:
- RPO/RTO:
- Последний успешный бэкап:
- Последний restore test:
- Инструкция:

## 9. Доступы

> Здесь только ссылки и метаданные. Секреты хранятся отдельно.

| Система | Тип аккаунта | Роль | MFA | Ссылка на vault | Пересмотр |
|---|---|---|:---:|---|---|
| | | | | | |

## 10. Риски и исключения

| Риск/исключение | Влияние | Временная мера | Владелец | Пересмотр | Задача |
|---|---|---|---|---|---|
| | | | | | |

## 11. Изменения и окна

- Стандартное окно:
- Кто согласует экстренное изменение:
- Журнал релизов:
- Чек-лист после релиза:

## 12. Onboarding/offboarding

- Акт исходного состояния:
- Дата принятия ответственности:
- Условия передачи:
- Срок хранения истории:
- Чек-лист отзыва прав:

## История проверки карточки

| Дата | Что проверено | Изменения | Проверил |
|---|---|---|---|
| | | | |

Короткий шаблон портфельного реестра

| ID | Проект | URL | Статус | Класс | Владелец | Резерв | Профиль | Общий риск | Review |
|---|---|---|---|---|---|---|---|---|---|
| WEB-0001 | | | | | | | | | |

Для таблицы добавьте отдельные фильтруемые столбцы:

• CMS;
• хостинг;
• DNS-провайдер;
• регистратор;
• наличие формы;
• наличие 1С;
• restore test;
• MFA;
• профиль и версия;
• дата завершения договора.

Не складывайте всё в одно поле «комментарий». Неформализованный текст нельзя надёжно фильтровать.

Заполненный мини-пример

---
project_id: "WEB-0042"
project_name: "Магазин Север"
production_url: "https://shop.example.ru"
status: "active"
service_class: "A"
monitoring_profile: "shop-a"
monitoring_profile_version: "3"
studio_owner: "Иван Петров"
studio_backup_owner: "Мария Орлова"
client_owner: "Операционный директор"
last_reviewed: "2026-08-01"
next_review: "2026-09-01"
---

# Паспорт проекта: Магазин Север

## Критические функции

| Функция | Влияние отказа | Допустимый тест | Владелец |
|---|---|---|---|
| Оформление заказа | Нельзя создать заказ | Тестовый товар, без списания | Студия |
| Обмен с 1С | Не обновляются цены и заказы | Heartbeat + контроль возраста выгрузки | Совместно |
| Почта заказов | Менеджер не видит заказ | Тестовый маркер в отдельный ящик | Клиент |

## Открытый риск

| Риск | Влияние | Временная мера | Владелец | Пересмотр |
|---|---|---|---|---|
| Restore test старше шести месяцев | Не подтверждено фактическое время восстановления | Назначено тестовое развёртывание | Техлид | 2026-08-20 |

Пример не является универсальным SLA. Значения и роли устанавливаются для конкретного договора и инфраструктуры.

Где вести каталог

Электронная таблица

Подходит для быстрого старта и портфельного обзора.

Плюсы:

• знакомый интерфейс;
• фильтры;
• быстрый импорт;
• низкий порог входа.

Ограничения:

• сложнее контролировать структуру длинной карточки;
• легко случайно открыть лишний доступ;
• история изменений может быть недостаточной;
• возникает желание хранить пароли рядом.

База знаний или рабочая база

Подходит для карточек, связей и инструкций.

Проверьте:

• ролевой доступ;
• историю версий;
• экспорт;
• API;
• резервное копирование;
• возможность обязательных полей;
• offboarding пользователей.

Репозиторий Markdown/YAML

Подходит технической команде, если важны review, история и автоматические проверки.

Плюсы:

• версионирование;
• pull request;
• машинная проверка полей;
• удобная генерация сводок.

Ограничения:

• доступен не всем аккаунт-менеджерам;
• нельзя помещать секреты;
• требуется дисциплина структуры;
• интерфейс поиска и связей нужно продумать.

CMDB или service catalog

Имеет смысл при большом портфеле и сложных зависимостях. Не внедряйте тяжёлую систему до определения модели данных и процесса актуализации.

Инструмент выбирается после ответа на вопросы:

1. Кто обновляет?
2. Когда обновляет?
3. Кто проверяет?
4. Как найти расхождение?
5. Как экспортировать и восстановить каталог?

Кто отвечает за актуальность

Полезно разделить роли:

• владелец каталога — определяет структуру и контроль качества;
• владелец проекта — отвечает за фактическую карточку;
• аккаунт-менеджер — проверяет договорные и клиентские контакты;
• технический специалист — обновляет контур, зависимости и runbook;
• ответственный за доступы — сверяет права и ссылки на хранилище;
• автоматическая проверка — выявляет отсутствующие и устаревшие поля.

Ответственность «всей команды» обычно означает, что поле обновит следующий человек — то есть никто.

Когда карточка должна обновляться

Календарный review полезен, но важнее события.

Обязательные триггеры:

• новый договор или изменение пакета;
• запуск production;
• смена домена, DNS, хостинга или CDN;
• новый критический путь;
• подключение интеграции;
• изменение владельца;
• выдача или отзыв административного доступа;
• смена процедуры бэкапа;
• проверка восстановления;
• P1 или важный postmortem;
• принятие исключения;
• приостановка или завершение поддержки.

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

Как проверить качество каталога

Проверка полноты

Сопоставьте четыре списка:

1. активные договоры или биллинг;
2. проекты в каталоге;
3. сайты в мониторинге;
4. клиентские коллекции в хранилище доступов.

Расхождение — отдельная задача.

Проверка актуальности

Выберите случайные карточки и попросите резервного инженера:

• назвать границы поддержки;
• найти владельца;
• открыть runbook;
• найти историю релиза;
• определить канал клиента;
• показать, где расположен доступ, не раскрывая секрет;
• объяснить критический путь.

Если это невозможно за разумное время, карточка существует формально.

Проверка безопасности

Ищите:

• пароли и токены в открытом тексте;
• публичные ссылки;
• личные аккаунты;
• бывших сотрудников;
• общие права администратора;
• неограниченный экспорт;
• чувствительные данные без необходимости;
• отсутствие журнала изменений.

Проверка портфельной полезности

Попробуйте ответить фильтром:

• какие сайты зависят от одного DNS-провайдера;
• где не тестировали восстановление;
• у каких проектов нет резерва;
• кто использует устаревший профиль;
• какие договоры завершаются;
• где форма не проверяется до результата;
• где принято исключение без даты пересмотра.

Если каждый ответ требует ручного чтения всех карточек, структура недостаточно формальна.

Как внедрить каталог за пять рабочих дней

День 1. Определить модель

• выбрать владельца;
• утвердить обязательные поля;
• создать ID;
• определить статусы и классы;
• запретить хранение секретов.

День 2. Собрать реестр

• выгрузить договоры;
• выгрузить мониторинг;
• собрать известные проекты;
• отметить расхождения и неизвестное.

День 3. Заполнить критические проекты

• начать с класса A;
• назначить владельцев;
• заполнить функции, зависимости, восстановление и алерты;
• не ждать идеальной полноты всего портфеля.

День 4. Связать системы

• добавить ссылки на Pingvera, Helpdesk, репозиторий и vault;
• проверить права;
• создать представления для дежурного и аккаунта.

День 5. Проверить и запустить ритм

• провести тест с резервным инженером;
• исправить поля;
• назначить review;
• добавить обновление карточки в onboarding, release и offboarding.

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

Частые ошибки

Сначала выбирают инструмент

Команда внедряет CMDB, но не знает, кто владелец и какие поля обязательны. Сначала модель и события обновления.

Заполняют всё свободным текстом

Карточки красиво читаются, но нельзя найти общую зависимость. Ключевые поля должны иметь контролируемые значения.

Хранят секреты рядом

Удобство создаёт слишком большой радиус компрометации. Каталог хранит ссылку и метаданные.

Не фиксируют неизвестное

Пустая ячейка выглядит как забытая. Используйте значение «не установлено» и задачу с владельцем.

Нет истории

После инцидента невозможно понять, когда изменилась ответственность. Используйте журнал или версионирование.

Закрытые проекты не проходят offboarding

Доступы, мониторинг и расходы продолжают жить. Статус должен запускать чек-лист завершения.

Каталог дублирует всё

Любое изменение нужно внести в пять мест. Определите систему-источник для договора, секрета, события и кода, а каталог связывает их.

Как помогает Pingvera

Для каждого проекта в каталоге можно сохранить ссылку на его наблюдение в Pingvera и ожидаемый профиль:

• внешняя доступность;
• критические URL и содержимое;
• формы и фактическая доставка тестовой заявки;
• SSL и домен;
• heartbeat фоновых процессов;
• проверки CMS или сервера в пределах выбранной конфигурации;
• каналы уведомлений;
• история событий.

Каталог объясняет, почему и кем выполняется проверка. Pingvera показывает, что происходило с наблюдаемой функцией. Связка полезнее попытки превратить любой один инструмент во все системы сразу.

Соберите источник правды: создайте портфельный реестр, назначьте владельцев, а затем свяжите карточки с действующими проверками в Pingvera.

Часто задаваемые вопросы

Можно ли вести каталог в Google Sheets или Яндекс Таблицах?

Да, для старта. Ограничьте доступ, не храните секреты, используйте проверяемые значения и историю. По мере роста добавьте карточки и автоматическую сверку.

Кто должен владеть каталогом?

Один человек отвечает за модель и качество, а владельцы проектов — за факты в своих карточках. Без центрального владельца структура быстро расходится.

Как часто проверять карточки?

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

Нужно ли давать клиенту доступ?

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

Следует ли хранить IP-адреса и персональные контакты?

Только необходимые для работы сведения, с подходящим доступом и сроком хранения. Конкретные требования к персональным данным и договору определяются отдельно с профильными специалистами.

Что делать, если владелец зависимости неизвестен?

Так и записать: «не установлен», указать влияние и создать задачу с владельцем поиска. Не подменять факт предположением.

Нужно ли автоматически синхронизировать каталог?

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

Главное

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

Хороший каталог:

• не хранит секреты;
• имеет владельца;
• обновляется по событиям;
• допускает фильтрацию и сверку;
• показывает неизвестное;
• поддерживает весь жизненный цикл проекта.

Источники и дополнительное чтение

• NIST Cybersecurity Framework 2.0
• NIST CSF 2.0: Implementation Examples
• OWASP: Secrets Management Cheat Sheet
• Google SRE: Monitoring Distributed Systems
• Pingvera: как принять сайт на техническую поддержку
• Pingvera: карта критических бизнес-путей
• Pingvera: поддержка 10, 50 и 100 сайтов

Следующий материал курса: «Матрица безопасных доступов: кому и какие права выдавать в веб-студии».

Читайте также: Blameless postmortem для веб-студии: шаблон · SLA технической поддержки сайта: шаблон студии · Матрица доступов веб-студии: готовый шаблон · Юнит-экономика интернет-магазина: шаблон расчёта · Бесплатно проверить сайт.