BMC Control-M 7: Путешествие от традиционного пакетного планирования к автоматизации рабочих нагрузок

Control-M является одной из наиболее широко используемых платформ автоматизации пакетной рабочей нагрузки корпоративного класса. Обладая глубокими знаниями Control-M, вы сможете использовать этот инструмент для удовлетворения постоянно растущих потребностей в пакетной обработке данных. До сих пор не было книги, которая помогла бы вам успешно внедрить и управлять этим мощным инструментом. С помощью этой книги вы быстро освоите Control-M и сможете назвать себя “специалистом по Control-M”!

“BMC Control-M 7: Путешествие от традиционного пакетного планирования к автоматизации рабочей нагрузки” введет вас в мир Control-M и поможет вам успешно внедрить и поддерживать среду Control-M. Освоив этот инструмент автоматизации рабочих нагрузок, вы увидите, как перед вами откроются новые возможности.

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

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

Глава 1. Знакомство с концепцией

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

Запомнив эти ключевые моменты, вы легко поймете назначение каждой функции Control-M, о которой пойдет речь далее в книге. Что еще более важно, принятие правильных концепций пакетной обработки поможет вам построить эффективную централизованную пакетную среду и в будущем использовать Control-M наиболее эффективным образом.

К концу этой главы вы сможете:

Объяснить смысл пакетной обработки и понять, зачем нужна пакетная обработка

Описать два основных типа пакетной обработки

Перечислить проблемы пакетной обработки в современной ИТ-среде

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

Назовите различные рабочие роли и обязанности в централизованной пакетной среде

Понять, почему автоматизация рабочей нагрузки является следующим шагом для пакетного планирования

Представьте пакетную обработку

Мы слышим о горячих темах в сфере ИТ каждый день и повсюду. Возьмите в руки технический журнал, посетите ИТ-сайт или подпишитесь на еженедельную рассылку, и вы увидите темы об облачных вычислениях, SOA, BPM/BPEL, хранилищах данных, ERP – да что угодно! Даже по телевизору и в кинотеатрах вы можете увидеть что-то вроде рекламы “Железный человек 2 скоро в кинотеатрах + Sun/Oracle в центре обработки данных сейчас”. В последние годы ИТ стали модой, а не просто технологией, но как часто вы слышите слова “пакетная обработка”, упомянутые в статьях или на ИТ-шоу?

История пакетной обработки

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

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

Это файл из Викисклада. Commons – это хранилище медиафайлов со свободной лицензией ).

Со временем технология перфокарт потеряла свою славу и устарела, а на смену ей пришли гораздо более совершенные технологии хранения данных. Однако метод пакетной обработки удивительным образом выжил и продолжает играть важную роль в компьютерном мире для решения важнейших бизнес-задач. Хотя окружающие технологии значительно изменились, основная концепция пакетной обработки осталась прежней. Для повышения эффективности программы, написанные для пакетного режима (они же пакетные задания), обычно запускаются, когда накапливается большое количество входных данных, готовых к обработке. Кроме того, многие рутинные бизнес-процессы процедурного типа, естественно, должны обрабатываться в пакетном режиме. Например, ежемесячное выставление счетов и двухнедельные платежные ведомости – типичные бизнес-процессы, ориентированные на пакетную обработку.

Словарное определение пакетной обработки: (Computer Science) Набор данных для обработки за один запуск программы.

Традиционные пакетные задания, как известно, обрабатывают сразу большой объем данных. Поэтому ожидать, что результат будет получен немедленно, непрактично. Однако для каждой пакетной обработки все равно существует предопределенный срок выполнения, либо он установлен бизнес-требованиями (также известными как SLA – Service Level Agreement), либо просто потому, что она должна завершиться, чтобы можно было начать выполнение зависимых заданий пакетной обработки. Например, группа пакетных заданий организации должна сформировать данные по начислению заработной платы и отправить их в банк к 5 утра понедельника, чтобы у банка было достаточно времени для их обработки и обеспечения перевода средств на счета каждого сотрудника организации к 8 утра вторника.

Правила и требования тех бизнес-процессов, которые требуют пакетной обработки, становятся все более сложными. Это делает пакетную обработку не только очень трудоемкой, но и трудоемкой, то есть от бизнес-процесса требуется выполнение более чем одного шага или даже множества связанных между собой заданий, следующих одно за другим (также известный как поток заданий). Для того чтобы компьютерная система могла выполнить задание или поток заданий без участия человека, соответствующие шаги в рамках задания или задания в рамках потока заданий должны быть предварительно упорядочены в требуемом логическом порядке, а входные данные должны быть готовы до начала выполнения шага задания.

Пакетная обработка в сравнении с интерактивной обработкой

С течением времени компьютерные системы получили еще одно значительное усовершенствование, получив возможность обрабатывать интерактивные действия пользователей (также называемые обработкой транзакций или интерактивной обработкой). Это стало важной вехой в истории вычислительной техники, поскольку навсегда изменило способ работы человека с компьютером, то есть для определенных типов запросов пользователям больше не нужно ждать, пока произойдет обработка (только в пакетном режиме в течение определенного периода времени). Пользователи могут отправить запрос в компьютер для немедленной обработки. Такие запросы могут быть запросами на получение или изменение данных. Например, кто-то проверяет баланс своего банковского счета на банкомате или кто-то размещает ордер на покупку или продажу акций через веб-сайт онлайн-брокера. В отличие от пакетной обработки, компьютерные системы обрабатывают каждый запрос пользователя индивидуально в момент его подачи. CICS (Customer Information Control System) – это типичное приложение для мэйнфреймов, предназначенное для обработки большого объема онлайновых транзакций. С другой стороны, начали набирать популярность персональные компьютеры, которые разработаны и оптимизированы для работы преимущественно в интерактивном режиме.

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

Вот пример типичного сценария в общей среде пакетной обработки и обработки транзакций для сайта интернет-магазина:

7:00 утра: В это время сайт обычно начинает получать онлайн-трафик, но его объем невелик.

10:00: Трафик начинает расти, но все еще относительно небольшой. Пользовательские запросы поступают из Интернета, например, просмотр каталога продукции, размещение заказа или отслеживание существующего заказа.

12:00 вечера: Начинаются часы пика транзакций. Система выделена для обработки онлайн-запросов пользователей. В это время генерируется большое количество заказов.

10:00 вечера: Онлайн-трафик начинает замедляться.

11:30 вечера: Начинается ежедневное резервное копирование базы данных и файловой системы.

12:00: Запускается пакетное задание для выполнения ежедневного согласования продаж.

12:30 вечера: Запускается еще одно пакетное задание для обработки заказов, созданных за последние 24 часа.

2:00: Запускается многоэтапное пакетное задание для обработки обратных заказов и отправки заказов магазина поставщикам.

3:00: Поскольку все невыполненные заказы были обработаны, запускается задание резервного копирования для резервного копирования базы данных и файловой системы.

5:00 утра: пакетное задание формирует и отправляет в бухгалтерию отчет о продажах за вчерашний день.

5:15 утра: Другое пакетное задание формирует и отправляет отчет об остатках товара на складе и в отдел закупок.

5:30 утра: Запускается сценарий для очистки старых файлов журнала и временных файлов.

7:00: Система снова начинает загружаться онлайн-трафиком.

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

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

Пакетные задания, основанные на времени, и пакетные задания, основанные на событиях

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

розничный магазин, выполняющий ежедневную консолидацию продаж

электроэнергетические компании, генерирующие ежемесячные счета

Банки, составляющие квартальные отчеты

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

Онлайн-запросы начали поступать в обычное время, но пакетная обработка бэкенда все еще запущена. Поскольку системные ресурсы, такие как процессор, память и IO, все еще заняты запущенными пакетными заданиями, рез

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

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

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

Клиент отправил заказ через Интернет

Была куплена новая SIM-карта для мобильного телефона

файл с удаленного сервера поступил для дальнейшей обработки.

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

С другой стороны, поскольку заметный объем работы по пакетной обработке освобождается во время событий, объем работы по пакетной обработке во время пакетного окна (например, ночного пакета), скорее всего, уменьшится.

Это конец для пакетной обработки?

Ходят разговоры о полной замене пакетной обработки, основанной на времени, на обработку, управляемую событиями в реальном времени, для создания так называемого предприятия реального времени. Группа людей утверждает, что пакетная обработка приводит к задержкам в бизнес-процессах, а поскольку решения, основанные на событиях, становятся доступными, предприятиям следует рассмотреть возможность полного перехода на событийно-ориентированную обработку в реальном времени. Этот подход обсуждается уже много лет. Однако он еще не полностью заменил пакетную обработку.

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

Бизнес также может стать более конкурентоспособным и получить дополнительную прибыль, если каждое отдельное событие будет обрабатываться в режиме реального времени. Например, компании мобильной связи предпочитают предоставлять каждую SIM-карту сразу после ее покупки, а не заставлять клиентов ждать до следующего дня (когда ночная пакетная обработка завершит обработку данных) и терять потенциальные звонки, которые могут быть оплачены за время ожидания.

Тематическое исследование: Commonwealth Bank of Australia переходит на банковское обслуживание в режиме реального времени

“В октябре 2010 года Commonwealth Bank of Australia объявил о своей будущей стратегии в области информационных технологий, а именно о постепенной модернизации своих банковских платформ для предоставления клиентам банковских услуг в режиме реального времени. Банковское обслуживание в режиме реального времени – это возможность открывать и закрывать счет, совершать кредитные и дебетовые операции, а также мгновенно менять функции. Банковское обслуживание в режиме реального времени устраняет задержку, которую мы испытываем сейчас из-за пакетной обработки, когда транзакции не завершаются до следующего рабочего дня. Банковские операции в режиме реального времени постепенно заменят пакетную обработку, поскольку наша новая банковская платформа заменит существующие системы в течение следующих нескольких лет”.

Ссылка с сайта Commonwealth Bank of Australia.

Однако обработка данных в режиме реального времени – это не серебряная пуля. Хотя приобретение решений реального времени становится все дешевле, перевод всей пакетной обработки организации на обработку в реальном времени может быть чрезвычайно дорогостоящим и рискованным проектом. Кроме того, мы можем обнаружить, что нынешние вычислительные технологии все еще недостаточно мощные, чтобы обрабатывать все в режиме реального времени. Некоторые ИТ-специалисты провели тест в ходе проекта. Они спроектировали систему так, чтобы она обрабатывала все в режиме реального времени, а когда рабочая нагрузка увеличилась, вся система просто рухнула. Мы знаем, что оборудование в наши дни становится все дешевле, но вычислительная мощность машины – не единственное ограничение. Когда мы говорим об ограниченности вычислительных ресурсов, это также может быть количество установленных сессий к базе данных или доступность информации для доступа. В случае большого запроса, например, создания отчета, может потребоваться эксклюзивный доступ к базе данных. Во время обработки данных в таблице они недоступны для изменения другими запросами. Поэтому такие запросы следует рассматривать как пакетную обработку и настраивать их на выполнение в соответствующее время.

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

Рон Шмельцер из ZapThink пишет:

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

При выполнении бизнес-процесса в режиме реального времени или пакетно, разработчик системы должен принять во внимание множество факторов, таких как:

Должен ли бизнес-процесс выполняться в режиме реального времени?

Какова будет стоимость выполнения бизнес-процесса в реальном времени?

Каковы негативные последствия для других при выполнении бизнес-процесса в режиме реального времени?

Оправдает ли выгода затраты и последствия?

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

Выполнение задач пакетной обработки

Чтобы лучше понять пакетную обработку, нам нужно начать с ее отца – компьютеров мэйнфреймов. Язык управления заданиями (JCL) был введен в качестве основного инструмента на компьютерах мэйнфреймов для определения того, как должна выполняться пакетная программа. JCL рассматривается как задание, которое также называется карточкой задания (унаследовав название от перфокарт). Задание может состоять из одного или нескольких шагов (до 255 шагов в каждом JCL), и каждый шаг представляет собой исполняемую программу или процедуру JCL (часто используемые операторы JCL определяются в процедуры для повторного использования). В JCL пользователю необходимо указать имя задания, программу или процедуру, которая будет выполняться на каждом шаге задания, а также входные и выходные данные шага. После того как задание отправлено на выполнение, подсистема ввода заданий (JES) интерпретирует JCL и отправляет его в операционную систему мэйнфрейма (MVS или Z/OS) для обработки (см. следующую схему).

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

Пакетная обработка может быть отдельной задачей, но в большинстве случаев бизнес-процессы требуют выполнения многих шагов. Технически все эти шаги могут быть объединены в рамках одного блока обработки (например, шаги с помощью JCL), но если во время обработки какой-то шаг не сработает, повторный запуск этого конкретного шага может оказаться сложной задачей. На мэйнфреймах существуют продукты сторонних производителей, предназначенные только для управления повторным запуском шагов JCL.

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

Вот пример пакетной обработки на примере Hello World. imagamingpc.com – это интернет-магазин компьютеров, специализирующийся на сборке игровых компьютеров на заказ. Владелец реализовал собственное приложение для обработки заказов в режиме онлайн. Система работает следующим образом:

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

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

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

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

Это очень простой пример пакетной обработки. Нетрудно понять, что шаг 2 – это обработка взаимодействия, а шаг 3 – пакетная обработка.

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

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

К 12:00 утра всего сгенерировано десять заказов. Программа PROCESS_ORDER настроена на срабатывание в это время дня для их обработки. Для каждого заказа программа сканирует инвентарь, чтобы убедиться, что каждый товар в заказе есть на складе, и создает файл под названием daily build list .

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

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

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

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

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

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

Автоматизация пакетной обработки

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

Для автоматизации сценариев JCL на мэйнфреймах были разработаны собственные наборы инструментов. Современные распределенные компьютерные системы также имеют некоторые общие возможности для автоматизации задач пакетной обработки. На компьютерах Unix или LINUX CRON – это утилита, предоставляемая как часть операционной системы для автоматизации запуска исполняемых файлов. Аналогичный инструмент в Windows называется планировщиком задач. С помощью этих инструментов пользователь может определить программы или сценарии для запуска в определенное время или через различные временные интервалы. Эти инструменты в основном используются для базовых потребностей планирования, таких как автоматизация резервного копирования в определенное время или обслуживание системы.

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

С годами крупные производители программного обеспечения разработали специальные коммерческие инструменты пакетного планирования, такие как BMC Control-M, чтобы удовлетворить растущие потребности в пакетной обработке. Эти инструменты предназначены для автоматизации сложных требований пакетной обработки, предлагая возможность инициировать выполнение заданий в соответствии с логическими зависимостями между ними.

Основные элементы задания

Как и в случае с CRON, от пользователя в первую очередь требуется определить каждую задачу пакетной обработки в инструменте пакетного планирования вместе с условиями ее запуска. Такие определения обычно называются “Определениями заданий”, которые хранятся и управляются инструментом планирования. В каждом определении задания есть три основных элемента:

Что запускать – физическое местоположение исполняемой программы в файловой системе.

Когда запускать – критерии планирования задания

Зависимости – предшественники и зависимые элементы задания.

Что запускать

С точки зрения инструмента пакетного планирования, ему необходимо знать, какой объект должен быть запущен. Это может быть JCL на мэйнфрейме, сценарий оболочки Unix, программа Perl или исполняемый файл Windows. Задание также может быть запросом к базе данных, хранимой процедурой, выполняющей поиск или обновление данных, или даже задачей передачи файлов. Существуют также объекты выполнения, специфичные для конкретного приложения, например, задания SAP или PeopleSoft.

Когда запускать (критерии планирования задания)

Каждое задание имеет свои критерии планирования, которые указывают инструменту пакетного планирования, когда задание должно быть отправлено на выполнение. Критерии планирования задания содержат дату и время выполнения задания. Задание может быть ежедневным, ежемесячным или ежеквартальным, или настроено на выполнение в определенную дату (например, в конце каждого месяца, когда нет выходных или праздничных дней). Задание также может быть настроено на выполнение через заданные интервалы времени (циклическое выполнение). В таких случаях в определении задания необходимо указать, как часто оно должно выполняться, и, по желанию, время начала его первого выполнения и время окончания последнего выполнения (например, с 15:00 до 21:00 выполнять задание каждые пять минут). Большинство заданий

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

один к одному

Один ко многим (с или без if-then, else)

Многие к одному (И/ИЛИ)

Взаимосвязь “один к одному” означает, что задания выполняются одно за другим, например, когда задание A завершено, начинается задание B.

Отношения “один ко многим” означают, что многие дочерние задания зависят от родительского задания, и как только родительское задание будет завершено, дочерние задания начнут выполняться. Иногда в нем присутствует определенная степень принятия решений, например, если код возврата задания A равен 1, то запускается задание B, или если код возврата задания A больше 1, то запускаются задания C и D.

Отношения “многие к одному” означают, что одно дочернее задание зависит от многих родительских заданий. Зависимость от завершения родительских заданий может быть отношением AND, OR, а также может быть AND и OR смешанным, например, в сценарии AND задание D будет выполняться только в том случае, если все задания A, B и C завершены. В сценарии ИЛИ задание D будет выполняться, если выполнено любое из заданий A, B или C. В смешанном сценарии задание D будет выполнено, если выполнено задание A или задание B и задание C.

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

Более продвинутые функции инструментов планирования

Под влиянием спроса со стороны бизнеса и пользователей современные инструменты планирования, помимо автоматизации выполнения пакетных заданий, оснащены более сложными функциями, такими как:

Возможность генерировать предупреждающее сообщение при возникновении ошибок

Возможность обработки внешних пакетных заданий, управляемых событиями

Интеллектуальное планирование – принятие решений на основе предварительно заданных конаций

Дополнительные функции отчетности, аудита и отслеживания истории

Возможность генерировать уведомления

Благодаря возможности генерировать уведомления по определенным событиям, операторы освобождаются от постоянного мониторинга 24*7 и должны контролировать задания только в исключительных случаях. Пользователи могут настроить правила таким образом, чтобы уведомление отправлялось при наступлении определенного события, например, когда задание не выполняется, задание начинается с опозданием или выполняется дольше, чем ожидалось. В зависимости от возможностей инструмента планирования, местом назначения уведомления может быть консоль оповещения, почтовый ящик или SMS на мобильный телефон. Некоторые инструменты планирования также имеют возможность интеграции со сторонними инструментами управления ИТ-услугами (ITSM) для автоматического создания билета на ИТ-инцидент. В оповещение может быть включена информация о задании, например, название задания, местоположение задания, причина сбоя и время сбоя.

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

Пакетные задания с четным управлением определяются таким образом, чтобы запускаться только тогда, когда произошло ожидаемое внешнее событие. Для того чтобы иметь такую возможность, в инструменте пакетного планирования разрабатываются специальные интерфейсы для обнаружения такого события. Обнаружение создания или прибытия файла является типичным интерфейсом для пакетного планирования по событию. Некоторые пакетные планировщики также предоставляют свой собственный интерфейс прикладного программирования (API) или имеют возможность действовать как веб-сервис или через очередь сообщений для приема внешнего запроса. Пользователю необходимо предварительно указать, какое событие должно быть инициировано, какое задание или действие в инструменте пакетного планирования и в течение какого периода времени. Таким образом, в течение определенного периода времени планировщик будет прослушивать событие и запускать соответствующее задание или действие. Внешние события иногда могут быть непредсказуемыми, и это может произойти в любое время. Инструменты пакетного планирования также должны иметь возможность ограничивать количество одновременно выполняемых пакетных заданий, запускаемых по событию, чтобы предотвратить перегрузку машины в пиковые периоды времени.

Интеллектуальное планирование – принятие решений на основе заранее определенных условий

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

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

Запустить задание B, если на выходе задания A есть сообщение Обработка завершена, или запустить задание C, если на выходе задания A есть сообщение Обработка завершена с предупреждением

Пропустить задание C, если задание B не завершено к 17:00.

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

В целях информационной безопасности файлы, находящиеся в компьютерной системе, обычно защищены правами доступа. Скрипт или исполняемый файл должен быть запущен под соответствующим пользователем или группой, чтобы читать файлы в качестве входных данных и записывать в файл в качестве выходных. В случае работы с базой данных или FTP информация для входа в систему должна быть записана в сценарий для аутентификации во время выполнения. Людям, управляющим пакетной обработкой, требуется полный доступ к учетным записям пользователей для запуска сценария или исполняемого файла, что означает, что они также будут иметь доступ к данным, которые им не разрешено видеть. Существует также риск того, что люди с правами доступа пользователей могут изменять и выполнять исполняемые файлы без разрешения. Инструменты пакетного планирования устранили эту проблему, предоставив дополнительные функции безопасности, начиная с перспективной пакетной обработки, то есть обеспечили аутентификацию пользователей для доступа к консоли пакетного планирования и сгруппировали пользователей по различным уровням привилегий в соответствии с их должностной ролью. Например, пользователи из группы разработки приложений имеют право определять и изменять задания, пользователи из группы эксплуатации имеют право запускать или перезапускать задания, а некоторые сторонние пользователи могут иметь права только на мониторинг определенной группы заданий.

Дополнительные функции отчетности, аудита и отслеживания истории

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

Централизованное планирование на предприятии

Оглядываясь на 20 лет назад, можно сказать, что технологии выросли до невообразимых пределов, но потребности в пакетной обработке не уменьшились. Согласно отчету Gartner “Магический квадрант планирования заданий 2009”, 70 процентов бизнес-процессов выполняются в пакетном режиме. В том же отчете Gartner прогнозирует ежегодный рост рынка планирования заданий на 6,5 процентов в будущем.

Проблемы современной пакетной обработки данных

Пакетные задания с четным управлением определяются таким образом, чтобы запускаться только тогда, когда произошло ожидаемое внешнее событие. Для того чтобы иметь такую возможность, в инструменте пакетного планирования разрабатываются специальные интерфейсы для обнаружения такого события. Обнаружение создания или прибытия файла является типичным интерфейсом для пакетного планирования по событию. Некоторые пакетные планировщики также предоставляют свой собственный интерфейс прикладного программирования (API) или имеют возможность действовать как веб-сервис или через очередь сообщений для приема внешнего запроса. Пользователю необходимо предварительно указать, какое событие должно быть инициировано, какое задание или действие в инструменте пакетного планирования и в течение какого периода времени. Таким образом, в течение определенного периода времени планировщик будет прослушивать событие и запускать соответствующее задание или действие. Внешние события иногда могут быть непредсказуемыми, и это может произойти в любое время. Инструменты пакетного планирования также должны иметь возможность ограничивать количество одновременно выполняемых пакетных заданий, запускаемых по событию, чтобы предотвратить перегрузку машины в пиковые периоды времени.

Запустив пакетную обработку на одной машине и в одном приложении, мы получили ИТ-среду с сотнями или тысячами машин. Некоторые из этих машин работают в качестве сервера базы данных или хранилища данных под управлением Oracle, Sybase и MS SQL Server. Некоторые другие машины могут использоваться исключительно для выполнения ETL-заданий от Informatica или Datastage. Есть также машины, которые являются выделенными файловыми серверами для отправки и получения файлов в соответствии с определенным событием. Также существуют приложения резервного копирования, выполняющие задачи архивирования данных во всей ИТ-среде. Кроме того, у нас все еще есть компьютеры мэйнфреймов, на которых работают устаревшие приложения, нуждающиеся в интеграции с приложениями в распределенной среде.

В большей или меньшей степени эти машины будут иметь свои собственные пакетные задания, выполняемые для удовлетворения определенных потребностей. Не только это, приложения, которые специализируются в определенной области, также могут требовать пакетной обработки. Некоторые из этих приложений, такие как PeopleSoft Finance и SAP R/3, должны были иметь встроенную функцию пакетного планирования для удовлетворения собственных требований к пакетной обработке.

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

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

Давайте вернемся к примеру с imagamingpc.com:

По мере того как пакетная обработка разбивалась на отдельные задания, качество обслуживания клиентов стало улучшаться, а сайт становился все более загруженным. Через шесть месяцев среднее количество заказов в день выросло до 300! Владелец бизнеса был счастлив, но ИТ-специалист был немного обеспокоен; он вкратце описал владельцу бизнеса следующие проблемы:

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

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

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

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

Переместить базу данных инвентаризации на новую машину (машина B), отдельно от веб-сервера (машина A), чтобы уменьшить использование ресурсов.

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

Чтобы сохранить данные в безопасности, после завершения обработки создайте резервную копию всех данных на ленту.

Владелец бизнеса согласен с таким подходом. Во время внедрения новой среды ИТ-специалист столкнулся с новой проблемой. Теперь пакетные задания разделены для выполнения на разных машинах. Возникает проблема синхронизации, то есть, когда взаимосвязанные задания не находятся на одной машине, как нисходящие задания узнают, что их родительское задание (задания) завершено? ИТ-специалист использовал подход, основанный на согласовании времени, то есть определил временные рамки для выполнения каждого шага. Последовательность выполнения задания следующая:

12:00 до 1:00: FTP-заказ генерируется в течение дня с машины A на машину C .

С 1:00 утра до 1:30 утра: машина C вводит список сборки в базу данных.

С 1:30 до 2:00: запуск “PROCESS_ORDER” на машине C .

С 2:00 до 2:15: MAIL_CONFRIMED_ORDER выполняется на машине C .

2:15 – 2:30: машина C выполняет PRINT_DAILY_BUILD_LIST .

С 2:30 до 3:00: UPDATE_INVENTORY запускается машиной C .

С 3:00 до 3:30: машина B запускает GENERATE_BACKORDER_LIST .

С 3:30 до 4:00 утра: машина B запускает MAIL_BACKORDER .

С 4:00 утра до 5:00 утра: машина D запускает RUN_BACKUP для резервного копирования данных на машинах B и C.

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

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

длина пакетного окна

Мониторинг и управление пакетами

Планирование в разных часовых поясах

Обслуживание и устранение неполадок

Реагирование на изменения

Время обработки

При использовании метода согласования времени весь пакетный поток будет выполняться дольше из-за разрыва во времени между выполнением заданий. Дочернее задание (задания) не сработает до наступления запланированного времени, даже если родительское задание (задания) завершилось раньше или в среднее время завершения. В крайних случаях родительское задание может выполняться сверх отведенного времени, что означает, что дочернее задание будет запущено в соответствии с заданным временем, в то время как родительское задание все еще выполняется. Это может привести к серьезному сбою и потребовать отката данных и сброса задания (заданий) оверлея, чтобы вернуться в исходное состояние. Как следствие, общая продолжительность выполнения пакетного потока увеличится с риском выполнения дольше, чем предварительно согласованное пакетное окно. Это крайне неблагоприятно при текущей тенденции, когда время обработки увеличивается, а пакетное окно сокращается.

Длина пакетного окна

В традиционном сценарии пакетное окно выделяется ночью, когда активность в сети низкая. У системы есть достаточно времени для выполнения пакетных заданий и восстановления после ошибок до того, как активность в сети снова возрастет на следующее утро. С развитием Интернета организации получили возможность расширять свой бизнес, предлагая продукты и услуги по всему миру. Это требует, чтобы компьютерная система была почти 24 часа доступна для обработки онлайн-запросов из разных часовых поясов, и поэтому оставляет очень мало места для пакетной обработки.

Мониторинг и управление пакетной обработкой

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

Планирование в разных временных зонах

В условиях глобализации часто можно увидеть, что бизнес работает во многих странах. Офисы продаж расположены в Северной Америке и Европе, производственные офисы – в Азии, а центры поддержки клиентов – в Южной Америке. Каждая из этих точек не работает сама по себе, и более чем вероятно, что им необходимо обмениваться большим количеством данных между собой, следовательно, будут существовать бизнес-процессы, требующие пакетной обработки в разных регионах, которые должны выполняться один за другим. Из-за разного времени работы и разной географии, планирование между временными зонами оказывается чрезвычайно трудновыполнимым с помощью подхода совмещения времени. Это также увеличивает

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

Длина пакетного окна

В многоплатформенной среде каждая система или приложение, скорее всего, будет управляться отдельными командами, которые специализируются в своих областях. Поскольку каждое пакетное задание находится на разных машинах в разных отделах, на поиск точки сбоя могут уйти часы. Например, в 2:00 ночи запускается задание по составлению отчетов и сразу же выходит из строя. Ответственный за отчетность быстро проверяет причину проблемы и обнаруживает, что родительское задание тоже не сработало в 1:50 утра. Родительским заданием был сценарий базы данных, вставляющий данные из CSV-файлов, которые должны были прийти в 1:30 утра. Поэтому DBA выясняет у человека, ответственного за создание файла, что происходит, и даже может выясниться, что сбой задания вызван кем-то на другом конце света. К тому времени, когда они выяснят изначальную проблему, будет уже слишком поздно, чтобы позволить повторному запуску завершиться в рамках SLA.

В традиционном сценарии пакетное окно выделяется ночью, когда активность в сети низкая. У системы есть достаточно времени для выполнения пакетных заданий и восстановления после ошибок до того, как активность в сети снова возрастет на следующее утро. С развитием Интернета организации получили возможность расширять свой бизнес, предлагая продукты и услуги по всему миру. Это требует, чтобы компьютерная система была почти 24 часа доступна для обработки онлайн-запросов из разных часовых поясов, и поэтому оставляет очень мало места для пакетной обработки.

Отчетность

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

Реагирование на изменения

Бизнес-среда не всегда остается неизменной. Изменения, внесенные в бизнес, могут кардинально повлиять на работу ИТ. Подумайте о таких ситуациях, как слияние компаний. Без общего представления всей пакетной среды с точки зрения бизнес-процессов, а также при отсутствии стандартизации и документации, ИТ будет сопротивляться переходу бизнеса. Даже при таких небольших бизнес-событиях, как маркетинговая кампания, пакетные задания могут выполняться дольше обычного, чтобы обработать дополнительный объем данных. Например, когда национальный розничный магазин открыт на 24 часа в рождественский период, машине требуется больше ресурсов, чтобы справиться с онлайн-транзакциями. Если пакетные задания размещаются на многих платформах, то потребуется множество ручных модификаций, чтобы учесть временные изменения.

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

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

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

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

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

Время обработки и использование ресурсов

Мониторинг и управление пакетами

Планирование работы в разных временных зонах

Обслуживание и устранение неисправностей

Реагирование на изменения

Время обработки и использование ресурсов

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

Мониторинг и управление пакетами

Мы часто слышим от старших ИТ-специалистов рассказы о “старых добрых временах” – операторы пакетного планирования имели список всех заданий, которые должны были быть выполнены в этот день, а также список машин, на которых эти задания находились. Им приходилось вручную заходить на каждую машину, чтобы проверить состояние завершения соответствующего задания, затем заходить на другую машину, чтобы выполнить следующее задание. Централизованное планирование позволило пользователям контролировать и управлять межплатформенными пакетными заданиями из единой точки управления. Пользователям больше не нужно определять, какое задание должно выполняться следующим, глядя в электронную таблицу, поскольку задания, относящиеся к одному бизнес-процессу, группируются в визуализированный пакетный поток. Пользователи могут точно видеть, на каком этапе находится выполнение в пакетном потоке. Централизованное планирование также обеспечивает единый интерфейс управления заданиями. Людям, отвечающим за управление пакетными заданиями, больше не нужно обладать глубокими знаниями о среде выполнения заданий, чтобы выполнить такие простые задачи, как повторный запуск задания, отложить выполнение задания или развернуть новое задание.

В традиционном сценарии пакетное окно выделяется ночью, когда активность в сети низкая. У системы есть достаточно времени для выполнения пакетных заданий и восстановления после ошибок до того, как активность в сети снова возрастет на следующее утро. С развитием Интернета организации получили возможность расширять свой бизнес, предлагая продукты и услуги по всему миру. Это требует, чтобы компьютерная система была почти 24 часа доступна для обработки онлайн-запросов из разных часовых поясов, и поэтому оставляет очень мало места для пакетной обработки.

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

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

Мониторинг и управление пакетами

Мы часто слышим от старших ИТ-специалистов рассказы о “старых добрых временах” – операторы пакетного планирования имели список всех заданий, которые должны были быть выполнены в этот день, а также список машин, на которых эти задания находились. Им приходилось вручную заходить на каждую машину, чтобы проверить состояние завершения соответствующего задания, затем заходить на другую машину, чтобы выполнить следующее задание. Централизованное планирование позволило пользователям контролировать и управлять межплатформенными пакетными заданиями из единой точки управления. Пользователям больше не нужно определять, какое задание должно выполняться следующим, глядя в электронную таблицу, поскольку задания, относящиеся к одному бизнес-процессу, группируются в визуализированный пакетный поток. Пользователи могут точно видеть, на каком этапе находится выполнение в пакетном потоке. Централизованное планирование также обеспечивает единый интерфейс управления заданиями. Людям, отвечающим за управление пакетными заданиями, больше не нужно обладать глубокими знаниями о среде выполнения заданий, чтобы выполнить такие простые задачи, как повторный запуск задания, отложить выполнение задания или развернуть новое задание.

Поскольку задания управляются и планируются из центра

В традиционном сценарии пакетное окно выделяется ночью, когда активность в сети низкая. У системы есть достаточно времени для выполнения пакетных заданий и восстановления после ошибок до того, как активность в сети снова возрастет на следующее утро. С развитием Интернета организации получили возможность расширять свой бизнес, предлагая продукты и услуги по всему миру. Это требует, чтобы компьютерная система была почти 24 часа доступна для обработки онлайн-запросов из разных часовых поясов, и поэтому оставляет очень мало места для пакетной обработки.

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

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

Она может планировать задания на различных системных платформах и предоставлять централизованную консоль мониторинга и управления с графическим интерфейсом, такими системными платформами являются (но не обязательно) мэйнфрейм, AS/400, Tandem, Unix, Linux и Microsoft Windows.

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

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

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

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

Мониторинг и управление пакетами

Некоторая степень интеграции с приложениями (например, ERP, финансовыми приложениями).

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

Функции безопасности и аудита.

Интеграция с ITSM (управление ИТ-услугами).

От пакетного планирования к автоматизации рабочих нагрузок

Сегодня пакетное планирование превратилось из одноплатформенной автоматизации в межплатформенное и межприкладное планирование. Широкие возможности, предоставляемые инструментами, эффективно снизили сложность мониторинга и управления пакетным планированием. Кажется, что все необходимое для пакетного планирования доступно, и пользователи довольны. Однако история говорит нам, что в ИТ ничто не остается неизменным; технологии должны расти и совершенствоваться, иначе их заменяют другие, более новые и лучшие технологии, и пакетное планирование не является исключением.

В Магическом квадранте Gartner по планированию заданий издания 2009 года в самом начале говорится: “Планирование заданий, зрелый рынок, претерпевает трансформацию в сторону технологии IT Workload Automation Broker”.

Ссылка – Магический квадрант Гартнера по планированию заданий 2009 .

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

Пакетное планирование: Статическое планирование

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

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

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

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

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

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

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

Добавление дополнительных вычислительных ресурсов еще больше усложнит и без того перегруженную ИТ-среду.

Технология IT Workload Automation Broker (ITWAB) была первоначально представлена компанией Gartner в 2005 году. Она была разработана для преодоления статического характера планирования заданий, позволяя управлять пакетными заданиями как рабочими нагрузками в соответствии с бизнес-политикой и соглашением об обслуживании. Следуя этому стандарту, пакетная обработка должна стать более гибкой, а значит, сможет воспользоваться преимуществами технологии виртуализации и стать ресурсоориентированной, чтобы иметь возможность динамически распределять рабочую нагрузку на основе использования ресурсов во время выполнения. Пакетная обработка также должна расширить свои возможности поверх существующей пакетной обработки с триггером событий, приняв подход сервис-ориентированной архитектуры (SOA) для повторного использования и предлагая стандартный интерфейс интеграции для внешних систем.

Динамическая пакетная обработка с использованием технологии виртуализации и облачных вычислений

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

Облачные вычисления продвинули технологию виртуализации еще на один шаг вперед, обеспечив возможность динамического управления виртуальными ресурсами в соответствии с требованиями реального времени. Когда ИТ перешли к облачным вычислениям, подход к автоматизации рабочих нагрузок позволил инструменту пакетного планирования использовать “неограниченный запас” вычислительных ресурсов. При таком подходе вместо определения заданий для выполнения на статичном узле, задания группируются в рабочую нагрузку, которая назначается на любой узел выполнения заданий без необходимости изменять исходное определение задания. Таким образом, платформа пакетного планирования может свободно распределять работу по обработке на виртуальные ресурсы в облаке в соответствии с рабочей нагрузкой. В сценариях, когда существующие узлы выполнения заданий достигают предела использования, инструмент планирования может просто запросить новые виртуальные ресурсы в облаке и направить на них дополнительную рабочую нагрузку. Для пакетной обработки, основанной на времени, такой подход всегда гарантирует наличие достаточного количества вычислительных ресурсов, чтобы пакетная обработка могла завершиться в пределах окна пакета. При пакетной обработке на основе событий пакетные запросы, генерируемые случайными внешними событиями, всегда могут обрабатываться немедленно без очереди.

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

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

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

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

В предыдущей части этой главы мы обсуждали, может ли система реального времени полностью заменить пакетную обработку. Пакетная обработка может оправдать свое существование благодаря своей высокой производительности, когда речь идет об обработке больших объемов данных. Между пакетной обработкой и обработкой в реальном времени всегда существовал разрыв. Событийно-триггерное планирование было разработано для устранения этого разрыва, чтобы пакетная обработка могла запускаться запросами реального времени. Но из-за своей статичности событийно-триггерное планирование с трудом справляется с современными динамичными требованиями ИТ.

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

При подходе к автоматизации рабочих нагрузок пакетная обработка определяется политикой, становясь динамическим компонентом приложения для обслуживания бизнес-потребностей в режиме реального времени. Применяя принципы проектирования сервис-ориентированной архитектуры (SOA), пакетный поток может быть запущен по требованию как единый многократно используемый сервис, слабо связанный со своими потребителями.

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

Ссылка на Википедию – Сервис-ориентированная архитектура.

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

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

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

Резюме

Отлично. Мы завершили первую главу! Это было интересное путешествие через историю назад в будущее, то есть от начала пакетной обработки до сегодняшних новейших технологий. Как всегда говорят, для всего есть причина, и лучший способ понять ее цель – это понять историю. К этому моменту вы должны хорошо понимать концепцию пакетной обработки и централизованного планирования на предприятии – какие были проблемы и почему они существуют сегодня. Кроме того, мы также получили общее представление о новейшей концепции – автоматизации рабочей нагрузки.

Позже в этой книге вы увидите, как решаются эти проблемы и как достигается идеальная концепция автоматизации рабочей нагрузки в удивительной функции Control-M. Оставайтесь с нами! Мы вот-вот дадим старт настоящей игре!

Цян Динг (Мельбурн, Австралия) работает в сфере Control-M уже более четверти своей жизни. В первые годы работы в BMC Software Цян решал бесчисленное количество критических технических проблем для клиентов Control-M по всему миру – от компаний из списка Fortune 500 до правительственных организаций. В последние годы Цян преодолел сотни тысяч миль по Австралии и Северному региону АТР, чтобы помочь многим организациям в разработке, управлении и оптимизации среды автоматизации пакетных рабочих нагрузок и передать свою страсть другим, проводя тренинги по Control-M для конечных пользователей и партнеров BMC. В настоящее время Цян временно живет в Сиднее и работает над проектом по миграции и консолидации Control-M в масштабах предприятия для крупного австралийского банка. Ему нравится работать с другими экспертами в этой области, и он постоянно участвует в поиске путей для внесения улучшений в пакет.