История компьютерных систем — это и история багов, в том числе страшных и катастрофических, причинивших ущерб в миллионы долларов, принесших разрушения и даже смерть. Хватало, кроме истории с Боингом, известных сбоев систем и невыполненных проектов, за которые также пришлось заплатить высокую цену. Некоторые подобные баги кажутся небольшими и глупыми ошибками, например, бесславное крушение ракеты Ariane 5, вызванное программной ошибкой величиной всего в одну строку. Но даже такая маленькая ошибка, как и любая другая изолированная ошибочка или отказ, не нанесут серьезного вреда крупной системе — если в этой системе не допущены грубые ошибки на уровне архитектуры и проектирования, а также просчеты при управлении.
Именно такие проблемы Барри Бём называет «Разрушителями архитектуры». Они возникают в случаях, когда структура системы не соответствует требованиям реального мира, и при работе с ней вы совершенно неожиданно сталкиваетесь с фундаментальными недостатками или непреодолимыми границами возможностей выбранной платформы.
«Разрушители архитектуры» возникают на периферии — или уже за пределами — конкретного варианта системы, вне номинальных благоприятных сценариев. Система работает почти всегда, но в одном случае на миллион возможна ошибка. Такую ошибку никто не воспринимает всерьез, до тех пор, пока эта «крайне маловероятная» проблема не начинает случаться раз в несколько дней. Бывает и так, что система обрушивается при неожиданном скачке нагрузки, при увеличении количества запросов. И такая нагрузка никуда не денется сама собой, если вы не найдете способ быстро масштабировать систему и справиться с ней. Впрочем, если масштабировать систему не удастся, проблема чрезмерного количества запросов снимется сама — ваши клиенты просто уйдут и не вернутся. Загвоздка, которая на первый взгляд может показаться мелким эксплуатационным неудобством, на самом деле может быть первым симптомом фундаментальной ненадежности или небезопасности всей системы.
ПОИСК РАЗРУШИТЕЛЕЙ АРХИТЕКТУРЫ
Обычно все начинается с неприятной ошибки, изолированной эксплуатационной проблемы или инцидента, связанного с брешью в системе безопасности. Пускаясь в исследование этой ошибки, вы находите новые потенциально опасные случаи, зияющие дыры в системе, непреодолимые границы ее технологических возможностей. Встречаются и такие виды отказов, которые не удается ни предотвратить, ни объяснить. Структура начинает рассыпаться на глазах, поскольку оказывается, что каждая проблема способна провоцировать еще целый класс проблем. На устранение всех таких недостатков уходит время и тратятся деньги. Иногда приходится вновь возвращаться к чертежу и пересматривать фундаментальные архитектурные решения и технологические подходы.
То, что казалось случайным отказом или неприятной ошибкой, оказывается намного более серьезной проблемой.
Такие проблемы особенно опасны и потому, что обычно их удается выявить очень поздно — намного позже проектирования системы и приемочного тестирования, когда система уже используется в производстве и обслуживает массу реальных клиентов, выполняющих с ее помощью важную работу. Если что-то начинает идти не так, то бывает сложно сразу оценить масштабы бедствия. Должно случиться еще два, три или больше отказов, прежде чем вы осознаете — и признаете — насколько далеко все зашло. Не сразу удается и уловить закономерность, позволяющую понять, в чем на самом деле заключается проблема.
К тому моменту, когда удастся ответить на все эти вопросы, вы уже можете потерять и деньги, и клиентов, а времени на решение проблемы останется в обрез. Никто не желает и слышать о том, что необходимо остановиться и вернуться назад, переписать часть системы или переделать всю архитектуру и начать сначала. Не менее прохладно воспринимается и необходимость поразмыслить, провести тесты, понять, что идет не так, сформулировать мнение о проблеме — и лишь потом рассказать, сколько времени может уйти на ее устранение и сколько это может стоить.
ПО КАКИМ ПРИЧИНАМ РАЗРУШАЕТСЯ АРХИТЕКТУРА?
Как правило, разрушители архитектуры — фундаментальные проблемы, которые кроются в важных, но нефункциональных аспектах системы:
• стабильность и целостность данных: некий модуль системы не выдерживает высоких нагрузок или начинает периодически отказывать после того, как система непрерывно поработает в течение дней или недель. Возможно, вы потеряете критически важные пользовательские данные, которые не сможете восстановить, либо не сможете достаточно быстро реанимировать сервис после эксплуатационного отказа;
• масштабируемость и пропускная способность: платформа (язык, контейнер, коммуникационная фабрика, база данных или все сразу) поначалу функционирует прекрасно, но после какого-то предела перестает выдерживать наплыв клиентов, даже если вы подключаете дополнительное аппаратное обеспечение. Почитайте о том, как в Twitter попробовали горизонтально масштабировать Ruby или как Facebook взялся масштабировать PHP, а также о любых других случаях, в которых кто-либо пытался горизонтально масштабировать кластер реальных приложений Oracle;
• допустимая задержка: возрастают требования к скорости отклика в реальном времени или выдерживания дедлайнов. Возможны случаи, в которых в системе возникают неприемлемые флуктуации или изменчивость (допустим, вы выбрали Java в качестве платформы времени исполнения; что произойдет если в работу вклинится сборщик мусора?);
• безопасность. Вас просто атаковали хакеры, и вы обнаруживаете, что тот баг, которым воспользовались злоумышленники, — всего лишь один из тысяч, которые необходимо найти и устранить. Оказывается, выбранный вами вариант (язык, фреймворк) либо способ его использования полон дыр, как кусок швейцарского сыра.
Подобные проблемы возникают из-за непонимания того, как именно работают технологии или фреймворк, лежащие в основе выбранной платформы, каковы границы возможностей данного варианта архитектуры или технологии. Дело может быть и в полном незнании, недосмотре или игнорировании какого-то важного аспекта реализуемой архитектуры.
От таких проблем обычно не удается избавиться на уровне написания кода, или это очень непросто. Иногда проблема вообще никак не связана с кодом: все дело в той технологии, которая лежит в основе сторонней платформы, которая просто не может справиться с предъявляемыми требованиями. Это может быть сам язык либо важная часть стека (контейнер, база данных, коммуникационная фабрика или иной элемент, на который вы полагаетесь при построении кластеров, автоматическом преодолении отказов или при какой-то другой «магии»). В принципе, в реальных условиях практически любая программа, написанная сторонним разработчикам, не полностью удовлетворяет ваши нужды или не совсем соответствует обещаниям производителя.
Приходится тратить дополнительное время на работу с производителем (порой — с несколькими производителями) и разъяснять им поставленную задачу, заставлять их признать, что эту задачу они обязаны решить в полном объеме. Если же ваши подрядчики не могут решить всех возникающих проблем либо не способны справиться с ними достаточно быстро, то нужно быстро переходить к плану «B» и надеяться, что новые разработчики не столкнутся с такими же или еще более сложными проблемами.
КАК ИЗБЕЖАТЬ ПОЯВЛЕНИЯ РАЗРУШИТЕЛЕЙ АРХИТЕКТУРЫ
Обычно разрушители архитектуры возникают в результате преждевременных или неверных решений. Возможно, нужное решение было просто принято с опозданием или не принято вообще. Бём рассказывает о разрушителях архитектуры в рамках аргументации против «простого дизайна». Он видит проблему в том, что многие команды, особенно исповедующие Agile-методологии, занимаются проработкой лишь благоприятных сценариев. Новые функции дописываются с единственной целью — доставить удовольствие клиенту. При этом игнорируются этапы заблаговременного планирования архитектуры и анализа того, что может пойти неправильно. Но разрушители архитектуры — явление гораздо более древнее, чем Agile и простой дизайн. В своей книге «Создание программ» (глава 10: «Архитектура: сколько и когда») Бём рассказывает о 1980-х годах, когда были впервые идентифицированы такие проблемы. Тогда единственно правильными методологиями считались структурное программирование и появившаяся несколько позже каскадная модель («Водопад»).
Бём предлагает подробнее и лучше определять архитектуру, а также управлять техническими рисками при помощи «спиральной модели». В таком варианте жизненного цикла все начинается с продумывания архитектуры, обнаружения областей потенциального риска. Далее эти области исследуются в ходе итеративного проектирования через оценку рисков, прототипирования и многоэтапной разработки. Спиральная разработка напоминает современные итеративные инкрементные методологии, применяющие пилотные варианты архитектуры с учетом рисков. Но спиральная методология предполагает гораздо более длительные циклы итеративной разработки и технического прототипирования, более аккуратное управление рисками, обширное планирование, работу на бумаге и, соответственно, гораздо более высокие расходы.
Но не все баги такого рода можно устранить, если просто уделять больше внимания архитектуре и своевременному управлению техническими рисками — идет ли речь о спиральной разработке или более полноценной и дисциплинированной Agile-разработке.
Если просто тратить на все это больше времени, вы не исключите наивные предположения о масштабировании, скорости отклика, надежности или безопасности системы. Возможно, проблемы просто недостаточно глубоко понимаются, и недостаток знаний не позволяет оценить риски. Вы не найдете упоминаний о разрушителях архитектуры в проектных экспертизах, так как никто не будет искать еще не проявившихся проблем.
Возможно, конечно, при разработке применяется строгая система анализа видов и последствий возможных отказов, например, FMEA или FMECA. Работая таким образом, вы вынуждены задавать острые вопросы. Правда, лишь некоторые люди, занятые вне регулируемых отраслей, хотя бы слышали о таких проблемах.
Кроме того, далеко не все разрушители архитектуры можно отследить в ходе тестирования, даже если речь идет о тестировании на долговечность (longevitytesting) или тестировании стабильности. Не всегда помогает обширное тестирование методом ввода неверных данных (fuzztesting), имитация отказов, намеренное внесение неисправностей, разрушающее тестирование и стресс-тестирование. Даже если все эти виды тестирования выполняются со всей серьезностью, всегда могут оставаться экстремальные случаи, которые зачастую просто считаются реалистичными.
Нужно уметь справляться с разрушителями архитектуры. Предугадывая возможные проблемы и сегментируя вашу архитектуру — например, в соответствии с «паттернами стабильности», описанными Майклом Найгардом в его замечательной книге «ReleaseIt!», вы, как минимум, сможете гарантировать, что серьезные ошибки времени исполнения не распространятся на всю систему. Описанные в этой книге стратегии также помогут вам при обеспечении масштабирования и безопасности. А если вы все же наткнетесь на подобную редчайшую критическую ошибку при технической экспертизе, тестировании или обнаружите ее в уже работающей системе, умейте максимально оперативно и правильно оценить серьезность ошибки, действуйте быстро и решительно. Может быть, тогда «Боинг» уже не выйдет из-под контроля пилотов прямо в небе.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.