Прочитал “Toward a theory of evolution as multilevel learning”. Как бы я трактовал эту работу в контексте своего проекта? Рассмотрю пересечение феноменов этой эволюции и моих наблюдений ИТ-продукта.
Продукт это не только запущенная программа на сервере, но и люди, которые участвуют в создании ценности для пользователя продукта. Первый феном - существование агентов на любом уровне организации. В компании это, например, отдел-агент и сотрудник-агент, а в ит-системе это сам ит-продукт-агент и сервера-агенты. Хоть сама ит-система не живая по сути, но живой по поведению ее делают люди, программируя её. Отделы отделяют себя от других отделов и при взаимодействии с ними учатся и изменяют себя.
Второй феномен - фрустрация. В любой системе всегда есть что-то что не устраивает агентов, какие-то проблемы. Устраняя эти проблемы агентам становится жить легче, менее затратно энергетически. Добавление каких-то регламентов в работе, шаблонов, внедрение новых технологий в продукт. Такие изменения влекут другие изменения и влияют на всю компанию и продукт. Все внутри изменяется всегда и всегда появляются другие проблемы требующие решения - задач оптимизации.
Третий феномен - многоуровневая иерархия. Я уже затронул ее при описании агентов. Малая компания, которая состоит из отделов растет, увеличивается количество отделов. В какой-то момент у директора не хватает времени на управления и появляются департаменты (новый уровень), которыми он управляет, а те в свою очередь управляют отделами. В микросервисной архитектуре ит-системы появляются оркестраторы, у объектов появляются абстракции, у классов стратегии.
Четвертый феномен - близость к оптимальности. Есть определенные проблемы, которые приемлемы для нас. Мы их не решаем. Например в ит-системе могут копиться слишком много логов в течении года и мы решаем, что проще заходить раз в год и их чистить, чем находить “правильное” решение. То есть применяем “заплатку”, “обходной путь”. Но если проблема очень большая, - например каждое изменение требует ручного регресса всей системы, который идет две тысячи человеко-часов, то мы вынуждены искать “правильное” решение. Мы решаем писать автотесты, но заранее не уверены в успехе, у нас есть только гипотеза, представление. После написания оказывается, что автотесты писать еще дольше, чем тестировать вручную. Появляется новая гипотеза - покрывать автотестами не всю систему, а только часть. Снова пробуем гипотезу и так далее. Мы близки к оптимальному решению, но не находим его и двигаемся по наитию, близкому к случайности. Только сделав мы понимаем правильно ли сделали или нет. “Какой ремонт вы хотите? - Я пойму, когда увижу”.
Пятый - разнообразие близких к оптимальному решений. Наличие “правильного” решения и “заплатки” в проблеме с логами говорит нам об этом. Если взять горизонт в 10 лет, то время, которое потратиться на “заплатки” превысит время, которое было бы потрачено на “правильное” решение. А можно было бы придумать и третье решение - вообще отказаться от логов и четвертое - сделать автоочистку. Каждое решение имеет свою плюсы и минусы и каждое по-своему плохое и по-своему хорошее, но все они не оптимальны.
Шестой - разделение фенотипа и генотипа. В ит-системах разделено хранение информации в базе данных и её обработка сервисом. Поведение системы зависит от того, какая информация в ней хранится. В отделе тоже, обработка информации, которую делают агенты люди разделены от хранения информации на компьютерах.
Седьмой - репликация. Компании разрастаются и размещаются в нескольких городах. ИТ-системы усложняются и сервера находятся в разных странах. Существует резервное копирование, чтобы при гибели какой-то из системы ее можно было бы заново создать. Все эти системы обмениваются информации сами с собой и с окружающими системами и этот обмен увеличивает потенциал роста.
Восьмой - естественный отбор. ИТ-продукты конкурируют за выживание, слабые исчезают, сильные растут. Новые отделы, которые не приносят пользу расформировывают или упрощают, как упразднили ростуризм или профессии, которые больше не существуют.
Девятый - паразитизм. Существует потому, что почему бы и нет. К нему относятся отделы, которые не приносят пользу и тратят деньги. Иногда это может быть выгодно компании, - мне кажется отсюда появилось направление developer relations. Люди сидели на работе, но кроме работы занимались тем, что ходили на конференции и писали на форумах. А потом компании решили это использовать в своих интересах и стали получать из этого выгоду. Я бы мог это назвать взаимовыгодный паразитизм. Паразитизм существует, потому что защищаться от него слишком дорого. Эти проблемы приемлемы и агенты экономят на их решении.
Десятый - программируемая смерь. Мне на ум приходит отказ от каких-то сервисов в ИТ-продукте, устаревших. Или упразднение каких-то филиалов, которые не приносят прибыли компании. Некоторые компании даже банкротятся - можно сказать что это эволюционный суицид. Еще в ИТ-системах есть объекты, которые живут в оперативной памяти некоторое время, пока нужны, а потом удаляются. То же происходит и с очисткой кеша в приложениях.