Уважаемый 
hvostat_hvostat скинул мне ссылку на новость, которая, оказывается, взорвала UA-net и около, и попросил прокомментировать. Новость меня так зацепила, что я даже разморозил свою уютную жежешечку...
Сразу оговорюсь, я не знаю, насколько эта информация правдива. Вполне возможно, это банальный вброс. И все же. Начнем с того, что мне известно.
Упомянутая в тексте система HDS VSP несколько лет назад была установлена и инициализирована, как это положено, непосредственно инженерами HDS и сконфигурирована мною, в рамках работ по инсталляции кластера для информационной системы тогда еще ГНАУ. Проект был очень мощный по оборудованию и очень бестолковый по реализации. Кластер из двух IBM Power 770 в полной набивке, HDS VSP, куча оборудования Cisco, специально построенное серверное помещение, ленточные библиотеки, блейд-центры HP... И абсолютно нулевая организация процесса. Достаточно сказать, что интегратор, который непосредственно вел проект и поставлял оборудование, не имел реальных компетенций ни по системам IBM Power, ни по IBM HDS. SAN был по-непонятной причине реализован на оборудовании Cisco MDS, при том, что толковых спецов по SAN не так-то много, а уж знакомых с SAN оборудованием Cisco - и того меньше. Когда оказалось, что специалисты интегратора не в состоянии сконфигурировать MDS, мне пришлось самостоятельно разбираться с особенностями этих коммутаторов и конфигурить их самому.
В процессе инсталляции оборудования сбои систем охлаждения и электропитания происходили несколько раз и устранялись специалистами интеграторов/вендоров (я не вникал, кто эти люди, у меня был свой скоп работ) на ходу. К примеру, я мог придти на очередную итерацию работ и обнаружить обесточеный по питанию Power 770, что в общем случае недопустимо вообще.
В итоге, кластер был сдан мной в эксплуатацию, написан комплект документации. Однако РЕАЛЬНОГО тестирования, как нагрузочного, так и отказоустойчивости проведено не было. Специалисты со стороны заказчика (ГНАУ) явно не соотвествовали по компетенциям тем задачам, которые необходимо было решать на этом оборудовании. Я не хочу ничего плохого сказать про ребят, все они были толковые и теоретически подкованые, их отправляли на соотвествующее обучение, но на тяжелых железках учиться "по ходу" - это не лучший вариант. В целом у меня остались самые хорошие впечатления. Если бы у них было время и мотивация - все бы было отлично. Времени не было. А мотивация... ну через полгода или чуть больше я их видел на конференциях с бэджиками совсем других компаний...
В дальнейшем персонал поменялся, ребята свалили, поменялось, насколько мне известно, начальство. Сроки поддержки вендора на оборудование IBM & Hitachi закончились. Поддержку, разумеется никто не продлил, профилактические и регламентные работы не проводились, уровень квалификации персонала, который эксплуатирует данные системы также оставлял желать лучшего. Еще раз, я не хочу никого обидеть, но для эксплуатации ИС такого уровня мало иметь "общие скиллы в ИТ" или уметь администрировать прикладной софт, а железо, системное ПО и инфраструктуру обслуживать по остаточному принципу. Дальнейшие изменения в инфраструктуре и ньюансы эксплуатации мне, увы, неизвестны.
Знаю достоверно, что упоминавшийся "сервер", а на самом деле СХД DS8800 была куплена, якобы, из-за недостаточной производительности HDS VSP. Тоже показательно: вместо продления поддержки и расширения имеющейся дорогой системы, была куплена ЕЩЕ одна дорогая система. Проводился ли при этом обязательный в таких случаях site assessment, для проверки соответствия серверного помещения требованиям по электропитанию и охлаждению? Я очень сильно сомневаюсь.
Что до правдивости самой новости, насколько мне известно, основные данные были перенесены с VSP на DS8800. Возможно часть продуктивных данных осталась на VSP? Но где резервные копии? На той же СХД и ее развалившихся(?) RAID группах? Но там же были и библиотеки, и настроенная система СРК.. Или с тех пор все стало еще хуже и доломали и ее? Зачем перезагружать операционную систему для переноса данных на другое хранилище? Там стоял AIX, зачем что-то перезагружать, когда миграция данных с хранилища на хранилище выполняется абсолютно прозрачно, без останова систем? В общем вопросов больше, чем ответов. Однозначно можно сказать одно - корни сбоя кроются в бардаке в организации ИТ, свойственном для наших госструктур.
Самое печальное, что из всей этой истории никто не сделает никаких выводов. В ИТ госструктур так и будут сидеть люди, на которых будут вешать неадекватные задачи за никакую зарплату. Будет закупаться за откаты дорогое оборудование, которое будет медленно дохнуть без саппорта, а в случае сбоев - найдут крайних из тех же ИТ-шников, которые, в общем-то, ни в чем не виноваты.
UPD: в узком кругу этот пост вызвал некислый дискасс на предмет профессиональной этики, NDA, и прочих тонких материй. после долгой внутренней борьбы я этот пост таки оставляю в паблик. никого лично, надеюсь, я тут не оскорбил, никаких государственных тайн не открыл. целью этого поста было - избежать некомпетентных домыслов на тему, которые неизбежно возникают в таких ситуациях.таки в подзамок
