Обратный отсчет до второго тысячелетия

"Проблема 2000 года" реальна. А ваша телекоммуникационная инфраструктура на нуле. Время уходит.

Вы слышали об этом. Вы видели передачи по ТВ. За время между написанием этой статьи в конце 1998 года и 1 января 2001 года множество компьютерных систем выйдет из строя в результате ошибок при обработке даты/времени.

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

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

Результат — директора ИС вынуждены работать по выходным, а программисты на COBOL стали пользоваться невероятным спросом по всему миру. Как будто ниоткуда возник прибыльный рынок программного инструментария типа декомпиляторов, синтаксических анализаторов и т. п. для решения проблемы Y2K. Десятки консультантов заполнили образовавшийся спрос на знания и специалистов. До 2001 года, по оценкам Gartner Group, около 600 млрд долларов будет потрачено во всем мире на идентификацию, исправление, тестирование и переустановку унаследованного кода, написание совершенно нового кода, переформатирование баз данных и полную замену унаследованных систем — в целях решения проблемы 2000 года. Все эксперты соглашаются с тем, что, несмотря на все усилия и затраты, некоторые компании так и не успеют к положенному сроку.

Но что если вы не используете в своем бизнесе мэйнфреймы с кодом на COBOL 30-летней давности? К сожалению, это не избавляет вас от опасности.

ЗАБЫТЫЙ ЗНАКОМЫЙ

Полночь, 1 января 2000 года. Вы потягиваете "Вдову Клико" в кругу семьи, и вдруг ваша телефонная система начинает сыпать искрами. Добро пожаловать в ад.

УАТС может решить, что наступил 1980 год, и вследствие этого начнет выдавать записи SMDR. Система учета звонков/управления отелем примет данные записи на обработку и попытается выставить постояльцам отеля счета за "разговоры продолжительностью минус двадцать лет" (или, что более вероятно, отвергнет транзакции и не сумеет выставить по ним счет). В то же время система интерактивного голосового ответа станет неправильно записывать время транзакции или откажется воспринимать правильно вводимую звонящими дату. Системы голосовой почты возьмутся стирать новые сообщения, решив, что сообщения с отметкой о времени 00 устарели уже на сто лет. Некоторые приложения попытаются произвести вычисления, используя странные интервалы времени, получат непонятные результаты (например, отрицательную продолжительность звонка) и выйдут из строя. Компьютеры перестанут загружаться, поскольку их операционные системы решат, что выполняются на отжившем свой век оборудовании.

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

Все это выглядит пугающе.

КАК ЭТО ВОЗМОЖНО?

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

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

Часовые/календарные компоненты. Часовые/календарные подсистемы являются важными составляющими многих электронных продуктов, таких, как видеомагнитофоны. Некоторые часовые/календарные системы выдают время в формате наручных часов — с представлением года с помощью двух цифр.

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

Программное обеспечение BIOS. Базовая система ввода/вывода (Basic Input/Output System, BIOS), включая системный код "начальной загрузки", представляет собой самый нижний уровень программного обеспечения, управляющего ПК или другими устройствами с ЦПУ. Одна из функций BIOS в современных ПК состоит в расчете текущего времени (на основании данных источника реального времени) и сообщении его операционной системе и приложениям. Значительная доля BIOS в ПК (по некоторым оценкам, до 15% всех используемых систем) не в состоянии корректно обработать смену тысячелетия, если переход произойдет, когда питание ПК отключено. При включении ПК 1 января 2000 года BIOS решит, что наступил 1900 год или начнет отсчет времени со "дня рождения BIOS" — обычно с 1980 г. Это может иметь последствия для всего программного обеспечения в системе (ОС и приложений) и привести к путанице в датировке файлов или вызвать другие серьезные проблемы, в частности невозможность загрузки.

Операционные системы. Все широко используемые операционные системы ПК (все версии MS-DOS, Windows 3.1, Windows for Workgroups и Windows NT вплоть до версии 3.51, до появления Service Pack 5) воспринимают и хранят четырехзначные даты при системном учете времени. Однако каждая из этих ОС по-прежнему испытывает те или иные проблемы с обработкой дат. Windows File Manager, например, будет неправильно указывать дату создания и изменения файлов после 2000 года. Кроме того, ни одна из вышеназванных ОС не способна правильно обнаруживать и исправлять ошибки "плохих BIOS", если таковые встречаются (см. выше). Эта функциональность предлагается в последующих версиях Windows 95/ NT.

Инструментарий разработки приложений, DLL, библиотеки реального времени, клиент-серверные механизмы и т. п. Потенциально это наиболее серьезные источники проблемы. Большинство современных инструментов разработки и серверных компонентов могут корректно хранить и манипулировать четырехзначными датами. Однако программисты до сих пор пишут внешние интерфейсы, принимающие ввод даты года в виде двух цифр и заставляющие свои внутренние системы разрешать их. Используемые при этом методы и допущения не стандартизованы и, что еще хуже, изменяются от версии к версии системы разработки и ее вспомогательных компонентов. Например, получив 99 как часть переменной Date, версии Visual Basic до 7 преобразуют 99 в соответствии с кодом в 1999 (спецификация VBRUNXXX.DLL). Однако текущая версия, где задействуются библиотеки автоматизации OLE для определения дат, узнает столетие на основании показаний системных часов, так что ввод 99 преобразуется в 1999 до 2000 года и в 2099 после него. Такой подход имеет смысл, если только ваш программист не позабудет учесть это при разработке системы.

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

ТОЧКА ОТСЧЕТА

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

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

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

3. Несмотря на то что большая часть современного телефонного оборудования (УАТС, голосовая почта) разрабатывается на базе компонентов для ПК, вопросы стоимости, амортизации и т. п. не позволяют отказаться от прежних архитектур. Системы голосовой почты на базе DOS по-прежнему остаются весьма популярны. Компактные мини-АТС могут быть построены на базе 386-х микропроцессоров (и BIOS старых моделей). Возникающие с такими продуктами проблемы нельзя будет решить "прозрачным образом" посредством быстрой модернизации, как это имеет место в случае настольного оборудования на базе ПК.

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

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

6. Значительная часть "прикладного программного обеспечения" связи (от систем учета звонков до развитых сервисных платформ) была написана с использованием Visual Basic, Visual C++, SQL Server, Access и другого инструментария разработки, у которого — в текущих версиях — известны проблемы.

Еще более усложняет неразбериху тот факт, что отрасль связи в целом весьма медленно реагирует на чрезвычайные ситуации. При введении нового североамериканского плана нумерации (North American Numbering Plan, NANP) многие владельцы УАТС не обеспокоились их модернизацией, пока, во-первых, конечные пользователи не стали жаловаться, что они не могут связаться с абонентами при наборе правильного кода города, или, во-вторых, производители УАТС не снизили стоимость модернизации почти до нуля.

ЧТО ДЕЛАТЬ?

Прежде всего, не паниковать. Однако сидеть и ждать, сложа руки, тоже не стоит. Ниже мы предлагаем примерный план подготовки к смене тысячелетия.

1. Если вы еще не сделали этого, воспользуйтесь данным поводом для подключения к Internet. Web содержит множество источников информации по вопросам Y2K, а электронная почта представляет собой важное средство общения с поставщиками.

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

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

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

3. Составьте перечень проблемных компонентов в порядке убывания их "коэффициента катастрофичности последствий" и займитесь наиболее приоритетными из них (см. также врезку "Проблемные места — с чего начать?").

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

5. Позвоните всем своим поставщикам и спросите у них о готовности их оборудования к 2000 году или, в случае отрицательного ответа, о том, что требуется сделать для его подготовки. Не удивляйтесь, если вас будут переадресовывать от одного должностного лица к другому. Вряд ли кто из поставщиков не знает о проблеме Y2K, но многие еще не выработали четкой политики в отношении того, как будет осуществляться необходимая модернизация/замена и сколько она будет стоить. Некоторые не способны ее решить без полной замены плат ЦПУ и/или программного обеспечения. Другие ограничиваются предоставлением заплат только для последних версий программного обеспечения.

6. Проведите ревизию ключевых систем на базе ПК с компонентами от разных поставщиков (например, корпоративной системы обмена сообщениями). Составьте последовательный план тестирования и обновления в соответствии с рекомендациями всех ключевых производителей. По возможности, данный план не должен включать такие меры, как отключение системы, перевод часов BIOS и... "посмотрим, что случится", так как это может привести к непредсказуемым последствиям.

7. Следуйте рекомендациям отдела ИС и поставщиков по модернизации "автономных" ПК, систем анализа записей о звонках, баз данных и других компонентов инфраструктуры.

8. Установите диалог с оператором связи, провайдером Internet и другими провайдерами, а также со своим сервисным бюро. Обратите особое внимание на интерфейс ввода дат, услуги учета вызовов оператора связи, каналы SMDI с периферией Centrex и форматы данных в счетах на базе CD.

Проблемные места - с чего начать?

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

• Телефонная система. Уязвима вследствие проблем ОС с интерпретацией "неверной даты BIOS", общими системными ошибками, неумением периферийных систем управления правильно интерпретировать дату. Может привести к появлению испорченных записей SMDR.
• Автоматическое распределение вызовов. Все вышеназванные проблемы плюс другие с маршрутизацией и планированием, управляющими терминалами, подсистемами анализа и учета.
• Усовершенствованные сервисные платформы и сервисы (например, международный обратный звонок). Все вышеназванные проблемы плюс серьезные проблемы с порчей баз данных и подсистем составления счетов.
• Интерфейсы управления имуществом. Как и выше.
• Системы обнаружения ответа (часто устанавливаемые между УАТС и станциями управления телефонной системой). Все, из-за чего данные SMDR могут оказаться испорчены.
• Оборудование и услуги учета звонков. Порча баз данных, неверная интерпретация SMDR, ошибочный анализ.
• Голосовая почта. Крах системы (как в случае ПК). Неверные отметки о времени. Сбой резервного копирования. Накопление неверных записей.
• Интерактивный голосовой ответ. Многочисленные аномалии. Наибольший риск —порча данных транзакций.
• Защита питания. Системы управления ИБП могут выйти из строя и не подлежать модернизации.
• Автоматические системы резервирования. Неверная обработка данных может привести к их полной потере.

Как проверить свой ПК?

Ниже мы предлагаем быстрый метод проверки ПК на совместимость с 2000 годом на уровне BIOS.

1. Создайте загружаемый системный диск MS-DOS.

2. Перезагрузите систему, используя этот диск. После загрузки система выдаст запрос A>.

3. С помощью команды date задайте дату 31.12.99, а с помощью команды time введите время 23:55:00.

4. Отключите систему и подождите десять минут.

5. Перезагрузитесь с дискеты. Проверьте дату и время. Если дата неверна (например, 1980 или другой), то у вас проблемы.

Чтобы определить их серьезность, выполните второй тест.

1. Задайте дату и время равными 01.01.2000 (с использованием четырехзначного представления года) и 00:05:00 (т. е. пять минут пополуночи).

2. Выключите систему и подождите пять минут.

3. Перезагрузитесь и проверьте дату и время. Некоторые BIOS не способы правильно определить время, если они были отключены при смене тысячелетия, но они будут правильно его определять при последующих отключениях.

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