Одна неудачная попытка развертывания привела к инциденту стоимостью 180 000 долларов, не потому что развертывание было исключительно катастрофическим, а потому что в системе не было настроено ничего, что предотвратило бы его распространение. Радиус поражения этого развертывания, задокументированный ZopDev, не зависел от того, что пошло не так. Он зависел от того, сколько сервисов зависело от неисправного компонента без зарегистрированной границы отказа для сдерживания каскада. Развертывание провалилось по обычным причинам. Результат в 180 000 долларов стал следствием архитектуры, которая никогда не рассчитывала свой собственный радиус поражения и, следовательно, не имела оснований для определения размера инвестиций в сдерживание.
Каждая услуга с зависимыми компонентами и без зарегистрированной границы сбоя представляет собой реальную угрозу, стоимость которой определяется тем, во сколько обойдется следующее неудачное развертывание. Это не преувеличение, а финансовый отчет. Радиус поражения от неудачного развертывания — это ширина угрозы в момент, когда изменение приводит к ошибке. Умноженное на время, необходимое для обнаружения и устранения проблемы, это дает общую стоимость инцидента. Анализ радиуса поражения — это дисциплина оценки этой стоимости до начала развертывания, пока эта оценка еще может повлиять на принятие решения.
Проследить за языковыми барьерами
SMART TS XL Вычисляет полный масштаб распространения любого предлагаемого изменения на все языки вашего портфолио до момента его подтверждения.
УЗНАТЬ БОЛЬШЕ…Что на самом деле измеряет радиус взрыва?
В контексте развертывания программного обеспечения «радиус поражения» — это общее количество пользователей, систем и бизнес-функций, которые пострадают в случае сбоя развертывания. Это показатель масштаба, а не серьезности: развертывание с большим радиусом поражения затрагивает множество пользователей и систем; развертывание с малым радиусом поражения затрагивает лишь немногих. Серьезность (насколько серьезен сбой для каждого пострадавшего пользователя) и радиус поражения (сколько пользователей пострадало) — это независимые переменные, которые перемножаются при расчете стоимости.
Основная формула из области операций развертывания:
Общее количество случаев негативного воздействия на пользователя = Радиус взрыва × MTTR
Где:
- Радиус взрыва это доля пользователей, трафика или затронутых систем (от 0% до 100%).
- MTTR Среднее время восстановления, от начала отказа до полного восстановления.
Внедрение системы со 100% радиусом поражения и 5-минутным средним временем восстановления (MTTR) затрагивает каждого пользователя в течение 5 минут. Внедрение системы с 5% радиусом поражения и 100-минутным MTTR затрагивает 5% пользователей в течение 100 минут. Оба варианта приводят к одинаковым общим неудобствам для пользователей согласно формуле, но их профили затрат значительно различаются: первый — это видимый сбой, который вызывает немедленное реагирование; второй — это медленное ухудшение качества, которое может оставаться незамеченным в течение нескольких часов.
Радиус взрыва — это не то же самое, что:
Показатель частоты отказов при изменении конфигурации (Change Failure Rate ) — это метрика DORA, измеряющая долю развертываний, требующих немедленного вмешательства. Показатель частоты отказов при изменении конфигурации — это агрегированный показатель, измеряемый постфактум. Радиус поражения (Blast Radius) — это оценка, сделанная до развертывания, и показатель масштаба инцидента в реальном времени.
Радиус поражения — синоним. Эти два термина используются взаимозаменяемо; радиус взрыва чаще используется в контексте рисков развертывания и управления агентами ИИ.
Риск — это вероятность, умноженная на силу удара. Радиус взрыва — один из компонентов силы удара. Развертывание с низкой вероятностью и большим радиусом взрыва может иметь меньшие ожидаемые затраты, чем развертывание с высокой вероятностью и малым радиусом взрыва.
Модель расчета стоимости радиуса взрыва
«Неудовлетворенность пользователей» — полезный операционный показатель. Финансы требуют денежных средств. Полная модель затрат на снижение радиуса поражения преобразует неудовлетворенность пользователей в пять категорий затрат, которые обосновывают целесообразность инвестиций в снижение радиуса поражения:
Категория затрат 1: Влияние на выручку
Для сервисов, приносящих доход, формула проста: доход в час × процент зоны поражения × среднее время восстановления (MTTR) в часах. Сервис оформления заказов, обрабатывающий 500 000 долларов в час, при 100% зоне поражения в течение 45 минут: 375 000 долларов потерянного дохода. Сервис рекомендаций, обеспечивающий 15% покупок, при 100% зоне поражения в течение 45 минут: 56 250 долларов потерянного дохода из-за затронутой функции, при условии, что покупки нерекомендуемых товаров продолжаются.
Ключевым параметром является процент зоны поражения: использование индикатора в 5% ограничивает влияние на выручку до 5% от общей суммы, независимо от того, сколько времени займет восстановление.
Категория затрат 2: Инженерные затраты
Реагирование на инциденты обходится дорого. Инцидент уровня P1, требующий трехчасового совещания с участием 8 инженеров, за которым следует процедура отката и анализ причин сбоя, обходится примерно в 30 инженерных часов плюс 8 часов дежурства. При средней стоимости услуг инженеров в час (150 долларов США) это составляет 4,500 долларов США прямых инженерных затрат на трехчасовой инцидент, не считая упущенной выгоды от функций, которые эти инженеры не разрабатывали.
Категория затрат 3: Затраты на соблюдение нормативных требований и соответствие законодательству.
Внедрение систем, затрагивающих регулируемые системы, системы, хранящие персональные данные, записи финансовых транзакций, медицинскую информацию или данные держателей карт, может повлечь за собой обязательства по соблюдению нормативных требований, выходящие далеко за рамки самого инцидента. Сбой при внедрении, приводящий к повреждению финансовых записей клиентов, может повлечь за собой требования к уведомлению о нарушении GDPR (в течение 72 часов с момента обнаружения), отчетность о нарушении HIPAA (в течение 60 дней с момента обнаружения) и требования к документированию инцидента в соответствии с PCI-DSS. Регуляторные издержки включают не только уведомление, но и юридическую экспертизу, бремя подготовки документации, потенциальный штраф и последующее взаимодействие с регулирующими органами.
Для организаций, подпадающих под действие системы обеспечения операционной устойчивости DORA, инциденты в сфере ИКТ, затрагивающие критически важные функции, подлежат официальной отчетности перед соответствующим финансовым регулятором. Один-единственный инцидент с большим радиусом поражения, затронувший регулируемую DORA функцию, может инициировать процесс отчетности перед регулирующими органами, который обойдется значительно дороже, чем инженерные работы по устранению последствий.
Категория затрат 4: SLA и договорные штрафы
Соглашения об использовании корпоративного программного обеспечения обычно включают в себя соглашения об уровне обслуживания (SLA) с финансовыми штрафами за сбои в доступности. Развертывание, вызывающее сбой уровня P1 на 45 минут, может привести к начислению компенсаций по SLA всем корпоративным клиентам, у которых превышено оговоренное время бесперебойной работы. Затраты на компенсации по SLA быстро накапливаются: компенсация в размере 0.1% в месяц по SLA для 200 корпоративных клиентов, каждый из которых платит 50 000 долларов в год, приводит к начислению компенсаций на сумму 100 000 долларов за один 45-минутный сбой.
Категория затрат 5: Затраты на восстановление
Откат не бесплатен. Для отката развертывания необходимо: обнаружить сбой (что занимает время, задержка обнаружения напрямую увеличивает потенциальный ущерб), запустить процедуру отката (автоматическую или ручную), выполнить откат (повторное развертывание, перекомпиляция для скомпилированных систем, очистка данных, если состояние было повреждено) и проверить восстановление. Общее время восстановления — это среднее время восстановления (MTTR). Стоимость восстановления — это затраты на рабочую силу и инфраструктуру за это время MTTR.
Для устаревших систем COBOL затраты на восстановление имеют дополнительный аспект: процедуры перекомпиляции и переноса кода, которые могут занять от 30 до 60 минут, прежде чем откатимый код будет запущен в производственной среде. Каждая минута времени компиляции и переноса — это минута потенциального риска. Современные системы, поддерживающие мгновенный откат с помощью переключения «синий-зеленый», имеют структурное преимущество в отношении среднего времени восстановления (MTTR) по сравнению с скомпилированными устаревшими системами.
Полная смета расходов:
Total Blast Cost = (Revenue/hr × Blast% × MTTR_hrs)
+ (Eng_hourly_cost × Eng_headcount × MTTR_hrs)
+ Regulatory_cost (if regulated system in blast)
+ SLA_credit_cost (per customer per SLA tier)
+ Recovery_labor_cost
Example (high blast radius incident):
Revenue: $500K/hr × 100% × 0.75 hrs = $375,000
Engineering: $150/hr × 10 engineers × 3 hrs = $4,500
Regulatory: Legal review + notification = $15,000
SLA credits: 50 enterprise customers = $25,000
Recovery: 4 engineers × 3 hrs = $1,800
─────────────────────────────────────────────────────────
Total blast cost: = $421,300
Показатель радиуса поражения при предварительном развертывании
Предварительный показатель зоны поражения перед развертыванием — это число, вычисляемое до начала развертывания, которое оценивает потенциальные затраты в случае неудачи и выражается в виде классификации риска, определяющей решение о развертывании.
Показатель имеет четыре входных параметра:
Входные данные 1: Распределение зависимостей. Сколько сервисов, программ или систем зависят от развертываемого компонента? Компонент с 50 зависимыми компонентами имеет больший радиус поражения, чем компонент с 2 зависимыми компонентами. Это структурные входные данные, полученные из графа зависимостей, а не из оценки. Радиус поражения нельзя надежно рассчитать без графа зависимостей. Без знания того, какие сервисы зависят от целевого компонента, оценка не учтет косвенное воздействие.
Входные данные 2: Процент затронутого трафика. Какая доля производственного трафика проходит через развертываемый компонент? Общая служба аутентификации, обрабатывающая каждый запрос пользователя, в случае сбоя оказывает 100%-ное влияние на трафик. Компонент A/B-тестирования с флагами функций обрабатывает 5% трафика. Эти входные данные определяют множитель влияния на доход.
Входные данные 3: Критичность затронутых компонентов. Включает ли зона поражения какие-либо системы первого уровня (критически важные для выполнения задач), регулируемые системы или системы с обязательствами по соглашению об уровне обслуживания (SLA)? Развертывание, затрагивающее регулируемую DORA функцию, приводит к увеличению показателя радиуса поражения независимо от процента трафика, поскольку регуляторные последствия являются бинарными: функция либо затронута, либо нет.
Входные данные 4: Оценка времени отката. Сколько времени займет восстановление в случае сбоя развертывания? Микросервис с автоматическим сине-зеленым откатом восстанавливается за секунды. Пакетная программа COBOL с процедурой ручной перекомпиляции и продвижения занимает 30-60 минут. Эти входные данные определяют множитель MTTR.
| Результат взрыва | Зал развертывания | Типичный профиль |
|---|---|---|
| 0-25 | Автоматическое развертывание | Низкая вероятность распространения сигнала, низкий процент трафика, быстрый откат, отсутствие первого уровня в рассылке. |
| 26-50 | Развертывание с расширенным мониторингом. | Умеренное распределение трафика или высокий процент трафика, быстрый откат. |
| 51-75 | Требуется одобрение человека. | Высокий процент распространения или трафика, или 1-й уровень в масштабе взрыва. |
| 76-100 | Обязательны анализ воздействия и поэтапное внедрение. | Очень высокая скорость распространения взрыва, регулируемая система в режиме взрыва, медленное откатывание. |
Стратегии сдерживания: сужение радиуса до его расширения
Наиболее экономически эффективным способом управления радиусом поражения является предварительное локализация взрыва, ограничивающая зону поражения системы в случае несанкционированного развертывания, прежде чем взрыв будет обнаружен и предотвращен.
Выпуск тестовой версии (canary releases). Развертывайте версию на небольшой части производственного трафика: 1%, 5%, 10%, перед полным развертыванием. При развертывании на 5% пользователей максимальный радиус поражения составляет 5% пользователей, если развертывание не удастся до перехода на полную версию. Отслеживайте частоту ошибок, задержку и бизнес-показатели тестовой версии; переходите на полную версию только тогда, когда тестовая версия будет работоспособной.
Флаги функций. Отделение развертывания от релиза. Код поставляется на все серверы, но активируется только для определенной группы пользователей. Флаг функции, активирующий новый алгоритм ценообразования для 1% пользователей, имеет радиус поражения в 1%. Откат путем отключения флага, повторное развертывание не требуется, откат за считанные секунды.
Сине-зеленое развертывание. Поддерживайте две идентичные производственные среды. Новые развертывания выполняются в неактивной среде; переключение трафика происходит мгновенно, когда среда готова. Неудачное сине-зеленое развертывание отменяется путем переключения трафика обратно на предыдущую среду за секунды, а не за минуты. Среднее время восстановления (MTTR), измеряемое в секундах, значительно снижает общую стоимость инцидента независимо от масштаба проблемы.
Автоматические выключатели и перегородки. Архитектурные решения, ограничивающие отказы определенными границами. Автоматический выключатель, размыкающийся при отказе нижестоящего устройства, останавливает каскад отказов на границе цепи, радиус поражения ограничивается непосредственными потребителями отказавшего устройства, а не распространяется транзитивно.
Формула ограничения зоны поражения взрывом на практике:
# Kubernetes: progressive canary with blast radius gate
# Using Argo Rollouts for automated canary analysis
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
strategy:
canary:
steps:
- setWeight: 5 # 5% blast radius maximum at step 1
- analysis:
templates:
- templateName: blast-radius-gate
- setWeight: 25 # Expand only if analysis passes
- analysis:
templates:
- templateName: blast-radius-gate
- setWeight: 100 # Full rollout only after staged validation
analysis:
successfulRunHistoryLimit: 3
unsuccessfulRunHistoryLimit: 3
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: blast-radius-gate
spec:
metrics:
- name: error-rate
successCondition: result < 0.01 # Block if error rate > 1%
provider:
prometheus:
query: |
rate(http_requests_total{status=~"5.."}[5m])
/ rate(http_requests_total[5m])
- name: latency-p99
successCondition: result < 500 # Block if p99 > 500ms
provider:
prometheus:
query: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
Проблема устаревших систем: когда стратегии сдерживания дают сбой
Описанные выше стратегии изоляции — канареечные релизы, флаги функций, сине-зеленое развертывание — предполагают архитектуру системы, в которой трафик может быть разделен между старыми и новыми версиями, где развертывание происходит мгновенно, а откат представляет собой изменение конфигурации, а не процесс сборки. Устаревшие пакетные системы COBOL нарушают все три предположения.
Пакетная программа на COBOL не может быть развернута по принципу «канареечного» развертывания. Ночная пакетная программа, обрабатывающая 10 000 записей о клиентах, не имеет режима «5% записей», она обрабатывает все записи или не обрабатывает ни одной. Разделение трафика в пакетной обработке отсутствует.
Для развертывания COBOL требуется перекомпиляция и продвижение. Неудачное развертывание COBOL нельзя отменить, просто изменив флаг функции или вернувшись к предыдущему образу в Argo Rollout. Для отмены требуется: перекомпиляция предыдущей версии из исходного кода, продвижение скомпилированного модуля загрузки через систему управления изменениями в производственную библиотеку и повторный запуск пакетной обработки с точки сбоя. В идеальных условиях это занимает 30-60 минут. На практике, для сложных изменений или когда перекомпиляция выявляет влияние на последующие этапы, это занимает больше времени.
Радиус поражения COBOL измеряется в пакетных окнах, а не в процентах от числа пользователей. Неудачное развертывание COBOL в 2 часа ночи, приводящее к сбою ночной пакетной обработки, обнаруживается только к 8 часам утра, когда прибывает оперативная группа. Это шесть часов воздействия, в течение которых следующая запланированная пакетная обработка также может завершиться с ошибкой, поскольку она зависит от результатов неудачного запуска. Каскад сбоев пакетной обработки, который может последовать за одним неудачным развертыванием COBOL, является устаревшим аналогом каскада сбоев микросервисов, для предотвращения которого и был разработан автоматический выключатель.
Таким образом, стратегия ограничения радиуса поражения при использовании COBOL должна быть сосредоточена на сокращении среднего времени восстановления после взрыва, а не на уменьшении радиуса поражения:
Предварительно протестированные процедуры отката. Процедура отката для развертывания COBOL должна быть задокументирована, протестирована в непроизводственной среде и выполняться менее чем за 15 минут оператором, который ранее не участвовал в неудачном развертывании. Процедура отката, требующая обнаружения, пробуждения и предоставления доступа к системе управления изменениями исходному разработчику, имеет структурное среднее время восстановления (MTTR), измеряемое в часах, а не в минутах.
Использование «теплых» сред для перекомпиляции. Предварительная подготовка к откату компиляции в «теплой» среде, где доступны артефакты компиляции предыдущей версии и перекомпиляция может начаться немедленно, сокращает среднее время восстановления (MTTR) с времени компиляции плюс время отката до времени только отката.
Контрольная точка и перезапуск пакета. Пакетные программы COBOL, реализующие возможность создания контрольных точек и перезапуска, записывающие свой прогресс в восстанавливаемое состояние через определенные интервалы, уменьшают масштаб последствий сбоя в середине пакета с «повторного запуска всего пакета с начала» до «перезапуска с последней контрольной точки». Для длительных пакетных заданий это структурный эквивалент уменьшения масштаба последствий: последствия ограничиваются записями, обработанными с момента последней контрольной точки, а не всем пакетом.
Соотношение радиуса взрыва и среднего времени восстановления
Анализ радиуса взрыва иногда ошибочно понимают как оптимизацию для достижения наименьшего возможного радиуса взрыва. Это неверная цель. Правильная цель — это наименьшая возможная общая стоимость инцидента, которая может быть достигнута путем минимизации радиуса взрыва, минимизации среднего времени восстановления после взрыва (MTTR) или их комбинации.
Компромисс реален и заслуживает того, чтобы его четко обозначить:
| Стратегии | Радиус взрыва | MTTR | Профиль общей стоимости | Для каких задач |
|---|---|---|---|---|
| Канарейка | Очень низкий (5%) | Все | Низкий уровень при интенсивном мониторинге | Веб-сервисы с высокой посещаемостью |
| Сине-зеленое развертывание | 100% мгновенно | Очень мало (секунд) | Низкий уровень из-за быстрого восстановления | Микросервисы с мгновенным откатом |
| Предварительно протестированный откат | 100% (без канареек) | Низкий уровень (< 15 мин) | Средняя | Пакетные, компилируемые, устаревшие системы |
| Флаги функций | Очень низкий (процент флага) | Очень низкий (переключение флага) | Очень низкий | Новая функциональность с ограниченным доступом |
| Нет сдерживания | 100% | Технология | Наивысший | Сценарий ZopDev на сумму 180 000 долларов |
Для устаревших систем COBOL строки с флагами «канареечного» и «функционального» типов неприменимы. Сине-зеленый подход частично применим (некоторые организации поддерживают параллельные среды библиотек COBOL), но требует значительной операционной инфраструктуры. Практическая стратегия заключается в предварительно протестированном откате в сочетании с контрольными точками/перезапуском, принимая во внимание 100% радиус поражения, присущий пакетной обработке, и инвестируя в сокращение среднего времени восстановления (MTTR) для минимизации общих затрат.
Показатель «радиуса поражения» для развертывания на COBOL обычно выше, чем для эквивалентного микросервиса, не потому, что развертывание более рискованно с точки зрения качества кода, а потому, что структурные ограничения пакетной обработки исключают возможности разделения трафика, которые снижают «радиус поражения» для веб-сервисов. Признание этого структурного ограничения — первый шаг к правильному смягчению последствий: инвестируйте в инфраструктуру MTTR, а не в инфраструктуру изоляции, которую архитектура не может поддерживать.
Как SMART TS XL Предоставляет граф зависимостей для расчета радиуса взрыва.
Основной вывод из практики анализа радиуса взрыва заключается в том, что для точного расчета радиуса взрыва необходима точная диаграмма зависимостей. Без знания того, какие системы зависят от цели, оценка не учтет косвенное воздействие, а именно такая оценка и привела к инциденту на сумму 180 000 долларов.
SMART TS XLАвтора сопоставление зависимостей приложения Предоставляет граф зависимостей, который обеспечивает точный расчет радиуса взрыва для устаревших сред COBOL и многоязычных корпоративных сред. Для любого предлагаемого изменения, модификации копибука, изменения интерфейса подпрограммы, переопределения набора данных JCL, карта зависимостей перечисляет каждую программу в области взрыва: прямые зависимые на уровне 1 и транзитивные зависимые на уровне 2 и далее. Это перечисление является структурным входным параметром для оценки радиуса взрыва: количество разветвлений, критичность каждой зависимости и зависимости контрактов данных, которые пересекают границы системы.
Функция анализа воздействия преобразует граф зависимостей в оценку рисков развертывания: сколько программ необходимо перекомпилировать, какие нижестоящие системы получают измененные выходные данные, какие регулирующие функции находятся в зоне риска. Эта оценка является структурированным входным параметром для оценки радиуса риска перед развертыванием, преобразуя абстрактный граф зависимостей в конкретный, количественно измеримый профиль риска, определяющий решение о развертывании.
Функция статического анализа кода определяет параметр сложности отката: программы с высокой цикломатической сложностью, плотной связанностью и большим разветвлением имеют более высокие показатели сложности отката, их перекомпиляция обходится дороже, они с большей вероятностью имеют зависимости от последующих компиляций и с большей вероятностью требуют расширенной проверки перед подтверждением успешного отката. Этот показатель сложности является входным параметром MTTR для расчета стоимости радиуса взрыва.
Функция корпоративного поиска позволяет запрашивать данные об уязвимости на скорости принятия решений: находить каждую программу, содержащую определенный шаблон кода (уровень уязвимости на этапе компиляции), каждую программу, считывающую данные из определенного набора данных (уровень уязвимости на этапе выполнения), каждую программу, передающую данные в систему нормативной отчетности (уровень уязвимости на этапе соответствия). Эти запросы позволяют получить данные об уязвимости за считанные секунды, до утверждения изменения, а не после объявления об инциденте.
Для организаций, проводящих программы модернизации устаревших систем , анализ масштабов последствий является обязательным условием для каждой волны миграции. Каждое решение о миграции — это решение о развертывании, и каждое решение о развертывании в устаревшей среде COBOL имеет масштаб последствий, который структурно больше, чем при развертывании эквивалентного микросервиса. Знание этого масштаба последствий до начала этапа миграции отличает программы модернизации, которые управляют рисками, от тех, которые их обнаруживают.
Вывод: радиус взрыва можно рассчитать. Но это не оправдание для того, чтобы этого не делать.
Инцидент на 180 000 долларов не был непредсказуемым. Причины сбоя были известны. Зависимости, приведшие к отказу системы, были реальными и, в принципе, могли быть обнаружены до начала работ. Не хватало не информации, а дисциплины в расчете радиуса взрыва до начала работ, использовании этого расчета для определения размера инвестиций в меры по сдерживанию и рассмотрении незаявленных зависимостей как реальных финансовых рисков, а не как незадокументированной архитектуры.
Анализ радиуса взрыва — это не мероприятие, проводимое после инцидента. Это мероприятие, проводимое до развертывания, расчет, который преобразует решения о развертывании из категории «мы считаем это безопасным» в категорию «мы знаем, что радиус взрыва ограничен X, предполагаемая стоимость отказа составляет Y долларов, а время восстановления — Z минут». Организации, которые принимают решения о развертывании на основе этих данных, развертывают системы с большей уверенностью, более эффективно локализуют отказы и тратят меньше средств на реагирование на инциденты, чем организации, которые обнаруживают свой радиус взрыва, когда он уже начинает расширяться.
Радиус поражения всегда можно рассчитать до развертывания. Вопрос лишь в том, происходит ли расчет до внедрения изменений или после объявления инцидента.
Мета-описание, 165 символов
Вариант 1: Анализ радиуса взрыва: пятикомпонентная модель затрат, оценка перед развертыванием, стратегии локализации, проблемы пакетной обработки данных в устаревшем COBOL и компромисс между средним временем восстановления (MTTR).
Вариант 2 (рекомендуемый): Оценка стоимости неудачного развертывания: модель оценки радиуса поражения, предварительная оценка, сравнение методов «канареечного», «сине-зеленого» и пакетного сдерживания COBOL, а также объяснение компромисса между средним временем восстановления (MTTR).
Вариант 3: Анализ радиуса взрыва: инцидент стоимостью 180 000 долларов, модель затрат, оценка перед развертыванием, канареечное и сине-зеленое локализация, а также задача пакетной обработки COBOL.
