Поддержка через почту работает, если заранее заданы адреса, правила маршрутизации, ответственные, статусы, сроки реакции и способ контроля обращений. Без этих правил почта быстро превращается в неуправляемый поток.

Короткий ответ

Рассматриваем, как обработка почты становится основой бизнес-процессов поддержки клиентов. Алиасы и фильтры — первый шаг к управляемым процессам и системности.

Когда применять

Поддержка клиентов почти всегда начинается с простого обработка электронной почты. Адрес вида support@ знаком каждому, и долгое время он кажется удобным решением. Но по мере роста компании такой ящик превращается в источник хаоса: письма теряются, запросы остаются без ответа, руководители не видят реальной картины загрузки.В этой статье мы рассмотрим, как электронная почта может быть не только каналом связи, но и частью бизнес-процесса поддержки. Мы покажем, какие простые шаги помогают превратить хаотичный поток писем в управляемый процесс, и почему именно почта задаёт основу системности в работе поддержки клиентов.

Основная идея

На схеме показан путь письма: входящий адрес, классификация обращения, назначение ответственного и фиксация статуса.<img src="https://files.robotbull.com/robotbull.strapi/support_process_68e055ee75.png" alt="Схема обработки обращения через почту" width="1000">

Схема обработки обращения

Для рабочей поддержки одного адреса обычно недостаточно. Сначала нужно разделить входящие потоки и сделать так, чтобы по письму было понятно, к какому направлению оно относится.<ul><li>Алиасы. Вместо одного ящика можно использовать несколько адресов: <code>sales@</code> для коммерческих запросов, <code>support@</code> для общих обращений, <code>product-a@</code> для конкретного продукта или проекта. Алиас может вести в общий ящик, но сохраняет признак канала.</li><li>Фильтры и папки. Письма на <code>product-a@</code> можно направлять в папку <code>INBOX/PRODUCT-A</code>, а письма с темой про счет или <code>invoice</code> — в <code>INBOX/FINANCE</code>. Так команда быстрее видит нужные обращения, а руководитель понимает нагрузку по направлениям.</li><li>Ответственные. Для каждого канала или папки нужно назначить владельца обработки и правило замещения, иначе письма будут распределены технически, но не управленчески.</li></ul>

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

Системность часто воспринимается как что-то сложное: регламенты, метрики, внедрение платформ. На практике всё начинается с простых шагов.

Почему системность процессов начинается с почты

<ul><li>Прозрачность. Видно, сколько обращений поступает, по каким направлениям и где скапливаются нерешенные письма.</li><li>Ответственность. Команда понимает, кто отвечает за финансы, продуктовую поддержку, коммерческие вопросы и общие обращения.</li><li>Управляемость. Алиасы, фильтры, папки, статусы и правила обработки зафиксированы в документации, поэтому процесс не зависит от одного сотрудника.</li><li>Готовность к автоматизации. Категории обращений, ответственные и правила реакции уже описаны, поэтому переход к Service Desk не начинается с хаотичного ящика.</li></ul>

Что проверить в процессе

Важно понимать: почта сама по себе не решает всех задач.<ul><li>Нет SLA. Нельзя задать время реакции и контролировать его выполнение.</li><li>Нет аналитики. Сложно измерять среднее время ответа или процент закрытых обращений.</li><li>Нет автоматической маршрутизации. Сложные запросы нельзя распределить по правилам приоритета или компетенции.</li></ul>Это означает, что почта подходит как стартовая точка, но со временем компания неизбежно сталкивается с её ограничениями.

Ограничения подхода «только почта»

Почта задаёт фундамент. Дальше компании идут по пути усложнения:<ol><li>Структурированная почта. Алиасы и фильтры создают первичный порядок.</li><li>Система поддержки (Service Desk). Письма начинают автоматически превращаться в заявки, появляется SLA, аналитика и контроль.</li><li>Автоматизация бизнес-процессов. Обращения интегрируются с CRM, ERP, BI-системами. Поддержка становится частью общей цифровой архитектуры.</li></ol>Таким образом, обработка почты – это первый уровень зрелости бизнес-процессов поддержки, и именно от её организации зависит, насколько легко компания перейдёт к следующему этапу.Организация службы поддержки часто кажется сложной задачей. Но системность рождается с простого шага: упорядоченной работы почты. Алиасы и фильтры превращают хаотичный поток писем в управляемый бизнес-процесс, дают прозрачность и ответственность.Почта не заменяет системы поддержки, но без её организации переход к автоматизации будет хаотичным и рискованным.

Связь с автоматизацией бизнес-процессов

Почтовые правила обычно становятся первым уровнем зрелости: дальше обращения можно переводить в Service Desk, связывать с SLA, аналитикой и автоматизацией бизнес-процессов.<img src="https://files.robotbull.com/robotbull.strapi/support_stages_f66a0f7479.png" alt="Этапы развития поддержки от почты к автоматизации" width="1000">

Этапы развития поддержки

<ul><li>Каждое обращение фиксируется. Понятно, куда пишет пользователь, кто отвечает и в каком статусе находится запрос.</li><li>Появляются правила обработки. Можно задать сроки реакции, маршрутизацию, приоритеты и основания для эскалации.</li><li>Переход к Service Desk становится проще. Почтовые правила, категории обращений и ответственные уже описаны, поэтому автоматизация не начинается с хаоса.</li></ul>

Результат на выходе

Каждое обращение фиксируется.
См. также: <a href="/handbook/soprovozhdenie-i-razvitie/ekspluatacionnaya-dokumentaciya-na-po">Эксплуатационная документация: что должно остаться после запуска</a>, <a href="/handbook/soprovozhdenie-i-razvitie/hranenie-i-peredacha-ishodnogo-koda">Хранение и передача исходного кода</a>, <a href="/handbook/soprovozhdenie-i-razvitie/peredacha-proekta-kod-dostupy-changelog-instruktsii">Передача ИТ-проекта в поддержку: что передать и как проверить</a>.

Что дальше

Рассматриваем, как обработка почты становится основой бизнес-процессов поддержки клиентов. Алиасы и фильтры — первый шаг к управляемым процессам и системности.

Поддержка через почту

Сопровождение и развитие

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

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

<h3>Зачем управлять хранением исходного кода</h3>Система хранения исходного кода — это не просто Git-репозиторий, а управляемый контур разработки: Git-сервис, политики доступа, резервное копирование, артефакты сборки и интеграция с CI/CD. Такой подход снижает риск потери кода и упрощает контроль версий.В статье — основные роли, структура репозиториев, порядок передачи кода и принцип, по которому прозрачность проекта можно обеспечить без постоянного прямого доступа заказчика к рабочему Git.
<h3>Почему подход к хранению кода важен</h3><ul><li>Исходный код — стратегический актив проекта.</li><li>Его утрата или несогласованные изменения могут привести к потере управляемости продуктом.</li><li>Управляемое хранение снижает технические и юридические риски.</li><li>Отстроенные процессы хранения формируют зрелую инфраструктуру разработки и доверие со стороны заказчика. </li><li>Единая система управления исходным кодом помогает снизить технический долг и облегчает передачу между подрядчиками.</li></ul>
<h3>Почему доступ к Git не всегда обязателен для заказчика</h3><ul><li>Git — инструмент внутренней разработки, а не единственный способ управлять результатом проекта.</li><li>Контроль и прозрачность можно обеспечить через версионирование, сборку, changelog, документацию и формализованную передачу артефактов.</li><li>Заказчик получает то, что нужно для проверки и аудита результата: сборочные артефакты, отчётную документацию и акт передачи исходного кода.</li><li>Такой подход снижает риск случайных изменений в рабочем контуре и делает поставку воспроизводимой даже при смене подрядчика.</li></ul>

Зачем управлять исходным кодом

Контур хранения исходного кода — это не только репозиторий. Для управляемого проекта нужно проверить несколько связанных элементов.<ul><li>Git-сервис. GitLab, GitHub, Bitbucket или другой сервер, где хранится актуальная история изменений.</li><li>Роли и права. Кто может читать код, создавать ветки, принимать merge request, выпускать релизы и менять настройки проекта.</li><li>Ветки и окружения. Как связаны <code>main</code>, <code>develop</code>, feature-ветки, release/hotfix-ветки и окружения <code>dev</code>, <code>stage</code>, <code>prod</code>.</li><li>Артефакты сборки. Где лежат Docker-образы, пакеты, библиотеки и другие результаты сборки: например Docker Registry или Nexus.</li><li>Резервное копирование. Как восстанавливаются репозитории, настройки, секреты, артефакты и документация.</li><li>Передача результата. Как фиксируются архив исходного кода, changelog, инструкция запуска, документация и акт передачи.</li></ul>Такой контур особенно важен для команд от нескольких человек, проектов с несколькими окружениями, требований к аудиту или ситуации, когда систему может принять другая команда.

Что входит в контур хранения кода

<h3>Как устроена система хранения исходного кода и доступов</h3>Внутренняя архитектура системы хранения исходного кода построена на best practices Git и принципах DevOps — с чётким разграничением ролей, веток и окружений.Ветки и окружения<ul><li>main (master) — стабильная протестированная версия продукта.</li><li>develop (dev) — активная зона интеграции новых функций.</li><li>feature/* — изолированная разработка отдельных задач.</li><li>release/* и hotfix/* — версии для подготовки релизов и исправления инцидентов.</li></ul>Такая структура помогает отслеживать изменения, формировать тестовые окружения и сохранять предсказуемость релизов.Документация и воспроизводимостьУправляемость разработки невозможна без прозрачной документации и воспроизводимых версий кода. Каждая поставка сопровождается чётко зафиксированными изменениями, описанием состава и формализованной передачей результатов.Документация встроена в процесс разработки: она обновляется вместе с кодом и остаётся актуальной на каждом этапе. Такой подход делает систему прозрачной и снижает зависимость от конкретных людей или команд.При передаче результатов заказчик получает формализованный комплект — архив исходного кода, документацию и акт приёма-передачи. Эти материалы обеспечивают возможность аудита и подтверждают юридическую определённость владения результатом.Подробные технические аспекты — структура тегов, changelog и интеграция документации в CI/CD — представлены в whitepaper «DevOps-архитектура хранения и передачи исходного кода».Контроль доступа и безопасностьУправление доступом к исходному коду — ключевой элемент устойчивой DevOps-архитектуры. Все операции с кодом происходят в контролируемой среде с разграничением ролей, журналированием действий и защитой конфиденциальных данных.Безопасность обеспечивается не отдельными инструментами, а системой процессов: каждая ветка, сборка и поставка проходят проверку и фиксируются в истории версий.Такой подход гарантирует прозрачность и воспроизводимость, снижает риски человеческих ошибок и обеспечивает устойчивость разработки даже при смене команды или подрядчика.Подробные технические механизмы — роли, политики доступа и работа с секретами — описаны в whitepaper «DevOps-архитектура хранения и передачи исходного кода».

Как устроить хранение и доступы

Схема показывает полный путь исходного кода: разработка, контроль версий, сборка, передача артефактов и развёртывание в инфраструктуре заказчика.<img src="https://files.robotbull.com/robotbull.strapi/sources_development_customer_c12475c38d.png" alt="Архитектура процессов хранения, сборки и передачи исходного кода" width="1000">Схема архитектуры хранения, сборки и передачи исходного кода.

Схема хранения, сборки и передачи кода

<h3>Что делает эту схему полезной для бизнеса</h3>Архитектура отражает не просто технический процесс, а управляемую систему взаимодействия между исполнителем и заказчиком. Она показывает, где проходят границы ответственности и как фиксируются результаты на каждом этапе.Такой подход особенно важен при передаче прав, подготовке к аудиту и переходе к устойчивой DevOps-инфраструктуре, когда требуется прозрачность и воспроизводимость всех стадий — от разработки до эксплуатации.Схема отражает три уровня: производственную среду исполнителя, этап поставки и эксплуатацию у заказчика.
<h3>Сценарии: когда особенно важно правильное хранение кода</h3>Архитектура управления исходным кодом особенно значима в ситуациях, где от прозрачности и воспроизводимости зависит устойчивость проекта.<h3>Типовые сценарии</h3><ul><li>Смена подрядчика. Новый исполнитель получает код, документацию и историю изменений без восстановления проекта по локальным копиям.</li><li>Рост команды. Новые участники быстрее подключаются к работе, потому что ветки, окружения, права и правила сборки уже описаны.</li><li>Аудит или сертификация. Можно документально подтвердить, где хранится код, кто менял систему и какая версия была передана.</li><li>Инцидент или баг. Команда может быстро найти изменение, откатиться к зафиксированной версии и восстановить сборку.</li></ul>

Когда это особенно важно

<ul><li>Код находится в управляемом репозитории. Понятно, где актуальная версия, кто имеет доступ и как восстановить историю изменений.</li><li>Передача проекта не зависит от одного человека. Репозитории, права, артефакты, инструкции и связанные окружения фиксируются в проверяемом процессе.</li><li>Дальнейшая поддержка становится предсказуемее. Команда может безопасно принимать изменения, разбирать инциденты и подключать новых участников.</li></ul>

Если нужно привести хранение исходного кода, доступы и передачу проекта к управляемой схеме, начните с инвентаризации репозиториев, ролей, прав, резервного копирования, CI/CD, секретов, инструкций запуска и состава передаваемых артефактов.
См. также: <a href="/handbook/soprovozhdenie-i-razvitie/peredacha-proekta-kod-dostupy-changelog-instruktsii">Передача ИТ-проекта в поддержку: что передать и как проверить</a>, <a href="/handbook/soprovozhdenie-i-razvitie/ekspluatacionnaya-dokumentaciya-na-po">Эксплуатационная документация: что должно остаться после запуска</a>, <a href="/handbook/soprovozhdenie-i-razvitie/podderzhka-cherez-pochtu">Поддержка через почту</a>.

Как организовать хранение исходного кода: Git-репозиторий, роли, доступы, резервные копии, CI/CD и передача проекта заказчику.

Хранение и передача исходного кода

Эксплуатационная документация на ПО - это комплект материалов, который остается у заказчика, службы поддержки и администраторов после запуска системы. Он нужен не для описания того, как систему разрабатывали, а для повседневной работы: как пользоваться функциями, как администрировать сервис, как обновлять версию, как восстановиться после сбоя и кто отвечает за регулярные операции.В минимальном виде комплект включает руководство пользователя, руководство администратора, инструкции по нештатным ситуациям, регламент обновлений, описание мониторинга, список доступов и ведомость эксплуатационных документов. Для формальных проектов этот состав связывают с ГОСТ 19, ГОСТ 34, программной документацией и документами приемки. Для практического ИТ-проекта важнее проверить, сможет ли новая команда сопровождать систему без устных пояснений разработчиков.

<ul><li>перед запуском промышленной версии или передачей системы в поддержку;</li><li>при смене подрядчика, команды разработки, администратора или владельца сервиса;</li><li>если система зависит от интеграций, расписаний, сертификатов, очередей, фоновых задач и внешних сервисов;</li><li>когда есть SLA, регламент инцидентов, дежурства или обязательные окна обновлений;</li><li>перед приемкой, аудитом, вводом в опытную эксплуатацию или промышленную эксплуатацию;</li><li>когда пользователи уже работают в системе, но знания о поддержке остаются в чатах и личных заметках.</li></ul>Если проект небольшой, эксплуатационная документация не обязана превращаться в набор тяжелых томов. Часть сведений может жить в README, базе знаний, runbook, карточках доступа или регламенте поддержки. Но у каждого критичного действия должен быть понятный владелец, место хранения и способ проверки.

Состав эксплуатационной документации зависит от масштаба системы, требований заказчика и уровня формальности. Ниже - рабочий набор для ИТ/ПО-проекта. Он сохраняет смысл старого материала про эксплуатационный комплект, но раскладывает документы по практической роли после запуска.<table><thead><tr><th>Часть комплекта</th><th>Что передать</th><th>Как проверить</th></tr></thead><tbody><tr><td>Ведомость эксплуатационных документов</td><td><ul><li>перечень документов;</li><li>версии и даты обновления;</li><li>статус актуальности;</li><li>владельцев документов;</li><li>ссылки на место хранения.</li></ul></td><td><ul><li>понятно, какие документы входят в комплект;</li><li>нет потерянных приложений и устаревших копий;</li><li>можно быстро показать состав на приемке или аудите.</li></ul></td></tr><tr><td>Руководство пользователя или оператора</td><td><ul><li>основные сценарии работы;</li><li>ограничения и правила ввода данных;</li><li>типовые ошибки;</li><li>порядок обращения в поддержку;</li><li>критичные действия, которые нельзя выполнять без согласования.</li></ul></td><td><ul><li>пользователь выполняет ключевой сценарий без помощи разработчика;</li><li>первая линия поддержки понимает, какие вопросы решать самостоятельно;</li><li>инструкция не противоречит текущему интерфейсу.</li></ul></td></tr><tr><td>Руководство администратора</td><td><ul><li>настройки системы;</li><li>роли и права;</li><li>переменные окружения;</li><li>порядок запуска и остановки;</li><li>резервное копирование и восстановление;</li><li>операции обслуживания.</li></ul></td><td><ul><li>администратор может поднять или проверить систему по инструкции;</li><li>критичные операции не завязаны на одного разработчика;</li><li>есть понятные границы, что менять вручную нельзя.</li></ul></td></tr><tr><td>Инструкция по нештатным ситуациям</td><td><ul><li>сценарии сбоев;</li><li>признаки деградации;</li><li>порядок диагностики;</li><li>контакты эскалации;</li><li>действия при отказе интеграций;</li><li>план отката или восстановления.</li></ul></td><td><ul><li>дежурная команда понимает первые действия при инциденте;</li><li>описаны условия, когда нужно эскалировать проблему;</li><li>после сбоя можно восстановить сервис до согласованного состояния.</li></ul></td></tr><tr><td>Требования к квалификации персонала</td><td><ul><li>какие роли работают с системой;</li><li>какие навыки нужны пользователям, администраторам и поддержке;</li><li>кто согласует изменения;</li><li>какое обучение требуется перед передачей.</li></ul></td><td><ul><li>не возникает ситуации, когда система формально передана, но ее некому сопровождать;</li><li>ответственность за эксплуатационные действия распределена между ролями;</li><li>ИБ и владелец сервиса понимают, кому нужны доступы.</li></ul></td></tr><tr><td>Регламент обновлений и changelog</td><td><ul><li>порядок выпуска версии;</li><li>окна работ;</li><li>миграции данных;</li><li>обратимость изменений;</li><li>известные ограничения;</li><li>уведомления пользователей и поддержки.</li></ul></td><td><ul><li>понятно, что изменилось в версии;</li><li>известно, какие действия нужны до и после релиза;</li><li>есть критерии smoke-проверки и отката.</li></ul></td></tr><tr><td>Инструкции по инфраструктуре и аппаратным средствам</td><td><ul><li>серверы, хранилища, внешнее оборудование;</li><li>ограничения поставщиков;</li><li>версии платформ;</li><li>ссылки на vendor-документацию;</li><li>особые условия эксплуатации.</li></ul></td><td><ul><li>поддержка знает, где заканчивается зона ПО и начинается зона инфраструктуры;</li><li>нет скрытой зависимости от личных заметок инженера;</li><li>понятно, какие инструкции можно заменить ссылками на документацию производителя.</li></ul></td></tr></tbody></table>

Что входит в эксплуатационную документацию

В практическом проекте удобнее думать не только документами, но и проверяемыми частями передачи. Такой разрез помогает увидеть пробелы: например, пользовательская инструкция есть, а правил восстановления, мониторинга и обновления нет.<table><thead><tr><th>Часть</th><th>Что передать</th><th>Как проверить</th></tr></thead><tbody><tr><td>Код и сборка</td><td><ul><li>репозитории;</li><li>ветки, теги и commit поставки;</li><li>правила ветвления;</li><li>README;</li><li>зависимости и миграции;</li><li>CI/CD или инструкции ручной сборки.</li></ul></td><td><ul><li>новая команда может собрать проект по инструкции;</li><li>стенд поднимается и проходит smoke-проверку;</li><li>известно, какая версия соответствует поставке.</li></ul></td></tr><tr><td>Доступы</td><td><ul><li>права и группы;</li><li>сервисные учетные записи;</li><li>секреты и сертификаты;</li><li>владельцы доступов;</li><li>сроки ротации;</li><li>порядок выдачи и отзыва прав.</li></ul></td><td><ul><li>нет личных доступов как единственной точки управления;</li><li>секреты не передаются в переписке открытым текстом;</li><li>владелец сервиса понимает, кто имеет доступ к production.</li></ul></td></tr><tr><td>Запуск и эксплуатация</td><td><ul><li>переменные окружения;</li><li>конфигурационные файлы;</li><li>фоновые задачи;</li><li>расписания;</li><li>мониторинг;</li><li>логи и алерты;</li><li>резервное копирование и восстановление.</li></ul></td><td><ul><li>поддержка знает, что делать при сбое;</li><li>алерты ведут к понятному действию;</li><li>после восстановления можно проверить бизнес-сценарии.</li></ul></td></tr><tr><td>Интеграции</td><td><ul><li>контракты API;</li><li>форматы данных;</li><li>очереди и события;</li><li>правила повторов;</li><li>таймауты;</li><li>контакты внешних владельцев;</li><li>регламент отключений.</li></ul></td><td><ul><li>при отказе внешней системы понятно, что проверять первым;</li><li>описаны ошибки, которые можно повторить или компенсировать;</li><li>ответственность сторон не остается устной договоренностью.</li></ul></td></tr><tr><td>Changelog и ограничения</td><td><ul><li>версии;</li><li>изменения поведения;</li><li>миграции;</li><li>известные ограничения;</li><li>совместимость;</li><li>условия отката.</li></ul></td><td><ul><li>поддержка понимает, что изменилось после релиза;</li><li>можно объяснить пользователю новое ограничение;</li><li>есть связь между версией, документацией и инцидентами.</li></ul></td></tr></tbody></table>

Состав эксплуатационного комплекта

ГОСТ 19 и ГОСТ 34 полезны как язык для формального состава документов, но их не стоит копировать без привязки к жизненному циклу проекта. В ГОСТ 19 встречаются руководство пользователя, руководство системного программиста, описание применения, формуляр и ведомости. В ГОСТ 34 эксплуатационные материалы связаны с вводом системы в действие, приемкой, испытаниями и сопровождением.Для коммерческого ИТ-проекта это означает простое правило: если документ помогает использовать, администрировать, обновлять, восстанавливать или проверять систему после запуска, он относится к эксплуатационному комплекту. Если документ объясняет, почему система была спроектирована именно так, он скорее относится к проектной или архитектурной документации. Если документ фиксирует версию, состав поставки и историю изменений, он должен быть связан с эксплуатацией, но не подменять инструкции.Формальная ведомость эксплуатационных документов особенно полезна, когда есть приемка, аудит или несколько подрядчиков. Она не делает комплект качественным сама по себе, но показывает, что именно передано, где лежит актуальная версия и кто отвечает за обновление.

ГОСТ 19, ГОСТ 34 и практический комплект

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

Что не входит в эксплуатационную документацию

<ul><li>Есть рабочие инструкции запуска, остановки, обновления и восстановления.</li><li>Доступы, секреты, сертификаты и сервисные учетные записи описаны через управляемый процесс, а не через личные аккаунты.</li><li>Мониторинг, логи и алерты связаны с действиями поддержки.</li><li>Интеграции имеют контакты владельцев, правила повторов, форматы ошибок и порядок временного отключения.</li><li>Changelog объясняет изменения версии, миграции, известные ограничения и влияние на поддержку.</li><li>Документы имеют владельцев, место хранения, дату актуализации и понятный статус.</li><li>Пользовательская инструкция соответствует текущему интерфейсу и реальным ролям.</li><li>Новая команда может выполнить smoke-проверку без участия разработчиков, которые сдавали проект.</li></ul>

Что проверить перед передачей в поддержку

Для небольшого ИТ-проекта минимальный комплект может быть компактным. Главное - не формат, а проверяемость. Обычно достаточно пяти связанных частей:<ol><li>README или runbook для запуска: как поднять окружение, какие переменные нужны, какие миграции выполнить, как проверить работоспособность.</li><li>Краткая пользовательская инструкция: ключевые сценарии, роли, ограничения, типовые ошибки и путь обращения в поддержку.</li><li>Административная инструкция: доступы, настройки, мониторинг, резервное копирование, восстановление и регулярные операции.</li><li>Инструкция при сбое: симптомы, первые проверки, эскалация, rollback, контакты ответственных и критерии восстановления.</li><li>Ведомость комплекта: ссылки на все документы, версии, владельцы, дата актуализации и статус.</li></ol>Если проект растет, этот минимум дополняют регламентом релизов, отдельными инструкциями по интеграциям, матрицей ролей, описанием контуров, политикой резервного копирования и формальными документами по ГОСТ.

Пример минимального эксплуатационного комплекта

<ul><li>Оставить только пользовательскую инструкцию и назвать ее эксплуатационной документацией.</li><li>Не описать доступы, секреты, сертификаты и сроки их обновления.</li><li>Передать систему без процедуры восстановления и без понятного rollback.</li><li>Смешать проектные решения, инструкции, changelog и протоколы встреч в один файл.</li><li>Не указать владельцев документов и место хранения актуальной версии.</li><li>Считать, что код в репозитории заменяет эксплуатационный комплект.</li><li>Оставить инструкции в формате «спросить у разработчика», когда разработчик уже уходит с проекта.</li></ul>Главный риск - формально закрыть приемку, но оставить поддержку без работающего способа обслуживать систему. Тогда каждый инцидент превращается в расследование, а стоимость сопровождения растет быстрее, чем ожидалось.

Ошибки и риски

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

Если комплект нужно собрать с нуля, начните с общего состава документации на ПО .
См. также: <a href="/handbook/proektirovanie-i-otsenka/dokumentatsiya-po-dlya-it-proekta">общего состава документации на ПО</a>, <a href="/handbook/proektirovanie-i-otsenka/proverka-komplektnosti-dokumentatsii-pered-priemkoy">комплектность документации</a>, <a href="/handbook/soprovozhdenie-i-razvitie/peredacha-proekta-kod-dostupy-changelog-instruktsii">про код, доступы, changelog и инструкции</a>, <a href="/handbook/proektirovanie-i-otsenka/dokumentatsiya-dlya-integratsionnogo-proekta">документацию интеграционного проекта</a>, <a href="/handbook/soprovozhdenie-i-razvitie/hranenie-i-peredacha-ishodnogo-koda">Хранение и передача исходного кода</a>.

Что входит в эксплуатационную документацию на ПО: инструкции, регламенты, доступы, восстановление, ГОСТ 19/34 и комплект для поддержки после запуска.

Эксплуатационная документация

Эксплуатационная документация: что должно остаться после запуска

Передача ИТ-проекта в поддержку - это управляемый handover, после которого новая команда может собрать, запустить, проверить, сопровождать и развивать систему без постоянного участия исходных разработчиков. Передать нужно не только код, но и версию поставки, доступы, инструкции сборки и запуска, changelog, эксплуатационную документацию, контакты владельцев, известные ограничения и список открытых вопросов.Хорошая передача проекта закрывает три слоя одновременно: юридический состав результата, техническую готовность к сопровождению и передачу знаний. Если один слой пропущен, проект формально может быть сдан, но поддержка будет зависеть от личных аккаунтов, устных пояснений, старых чатов и бывших участников команды.

<table><thead><tr><th>Часть</th><th>Что передать</th><th>Как проверить</th></tr></thead><tbody><tr><td>Код</td><td><ul><li>репозитории;</li><li>ветки;</li><li>теги;</li><li>commit поставки;</li><li>правила ветвления;</li><li>лицензии и сторонние зависимости.</li></ul></td><td><ul><li>новая команда видит историю изменений;</li><li>понятно, какая версия передана;</li><li>код не лежит единственной копией в архиве.</li></ul></td></tr><tr><td>Доступы</td><td><ul><li>права и группы;</li><li>сервисные учетные записи;</li><li>секреты;</li><li>сертификаты;</li><li>владельцы;</li><li>порядок выдачи и отзыва прав.</li></ul></td><td><ul><li>нет личных доступов как единственной точки управления;</li><li>секреты не переданы в открытой переписке;</li><li>production-доступы имеют владельца.</li></ul></td></tr><tr><td>Сборка и запуск</td><td><ul><li>README;</li><li>переменные окружения;</li><li>CI/CD;</li><li>зависимости;</li><li>миграции;</li><li>инструкция smoke-проверки.</li></ul></td><td><ul><li>стенд поднимается на чистом окружении;</li><li>проверку выполняет не автор проекта;</li><li>ошибки запуска исправлены в документации.</li></ul></td></tr><tr><td>Changelog и release notes</td><td><ul><li>версии;</li><li>изменения;</li><li>миграции;</li><li>известные ограничения;</li><li>откаты;</li><li>влияние на пользователей и поддержку.</li></ul></td><td><ul><li>понятно, что изменилось;</li><li>видно, какие действия нужны при обновлении;</li><li>ограничения не обнаруживаются только после инцидента.</li></ul></td></tr><tr><td>Эксплуатация</td><td><ul><li>мониторинг;</li><li>обновления;</li><li>восстановление;</li><li>инциденты;</li><li>контакты эскалации;</li><li>регламент поддержки.</li></ul></td><td><ul><li>поддержка знает, что делать при сбое;</li><li>есть связь с эксплуатационной документацией;</li><li>понятно, кто владеет регулярными операциями.</li></ul></td></tr></tbody></table>

Что входит в пакет передачи

Передача становится управляемой, когда понятно, кто принимает каждый слой результата. Один общий созвон не заменяет приемку доступа, кода, эксплуатационных инструкций и знаний.<table><thead><tr><th>Роль</th><th>Что принимает</th><th>Признак готовности</th></tr></thead><tbody><tr><td>Заказчик или владелец продукта</td><td><ul><li>состав поставки;</li><li>границы результата;</li><li>известные ограничения;</li><li>открытые вопросы;</li><li>связь с актом или этапом.</li></ul></td><td>Понятно, что принято сейчас, что переносится дальше и кто владелец каждого остатка.</td></tr><tr><td>Поддержка</td><td><ul><li>инструкции инцидентов;</li><li>мониторинг;</li><li>контакты эскалации;</li><li>регулярные операции;</li><li>частые ошибки.</li></ul></td><td>Команда может выполнить первые действия при сбое без обращения к разработчику.</td></tr><tr><td>DevOps или администратор</td><td><ul><li>контуры;</li><li>секреты;</li><li>CI/CD;</li><li>резервное копирование;</li><li>миграции;</li><li>права доступа.</li></ul></td><td>Стенд поднимается, обновляется и восстанавливается по инструкции.</td></tr><tr><td>Новая команда разработки</td><td><ul><li>репозитории;</li><li>архитектурные решения;</li><li>зависимости;</li><li>технический долг;</li><li>правила ветвления.</li></ul></td><td>Команда может внести небольшое изменение и пройти сборку/проверку.</td></tr><tr><td>ИБ или владелец доступов</td><td><ul><li>роли;</li><li>сервисные учетные записи;</li><li>секреты;</li><li>журналы доступа;</li><li>порядок ротации.</li></ul></td><td>Нет неуправляемых личных доступов и неизвестных владельцев прав.</td></tr></tbody></table>

Кто что принимает при передаче проекта

Юридическая передача фиксирует права и состав результата, но сама по себе не доказывает, что систему можно сопровождать. Техническая готовность показывает, что переданные материалы действительно работают и понятны новой команде.<table><thead><tr><th>Область</th><th>Юридическая передача</th><th>Техническая готовность</th></tr></thead><tbody><tr><td>Исходный код</td><td><ul><li>условия передачи;</li><li>состав результата;</li><li>права использования;</li><li>ограничения договора.</li></ul></td><td><ul><li>репозиторий доступен;</li><li>есть история и теги;</li><li>зафиксирован commit поставки;</li><li>известны зависимости.</li></ul></td></tr><tr><td>Сборка</td><td><ul><li>указано, что передаются материалы для сборки и запуска;</li><li>описан состав приложений.</li></ul></td><td><ul><li>инструкция проверена на чистом окружении;</li><li>миграции описаны;</li><li>smoke-проверка проходит.</li></ul></td></tr><tr><td>Доступы</td><td><ul><li>определено, кому передаются права управления;</li><li>есть ответственный за приемку.</li></ul></td><td><ul><li>секреты ротируются;</li><li>личные аккаунты не являются единственным доступом;</li><li>есть владелец production.</li></ul></td></tr><tr><td>Эксплуатация</td><td><ul><li>передаваемые документы перечислены в составе результата;</li><li>акт не скрывает ограничения.</li></ul></td><td><ul><li>есть инструкции мониторинга, обновления и восстановления;</li><li>поддержка знает действия при инциденте.</li></ul></td></tr><tr><td>Знания</td><td><ul><li>может быть указан порядок консультаций или сопровождения после передачи.</li></ul></td><td><ul><li>проведен knowledge transfer;</li><li>записаны решения;</li><li>открытые вопросы имеют владельцев.</li></ul></td></tr></tbody></table>

Юридическая передача и техническая готовность

Knowledge transfer нужен, когда передать нужно не только артефакты, но и рабочий контекст. Хорошая сессия передачи объясняет архитектурные решения, критичные ограничения, нестандартные места, частые инциденты, процесс релизов и зоны, где документация еще неполная. Но такая встреча не заменяет документы: после нее должны остаться записи, ссылки, владельцы и список открытых вопросов.<ol><li>Сначала пройти карту системы: компоненты, данные, интеграции, внешние зависимости.</li><li>Показать сборку и запуск на чистом окружении.</li><li>Разобрать типовой релиз: версия, миграции, smoke-проверка, rollback.</li><li>Показать мониторинг, логи, алерты и порядок реакции на инцидент.</li><li>Зафиксировать вопросы, которые нужно закрыть после передачи.</li></ol>

Knowledge transfer

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

Переход от подрядчика к внутренней команде

Передача исходного кода заказчику должна быть проверяемой. Недостаточно получить архив и считать задачу закрытой: нужно понимать, соответствует ли код переданной версии, есть ли инструкции сборки, какие библиотеки и лицензии используются, где хранятся конфигурации и можно ли развернуть систему без доступа к личному компьютеру разработчика.<ul><li>сверить commit или tag с версией, которая передается по акту;</li><li>проверить, что репозиторий содержит инструкции, миграции и конфигурационные шаблоны;</li><li>отдельно зафиксировать сторонние компоненты, лицензии и ограничения использования;</li><li>подтвердить, что сборка проходит в целевом окружении, а не только на машине автора.</li></ul>

Проверка передачи исходного кода

Самая полезная проверка передачи - попросить человека, который не писал проект, поднять стенд по инструкции. Если он сразу упирается в неизвестную переменную окружения, отсутствующий секрет, локальную зависимость или неописанную миграцию, handover еще не завершен. Проверку лучше делать до финального созвона, чтобы исправить инструкцию, а не объяснять все голосом.<ul><li>зафиксируйте целевую версию runtime, базы данных, брокера, внешних сервисов и системных пакетов;</li><li>проверьте, что секреты и сертификаты выдаются через управляемый процесс;</li><li>опишите порядок миграций и seed-данных, если без них приложение не стартует;</li><li>добавьте smoke-сценарий: какие страницы, API или фоновые задачи должны подтвердить успешный запуск.</li></ul>

Как проверить сборку на чистом окружении

<ol><li>Зафиксировать состав поставки и версию, которая передается.</li><li>Проверить, что репозитории и артефакты доступны целевым ролям.</li><li>Пройти инструкцию сборки и запуска не автором проекта.</li><li>Сверить changelog, миграции, rollback и известные ограничения.</li><li>Передать эксплуатационные инструкции, мониторинг и контакты эскалации.</li><li>Провести knowledge transfer и записать открытые вопросы.</li><li>Закрыть временные доступы и подтвердить владельцев постоянных прав.</li></ol>

Порядок передачи

<ul><li>новая команда может собрать и запустить проект по инструкции;</li><li>понятно, какая версия передана и какие изменения в нее входят;</li><li>доступы управляются ролями и владельцами, а не личными аккаунтами разработчиков;</li><li>поддержка знает, где смотреть мониторинг, логи и инциденты;</li><li>есть список известных ограничений, технического долга и открытых вопросов;</li><li>эксплуатационная документация связана с кодом, changelog и релизным процессом;</li><li>после передачи не требуется срочно искать бывших участников проекта для базовых операций.</li></ul>

Критерии успешной передачи

После handover полезно оставить короткий post-transfer log: дата передачи, версия, кто принял доступы, какие проверки прошли, какие вопросы остались и какие временные договоренности нужно закрыть. Это помогает не потерять контекст между финальной встречей, актом и реальным стартом поддержки.Если поддержка в первые дни обнаруживает пробелы в инструкции, их нужно дополнять в документации, а не оставлять в переписке. Иначе следующая передача снова начнется с восстановления того же знания.Отдельно стоит отметить временные исключения: доступ, который еще не переведен на группу, ручной обходной путь, неполный мониторинг или незакрытый дефект. У каждого такого исключения должен быть срок и владелец.

Что фиксировать после передачи

<ul><li>передать zip-архив вместо репозитория с историей и версиями;</li><li>оставить секреты и доступы в личных аккаунтах;</li><li>не проверить сборку на чистом окружении;</li><li>не описать миграции, настройки и внешние зависимости;</li><li>не связать changelog с релизом и известными дефектами;</li><li>провести knowledge transfer без записи решений и открытых вопросов;</li><li>считать, что эксплуатационная документация нужна только после аварии.</li></ul>

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

Проверьте эксплуатационную документацию на ПО , общий состав документации на ПО и роль листинга программы в комплекте документации .
См. также: <a href="/handbook/soprovozhdenie-i-razvitie/ekspluatacionnaya-dokumentaciya-na-po">эксплуатационную документацию на ПО</a>, <a href="/handbook/proektirovanie-i-otsenka/dokumentatsiya-po-dlya-it-proekta">состав документации на ПО</a>, <a href="/handbook/proektirovanie-i-otsenka/proverka-komplektnosti-dokumentatsii-pered-priemkoy">проверку комплектности документации</a>, <a href="/handbook/soprovozhdenie-i-razvitie/hranenie-i-peredacha-ishodnogo-koda">Хранение и передача исходного кода</a>, <a href="/handbook/soprovozhdenie-i-razvitie/podderzhka-cherez-pochtu">Поддержка через почту</a>.

Что передать при handover ИТ-проекта в поддержку: код, доступы, версии, changelog, инструкции, эксплуатационные документы, знания и проверка готовности.

Передача проекта

Передача ИТ-проекта в поддержку: что передать и как проверить

Раздел описывает жизнь системы после запуска: поддержка, обращения, SLA, передача проекта, изменения, улучшения и развитие без потери управляемости.

<ul><li>правила поддержки и обработки обращений;</li><li>границы SLA и ответственность сторон;</li><li>передачу кода, доступов и знаний;</li><li>разделение сопровождения, гарантии, аварийных работ и нового развития.</li></ul>

Что важно согласовать

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

Результат

Материалы помогают заранее договориться, как система будет поддерживаться и развиваться после первого запуска.
См. также: <a href="/handbook/soprovozhdenie-i-razvitie/ekspluatacionnaya-dokumentaciya-na-po">Эксплуатационная документация: что должно остаться после запуска</a>, <a href="/handbook/soprovozhdenie-i-razvitie/hranenie-i-peredacha-ishodnogo-koda">Хранение и передача исходного кода</a>, <a href="/handbook/soprovozhdenie-i-razvitie/peredacha-proekta-kod-dostupy-changelog-instruktsii">Передача ИТ-проекта в поддержку: что передать и как проверить</a>, <a href="/handbook/soprovozhdenie-i-razvitie/podderzhka-cherez-pochtu">Поддержка через почту</a>.

Материалы о поддержке, SLA, передаче проекта, изменениях после запуска, эксплуатационных правилах и развитии системы.

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

<ul><li>Если нужно быстро подготовиться к оценке, начните со страницы <a href="/handbook/predproektnaya-prorabotka/chto-podgotovit-pered-obsuzhdeniem-proekta">«Что подготовить для оценки ИТ-проекта»</a>. Там собран минимальный brief: цель, пользователи, системы, данные, ограничения и критерии результата.</li><li>Если нужно разобраться в текущих процессах и системах, используйте <a href="/handbook/predproektnaya-prorabotka/predproektnoe-obsledovanie-it-proekta">«Предпроектное обследование ИТ-проекта»</a>. Материал помогает понять, что входит в обследование, какие риски фиксировать и какой результат должен быть на выходе.</li><li>Если задача пока неопределенная, откройте <a href="/handbook/predproektnaya-prorabotka/kogda-nuzhen-discovery">«Когда нужен discovery перед разработкой»</a>. Материал помогает понять, можно ли оценивать проект сразу или сначала нужно отдельное исследование.</li><li>Если речь о цифровой трансформации, используйте <a href="/handbook/predproektnaya-prorabotka/tsifrovaya-transformatsiya">«С чего начать цифровую трансформацию бизнеса»</a> как первичную рамку. Это supporting-страница, а не полный guide по трансформации.</li></ul>

Что читать сначала

Для простых задач достаточно собрать brief и перейти к оценке этапа. Для интеграционных, продуктовых и организационно сложных задач сначала нужно проверить процессы, системы, данные, владельцев, ограничения, сценарии отказа и критерии успеха. Если часть этих вводных неизвестна, лучше не просить точную смету сразу, а договориться о предпроектном обследовании, discovery или аудите.Следующий шаг зависит от зрелости вводных: обсуждение задачи, оценка по brief, предпроектное обследование, discovery, аудит, проектирование или план первого этапа.

Как использовать раздел

Для простых задач достаточно собрать brief и перейти к оценке этапа.
См. также: <a href="/handbook/predproektnaya-prorabotka/kogda-nuzhen-discovery">Когда нужен discovery перед разработкой</a>, <a href="/handbook/predproektnaya-prorabotka/predproektnoe-obsledovanie-it-proekta">Предпроектное обследование ИТ-проекта: что входит и что должно быть на выходе</a>, <a href="/handbook/predproektnaya-prorabotka/chto-proveryat-v-audite-koda-i-arhitektury">Что проверять в аудите кода и архитектуры</a>, <a href="/handbook/predproektnaya-prorabotka/chto-podgotovit-k-it-auditu">Что подготовить к ИТ-аудиту</a>, <a href="/handbook/predproektnaya-prorabotka/chto-podgotovit-pered-obsuzhdeniem-proekta">Что подготовить для оценки ИТ-проекта</a>.

Как подготовиться к оценке ИТ-проекта: собрать вводные, понять ограничения, выбрать discovery или другой следующий шаг перед разработкой.

Предпроектная проработка

Предпроектная проработка ИТ-проекта

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

<ul><li>требования и границы ближайшего этапа;</li><li>архитектура, интеграции, данные и внешние зависимости;</li><li>модель работ, сроки, бюджет и допущения;</li><li>проектные артефакты, документы, устройства и доступы.</li></ul>

Что здесь согласуется

Материалы помогают собрать основание для оценки, КП, договора, предпроектного этапа или рабочей спецификации без смешения целей, требований и обязательств поставки.

Материалы помогают собрать основание для оценки, КП, договора, предпроектного этапа или рабочей спецификации без смешения целей, требований и обязательств поставки.
См. также: <a href="/handbook/proektirovanie-i-otsenka/proektirovanie-it-sistem">Проектирование ИТ-систем</a>, <a href="/handbook/proektirovanie-i-otsenka/roadmap-it-proekta">Roadmap проекта из требований: как собрать этапы и проверить план</a>, <a href="/handbook/proektirovanie-i-otsenka/backlog-zadach">Backlog задач: как вести список работ, чтобы он не превращался в свалку</a>, <a href="/handbook/proektirovanie-i-otsenka/dinamicheskie-atributy-dannyh">Динамические атрибуты данных: как выбрать модель хранения</a>, <a href="/handbook/proektirovanie-i-otsenka/fte-ocenka-proekta">FTE-оценка проекта: FTE-месяцы и емкость команды</a>.

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

Проектирование и оценка

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

<ul><li>прикладная разработка и доработка системы;</li><li>подготовка релиза и ввод в работу;</li><li>проверка пользовательских и внутренних сценариев;</li><li>первый производственный результат и обратная связь.</li></ul>

Что входит в запуск

Материалы помогают не смешивать разработку с предварительной оценкой, инфраструктурной подготовкой и последующим сопровождением.

Материалы помогают не смешивать разработку с предварительной оценкой, инфраструктурной подготовкой и последующим сопровождением.
См. также: <a href="/handbook/razrabotka-i-zapusk/agent-materials-workspace-dlya-ai-coding-agents">Agent Materials Workspace для AI coding agents: как разделить материалы, рабочие папки и артефакты</a>, <a href="/handbook/razrabotka-i-zapusk/agents-md-skill-md-mcp-dlya-ai-coding-agents">AGENTS.md и SKILL.md для AI coding agents: что хранить в Markdown, а что отдавать через MCP</a>, <a href="/handbook/razrabotka-i-zapusk/change-request-v-proekte-razrabotki">Change request в разработке: как работают изменения scope</a>, <a href="/handbook/razrabotka-i-zapusk/chek-list-pilota-ai-coding-agents-v-komande">Чек-лист пилота AI coding agents в команде</a>, <a href="/handbook/razrabotka-i-zapusk/codex-claude-code-i-cursor-dlya-komandy">Codex, Claude Code и Cursor для команды: как выбрать coding agent под процесс разработки</a>.

Материалы о создании прикладных систем, реализации функций, релизе, вводе в работу и первом производственном результате.

Разработка и запуск

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

<ul><li>CI/CD, репозитории и правила работы с кодом;</li><li>мониторинг, метрики и нагрузочные проверки;</li><li>миграции, производительность и инженерные среды;</li><li>доступы, безопасность и воспроизводимость технического контура.</li></ul>

Что здесь фиксируется

Материалы помогают снизить технические риски и подготовить систему к регулярным изменениям, проверкам и эксплуатации.

Материалы помогают снизить технические риски и подготовить систему к регулярным изменениям, проверкам и эксплуатации.
См. также: <a href="/handbook/infrastruktura-i-avtomatizatsiya/keycloak-openid-ldap-avtorizatsiya">Единая авторизация с Keycloak, OpenID Connect и LDAP: что подготовить</a>, <a href="/handbook/infrastruktura-i-avtomatizatsiya/devops-i-upravlenie-kodom">DevOps и управление кодом: термины, доступы и передача проекта</a>, <a href="/handbook/infrastruktura-i-avtomatizatsiya/mcp-integratsii-dlya-coding-agents">MCP-интеграции для coding agents: что можно подключать агенту</a>, <a href="/handbook/infrastruktura-i-avtomatizatsiya/migratsiya-dannyh-mezhdu-sistemami">Миграция данных между системами: план, проверка и подтверждение результата</a>, <a href="/handbook/infrastruktura-i-avtomatizatsiya/nagruzochnoe-testirovanie-sistemy">Нагрузочное тестирование системы: сценарии, метрики и отчет</a>.

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