Все новости от 17 июня 2004 г.

Выход не в open source, а во втором источнике

И не он один: под ударом оказались также Microsoft, Google и Yahoo. Что именно произошло, пока не ясно, но похоже, что в центре внимания Akamai — компания, управляющая DNS-преобразованием имен всех этих сайтов в цифровые интернет-адреса.

На другом конце спектра веб-контента перед пустыми экранами оказались тысячи блоггеров. Дейв Винер, организатор службы бесплатного хостинга weblog.com, в одностороннем порядке решил, что это дело отнимает у него слишком много времени и денег, и без предупреждения лишил жизни три тысячи «живых журналов». Трудно представить себе способ навлечь на себя еще больший гнев за такое короткое время, разве что размахивать флагом с серпом и молотом на съезде Республиканской партии.

Снова и снова: в мелких и крупных сейсмических толчках, сотрясающих онлайновый мир, есть одно общее — единые точки отказа. Если это вирусы и черви, то объектом обычно служит Microsoft: не потому, что ее код обязательно хуже, чем у других, а из-за вездесущности, усиливающей любую мелкую ошибку до размеров глобальной уязвимости. В инфраструктуре интернета скрытые проблемы в маршрутизаторах Cisco или поручение единственной компании управлять доменами верхнего уровня создают слабые звенья в системе, построенной на сверхотказоустойчивом протоколе.

Неверно думать, что это в первую очередь техническая проблема. Те, кто расследовал авиакатастрофы, знают, что ошибка пилота или отказ механизма почти никогда не приводят к аварии сами по себе: катастрофой обычно заканчивается целая цепочка событий. В каждом звене этой цепочки аварию можно было предотвратить. В плохих погодных условиях нужно быстро изменить высоту. Пилот пытался это сделать, но из-за грозы проскочил заданный уровень. Диспетчерская служба была перегружена и не заметила ошибки. У другого самолета, занимавшего соседний коридор, была неисправна система предупреждения о столкновениях. В результате катастрофа. Не будь любого из этих факторов, все могло бы закончиться совсем иначе.

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

Раньше было золотое правило проектирования электронных устройств: всегда имей второй источник. Если твое изделие зависит от уникального компонента, поставляемого единственной компанией, ты подвергаешься повышенному риску коммерческого шантажа, случайной аварии или неспособности производителя справиться со спросом. При любой возможности таких компонентов старались избежать. Теперь жизненный цикл продуктов стал столь коротким, а стремление побыстрее получить уникальные преимущества — столь сильным, что это правило часто игнорируют: что произойдет со стратегией Apple iPod Mini, случись пожар на заводе 1-дюймовых 4-Гбайт жестких дисков Hitachi?

И все же как много спецификаций на новые ИТ-системы содержат требование возможности переключения на другого поставщика для всех ключевых компонентов, как аппаратных, так и программных, в случае опасных ситуаций с этими компонентами? Для поставщиков привязка — самое желанное состояние: если у вас все работает на Microsoft или на SAP, эти поставщики будут всеми силами стараться сохранить такое положение. Может ли это втягивание увеличить стоимость перехода к другому поставщику? Безусловно. Нужно ли соглашаться с этим? Нет.

Может показаться, что ответ дает ПО open source, но и оно не обеспечит неуязвимости. Конечно, оно облегчит стратегию отказоустойчивости, но ни в коем случае не гарантирует ее: хотя авантюра SCO потихоньку проваливается, патенты на программное обеспечение остаются источником всеобщей опасности. История технологии XX века полна примеров, когда могущественные и агрессивные компании использовали для укрепления своей власти любое юридическое оружие. Не думайте, что раз у вас есть исходный код и право на его использование по собственному усмотрению, то это право уже никто никогда не нарушит. Его не должны нарушать, — но этого «не должны» недостаточно.

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

Apple, Google и прочие быстро вернулись в Сеть: DNS-серверы легко поменять, если вы к этому готовы. А те блоггеры с weblog.com, которые хранили копии своих журналов, переводят их на другие сайты с совместимым ПО. Громче всех вопят те, у кого таких копий не осталось. Правило успеха гласит: не доверяйся никому.

Об авторе:
Руперт Гудвинс — научный редактор ZDNetUK 

 Предыдущие публикации:

 В продолжение темы:

Обсуждение и комментарии

	ggv 17 Jun 2004 11:15 AM
well said
	Maverik 17 Jun 2004 1:42 PM
Еще одна статья о вреде монокультуры. Хотя стиль вполне приличный, и читается очень легко. Отдаю дань уважения автору.
	Игорь 18 Jun 2004 12:00 PM
very good
	Petro - petrodce.tsure.ru 18 Jun 2004 12:08 PM
Интересно получается, вроде бы солидные компании, а простейшие вопросы надежности не продумали?! Взять к примеру любую отечественную систему, которая проходила контроль госприемки, у нее будет дублирование наиболее уязвимых узлов. Мне думается, что в погоне за выгодой в скорости разработки (или в стоимости, хотя вряд ли)вопросы устойчивости ИТ-систем оставляются "на потом", а вот руки до "потом" не доходят. Другими словами, количество ставится превыше качества. Во что это выливается, описано в статье, причем весьма просто и доступно. Автору спасибо. А читателям - мотайте на ус, чтобы Ваши системы выглядели крепостями, а не соломенными домиками...
	- 18 Jun 2004 2:14 PM
Дило бачит.
	Вlack ibm.* 18 Jun 2004 2:55 PM
Полностью согласен с автором статьи. ЧТО и некое доминирование Linux ТОЖЕ ПЛОХО.( ОН тоже уязвим) НЕ говоря уже о MS. Хотя ведь есть Frя.
	Вlack ibm.* 18 Jun 2004 2:59 PM
2 Petro если безопасность ставить в главу угла сразу ТО МОЖНо и не начинать ДЕЛАТЬ.:). ОДНО дело не ставить временно безопасноть пока у вас один сервер в сети и на нем всего 100 user в день. Другое дело что елси РАСШИРЯЕШЬСЯ Ти потом не доходят руки ТО ТУТ согласен с ВАМИ. И причем уровень безопасности() и прчем не важно в какой сфере IT или добыча нефти - приер ЮКОС) Должен расти бытсрее чем ваш бизнес. вот АМАКАИИ Этого не учли..
	-- 18 Jun 2004 4:19 PM
А что фря? Вы уж определитесь. А то завтра скажете - "хотя ведь есть AIX!".
	AT - 220220pager.icq.com 18 Jun 2004 4:57 PM
Ха-ха ... Надо просто попросить две версии Windows Microsoft выпускать чтобы не было моно-культуры. Кто хочет - под Win 98 Personal Web-Server держит сайты, а кому нада под Win2003 IIS ;o)
	DEFILER 19 Jun 2004 4:37 AM
2 Black ibm.* "Доминирование Линукса" - это доминирование отсутствия доминирования. Своего рода логический парадокс. Линукс это не 2-3 стандартные версии по сегментам рынка. Это "две копии - три версии":) То, что валит редхат, бесполезно для ALT, например. Но есть еще отличия: лучше всего защищен тот продукт, версии которого плодятся как грибы. Попробуй найти кряк для ReGet самого свежего билда, например! Еще менее популярны кряки к редким прогам. То же касается и сетевого взлома. Ну нафига запускать в сеть вирус, который грохает только какой-нибудь кернел 2.2.14, но не 2.2.15? Есть, конечно, виндоуз апдейт, сервис паки... только для белых, т.е. для лицензионных копий. Но больше всего страдают именно юзеры лицензий, т.к. они могут себе их позволить и работают с более дорогой инфой, чем пираты. M$ РОЕТ СЕБЕ МОГИЛУ!
	Mauhuur - warlockskeptik.net 19 Jun 2004 4:20 PM
Не понял противоречия. OpenSource - и есть то самое экологическое diversity, которое необходимо устойчивости системы...
	Дмитрий 21 Jun 2004 3:33 PM
2 Mauhuur: Автор имел в виду диверсификацию интернет-источников. Вообще неплохо сказано: Если это вирусы и черви, то объектом обычно служит Microsoft: не потому, что ее код обязательно хуже, чем у других, а из-за вездесущности, усиливающей любую мелкую ошибку до размеров глобальной уязвимости - Люблю здравые мысли.
	Вlack ibm.* 21 Jun 2004 8:45 PM
DEFILER да все я понимаю ( кому вы обясняете ) а ВООЬЩЕ по смыслу Linuxа. что ЯДРО диминирует.. а не сама технология OSS. а тпереь и KDE уже доминирует в среде OSS что тоже не есть гуд( даже без точски зрнеия безопасности().
	Нос 22 Jun 2004 7:36 AM
главная причина всех этих "проблем" - желание халявы. Лучше подешевле, а и можно и совсем бесплатно. Только к сожалению "подешевле" накладывает отпечаток на качество
	Andy 22 Jun 2004 2:53 PM
2Нос: Интересная точка зрения на корень проблемы. Обоснуйте её, пожалуйста, поподробнее...
	Black Bat 22 Jun 2004 5:41 PM
to Andy: Краткий смысл: даром - за амбаром!
	Andy 23 Jun 2004 12:06 PM
2BlackBat: Ну вот Р.Гудвинс утверждает, что многие проблемы происходят из-за высокой степени привязки ИТ-систем к одному поставщику и общей гомогенности ИТ культуры. Здесь можно размышлять о необходимости дальнейшей унификации интерфейсов взаимодействия ИТ-систем или об опасности такой унификации, но есть достаточно чётко высказанная мысль и её аргументация. Хотелось бы того же и по поводу вашей с Носом 'тоже мысли'.
	Andy 23 Jun 2004 12:06 PM
2BlackBat: Ну вот Р.Гудвинс утверждает, что многие проблемы происходят из-за высокой степени привязки ИТ-систем к одному поставщику и общей гомогенности ИТ культуры. Здесь можно размышлять о необходимости дальнейшей унификации интерфейсов взаимодействия ИТ-систем или об опасности такой унификации, но есть достаточно чётко высказанная мысль и её аргументация. Хотелось бы того же и по поводу вашей с Носом 'тоже мысли'.
	Andy 23 Jun 2004 12:07 PM
2BlackBat: Ну вот Р.Гудвинс утверждает, что многие проблемы происходят из-за высокой степени привязки ИТ-систем к одному поставщику и общей гомогенности ИТ культуры. Здесь можно размышлять о необходимости дальнейшей унификации интерфейсов взаимодействия ИТ-систем или об опасности такой унификации, но есть достаточно чётко высказанная мысль и её аргументация. Хотелось бы того же и по поводу вашей с Носом 'тоже мысли'.
	Andy 23 Jun 2004 12:08 PM
Упс, прошу прощения за тройной пост - глюки :(
	00alex 23 Jun 2004 3:53 PM
хочешь, дружок, я расскажу тебе сказку?.. ;-)
	Maverik 25 Jun 2004 2:44 PM
2 Andy > Здесь можно размышлять о необходимости дальнейшей унификации > интерфейсов взаимодействия ИТ-систем или об опасности такой > унификации, Интерфейсы -- стандартные, открытые и монокультурные. Реализация -- произвольная. Уязвимости в протоколах можно по пальцам пересчитать. И еще: у *nix дофигища инкарнаций, а вот клон NT есть только один, и тот в зачатошном состоянии. Интересно, к чему бы это?
	Нос 25 Jun 2004 7:43 PM
2Andy: смысл в том, что надежность изделия начинает страдать из-за его девешивизны. Никто не купит, если все хорошенько протестировать - оно будет стоить ого-го (в частности, некоторые вещи и стоят. Поскольку их более-менее проверяют). Пингвин в этом плане выдающийся пример - выпустили ядро 2.6, называется :). Так хотелось релиз, что забыли одну вещь - тесты. P.s.: МС вон как сейчас надрывается, тратя огромные деньги на sp2 для ХР. Все потому, что поторопились раньше. Сейчас вдвойне заплатят.
	LinFan 29 Jun 2004 11:49 AM
2Нос: Ошибаетесь батенька - ядро это вам не новая версия WMP - на следующий день после его релиза RH,MDK,Suse и пр. почему-то не выпускают новый дистриб. А ставят его себе... тестеры (как не странно:). А до живого дистриба от 3 до 5 месяцев проходит. Эт виндузоиды по свистку загружают сервиспаки.
	Нос 29 Jun 2004 12:03 PM
2LinFan: Я не про релизы конкретных дистрибутивов говорил. А про релиз ядра. Полгода прошло, а уже 2.6.4 на подходе (а сколько еще RC было). Расскажи лучше, когда оно стандартно появится в RHEL или SLES (или как он там...)? Лет через надцать?
	Шурик 29 Jun 2004 3:24 PM
Да ну все эти рассуждения. Когда система простая то в ней проблемы безопастноси не возинкает - и так все понятно. Когда система сложная - то в ней все сложно и безопастность и остальное (вообще иногда не понятно как сделать). Есть жизненый цикл разработки. Когда про что думать сложный вопрос. Один художник начинает рисовать с фона, другой с объекта в левом нижнем углу. Главное все что сделал систематизировать и "складывать" аккуратно с "запасом", что бы можно было потом ворочать то что наворотил (простие за каламбур!). Так что надежность в любой тех ситеме это технология конроля за ревизиями.И дело тут не в деньгах, а таланте конструктора.Но мне кажется что в MS много таланливых маркетологов и мало хороших программистов-конструкторов. В этой системе все хорошо для тех кто ничего в системах не понимает. Красиво и уютно! Как попса и классика! Ведь если классики не понимаешь, то никогда не будешь ее слушать. И если от попсы тошнит тоже не будешь. Вобщем я и за то и за другое. Сравнивать только их не хочется. Рука не поднимается!
	AT - 220220pager.icq.com 2 Jul 2004 4:19 AM
Вопрос - а вам не кажеться что релиз новой версии ядра Linux и сервис-пака к Винде немного разные события ? Сравнивать их не стоит, а если и сравнивать - то не забывать что сначала сервис-паки и новые версии виндов сначала внутири большой компании потихоньку на пару десятков тысяч компов ставят. И потом еще потихоньку скарливают приближенным людям извне - вендорам железок, софта, IT отделам очень больших контор и просто неленивым домашним юзерам. Релиз ядра в Linux это значит что оно таки скомпилировалось, а релиз сервис-пака это значит что оно уже где-то поработало. Почуйствуйте разницу.