Зачастую для того чтобы развернуть новую систему мониторинга с web-интерфейсом, систему приема заявок, базу знаний или корпоративный портал, если об этом за нас не позаботились разработчики, нам приходится заниматься инсталяцией веб-сервера, конфигурировать его, прикручивать дополнительные модули и многое другое. В таком вопросе нужно разбираться досконально, чем мы сейчас собственно и займемся.
Итак, чтобы его установить, непременно придется раздобыть его - дистрибутив Apache брать стоит здесь, файл выбирайте на свой вкус.
собственно здесь производится небольшое конфигурирование - нам предлагается либо установить для всех пользователей, на 80 порт, и запускать в качестве службы (производственный вариант), либо только для одного пользователя на порт 8080, при ручном запуске (вариант для тестов и разработчиков). Выбираем то, что нужно Вам.
В остальном установка это исключительно выбор дефолтных настроек.
По окончанию установки и запуска Apache в системном трее мы с увидим перышко (ApacheMonitor).
Другим вариантом установки может являться распаковка архива и конфигурирование вручную.
Продолжим разбираться с терминологией ITIL, дополненной моими небольшими комментариями и замечаниями, сделанными на основе практического опыта внедрения.
Бюджет - Перечень денежных средств, которые организация или бизнес-единица планирует получить или потратить в течение определенного периода времени.
Бюджетирование - Деятельность по прогнозированию и последующему контролю расходов денежных средств. Состоит из периодического (обычно ежегодного) составления Бюджетов будущих периодов и ежедневного мониторинга, уточнения Бюджета текущего периода.
Бизнес - Общекорпоративное образование или Организация, сформированные из некоторого количества Бизнес-единиц. В контексте ITSM термин Бизнес распространяется как на некоммерческие организации и государственный сектор экономики, так и на коммерческие компании. Бизнес является основным потребителем услуг подразделения ИТ. Специалисты ИТ, на всех уровнях, должны понимать, что основным в деятельности организации является бизнес и его потребности.
Бизнес-кейс - Обоснование какой-либо значительной статьи расходов. Включает информацию о затратах, выгоде, вариантах реализации, сложностях, рисках и возможных проблемах. Бизнес-кейс является одним из ключевых моментов в управлении финансами. Причем, заострять внимание стоит на выгодах, рисках и возможных сложностях, эти моменты наиболее интересны бизнесу, нужно понимать, что бизнес общается именно на этих терминах, они ему близки и понятны. Поэтому составлению бизнес-кейсов стоит уделять довольно много времени - именно они останутся в памяти бизнес-руководителей и топ-менеджеров.
Бизнес-процесс - Процесс, владение и управление которым выполняется Бизнесом. Бизнес-процесс способствует предоставлению продукта или Услуги для Бизнес-заказчика.
Например, предприятие розничной торговли может иметь Процесс закупок, который помогает предоставлять Услугу его Бизнес-заказчику. Многие Бизнес-процессы зависят от ИТ-услуг.
Бизнес-услуга - ИТ-услуга, которая напрямую поддерживает Бизнес-процесс, в противоположность Инфраструктурной услуге,
которая используется внутри Поставщика ИТ-услуг и обычно не
является очевидной для Бизнеса.Термин Бизнес-услуга также используется для обозначения Услуги, которая предоставляется
Бизнес-заказчикам от Бизнес-единиц. Например, предоставление финансовых услуг Заказчикам банка или товаров Заказчикам розничного магазина. Успешное предоставление Бизнес-услуги
часто зависит от одной или более ИТ-услуг.
Бизнес-единица - Сегмент Бизнеса, который имеет свои собственные планы, метрики, доход и затраты. Каждая бизнес-
единица владеет активами и использует их для создания ценности для заказчиков в форме товаров и услуг.
Актив - Любые ресурс или способность. Активы поставщика услуг включают в себя все, что задействовано в предоставлении услуг. Активы могут быть отнесены к одному из следующих типов: управление, организация, процесс, знания, люди, информация, приложения, инфраструктура и финансовый капитал.
Архитектура -Структура Системы или ИТ-услуги, включающая Взаимоотношения между компонентами и средой, в которой они находятся. Архитектура также включает стандарты и руководящие документы, которые определяют проектирование и развитие информационной системы.
В этой небольшой статье, я попробую представить основные термины, которые были введены нами в ходе планирования и внедрения системы управления ИТ. Материал объемный, поэтому выкладывать буду по-немногу в несколько постов, где считаю нужным будут мои комментарии, по наиболее важным пунктам или узким местам.
Активный мониторинг- Мониторинг Конфигурационных единиц или ИТ-Услуг, использующий автоматизированные регулярные проверки для отслеживания текущего статуса объектов мониторинга.
Деятельность- Набор действий, спроектированный с целью получения определенного результата. Деятельности обычно определяются как части Процессов или Планов, и документируются в Процедурах.
Оценка требований приложений - Деятельность, отвечающая за понимание требований к ресурсам, необходимым для поддержки нового приложения, или значимого изменения в существующем приложении. Оценка требований приложений помогает гарантировать соответствие ИТ-услуги установленным показателям уровня услуг в части мощности и производительности. Один из ключевых моментов в процессах управления конфигурациями, изменениями и релизами.
Предупреждение - Предупреждение о том, что было достигнуто пороговое значение, что-то изменилось или произошел Сбой. Основной сферой применения стали процессы Управления инциндентами и управления проблемами на этапе эскалации до уровня директора по ИТ и руководства предприятия.
Приложение - Программное обеспечение, предоставляющее функции, необходимые для ИТ Услуги. Каждое приложение может быть частью более чем одной ИТ-Услуги. Приложение может иметь одну или более серверных или клиентских частей. Здесь очень важно понять, что приложение - это только то, что действительно необходимо бизнесу, а не любое программное обеспечение, использующееся в компании.
Портфель приложений - Часть процесса управления конфигурациями, представляющий собой базу данных или структурированный документ, используемый для управления Приложениями в течение всего их жизненного цикла. Портфель приложений удобно использовать в части стратегического управления ИТ.
Соглашение - Документ, который описывает и формализует отношения между двумя или более сторонами. Соглашение не определяет юридических обязательств сторон, за исключением случаев, когда оно является частью договора. Является одним из ключевых понятий ITIL.
Уполномоченный - Официально наделенный полномочиями исполнять какую-либо Роль. Например, у нас уполномоченными являются менеджеры процесса, т.к. процессы структура логическая, и штатной должности не предполагает. Уполномоченный официально наделен правами Директора по ИТ в части, касающейся его процесса.
Учёт затрат - Процесс,отвечающий за идентификацию фактических Затрат на предоставление ИТ-Услуги, их сопоставление с плановыми Затратами, и управление отклонениями от Бюджета.
Предлагаю вашему вниманию занимательную книгу по личному тайм-менеджменту - Т. Лимончелли. Тайм-менеджмент для системных администраторов. Данная книга подойдет в первую очередь системным администраторам небольших компаний и работникам служб технической поддержки высокого уровня поддержки, описываемые в ней методики довольно просты в применении. Основной упор в ней делается на создание своих собственных "процедур" во всех областях жизни и исполнение их на автомате, дробление задач на подзадачи, распределение труда в коллективе. В принципе, довольно интересный материал и читается довольно легко.
А вот и аннотация к книге:
По тайм-менеджменту изданы сотни книг, но только эта написана сисадмином для сисадминов. Автор учитывает специфику их труда: работая над долгосрочными проектами, сисадмины вынуждены постоянно прерываться, чтобы наладить технику, помочь пользователям. И даже овладев всеми тонкостями профессий, сисадмин задерживается по вечерам и работает по выходным.
Основное внимание уделяется приемам, которые помогут сисадминам не только вести повседневные дела, но и справляться с неизбежными критическими ситуациями. Вы научитесь управлять отвлекающими факторами, исключать непроизводительные затраты времени, вести список дел, разрабатывать процедуры для регулярно совершаемых действий, сосредотачиваться на текущей задаче, расставлять приоритеты в соответствии с ожиданиями клиентов, документировать и автоматизировать рабочие процессы для ускорения их выполнения.
Издание насыщено примерами, взятыми автором из его долгой карьеры, на протяжении которой он занимался обслуживанием рабочих станций и серверов, а также разработкой ПО и систем безопасности. А это значит, что читатель получит советы бывалого человека. Томас давно занимается проблемой тайм-менеджмента, ведет обучающие семинары. Приемы, которыми он делится с коллегами, проверены на практике. Они работают!
У каждого из нас есть свои особые периоды максимальной умственной и физической активности, ясности и тонкости мыслей, проявления креатива - вот только обычно тратим мы их не совсем рационально. Для меня, время такого подъема - утро. Два года назад заметил за собой привычку - начинать рабочий день с разгребания почтового ящика, беглого просмотра мировых новостей, ЖЖ, ithappens, bash.org.ru, anekdot.ru, тематических блогов и новостей, за которыми слежу. В итоге пол-дня гарантированно уходило исключительно на это все, с небольшими прерываниями на выполнение прямых обязанностей. А вся соль в том, что это было в порядке вещей у всего отдела, где я тогда работал, с самого утра все втыкали в свои собственные клоаки информационного мусора, бесполезная затуманивающая ум муть лилась отовсюду. Естественно, этой же мутью мы активно обменивались по почте, через icq и jabber. Не могу сказать, что работа выполнялась плохо, или не выполнялась вообще. Нет все работало, но не было одного очень важного момента - развития. Вот оно-то и буксовало.
Вполне естественно, что перед тем как поддерживать услуги их нужно внедрить, но это естественно только в случае когда Вы начинаете разворачивать инфраструктуру с нулю, в случае если же услуги и сервисы уже кое-как внедрены, а Вам нужно внедрять ITIL поверх уже существующей инфраструктуры (как, к слову, и бывает в большинстве случае), в таком случае вы в первую очередь внедрите поддержку существующих услуг, а уже затем начнете внедрять предоставление услуг. Чем собственно, по такому сценарию я и занялся после внедрения поддержки.
Для начала опишу, какие определения получили процессы этого раздела у нас.
Любой специалист, работающий в области информационных технологий скажет, что работа с пользователями, самая проблемная и сложная, в моральном плане. Поэтому любой высококвалифицированный специалист по мере роста своего проекта\компании пытается избавиться от этих обязанностей и переложить их на менее квалифицированного специалиста. Сначала это становиться просто перераспределением функций внутри отдела, затем вычленение одного человека, который станет единой точкой обращения для пользователей. С этого момента можно считать, что поддержка пользователей организована. Можно уже считать этого человека отдельным подразделением. Изо дня в день он отвечает на вопросы пользователей, по мере развития обрастает определенными инструментами (тут уж как повезет). А дальше, начинаются чудеса. И проявляются они в том, что дальше никакого развития нет, все, потолок, увеличивается количество сотрудников, занимающихся поддержкой услуг, а не их качество и техническое оснащение.
Одним из первейших шагов вперед в направлении поддержки пользователей, который может сделать руководитель ит-подразделения - максимально технически обеспечить свою службу поддержки пользователей. Но со временем это перестает приносить ощутимые результаты, и снова выбор становиться либо на увеличении количества сотрудников, занимающихся проблемами пользователей, обработкой телефонных звонков, решением рутинных проблем, либо в изменении качественного состава службы поддержки. По опыту, перевод пары сильных программистов или администраторов проекта в сектор поддержки пользователей, с сокращением числа обычных операторов, приносит почти мгновенные положительные результаты. Квалифицированный специалист, привыкший постоянно отвечать за какую-то часть проекта, перейдя (по своему желанию) в сектор поддержки пользователей, чувствует себя куда более раскрепощенным и забирает на себя большую часть тех проблем, которые бы обычный оператор перевел бы на более высокий уровень поддержки, отвлекая тем самым более квалифицировнного специалиста.
Квалификация специалистов технической поддержки - краеугольный камень всех ит-подразделений, в одних считают нормой студента, без практического опыта работы с информационными системами, своими интересами и откровенным пофигизмом, в других, нанимают высококвалифицированных специалистов, или переводят своих сотрудников, которые в дальнейшем к рутинным вопросам работы ИТ относятся халатно, потому как нет подушки из низкоквалифицированных специалистов. Как итог - практикиа когда поддержка пользователей - щит проекта от этих самых пользователей . Проект и вся служба получают низкие оценки своей работы от пользователей и как итог от своих руководителей. Думаю дальше все довольно предсказуемо.
Так что обязанность любого грамотного руководителя найти ту золотую середину, между количество простых специалистов и квалифицированных, разделить их работу, мотивировать квалифицированного специалиста.
Дальнейший этап становиться самым сложным, подразделение разрастается до таких размеров, когда полноценно контролировать его работу и работу с проблемами подразделения в частности становиться крайне затруднительно. Вот здесь и приходит на помощь ITIL в лице ITSM. ITSM , ка кподмножжество ITIL имеет прямое отношение к поддержке и предоставлению услуг и может направить в вопросах дальнейшего построения инфрастуктуры.
После того как ITSM , внедрен остается один небольшой шаг до ITIL, и он проходится уже не так болезненно, потому как бизнес-процессы компании уже впору созрели, есть понимание направления движения компании, ее идеология и костяк.
Внедрение ITIL не является каким-то чудестным способом избавиться от всех проблем мироздания, но вот обмерять и проанилизировать работу ИТ позволяет, так же как измерять работу и каждого члена этого подразделения, так же это предоставляет гибкие и формализованные инструменты всему ИТ-подразделению.
Количество продуктов, предлагаемых для использования в области управления в информационных технологий, на первый взгляд кажется ущербным, на второй громадным, на третий и четвертый ты либо приходишь к выводу что нужно создавать что-то свое, или выбираешь конкретный продукт, просто так, потому как существенных отличий в их функциональности просто нет. Все вышесказанное относится только к категории програмных продуктов, определенных моими трабованиями, а именно наличием пользовательского веб-интерфейса.
Итак, на данный момент на рынке представлено множество продуктов, с заложенной в них поддержкой ITIL. Среди них, для себя, после прочтения большого количества материала по ним я выделил несколько.
1. Manageengine ServiceDesk Plus - комлексное решение для управления информационными технологиями, поддерживает ITIL, довольно удобен в использовании, обладает богатыеми возможностями по настройке, разграничению доступа и особенно сбору статистической информации в автоматическом режиме. Многие процессы автоматизированы, или позволяют их автоматизировать. Поддерживает импорт пользователей из ActiveDirectory и их прозрачную авторизацию.
Из недостатков выделю прожорливость до ресурсов сервера, использующего Java, Нет возможности вставить скриншот в форму заявки из буфера обмена, его необходимо прикреплять через вложение файла.
Пробную версию можно скачать с сайта производителя.
2. SysAid - очень комфортное в работа решение, менее функционально в сравнении с Manageengine, зато отлично кастомизировано, есть версия Free - поддерживает работу до 100 пользователей и 2 администраторов, не умеет практически ничего из ITIL, зато дальше есть простор где развернуться - коммерческие версии могут быть сконфигурированы практически как угодно, множество дополнительных подключаемых модулей (естественно, за дополнительную плату). В работе, немного раздражает не совсем корректный русский перевод, и невозможность использовать разные языки для админстраторской части и пользовательской (а может я не нашел). Довольно запутанное меню, требующее привыкания, но затем все просто.
3. GLPI - достойная внимания вещь, для небольшого отдела информационных технологий в самый раз, есть русский интерфейс, интеграция с AD, OCS Inventory. Работал с этой системой мало, т.к. уже был выбран продукт, но в принципе довольно интересная вещица.
По большому счете здесь можно перечислить еще два десятка похожих продуктов, все они будут чем-либо отличаться, иметь одно преимущество над другим, но уступать третьему в чем-то еще.
Так что в выборе программного обеспечения для вашего подразделения информационных технологий, в выборе я бы рекомендовал руководствоваться соображениями удобства для пользователей, поддержки и цены продукта. ФУнкциональность же у всех примерно одинаковая.
От себя добавлю что мы выбрали открытый программный продукт, и ниразу об этом не пожалели, хотя изначального его даже не рассматривали.
Лицо должно быть красивым, улыбающимся и приветливым.
Пользователь - живой человек.
Отвечая на письмо пользователя, подумай: а устроил бы такой ответ тебя? Не забывай, что с другой стороны монитора живой человек и общаться с ним нужно как с живым человеком.
Любое письмо - вопрос.
Если пользователь написал, значит у него проблема, и он хочет получить ответ именно на поставленный вопрос, а не отписку, не имеющую отношения к его проблеме. Всегда отвечай на вопрос пользователя.
Читай переписку.
Тебе понравится, когда одно и то же спрашивают по несколько раз? Обязательно читай переписку полностью.
Сокращай итерации.
Если пользователь предоставил недостаточно данных, лучше попросить его прислать всё необходимое (или даже больше) в одном письме, а не задавать по одному наводящему вопросу.
Одно предложение - не ответ.
Ответ обязан содержать помимо ответа на вопрос пользователя еще и объяснение причин возникновения проблемы. Ответ в одно предложение - отписка.
Непонятного - боятся.
Письмо в поддержку - крик о помощи. У пользователя что-то пошло не так. Он не понимает в чем дело. Ответ должен успокоить его, а не вогнать в еще большую панику. Саппортер - всегда немного психолог.
Не задерживай ответ.
Если решение проблемы затягивается, не молчи: скажи пользователю об этом. Не бойся признать наличие проблемы, скажи, что ее решают, назови примерные сроки. Если сроки пока никто не знает, пообещай связаться сразу же, как только получишь ответ - и сделай это! Пусть пользователь знает, что о нем не забыли.
Ты - не робот.
Не старайся отгородиться от пользователя формализмом и канцелярщиной сухих фраз. С живым человеком ему наладить диалог намного проще. Не бери пример с госучреждений.
Не бойся спрашивать.
Если не знаешь, что ответить пользователю - спроси у коллег. Лучше узнать точно, чем показать свою некомпетентность в вопросе пользователю. Не поленись проверить ответ перед отправкой.
Как известно каждому, кто думает о внедрении ITIL в своей организации, первейшей задачей, в случае внедрения на уже работающую инфраструктуру, будет внедрение всеобъемлющей поддержки услуг.
В моем случае, инфраструктура без видимых изменений действовала уже несколько лет, бизнес-процессы компании были сформированы и работали хорошо. Служба ИТ практически без превлечения сторонних организаций занималась к администрирование и поддержкой работы инфраструктуры, так и разработкой и сопровождением проектов.
Подразделение helpdesk занималось обработкой заявок пользователей, велась единая база этих заявок, эскалация производилась на один уровень до прямого исполнителя в случае с серьезными проблемами в программном коде или аппаратном обеспечении.
Использоватлась своя разработка на основе Lotus Notes.
Первым шагом во внедрении ITIL стала разработка нормативной базы именно для службы поддержки пользователей, которая бы соответствовала стандартам.
В это документацию мы включили
-Соглашение о уровне услуг (SLA)
- Каталог услуг
- Инструкция по эскалации
к тому моменту уже существовала внутренняя база знаний, матрица приоритетов, правила закрытия заявок, но все они нуждались в переработке.
Как итог - перерабатывать пришлось абсолютно всю документацию.
Не менее важным моментом стало то, что было принято отказаться от работы с имеющейся программной платформой. Во многом на это повлияла сложность разработки адекватного требования программного обеспечения. Был начат поиск подходящих вариантов, для использования в качестве единой базовой основы работы IT.
Не стану вдаваться в описание всех красивостей и полезностей ITIL для среднестатистической службы IT, отдельно взятого it-директора или простого сисадмина, не буду вставлять и большие копипасты с wikipedia и прочих крайне популярных ресурсов, хотя без этого тоже не обойдется. А попытаюсь рассказать о практике внедрения iTIL в отдельно взятой компании, которая по мере своего роста пришла к нему. Так же напомню, всем джедаям, которые особо увлекаются чтением стандартов, но не практикой внедрения, что таких компаний большинство и опыт внедрения ITIL в компании в 20.000 человек, пригодится только 1%, а опыт внедрения в компании с числом около 1.000 сотрудников будет интересен многим.
Итак, черный ящик открывается и из него появляется великий и ужасныйITIL, встречайте!
ITIL (произносится как «айти́л», IT Infrastructure Library — библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.
Честно говоря не лучшее определение, но для начала сойдет. Да действительно это набор библиотек, которые рекомендуют нам best practices. ITIL не единственна в своем роде. Существует еще много различных документов, продумывающих работу IT службы, от того же cobit и до метода сисадмина Васи Пупкина, организовавшего работу в своей организации в соответствии со своими лучшими практиками и видением мира.
Мой выбор остановился на ITIL, и объяснять ее преимущества и недостатки я не стану, потому как они есть везде, а их обсасывание является пустейшей тратой времени, не ведущей не к чему.