Сопровождение программных комплексов
Качество данных — Data Governance, роль БД.
С чего начать, если вы новичок
Сопровождение (software maintenance, иногда пишут "поддержка" или maintenance) — всё, что делают с уже сданным продуктом, чтобы он продолжал работать и соответствовал новым условиям — законы меняются, банк меняет API, пользователи находят баги, хакеры находят дыры в библиотеках.
Частая иллюзия: "проект закончился на акте приёмки". На деле у долгоживущих систем значительная доля полной стоимости (TCO — total cost of ownership, "стоимость владения") приходится на годы после первой поставки; в учебниках и ISO/IEC 14764 для зрелых продуктов нередко приводят оценку порядка двух третей затрат жизненного цикла на сопровождение (цифра зависит от домена и способа учёта). В жизненном цикле ПО это фаза эксплуатация и поддержка (SDLC).
Разработка — постройка дома.
Сопровождение — коммунальные платежи, ремонт крыши после шторма, замена лифта по новым нормам. Дом "готов", но без ухода он дешевеет и становится опасным.
Любое сопровождаемое годами ПО со временем становится "наследием" (legacy).
Безопасные изменения — в разделе Легаси-код.
Мини-глоссарий
| Термин | Простыми словами |
|---|---|
| Инцидент | Событие "что-то сломалось" или "не работает как ожидали" |
| Заявка / тикет | Запись в системе учёта (Jira, ServiceNow): описание проблемы, приоритет, статус |
| SLA | Service Level Agreement — договорённые сроки реакции и восстановления |
| L0 | Call-center / горячая линия — приём обращения, маршрутизация (не то же, что инженер L1) |
| L1 / L2 / L3 | Уровни поддержки: типовые ответы → углублённый анализ → разработчики / архитектура |
| Сопровождение vs поддержка | По ISO 14764 сопровождение (maintainer) — изменения в ПО и контроль качества; поддержка у заказчика — эксплуатация и helpdesk, часто без правки кода |
| Регресс | Проверка, что исправление не сломало старый функционал |
| Release notes | Краткое описание изменений в новой версии для пользователей и поддержки |
| Техдолг | Упрощения при разработке, которые потом дорого чинить |
Четыре вида сопровождения (классика IEEE)
Исторически выделяют четыре типа работ — на практике один тикет часто сочетает два.
| Вид | По-английски | Суть | Пример из жизни |
|---|---|---|---|
| Корректирующее | Corrective | Исправление дефектов — система вела себя не так, как в ТЗ | Неверный расчёт НДС в счёте |
| Адаптивное | Adaptive | Подстройка к изменившейся среде без смены бизнес-требований | Новая версия Windows, банк отключил старый API |
| Совершенствующее | Perfective | Улучшение без изменения спецификации | Ускорили отчёт, который "и так работал, но медленно" |
| Предупреждающее | Preventive | Работа заранее, чтобы снизить будущие риски | Обновили уязвимую библиотеку, отрефакторили модуль перед пиком нагрузки |
Как отличить на совещании: спросите "меняется ли то, что обещали заказчику в ТЗ?"
- Только баг — corrective.
- ТЗ то же, среда другая — adaptive.
- ТЗ то же, хотим быстрее/удобнее — perfective.
- Профилактика без жалобы пользователя — preventive.
Смешанный пример: "После обновления ОС перестала печататься накладная" — adaptive (среда) + часто corrective (ошибка в драйвере/коде).
Этапы и процедуры — путь заявки от звонка до релиза
Типовой цикл (близок к ITIL — библиотеке практик ITSM; приоритеты — по SLA):
Что происходит на каждом шаге
- Регистрация — без тикета нет истории, нет SLA, нельзя доказать объём работ при споре с заказчиком.
- Классификация — инцидент (срочно, что-то упало) отличают от запроса на обслуживание ("как выгрузить отчёт?") и от запроса на изменение (новая кнопка в интерфейсе).
- Приоритет — обычно матрица "влияние × срочность"; P1 — простой всей системы, P4 — косметика.
- Диагностика — воспроизведение на копии prod или staging; без логов L3 часто "слепой".
- Релиз — патч идёт через тот же SCM, что и основная разработка — версия, тег, протокол регресса.
Ключевые артефакты: журнал инцидентов, SLA, release notes, обновлённая документация, запись в управлении конфигурацией.
SLA — что обещают заказчику и как это считать
SLA фиксирует измеримые обязательства. Примеры формулировок (цифры — иллюстрация, в контракте свои):
| Метрика | Что значит | Пример |
|---|---|---|
| Время реакции | Когда дежурный подтвердил тикет и начал работу | P1 — 15 минут, P3 — 8 рабочих часов |
| Время восстановления (RTO) | Когда сервис снова доступен (хотя бы обходной путь) | RTO ≤ 4 ч для P1 |
| Доступность (uptime) | Доля времени, когда система доступна | 99,5% в месяц (≈ 3,6 ч простоя) |
RPO (Recovery Point Objective, целевая точка восстановления) — максимальный интервал, за который допустима потеря данных при катастрофе (например, "не больше 15 минут несохранённых транзакций"). От RPO зависят частота бэкапов, архивация журналов СУБД (WAL) и затраты на зеркалирование. RTO (Recovery Time Objective, целевое время восстановления) — сколько может длиться простой от сбоя до снова работающего сервиса (с учётом времени обнаружения инцидента). Оба показателя закладывают в смету и в стратегию резервного копирования БД; теория — восстановление после сбоя. Связь с надёжностью по ISO 25010.
В госконтракте SLA часто привязаны к штрафам или бонусам. Для исполнителя важно закладывать в смету дежурства, стенд, автотесты регресса — иначе формально SLA выполнить невозможно.
Ресурсы для сопровождения
| Ресурс | Зачем нужен | Что бывает, если нет |
|---|---|---|
| Команда L2/L3 | Анализ, код, релизы | Всё зависает на одном "герое" |
| База знаний / runbook | Типовые инструкции ("перезапуск службы X") | Каждый раз изобретают велосипед |
| Среды dev / test | Воспроизвести баг без риска для prod | Патч "на живую" ломает больше |
| Мониторинг и логи | Раннее обнаружение, расследование | Пользователь звонит раньше, чем вы узнали |
| Контракт и бюджет | Понятный объём работ в год | "Бесплатные" доработки съедают маржу |
Ориентир по бюджету: для многих корпоративных систем закладывают 15–25% от стоимости первоначальной разработки в год на сопровождение — сильно зависит от домена (медицина, финансы, АСУ ТП дороже).
В госзаказе сопровождение часто выносят отдельным этапом или отдельным контрактом с штатным расписанием и регламентом.
Экономика сопровождения — почему это тема курса
Три связи с экономикой производства:
- Стоимость изменения растёт, если при разработке не закладывали сопровождаемость (modularity, testability, документация).
- Технолг на этапе "быстро сдать" — это счёт, который предъявят в сопровождении: каждый патч дороже предыдущего.
- COCOMO II учитывает опыт людей и стабильность требований; после сдачи часто растёт доля adaptive-работ (законы, интеграции), даже если функциональные требования "заморожены".
Учебный пример TCO на 5 лет
Допустим, разработка стоила 80 млн ₽, сопровождение — 20% в год от этой суммы.
| Год | Разработка | Сопровождение | Накоплено |
|---|---|---|---|
| 0 | 80 млн | — | 80 млн |
| 1 | — | 16 млн | 96 млн |
| 2 | — | 16 млн | 112 млн |
| 3 | — | 16 млн | 128 млн |
| 4 | — | 16 млн | 144 млн |
| 5 | — | 16 млн | 160 млн |
За пять лет сопровождение сравнялось с первоначальной разработкой. Решение "переписать с нуля" vs "чинить дальше" сравнивают именно по такой полной стоимости — см. TCO и легаси.
Организационные модели — кто делает сопровождение
| Модель | Как устроено | Плюсы | Минусы |
|---|---|---|---|
| Та же команда разработки | "You build it, you run it" | Знают код, быстрые фиксы | Дорого; выгорание; мало времени на новые фичи |
| Выделенная поддержка | Отдельный штат L2/L3 | Фокус на SLA | Разрыв с архитектурой; "костыли" без рефакторинга |
| Аутсорс | Внешний подрядчик по регламенту | Гибкий бюджет | Потеря экспертизы; долгий онбординг |
| Гибрид | L1 у заказчика, L2/L3 у разработчика | Баланс | Нужны чёткие границы эскалации |
Выбор модели — решение экономики и риска, а только HR.
Связь с документированием и приёмкой
При каждом релизе сопровождения обновляют:
- руководство пользователя / оператора;
- release notes (что изменилось, что проверить после обновления);
- при изменении поведения — фрагмент ТЗ или приложение к контракту;
- сценарии для регрессионных испытаний в ПМИ.
Иначе заказчик примет патч "на словах", а на следующей приёмке крупного релиза всплывёт расхождение с документацией — см. сертификацию и приёмку.
Типичные ошибки и как их избежать
- Нет регресса — каждый патч ломает старое. Лечение: минимальный набор автотестов на критичные сценарии + smoke после деплоя.
- "Героический" L3 — знания только в одной голове. Лечение: runbook, парная работа, код-ревью даже "мелких" фиксов.
- Сопровождение без логов prod — невозможно расследовать. Лечение: централизованные логи, correlation id в запросах.
- Игнорирование preventive — накопление CVE в зависимостях. Лечение: регулярный dependency audit, окно на обновления.
- Смешение сопровождения и бесплатных доработок — scope creep без change request. Лечение: в контракте чётко: что входит в SLA, что — отдельная оплата.
Рекомендую читать дальше
| Тема | Материал |
|---|---|
| SCM, версии | Управление конфигурацией |
| Безопасные правки | Легаси-код |
| Приёмка релизов | Сертификация и приёмка |
| Качество и NFR | ISO/IEC 25010 |
| Оценка трудозатрат | COCOMO II |