По рекомендациям почти с Вами согласен, единственное что думаю управление конфигурациями все-таки необходимо для более полноценной отчетности перед бухгалтерией, да и сама по себе инвентаризация вещь хорошая. Другое дело что не нужно делать ее слишком детальной.
ITIL не бывает в чистом виде, нет четких рекомендаций как и что нужно внедрять. Это всего-лишь набор инструкций. Внедрив только управление инцидентами, вы уже автоматически внедрили у себя ITIL. Я как-бы хотел и развеять этой статьей миф, что он не работает в маленьких компаниях.
Пускай в полном объеме и не нужно внедрять там управления проблемами, но понимать что это такое и уметь оформить проблему, пускай в виде отдельного инцидента не помешает.
Таких ситуаций как Вы описываете не существует, ломается абсолютно все и обычно в самый неподходящий момент. Запросы поступают со всех сторон и самые различные.
Зря Вы админа с охранником сравнили. Небось он у Вас обязательно свитер носит и пьет пиво на работе?
Как раз наоборот, это практично с точки зрения бизнеса и оптимизации рабочего времени администратора. Да и с позиции пользователей… смотрите сами. Неужели профессиональный работник хочет ежедневно ловить админа, и спрашивать его — когда уже будет приобретена новая клавиатура, или установлен специфическое ПО? Отнюдь, ему это явно не в радость. Он попросту вынужден тратить свое время на эту беготню — и именно из-за отсутствия в организации удобной системы взаимодействия между пользователем и техническими специалистами.
К тому же, в тех редких случаях, когда онлайн-заявку подать нельзя, всегда можно зарегистрировать ее по телефону. Что до паролей к WiFi, или адресов POP3\SMTP — согласитесь, пользователю не нужно знать ни того, ни другого. Поскольку первое — риск для системы безопасности предприятия, а второе — работа, собственно, администратора — и никак не сотрудника.
А документировать вызовы — необходимо. Поскольку это отражает реальную работу администратора, и реальный уровень пользователей, а также рентабельности оборудования. Это важные бизнес-показатели, и всем выгодно отражать их объективно.
Поэтому согласиться с Вами я могу только в одном: после внедрения этой системы, к админу действительно будет не подойти. Ведь этого и следует добиваться — убрать из системы технической деятельности человеческий фактор. Админ — это техническая, а не социальная позиция.
Смысл в том, что по ходу времени компании развивается ей нужны все больше новых сервисов, к примеру IP телефония, а времени внедрять ее у вас не будет из-за вот таких запросов. Обилие «глупых» запросов может послужить основанием для выделения рабочего места под вашего помощника.
С другой стороны верно и то, что в большинстве случаем поможет и обучение пользователей. Оно тоже приведет к уменьшению запросов=освобождению вашего времени.
Конечно, если офис насчитывает малое — десять, скажем — число машин, то можно обойтись обычным журналом. Но если парк техники больше, а вы все еще один — следует оптимизировать свое время. Которое обязательно будет потрачено на верстку понятного для начальства отчета по журналу, на поиск в журнале критических инцидентов (для определения слабых мест инфраструктуры), на просмотр истории инцидентов с компонентом базы.
Экономия времени — это тоже важно, пусть даже придется затратить какие-то усилия в самом начале. Не обязательно что-то разрабатывать можно попробовать что-то бесплатное. Например, ru.wikipedia.org/wiki/OTRS
Абсолютно все запросы нужно регистрировать! Если действительно запрос срочный, например исходит от начальника — то нужно пойти и выполнить его, а постфактум записать в базу. Сотня таких запросов за квартал уже будет являться причиной найма низкоквалифицированного специалиста для освобождения вашего времени.
Так как мы рассматриваем малый бизнес — то выхода тут два: сотрудник обращается напрямую к администратору, либо создает запрос по телефону. В обоих случаях инцидент регистрирует администратор. Если есть веб-интерфейс, он действительно может использовать компьютер коллеги.
К слову, в большом бизнесе оно ничем не отличается — мы используем компьютер коллеги вместе с коллегой и от его имени регистрируем инцидент, либо если коллега отсутствует — используем телефон.
Нужно сначала определиться с приоритетными направлениями, развитием. Затем реализовать эти планы в дизайне. После этого нужно в тестовой среде уже физически реализовать все. Затем из тестовой среды перенести в продакшен. Потом все мониторить и вносить изменения, согласовывая с конечным потребителем сервиса(пускай это будет конечный пользователь). Хорошо это все документировать.
И это все делают 1 или 2 человека? Я тут привел совсем облезлый пример, есть еще закупки, управление доступностью сервисов, все то что Вы упомянули в статье и много другое.
Даже если у Вас получается это все делать на отлично где гарантии, что после Вашего ухода эта инфраструктура сохранит управляемость?
Из моего личного опыта — даже если человек и дорастает до уровня архитектора, он планирует лишь часть инфраструктуры, взаимодействуя с другими.
Мое мнение что нехватка кадров при управлении большой инфраструктурой — жлобство со стороны компании, за которое она может очень сильно поплатиться.
Во-во, точно, читая статью подумал о том что описывается типичный CIO. Ниже узкопрофильные системные инженеры, менеджмент по направлениям, который вырос из этих самых инженеров или чаще просто менеджмент.
А вообще рекомендовал бы топикстартеру почитать ITIL на досуге, очень нехорошо управление всей ИТ инфраструктурой компании держать в одних\нескольких руках. Разграничивать нужно, уменьшая риски.
ITIL не бывает в чистом виде, нет четких рекомендаций как и что нужно внедрять. Это всего-лишь набор инструкций. Внедрив только управление инцидентами, вы уже автоматически внедрили у себя ITIL. Я как-бы хотел и развеять этой статьей миф, что он не работает в маленьких компаниях.
Пускай в полном объеме и не нужно внедрять там управления проблемами, но понимать что это такое и уметь оформить проблему, пускай в виде отдельного инцидента не помешает.
В крупной компании и проблем больше, там админу тоже некогда особо отдыхать, все время нужно настраивать, оптимизировать, внедрять сервисы.
Зря Вы админа с охранником сравнили. Небось он у Вас обязательно свитер носит и пьет пиво на работе?
К тому же, в тех редких случаях, когда онлайн-заявку подать нельзя, всегда можно зарегистрировать ее по телефону. Что до паролей к WiFi, или адресов POP3\SMTP — согласитесь, пользователю не нужно знать ни того, ни другого. Поскольку первое — риск для системы безопасности предприятия, а второе — работа, собственно, администратора — и никак не сотрудника.
А документировать вызовы — необходимо. Поскольку это отражает реальную работу администратора, и реальный уровень пользователей, а также рентабельности оборудования. Это важные бизнес-показатели, и всем выгодно отражать их объективно.
Поэтому согласиться с Вами я могу только в одном: после внедрения этой системы, к админу действительно будет не подойти. Ведь этого и следует добиваться — убрать из системы технической деятельности человеческий фактор. Админ — это техническая, а не социальная позиция.
С другой стороны верно и то, что в большинстве случаем поможет и обучение пользователей. Оно тоже приведет к уменьшению запросов=освобождению вашего времени.
Экономия времени — это тоже важно, пусть даже придется затратить какие-то усилия в самом начале. Не обязательно что-то разрабатывать можно попробовать что-то бесплатное. Например, ru.wikipedia.org/wiki/OTRS
К слову, в большом бизнесе оно ничем не отличается — мы используем компьютер коллеги вместе с коллегой и от его имени регистрируем инцидент, либо если коллега отсутствует — используем телефон.
Архитектор занимается дизайном и не обязательно системы, это может быть ее часть. Например, занимается дизайном AD в Windows среде.
Прошу прощения, но статья на английском.
en.wikipedia.org/wiki/Systems_architect
Нужно сначала определиться с приоритетными направлениями, развитием. Затем реализовать эти планы в дизайне. После этого нужно в тестовой среде уже физически реализовать все. Затем из тестовой среды перенести в продакшен. Потом все мониторить и вносить изменения, согласовывая с конечным потребителем сервиса(пускай это будет конечный пользователь). Хорошо это все документировать.
И это все делают 1 или 2 человека? Я тут привел совсем облезлый пример, есть еще закупки, управление доступностью сервисов, все то что Вы упомянули в статье и много другое.
Даже если у Вас получается это все делать на отлично где гарантии, что после Вашего ухода эта инфраструктура сохранит управляемость?
Из моего личного опыта — даже если человек и дорастает до уровня архитектора, он планирует лишь часть инфраструктуры, взаимодействуя с другими.
Мое мнение что нехватка кадров при управлении большой инфраструктурой — жлобство со стороны компании, за которое она может очень сильно поплатиться.
А вообще рекомендовал бы топикстартеру почитать ITIL на досуге, очень нехорошо управление всей ИТ инфраструктурой компании держать в одних\нескольких руках. Разграничивать нужно, уменьшая риски.
также есть хорошая книжка:
SECURITY AND QUALITY
OF SERVICE IN AD HOC
WIRELESS NETWORKS
AMITABH MISHRA
Johns Hopkins University
Все маленькими группами занимаются этой проблемой, но идея просто отличная.
Нельзя очернять людей без фактов!
При -18 видел как бегают по Осло. Видел еще Th!nk, но линков не нашел.
В Голландии активно ездят Canta — на вид как Норвежские.
SO — Service Operations. Совсем другой курс.
otrs.org/download/
freshmeat.net/projects/otrs/