Каковы способы согласования информации об обслуживании сервера с вашей командой? [закрыто]
Я нахожусь в команде, которая координирует действия по обслуживанию и некоторые другие действия для некоторых серверов в нашей компании. Теперь, когда в команде больше людей и больше серверов под нашей опекой, становится все труднее отслеживать проблемы или советы, связанные с обслуживанием определенных серверов.
Мне интересно, есть ли какие-либо инструменты или методы, которые упрощают координацию этого типа информации? Я пробовал некоторые инструменты отслеживания ошибок, но они очень специфичны для проблем и ошибок. Сейчас мы рассылаем по электронной почте сводку после каждого действия, но если к команде присоединится новый человек, у него не будет этой истории. Я тоже думал о вики, но это казалось неудобным для такого типа ведения документации.
Например, I для серверов a, b и c я хотел бы отслеживать тот факт, что перед перезагрузкой службы 1, 2 и 3 должны быть отключены перед перезагрузкой. Если обновление произошло на серверах b и c, я хотел бы найти способ отслеживать проблемы, возникшие во время обновления. Таким образом, некоторое время спустя, если другой человек в команде будет участвовать в каком-либо обслуживании сервера «b», он сможет увидеть всю историю, связанную с этим сервером.
Мы будем благодарны за любые советы или решения.
Я пошел с двумя методами:
1) Wiki Мы - корпоративный пользователь приложений Google и мы используем функцию "Sites" как нашу Wiki. Заблокированный вниз так, чтобы только пользователи домена видели его, конечно (можно стать еще более конкретными в случае необходимости).
Каждый сервер имеет две страницы в Wiki. Одна страница для спецификаций, указаний по применению и лейтмотивов и одна страница являются журналом операций. Журнал является таблицей Даты, время, задача и индикатор перезагрузки. Идеально, ничего не происходит, который не становится зарегистрированным!
Примечание стороны: вещь "сайтов" Google делает регистрирующиеся страницы очень легкими создать использование их шаблона "List".
2) WhatsUp Pro
Я использую WhatsUp для контроля моих серверов и устройств. Где полезный, я добавил, ключевая информация ("не забывают запускать сервис x", или "удостоверяются, что интерфейс A прибывает") к свободной форме, отмечает поле устройством. Затем когда парень по вызову разбит на страницы (по SMS), текст включает те примечания. Очень удобный, чтобы иметь.
-
1Мне нравится идея Wiki с 2 страницами для каждого сервера.Спасибо! – BrianH 24 August 2009 в 21:12
-
2Upvote, полностью согласитесь с Вами. Мы используем Wiki также, (tikiwiki на самом деле.) We' ре также с помощью What' s Pro, (новая версия является хорошим ain' t это?) и I' m включающий те примечания также. Если ничто иное, it' s хороший знать, что кто-то еще независимо делает то же, как я, таким образом проверяя мои усилия.:) – Greg Meehan 24 August 2009 в 21:22
Лучшей вещью иметь это, которое я нашел, является центральное расположение для Вашей документации, о которой все знают. Я лично предпочитаю Wiki, потому что это быстро и легко. Другие опции были бы системой управления версиями как Подверсия, МЕРЗАВЕЦ или CVS. Sharepoint и его функции управления документооборотом могли бы также работать на Вас, но это будет довольно тяжелым решением для просто этой проблемы.
-
1У нас действительно есть Подверсия, но это немного более трудно искать. Мы могли найти, что некоторые хорошие стандарты для названий документа сделали информацию об открытии легче. I' ve, учитывая Wiki некоторая серьезная мысль, но я просто can' t думают о хорошем способе записать операции для сессии обслуживания. I' d нравится сделать, чтобы все сохранили журнал, когда они связаны с обслуживанием - который кажется немного более хитрым, чтобы сделать с Wiki. Это - хорошие идеи! – BrianH 24 August 2009 в 20:11
Я использовал бы SharePoint, конкретно Windows SharePoint Services. Это относительно легко, ничего не будет стоить Вам и может сделать некоторые хорошие многомерные представления данных. В он является самым простым, это мог быть просто единственный список, сгруппированный именем сервера и ролью, со вторым представлением его также сгруппированный ролью и затем именем сервера. Можно также использовать некоторые из других типов списка для функций такой, как совместно использовано ведение календаря (это является 30-м, что расшатанное старое поле должно быть перезагружено снова), контакты, и т.д.
-
1Можно ли уточнить многомерные представления? Я могу вообразить элемент списка для каждого сервера, но являюсь там путем к " join" таблица примечаний по имени сервера? Таким образом, я вижу список серверов и затем разворачиваю " notes" раздел для того сервера и видит все примечания, кто-то уехал в него? I' m принятие всего этого было бы абсолютно доступно для поиска также... – BrianH 24 August 2009 в 20:52
Это кажется на необходимость во внутренней системе покупки билетов, оперативной, который может также использоваться в качестве базы знаний для поиска/соединения мимо и связанных билетов, зарегистрированных под той же категорией.
Мы используем "Дорожку - Это!" в моей компании для отслеживания все обслуживание, включая операционные запросы. Я уверен, что там существуют некоторые другие лучше и/или более дешевые решения.
IMO, реализовывая систему покупки билетов легок, твердая часть заставляет весь admins/techs следовать за процессом создания тикета и заполнения он правильно, таким образом, он может искаться и сослан позже.
-
1Дорожка это действительно выглядит большим - но также и выглядит дорогим. Хороший совет, хотя - Спасибо! – BrianH 24 August 2009 в 21:12
Много людей, поддерживающих много серверов в доме, не отличаются, чем те же люди, поддерживающие то же количество распространения серверов по всей стране.
Система отслеживания ошибок одного человека является чьей-либо "Историей обслуживания сервера" :)
В зависимости от системы Вы выбираете, должно быть место для сохранения информации на каждом проекте (сервер) и при том присоединении случаи (инциденты обслуживания) каждого сервера.
Ничто не бьет спиральный ноутбук и перо (в моей книге) для краткой записи, что происходит, прежде чем примечания вводятся в систему в более когерентном и возможно организованном пути (при работе над чем-то, что это быстрее для записи) - иногда).
Первый шаг должен понять, что существует потребность в "системе", и заставьте кого-то платить за него.
Что касается системы отслеживания ошибок, я постараюсь не делать очевидное предложение для попытки :)
-
1
-
2
-
3Я никогда не видел, что один - это на самом деле выглядит довольно хорошим. Хм – BrianH 24 August 2009 в 21:41
Мы используем Spiceworks для отслеживания всю нашу информацию о сервере/рабочей станции и для запросов, представленных через билеты справочной службы. Большая часть - то, что это свободно.
Просто бросив другую опцию в соединение. Я использовал tiddlywiki в течение долгого времени, но это - клиент только Wiki. Существуют некоторые взломы, чтобы заставить это синхронизировать с сервером, но я не нашел, что это очень легко.
Идея, что я работаю с теперь, состоит в том, чтобы использовать tiddlywiki, чтобы отслеживать операции нашей команды с серверами и использовать Подверсию для хранения tiddlywiki в синхронизации друг с другом. Тем путем у нас есть всегда доступная копия только для чтения наших журналов, и если мы вносим изменения, мы можем согласиться на репозиторий Подверсии.
Я играю вокруг с ним, но прямо сейчас это походит на наименее дорогое, самое легкое для реализации решения.