Что такое сопровождение ПО: виды, линии поддержки и SLA

Сопровождение программного обеспечения — это этап жизненного цикла ПО после передачи в эксплуатацию, на котором продукт изменяют: исправляют ошибки, адаптируют к новой среде, улучшают и заранее устраняют причины будущих сбоев. Этап описан международным стандартом ISO/IEC/IEEE 14764 (действующая редакция 2022 года; российский ГОСТ Р ИСО/МЭК 14764-2002 основан на редакции 1999 года).

Поддержка ПО — смежный, но другой процесс: помощь пользователям в работе с системой (консультации, настройка, прием и разбор обращений) без обязательного изменения кода. На практике оба слова часто смешивают, а договоры называют «сопровождением» весь пакет работ сразу. Ниже разберем, где проходит граница, какие бывают виды сопровождения, как устроены линии поддержки и что фиксирует SLA.

Мини-словарь: сопровождение, поддержка, эксплуатация

Эти три понятия путают чаще всего. Упрощенно их можно развести так:

Граница условная: одна компания называет «поддержкой» все, что после релиза, другая делит работы по договору. Надежный признак один — требуется ли модификация продукта. Если да, это сопровождение, даже если обращение пришло через линию поддержки.

Еще четыре термина из практики ITSM (в духе ITIL), которые пригодятся дальше:

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

Виды сопровождения ПО

Классическая классификация восходит к работе Э. Б. Свенсона 1976 года (корректирующее, адаптивное, совершенствующее), позже к ним добавили превентивное. В ISO/IEC 14764:2006 четыре вида сведены в две группы: исправления и улучшения — так их группирует таблица ниже.

Редакция ISO/IEC/IEEE 14764:2022 добавила пятый вид — дополняющее сопровождение (additive): относительно крупное добавление новых функций после передачи в эксплуатацию, которое отделили от совершенствующего. Группировка там тоже другая: реактивные виды (корректирующее, адаптивное) и проактивные (превентивное, совершенствующее, дополняющее). Если в договоре или ТЗ есть ссылка на стандарт, смотрите, на какую редакцию.

Отдельно выделяют аварийное (экстренное) сопровождение — незапланированное изменение, которое вносят срочно, чтобы временно удержать систему в работе до полноценного корректирующего исправления. Его обычно разрешают выпускать по упрощенной процедуре, но с обязательным разбором после.

Как отличить виды на практике: задайте вопрос «что изменилось?». Изменилась среда — адаптивное. Изменились требования пользователя — совершенствующее. Ничего не изменилось, а продукт работает не так, как задумано, — корректирующее. Дефект еще не проявился — превентивное.

Процесс сопровождения: от запроса до вывода из эксплуатации

ISO/IEC 14764 описывает сопровождение не как набор разовых исправлений, а как процесс. Упрощенно его шаги (по редакции 2006 года; в 2022 году процесс согласовали с ISO/IEC/IEEE 12207:2017):

1. Подготовка процесса — план сопровождения, правила приема запросов, ответственные, среда для тестов.
2. Анализ проблемы или модификации — воспроизвести, оценить влияние, трудоемкость и риски, выбрать вариант.
3. Реализация модификации — изменить код или конфигурацию, обновить документацию.
4. Проверка и приемка — регрессионное тестирование, согласование с заказчиком.
5. Миграция — перенос на новую платформу или среду, если требуется.
6. Вывод из эксплуатации — план отключения, перенос данных, архив.

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

В российской практике для автоматизированных систем долго действовал ГОСТ 34.601-90, где последняя стадия называлась «Сопровождение АС» и включала работы по гарантийным обязательствам и послегарантийное обслуживание. Сейчас стадии создания АС описывает ГОСТ Р 59793-2021; для госзаказчиков и договоров полезно сверять, на какой стандарт ссылается техническое задание.

Линии поддержки: L0, L1, L2, L3

Линии — это способ распределить обращения по квалификации: простое решается дешево и быстро, сложное эскалируется к тем, кто может изменить продукт. Стандарта, который жестко задает число линий, нет; ниже типичная схема.

Важный момент: L1 — это не «колл-центр, который только передает звонки». Хорошая первая линия закрывает значимую часть обращений сама, если у нее есть актуальная база знаний. Поэтому инженеры L2 и L3 после каждого нового решения пишут статью в базу — так обращение в следующий раз закрывается на уровень ниже.

Путь одного обращения: сквозной пример

Разберем, как линии, виды сопровождения и ITSM-термины складываются вместе.

1. Бухгалтер пишет: «Отчет по НДС за сентябрь не формируется». L1 регистрирует инцидент, проверяет базу знаний — похожего нет.
2. L2 воспроизводит ошибку: отчет падает, если в периоде есть документ с нулевой суммой. Дает обходной путь — временно исключить такой документ. Сервис восстановлен, инцидент закрыт.
3. Так как причина не устранена, заводят проблему. Выясняется, что в коде деление на сумму документа без проверки на ноль.
4. L3 готовит изменение — это корректирующее сопровождение. Правка проходит тесты и выходит в очередном релизе.
5. L2 добавляет статью в базу знаний, а команда заводит задачу на превентивное сопровождение: найти в коде другие места с тем же шаблоном.

В этом примере поддержка и сопровождение не спорят за территорию: поддержка восстановила работу, сопровождение устранило причину.

Что такое SLA и что в нем фиксируют

SLA (Service Level Agreement) — соглашение об уровне услуги между поставщиком и заказчиком. Внутри компании его дополняют OLA (соглашение между внутренними командами, например L1 и L2) и UC (договор с внешним подрядчиком, например L4). Обычно SLA включает:

• приоритеты — как влияние и срочность превращаются в P1-P4;
• время реакции — за сколько обращение возьмут в работу (первый содержательный ответ, а не автоответ);
• время решения — за сколько сервис восстановят, в том числе обходным путем;
• доступность — процент времени, когда сервис работает;
• часы обслуживания — календарные часы (24×7) или рабочие (например, 9-18 по будням);
• исключения — плановые окна работ, ожидание ответа клиента, сбои по вине заказчика.

Время реакции и время решения — разные метрики. Можно ответить за 10 минут и все равно нарушить SLA, если решение заняло дольше установленного срока.

Считаем простой и сроки: пример на Python

Ниже — минимальный калькулятор. Первая часть переводит процент доступности в минуты допустимого простоя за 30-дневный месяц. Вторая определяет приоритет по упрощенной матрице 3×3 и проверяет, уложилось ли обращение в сроки. Проверено на Python 3.14.

from datetime import datetime, timedelta

# 1. Сколько простоя допускает процент доступности (месяц = 30 дней)
MONTH_MIN = 30 * 24 * 60
for availability in (99.0, 99.5, 99.9, 99.99):
    allowed = MONTH_MIN * (100 - availability) / 100
    print(f"{availability:>6}% -> {allowed:7.1f} мин простоя в месяц")

# 2. Приоритет = влияние x срочность (упрощенная матрица 3x3)
PRIORITY = {
    ("high", "high"): "P1", ("high", "medium"): "P2", ("high", "low"): "P3",
    ("medium", "high"): "P2", ("medium", "medium"): "P3", ("medium", "low"): "P4",
    ("low", "high"): "P3", ("low", "medium"): "P4", ("low", "low"): "P4",
}
# Целевые сроки в календарных часах: (реакция, решение)
TARGETS = {"P1": (0.25, 4), "P2": (1, 8), "P3": (4, 24), "P4": (8, 72)}

def check(opened, impact, urgency, first_reply, resolved):
    p = PRIORITY[(impact, urgency)]
    react_h, fix_h = TARGETS[p]
    react_ok = first_reply - opened <= timedelta(hours=react_h)
    fix_ok = resolved - opened <= timedelta(hours=fix_h)
    return p, react_ok, fix_ok

t0 = datetime(2026, 9, 24, 10, 0)
print(check(t0, "high", "high", t0 + timedelta(minutes=10), t0 + timedelta(hours=5)))
print(check(t0, "medium", "low", t0 + timedelta(hours=2), t0 + timedelta(hours=30)))

Результат прогона:

  99.0% ->   432.0 мин простоя в месяц
  99.5% ->   216.0 мин простоя в месяц
  99.9% ->    43.2 мин простоя в месяц
 99.99% ->     4.3 мин простоя в месяц
('P1', True, False)
('P4', True, True)

Первое обращение — наглядный случай из предыдущего раздела: реакция за 10 минут уложилась в 15, но решение за 5 часов нарушило срок P1 в 4 часа. Второе обращение с приоритетом P4 уложилось в оба срока.

Границы примера: сроки в таблице TARGETS условные, в реальных SLA их задает договор. Код считает календарные часы и не ставит таймер на паузу, пока ждут ответа клиента. Если SLA действует только в рабочие часы, нужен календарь рабочего времени с праздниками — иначе заявка, поданная в пятницу вечером, окажется «просроченной» в понедельник утром. И еще одна граница: 99.9% в месяц и 99.9% в год — это разный допустимый простой, поэтому период расчета должен быть записан в соглашении.

Кто занимается сопровождением и поддержкой

В небольшой компании все линии может закрывать один отдел, в крупной это разные роли: специалист service desk (L1), инженер технической поддержки (L2), инженер сопровождения или разработчик (L3) и руководитель поддержки, который отвечает за SLA, метрики и базу знаний. Для старта на L1-L2 обычно нужны уверенная работа с ОС и сетями, понимание устройства веб-приложений и баз данных, умение читать логи и ясно писать. Дальше этот опыт часто ведет в системное администрирование, DevOps или тестирование.

Выводы

• Сопровождение ПО — это изменения продукта после передачи в эксплуатацию; поддержка — помощь пользователям в работе с ним. Признак сопровождения — модификация продукта.
• Виды сопровождения по ISO/IEC 14764:2006: корректирующее и превентивное (исправления), адаптивное и совершенствующее (улучшения); редакция 2022 года добавила дополняющее; аварийное — срочная временная правка до корректирующего исправления.
• Линии L0-L3 (иногда L4) распределяют обращения по квалификации; правка кода начинается на L3.
• По инциденту восстанавливают сервис, по проблеме устраняют причину — это разные задачи, и сроки SLA обычно считают по инцидентам.
• В SLA важно различать время реакции и решения, часы обслуживания, исключения и период расчета доступности.

Где применяется / связь с практикой

FAQ

Гарантийное обслуживание — это тоже сопровождение?
Да, обычно это часть сопровождения: в гарантийный срок поставщик исправляет дефекты за свой счет, а доработки и адаптация идут по отдельному договору на послегарантийное обслуживание.

Обновление версии библиотеки из-за уязвимости — какой это вид?
Зависит от того, что считать причиной: если уязвимость уже эксплуатируется или проявилась — корректирующее, если закрывается заранее по бюллетеню — превентивное. Во многих компаниях такие правки выделяют в отдельный поток с собственными сроками.

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