Принцип Анны Карениной в программировании и ИТ
«Принципу Анны Карениной» посвящено немало научных публикаций и даже отдельная статья в Википедии. Применим к ИТ и программированию? А может он уже работает против вашего проекта?
Первый вариант этой статьи я опубликовал в моём англоязычном блоге и поместил ссылки в несколько узкоспециализированных форумов. Состоявшиеся там обсуждения мотивировали меня предложить её вариант на русском языке читателям Хабра.
В статье обсуждается один из философских принципов, который с точки зрения автора:
а) обьективно существует
б) релевантен для ИТ-проектов и программирования.
Если Вам, дорогой читатель, такие темы не интересны, вряд ли Вам стоит читать эту статью дальше.
Недавно я перечитал великий роман Льва Толстого «Анна Каренина».
Первый раз я прочитал его в школьные годы, поскольку того требовала от нас учительница литературы. Но чтобы понять такие книги, их надо читать в зрелом возрасте, накопив достаточно своего личного жизненного опыта и понимания людских характеров.
От главы к главе Лев Толстой описывает происходящие события, как бы наблюдая их глазами того или иного участника событий. И поступки некоторых героев романа, которые до этого воспринимались легкомысленными выходками или проявлениями их злой воли, рассмотренные с другой перспективы, кажутся глубоко логичными и даже единственно возможными.
А по прочтению романа остается впечатление, что иначе и не могло быть. Легкий флирт между замужней женщиной и молодым блестящим аристократом-офицером переходит в страстную любовь, затем — в моральный надлом отношений между влюблёнными и, в финале — самоубийством героини под колесами поезда.
И каждое звено в этой ужасной цепи событий в момент прочтения представляется понятным и логичным.
Прочитав роман, каждый может сам для себя решить, что означает это загадочное, самое первое предложение романа: 
«Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему.»
Одно из возможных объяснений состоит в том, что Лев Толстой в этом предложении сформулировал куда более общий философский принцип, который проявляется в медицине, социологии, биологии, глобальных геофизических явлениях и, по моему мнению — в ИТ в целом и в программировании в частности.
Что означает Принцип Анны Карениной?
Интерпретациям этого принципа, получившего имя «Принцип Анны Карениной», посвящено немало научных публикаций и даже отдельная статья в Википедии.
Что означает этот принцип? Очень сложные химические, физические, биологические, психологические, социальные и т.п. системы могут долго и успешно существовать и развиваться только если их части хорошо подходят друг к другу и к внешней среде.
Если бы мы были в состоянии описать такие системы каким-то количеством параметров, то заметили бы, что для каждого класса систем существует совсем немного «успешных» комбинаций этих параметров.
Замечание: Для придания нашим параметризованным моделям большей реальности мы должны говорить не об отдельных значениях параметров, а об классах эквивалентности параметров. Но это не меняет сути.
Как это ни парадоксально, но чем сложнее класс систем, тем меньше у него «успешных» комбинаций.
Кофеварки различных производителей отличаются друг от друга по используемым техническим решениям и даже по внешнему виду сильнее, чем легковые автомобили, а те — сильнее чем пассажирские самолёты.
Принцип Анны Карениной и одомашнивание животных или ограниченность и вторичность параметров отбора
Британский ученый Фрэнсис Гальтон, живший одновременно с Толстым, сформулировал похожий на Принцип Анны Карениной принцип, рассматривая одомашнивание животных: 
Складывается впечатление, что все дикие животные имели шанс сделаться домашними. При этом немногие… были одомашнены давным-давно, а огромное число остальных, когда-то не использовавших свой шанс из-за какой-то мелкой особенности, так и обрекли себя на вечное дикое состояние.
Дальнейшие интересные рассуждения о том, как сработал этот принцип можно найти в увлекательно написанной книге Джареда Даймонда «Ружья, микробы и сталь».
Глава 9. Зебры, несчастливые браки и принцип «Анны Карениной» этой книги начинается такой фразой (в переводе на русский):
Все одомашниваемые животные похожи друг на друга, каждое неодомашниваемое животное неодомашниваемо по-своему.
Если вам показалось, что где-то вы уже читали нечто подобное, вы не ошиблись. Поменяйте несколько слов, и получится знаменитое первое предложение «Анны Карениной», великого романа Льва Толстого: «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». Этой фразой Толстой хотел сказать, что счастливым может быть только брак, состоявшийся во множестве разных аспектов: между супругами есть обоюдное сексуальное притяжение, налажены отношения с родней друг друга, нет разногласий по поводу финансов, воспитания детей, религии и остальных жизненно важных вопросов. Неудача на одном из этих важнейших направлений способна погубить брачный союз, даже если у него есть все остальные компоненты для счастья.
Далее автор называет факторы, которые не позволили, несмотря на многочисленные и продолжающиеся до сих пор попытки одомашнить диких животных. Их немного: рацион питания, скорость роста, проблемы с размножением в неволе, «дикость» характера, склонность к панике, социальное устройство.
Интересно отметить тот факт, что все перечисленные автором факторы — «вторичные». Например, человечество выращивает и забивает на мясо не носорогов (3 тонны мяса), а куда более мелких животных — коров, свиней и овец.
Другими словами, если бы мы программировали алгоритм отбора животных для одомашнивания, нам в качестве параметров пришлось бы использовать не первичные атрибуты этого вида животных (вес, рост, продолжительность жизни и т.д.), а вторичные, вычисляемые с помощью специальных функций. И уже на них мы бы накладывали весьма жесткие ограничения.
Если вам это интересно, то найдите и почитайте книгу.
Но автор объясняет действие принципа в конкретной предметной области. Имеется его более широкая интерпретация?
Принцип хрупкости хорошего
Взглянуть на проблему с более широких и в тоже время чисто математических позиций попытался гениальный математик Владимир Арнольд в своей книге «Теория катастроф»
Там он описывает т.н. «Принцип хрупкости хорошего».
Он пишет: 
… для системы, принадлежащей особой части границы устойчивости, при малом изменении параметров более вероятно попадание в область неустойчивости, чем в область устойчивости. Это проявление общего принципа, согласно которому всё хорошее (например, устойчивость) более хрупко, чем плохое. По-видимому, все хорошие объекты удовлетворяют нескольким требованиям одновременно, плохим же считается объект, обладающий хотя бы одним из ряда недостатков
.
В рассматриваемом им контексте Владимир Арнольд возможно был и прав. Но в более широком контексте можно видеть, что на самом деле он говорит о хрупкости, а точнее — о редкости устойчивости, а не «хорошести».
Не все неустойчивое плохо и не все устойчивое хорошо.
Кто хоть раз в жизни переходил лужу или канаву по бревнышку, меня понимает. Неустойчиво двигаться по бревнышку лучше, чем свалиться вниз и принять в канаве устойчивое положение.
С другой стороны -любое движение скорее неустойчивость. Деревья и цветы хороши пока они живы и растут, а засохнувшие — как правило нет.
И в то же время, про дерево, растущее сотни лет, интуитивно хочется сказать, что оно стабильно (устойчиво) растет.
Подведем промежуточный итог: Устойчивость (стабильность) и «хорошесть» — показатели скорее независимые друг от друга и зависят от того, что же мы измеряем или моделируем. При этом следует добавить, что устойчивость — это скорее объективный, измеряемый параметр. Что такое хорошо и что такое плохо — это субъективное решение наблюдателя.
Принцип Анны Карениной и аттракторы
Размышляя о динамической неустойчивости, мы почти неизбежно придем к понятию хаоса.
Теория хаоса — сравнительно молодая наука. О её становлении и первых шагах увлекательно рассказывает книга »Хаос. Создание новой науки» Джеймса Глейка. Один из самых увлекательных сюжетов в этой книге — открытие такого явления как аттракторы.
Согласно определению Википедии -Аттра́ктор (англ. attract — привлекать, притягивать) — компактное подмножество фазового пространства динамической системы, все траектории из некоторой окрестности которого стремятся к нему при времени, стремящемся к бесконечности. Аттрактором может являться притягивающая неподвижная точка (к примеру, в задаче о маятнике с трением о воздух), периодическая траектория (пример — самовозбуждающиеся колебания в контуре с положительной обратной связью), или некоторая ограниченная область с неустойчивыми траекториями внутри (как у странного аттрактора).
Внизу изображен один из вариантов Аттрактора Лоренца.
Какое отношение имеют аттракторы к Принципу Анны Карениной?
Я думаю, с философской точки зрения аттракторы представляют в мире хаоса «одинаковые счастливые семьи» в то время как остальные точки фазового пространства — «несчастливые семьи, несчастливые по-своему».
В колоде мало козырей…
Вы наверняка слышали о долгих спорах Эйнштейна и Бора о фундаментальных основах квантовой физики. Дискуссия велась вокруг вопроса, какая модель определяет траекторию отдельной элементарной частицы: детерминистская или вероятностная. Два великих физика абстрагировали суть спора до полушутливого вопроса: Играет ли Бог в кости, управляя движением частиц, составляющих наш мир?
За прошедшее столетие модели описания мира невероятно умножились и усложнились. Продолжая линию Эйнштейна и Бора применительно к нынешней ситуации мы можем сказать, что для управления миром Богу необходимы инструменты посложнее, чем игральная кость. Например — колода карт.
Тогда, с учетом Принципа Анны Карениной можно сказать, что колоды карт, которые Бог выбирает для управления природными и социальными феноменами, как правило, не очень хороши. В них слишком мало козырей…
Ну, а сами феномены делятся на устойчивые и неустойчивые. При этом «очень» неустойчивые со временем часто «скатываются» на аттракторы.
Как мы поделим их на хорошие и плохие — зависит от нас. Но похоже, в нынешнем мире больше неустойчивого, чем устойчивого. А плохого больше чем хорошего.
Другими словами, мир выглядит так, как на моей картинке внизу.
Принцип Анны Карениной в ИТ
Все это может и похоже на правду, возможно уже подумал про себя кто-то из читателей. Но где обещанные в заголовке ИТ и программирование? Действует Принцип Анны Карениной в этих областях человеческой деятельности?
Уверен, действует. Хотя бы потому, что этот общий принцип просто должен действовать и в этой конкретной предметной области. По крайней мере для тех программно-аппаратных и чисто программных систем, которые достаточно сложны и динамичны. А многие из них действительно таковы.
Синдром Анны Карениной
Если Принцип Анны Карениной (ПАК) в ИТ присутствует, как его заметить?
Во-первых, если ваша система работает стабильно и позволяет себя безболезненно расширять и конфигурировать, вам не стоит особенно беспокоиться. Ваша система находится в устойчиво-хорошей части (см. картинку вверху).
Если ваша система не совсем хороша или совсем нехороша, но устойчива и делает своё дело (находится в неустойчиво-хорошей части мира), вам следует хорошенько подумать, а стоит ли рисковать и что-то радикально менять.
ПАК начинает показывать себя со своей негативной стороны, если попытки исправить конкретные ошибки только ухудшают ситуацию. Ошибки действительно исправляются, патчи инсталлируются, но «ниоткуда» появляются новые, более каверзные ошибки. В подобных случаях можно говорить о Синдроме Анны Карениной (САК).
Вспомним, что синдром представляет собой комплекс органически связанных между собой признаков (симптомов), объединенных единым механизмом возникновения и развития.
В зависимости от размеров системы САК показывает себя по-разному. Но большинство проявлений сводятся к определённым «скандалам».
Внизу я попытался привести списки (далеко неполные) характерных симптомов, принадлежащих САК в зависимости от размера системы.
В энтерпрайзе скандалят люди
В больших энтерпрайз-системах программные и аппаратные проблемы ИТ-компонент быстро трансформируются в скандалы менеджеров и психологические войны подразделений между собой. Если попытаться отфильтровать субъективно-психологические аспекты, то часто остаются объективно регистрируемые феномены:
- Приходится делать всё больше и больше workarounds.
- В workflows самозарождаются фантом-инстанции процессов.
- Инстанции workflow- процессов расщепляются или не заканчиваются корректным образом и начинают блуждать по workflows. В силу их непонятности персонал вольно или невольно проталкивает их дальше и дальше.
- Автоматика workflows подменяется ручными операциями.
- Данные правятся с помощью скриптов, запускаемых по ночам.
- Работающую систему приходится все чаще останавливать и перезапускать.
В больших клиент-серверных системах скандалят компоненты
На уровне отдельных систем входящих в большой энтерпрайз, либо независимых больших систем с клиент-сервер архитектурой САК проявляется нередко таким образом:
- В Банках Данных неожиданно появляются «зомби» (Неполные записи с некорректными внешними ссылками, которые вроде бы не могут быть созданы регулярным скриптами и программами обработки. В немецком ИТ-жаргоне их называют Leichen — трупы).
- Учащаются торможения системы, когда она «ползает на четвереньках», а порой она просто «падает».
- Появляются «гиблые места» — группы пользовательских масок, пользоваться которыми отваживаются только немногие пользователи.
- Появляются «заповедные места» — группы масок, доступ к которым без внятных причин организационно или технически закрыт.
- Учащаются странные ошибки при конвертировании данных, например при посылке их партнер-системам.
В небольших системах скандалят модули и классы
На уровне небольших систем (например — Десктоп-Приложений) САК проявляет себя в том что:
- Теряется идемпотентность операций (например, вычисления, которые в теории не должны менять состояния системы, повторенные несколько раз дают разные результаты.
- Пользователи жалуются на феномены, которые не удается воспроизвести.
- Линейные расширения (добавление в систему функциональности основного профиля, например новой бизнес-функции) приводит к ошибкам или отказам в работавших до этого модулях.
- Вторичные изменения (например, смена цвета в GUI) приводят к ошибкам или отказам в основной функциональности.
Можно ли поменять квадрант?
Можно ли для нашей системы, очутившейся в левом нижнем квадранте, поменять его на другой?
Думаю, не всегда. Иногда систему проще заменить, чем пробовать вылечить. Благо средний срок жизни современных ИТ систем недолог — около 10 лет. (Эта цифра — результат моих наблюдений, а не официальной статистики. Поразительно, что примерно столько же времени требуется для полного обновления клеток нашего организма.)
Откуда берутся наши проблемы? Как правило, большинство проблем зарождается при неверном выборе или программировании отдельных компонент либо использовании элементов базовых frameworks.
Например, в своей профессиональной карьере я наблюдал развитие нескольких проектов, которые зарождались на базе реализации предположительно гениальных алгоритмов. Эти алгоритмы были реализованы на устарелых языках программирования. Важность этих изначальных точек роста (ядер)представлялась в начале проекта огромной. Поэтому заказчики настаивали на том, чтобы эти ядра непременно остались в системе.
Под эти ядра подстраивалась архитектура и даже пользовательский интерфейс систем. В конце-концов стоимость этих прилад в десятки раз превосходила стоимость реализации самих ядер (если бы их реализовали заново). Прилады получались хлипкими и у готовых системы можно было однозначно диагностировать САК.
Что делать?
Энтерпрайз часто может позволить себе радикальное решение — замену одной компоненты на другую. Часто это действительно единственно приемлемое, хотя и очень болезненное решение.
Если же система уникальна, слишком заточена на ваш бизнес, или миграция и стоимость лицензий новой системы слишком велики, надо пробовать справиться с САК на месте. Тогда возникает естественный вопрос:
Что у нас не так?
Вот это ключевой вопрос. Почему конкурирующая или схожая система не падает в этом месте, а ваша падает?
Часто потому, что в вашей системе есть несколько компонент, которые спрограммированы или сконфигурированы «не по правилам» — не соответствуют зарекомендовавшим себя best practicies или просто здравому техническому смыслу.
Если их найти и системно исправить, заменить, правильно сконфигурировать — то может быть, ваша система станет менее уникальной, экзотичной, эзотерической, загадочной, но зато перестанет вас мучить. Но повторюсь — задача не в том, чтобы исправить накопившиеся ошибки, а в том, чтобы провести системный анализ и по его итогам сделать рефакторинг или реинжениринг вашей системы.
Но тогда …- она станет более похожа на другие удачны системы. Так же, как »… Все счастливые семьи похожи друг на друга.»
Под конец позволю себе предложить специализированную формулировку Принципа Анны Карениной применительно к ИТ-системам и программированию:
Все удачные системы одной и той же предметной области похожи друг на друга, каждое проблемная система проблематична по-своему.
Проблемы возникают из-за использования нестандартных, неопробованных, другими словами — «экзотических» решений и компонент. «Экзотические» решения и компоненты «проникают» в систему из-за низкой квалификации или неоправданного энтузиазма разработчиков, менеджеров или заказчиков.Если экономические и технические показатели системы плохие, исправление одних ошибок в ней приводит к появлению новых — то скорее всего это проявления Синдрома Анны Карениной. Как правили, в этом случае требуется радикальный рефакторинг системы либо замена её некоторых частей на другие либо всей системы в целом.
Думаю Ваше мнение, уважаемый читатель, будет интересно и другим читателям Хабра. Поэтому я буду Вам очень признателен, если Вы примете усастие в опросе.
Иллюстрации:
