Начиная с Адама Смита, уже лет 230 с гаком, концепция разделения труда определяет профессиональную специализацию и зоны ответственности, что особенно заметно в условиях научно-технического прогресса. Очередная НТР, в виде виртуализации серверов, создала новую специализацию, условно, администратор/менеджер виртуальной инфраструктуры. При этом, осталась роль администратора/менеджера инфраструктуры физической. Но, что поменялось для последнего? Самое главное – на некоторое время он был лишен своих рецепторов, сервера было нечем мониторить – датчики отсутствовали в принципе, либо были сильно ограничены. Ситуация актуальна и в настоящее время, что подтверждают наши источники. Радует только одно, что в данном направлении работают и производители средств виртуализации, и производители серверов. На данный момент техническая проблема мониторинга серверов решается и компанией VMware. В скором времени будут доступны дистрибутивы ESXi для всех крупных вендоров со встроенными CIM-агентами.
Но, есть не меннее важная проблема специализации – это организационное разделение зон ответственности. Какая картинка предстаёт перед нами? Администраторы виртуализации ставят гипервизор без средств мониторинга аппаратной части, ссылаясь на отсутствие ответственности за оную. Если устанавливается полный ESX, то проблема зачастую решается путём долгих уговоров установкой средств мониторинга под RHEL в консоль, а если используется ESXi, то убедить заменить на аналогичный дистрибутив от Dell, IBM,HP бывает очень трудно, по причине непонимания “софтварщиками” проблем “железячников”. Как итог, появляется стыковка-нестыковка инфраструктур, если договорились и думали системно, то первое, а если каждый думал о своей “Специализации”, то второе.
Хотелось бы напомнить, что невозможно создать эффективную систему управления (АСУ) только техническими методами, так как её эффективность определяют организационные методы. Например, “виртуальщику” очень нравится новая функция VMware Fault Tolerance, которая якобы совсем отвязывает виртуальные машины от падений аппаратной части, но довольно просто представить ситуацию повышения температуры в серверной до 35-45 градусов(отказ системы или сети хранения, потеря электропитания), когда виртуальным машинам просто некуда будет сбежать. Получается, что технически получили отказоустойчивую виртуальную среду, но в определённых условиях получили нулевую бизнес-эффективность, так как организационно не определили взаимодействие.
Построение систем требует системного подхода, просьба не забывать об этом, одни объекты системы взаимодействуют с другими, при отсутствии взаимодействия система распадается. Так будем взаимодействовать!
P.S. Если считаете, что это касается только крупных организаций, где много администраторов, то вы ошибаетесь, в малом бизнесе, где работает 1 человек, происходит немного другая проблема: потеря знаний об объектах системы и их взаимодействии – “не знал, да забыл”.
Согласен с тем, что проблема нестыковки инфраструктур вызвана в большей мере отсутствием определенных оргмер, чем технических.
Например, есть два менеджера: физических и виртуальных серверов, а координирующего звена – руководителя между ними нет.
Соответственно, стыковка получится при наличии между ними эмоционального контакта. Если контакта не будет, они пошлют друг друга туда, где солнце не встает. И будут тянуть одеяло на себя.
Подобный пример приводит и Брукс в “Мифический человеко-месяц”.
При разработке OS/360 программисту выдавался определенный объем памяти для его части системы. Если он не укладывался в него, то разбивал программу на оверлеи. В результате, программист укладывался в заданный объем памяти, но суммарное количество оверлеев замедляло работу системы в десятки раз.