Иногда умные люди, которые умеют хорошо работать, случайно всё портят. Эта моя история основана на воспоминаниях о реальных событиях.
Небольшая команда разработчиков в SaaS-компании средних размеров столкнулась с проблемой. У компании было некоторое количество сервисов, осуществляющих загрузку и трансформацию данных. И нагрузка на эти сервисы резко возросла с появлением клиента (назовем его Клиент-А), который генерировал в разы больше данных, чем остальные.
С нагрузкой сотрудникам удалось справиться, но возникла другая сложность. Они увеличили пропускную способность системы, однако, как выяснилось, пострадала равномерность. В результате некоторым другим клиентам часто приходилось ждать или получать устаревшие данные. Клиент-А создал затор в очереди и отрезал другим клиентам доступ к ресурсам. Это примерно как проблема с планированием процессов у операционной системы, только в контексте микросервисов распределенной системы.
Всё это породило проблему наихудшей разновидности – проблему, которая влияет на людей. Именно из-за проблем такого рода начальство, которое раньше вообще не знало о существовании сервиса, начинает требовать ежедневных отчетов о его работе.
Выясняется, что в этом конкретном сервисе для планирования используются таблица Postgres и топики Kafka. Имеется множество переменных, которые необходимо скорректировать для нужного баланса пропускной способности и равномерности. Планирование – сложная штука. В команде бросают клич: кто поможет наладить систему? Разработчики компании, которые обычно работают над подобными задачами, не знакомы с Kafka. Совершенствованием системы лучше заниматься тому, кто хорошо понимает принципы ее работы.
Команде удается найти баланс пропускной способности и равномерности, но во избежание инцидентов в будущем сотрудника по имени Тим просят разобраться, как в доброй сотне сервисов компании обрабатываются очереди и текущие процессы. Тим – техлид на очень высокой должности, так что свое дело он знает. Перед ним поставлена задача: нужно что-то придумать, чтобы такого больше не повторялось. Скоро подоспеет еще энное число клиентов, сравнимых по масштабу с Клиентом-А. Мы не можем себе позволить осваивать эту область через цепочку ЧП – сначала один сервис дает сбой под нагрузкой, потом другой. Такими темпами мы растеряем видных клиентов и бла-бла, акционерная стоимость. Требуется какое-то более удачное решение.
Итак, Тим изучает все представленные сервисы и начинает набрасывать план. Оказывается, работа с очередями и текущими процессами у сервисов происходит по принципу «кто в лес, кто по дрова». Какую-то общую картину ему выстроить сложно, но, похоже, в большинстве сервисов используются SQS, таблицы баз данных или Kafka.
Тим предлагает следующее решение: сделать общую библиотеку для всего, что связано с очередями и обработкой сообщений. В основе будет Kafka, и все переедут туда.
Красота такого подхода заключается в том, что всё будет работать одинаково. Если команда, работающая над одним из сервисов, придумает, как оптимизировать распределение ресурсов, воспользоваться их идеей смогут все – библиотека-то общая. А если на каком-то участке возникнут сложности, люди из других команд смогут помочь, потому что одинаковые решения годятся для всех сервисов.
В общем, вышло всё совсем иначе.
В прежнем мире каждый сервис, обрабатывающий данные, работал не совсем так, как остальные, и поэтому систему в целом сложно было осмыслить, если двигаться от общего к частному. Тим с большим трудом разобрался, что как работает; к тому же у каждой из этих подсистем были свои слабые места, которые при масштабировании создавали еще более серьезные проблемы.
Предполагалось, что при стандартизации многие из этих разрозненных проблем, никак не связанных с планированием, разом разрешатся. Реальность опровергла эту гипотезу. Для стандартизации была проделана серьезная работа, которая действительно устранила некоторые проблемы, но, в общем и целом, система стала работать хуже. И, оказывается, существует отличная книга, которая целиком посвящена ошибкам именно такого рода.
Примечание: на мой взгляд, выбор Kafka был здесь стратегически неверным шагом, он мало подходит для работы с очередями и освоить его непросто. Но в силу сопутствующих обстоятельств, не представляющих большого интереса, его сочли подходящим вариантом. Однако я бы хотел сосредоточиться на более значимой проблеме – стремлении к стандартизации как самоцели.
Книга Джеймса Скотта Seeing Like A State рассматривает только одну проблему: как централизованные, идущие от структуры к элементу схемы усовершенствования мира терпят крах. В ней рассматривается большое количество инициатив по централизации и стандартизации, и у них обнаруживается много общего, в том числе и с нашей инициативой по унификации планирования.
Лично мне больше всего понравилась история о деревьях. В Европе XIX века леса были важнейшим источником дохода. Дерево можно было обратить в древесину или дрова, каждый акр леса в распоряжении государства имел свою цену. Но какую именно?
С лесами проблема состоит в том, что они состоят из произвольных деревьев, расположенных в произвольном порядке. Закономерности не считываются. Невозможно окинуть лес взглядом с высоты и понять, какие конкретно там есть деревья. Можно составить карту, но это потребует много усилий, и карта получится запутанная. Существует множество разновидностей деревьев, которые могут служить для разных целей. В общем, приходится заключить, что в реальном мире творится полная неразбериха.
В свете этого было придумано решение: научное лесоводство. Давайте набросаем карту упрощенного леса, где растут только самые лучшие деревья на оптимальном расстоянии друг от друга. А потом создадим лес, который будет ей соответствовать. Кстати, лучшими деревьями были признаны ели обыкновенные. Они быстро растут и имеют новогодний вид.
Вышло так себе.
Казалось бы, на этом всё должно и прекратиться, однако искусственные лесонасаждения до сих пор пользуются популярностью. И центральное планирование, при котором всё выглядит очень единообразно на схемах и не особенно работает в действительности, продолжается и по сей день.
Джеймс Скотт называл такие нисходящие решения «простыми для чтения системами». Они легко поддаются объяснению в общих чертах. Как строится работа в этом сервисе? Так же, как и во всех остальных. Что это за дерево растет в лесу? Ель обыкновенная, они все там ели обыкновенные.
С токи зрения Скотта, проблема здесь заключается в том, что стремление к стандартизации уничтожает огромный массив никем не озвучиваемых знаний, актуальных для конкретных участков, ради построения системы, где всё завязано на подчинении частного общему.
Стандартизация пренебрегает забором Честертона. Почему в городах появляются зоны смешанного назначения? Почему в этом сервисе очереди обрабатываются при помощи простой таблицы базы данных? Почему ель обыкновенная обычно не растет в этих краях? Если вы не можете ответить на эти вопросы, существует немалый риск, что ваш план провалится.
В книге Seeing Like A State разбирается много подобных примеров. По мнению автора, прямоугольная планировка, современное зонирование городов и крупномасштабные архитектурные проекты все повторяют ошибку научного лесоводства. Эту ошибку легко определить: люди пытаются перекроить территорию под карту и забывают, что карта (или же архитектурный проект) – это всего лишь карта. Она не отражает многих особенностей местности.
Я не хочу сказать, что это глупая ошибка, которую стыдно совершать. Ошибиться в таком ключе очень просто. Когда пытаешься разобраться в принципах работы нескольких систем сразу, приходится держать в голове много деталей. Наш мозг в таких ситуациях осмысляет информацию следующим образом: абстрагируется от частностей и объединяет детали в группы. Мы вырабатываем общее понимание и уже на его основе ищем решение.
Книга Seeing Like A State говорит нам о том, что проблема состоит в попытке найти глобальное решение. Глобальное решение, просто по определению, должно пренебрегать локальными особенностями. Карта исключает больше объектов, чем включает. Если решение проще расписать на доске, это не значит, что оно лучше – его только проще расписать на доске.
Возвращаясь к нашей истории с очередями, если бы Тим включился в работу одной команды и нашел бы с ней решение конкретной проблемы, затем подключился бы к другой команде и решил бы другую конкретную проблему – возможно, выявились бы некоторые общие черты. Или нет. Возможно, каждая ситуация потребовала бы особого решения. Когда работаешь в связке с отдельной командой, видишь все обстоятельства прямо «на местности». Многие из них не имеют большого значения, но некоторые очень важны.
Большая часть знаний о функционировании той или иной системы хранится не в книгах и не в голове у какого-нибудь эксперта – они распределены по сети людей, задействованных в работе этой системы. И это не какая-то абстрактная мысль о строении человеческого общества – речь о том, что существует огромный массив узконаправленных знаний, которые нигде не зафиксированы.
Поэтому теперь, когда я слышу о попытках нисходящей стандартизации, то испытываю смутное беспокойство: я знаю, что сведение многочисленных проблем к общему знаменателю – рискованная затея. Гораздо более действенный способ разобраться с проблемой – внедрение и совместная работа с теми людьми, у которых больше всего скрытых знаний в этой области. Стандартизация и указы сверху вниз не дают результата, когда они не учитывают или идут вразрез с негласными умозаключениями тех, кто близко знаком с проблемой.
Небольшая команда разработчиков в SaaS-компании средних размеров столкнулась с проблемой. У компании было некоторое количество сервисов, осуществляющих загрузку и трансформацию данных. И нагрузка на эти сервисы резко возросла с появлением клиента (назовем его Клиент-А), который генерировал в разы больше данных, чем остальные.
С нагрузкой сотрудникам удалось справиться, но возникла другая сложность. Они увеличили пропускную способность системы, однако, как выяснилось, пострадала равномерность. В результате некоторым другим клиентам часто приходилось ждать или получать устаревшие данные. Клиент-А создал затор в очереди и отрезал другим клиентам доступ к ресурсам. Это примерно как проблема с планированием процессов у операционной системы, только в контексте микросервисов распределенной системы.
Всё это породило проблему наихудшей разновидности – проблему, которая влияет на людей. Именно из-за проблем такого рода начальство, которое раньше вообще не знало о существовании сервиса, начинает требовать ежедневных отчетов о его работе.
Выясняется, что в этом конкретном сервисе для планирования используются таблица Postgres и топики Kafka. Имеется множество переменных, которые необходимо скорректировать для нужного баланса пропускной способности и равномерности. Планирование – сложная штука. В команде бросают клич: кто поможет наладить систему? Разработчики компании, которые обычно работают над подобными задачами, не знакомы с Kafka. Совершенствованием системы лучше заниматься тому, кто хорошо понимает принципы ее работы.
Команде удается найти баланс пропускной способности и равномерности, но во избежание инцидентов в будущем сотрудника по имени Тим просят разобраться, как в доброй сотне сервисов компании обрабатываются очереди и текущие процессы. Тим – техлид на очень высокой должности, так что свое дело он знает. Перед ним поставлена задача: нужно что-то придумать, чтобы такого больше не повторялось. Скоро подоспеет еще энное число клиентов, сравнимых по масштабу с Клиентом-А. Мы не можем себе позволить осваивать эту область через цепочку ЧП – сначала один сервис дает сбой под нагрузкой, потом другой. Такими темпами мы растеряем видных клиентов и бла-бла, акционерная стоимость. Требуется какое-то более удачное решение.
Итак, Тим изучает все представленные сервисы и начинает набрасывать план. Оказывается, работа с очередями и текущими процессами у сервисов происходит по принципу «кто в лес, кто по дрова». Какую-то общую картину ему выстроить сложно, но, похоже, в большинстве сервисов используются SQS, таблицы баз данных или Kafka.
Тим предлагает следующее решение: сделать общую библиотеку для всего, что связано с очередями и обработкой сообщений. В основе будет Kafka, и все переедут туда.
Красота такого подхода заключается в том, что всё будет работать одинаково. Если команда, работающая над одним из сервисов, придумает, как оптимизировать распределение ресурсов, воспользоваться их идеей смогут все – библиотека-то общая. А если на каком-то участке возникнут сложности, люди из других команд смогут помочь, потому что одинаковые решения годятся для всех сервисов.
В общем, вышло всё совсем иначе.
В прежнем мире каждый сервис, обрабатывающий данные, работал не совсем так, как остальные, и поэтому систему в целом сложно было осмыслить, если двигаться от общего к частному. Тим с большим трудом разобрался, что как работает; к тому же у каждой из этих подсистем были свои слабые места, которые при масштабировании создавали еще более серьезные проблемы.
Предполагалось, что при стандартизации многие из этих разрозненных проблем, никак не связанных с планированием, разом разрешатся. Реальность опровергла эту гипотезу. Для стандартизации была проделана серьезная работа, которая действительно устранила некоторые проблемы, но, в общем и целом, система стала работать хуже. И, оказывается, существует отличная книга, которая целиком посвящена ошибкам именно такого рода.
Примечание: на мой взгляд, выбор Kafka был здесь стратегически неверным шагом, он мало подходит для работы с очередями и освоить его непросто. Но в силу сопутствующих обстоятельств, не представляющих большого интереса, его сочли подходящим вариантом. Однако я бы хотел сосредоточиться на более значимой проблеме – стремлении к стандартизации как самоцели.
Книга Джеймса Скотта Seeing Like A State рассматривает только одну проблему: как централизованные, идущие от структуры к элементу схемы усовершенствования мира терпят крах. В ней рассматривается большое количество инициатив по централизации и стандартизации, и у них обнаруживается много общего, в том числе и с нашей инициативой по унификации планирования.
Лично мне больше всего понравилась история о деревьях. В Европе XIX века леса были важнейшим источником дохода. Дерево можно было обратить в древесину или дрова, каждый акр леса в распоряжении государства имел свою цену. Но какую именно?
С лесами проблема состоит в том, что они состоят из произвольных деревьев, расположенных в произвольном порядке. Закономерности не считываются. Невозможно окинуть лес взглядом с высоты и понять, какие конкретно там есть деревья. Можно составить карту, но это потребует много усилий, и карта получится запутанная. Существует множество разновидностей деревьев, которые могут служить для разных целей. В общем, приходится заключить, что в реальном мире творится полная неразбериха.
В свете этого было придумано решение: научное лесоводство. Давайте набросаем карту упрощенного леса, где растут только самые лучшие деревья на оптимальном расстоянии друг от друга. А потом создадим лес, который будет ей соответствовать. Кстати, лучшими деревьями были признаны ели обыкновенные. Они быстро растут и имеют новогодний вид.
Вышло так себе.
В обедненной экосистеме не заводились дикие животные и лекарственные травы, которыми кормились жители близлежащих деревень – это привело их к экономическому краху. Аккуратные ряды одинаковых деревьев оказались идеальной средой для развития древесных болезней и лесных пожаров. Нарушились сложные экологические процессы, которые поддерживали плодородность почвы, так что второе поколение елей обыкновенных выросло истощенным и низкорослым.
Казалось бы, на этом всё должно и прекратиться, однако искусственные лесонасаждения до сих пор пользуются популярностью. И центральное планирование, при котором всё выглядит очень единообразно на схемах и не особенно работает в действительности, продолжается и по сей день.
Джеймс Скотт называл такие нисходящие решения «простыми для чтения системами». Они легко поддаются объяснению в общих чертах. Как строится работа в этом сервисе? Так же, как и во всех остальных. Что это за дерево растет в лесу? Ель обыкновенная, они все там ели обыкновенные.
Это процесс, противоположный составлению карты местности. Как если бы мы сказали: «Давайте возьмем карту и скорректируем местность под нее».
С токи зрения Скотта, проблема здесь заключается в том, что стремление к стандартизации уничтожает огромный массив никем не озвучиваемых знаний, актуальных для конкретных участков, ради построения системы, где всё завязано на подчинении частного общему.
В вопросе направленных преобразований, в отличие от деформаций, существует один простой и очевидный принцип, который даже можно назвать парадоксом. Допустим, существует конкретный закон или институт, для простоты примера забор или ворота, расположенные поперёк дороги. Современный тип реформатора, с энтузиазмом предлагает: «Я не вижу никакой пользы от этого; давайте уберём его с дороги». На что более разумный реформатор способен ответить: «Если вы не видите пользы от этого сооружения, я точно не могу позволить вам избавиться от него. Найдите время и подумайте. Только затем, когда вы вернётесь и сможете объяснить мне, что вы видите применение ему, возможно, я позволю вам исполнить ваше намерение».
— Забор Честертона
Стандартизация пренебрегает забором Честертона. Почему в городах появляются зоны смешанного назначения? Почему в этом сервисе очереди обрабатываются при помощи простой таблицы базы данных? Почему ель обыкновенная обычно не растет в этих краях? Если вы не можете ответить на эти вопросы, существует немалый риск, что ваш план провалится.
В книге Seeing Like A State разбирается много подобных примеров. По мнению автора, прямоугольная планировка, современное зонирование городов и крупномасштабные архитектурные проекты все повторяют ошибку научного лесоводства. Эту ошибку легко определить: люди пытаются перекроить территорию под карту и забывают, что карта (или же архитектурный проект) – это всего лишь карта. Она не отражает многих особенностей местности.
Я не хочу сказать, что это глупая ошибка, которую стыдно совершать. Ошибиться в таком ключе очень просто. Когда пытаешься разобраться в принципах работы нескольких систем сразу, приходится держать в голове много деталей. Наш мозг в таких ситуациях осмысляет информацию следующим образом: абстрагируется от частностей и объединяет детали в группы. Мы вырабатываем общее понимание и уже на его основе ищем решение.
Книга Seeing Like A State говорит нам о том, что проблема состоит в попытке найти глобальное решение. Глобальное решение, просто по определению, должно пренебрегать локальными особенностями. Карта исключает больше объектов, чем включает. Если решение проще расписать на доске, это не значит, что оно лучше – его только проще расписать на доске.
Возвращаясь к нашей истории с очередями, если бы Тим включился в работу одной команды и нашел бы с ней решение конкретной проблемы, затем подключился бы к другой команде и решил бы другую конкретную проблему – возможно, выявились бы некоторые общие черты. Или нет. Возможно, каждая ситуация потребовала бы особого решения. Когда работаешь в связке с отдельной командой, видишь все обстоятельства прямо «на местности». Многие из них не имеют большого значения, но некоторые очень важны.
Большая часть знаний о функционировании той или иной системы хранится не в книгах и не в голове у какого-нибудь эксперта – они распределены по сети людей, задействованных в работе этой системы. И это не какая-то абстрактная мысль о строении человеческого общества – речь о том, что существует огромный массив узконаправленных знаний, которые нигде не зафиксированы.
Поэтому теперь, когда я слышу о попытках нисходящей стандартизации, то испытываю смутное беспокойство: я знаю, что сведение многочисленных проблем к общему знаменателю – рискованная затея. Гораздо более действенный способ разобраться с проблемой – внедрение и совместная работа с теми людьми, у которых больше всего скрытых знаний в этой области. Стандартизация и указы сверху вниз не дают результата, когда они не учитывают или идут вразрез с негласными умозаключениями тех, кто близко знаком с проблемой.
