Показатели производительности сисадмина?
Я работаю в dot com, и часть ответственности нашей команды - поддерживать производственное веб-приложение и ферму серверов. Только недавно наш отдел даже был создан, и теперь у нас есть огромное количество серверов для исправления ошибок, а также для реализации мониторинга и резервного копирования.
Чтобы начать работу с этим монстром, мы разбили его на этапы, и как часть нашего первого этапа мы переустанавливаем ОС на нескольких серверах, получая их обновления из старых версий ОС Redhat 8 (не Fedora 8). В качестве веб-приложения на серверах должны работать apache и php. Модули, которые должны быть скомпилированы в эти программы, задокументированы, и задокументирован старый процесс сборки для компиляции.
Как сисадмины, что вы, ребята, ожидаете документировать, и что вы должны документировать? Поскольку процесс сборки и документация должны быть обновлены, каков наилучший способ размещения элементов, которые необходимо выполнить? Определение шагов должно быть частью работы системного администратора или частью работы технического менеджера? Является ли это частью квалификации "старший инженер Unix" против младшего инженера? Какой стандарт вы хотели бы придерживаться для оценки вашей эффективности в таком проекте, как этот, если это повлияет на ваш обзор эффективности?
Изменить: приложение находится в стадии постоянной разработки. Большая часть написана на PHP4 и продолжает работать на PHP4, однако более новый код, работающий в качестве веб-службы, работает как PHP5. Так что на одних и тех же блоках есть и php4, и PHP5. Модули, необходимые для каждой сборки, документированы. Сисадмин имеет этот документ.
6 ответов
Если это уникальная проблема, как вы можете измерить, кроется ли проблема в человеке или в проблеме?
Вы должны документировать все, что потребуется для работы вашего отдела, если половина ваших сотрудников будет убита / уволена / и т. Д.... если вам нужно перестроить отдел с новыми администраторами, они смогут снова запустить работу на новом местоположение с вашей документацией.
На практике... хи! Да правильно. Вам повезет, если документы будут обновляться, даже если они созданы в большинстве мест.
Если вы управляете задачами монстров, возможно, вам просто нужно встретиться с админами и спросить, как идут дела и что пытались. Если за эти три недели ему была поручена только эта проблема, и она не решается, это потому, что он не работает над ней? Что он пытался исправить проблему?
Ты не сможешь решить проблему на микроуровне, иначе он, вероятно, начнет с тобой бороться. Сисадминам нужно достаточно свободы, чтобы работать, не чувствуя, что его внимательно изучают на каждом шагу. Но если проект или задача действительно сильно отстают, у вас есть законное беспокойство. Выясните у него, есть ли что-то, в чем он нуждается, чтобы выполнить работу, или в чем проблема в том, что он испытывает трудности с преодолением.
Хорошая книга: Управление людьми Майкла Лоппа.
Производительность должна зависеть от того, насколько хорошо ИТ-проблемы решаются для удовлетворения потребностей пользователей, наряду с обслуживанием серверов и проблемами инфраструктуры. Вы не можете свести проблему к "решению X проблем в день" или "написанию X строк кода" для измерения каждого сотрудника.
Может быть, вы можете получить информацию от других членов команды, чтобы получить обратную связь о том, как дела друг у друга или каковы основные потребности. Хорошие технари хотят работать с хорошими технарями. Они не хотят работать с людьми, которые "счастливы и хороши", но некомпетентны. Они будут работать с сварливым придурком, который ненавидит находиться в комнате с ними, если это означает, что все работает хорошо, и обманщик знает свое дело.
Старый материал (Наследие) может быть трудным:
Если я правильно прочитал, у вас есть старые сборки программного обеспечения, и вы пытаетесь запустить его на последних сборках ОС. Red Hat 8 уже 7 лет, так что я бы сказал, что приложение тоже нужно обновить (возможно, эти модули с тех пор не обновлялись). Так что это звучит как сложный беспорядок, как вы говорите.
Документирование и ожидания:
Это зависит, но вы действительно должны изложить то, что вы ожидаете в целом. Сделайте все, что вы хотите, очень ясно. Тогда вы сможете доверить администратору выполнить это и обновить вас, если они не смогут по какой-то причине. Вы можете проверить с ними, и убедитесь, что они делают это. Системное администрирование странно тем, что оно сильно различается от позиции к позиции, поэтому может потребоваться некоторое время, чтобы заставить их понять, чего вы от них ожидаете.
Моя рекомендация, общайтесь!
Я думаю, что мы не можем сказать вам, если это не сложные проблемы. Разработчики не должны быть настолько далеки от системных администраторов, поэтому, если у вас возникли проблемы, попросите разработчика, которому вы доверяете, сесть с администратором и помочь ему решить эти проблемы. Этот разработчик должен быть в состоянии дать некоторую обратную связь.
Что касается обновления Все:
Некоторые мысли, которые могут или не могут быть полезны:
- Насколько сильно это используется? Может быть, было бы лучше виртуализировать это и забыть об этом:-P
- Насколько сложно приложение? Может быть, это будет дешевле и займет меньше времени, просто восстановить? Это также относится к обновлению приложения, возможно, если эти модули устарели, эти части следует извлечь и перекодировать. Это также относится к общению, объединению системных администраторов и разработчиков, чтобы найти лучшее решение, если вы можете.
Я бы сказал, что если ваш системный администратор не может завершить установку собственной ОС через 3 недели, либо он / она некомпетентен, либо вы каким-то образом путаете его / ее, что приводит к бесконечным задержкам. В описанном вами сценарии базовый / базовый рабочий процесс должен быть следующим: команда управления и / или развертывания составляет список требований и зависимостей. Требования будут включать временные рамки, масштабируемость, отказоустойчивость, надежность, пороговые значения доступности и т. Д. Зависимости будут охватывать, какие приложения необходимо запускать на сервере, и, опционально, какое программное обеспечение требуется для поддержки этих приложений. Сисадмин мог бы справиться с последним, если у вас не было очень определенных, известных потребностей в отношении программного обеспечения и версий программного обеспечения. В любом случае, все это должно быть задокументировано, с процессами одобрения, чтобы "парень вниз по коридору" не мог вносить изменения за спиной людей и в конечном итоге возиться с рабочим процессом и ожиданиями сисадмина. Как только вся информация передана сисадмину, он / она сможет предоставить более или менее точную оценку времени.
Из того, что вы сказали, похоже, что этот человек даже не тестирует сборки, чтобы увидеть, все ли работает. В идеальной среде должен быть установлен набор тестовых сценариев, чтобы можно было проверить правильность сборки или нет, запустив указанные сценарии. Они будут проверять не только функциональность, но и наличие или отсутствие правильных версий программного обеспечения (в том числе системные библиотеки и библиотеки приложений). В больших средах весьма обычно иметь целую команду, посвященную также тестированию производительности, так что после развертывания сервера и его установленных приложений вы можете быть уверены, что он будет функционировать и масштабироваться так же, если не лучше чем, в лаборатории или постановочной среде. Это еще одна вещь: постановочная среда является ключевой. У вас могут быть политики, требующие перехода серверов из лабораторной среды в промежуточную и, наконец, в производственную среду.
Я не возражаю, если системному администратору понадобится время, чтобы тщательно изучить все, чтобы, когда сервер запущен в работу, он работал отлично. Раньше я знал парня, который сделал это. Не то чтобы он был некомпетентен; скорее он знал о серьезности неудачных развертываний, и поэтому ему потребовалось немного дополнительного времени, чтобы на 100% убедиться, что все было кошерно. Пока что его репутация почти безупречна, и я бы порекомендовал его любой команде системного администратора. Тем не менее, повторяющиеся промахи при выполнении простых задач должны поднимать оранжевые (еще не красные) флаги. Базовый системный администратор должен знать свои операционные системы и часто используемые библиотеки приложений, поэтому, когда приходит время строить систему, у него очень мало вопросов о том, какую ОС использовать, а какие библиотеки и приложения развертывать. Что касается пользовательской сборки сервера для набора пользовательских приложений, мне потребовалось бы около 1-2 дней, чтобы завершить базовую установку и настройку (плюс настройки производительности, усиление и т. Д.). После этого все будет зависеть от того, что нужно установить. Чем больше требований к программному обеспечению, тем больше времени потребуется для сборки, установки и тестирования, и, возможно, именно это сдерживает вашего системного администратора. Я не могу сказать это наверняка, так как вы не предоставили достаточно информации.
Надеюсь, это поможет.
Майкл
Я проделал большую работу системного администратора для стартапов, и я должен сказать, что старая документация хуже, чем отсутствие документации. Я не могу сосчитать, сколько раз я просматривал существующую системную документацию, чтобы понять, как все сшито, и обнаружил, что система полностью перестроена.
Эта ситуация обычно возникает, когда системный администратор покидает компанию, и его последней задачей является документирование систем. С одной ногой за дверь качество получаемой информации часто оставляет желать лучшего. И если системный администратор не заменяется сразу (в обычном случае), системы обычно управляются наименее компетентным и / или младшим разработчиком (так как у него есть время). Это означает, что системы могут быть не синхронизированы, не документированы и, в худшем случае, различаться от машины к машине (настоящая проблема с кластером веб-приложений, в котором одно отличается от других).
Я ненавижу вики-синтаксис, но мне нравится, что системная документация находится в вики, поэтому у меня есть хотя бы отметка времени и имя того, кто задокументировал, что и когда. Установка MediaWiki проста в настройке и идеально подходит для системных задач.
Что касается того, как хорошо ваш старший. Сисадмин это, сложно сказать. Многие из нас отстой, и многие уходят на второй план, просто выполняя свою работу. И у всех нас есть плохие дни.
Недавно я потратил безумное количество времени (например, несколько дней), пытаясь заставить Ganglia скомпилировать на 64-битной машине только для того, чтобы обнаружить, что это было ошибкой в компоновке. Я уверен, что выглядел как полный идиот для этих людей...
Мост Сисадмин - довольно хорошие программисты, по моему опыту. Выяснение опций компиляции, чтобы заставить что-то работать, не должно быть проблемой, если только это не что-то неочевидное. Похоже, у вашего сисадмина есть все необходимое для выполнения работы, но дьявол кроется в деталях.
Мой совет - будь прямым и спроси в чем проблема. И посмотрите книгу "Управление людьми", которую предложил кто-то другой - это очень хорошо.
Этот парень, вероятно, бесится, потому что, похоже, ваша ИТ-среда - это кошмар, основанный на вашем кратком объяснении того, как все работает.
Я бы поспорил на никель, что инструкции, которые ваша SA получает от разработчиков / сотрудников бизнес-единиц, также ужасны. Попросите кого-нибудь сесть между людьми, подающими запросы, и парнем, который работает. Пусть они отклоняют запросы, которые не имеют смысла, и документируют, что делается.
Эйнштейн сказал: "Insanity делает одно и то же снова и снова и ожидает разных результатов"
Отличные ответы выше. Я особенно хотел бы подчеркнуть этот момент из поста Барта:
Вы должны документировать все, что потребуется для работы вашего отдела, если половина ваших сотрудников будет убита / уволена / и т. Д.... если вам нужно перестроить отдел с новыми администраторами, они смогут снова запустить работу на новом местоположение с вашей документацией.
Это абсолютно необходимо для некоторых методов ведения бизнеса, и это должно быть требованием, а не вариантом. Что если "единственный, кто знает жизненно важную систему XYZ" уйдет на вас или его уволят? Люди есть люди - такие вещи случаются. Документируйте основные системы и процессы, любые особые требования, предостережения, какие серверы отвечают за что. Это, по крайней мере, основа - большинство приличных администраторов выяснят мелкие детали как часть своей работы.
Однако, как повторилось выше, в "реальной жизни" вам действительно посчастливится создать эти документы, причем гораздо менее актуальные и правильные. ИМО, стоит стянуть администратора с проекта и поручить ему ознакомиться с документацией, если это возможно.
Надеюсь, все получится.