plakhov: (Default)
[personal profile] plakhov
Распространено мнение, согласно которому с увеличением программной системы число ошибок в ней обязано расти сверхлинейно (в зависимости от пессимизма носителя встречаются различные конкретизации, от "квадратично" до "экспоненциально"), и этот эффект неотвратим, как закон природы. Это мнение неверно.

Частично оно вызвано тем, что стандартный способ обеспечения отказоустойчивости, воспетый Кларком в "Свидании с Рамой", в софте плохо применим: три копии имеют большую отказоустойчивость, чем одна, только если речь идет об отказах оборудования, и то с оговорками.

Несколько раз я уже писал о том, как обходится этот "закон природы" в частных случаях (1, 2, 3, 4, 5), попробую обобщить.

Кроме abstraction leaks бывают и, назовем их так, abstraction sinks - методы, подсистемы, и алгоритмы, которые умеют "переваривать" ошибки и протечки соседей. К abstraction sink'у всегда можно подключить очередной "черный ящик", реализующий некоторый заранее обговоренный интерфейс. Работа системы в целом будет улучшаться, если этот "черный ящик" работает разумно, и не ухудшаться, если он ошибается (в том числе, если "заранее обговоренный" интерфейс оказывается протекающей абстракцией). После этого конкретные "чёрные ящики" могут писать эскимосские аутсорсеры, умные студенты, эволюционные процедуры, whatever, они могут быть сколь угодно "глючными" - лишь бы хоть иногда преодолевали порог полезности.

Здесь следует считать, что каждый черный ящик работает в собственной песочнице, т.е. не может, например, испортить память, или выбросить "неловимое" исключение. Если он примет управление и "упадет", начнет жутко тормозить, или зависнет, то можно продолжить работу так, как будто его никогда и не было. Как именно этого добиться в боевых условиях - вопрос интересный, но, надеюсь, понятно, что решаемый (если осознанно ставить себе такую задачу). Для простоты можно принять не очень реалистичное допущение, что каждый "черный ящик" запущен на собственном железе, и общается с abstraction sink'ом по сети.

Известно по крайней мере два типа abstraction sink'ов: машинное обучение ("черными ящиками" в этом случае являются отдельные features), и алгоритмы поиска и планирования ("черные ящики" - эвристики выбора "макроходов"). Ни тот, ни другой - не панацея, но их применение позволяет очень долго наращивать сложность системы уже после того, как она перестает помещаться у человека в голове, и оставлять её при этом работающей. Намного дольше, чем в привычных иерархическом или объектно-ориентированном подходах, где недопущение abstraction leak'ов критически важно.

Кое-какие современные задачи иначе и не решаются. Те, которые решаются именно так, по не до конца мне понятному совпадению чаще всего относятся к "искусственному интеллекту".

Для старых друзей: в геймдеве всё это практически не применимо. :)

Date: 2011-02-21 07:00 pm (UTC)
From: [identity profile] nudnik.ru (from livejournal.com)
Пост травли старых друзей, ок.

Date: 2011-02-22 08:59 am (UTC)
From: [identity profile] plakhov.livejournal.com
Я кстати наоборот уверен, что у старых друзей, где abstraction sink'ов нет, принято в целом лучше программировать, потому что иначе все дохнет быстро. Вообще конечно забавно, когда я в геймдеве работал, многие с вожделением думали, что у них там в серьезном софте о, такие технологии и методологии, что просто умереть - а на самом деле дела обстоят ровно наоборот.

Date: 2011-02-22 01:15 pm (UTC)
From: [identity profile] nudnik.ru (from livejournal.com)
Плахов сливает, что Яндекс запрограммирован хуже Тетриса!

Date: 2011-02-24 07:02 pm (UTC)
From: [identity profile] itman.livejournal.com
Мое большое подозрение: практически все, что интенсивно используется, за исключением нескольких вылизанных опенсорсных проектов такое, что лучше без респиратора не подходить.

Date: 2011-02-22 01:17 pm (UTC)
From: [identity profile] nudnik.ru (from livejournal.com)
А если серьезно, это нормально, я тоже думал, что в больших серьезных компаниях с управлением и бардаком всё ок, такие технологии и методологии, что просто умереть - а на самом деле дела обстоят ровно наоборот.

Date: 2011-02-22 10:29 pm (UTC)
From: [identity profile] golergka.livejournal.com
Осталось рассказать страшную правду о том, что там кофе РАСТВОРИМЫЙ на кухне - и всё, можно совершать ритуальное самоубийство от безысходнсти.

Date: 2011-02-22 10:41 pm (UTC)
From: [identity profile] nudnik.ru (from livejournal.com)
Нет, вроде кофе-машины стоят тоже.

Date: 2011-02-23 10:21 am (UTC)
From: [identity profile] plakhov.livejournal.com
ЭТОЪ НЕПРАВДАЪ

Date: 2011-02-24 09:08 am (UTC)
From: [identity profile] plakhov.livejournal.com
А откуда, собственно, безысходность? Это в маленькой организации если где-то начинается бардак, то скоро вообще наступает смерть жопа сотона, а большие могут себе позволить некоторую степень бардак без потери потенции. Это типа как жирок на мышцах.

Date: 2011-02-24 09:10 am (UTC)
From: [identity profile] golergka.livejournal.com
Ой, ну постебаться уже нельзя.

Date: 2011-02-24 09:13 am (UTC)
From: [identity profile] plakhov.livejournal.com
Ну я так, скорее, для случайных прохожих.

Date: 2011-02-21 08:13 pm (UTC)
From: (Anonymous)
Первый абзац напомнил о Парке юрского периода. Там кажется одно из "приближений" начиналось подобным мнением с занятной иллюстрацией, называющейся совершенно чарующе для неокрепшего ума - кривой дробной размерности..

Date: 2011-02-21 09:09 pm (UTC)
From: [identity profile] sleepy-drago.livejournal.com
не смешно даже. В каждой программной системе есть подсистемы генерирующие базовые данные. Они не дублируются. И никакой машинный sink не вытащит корректные данные если их (уже) нет.

Кстати в играх эти sink'и сплошь и рядом еще лучше чем, так как кому какая разница если вместо 65537 партиклов нарисуется 65536 или часть предмета затекстурируется другой текстурой ? Люди даже терпят в мультиплейере когда клиент показывает что они выиграли а с сервера приходит проиграли и клиент как ни в чем небывало поверх рисует проиграли :)) и ничего. Но количество багов от этого почему-то не уменьшается.

А когда данные ходят кругами и результат влияет на будущий вход ...

В общем не смотря на личности и авторитеты ктото тут сильно не прав.

Date: 2011-02-22 09:10 am (UTC)
From: [identity profile] plakhov.livejournal.com
Я, видимо, плохо выразился. Конечно, это не универсальное средство, и существует оно только для некоторых задач.

У задачи, в которой можно соорудить abstraction sink, должно быть следующее свойство: код, проверяющий, с каким качеством она решена, гораздо проще, чем код, который её решает. Так, чтобы можно первый проверить от и до, и написать без ошибок. Например, распознавание образов - такая задача (потому что можно качество измерять на 1000 примерах с ручной разметкой), или веб-поиск, или там, не знаю, задача поддержания динамического равновесия.

Date: 2011-02-21 09:23 pm (UTC)
From: [identity profile] clayrat.livejournal.com
это ж эрланг
там принцип let it fail

Date: 2011-02-22 09:14 am (UTC)
From: [identity profile] plakhov.livejournal.com
В Эрланге как раз как у Кларка скорее

Date: 2011-02-21 10:06 pm (UTC)
From: [identity profile] pg.livejournal.com
Это такой тонкий развод? IMHO понятно, что есть системы, позволяющие подобную декомпозицию, а есть - не позволяющие.

Кстати, если ты про наш поиск - то не забывай Лешу, который, фактически, и есть такой "abstraction sink", все остальное без его приемки рассыпалось бы. А это не машина, а живой человек.

Date: 2011-02-22 09:18 am (UTC)
From: [identity profile] plakhov.livejournal.com
Ну да, я и не отрицаю. Я даже могу сказать основной критерий: качество работы системы должно быть можно измерить автоматически, формально и просто, только тогда она может позволять такую декомпозицию.

Собственно, без Леши никак именно потому, что измерения эти кое-где недоформализованы и недоавтоматизированы.

Date: 2011-02-21 10:29 pm (UTC)
From: [identity profile] ushastyi.livejournal.com
Идея хорошая, но эти abstraction sinks требуют интерфейса с соседями, то есть возрастает количество связей, что не всегда хорошо. Кроме того, где-то должен быть код, который определяет, что да, ошибка есть, и надо дать попробовать кому-то ее исправить. Как гарантировать, что этот код не ошибается?

С другой стороны, возможны архитектуры, в которых похожий подход возможен. Но разработка таких архитектур -- отдельная сложная задача. Возможно, для поиска это и применимо, так как данные нестрогие по своей природе. Кстати да, в случае нестрогих требований к корректности результата такой подход представляется более реалистичным.

Date: 2011-02-22 09:37 am (UTC)
From: [identity profile] plakhov.livejournal.com
Это не столько идея (потому что так и делают, и чем дальше, тем чаще), сколько взгляд на мир. Я тут уже несколько комментариев оставил на тему того, в каких задачах это применимо, так что не буду повторяться.

Date: 2011-02-22 10:33 am (UTC)
From: [identity profile] ushastyi.livejournal.com
Я не спорю, что так делают. Я сам так делаю. Но область применимости все же, на мой взгляд, достаточно ограничена.

Date: 2011-02-21 11:33 pm (UTC)
From: [identity profile] elephantum.livejournal.com
Обучение (как я понимаю ты имел ввиду ранжирование и классификацию) и планирование обладают общим свойством: принимают на вход много данных, на выходе дают мало. На самом деле именно структурная сложность этих систем довольно низка: набор независимых подсистем генерации фичей, единообразный интерфейс для входящих данных, единообразная внутренняя обработка данных, структурно примитивные выходные данные.

То есть я бы поспорил, о наблюдаемости эффектов "закона природы" на системах такого типа.

Есть другие системы, богатые бизнес-логикой, например тот же Биллинг, это структурно сложная система, в ней не работают подходы "сконвертируем все входные сигналы к единообразному виду и обработаем одинаково".

Пока писал понял: можно выделить три вида сложности системы:
- структурная (алгоритмическая) сложность программной системы
- сложность данных
- кумулятивная, поведенческая сложность

Ты показываешь нам системы с высокой поведенческой сложностью, но при этом она достигается через сложность гомоморфных данных. А "закон природы" наблюдается на системах с высокой структурной сложностью.

Date: 2011-02-22 09:26 am (UTC)
From: [identity profile] plakhov.livejournal.com
Я не думаю, что структурная сложность имеет какую-то самостоятельную ценность, коль скоро задача создания поведенческой сложности решается и без неё. Мне кажется, что как в том биллинге, сложность данных или систем их обработки растет в основном из-за того, что её бесконечно "изобретают" (не столько айтишники, сколько биздев и маркетинг), ну и из-за требований всевозможной обратной совместимости - то есть, фактически, люди сами её себе выдумывают.

Date: 2011-02-22 04:42 am (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
Прошу прощения, правильно ли я понимаю, что в эти "abstraction sink" входит и ОС UNIX с классическим взаимодействием скрип-программа? Где подпрограммы типа grep, cat, tar и т.д. могут память вообще не высвобождать.

Или нет?

Date: 2011-02-22 09:28 am (UTC)
From: [identity profile] plakhov.livejournal.com
Я об этом думал, и решил в качестве примера не приводить. Тут немного странно получается: фактически, ОС (или платформа) предоставляет "песочницы", а abstraction sink'ом работает человек, это он понимает, какие комбинации работают, какие запчасти полезны, а какие нет, и когда. Это действительно близкая конструкция, но все же другая.

Date: 2011-02-22 08:17 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
Тогда похоже на bittorrent? Когда качаем с разных людей, зная лишь контрольные суммы, и если какой-нибудь человек отрубится или нагонит лажи, мы его выбросим и скачаем с другого?

Date: 2011-02-24 09:05 am (UTC)
From: [identity profile] plakhov.livejournal.com
Ну в общем да, чем-то похоже.

Date: 2011-02-24 10:01 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
Если так, то это древняя концепция - песочница + диспетчер.

Пример - защита микроядер: в Minix есть автоматический рестарт драйверов, в Виндах 7 вроде видеодрайвера изолированы, и если вылетают, то ОС их перезапускает и таки выводит на экран то, что нужно.

В геймдеве, как я понимаю, песочница - это компьютер без эффекторов (чтобы ничего не сломал :-), а диспетчер - человек. :-)

Date: 2011-02-22 06:57 am (UTC)
From: [identity profile] dev-zzo.livejournal.com
надо сказать, что это неприменимо не только в геймдеве. в написании firmware для разных девайсов, например (чем, собственно, я сейчас и занимаюсь).
тем не менее, прочитать было интересно!

Date: 2011-02-22 09:29 am (UTC)
From: [identity profile] plakhov.livejournal.com
Кстати, по-моему, это очень похожие занятия.

Date: 2011-02-23 08:31 am (UTC)
From: [identity profile] dev-zzo.livejournal.com
А если чуть более развёрнуто? :)

Date: 2011-02-24 09:04 am (UTC)
From: [identity profile] plakhov.livejournal.com
Как я себе это представляю: часто встречаются риалтаймовые или около-риалтаймовые требований. Близость "к железу", востребованность около-железных языков программирования. Вообще, редко встречается возможность выбора "средств производства": изволь пилить тем, чем дали. Жесткие ограничения на потребляемую память, и вообще, нельзя в случае чего "масштабироваться оборудованием". Мало алгоритмически (или математически) сложных задач. В целом, если стоит задача Х, то понятно, что её решить можно, хороший специалист решит быстрее и качественнее, но средний тоже решит. Нужно много читать всяких спецификаций и сторонних документов. Высокие требования к отсутствию ошибок (поскольку abstraction sink'ов нету).

Date: 2011-02-22 07:46 am (UTC)
From: [identity profile] vlad-volkov.livejournal.com
Я думаю, фразу "всё это практически не применимо" следует расширить и обобщить. Очевидно, что не любая система может продолжать осмысленно функционировать при падении произвольного подмножества ее компонентов. Далее, нужен "контролёр", чтобы отличать работающий "черный ящик" от неработающего или плохо работающего, "контролер за контролером" и т.д.
В общем, кажется, что вся эта кухня красива, но применима только к достаточно ограниченному классу задач, а не к "сложном софту" вообще. Этот класс задач неплохо бы попробовать описать более четко. Кстати, наверное, это кто-то уже пытался делать?

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

Date: 2011-02-22 09:35 am (UTC)
From: [identity profile] plakhov.livejournal.com
Конечно, не стоит утрировать, о "произвольном подмножестве" речь не идёт. Осмысленная работа где-то все равно должна выполняться.

Я не знаю, как правильно называется такой класс задач, но основной их признак - автоматом проверить, с каким качеством задача решена, проще, чем решить. Поэтому и ко всяческим драйверам, большей части "системных" вещей, к созданию rich UI и т.п. это действительно не очень применимо.

Заниматься формализацией исходного утверждения не очень хочется, поскольку я в него все равно не верю :)

Date: 2011-02-22 12:13 pm (UTC)
From: [identity profile] alex ulyanov (from livejournal.com)
А точки зрения синергетики нельзя это объяснить?

Date: 2011-02-24 08:55 am (UTC)
From: [identity profile] plakhov.livejournal.com
Не знаю, аналогии какие-то, наверное, можно найти, но "объяснить" - вряд ли. Это очень технический вопрос, как мне кажется, "из общих соображений" в нём не разобраться.

Date: 2011-02-22 09:10 pm (UTC)
From: [identity profile] g00dmann.livejournal.com
Я не знаю, как правильно называется такой класс задач, но основной их признак - автоматом проверить, с каким качеством задача решена, проще, чем решить.

Класс задач достаточно узкий, но теоретически методика отличная, все красивенько и нарядненько. Элегантно получаем вроде бы приличное решение для не самой простой задачи, после чего спокойно его тюнингуем. Ага, как бы не так. В реале все получается не так прикольно, т.к. алгоритм для "автоматом проверить" как правило выбирается совсем не тот. Т.е., если не копать вглубь, то все вроде зашибись, а вот если копнуть... То жопа. :)

К тому же, в угоду качеству "автоматом проверить" логика черных ящиков иногда полностью отрывается от реальности.

Но если этого не замечать и тащиться от методики проверки качества, то да, все здорово. :)

Date: 2011-02-24 08:48 am (UTC)
From: [identity profile] plakhov.livejournal.com
Ну как бы понятно, что если задача неверно поставлена, то никакой способ её решения не сработает. :)

Что тут дополнительно обсуждать?

Date: 2011-02-23 06:54 pm (UTC)
From: [identity profile] dtjurev.livejournal.com
Насчёт отказоустойчивых систем. Надо посмотреть, как проектируется что-то типа софта для марсоходов, или систем поддержки электронных денег. Ведь там отказоустойчивость должна быть максимально возможной.

Date: 2011-02-24 08:54 am (UTC)
From: [identity profile] plakhov.livejournal.com
Насколько я читал (могу ошибаться), там просто всё бесконечно проверяется и перепроверяется кучей разных способов. В "марсоходах", кроме этого, приветствуются как раз разного рода "песочницы" (как софтовые, типа Ada, так и хардверные). В "системах поддержки электронных денег" есть сколько-то универсальных "безопасных абстракций", за работоспособность которых отвечает Oracle. :) Как-то так я это себе представляю.

Date: 2011-03-07 07:45 pm (UTC)
From: [identity profile] http://users.livejournal.com/_winnie/
abstraction syncs и leaks бывают на микроуровне и архитектуре в малом.

Приняли решение заливать неинициализированную память нулями в аллокаторе - получили хороший sink и помощь в отладке.

Решили синхронизировать на разных компьютерах операции с double - получили очень хрупкий объект. Пересылаем fixed point по сетке - получили маскировку неважных ошибок.

Запретили не-explicit конструкторы (совсем уж микро) - получили чуть-чуть sink.

Пишем на Haskell вместо assembler (крайности, для иллюстративности) - избежали массы ненужных ошибок.

Дядя Дима выкидывает сложную физику из "заваленный камнями лифт" и меняет на скриптовую катсцену.

WinWord/VisualStudio делает автосейвы каждую минуту - уже можно жить с каким-то багом который обрушивает Visual Studio раз в два дня.

Сервер ММО толерантен к ошибкам в скриптовых функциях на питоне, разумно расставлены try/catch - и сервер выглядит адекватным для 90% игроков, у разрабов есть пара дней для спокойной починки. Вообще сервер ММО целиком про abstracion sinks, все легкие способы работать на одном крыле, и пришивать крылья на лету - стараются использовать.
Edited Date: 2011-03-07 07:51 pm (UTC)
Page generated Jul. 25th, 2017 06:53 pm
Powered by Dreamwidth Studios