Мир все больше становится программно-конфигурируемым, приставка SD стала применяться повсеместно: SDN, SDS, SDI и прочие SDx, — а ПО лежит в основе любой современной инфраструктуры. Между человеком и машиной сегодня все чаще располагается программное обеспечение, постоянное усложнение которого повышает вероятность потери контроля над системами, приводя к ситуации, когда даже единичный сбой может вызвать серьезные последствия и человеческие жертвы. Задача обеспечения качества программ актуальна сегодня как никогда ранее.
Серия катастроф физически новых авиалайнеров Boeing 737 Max, регулярно проходивших техническое обслуживание, заставила задуматься: как такое стало возможным в отрасли, традиционно отличающейся высокими требованиями к сертификации по безопасности и наличием скрупулезного контроля за надежностью? Что могло к этому привести: низкое качество ПО, выгода в ущерб безопасности, культура разработки или все вместе?
Модель 737 впервые появилась еще в 1967 году — это был компактный авиалайнер с небольшими двигателями и относительно простой системой управления, благодаря чему самолет и стал популярен у многих авиакомпаний. Постепенно рынок и развитие технологий стали инициаторами модификаций, направленных на снижение показателя «стоимость мили / место», что в общем-то типично не только для авиастроения, — модель, в которую инвестированы огромные средства, будет развиваться, пока не наступит «момент истины». Для 737 Max таким моментом стало решение об увеличении размеров двигателя для повышения экономичности самолета. Однако изначально лайнер был рассчитан на небольшие двигатели, а новые означали изменение аэродинамики планера — при увеличении тяги турбин у самолета появилась склонность к поднятию носа. Вместо того чтобы переконструировать физический планер, в Boeing решили эту проблему программно с помощью системы увеличения характеристик маневрирования MCAS, что, конечно, намного дешевле — внесение серьезных конструктивных изменений фактически означало бы появление нового авиалайнера: а это новые сертификаты, новые лицензии пилотам, которые, похоже, действовали еще с 1967 года, обновление документации и прочие затраты.
Все бы хорошо, но MCAS недостаточно тщательно обрабатывала показания всех датчиков, прямо или косвенно отвечающих за ориентацию самолета, и не информировала пилотов о выполненных ею действиях по коррекции режима полета. В 737 Max, как и в большинстве современных авиалайнеров (а скоро, вероятно, и в большинстве автомобилей), косвенно или напрямую все контролируется системами типа MCAS. Мало того, во многих случаях уже даже исчезают реальные механические соединения между органами управления в кабине пилота или водителя автомобиля с устройствами, фактически регулирующими средство передвижения.
Для 737 Max в одной точке трагически сошлись технологические ограничения, риски сложности и рыночные приоритеты, причем было бы иллюзией считать проблему решенной лишь благодаря обновлению программы. По сути, сам факт обновления ПО означает, что продукт сырой, его выпустили в угоду рынку, в надежде доделать потом, когда будет время. Об этом не стоит забывать каждый раз, когда на вашем карманном гаджете обновляется программное обеспечение, на бортовой компьютер личного автомобиля «заливается» новая версия управляющей программы, а «умный» домашний холодильник загружает свежую прошивку приложения.
Задача обеспечения качества ПО сегодня в центре внимания специалистов по программной инженерии. Например, в статье «Игнорировать, рефакторизовать или переписать?» обсуждается, как поступить при обнаружении недоработок в коде: оставить все как есть, внести инкрементальные изменения или переписать программу. Если ПО, задуманное для повышения безопасности и комфорта, оказалось способным уничтожить больше людей, чем могло бы спасти, то это явный претендент на последний сценарий. Его нужно не исправлять в угоду рынку, а удалять — рефакторинг при устранении проблем, вызванных изменением физических параметров изделия, казавшийся разработчикам лишь небольшим порогом, на самом деле может превратиться в первую ступень длинной лестницы.
Новые архитектуры могут быть несовместимы с традиционными технологиями разработки сложных программных комплексов и культурой их сопровождения. Для обеспечения нужного качества бизнес-критичных программ и его поддержки на требуемом уровне нужны методы непрерывной инженерии, верификации и валидации, предусматривающие намного более тщательное, чем сегодня, выполнение процедур испытания на работоспособность. Кроме того, повсеместное внедрение технологий искусственного интеллекта требует обеспечить еще большую прозрачность работы соответствующих систем — например, необходимо понимание того, по каким правилам нейронная сеть определяет, можно ли предоставить клиенту кредит или как беспилотному автомобилю реагировать на стечение определенных и неопределенных обстоятельств. Классические регрессионные тесты и механизмы трассировки выполнения уже не помогут — средства верификации и валидации новых поколений будут все шире применять интеллектуальные инструменты, способные к анализу, самообучению на основе больших данных и автоматическому улучшению качества ПО. Однако следует учитывать, что системы искусственного интеллекта не тиражируются.
.jpg)
Еще при появлении первых киберфизических систем бытовала шутка про человека-пилота и собаку: задача первого — обеспечить комфорт пассажирам, считающим, что авиалайнером "управляет" человек, а задача собаки состояла в том, чтобы кусать пилота, если он попытается нажимать кнопки на приборной панели. К сожалению, как мы видим сегодня, реальность оказалась намного серьезнее.
Дмитрий Волков
