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