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