Принцип Анны Карениной в программировании и ИТ


    «Принципу Анны Карениной» посвящено немало научных публикаций и даже отдельная статья в Википедии. Применим к ИТ и программированию? А может он уже работает против вашего проекта?
    Первый вариант этой статьи я опубликовал в моём англоязычном блоге и поместил ссылки в несколько узкоспециализированных форумов. Состоявшиеся там обсуждения мотивировали меня предложить её вариант на русском языке читателям Хабра.

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

    Если Вам, дорогой читатель, такие темы не интересны, вряд ли Вам стоит читать эту статью дальше.

    Недавно я перечитал великий роман Льва Толстого «Анна Каренина».

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

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

    А по прочтению романа остается впечатление, что иначе и не могло быть. Легкий флирт между замужней женщиной и молодым блестящим аристократом-офицером переходит в страстную любовь, затем – в моральный надлом отношений между влюблёнными и, в финале – самоубийством героини под колесами поезда.

    И каждое звено в этой ужасной цепи событий в момент прочтения представляется понятным и логичным.

    Прочитав роман, каждый может сам для себя решить, что означает это загадочное, самое первое предложение романа:


    „Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему.“

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

    Что означает Принцип Анны Карениной?


    Интерпретациям этого принципа, получившего имя «Принцип Анны Карениной», посвящено немало научных публикаций и даже отдельная статья в Википедии.

    Что означает этот принцип? Очень сложные химические, физические, биологические, психологические, социальные и т.п. системы могут долго и успешно существовать и развиваться только если их части хорошо подходят друг к другу и к внешней среде.
    Если бы мы были в состоянии описать такие системы каким-то количеством параметров, то заметили бы, что для каждого класса систем существует совсем немного «успешных» комбинаций этих параметров.

    Замечание: Для придания нашим параметризованным моделям большей реальности мы должны говорить не об отдельных значениях параметров, а об классах эквивалентности параметров. Но это не меняет сути. 

    Как это ни парадоксально, но чем сложнее класс систем, тем меньше у него «успешных» комбинаций.

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

    Принцип Анны Карениной  и одомашнивание животных или ограниченность и вторичность параметров отбора


    Британский ученый Фрэнсис Гальтон,  живший одновременно с Толстым, сформулировал похожий на Принцип Анны Карениной принцип, рассматривая одомашнивание животных:


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

    Дальнейшие интересные рассуждения о том, как сработал этот принцип можно найти в увлекательно написанной книге Джареда Даймонда «Ружья, микробы и сталь».

    Глава 9. Зебры, несчастливые браки и принцип «Анны Карениной» этой книги начинается такой фразой (в переводе на русский):
    Все одомашниваемые животные похожи друг на друга, каждое неодомашниваемое животное неодомашниваемо по-своему.

    Если вам показалось, что где-то вы уже читали нечто подобное, вы не ошиблись. Поменяйте несколько слов, и получится знаменитое первое предложение «Анны Карениной», великого романа Льва Толстого: «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». Этой фразой Толстой хотел сказать, что счастливым может быть только брак, состоявшийся во множестве разных аспектов: между супругами есть обоюдное сексуальное притяжение, налажены отношения с родней друг друга, нет разногласий по поводу финансов, воспитания детей, религии и остальных жизненно важных вопросов. Неудача на одном из этих важнейших направлений способна погубить брачный союз, даже если у него есть все остальные компоненты для счастья.

    Далее автор называет факторы, которые не позволили, несмотря на многочисленные и продолжающиеся до сих пор попытки одомашнить диких животных. Их немного: рацион питания, скорость роста, проблемы с размножением в неволе, «дикость» характера, склонность к панике, социальное устройство.

    Интересно отметить тот факт, что все перечисленные автором факторы — «вторичные». Например, человечество выращивает и забивает на мясо не носорогов (3 тонны мяса) а куда более мелких животных — коров, свиней и овец.

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

    Но автор объясняет действие принципа в конкретной предметной области. Имеется его более широкая интерпретация?

    Принцип хрупкости хорошего


    Взглянуть на проблему с более широких и в тоже время чисто математических позиций попытался гениальный математик Владимир Арнольд в своей книге «Теория катастроф»

    Там он описывает т.н. «Принцип хрупкости хорошего».

    Он пишет:


    … для системы, принадлежащей особой части границы устойчивости, при малом изменении параметров более вероятно попадание в область неустойчивости, чем в область устойчивости. Это проявление общего принципа, согласно которому всё хорошее (например, устойчивость) более хрупко, чем плохое. По-видимому, все хорошие объекты удовлетворяют нескольким требованиям одновременно, плохим же считается объект, обладающий хотя бы одним из ряда недостатков
    .
    В рассматриваемом им контексте Владимир Арнольд возможно был и прав. Но в более широком контексте можно видеть, что на самом деле он говорит о хрупкости, а точнее — о редкости устойчивости, а не «хорошести».

    Не все неустойчивое плохо и не все устойчивое хорошо.

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

    С другой стороны -любое движение скорее неустойчивость. Деревья и цветы хороши пока они живы и растут, а засохнувшие — как правило нет.

    И в то же время, про дерево, растущее сотни лет, интуитивно хочется сказать, что оно стабильно (устойчиво) растет.

    Подведем промежуточный итог: Устойчивость (стабильность) и «хорошесть» — показатели скорее независимые друг от друга и зависят от того, что же мы измеряем или моделируем. При этом следует добавить, что устойчивость — это скорее объективный, измеряемый параметр. Что такое хорошо и что такое плохо — это субъективное решение наблюдателя.

    Принцип Анны Карениной  и аттракторы


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

    Теория хаоса — сравнительно молодая наука. О её становлении и первых шагах увлекательно рассказывает книга "Хаос. Создание новой науки" Джеймса Глейка. Один из самых увлекательных сюжетов в этой книге — открытие такого явления как аттракторы.

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

    Внизу изображен один из вариантов Аттрактора Лоренца.


    Какое отношение имеют аттракторы к Принципу Анны Карениной?

    Я думаю, с философской точки зрения аттракторы представляют в мире хаоса «одинаковые счастливые семьи» в то время как остальные точки фазового пространства — «несчастливые семьи, несчастливые по-своему».

    В колоде мало козырей...


    Вы наверняка слышали о долгих спорах Эйнштейна и Бора о фундаментальных основах квантовой физики. Дискуссия велась вокруг вопроса, какая модель определяет траекторию отдельной элементарной частицы: детерминистская или вероятностная. Два великих физика абстрагировали суть спора до полушутливого вопроса: Играет ли Бог в кости, управляя движением частиц, составляющих наш мир?

    За прошедшее столетие модели описания мира невероятно умножились и усложнились. Продолжая линию Эйнштейна и Бора применительно к нынешней ситуации мы можем сказать, что для управления миром Богу необходимы инструменты посложнее, чем игральная кость. Например — колода карт.

    Тогда, с учетом Принципа Анны Карениной можно сказать, что колоды карт, которые Бог выбирает для управления природными и социальными феноменами, как правило, не очень хороши. В них слишком мало козырей…

    Ну а сами феномены делятся на устойчивые и неустойчивые. При этом «очень» неустойчивые со временем часто «скатываются» на аттракторы.

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

    Другими словами, мир выглядит так,  как на моей картинке внизу.



    Принцип Анны Карениной в ИТ


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

    Уверен, действует. Хотя бы потому, что этот общий принцип просто должен действовать и в этой конкретной предметной области. По крайней мере для тех программно-аппаратных и чисто программных систем, которые достаточно сложны и динамичны. А многие из них действительно таковы.

    Синдром Анны Карениной


    Если Принцип Анны Карениной (ПАК) в ИТ присутствует, как его заметить?
    Во-первых, если ваша система работает стабильно и позволяет себя безболезненно расширять и конфигурировать, вам не стоит особенно беспокоиться. Ваша система находится в устойчиво-хорошей части (см. картинку вверху).

    Если ваша система не совсем хороша или совсем нехороша, но устойчива и делает своё дело (находится в устойчиво-нехорошей части мира), либо хороша но неустойчива, вам следует хорошенько подумать, а стоит ли рисковать и что-то радикально менять.

    ПАК начинает показывать себя со своей негативной стороны, если попытки исправить конкретные ошибки только ухудшают ситуацию. Ошибки действительно исправляются, патчи инсталлируются, но «ниоткуда» появляются новые, более каверзные ошибки. В подобных случаях можно говорить о Синдроме Анны Карениной (САК).

    Вспомним, что синдром представляет собой комплекс органически связанных между собой признаков (симптомов), объединенных единым механизмом возникновения и развития.

    В зависимости от размеров системы САК показывает себя по-разному. Но большинство проявлений сводятся к определённым «скандалам».

    Внизу я попытался привести списки (далеко неполные) характерных симптомов, принадлежащих САК в зависимости от размера системы.

    В энтерпрайзе скандалят люди


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

    • Приходится делать всё больше и больше workarounds.
    • В workflows самозарождаются фантом-инстанции процессов.
    • Инстанции workflow-процессов расщепляются или не заканчиваются корректным образом и начинают блуждать по workflows. В силу их непонятности персонал вольно или невольно проталкивает их дальше и дальше.
    • Автоматика workflows подменяется ручными операциями.
    • Данные правятся с помощью скриптов, запускаемых по ночам.
    • Работающую систему приходится все чаще останавливать и перезапускать.

    В больших клиент-серверных системах скандалят компоненты


    На уровне отдельных систем входящих в большой энтерпрайз, либо независимых больших систем с клиент-сервер архитектурой САК проявляется нередко таким образом:

    • В Банках Данных неожиданно появляются «зомби» (Неполные записи с некорректными внешними ссылками, которые вроде бы не могут быть созданы регулярным скриптами и программами обработки. В немецком ИТ-жаргоне их называют Leichen — трупы).
    • Учащаются торможения системы, когда она «ползает на четвереньках», а порой она просто «падает».
    • Появляются «гиблые места» — группы web-страниц или формуляров ввода данных, пользоваться которыми отваживаются только немногие пользователи.
    • Появляются «заповедные места» — группы масок, доступ к которым без внятных причин организационно или технически закрыт.
    • Учащаются странные ошибки при конвертировании данных, например при посылке их партнер-системам.

    В небольших системах скандалят модули и классы


    На уровне небольших систем (например — Десктоп-Приложений) САК проявляет себя в том что:

    • Теряется идемпотентность операций (например, вычисления, которые в теории не должны менять состояния системы, повторенные несколько раз дают разные результаты.
    • Пользователи жалуются на феномены, которые не удается воспроизвести.
    • Линейные расширения (добавление в систему функциональности основного профиля, например новой бизнес-функции) приводит к ошибкам или отказам в работавших до этого модулях.
    • Вторичные изменения (например, смена цвета в GUI) приводят к ошибкам или отказам в основной функциональности.

    Можно ли поменять квадрант?


    Можно ли для нашей системы, очутившейся в левом нижнем квадранте, поменять его на другой?

    Думаю, не всегда. Иногда систему проще заменить, чем пробовать вылечить. Благо средний срок жизни современных ИТ систем недолог — около 10 лет. (Эта цифра — результат моих наблюдений, а не официальной статистики. Поразительно, что примерно столько же времени требуется для полного обновления клеток нашего организма.)

    Откуда берутся наши проблемы? Как правило, большинство проблем зарождается при неверном выборе или программировании отдельных компонент либо использовании элементов базовых frameworks.

    Например, в своей профессиональной карьере я наблюдал развитие нескольких проектов, которые зарождались на базе реализации предположительно гениальных алгоритмов. Эти алгоритмы были реализованы на устарелых языках программирования. Важность этих изначальных точек роста (ядер)представлялась в начале проекта огромной. Поэтому заказчики настаивали на том, чтобы эти ядра непременно остались в системе.

    Под эти ядра подстраивалась архитектура и даже пользовательский интерфейс систем. В конце-концов стоимость этих прилад в десятки раз превосходила стоимость реализации самих ядер (если бы их реализовали заново). Прилады получались хлипкими и у готовых системы можно было однозначно диагностировать САК.

    Что делать?


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

    Если же система уникальна, слишком заточена на ваш бизнес, или миграция и стоимость лицензий новой системы слишком велики, надо пробовать справиться с САК на месте. Тогда возникает естественный вопрос:

    Что у нас не так?


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

    Часто потому, что в вашей системе есть несколько компонент, которые спрограммированы или сконфигурированы «не по правилам» — не соответствуют зарекомендовавшим себя best practicies или просто здравому техническому смыслу.

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

    Но тогда ...- она станет более похожа на другие удачные системы. Так же, как "… Все счастливые семьи похожи друг на друга."

    Под конец позволю себе предложить специализированную формулировку Принципа Анны Карениной применительно к ИТ-системам и программированию:
    Все удачные системы одной и той же предметной области похожи друг на друга, каждое проблемная система проблематична по-своему.

    Проблемы возникают из-за использования нестандартных, неопробованных, другими словами — «экзотических» решений и компонент. «Экзотические» решения и компоненты «проникают» в систему из-за низкой квалификации или неоправданного энтузиазма разработчиков, менеджеров или заказчиков.

    Если экономические и технические показатели системы плохие, исправление одних ошибок в ней приводит к появлению новых — то скорее всего это проявления Синдрома Анны Карениной. Как правило, в этом случае требуется радикальный рефакторинг системы либо замена её некоторых частей на другие либо всей системы в целом.

    Думаю Ваше мнение, уважаемый читатель, будет интересно и другим читателям Хабра. Поэтому я буду Вам очень признателен, если Вы примете участие в опросе.
    Иллюстрации:

    • Кадр из классической экранизации романа «Анна Каренина» Мосфильм. 1967.
    • Лев Николаевич Толстой. Источник: Википедия
    • Фрэнсис Гальтон. Источник: Википедия
    • Арнольд, Владимир Игоревич. Источник: Википедия
    • Аттрактора Лоренца. Источник: Newcastle Engineering Design Centre — Newcastle University

    Принцип Анны Карениной и мой проектный опыт

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 48
    • 0
      Кроме предметной области нужно учитывать и другие факторы, например порог входа и масштабируемость. Удачные системы в одной предметной области могут быть совершенно разные, если одна рассчитана на не квалифицированного индивидуального пользователя, а другая на транснациональные корпорации. Первая может вообще не требовать инсталляции и конфигурирования, а вторая — целого штата только для запуска.
      • +6
        Кажется, что корень всех зол в том, что мы (разработчики ПО) не умеем произвольно взятую задачу «правильно» декомпозировать на модули. Всякие умные подходы вроде ООП, MVC, DDD, Viper и т.п. не особо в этом помогают. Если представить все варианты реализаций требований как множество, то похоже, в этом множестве лишь немногие точки отвечают «хорошей» системе. В итоге три варианта:
        1. Разработчики уже знают как делать правильно, это называется «опыт в предметной области»;
        2. Приходят к хорошей системе путем непрерывного рефакторинга, стоит это бешеных денег и времени. Раза 3-4 всю системы нужно будет переписать. На практике такое возможно только в своих собственных проектах. Поэтому свои, домашние, проекты, лучше растят скилл по сравнению с коммерческой разработкой.
        3. Делают как показалось вначале правильным, судорожно пытаются найти время на рефакторинг и оказываются в итоге там же, где и большинство — в левой части вашего квадрата.

        Исправить такое незавидное положение можно если придумать некую алгебраическую структуру на множестве требований. Тогда «правильную» архитектуру мы сможем вычислять, с некоторой точностью. Но такого даже на горизонте нет. А пока нужно рассчитывать на опытных коллег, сообщество, общение и передачу знаний о том, что работает, а что нет.
        • 0
          IMHO — пункт «1.» (дорога к нему лежит через все последующие пункты).
          • +2
            «правильность» она тоже разная бывает, что порождает как минимум четвёртый вариант: система создана «правильной» в краткосрочной перспективе, но потенциала развития в долгосрочной нет или он сильно ограничен.
          • +2
            Все здоровые люди похожи друг на друга, каждый больной человек болен по-своему?
            • +2
              С точки зрения медицинского страхования все здоровые (на данный момент) принадлежат к одному кластеру, а больные разбиваются в кластеры в зависимости от диагноза и небольшого ряда других параметров.
              В статьях из области биологии и медицины много упоминаний о Принципе Анны Карениной.
            • –1
              Я для себя давно ещё так сформулировал (на примере хранимых процедур сервера БД):

              Процедура может вернуть различные коды возврата (не равные нулю) в случае каких-либо ошибок, так как причин возникновения ошибок — множество.
              В случае успешной отработки (без ошибок) процедура вернёт код возврата равный нулю (т.е. вариант успешной отработки один; а число «ноль» — также уникальное в своём роде).
              • –3

                Итогом работы программистов является код. Его качество напрямую зависит от "качества" собственно программиста. Следовательно, исследовать нужно причины, а не следствия. Личности, команды и их подготовку, а не их продукты.


                В статье же постулируется банальность. Вероятность совпадения двух и более положительных исходов равна произведению вероятностей. А так как отдельные вероятности всегда меньше 1 вывод очевиден… Хоть Карениной, хоть аттрактором это называйте ;)

                • +2
                  (выступлю без аргументации) Очередная модель, рождённая умелым подбором нужных факторов в нужных толкованиях. Что-то где-то подобное слышал, но на другом уровне и с совершенно другими выводами (где — не помню. М.б., в т.ч. у Роберта Сапольского?).
                  Одни рассуждения про «хорошее/плохое» (я уж думал, что подобные понятия давно остались на уровне детсада, ан нет), «устойчиво/неустойчиво» чего стоят. Как хочу, так верчу. Но зато в конце — какая классная модель!
                  Данная модель, в числе множества других примитивов, была бы хороша, будь она именно примитивом. Сама по себе модель «неустойчива» или «устойчива», смотря как смотреть/толковать, что уже выбивает основание из-под этой модели.
                  Но — талантливо, этого не отнять.
                  • 0
                    {краткое нестрогое ночное замечание от невыспавшегося радиофизика}
                    Проиллюстрируем поведение диссипативных динамических систем (между людьми есть «притяжение»).
                    <> Трудно иметь дело с негрубыми динамическими системами. Бесконечно малое изменение
                    параметров приводит к качественному изменению динамики, к другому аттрактору, другому «результату». Случай «вздорного» супруга, нестабильности психики или соматики. Не будем рассматривать, как предположительно не соответствующий счастливой семье.
                    <> С грубыми — существенно легче. Параметры можно «немного» изменить, а режим останется качественно неизменным.
                    <> Если грубая система существенно диссипативна — начальные условия («детали» встречи) и внешние воздействия играют малое значение в в наблюдаемом эксперименте, «быстро забываются», и аттрактор быстро достигается во временной реализации.
                    <> Если это не так, и степень сжатия элемента объема фазового пространства невелика,
                    приближение к аттрактору будет медленным.
                    — — — — — После введения, переформулируем эффект АК:
                    <> Мы неявно постулируем существование класса подобных семей, которые можно классифицировать как счастливые (единый аттрактор или множество некоторым образом «подобных» аттракторов).
                    <> {наблюдаемый режим}
                    Каждая счастливая семья — на неком аттракторе, который занимает малую область фазового пространства. Наблюдаемый режим семьи «ограничен». Несчастливые — в более «объемной» области наблюдаемых переменных, поведение может быть более разнообразным в каждом рассматриваемом случае. Также выше введен постулат о подобии режимов, свойство «счастье».
                    <> {параметры}
                    Внутренние характеристики каждой семьи (параметры) принадлежат множеству, соответствующему данному аттрактору «счастливая семья». В соответствии с постулатом «счастья», по-видимому, множества параметров подобны, или принадлежат одному общему множеству.
                    <> При анализе истории развития отношений счастливых семей, мы возможно, также обнаружим, что есть общность деталей их встречи (в каждом случае начальные условия принадлежат бассейну притяжения. Бассейны притяжения счастливых семей в первом приближении можно считать «подобными» ).
                    • +2

                      Каждый довоенный шаг участников Первой мировой кажется логичным и взвешенным, но в совокупности они привели к большой войне. Теперь я знаю как это называется. Раньше я называл это фразой из Летова (той, где всё летит в область неустойчивости). Ситуация, где любые логичные улучшения в конечном итоге ведут в пропасть. Здоровская статья, спасибо!

                      • 0

                        Либо действия некоторых участников были недостаточно продуманными, либо война и была целью некоторых, либо в целом ситуация в Европе тех лет наиболее легко могла разрешиться именно войной (по аналогии с термодинамикой — система без притока энергии сама приходит к состоянию термолинамического равновесия)

                        • 0
                          Вероятно тут совокупность из всех трёх факторов. С другой стороны, если бы кто-то смог оценить результаты войны, энтузиазм многих зачинщиков поубавился бы.
                        • 0
                          Каждый довоенный шаг участников Первой мировой кажется логичным и взвешенным
                          Ключевое слово — «кажется». Если послушать историков (было огромное количество интереснейших исторических передач в 2014г. по некоторым радио, в 2017г. была ещё одна волна), то совсем не кажется, а возникает вполне объёмная картина кретинизма, идиотизма и пр.; с логикой там было тяжело.
                          Но это я к словам придрался, извините. Важное здесь то, что ни в коем случае никогда не надо поддаваться соблазну натянуть сложное (впрочем, других не бывает) историческое событие на какую-то подобную модель, которая абсолютно другого уровня действия.
                          • 0
                            Эта ветка комментариев уже довольно далеко отошла от направления основной статьи, но весьма интересная. Насколько я могу судить, история только начинает использовать количественные модели и думать об их адекватности, сложности, непротиворечивости, значимости параметров и т.д. Без них споры историков сводятся к обсуждению только пары аспектов, возможно не самых важных. Например, историки крайне мало говорят об использованных в том или ином историческом процессе финансовых и материальных ресурсах.
                            • 0
                              Ну не совсем оффтоп. Эта ветка комментов отошла в сторону, чтобы со стороны посмотреть на предложенную модель, а заодно посмотреть на аспекты применения моделей вообще. Пытаемся провести анализ не только изнутри модели. А история — классная штука, на которой ломается много зубов при попытке свести её к какой-то модели.
                              количественные модели
                              Кстати, поэтому многие не считают историю наукой.
                              споры историков сводятся к обсуждению только пары аспектов
                              Не соглашусь. Аналитика историков, которую я слышу, как раз включает в себя рассмотрение многих факторов. По крайней мере, добросовестные историки принимают во внимание все доступные источники. Это, конечно, не означает абсолютности их суждений (много объективных причин). Поэтому и интересно (и важно) услышать разных историков.
                              историки крайне мало говорят об… финансовых и материальных ресурсах
                              Тут даже категорически можно не согласиться. Практически всё, что касается войн и революций, особенно 2-й Мировой, как раз базируется на количественном и качественном анализе сил.
                              Историки, здесь они не отличаются от специалистов в любой области знаний, также выбирают значимые, второстепенные и совсем малозначимые факторы, также строят некоторое подобие моделей (так проще самому понять и объяснить другим). Только исторические «модели» никак не соотносятся с нашими терминированными моделями.

                              Чтоб два раза не вставать. По верхам посмотрел что это за принцип. Вижу, роман для красного словца приплели (никакое худ. произведение никакого отношения к реальной жизни не имеет; всё, что там сказано — очередная субъективная модель очередного субъекта). Ощущение какой-то банальщины. В лучшем случае, одна из частных интерпретаций частных же случаев теории систем. Применение принципа сводится к (эмпирическому) набору факторов для каждого отдельного явления/системы. Не учитывается:
                              1) система, в общем случае, динамична, поэтому факторы должны на каждый отрезок времени подбираться заново;
                              2) есть внешние влияние, часто непредсказуемые.
                              Глядя на это, язык не поворачивается назвать это «принципом».

                              Примерно это и имел ввиду по отношению к вашей модели. Закономерные вопросы, из-за которых у каждого участника процесса будет своя (возможно, и не одна) картинка вашей модели IT-системы:
                              1) критерии «хорошо»;
                              2) критерии «устойчивости»;
                              3) критерии выбора факторов и их веса.
                              По каждому пункту — вкусовщина по полной программе.
                              Ну и в чём тогда смысл такой модели, которая не имеет чётких закономерностей своего построения, если практически невозможно прийти к консенсусу всей команде проекта? Навскидку в голову приходит (древовидная?) комплексная модель, состоящая из примитивов вашей модели (минимум факторов с чёткими критериями в каждом примитиве). Но это страшный геморрой, мне кажется.
                              С другой стороны, полностью поддерживаю подобные попытки. Даже такие нежизнеспособные модели помогают включать мозг. Я бы копал в уже наработанных методиках для практического применения (взять нужное из, например, ITIL/ITSM, PMBook {если всю систему представлять как проект}).
                              • 0
                                Вы действительно посмотрели по-верхам. Принцип придуман не мной. Погуглите на английском, почитайте соответствующую статью в Википедии.
                                Существует ли принцип или нет, каждый решает для себя. Я считаю что он стоит в ряду с другими философскими принципами типа перехода количества в качество.
                                В каком-то смысли это мета-принципы, которые можно конкретизировать для конкретных областей. Я попытался сделать это для ИТ и программирования.
                                Кстати, а обсуждении ангоязычного варианта статьи были очень любопытные выходы. В одном из форумов пришли к заключению о необходимости референтных моделей для предметных областей и типовых процессов.
                                Про ITIL не знаю, но одна фирма поблагодарила меня и сообщила о расширении своего материала иныормацией об этом принципе.
                                А что вы конкретно понимали в «копанием» ITL и т.д.?
                                • 0
                                  Странно, но ровно всё это я и описал, но общими словами, чтобы не замыкаться на конкретной задаче. Значит, недостаточно понятно.
                                  ITIL это то, что первое пришло на ум. На самом деле, если посмотреть упомянутые библотеки и другие серьёзные документы в IT (вспомнился SWEBOK), то можно увидеть определённые закономерности в том, как сформулированы цели/задачи, способы их достижения, контроля и кучи других процессов. Там логика очень похожая. И лично я там не увидел подхода типа вашей матрицы «запихать все показатели в один комплекс и получить чёткий ответ». Наоборот, увидел, что есть стремление разложить явления максимально атомарно, на основании чего дальше проводить аналитику и принимать решения. В т.ч. работа с «примитивными» матрицами.
                                  Ваш подход похож на очень любимые многими технократические приёмы принятия решений на основе KPI с кучей параметров, многие из которых притянуты в числовую область за уши. Это же так прикольно — зарыться в математику, красивые таблички и диаграммы. Ваше предложение отличается только подачей этой смеси борща, второго и компота в другой визуальной форме. Народ начинает строить какие-то немыслимые конструкции с многочисленными параметрами, забывая про зыбкость и субъективность каждого KPI. Поэтому в 10-й раз повторяюсь, если хочется достигнуть реальной цели, а не поиметь славу/денег/и прочего самоудовлетворения, придётся идти от простого к сложному постепенно, а не сводить офигительную комплексную сложность, даже оценки работы ПАК, к плоской картине с красивым названием. Зато это эффектно, согласен. Изучать и понимать накопленный опыт, потом уметь применять — не наш путь.
                                  Из той же серии, но глобальнее. Был поражён, увидев Cybersyn. Насколько понимаю, уже в то время должна была быть понятна утопичность построения технократической модели управления. Даже не будь никакого Пиночета, представляю, в какую задницу привела бы эта система всю страну. Но нет, нашлись смельчаки ))
                                  • 0
                                    Я не думаю, что используемый вами стиль диалога и способ аргументации способствует развитию интересных дискуссий.
                                    Очевидно, Вы относитесь как и примерно 11% процентов участвующих в опросе к скептикам относительно существования Принципа Анны Карениной.
                                    Это Ваш личный выбор, стоит ли прислушиваться к позиции большинства коллег (по крайней мере из усастников опроса).
                        • 0
                          я бы дополнил принцип Анны К. принципом Шрека (с уточнениями от Ослика):
                          Людоеды ИТ технологии и решения — как лук.
                          — Воняют?
                          — Да нет.
                          — От них все плачут?
                          — Нет.
                          — Если их оставить на солнце, то они темнеют и покрываются пятнами?
                          — Нет! Я говорю про слои! И у тех и у других есть слои, понятно?
                          — У тортов тоже есть слои! Значит, ты ИТ — как торт? »
                          Шрек (Shrek)
                          • 0

                            Следуя этой логике, если у систем с САК есть общие признаки, то они одинаково неустойчивы. Это несколько противоречит идее статьи о том, что устойчивость имеет ряд общих признаков, позволяющих ей быть устойчивой. А у неустойчивой системы нет общих признаков, которые позволяли бы ей быть неустойчивой.

                            • 0
                              Есть общие принципы и устойчивости и неустойчивости. Система одновременно может быть и устойчива и неустойчива (по разным «направлениям»). И можно рассматривать общие характеристики сложной динамики подобных систем.
                              Управление подобными системами рассматривает направление «управление хаосом»
                            • +3
                              Проблемы возникают из-за использования нестандартных, неопробованных, другими словами — «экзотических» решений и компонент.

                              Именно этим принципом на моей памяти руководствывались все менеджеры, выбирая Oracle (ведь большинство успешных компаний юзает эту СУБД). Других аргументов не было. В итоге мы приходим к некоторому стадному эффекту.

                              • 0
                                Еще можно притянуть к статье принцип оптимальности/эффективности по Парето, когда система как целое не «убыточна» в широком смысле, но улучшение параметров какой-либо из компонент системы может обернуться негативно для остальных элементов.
                                • +1
                                  притянуть в статью можно все что угодно,
                                  один автор недавно притянул джеб кличко как новую методологию управления проектом и линейной деятельностью.
                                  для писателя- это полезно, набивает руку писать тексты.
                                  вопрос в том — а какой инструмент дает чтение такой статьи читающему? Какие задачи он после прочтения станет решать по другому? что это дает его мировоззрению?
                                  не заценили выше принцип Шрека, хорошо — есть у меня и еще:
                                  если вам не на чем больше прокрастинировать, как на подобных статьях — то… прокрастинируйте на здоровье. если уж все равно заняться больше нечем достойным.
                                  принцип школьника — необходимо занимать свое мышление ЧЕМ НИБУДЬ, вдруг что-то из этого (тригонометрия или толстый роман Толстого) окажется когда-нибудь полезным. а не окажется — ну и хрен с ним мы не спешим, будем ждать вдруг окажется.
                                  • 0
                                    Немецкие менаджеры очень любят такую формулировку Принципа Паретто: «80% функциональности можно разработать за 20% бюджета». В соответствии с этим принципом начинают с самых «дешевых но сердитых» фичей. Такая «жадная» стратегия выбора фич часто приводит очень печальным результатам. Берлинский аэропорт и Гамбургская Опера тому примеры. Хотя конечно без коррупции там тоже не обошлось, имхо.
                                    Но всё же это другая тема, имхо.
                                    • 0
                                      Принцип Паретто не имеет отношения к статье. Однако же так называемая «оптимальность по Паретто» вполне
                                      • 0
                                        Гамбургская Опера тому примеры
                                        Спросил у знакомой в Гамбурге, что не так. Цитата:
                                        С оперой все в порядке, они имеют ввиду новую филармонию. Ее строительство стоило дороже запланированного и длилось на пару лет дольше. Зато за год с ее открытия для нее не напечатали ни одной рекламы, все концерты раскуплены сразу, несмотря на дорогие билеты. Она уже окупилась-)
                                        • 0
                                          Вы посоветуйте своей знакомой прочитать вот эту статью в немецкоязычной Википедии. Стоило здание в итоге в 3.5 раз дороже, чем договаривались вначале. Строили его на 7 лет дольше запланированного. С помпой сдали, но после нескольких переломанных зрителями костей закоыли на ремонт. Он по сей день интенсивно ведётся в некоторых местах здания. Это я на этой неделе по телевизору слышал.
                                          С математикой Ваша знакомая явно не в ладах. Посчитайте сами, как при паре не очень больших концертных залов, гостинице и нескольких ресторанах внутри здания можно за год заработать около 800 миллионов евро. Правда жизни такова, что город расчитывает за 20 лет отдать взятые под строительство кредиты. При этом город взял на себя много непрямых расходов по эксплуатации здания. Но знатоки относятся к этим расчётом очень скептически. И немецкое общество налогоплательщиков остро этот прект критикует.
                                          Городской совет особенно и не возражает. Говорит что строительство затеяно из престижа, чтобы у города был символ, как у Парижа его знаменитая башня.
                                          Вот в чём Ваша знакомая права — это с названием. Официальное название строения — Elbphilharmonie. Но в народе и даже по телевизору его всё-же часто называют оперой.
                                          • 0
                                            Почитал — впечатлило. Целый ряд нюансов в этой истории )) (мне интересно, т.к. видел стройку и 1-го этапа, и уже ближе к окончанию). Только, кажется, эта история больше про законные способы обогащения, а не про всякие там модели, принципы Паретто и т.п.
                                    • +1
                                      Попробую продолжить правильную мысль andreyverbin – и чуть более расширенно описать факторы, благодаря которым, на мой взгляд (цитата) «Все удачные системы одной и той же предметной области похожи друг на друга». Понимаю, что сейчас выступлю в роли Кэпа. Но оно работает. Хотя, к сожалению, об этих простейших вещах часто забывают, что и порождает пресловутый САК…

                                      1) Разработка «сверху вниз». Сначала проектирование «на бумаге» чёткой архитектуры проекта, проработка возможностей масштабирования, выбор инструментария и т.д. Только потом непосредственная разработка.
                                      Этим должны заниматься разные люди. «Стратеги» определяют общий план (не вдаваясь в частности), «тактики» определяют методы его реализации (при необходимости указывая «стратегам» на эти самые частности). Сообща вырабатывают наиболее оптимальные решения, тем самым страхуя друг друга от ошибок проектирования и/или реализации. Поэтому в проекте критически важно наличие специалистов обоих типов.
                                      В противном случае чаще всего получается печально знаменитый «индусский код», в процессе отладки которого ошибки могут множиться как головы Лернейской гидры – на месте одной пофиксенной появляются две новые…

                                      2) В команде обязательно должен быть хотя бы один аналитик с так называемым «негативным мышлением», способный думать на несколько шагов вперёд. Который, конечно же, дико замучает всех своими опасениями – но зато с высокой долей вероятности «предскажет» все возможные риски, подводные камни и прочие слабые места.
                                      Не в обиду (и не в упрёк) будет сказано, но непосредственные разработчики нередко просто физически неспособны на подобный критический анализ всего проекта, будучи полностью загружены решением локальных технических задач.

                                      3) По возможности ограничить использование в крупных проектах сторонних библиотек и компонентов. Согласен, что писать самим нередко дольше и сложнее. Но в своём коде всегда проще разобраться и найти проблемные места. Кроме того, в этом случае можно будет с самого начала «заточить» все необходимые модули конкретно под архитектуру текущего проекта.
                                      Впрочем, этот пункт сугубо ИМХО. Ситуации бывают разные.

                                      4) И, наконец – грамотный менеджмент проекта, с чётко выстроенной иерархией и чётко прописанными должностными обязанностями.
                                      Чтобы разработчики, с одной стороны, не метались между разнородными (и порой противоречащими друг другу) указаниями и комментариями различных начальственных инстанций, а с другой стороны – и не были предоставлены сами себе, действуя «кто в лес, кто по дрова».
                                      Причём, все обсуждения желательно фиксировать в письменном виде – хоть в тех же мессенджерах. Увы, необходимая бюрократия. Но она значительно снижает риск появления «ничейных» ошибок (поиск которых в крупных проектах подобен поиску иголки в стоге сена). Поскольку всегда можно поднять «логи» всех указаний/комментариев – за счёт чего гораздо проще выследить всю цепочку ошибочных решений. На всякий случай, уточню: это не с целью «поиска крайнего», а именно с целью локализации проблемных участков проекта.

                                      Вот как-то так видится…

                                      P.S. К слову, в продолжение темы безвременно усопшей госпожи Карениной (а также в тон статье), многое из вышеперечисленного применимо и наоборот – к человеческим отношениям. Круг замкнулся. ))
                                      • +1
                                        Программисты, научные сотрудники, инженеры должны делать обобщения по долгу службы, но иногда это заходит слишком далеко. Проявляется это в желании построения некой единой теории, которая может обобщить если не вселенную в общем, то жизнь индивида или хотя бы род его деятельности. Такие теории бывают двух видов. Первые ввиду чрезмерной абстрактности имеют нулевую предсказательную способность. Вторые имеют предсказательную способность, но не имеют четко обозначенных границ применения, которые все же четко существуют в голове теоретика, но вслух не произносятся.
                                        • 0
                                          Спасибо за ценное дополнение к статье. Я думаю, общепризнанные философские принципы типа «Переход количества в качество», «Единство и борьба противоположностей» а также менее признанные типа «Принципы Анны Карениной» или упоминавшегося в одном из комментариев «Принципа Паретто» относятся ко второй категории. Они имеют очевидную предсказательную способность, но их границы определения очень трудно определить.
                                          • 0

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


                                            Время от времени и правда появляется желание все взять и обобщить.

                                          • 0
                                            Не все неустойчивое плохо и не все устойчивое хорошо.

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


                                            Автор статьи немного не понял смысла сказанного в книге.
                                            Арнольд как раз говорил о том что хождение по бревнышку — является пределом устойчивости, за границей которого находится канава. То есть свалиться в канаву с бревна у нас больше шансов, чем пройти по бревну невредимым.
                                            • 0
                                              Сначала я в конце цитируемого предложения поставил смайлик, но потом его удалил, вспомнив что на Хабре они не приветствуются. Так или иначе, это была попытка немного пошутить по ходу повествования. Но и в этой шутке есть доля правды. Я сравниваю на самом деле два состояния: движение по бревну и лежание в канаве. Вы же сравниваете шансы свалиться и не свалиться. Т.е. — наши высказывания друг-другу не протвиворечат, поскольку речь идет о разных сравнениях.
                                            • +1
                                              Прочитал с удовольствием! ИМХО статья есть иллюстрация к понятию энтропии.
                                              • 0
                                                Как раз в ИТ наблюдается обратное — схожие проблемы успешно решаются совершенно разными способами.
                                                • 0
                                                  Задумался, а не является ли вариантом «Принципа Анны Карениной» старая сентенция: «Лучшее враг хорошего». Все «хорошее» более однородно чем «лучшее».
                                                  • 0
                                                    Я попытался в своей статьи оттолкнутся от филослфской части Принципа Анны Карениной и перейти к его конкретным проявлениям в области программирования и ИТ. Движение в противоположном направлении чревато издишним обощением у которого, как отметил PerlPower очень низкая предсказательная способность. Такие обощения описываются в частности фразами народной мудрости, фольклёром и т.д.
                                                    В общем — я думаю в определённом контексте Ваше утверждение верно.
                                                    • 0
                                                      С многими тезисами из статьи достаточно часто сталкиваюсь.
                                                      • +1

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


                                                        Изложение принципа в приложении к одомашниванию тоже некорректно.
                                                        Одомашнивались животные очень по разному.
                                                        Сравните кошку и собаку и их контракты на жизнь рядом с человеком.
                                                        А если упрощать, то не одомашниваемые тоже "одинаковые". Для них просто не нашлось подходящего контракта с человеком (подходящего человеку, конечно).


                                                        В реальности же можно говорить об ограниченном количестве приемлемых известных решений (то самое "одинаковое счастье" в терминах принципа Анны Каренниной).
                                                        Но однажды находится кто-то, кто находит новое решение и открывает "новый способ быть счастливым", расширяя список решений. Но люди стремятся к упрощению, и принимая новое решение забывают о чем-то старом. А потому новый способ может оказаться как действительно новым, так и давно забытым старым.
                                                        А еще хуже, когда следуя принципу Анны Карениной всех загребают под одну гребенку, объявляя что-то одно верным и каноническим, а все остальное ересью, не признавая счастье тех, кто продолжает быть счастливым "неправильно". Но те, кто вроде должен быть одинаково счастливым, частенько оказываются по разному несчастными, пытаясь следовать "единственно правильному решению проблемы счастья".

                                                        • 0
                                                          Я не согласен со всеми Вашими заявлениями.
                                                          1) Принцип Анны Карениной это по-сути модель. Любая модель проще описываемой реальности. Если речь идёт о динамических системах, интересен аспект предсказательной способности модели. А она может быть и отрицательная и положительная.
                                                          2) Термин «одомашнивание животных» я использовал строго в соответствии с цитируемой книгой. Если Вы эту книгу не читали, очень советую прочитать. Если Вы под одомашниванием понимаете что-то другое, чем в книге, то сначала надо договориться о терминах. И только потом заявлять о правильности или неправильности.
                                                          3) Принцип Анны Карениной — это инструмент. Им можно пользоваться или не пользоваться. Можно пользоваться неправильно, «загребая всех под одну гребёнку».
                                                          • 0

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

                                                            • 0
                                                              Боюсь что поздно выставлять претензии к автору цитаты про счастливые и несчастливые семьи (Шутка)
                                                          • 0
                                                            Если сторонняя оценка показателей «системы» плохая (у Анны она сначала была), то энергичное исправление видимых ошибок без объективной внешней оценки приводит к появлению новых, то есть «система» забуксовала в своей субъективности, поэтому следовало бы начать объективно разбираться с того места, когда показатели были относительно хорошие.
                                                            Так как все удачные «системы» одной и той же предметной области похожи друг на друга по объективным показателям во времени, то и каждая «система» может быть проблемная по своим субъективным показателям.
                                                            Проблемы могут возникать из-за решения лиц привлечь работников низкой квалификации с «экспериментальными» решениями, которые «проникают» в открытую и ослабленную «систему» из-за необходимости ее большей устойчивости во времени при осознаваемом обоюдном риске и энтузиазме получить эффект решения проблемы, а только потом оценку результатов (принцип «эксперимента").
                                                            Но итоге «система» выживет только так: объективная оценка — «высокая» квалификация – устойчивость системы с оценкой рисков – показатели – оценка показателей.
                                                            То есть Принципа Анны Карениной может и существует, но как недооценка или переоценка объективных показателей во времени, то есть как неудачный «эксперимент» с суммой субъективных оценок. Но остается «открытым» вопрос: нужны ли кому-то такие эксперименты?
                                                            • 0
                                                              Если ваша система не совсем хороша или совсем нехороша, но устойчива и делает своё дело (находится в неустойчиво-хорошей части мира), вам следует хорошенько подумать, а стоит ли рисковать и что-то радикально менять.

                                                              … вам можно примерять лавры чудотворца. Вы умудрились устойчиво-плохую систему запихать в неустойчиво-хороший квадрант.
                                                              Ну или злого гения.

                                                              • 0
                                                                Спасибо за комплимент. Позвольте и мне. Более тридцати тысяч прочитали, а Вы первый обратили внимание и сообщили об опечатке. Я её исправил.

                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.