Мнение «ELY (сущ.) — первое, малейшее подозрение, что что-то где-то пошло не так». Одно из лучших определений Дугласа Адамса и Джона Ллойда. Значение имени Лиффон прекрасно описывает начало этого кошмарного сценария для операторов крупного поставщика услуг — нарастающая волна предупреждений после запуска этого обновления.
У какого-то бедолаги в Microsoft только что была мать всех елей. Тщательная, сложная, протестированная и одобренная переделка пакета Azure DevOps была отправлена в мир, но Южная Бразилия погасла, поскольку она начала потреблять экземпляры клиентов. Вы можете прочитать кровавые подробности здесь, они столь же убедительны, как эпизод расследования авиакатастрофы. Скинни — это просто. Опечатка спровоцировала непредвиденный каскад ошибок, из-за которого дальнейшие попытки навести порядок затянулись на десять позорных часов.
Легко обижаться на Microsoft по множеству причин. Начинка своей ОС рекламным ПО, замаскированным под справочную систему. Опираясь на то, что все перейдут на Windows 11, в то время как почти половина ПК с Windows 10 не соответствует требованиям к оборудованию. Команды. Но эти наросты носят корпоративный и культурный характер: сбои в работе Azure из-за опечаток — широко распространенное в отрасли явление, совершаемое хорошими людьми. Простые опечатки и их двоюродный брат Мистер Неправильная конфигурация могут вызвать хаос у любого.
Как это возможно в год наших повелителей ИИ 2023, когда наши изобретения достаточно умны, чтобы писать сонеты? Более того, учитывая, что мы, люди, никогда не перестанем гадить, есть ли способ обнаружить ошибки до того, как они нанесут ущерб?
Часть проблемы заключается в том, что наша технология будет делать то, что мы ей говорим, и разница между очень полезной и экзистенциально угрожающей может быть очень тонкой. Возьмите печально известную команду Unix/Linux 'rm -r *'. Для тех из вас, у кого не потеют инстинктивно ладони при виде этой маленькой красоты, это означает «Удалить все файлы в этом каталоге и во всех каталогах под ним». Это чрезвычайно полезно при освобождении места или удалении старых установок, и система не позволит вам избавиться от вещей, к которым у вас нет прав доступа.
Запустите его с привилегиями root в корневом каталоге, что является просто sudo и cd / прочь, и вы уничтожили всю свою вселенную. Вы можете даже не заметить поначалу, как он начнет свою самоубийственную миссию с тихой эффективностью, но в конце концов появится какая-то странная ошибка, когда то, что осталось от запущенного программного обеспечения, потянется к важному файлу, которого там нет. Эли. Сообщения об ошибках, которые последуют, когда вы попытаетесь разобраться в своем апокалипсисе, станут уроком цифрового безумия.
Не попробовать это дома? Вы абсолютно должны. Никто из тех, кто видел, как это происходит, никогда не забудет — или не повторит — этого. Просто запустите новую виртуальную машину Linux и приступайте к делу. (Эль Рег не несет ответственности, если вы вводите не в то окно. Не делайте этого.) Этот принцип — совершать ошибки в месте, которое безжалостно демонстрирует их последствия, но не является следствием, — это золотой стандарт в сетях безопасности. В авиации такие места называются авиасимуляторами. В электронике, симуляторах схем. У людей, Ибица.
Почему не этот принцип, принятый в больших, сложных системах, например, в крупных сервисных и сетевых службах? В какой-то степени так оно и есть — процессы тестирования и валидации происходят в какой-то системе, которая пытается реагировать на что-то похожее на реальную вещь. Это работает, за исключением случаев, когда это не так – большие, сложные, динамические системы обычно слишком много всего, чтобы их можно было реалистично смоделировать, если они вообще могут быть моделированы. Их моделирование требует большого труда. В тех случаях, когда такие модели используются, они обязательно предполагают большую абстракцию, определенно слишком большую, чтобы фиксировать подробные изменения конфигурации в компонентах.
Такой тип мышления является провалом воображения и техники. Вернемся к авиасимуляторам, которые по нормативным требованиям должны разрабатываться вместе с самолетами, для которых готовят пилотов. На небесах devops тестовые сценарии и протоколы разрабатываются вместе с реальным программным обеспечением — ну, может быть. Как только программное обеспечение выходит на свободу и взаимодействует с другими системами, все это исчезает. Опечатка, которая приводит к каскадной цепочке отказов между компонентами, которые просто делают то, что им говорят, не имеет системной системы безопасности.
Все программное обеспечение исходит из функциональной спецификации — или, по крайней мере, давайте притворимся. Эта же спецификация используется при тестировании и проверке. Почему бы не использовать его дальше, чтобы создать смоделированную модель программного обеспечения, которую можно использовать в виртуальной среде? Он может делать вид, что выполняет работу, требующую массы физических ресурсов, чтобы смоделировать свое поведение и проверить его логику. Если вы управляете крупной сервисной структурой с терабайтами клиентских данных, вам не больше нужно реплицировать данные в виртуальной тестовой среде, чем авиасимулятору нужно реплицировать планетарную погодную систему. Просто нужен местный эффект. Вы не можете позволить себе реплицировать свою внутреннюю сеть и ее BGP-маршрутизаторы, да и толку от этого не будет. Вы даже не можете смоделировать это, потому что у вас нет хороших моделей компонентов.
Ни одна компания, производящая компоненты для авиационной техники, не смогла бы вести бизнес, если бы не ограничивалась функциональными спецификациями, позволяющими разработчикам тренажеров выполнять свою работу. Электронные компоненты поставляются со стандартными описаниями, которые можно виртуально подключить. Программное обеспечение не работает. У приборов нет. Они могли бы — информация существует — но на это не рассчитывают, нет стандартного способа выразить это, нет традиции доставлять виртуальные компоненты вместе с реальными.
Если бы это изменилось, насколько это возможно, с помощью автоматизированных инструментов для управления затратами, мы получили бы гораздо больше, чем просто системы безопасности для работающих систем. Мы могли бы ввести большие системы в их собственный эффективный цикл devops, мы могли бы исследовать «что, если» с новыми аппаратными и программными компонентами по мере их появления на рынке без необходимости собирать воедино дорогостоящие испытательные стенды. Поддержка виртуальных машин и ОС для новых устройств будет революционизирована стандартными характеристиками и функциональными моделями. А необходимость создавать и тестировать как виртуальные, так и реальные системы в соответствии со спецификацией может только улучшить качество программного обеспечения. Боже, это почти как настоящее инженерное дело.
Все равно все пойдет не так. Карта — это не территория. Тем не менее, учитывая, что мы знаем, что этот подход работает, отказ от разговора о том, как это может произойти, должен пробудить настоящее чувство уверенности в будущем. ®
