Release it! книжка о трещинах в ПО

releaseitВ этом году издательство «Питер» выпустило русскоязычный перевод книжки Майкла Нейгарда “Release it! Проектирование и дизайн ПО для тех, кому не всё равно” Оригинал этой книжки “Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers)”  появился в 2007 году. Не знаю какими соображениями руководствовалось издательство выпуская перевод сегодня. Как, впрочем, не помню почему именно эту книжку я взял почитать в отпуск. Тем не менее хочу порекомендовать эту книжку для чтения всем, кто так или иначе связан с архитектурой информационных систем.

Один из отзывов на ozon.ru утверждает:

Остался в некотором разочаровании от книги. Вопреки названию и аннотации оказалось, что она рассчитана не на рядовых программистов, а скорее на архитекторов систем. Все темы автор рассматривает в контексте распределенных систем, ориентированных на огромное число пользователей.

– и это чистая правда. В ходе чтения я не мог избавиться от ощущения déjà vu, постоянно ловил себя на мысли: откуда-то я все это уже знаю. Вряд ли я раньше читал оригинал. Ну, может быть, полистал однажды, но не более того. Скорее эта книжка просто приводит абсолютно типичные истории из жизни информационных систем. Пара предложений из предисловия:

Современные учебные программы по разработке программного обеспечения являются до ужаса неполными. В их рамках рассматривается только то, как должна вести себя система. При этом не раскрывается обратный аспект — как системы не должны себя вести. А они не должны рушиться, зависать, терять данные, предоставлять несанкционированный доступ к информации, приводить к потере денег, разрушать вашу компанию или лишать вас заказчиков.

А далее идут примеры каскадного обрушения стабильных монолитных систем, успешно прошедших все нагрузочные и интеграционные тестирования, но развалившихся в определенный момент в следствии «невероятного стечения обстоятельств». Главная метафора книги появляется в разделе 3.2 Режимы отказов:

К катастрофическому отказу могут привести как внезапные импульсы, так и чрезмерная нагрузка. Но в любом случае какой-то компонент системы начинает отказывать раньше, чем все остальное. В своей книге Inviting Disaster Джеймс Р. Чайлз называет это трещинами (cracks) системы. Он сравнивает сложную систему, находящуюся на грани отказа, со стальной пластинкой с микроскопической трещиной. Под нагрузкой эта трещина может начать расти быстрее и быстрее. В конечном счете скорость распространения дефекта превысит скорость звука, и металл с резким треском сломается.

Компонуя разделы учебной программы “Мастерская проектирования ИТ-решений”, я долго не мог придумать как в компактной, но понятной форме рассказать о проектировании технологической архитектуры. Какие слова смогут убедить слушателя в том, что логичные и красиво составленные сценарии синхронного взаимодействия информационных систем не годятся для описания интеграций. Они просто не будут работать. Вернее, будут, но не всегда и совсем не долго. Максимум – до завершения интеграционного и нагрузочного тестирования. В ходе реальной эксплуатации в информационной системе очень быстро появятся трещины и единственный внятный способ с ними справиться– заранее спроектировать решение так, чтоб оно противостояло распространению трещин.

Такого рода книжек очень не хватает архитекторам информационных систем. Нас все время пытаются завлечь в обсуждения малосущественных вещей типа сравнения нотаций моделирования, построение  архитектурного процесса или выбор “правильного” инструмента рисования картинок. И все это происходит на фоне регулярно рассыпающихся корпоративных информационных систем, происходящего из-за недостатков проектирования.

Release it! книжка о трещинах в ПО: 2 комментария

  1. Книга хороша, спору нет! Только надо обязательно уточнить, что издательство Питер славится своими не качественными переводами технической литературы. Ошибка есть прямо на обложке: “Design and Deploy” перевели как “Проектирование и Дизайн”. Это же просто ужас.

    1. Действительно так. И в тексте и на картинках много переводческих ляпов и просто не согласованных терминов. В одном случае на картинке будет написано “балансировщик”, в другом “распределитель нагрузки”.
      К тому же, автор “порадует” нас порцией недоумения по поводу отсутствия сессий в протоколе HTTP, но книжка то старая и заслуживает снисхождения

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *