Устаревшие компьютерные системы и приложения

Введение

Старые вычислительные технологии или система, которые остаются в использовании.

В вычислительной технике устаревшая система – это старый метод, технология, компьютерная система или прикладная программа, «относящаяся к предыдущей или устаревшей компьютерной системе», но всё ещё используемая. Часто упоминание системы как «устаревшей» означает, что она заложила основу для последующих стандартов. Это также может подразумевать, что система устарела или нуждается в замене. Устаревший код (legacy code) – это старый исходный код компьютера, который больше не поддерживается на стандартном оборудовании и в стандартных средах, и представляет собой кодовую базу, которая в некотором отношении устарела или поддерживает что-то устаревшее. Устаревший код может быть написан на устаревших языках программирования, использовать устаревшие фреймворки и внешние библиотеки, или использовать архитектуру и шаблоны, которые больше не считаются современными, что увеличивает когнитивную нагрузку и время на освоение для разработчиков, работающих с этой кодовой базой. Устаревший код может иметь недостаточное или полное отсутствие автоматизированных тестов, что делает рефакторинг опасным и повышает вероятность внесения ошибок. Долгоживущий код подвержен «разложению» программного обеспечения, когда изменения в среде выполнения или в окружающем программном обеспечении или оборудовании могут потребовать обслуживания или эмуляции для продолжения работы. Устаревший код может быть необходим для поддержки устаревшего оборудования, отдельной устаревшей системы или устаревшего клиента, использующего старую функцию или версию программного обеспечения. Хотя термин обычно относится к исходному коду, он также может применяться к исполняемому коду, который больше не запускается на более поздней версии системы или требует слоя совместимости для этого. Примером может служить классическое приложение Macintosh, которое не будет работать непосредственно на macOS, но будет работать в среде Classic, или приложение Win16, работающее на Windows XP с использованием функции Windows on Windows в XP. Примерами устаревшего оборудования являются устаревшие порты, такие как PS/2 и VGA, а также процессоры со старыми, несовместимыми наборами инструкций (например, с новыми операционными системами). Примеры устаревшего программного обеспечения включают устаревшие форматы файлов, такие как swf для Adobe Flash или .123 для Lotus 1-2-3, и текстовые файлы, закодированные с использованием устаревших кодировок символов, таких как EBCDIC.

In computing, a legacy system is an old method, technology, computer system, or application program, "of, relating to, or being a previous or outdated computer system", yet still in use. Often referencing a system as "legacy" means that it paved the way for the standards that would follow it. This can also imply that the system is out of date or in need of replacement. Legacy code is old computer source code that is no longer supported on the standard hardware and environments, and is a codebase that is in some respect obsolete or supporting something obsolete. Legacy code may be written in programming languages, use frameworks and external libraries, or use architecture and patterns that are no longer considered modern, increasing the mental burden and ramp up time for software engineers who work on the codebase. Legacy code may have zero or insufficient automated tests, making refactoring dangerous and likely to introduce bugs. Long lived code is susceptible to software rot, where changes to the runtime environment, or surrounding software or hardware may require maintenance or emulation of some kind to keep working. Legacy code may be present to support legacy hardware, a separate legacy system, or a legacy customer using an old feature or software version. While the term usually refers to source code, it can also apply to executable code that no longer runs on a later version of a system, or requires a compatibility layer to do so. An example would be a classic Macintosh application which will not run natively on macOS, but runs inside the Classic environment, or a Win16 application running on Windows XP using the Windows on Windows feature in XP. An example of legacy hardware are legacy ports like PS/2 and VGA ports, and CPUs with older, incompatible instruction sets (with e. g. newer operating systems). Examples in legacy software include legacy file formats like swf for Adobe Flash or .123 for Lotus 1 2 3, and text files encoded with legacy character encodings like EBCDIC.

Проблемы, связанные с устаревшими вычислениями

Некоторые инженеры-программисты считают устаревшие системы потенциально проблемными по ряду причин. Если устаревшее программное обеспечение работает только на устаревшем оборудовании, стоимость его поддержки может в конечном итоге превысить стоимость замены как программного обеспечения, так и аппаратного обеспечения, если только не будет применена эмуляция или обратная совместимость, позволяющая программному обеспечению работать на новом оборудовании. Такие системы сложно поддерживать, улучшать и расширять из-за общего недостатка понимания их устройства: сотрудники, которые были экспертами в этой области, вышли на пенсию или забыли свои знания, а новые специалисты никогда не изучали эти системы. Это может усугубляться отсутствием или утратой документации. В 2004 году авиакомпания Comair уволила своего генерального директора из-за сбоя в работе устаревшей системы планирования работы экипажа, столкнувшейся с неизвестным ранее ограничением. Устаревшие системы могут содержать уязвимости в старых операционных системах или приложениях из-за отсутствия доступных или установленных обновлений безопасности. Также могут существовать производственные конфигурации, создающие проблемы с безопасностью. Эти факторы могут подвергнуть устаревшую систему риску компрометации со стороны злоумышленников или осведомленных инсайдеров. Интеграция с новыми системами также может быть затруднена, поскольку новое программное обеспечение может использовать совершенно иные технологии. Интеграция между различными технологиями – обычная практика в вычислительной технике, но интеграция между современными и существенно устаревшими технологиями встречается редко. Возможно, просто нет достаточного спроса на разработку технологий интеграции. Некоторые из этих "прокладок" разрабатываются поставщиками и энтузиастами конкретных устаревших технологий. Ограниченные бюджеты часто не позволяют корпорациям решать проблему замены или миграции устаревшей системы. Однако компании часто не учитывают растущие затраты на поддержку (персонал, программное и аппаратное обеспечение, как упоминалось выше) и не принимают во внимание потенциальную потерю функциональности или непрерывности бизнеса в случае отказа устаревшей системы. Как только эти аспекты будут учтены, станет ясно, что внедрение новой, более безопасной и современной технологической платформы, с доказанной рентабельностью, не так дорого, как альтернатива, и бюджет будет найден. Тот факт, что большинство программистов, работавших с устаревшими системами, приближаются к пенсионному возрасту, а число молодых специалистов, способных их заменить, крайне мало, приводит к тревожному дефициту квалифицированных кадров. Это, в свою очередь, затрудняет поддержку устаревших систем и увеличивает стоимость привлечения опытных программистов. Некоторые устаревшие системы имеют жесткие ограничения по общей емкости, которые могут быть недостаточны для современных задач, например, ограничение в 4 ГБ оперативной памяти на многих старых процессорах x86 или ограничение в 4 миллиарда адресов в IPv4.

Legacy systems are considered to be potentially problematic by some software engineers for several reasons. If legacy software runs on only antiquated hardware, the cost of maintaining the system may eventually outweigh the cost of replacing both the software and hardware unless some form of emulation or backward compatibility allows the software to run on new hardware. These systems can be hard to maintain, improve, and expand because there is a general lack of understanding of the system; the staff who were experts on it have retired or forgotten what they knew about it, and staff who entered the field after it became "legacy" never learned about it in the first place. This can be worsened by lack or loss of documentation. Comair airline company fired its CEO in 2004 due to the failure of an antiquated legacy crew scheduling system that ran into a limitation not known to anyone in the company. Legacy systems may have vulnerabilities in older operating systems or applications due to lack of security patches being available or applied. There can also be production configurations that cause security problems. These issues can put the legacy system at risk of being compromised by attackers or knowledgeable insiders. Integration with newer systems may also be difficult because new software may use completely different technologies. Integration across technology is quite common in computing, but integration between newer technologies and substantially older ones is not common. There may simply not be sufficient demand for integration technology to be developed. Some of this "glue" code is occasionally developed by vendors and enthusiasts of particular legacy technologies. Budgetary constraints often lead corporations to not address the need of replacement or migration of a legacy system. However, companies often don't consider the increasing supportability costs (people, software and hardware, all mentioned above) and do not take into consideration the enormous loss of capability or business continuity if the legacy system were to fail. Once these considerations are well understood, then based on the proven ROI of a new, more secure, updated technology stack platform is not as costly as the alternative—and the budget is found. Due to the fact that most legacy programmers are entering retirement age and the number of young engineers replacing them is very small, there is an alarming shortage of available workforce. This in turn results in difficulty in maintaining legacy systems, as well as an increase in costs of procuring experienced programmers. Some legacy systems have a hard limit on their total capacity which may not be enough for today's needs, for example the 4 GB memory limit on many older x86 CPUs, or the 4 billion address limit in IPv4.

Улучшения устаревших программных систем

Там, где невозможно заменить устаревшие системы посредством вывода из эксплуатации, все же возможно их модернизировать (или "обновить"). Большая часть разработки часто направлена на добавление новых интерфейсов к устаревшей системе. Наиболее распространенным методом является предоставление веб-интерфейса для терминального приложения мейнфрейма. Это может снизить производительность персонала из-за более медленного времени отклика и более медленных действий оператора с использованием мыши, однако это часто рассматривается как "улучшение", поскольку стиль интерфейса знаком неквалифицированным пользователям и прост в использовании. Джон МакКормик обсуждает подобные стратегии, включающие использование промежуточного программного обеспечения. Улучшения в области печати представляют собой проблему, поскольку устаревшие программные системы часто не содержат инструкций по форматированию или используют протоколы, несовместимые с современными принтерами для ПК/Windows. Для перехвата данных и преобразования их в более современный код можно использовать сервер печати. Документы в формате Rich Text Format (RTF) или PostScript могут быть созданы в устаревшем приложении, а затем интерпретированы на ПК перед печатью. Внедрение биометрических мер безопасности в устаревшие системы затруднено. Рабочим решением является использование прокси-сервера Telnet или HTTP, расположенного между пользователями и мейнфреймом, для обеспечения безопасного доступа к устаревшему приложению. Некоторые организации переходят на программное обеспечение для автоматизации бизнес-процессов (ABP), которое генерирует полноценные системы. Эти системы могут взаимодействовать с устаревшими системами организации и использовать их в качестве хранилищ данных. Такой подход может обеспечить ряд значительных преимуществ: пользователи защищены от неэффективности устаревших систем, а изменения можно быстро и легко внести в программное обеспечение ABP. Подходы обратной и прямой разработки на основе моделей также могут использоваться для улучшения устаревшего программного обеспечения.

Пример НАСА

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

Перспективы на старый код

Некоторые специалисты в области разработки программного обеспечения предпочитают описывать "устаревший код" без негативного оттенка устарелости. Среди наиболее распространенных нейтральных представлений – исходный код, полученный от другого разработчика, и исходный код, унаследованный от более ранней версии программного обеспечения. Илай Лопиан, генеральный директор Typemock, определил его как "код, который разработчики боятся изменять". Майкл Федерс дал определение устаревшему коду как коду без тестов, что отражает точку зрения, согласно которой с таким кодом сложно работать, в частности, из-за отсутствия автоматизированных регрессионных тестов. Он также предложил использовать характеристические тесты для начала тестирования устаревшего кода. Джинни Хендри охарактеризовала создание кода как "вызов" для современных программистов – создавать код, который "подобен другим ценностям, передаваемым по наследству – антиквариату, семейным реликвиям и историям, которые бережно хранят и передают из поколения в поколение. А что, если устаревший код мог бы быть предметом нашей гордости?".

Дополнительные применения термина "наследие" в вычислительной технике

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

Архитектура Браунфилда

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