В одном бите от ядерной катастрофы

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

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

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

Нажатие на тормоз все еще передается на колеса почти напрямую, но и этот бастион скоро падет.

Чем сложнее система, тем больше вероятность того, что человек не приминает никаких решений напрямую. В самолетах концепция fly-by-wire давно победила ручное управление. Ракеты изначально летают в полностью автоматическом режиме. Финансовые системы практически полностью существуют в виртуальном мире. Решения о покупке и продаже принимаются автоматически. Медицинская техника? Это только кажется, что человек нажимает кнопку и что-то при этом решает. На самом дале нажатие кнопки всего лишь запускает глючный код, который определяет дозу рентгена, которую получит пациент. Атомные станции? Ядерный арсенал? Управляется опытными операторами? Не смешите мои тапочки. Опытные операторы только кнопки нажимают. Компьютеры принимают все решения.

Как компьютер принимает решение? А вот так:

if (speed < desired_speed)
{
    accelerate();
}

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

Достаточно ошибится в одном бите, чтобы выполнить действие, прямо противоположное действие задуманному. Разница между “отдать штурвал от себя” и “потянуть штурвал на себя” - один бит.

Страшно?

Read On →

Боинг 737 MAX

История с двумя авиакатастрофами самолетов Боинг 737 MAX 8 принимает интересный оборот. Эта модель самолета начала летать в мае 2017 года. 29 октября 2018 вскоре после взлета разбивается рейс 610 авиакомпании Lion Air. Далее, 10 марта 2019 года вскоре после взлета падает рейс 302 Эфиопских авиалиний.

Одинаковый характер обоих авиакатастроф ставит под подозрение систему MCAS (Maneuvering Characteristics Augmentation System) - новую систему разработанную специально для 737 MAX. Задача этой системы - избежать сваливания в ситуации, когда угол атаки превышает определенный порог. MCAS автоматически отклоняет горизонтальный стабилизатор, опуская нос самолета и уменьшая угол атаки.

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

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

Почему нельзя было переделать фюзеляж? Можно было бы, но это был бы новый самолет, с более сложной программой сертификации. Учитывая, что 737 MAX нужен был для конкуренции с A320neo, то времени на разработку и сертификацию нового самолета не было (классика).

В принципе в идее MCAS нет ничего особенно плохого. Однако в данном случае по всей видимости произошло то, что называется “process miss” - а именно цепочка событий привела в двум катастрофам, причем каждое их этих событий само по себе к катастрофе бы не привело.

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

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

Далее, многие пилоты отметили неадекватное обучение при переходе на 737 MAX с 737. Боинг рекламировал самолет как обыкновенный 737-й, ничем значительным не отличающимся от “обычных” 737-х. Это похоже на явный неумышленный просчет. Я могу легко себе представить, что система “заставляющая 737 MAX вести себя как 737” могла проскочить, как не стоящая пристального внимания и переучивания пилотов.

Я уверен в этой цепочке еще с десяток разный событий. По настоящему мне странно только использование только одного датчика. Особенно для системы, которая срабатывает автоматически. По хорошему их должно быть три. Тогда выход из строя одного из датчиков не проблема. Два - немного хуже чем три. С двумя датчиками нельзя распознать некоторые сбои. Но один?

Read On →

Скрытые угрозы

Ой, други мои! Ржу, не могу остановится. Текут слезы и болят бока. Набрел на шедевр махровой пропаганды, или как говорят в теперешней России, - вторник. Смотрите сами, а главное, - до самого конца:

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

Не реалистично.

Знаете как выглядят настоящие двухминутки ненависти? Это когда посмотрят такой вот продукт и говорят “пропаганда и вранье, конечно, но вот одну вещь они правильно заметили…”

Read On →

Водоплавающая ступень

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

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

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

Еще одно видео:

P.S. Dragon без приключений вышел на запланированную орбиту.

Как выглядит запуск с орбиты

Впечатляющее видео - покадровая съемка, показывающая как выглядел запуск Прогресса MC-10 с борта МКС:

Волшебство Питона

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

Непонятно как все это счастье держать в одной куче. Неужели все живут за счет 100% покрытия тестами? Не верю. Или все на PyCharm сидят?

Расскажу про очередной прикол Питона. Итак есть простой код:

def init(factories):
    """Convert a list of factorie into a list of objects.""" 
    return [factory() for factory in factories]

def cleanup(objects):
    """Clean up objects in the reversed order of their creation."""
    for obj in reversed(objects):
        obj.cleanup()

init() берет список фабрик и отдает список объектов, созданных фабриками. cleanup() чистит созданные объекты в порядке, противоположном порядку создания. Нам требуется написать тест, который проверяет, что методы cleanup() вызываются в правильном порядке:

from itertools import permutations
import mock

def test_cleanup():
    """Verify cleanup() order."""
    # Try all permitations of initialization order. 
    for init_order in permutations(range(3)):
        cleanup_order = []

        def factory(index):
            def cleanup():
                """Record the clean up order."""
                cleanup_order.append(index)

            def create():
                """Return a mock implementing cleanup()."""
                obj = mock.Mock
                obj.cleanup = mock.Mock(side_effect=cleanup)
                return obj

            return create

        # Create objects in the desired order.
        objects = init([factory(index) for index in init_order])

        cleanup(objects)

        # Verify that the object were cleaned up in the reveresed
        # order of their creation.
        assert cleanup_order == list(reversed(init_order))

Разберу логику по кускам. Тест перебирает все возможные кобинации порядка создания объектов:

for init_order in permutations(range(3)):

Декоратор factory() возвращает фабрику create(), которая в свою учередь создает объект с методом cleanup(). Для создания объекта на коленке используется Mock. Релизация cleanup() запоминает порядок вызова в cleanup_order.

init() создает объекты в заданном порядке, cleanup() - чистит:

objects = init([factory(index) for index in init_order])

cleanup(objects)

Наконец, в самом конце мы проверяем, что порядок очистки противоположен порядку создания:

assert cleanup_order == list(reversed(init_order))

Все просто, не так ли? Запускаем тест и получаем облом:

>               assert cleanup_order == list(reversed(init_order))
E     assert [2, 2, 2] == [2, 1, 0]
E       At index 1 diff: 2 != 1
E       Use -v to get the full diff


rabbit_test.py:41: AssertionError 

Заядлые питонщики давно раскусили, в чем проблема. А вы сможете найти ошибку не заглядывая в ответ?

Read On →

Марс: Внутри SpaceX

National Geographic начал показывать второй сезон сериала Марс и вместе с первым эпизодом выложил серию про SpaceX. Такого количества знакомых лиц в документальном фильме я еще не видел. Я там тоже засветился в 42:56. :)

Красиво снято. Рекомендую посмотреть.

Read On →

Ну-ка, еще разок

Питоний пакет retrying - универсальная заплатка для кода, который может поломаться из-за внешних причин. Например, socket.connect() может закончится ошибкой из-за непредвиденной ситуации в сети. Заворачиваем вызов в @retry и бац! Все работает.

@retry
def create_connection(address):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    return socket.connect(address)

Однако бездумное применение @retry, как нетрудно догадаться, приводит проблемам. Самый известный пример - вложенные @retry. @retry(stop_max_attempt_number=3) вложенный в другой @retry(stop_max_attempt_number=3) дает 9 повторов. Три уровня вложенности - 27 повторов.

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

Мораль истории - знайте свои ошибки в лицо и используйте параметр retry_on_exception.

Read On →

Тридцатиметровый телескоп

Верховный суд Гавайев разрешил постройку Тридцатиметрового телескопа на вершине горы Мауна-Кеа. Решение о постройке телескопа вызвало протесты среди защитников природы и сторонников традиционного гавайского образа жизни, которые считают гору Мауна-Кеа священной. В 2015 году Верховный суд Гавайев отменил уже готовое разрешение на постройку телескопа, из-за нарушений прав коренных гавайцев, а именно - спор не был рассмотрен в суде перед выдачей разрешения на постройку. Орган, ответственный за выдачу разрешения (The Board of Land and Natural Resources), подсуетился и организовал слушание. И вот теперь Верховный суд дал добро на постройку.

Отдельные части решения Верховного суда читаются как сказка (извиняйте за корявый перевод):

Некоторые коренные гавайцы, включая некоторых аппелянтов, считают гору Мауна-Кеа, возвышающуюся на 13796 футов над уровнем моря, предком, нине живущим членом семьи и прародителем гавайцев, рожденным от Wākea (небесного отца) и Papa (матери Земли). Они полагают, что вершина Мауна-Кеа, также известная как Kūkahauʻula (скопление puʻu или шлаковых конусов), является wahi pana (легендарным местом) и wao akua (местом, где живут боги), сферой исконных akua (богов, богинь, божеств), принимающих земную форму в виде puʻu, воды озера Waiau, и других значительных элементов ландшафта. Считается, что вершина Мауна-Кеа касается неба уникальным и важным способом, - как piko (пупок) через который устанавливается связь с предками или как piko hoʻokahi (единый пупок), который устанавливает духовную и генеалогическую связь, и обеспечивает права на живительную энергию всего того, чем являются Гавайи. Большое количество святилищ на Мауна-Кеа указывает на традицию паломничества: “прогулка вверх и назад во времени к космологическим началам” чтобы поклонится виду богини Poliʻahu и другим akua, таким как Kūkahau, Līlīnoe и Waiau.

Some Native Hawaiians, including some of the appellants, consider Mauna Kea, which rises to an elevation of 13,796 feet above sea level, to be an ancestor, a living family member and progenitor of Hawaiians, born of Wākea (Sky Father) and Papa (Earth Mother). They consider the Mauna Kea summit area, also known as Kūkahauʻula (cluster of puʻu or cinder cones), to be a wahi pana (storied place) and wao akua (the place where gods reside), the realm of ancestral akua (gods, goddesses, deities) believed to take earthly form as the puʻu, the waters of Lake Waiau, and other significant landscape features. The summit of Mauna Kea is thought to touch the sky in an unique and important way, as a piko (navel) by which connections to the ancestors are made known to them, or as the piko hoʻokahi (the single navel), which ensures spiritual and genealogical connections, and the rights to the regenerative powers of all that is Hawaiʻi. The large number of shrines on Mauna Kea indicate that there was a pattern of pilgrimage, “a walk upward and backward in time to cosmological origins,” to worship the snow goddess Poliʻahu and other akua such as Kūkahau, Līlīnoe, and Waiau.

Во как!

Read On →

Восход Земли

Композитное изображение Земли, восходящей над горизонтом Луны:

Изображение полученно из серии снимков, сделанных 12 октября 2015 года, с борта лунного орбитального зонда. В момент съемки аппарат находился на высоте 134 километров над кратером Комптон, расположенном на обратной стороне Луны (51.8°N, 124.1°E).

Статья, посвященная этому снимку, объясняет процесс съемки и ссылается на полноразмерное изображение.

Read On →