Service Desk - ITIL на коленке

Брайан Трейси - Оставьте брезгливость, съешьте лягушку

2010-12-31T07:48:00.005+02:00

В канун Нового года, мне довелось прочесть одну из, на мой взгляд, наиболее удачных книг по тайм-менеджменту. Самое что интересное в ней нет ни одного прямого отзыва к тайм-менеджменту, автор не нудит о том, что не хватает времени на все и не рассказывает как найти это время, он не дает никаких научных и околонаучных выкладок, и тем более статистических результатов. Наоборот, он практически сразу говорит, что, таки да, смиритесь, вам никогда не хватит времени на все - выберите самое значимое.
Именно это и позволило мне назвать эту книгу одной из лучших. Она хорошо подходит именно для технических специалистов, в первую очередь потому, что излагаемые в ней принципы просты, а их реализация остается полностью за вами, вам не навязываются какие-то строгие принципы.

1. Подготовьте “стол”. Определитесь с полной ясностью, к чему вы стремитесь. Ясность целей — совершенно необходимая вещь. Изложите на бумаге свои цели и задачи перед тем, как приступать к работе.
2. Загодя планируйте каждый свой день. Думайте “на бумаге”. Каждая минута, потраченная на планирование, способна сэкономить вам от пяти до десяти минут в работе.
3. Применяйте правило 80/20 во всем. 20% всех ваших дел соответствует 80 % достигаемых вами результатов. Всегда старайтесь направлять максимум своих усилий на названные “лучшие” 20 процентов дел.
4. Думайте о последствиях. Ваши самые важные задачи суть те, которые влекут наиболее серьезные последствия, положительные или отрицательные, для вашей жизни и работы. Уделяйте им повышенное внимание.
5. Постоянно применяйте метод “АБВГД”. Перед тем как начать работу в соответствии с перечнем дел, посвятите несколько минут тому, чтобы упорядочить их по значимости, благодаря чему вы обеспечите правильный порядок работы, а именно, согласно принципу: более важные дела — в первую очередь.
6. Основное внимание — ключевым категориям результатов. Дайте определение тем результатам, которых вам обязательно надо достичь в своей работе, и добивайтесь их на протяжении всего дня.
7. Закон “вынужденной производительности”. У вас никогда не хватит времени на все дела, по на самые важные из них время найдется всегда. Остается определить, что это за дела.
8. Тщательно подготовьтесь, перед тем как начинать работу. Подготовкой предваряют правильные поступки и предотвращают плохие.
9. Постоянно повышайте свой класс. Чем больше знаний и умений приобретаете вы в своей сфере деятельности, тем легче вам приниматься за наиболее важные задачи и быстро находить их решение.
10. Знайте и используйте свои особые таланты. Поразмыслите над тем, в каких вопросах в своей сфере деятельности вы являетесь подлинным специалистом или могли бы стать таковым, и направьте свою энергию на выполнение соответствующих задач.
11. Определяйте сдерживающие факторы. Определяйте “узкие места”, “непрочные звенья”, возможные недостатки и препятствия внутренней и внешней природы — все то, что накладывает ограничения на скорость, с которой вы достигаете своих наиболее значимых целей. Прикладывайте необходимые усилия к снижению их влияния.
12. “Одна нефтяная бочка за один раз”. Вы в состоянии выполнить самую объемную и сложную работу при условии, что будете осуществлять ее поэтапно.
13. Принуждайте самого себя к действию. Представьте себе, что уезжаете на месяц и перед отъездом вам необходимо закончить свои самые срочные дела. Подобная психологическая установка способна прекрасно повысить вашу дисциплину в работе.
14. Доведите до максимума собственные внутренние силы. Определите периоды времени в течение суток, когда ваша физическая и интеллектуальная активность достигает своего пика, и планируйте работу так, чтобы наиболее важные и требующие усилий задачи приходились на эти периоды.
15. Обеспечивайте себе стимулы для работы. Станьте ярым болельщиком в отношении самого себя. Находите положительные стороны в любой ситуации. Концентрируйте внимание на поиске решения проблемы, нежели на малосущественных ее аспектах. Придерживайтесь оптимистического мировоззрения и старайтесь играть во всем конструктивную роль.
16. Творчески распределяйте свое время. Поскольку вы не в состоянии уделить достаточно времени всем своим делам, вы должны научиться откладывать на потом малозначащие задачи, с тем чтобы у вас находилось время на небольшое количество дел по-настоящему важных.
17. Выполняйте самую трудную задачу в первую очередь. Начинайте день со своей самой сложной задачи, решив которую вы способны внести серьезный вклад в собственную карьеру, и проявляйте упорство, выполняя ее не иначе как до самого конца.
18. «Разрезайте» задачу на ломтики. Разбивайте крупные, сложные задачи на элементы, представляющие собой вполне посильные подзадачи, после чего выполнение одной из последних позволит вам начать работу над основной задачей.
19. Практикуйте сегментацию времени. Организуйте свой рабочий день вокруг крупных сегментов времени, в течение которых вы можете посвятить себя выполнению наиболее важных задач.
20. Чувствуйте неотложность. Вырабатывайте в себе привычку работать быстро с важными задачами. Приобретайте репутацию человека, способного работать быстро и качественно.
21. Одна задача — одна работа. Определитесь с приоритетами, приступайте к своей самой важной задаче и трудитесь над ней без остановок, пока не выполните ее на 100 процентов. Это истинный ключ к профессиональному успеху и максимальной продуктивности в работе.

Вот в принципе краткое содержание книги, которая в моем варианте заняла всего-лишь 110 страниц печатного текста. Эта книга не о классическом тайм-менеджменте, а больше о психологии, психологии принятия решений и психологии лидера. Как и с любой книгой, с ней нужно работать и ее нужно принять.

модель построения службы поддержки пользователей

2010-12-11T20:51:00.000+02:00

Когда закончено планирование новой структурной еденицы - службы поддержки пользователей, а оно обычно (для среднестатистической организации) заканчивается на определении ответственного, который собственно и станет ее организовывать.
И вот когда создана примерная модель функционирования службы, оказывается, что все как-то не так, как это виделось в начале проекта (в лучшем случае). Вот здесь и наступает момент, когда нужно наконец-то серьезно взяться за планирование, отложить сроки, молить руководство о дополнительных ресурсах, стоять на своем, кидаться на спину и сучить ногами, выбивая дополнительные средства.

Проблема в голове. А вернее в тех неправильных представлениях, которые, собственно, в этой голове и находятся. В момент первоначального планирования, служба поддержки пользователей, видится неким колл-центром, который маршрутизирует звонки и решает простые вопросы, типа "куда нужно кликнуть, чтоб было счастье".Но, внедри Вы такую модель, и через месяц ощутите, что нужно начинать планировать вновь.

Итак, суть - служба поддержки пользователей - это в первую очередь персонал, который там работает, те люди, которые изо дня в день занимаются не самой интересной, но крайне важной в масштабах всей службы работой. И кого туда набирать - решать Вам.
По моему мнению, выбор очевиден - необходимо набирать максимально квалифицированный персонал. Т.е. данная позиция ни в коем случае не должна быть начальной в масштабах отдела, управления, службы. Если у Вас есть хелп-деск, но единственная его работа в перераспределении поступивших заявок, их эскалация и минимальный контроль за ними, плюс решение мелких проблем - то Вы находитесь на тупиковой ветви развития. Все эти функции уже довольно давно умеют делать автоматизированные системы хелп-деск. Сами же специалисты хелп-деск должны владеть максимально возможным количеством технологий, которые внедрены в организации, и прав доступа для работы с ними. Желательно, чтобы на период организации службы поддержки пользователей, персонал туда был набран из числа уже работающих сотрудников.
Вполне естественно, что бонусы для таких позиций должны быть соответствующими.
Теперь поясню, допустим в вашей организации успешно внедрены и ежедневно используются 6-7 ключевых технологий, но абсолютно несхожих из разных областей. Пусть для примера это будут 1С - в нескольких конфигурациях, и с количеством разных баз от 25 до 50, корпоративный портал, развернутый на SharePoint со всеми рюшечками, которые были прикручены, несколько интернет-ресурсов, какая-нибудь ERP-система, а если не повезет то несколько, и это не беря в расчет базовых сервисов, локальной сети, домена\дерева доменов\леса ActiveDirectory, офисной техники, предоставления интернета, без которого никуда, тучи специфического софта, которым пользуется только два сотрудника, и который вы всем отделом устанавливали в течение недели, и то с костылями. Список сервисов можно составлять долго, а главное то, что специалист по поддержке пользователей должен обо всем этом знать, иметь представление. Довольно объемно. И одному человеку знать это все досконально не нужно, в рамках одной специальности.
Но поддержка пользователей это очень специальные люди, которые не всегда и во всем похожи на остальных. Дело в том, что все мы работает с железом, даже если нам иногда кажется, что у него есть душа. И это железо имеет одно очень нехорошее свойство - ломаться в самый неожиданный момент, а SLA таки да, - существует и от него не спрятаться не скрыться.
Конечно, у вас в компании есть много разных специалистов, каждый из них отвечает за какой-то свой сервис, работает с одной-двумя технологиями, но он. это специалист ни разу не железо, у него есть вполне себе такие осознаные потребности, нужности, интересы, ему нужно какое-то свободное время.
А разные поломки и косяки, только и ждут подходящего момента. и случаются, и вот тогда ведущий программист проекта, находясь у любимой бабушки на дне рождения диктует по телевону оператору поддержки пользователей свои учетки, расказывает куда тыкнуть, поправляет по телефону беду, и говорит себе, что как только окажется у компьютера, сразу подключится на работу и поменяет все пароли. И пусть даже так и будет, но на некоторое время, оператор имеет учетку ключевого сотрудника (замечу, что операторы обычно набираются из студентов, которым все по барабану, за то дешевые). И пусть даже ничего не случиться, но все же не красиво.
Придумать других ситуаций вагон не проблема, проблема уже озвучена - грамоная модель построения службы ИТ-поддержки.

Итак, мое виденье (фанфары)

1. составляем каталог услуг. смотрим и ужасаемся от числа ни за кем не закрепленных сервисов.
2. с боями составляем, согласованный с бизнесом, SLA.
3. создаем новую боевую еденицу из уже работающих сотрудников, желательно не junior, пусть даже от этого на определенное время пострадает бизнес. Важно, чобы они представляли разные отделы ИТ. Во время обкаточной работы они смогут создать начальную базу знаний, определят узкие места в работе службы.
4. в зависимости от предполагаемого количества специалистов поддержки пользователей, по желанию\жребию\на удачу назначаем руководителя вновь созданного подразделения, определяем обязанности.
5. Начинаем по одному выводить из работы по поддержке старых сотрудников и вводим в коллектив новых, сразу делая упор на комплексном обучении всем системам, в рамках администратора этих систем. Именно поэтому, на все позиции в поддержку пользователей, набираем не студентов, а системных администраторов со стажем, иначе не видать успеха. Настраиваемся на высокую цену таких специалистов и необходимость продалжительной работы по подбору.
6. Когда выучено достаточно технологий и так сказать получен некий кредит доверия - выделяем полноценные административные учетные данные необходимые для работы во всех системах. С одной стороны, это может показаться ударом по безопасности систем, ведь количество администрирующих возрастает. Здесь помогают административные меры и правило для поддержки - "работает не лезь!". Да им в принципе и так есть чем заняться:)

Вроде ничего сложного, но такая картина мира приходит только после продолжительного изучения работы уже существующих подразделений поддержки.

Все сказанное выше является сугубо моим личным мнением, применимым для компаний от средней до умеренно крупной, работающей с различными технологиями (ну т.е. для хостеров и провайдеров эти мои слова не представляют никакой роли, а только вред, их системы с "пожалуйста, подождите", "У вас вирусы, переустановите ОС", "мы все проверили у нас все нормально", "проблемы у сторонней организации" работают идеально, практически не дают сбоев и не поспоришь). Применено в организации с такими показателями - 70-100 заявок в день, 120-150 звонков, письменные обращения мимо всех и вся:), число сотрудников поддержки в смене - 2, процент закрытых заявок на первом уровне поддержки от 24 % до 36 % (месяц на месяц не приходится, смотря что сломается).

Ян Ван Бон - ИТ Сервис-менеджмент, введение

2010-11-29T08:14:00.002+02:00

Сегодня мне хотелось бы представить одну из немногих книг, которую можно назвать основами ITIL и ИТ сервис-менеджменту.

Вот что сказано в предисловии к русскому изданию данной книги:

Высказывая свое мнение об информационных технологиях, многие из руководителей компаний говорят, что это вынужденная необходимость. Не очень оптимистичное отношение. Удивительно? Но, это так.

Причин, по которым руководство остается недовольным качеством корпоративных информационных технологий (ИТ), много. Часть из них находится в области управления проектами внедрения ИТ. Далеко не всегда проекты завершаются в заданный срок и в рамках выделенных бюджетов. Но даже тогда, когда проекты заканчиваются, становятся актуальными ежедневные вопросы, связанные с использованием PIT, которые во многом формируют мнение о качестве работы ИТ:

- К кому обращаться?

- Сколько времени департамент ИТ будет обрабатывать мой вопрос?

- Планы требуют видоизменения корпоративных информационных систем. Когда это может быть сделано с условием сохранения текущей функциональности и непрерывности работы для обеспечения деятельности компании в настоящий момент?

- Куда уходят ресурсы, направляемые на сопровождение растущих информационных систем? Насколько эффективно они используются?

- Как организовать работу департамента ИТ в преддверии предстоящего роста компании? И так далее.

Решение вопросов через руководителей — далеко не самый эффективный путь. Необходимо налаживание горизонтальных связей, позволяющих построить взаимодействие сотрудников на всех уровнях. Книга, предлагаемая вашему, вниманию, представляет введение в ИТ Сервис-менеждмент, структурированный подход, позволяющий сделать работу департамента ИТ эффективной и рациональной. Этот подход стал стандартом де-факто в мире для формирования ИТ-службы как современного бизнес-подразделения, то есть департамента, постоянно ориентированного на потребности своих пользователей, нацеленного на решение изменяющихся задач при сохранении прозрачности для руководства с точки зрения достигнутого уровня качества и используемых ресурсов. Опыт показывает, что рассматриваемые принципы организации деятельности актуальны как для небольших, так и для крупных компаний и не зависят от того, передается ли сопровождение ИТ на аутсорсинг или организуется внутренними силами. Качественно работающий ИТ-департамент — это задача, ставшая актуальной для многих современных российских компаний.

Со своей стороны я выражаю благодарность представителям организаций, которые приняли активное участие в работе над книгой, являясь одними из первых в России, кто применил принципы ИТ Сервис-менеджмента в своей работе. Их участие выходило за рамки аудита, и они внесли значительный вклад в создание русской версии книги. Среди них департамент ИТ Сбербанка РФ в лице Хлызова А. Г., Левина А. В. и Аксенова В. Ю., дирекция ИТ компании «ВымпелКом» в лице Барино-ва И. И. и руководство ИТ компании «Чупа Чупс Рус» в лице Крачуна Н. В. Кроме того, я хочу выразить признательность моему коллеге по редакторской работе над книгой Григорьеву М. А., и Ле-винсону А. Б., возглавлявшему работу аудиторского коллектива.

Михаил Потоцкий

В книге подробно рассматриваются десять базовых процессов ITSM ITIL v.2

Процесс управления инцидентами
Процесс управления проблемами
Процесс управления конфигурациями
Процесс управления изменениями
Процесс управления релизами
Процесс управления уровнем услуг
Процесс управления мощностями (емкостью)
Процесс управления доступностью
Процесс управления непрерывностью
Процесс управления финансами

Скачать с Depositfiles (djvu, 6.82 mb)

Устанавливаем и конфигурируем Apache под Windows

2010-11-28T20:17:00.001+02:00

Зачастую для того чтобы развернуть новую систему мониторинга с web-интерфейсом, систему приема заявок, базу знаний или корпоративный портал, если об этом за нас не позаботились разработчики, нам приходится заниматься инсталяцией веб-сервера, конфигурировать его, прикручивать дополнительные модули и многое другое. В таком вопросе нужно разбираться досконально, чем мы сейчас собственно и займемся.

Итак, чтобы его установить, непременно придется раздобыть его - дистрибутив Apache брать стоит здесь, файл выбирайте на свой вкус.

собственно здесь производится небольшое конфигурирование - нам предлагается либо установить для всех пользователей, на 80 порт, и запускать в качестве службы (производственный вариант), либо только для одного пользователя на порт 8080, при ручном запуске (вариант для тестов и разработчиков). Выбираем то, что нужно Вам.

В остальном установка это исключительно выбор дефолтных настроек.

По окончанию установки и запуска Apache в системном трее мы с увидим перышко (ApacheMonitor).

Другим вариантом установки может являться распаковка архива и конфигурирование вручную.

- Сначала нужно скачать и установить Visual C++ 2008 Redistributable Package.

- Затем стоит разархивировать архив куда-нибудь, лично я его пестил в c:/apache2
После этого изкомандной строки необходимо запустить файл

>httpd.exe (c:/apache2/bin)

>httpd.exe -k install (установить в качестве службы)

После этого можно запустить ApacheMonitor.exe (c:/apache2/bin)

Если все прошло без ошибок, можно смело приступать к конфигурированию. Ошибки могут быть в том случае, если Вы разархивируете в каталог не с именем Apache2 и не в корень системного диска. Тогда для запуска придется поменять часть параметров в файле conf/httpd.conf.

Идем конфигурировать!!! В не зависимости от того, как Вы устанавливали сервер, конфигурировать его лучше через основной файл конфигурации ( c o n f / h t t p d . c o n f ). Вот с его-то содержимым нам и придется столкнуться вплотную.

Параметры конфигурационного файла Apache

ServerRoot "C:/Server/Apache/Apache2"- каталог с файлами сервера (не путать с "DocumentRoot")

Listen 80 - слушаем и работаем на 80 порту, при желании можете настроить любой, только не забудьте об этом рассказать всем посетителям вашего хоста..

ServerName localhost:80 - Имя сервера (на работу это не влияет).

ServerAdmin your@email.name - Администратор сервера. Содержит ваш адрес электронной почты, который будет отображаться при некоторых ошибках сервера. Как заполнять регшите сами.

DocumentRoot "C:/Sites/home/localhost/www" - DocumentRoot - место где будут располагаться ваши сайты. По умолчанию Apache устанавливает "DocumentRoot" - "%ServerRoot%/htdocs" (т. е. если вы установили Apache в папку "C:\Apache2", то "DocumentRoot" будет выглядеть так: "C:/Apache2/htdocs"). Вы должны изменить значение "DocumentRoot" на "C:/Sites/home/localhost/www".

Найдите и закомментируйте блок "<Directory "C:/Apache2/htdocs">",заменив его на следующий:

<Directory "C:/Sites">
Options Indexes Includes
AllowOverride All
Order allow,deny
Allow from all
</Directory>

Этими директивами вы разрешите просмотр содержимого каталога в браузере при отсутствии индексных файлов, включите поддержку SSI, разрешите использовать файлы .htaccess для настройки каталогов и разрешите доступ для всех к сайту.

DirectoryIndex index.php index.html index.html.var (добавьте те имена фалов, которые используете Вы) - управляющий элемент модуля mod_dir, включает перенаправление на указанный файл, при обращении не к файлу а к каталогу, содержащему этот файл (обращение пользователя - http://mysite.mu/ переадресуется на файл http://mysite.mu/index.php или другой, из указанных Вами в конфигурации)

ScriptAlias /cgi/ "C:/Sites/home/localhost/cgi/"
ScriptAlias /cgi-bin/ "C:/Sites/home/localhost/cgi/" - Задание псевдонима для каталога с cgi-скриптам.

LoadModule php5_module "C:/PHP/php5apache2_2.dll"

PHPIniDir "C:/PHP" - объясняем Apache откуда и как грузить интерпретатор PHP.

AddHandler cgi-script .cgi .bat .exe - Объясняем Apache, что файлы с расширением "cgi", "bat", "exe" нужно воспринимать как cgi-скрипты.

Блок "<Directory "C:/Apache2/cgi-bin">" заменяем на: <Directory "C:/Sites/home/localhost/cgi">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>

AddType application/x-httpd-php php phtml
ScriptAlias /_php_/ "C:/PHP/"
Action application/x-httpd-php "/_php_/php.exe" - подключаем PHP, указываем тот каталог в котором у Вас находится PHP.

AddType text/html .shtml
AddHandler server-parsed .shtml .html .htm - включение SSI

LoadModule rewrite_module modules/mod_rewrite.so - раскомментируем данную строчку и подключаем модуль mod_rewrite.

Виртуальные хосты

Итак, Вы создали каталог "localhost" для хранения и тестирования сайта. Но редко случается, что сайт только один. Можно, конечно, создать каталоги для других сайтов внутри "localhost" и обращаться к ним "http://localhost/site", но это как-то не по фен-шую. Тем более, что Apache дает возможность решить эту проблему с помощью виртуальных хостов. Есть два вида виртуальных хостов: отдельные для каждого IP адреса и использующие один IP (name-based хосты). Настроим последние, как наиболее веорятные для данной местности.
В каталоге "home" создадим директорию "mysite" . Это и будет рутом(корнем) ваших виртуальных хостов. В них должны быть папки "www" и "cgi", файлы access.log и error.log. Т. е. все так же как и с каталогом "localhost". Все ваши виртуальные хосты будут использовать IP "127.0.0.1".

Добавьте в файл "httpd.conf" следующее:
NameVirtualHost 127.0.0.1
#localhost
<VirtualHost localhost>
ServerAdmin me@localhost
ServerName localhost
DocumentRoot "C:/Sites/home/localhost/www"
ScriptAlias /cgi/ "C:/Sites/home/localhost/cgi/"
ErrorLog C:/Sites/home/localhost/error.log
CustomLog C:/Sites/home/localhost/access.log common
</VirtualHost>
#mysite
<VirtualHost mysite>
ServerAdmin me@mysite
ServerName mysite
DocumentRoot "C:/Sites/home/mysite/www"
ScriptAlias /cgi/ "C:/Sites/home/mysite/cgi/"
ErrorLog C:/Sites/home/mysite/error.log
CustomLog C:/Sites/home/mysite/access.log common
</VirtualHost>

Можно добавить в блоки "<VirtualHost>" и другие параметры, однако лучше управлять виртуальными хостами с помощью .htaccess. Также стоит отметить, что все параметры, не указанные в блоках "<VirtualHost>" или в .htaccess, наследуются от главного хоста (т. е. от "localhost").

Вот мы и настроили Apache для работы с виртуальными хостами.
Теперь определимся с тем, как Windows узнает о существовании виртуальных хостов? Для этого придется отредактировать файл "hosts" , хранящийся в каталоге "%WINDOWS%\System32\drivers\etc"
В него нужно будет дописать:
127.0.0.1 mysite

при добавлении любого нового сайта, виртуальный хост добавляется точно так же.

Теперь осталось перезапустить Apache,сделать это можно через ApacheMonitor, ну и собственно теперь стоит накатывать и настраивать сови сайты.

Терминология ITIL - 3

2010-11-24T21:18:00.000+02:00

Продолжим разбираться с терминологией ITIL, дополненной моими небольшими комментариями и замечаниями, сделанными на основе практического опыта внедрения.

Бюджет - Перечень денежных средств, которые организация или бизнес-единица планирует получить или потратить в течение определенного периода времени.

Бюджетирование - Деятельность по прогнозированию и последующему контролю расходов денежных средств. Состоит из периодического (обычно ежегодного) составления Бюджетов будущих периодов и ежедневного мониторинга, уточнения Бюджета текущего периода.

Бизнес - Общекорпоративное образование или Организация, сформированные из некоторого количества Бизнес-единиц. В контексте ITSM термин Бизнес распространяется как на некоммерческие организации и государственный сектор экономики, так и на коммерческие компании. Бизнес является основным потребителем услуг подразделения ИТ. Специалисты ИТ, на всех уровнях, должны понимать, что основным в деятельности организации является бизнес и его потребности.

Бизнес-кейс - Обоснование какой-либо значительной статьи расходов. Включает информацию о затратах, выгоде, вариантах реализации, сложностях, рисках и возможных проблемах. Бизнес-кейс является одним из ключевых моментов в управлении финансами. Причем, заострять внимание стоит на выгодах, рисках и возможных сложностях, эти моменты наиболее интересны бизнесу, нужно понимать, что бизнес общается именно на этих терминах, они ему близки и понятны. Поэтому составлению бизнес-кейсов стоит уделять довольно много времени - именно они останутся в памяти бизнес-руководителей и топ-менеджеров.

Бизнес-процесс - Процесс, владение и управление которым выполняется Бизнесом. Бизнес-процесс способствует предоставлению продукта или Услуги для Бизнес-заказчика.
Например, предприятие розничной торговли может иметь Процесс закупок, который помогает предоставлять Услугу его Бизнес-заказчику. Многие Бизнес-процессы зависят от ИТ-услуг.

Бизнес-услуга - ИТ-услуга, которая напрямую поддерживает Бизнес-процесс, в противоположность Инфраструктурной услуге,
которая используется внутри Поставщика ИТ-услуг и обычно не
является очевидной для Бизнеса.Термин Бизнес-услуга также используется для обозначения Услуги, которая предоставляется
Бизнес-заказчикам от Бизнес-единиц. Например, предоставление финансовых услуг Заказчикам банка или товаров Заказчикам розничного магазина. Успешное предоставление Бизнес-услуги
часто зависит от одной или более ИТ-услуг.

Бизнес-единица - Сегмент Бизнеса, который имеет свои собственные планы, метрики, доход и затраты. Каждая бизнес-
единица владеет активами и использует их для создания ценности для заказчиков в форме товаров и услуг.

Терминология ITIL - 2

2010-11-19T12:33:00.000+02:00

Продолжим знакомиться с терминологией ITIL.

Актив - Любые ресурс или способность. Активы поставщика услуг включают в себя все, что задействовано в предоставлении услуг. Активы могут быть отнесены к одному из следующих типов: управление, организация, процесс, знания, люди, информация, приложения, инфраструктура и финансовый капитал.

Архитектура -Структура Системы или ИТ-услуги, включающая Взаимоотношения между компонентами и средой, в которой они находятся. Архитектура также включает стандарты и руководящие документы, которые определяют проектирование и развитие информационной системы.

Атрибут - Определенная часть информации о Конфигурационной единице(КЕ). Например, имя, местоположение, номер версии и затраты. Атрибуты КЕ записываются в Базу данных управления конфигурациями (CMDB).

Аудит - Формальное обследование и проверка на предмет соблюдения какого-либо стандарта или набора руководящих документов, или точности ведения записей, или уровня достижения целевых значений по эффективности и результативности. Аудит может проводиться внутренними или внешними службами.

Базовое состояние - Зафиксированное состояние, используемое как ориентир (контрольная точка).

Доступность - Способность Конфигурационной единицы или ИТ-услуги выполнять согласованную Функцию, когда это требуется. Доступность определяется через Надежность, Сопровождаемость, Обслуживамость, Производительность и Безопасность. Доступность обычно измеряется в процентах. Это измерение часто базируется на Согласованном времени предоставления услуги и дростое. Лучшей практикой является вычисление доступности через измерение результатов ИТ-услуги, значимых для Бизнеса.

Зафиксированное состояние - Состояние чего-либо, зафиксированное на определенный момент времени. Зафиксированное состояние может быть создано для Конфигурацимм, Процесса или любого другого набора данных. Например, зафиксированное состояние может быть использовано в следующих случаях:

- Постоянное улучшение услуг, для фиксации текущего состояния и управления улучшениями.
- Управление мощностями, для документирования значений параметров Производительности, характеризующих нормальный режим эксплуатации.

Резервное копирование - Копирование данных с целью их защиты от нарушения целостности или доступности оригинала.

Управление доступностью - Процесс, отвечающий за определение, анализ, планирование, измерение и улучшение всех аспектов доступности ИТ-услуги. Управление доступностью отвечает за то, чтобы вся ИТ-инфраструктура, процессы, средства, роли и т.д. соответствовали согласованным целевым показателям уровня услуги в части доступности.

Терминология ITIL - 1

2010-11-18T10:02:00.000+02:00

В этой небольшой статье, я попробую представить основные термины, которые были введены нами в ходе планирования и внедрения системы управления ИТ. Материал объемный, поэтому выкладывать буду по-немногу в несколько постов, где считаю нужным будут мои комментарии, по наиболее важным пунктам или узким местам.

Активный мониторинг - Мониторинг Конфигурационных единиц или ИТ-Услуг, использующий автоматизированные регулярные проверки для отслеживания текущего статуса объектов мониторинга.

Деятельность - Набор действий, спроектированный с целью получения определенного результата. Деятельности обычно определяются как части Процессов или Планов, и документируются в Процедурах.

Оценка требований приложений - Деятельность, отвечающая за понимание требований к ресурсам, необходимым для поддержки нового приложения, или значимого изменения в существующем приложении. Оценка требований приложений помогает гарантировать соответствие ИТ-услуги установленным показателям уровня услуг в части мощности и производительности. Один из ключевых моментов в процессах управления конфигурациями, изменениями и релизами.

Предупреждение - Предупреждение о том, что было достигнуто пороговое значение, что-то изменилось или произошел Сбой. Основной сферой применения стали процессы Управления инциндентами и управления проблемами на этапе эскалации до уровня директора по ИТ и руководства предприятия.

Приложение - Программное обеспечение, предоставляющее функции, необходимые для ИТ Услуги. Каждое приложение может быть частью более чем одной ИТ-Услуги. Приложение может иметь одну или более серверных или клиентских частей. Здесь очень важно понять, что приложение - это только то, что действительно необходимо бизнесу, а не любое программное обеспечение, использующееся в компании.

Портфель приложений - Часть процесса управления конфигурациями, представляющий собой базу данных или структурированный документ, используемый для управления Приложениями в течение всего их жизненного цикла. Портфель приложений удобно использовать в части стратегического управления ИТ.

Соглашение - Документ, который описывает и формализует отношения между двумя или более сторонами. Соглашение не определяет юридических обязательств сторон, за исключением случаев, когда оно является частью договора. Является одним из ключевых понятий ITIL.

Уполномоченный - Официально наделенный полномочиями исполнять какую-либо Роль. Например, у нас уполномоченными являются менеджеры процесса, т.к. процессы структура логическая, и штатной должности не предполагает. Уполномоченный официально наделен правами Директора по ИТ в части, касающейся его процесса.

Учёт затрат - Процесс,отвечающий за идентификацию фактических Затрат на предоставление ИТ-Услуги, их сопоставление с плановыми Затратами, и управление отклонениями от Бюджета.

Хватит работать сверхурочно, пора работать рационально!

2010-11-15T23:23:00.000+02:00

Предлагаю вашему вниманию занимательную книгу по личному тайм-менеджменту - Т. Лимончелли. Тайм-менеджмент для системных администраторов. Данная книга подойдет в первую очередь системным администраторам небольших компаний и работникам служб технической поддержки высокого уровня поддержки, описываемые в ней методики довольно просты в применении. Основной упор в ней делается на создание своих собственных "процедур" во всех областях жизни и исполнение их на автомате, дробление задач на подзадачи, распределение труда в коллективе. В принципе, довольно интересный материал и читается довольно легко.

А вот и аннотация к книге:

По тайм-менеджменту изданы сотни книг, но только эта написана сисадмином для сисадминов. Автор учитывает специфику их труда: работая над долгосрочными проектами, сисадмины вынуждены постоянно прерываться, чтобы наладить технику, помочь пользователям. И даже овладев всеми тонкостями профессий, сисадмин задерживается по вечерам и работает по выходным.

Основное внимание уделяется приемам, которые помогут сисадминам не только вести повседневные дела, но и справляться с неизбежными критическими ситуациями. Вы научитесь управлять отвлекающими факторами, исключать непроизводительные затраты времени, вести список дел, разрабатывать процедуры для регулярно совершаемых действий, сосредотачиваться на текущей задаче, расставлять приоритеты в соответствии с ожиданиями клиентов, документировать и автоматизировать рабочие процессы для ускорения их выполнения.

Издание насыщено примерами, взятыми автором из его долгой карьеры, на протяжении которой он занимался обслуживанием рабочих станций и серверов, а также разработкой ПО и систем безопасности. А это значит, что читатель получит советы бывалого человека. Томас давно занимается проблемой тайм-менеджмента, ведет обучающие семинары. Приемы, которыми он делится с коллегами, проверены на практике. Они работают!

скачать с depositfiles.com

Утро нового дня

2010-11-15T22:57:00.000+02:00

У каждого из нас есть свои особые периоды максимальной умственной и физической активности, ясности и тонкости мыслей, проявления креатива - вот только обычно тратим мы их не совсем рационально. Для меня, время такого подъема - утро. Два года назад заметил за собой привычку - начинать рабочий день с разгребания почтового ящика, беглого просмотра мировых новостей, ЖЖ, ithappens, bash.org.ru, anekdot.ru, тематических блогов и новостей, за которыми слежу. В итоге пол-дня гарантированно уходило исключительно на это все, с небольшими прерываниями на выполнение прямых обязанностей. А вся соль в том, что это было в порядке вещей у всего отдела, где я тогда работал, с самого утра все втыкали в свои собственные клоаки информационного мусора, бесполезная затуманивающая ум муть лилась отовсюду. Естественно, этой же мутью мы активно обменивались по почте, через icq и jabber. Не могу сказать, что работа выполнялась плохо, или не выполнялась вообще. Нет все работало, но не было одного очень важного момента - развития. Вот оно-то и буксовало.

Честно признаться, после все того информационного мусора, обрушивавшегося на наши бедные головы не о какой ясности мысли и речи быть не могло, ну а какое тут развитие без трезвых мыслей? Правильно. Только деградация. Бороться с этой заразой начал с себя - запретил себе открывать браузер без должной необходимости, определил ресурсы на которые можно заходить, по каким вопросам и на какое время, не запускал почтовый клиент до того момента, пока не окончил все дела, которые запланировал на этот день.Не могу сказать, что работа пошла как по маслу, поперли новые гениальные идеи и воцарилось гармония, но небольшой результат был, особенно учитывая, что время от времени, свои правила я нарушал, да и сформулированными до конца они не были, поэтому и правилами в привычном понимании слова не являлись. Но путь был выбран, в принципе, верный. Работа над собой дала плоды - вот перечень правил, сформулированных мной, за последние два года и активно применяющиеся последние полгода.

Вот мои "НЕ" для работы

- Не просматривать почту до 12.00, и вообще просматривать ее только три раза в день в 12.00, 15.00, 18.00. Если что-то реально срочное - позвонят, и тут в любом случае или просмотришь важное сообщение, или введут в курс дела так.

- Не прерывать никаких дел, до момента их выполнения или некой контрольной точки, чтобы ответить на новое письмо или сообщение. На телефон тоже стараюсь не отвечать, а перезванивать позже.

- Не просматривать развлекательные ресурсы и форумы, куда интереснее выполнить всю работу за день, не брать ее домой, не оставаться после работы, а уделить это время семье или хобби.

- Не отвлекаться на внешние раздражители, не связанные с работой. В последнее время все чаще можно читать о трудности вхождении в "поток", и сотнях прерываний, которые нас отвлекают. Для меня "поток" существует.

- Не читаю тематические форумы, которые убивают массу времени, любую нужную информацию можно взять из первоисточника. Первоисточник - залог верной информации, и системному администратору и ит-менеджеру в первую очередь нужно читать первоисточники и документацию. Как говорили в моей армейской молодости - "Учи матчасть!".

Всего пять пунктов, а утро стало приносить радость, ведь раньше прочитав море ненужной информации голова становилась чужой, и все плодотворные идеи, которые родились за ночь и утро, умирали под обломками бесполезного ментального мусора.

Предоставление услуг (Service Delivery)

2010-11-15T00:29:00.000+02:00

Вполне естественно, что перед тем как поддерживать услуги их нужно внедрить, но это естественно только в случае когда Вы начинаете разворачивать инфраструктуру с нулю, в случае если же услуги и сервисы уже кое-как внедрены, а Вам нужно внедрять ITIL поверх уже существующей инфраструктуры (как, к слову, и бывает в большинстве случае), в таком случае вы в первую очередь внедрите поддержку существующих услуг, а уже затем начнете внедрять предоставление услуг. Чем собственно, по такому сценарию я и занялся после внедрения поддержки.

Для начала опишу, какие определения получили процессы этого раздела у нас.

- Процесс управления уровнем услуг - процесс улучшения качества предоставляемых пользователям сервисов, осуществляемый через всесторонний мониторинг, анализ инцидентов и проблем, уровень доступности сервисов и непосредственный анонимный опрос пользователей сервисов. Сутью этого процесса для нас стали аналитические действия каждого сотрудника ИТ, направленный на улучшение сервисов, за которые непосредственно ответственен исполнитель. Все этапы жизни этого процесса были сведены в единую точку входа-выхода, в том числе и анкетирование пользователей. Как показала практика из всех опрошенных пользователей около 10 % могут дать рекомендации, до которых мы сами бы не дошли. И проблема в основном в разной картине мира. Пользователь видит сервис совсем по-другому, нежели технический специалист. В то время когда ИТ ориентируется в основном на функциональность, мощность, гибкость, масштабируемость, пользователь интересуется простотой, доступностью, совместимостью. И вот здесь возникает вопрос : таки ИТ для бизнеса, или бизнес для ИТ? Как показывает практика, большинство сотрудников ИТ даже не мыслят в направлении бизнеса, их интересуют только технические вопросы. И после этого мы хотим понимания?

Непосредственными составляющими этого процесса являются - Каталог услуг и Соглашение об уровне услуг(SLA). Составление этих ключевых документов является довольно трудоемким процессом, особенно в компании, где число сервисов больше 30. ITIL так же рекомендует составить Требование к уровню услуг, но мы по своей лени и для удобства объединяем все это в одном документе - SLA. Так же, как внутренний документ службы, разработана Программа улучшения сервиса. Но об этом все позже в отдельных статьях.
- Процесс управления финансами - мероприятия направленные на рентабельное распоряжение финансовыми ресурсами службы информационных технологий, управление активами, проведение всестороннего анализа финансовой деятельности, установление постоянных взаимоотношений с контрагентами. В принципе, этот процесс был уже налажен и его оставалось только перенести на новую платформу.
- Процесс управления мощностью - процесс направленный на постоянное поддержание необходимого уровня услуг, посредством контроля и планирования мощностей, масштабируемость приложений, определение требующихся мощностей, востановление ключевых сервисов после сбоев. Процесс был полностью включен в CMDB, в него же и вошла база данных мощностей. Основными видами деятельности на поле управления мощностями стали проектирование, согласование и оптимизацию мощностей. Управление востановление систем после сбоя было выведено в отдельный процесс. На практике, этот процесс оказался практически клоном процесса управления конфигурациями, с отличием в том, что он в основном направлен на планирование и согласование. В общем больших трудностей он так же не вызвал, учитывая, что в начальной стадии он уже функционировал и оставалось только закрепить его на программной платформе и начать пользоваться.
- Процесс управления непрерывностью - процесс направленный на непрерывность предоставления услуг пользователям информационных систем и выполнение соглашения об уровне услуг. Наиболее сложный в практическом плане процесс. Выполнение SLA вообще непростая вещь. Этот процесс мы объеденили с Процессом управления доступностью, т.к. существенной разницы для нашей компании не увидели.

Вот примерно так, выглядит наша модель Предоставления услуг

techsupport зачем и как?

2010-11-13T20:04:00.000+02:00

Любой специалист, работающий в области информационных технологий скажет, что работа с пользователями, самая проблемная и сложная, в моральном плане. Поэтому любой высококвалифицированный специалист по мере роста своего проекта\компании пытается избавиться от этих обязанностей и переложить их на менее квалифицированного специалиста. Сначала это становиться просто перераспределением функций внутри отдела, затем вычленение одного человека, который станет единой точкой обращения для пользователей. С этого момента можно считать, что поддержка пользователей организована. Можно уже считать этого человека отдельным подразделением. Изо дня в день он отвечает на вопросы пользователей, по мере развития обрастает определенными инструментами (тут уж как повезет). А дальше, начинаются чудеса. И проявляются они в том, что дальше никакого развития нет, все, потолок, увеличивается количество сотрудников, занимающихся поддержкой услуг, а не их качество и техническое оснащение.

Одним из первейших шагов вперед в направлении поддержки пользователей, который может сделать руководитель ит-подразделения - максимально технически обеспечить свою службу поддержки пользователей. Но со временем это перестает приносить ощутимые результаты, и снова выбор становиться либо на увеличении количества сотрудников, занимающихся проблемами пользователей, обработкой телефонных звонков, решением рутинных проблем, либо в изменении качественного состава службы поддержки. По опыту, перевод пары сильных программистов или администраторов проекта в сектор поддержки пользователей, с сокращением числа обычных операторов, приносит почти мгновенные положительные результаты. Квалифицированный специалист, привыкший постоянно отвечать за какую-то часть проекта, перейдя (по своему желанию) в сектор поддержки пользователей, чувствует себя куда более раскрепощенным и забирает на себя большую часть тех проблем, которые бы обычный оператор перевел бы на более высокий уровень поддержки, отвлекая тем самым более квалифицировнного специалиста.

Квалификация специалистов технической поддержки - краеугольный камень всех ит-подразделений, в одних считают нормой студента, без практического опыта работы с информационными системами, своими интересами и откровенным пофигизмом, в других, нанимают высококвалифицированных специалистов, или переводят своих сотрудников, которые в дальнейшем к рутинным вопросам работы ИТ относятся халатно, потому как нет подушки из низкоквалифицированных специалистов. Как итог - практикиа когда поддержка пользователей - щит проекта от этих самых пользователей . Проект и вся служба получают низкие оценки своей работы от пользователей и как итог от своих руководителей. Думаю дальше все довольно предсказуемо.

Так что обязанность любого грамотного руководителя найти ту золотую середину, между количество простых специалистов и квалифицированных, разделить их работу, мотивировать квалифицированного специалиста.

Дальнейший этап становиться самым сложным, подразделение разрастается до таких размеров, когда полноценно контролировать его работу и работу с проблемами подразделения в частности становиться крайне затруднительно. Вот здесь и приходит на помощь ITIL в лице ITSM. ITSM , ка кподмножжество ITIL имеет прямое отношение к поддержке и предоставлению услуг и может направить в вопросах дальнейшего построения инфрастуктуры.

После того как ITSM , внедрен остается один небольшой шаг до ITIL, и он проходится уже не так болезненно, потому как бизнес-процессы компании уже впору созрели, есть понимание направления движения компании, ее идеология и костяк.

Внедрение ITIL не является каким-то чудестным способом избавиться от всех проблем мироздания, но вот обмерять и проанилизировать работу ИТ позволяет, так же как измерять работу и каждого члена этого подразделения, так же это предоставляет гибкие и формализованные инструменты всему ИТ-подразделению.

программные продукты для управления IT-инфраструктурой

2010-11-13T18:38:00.000+02:00

Количество продуктов, предлагаемых для использования в области управления в информационных технологий, на первый взгляд кажется ущербным, на второй громадным, на третий и четвертый ты либо приходишь к выводу что нужно создавать что-то свое, или выбираешь конкретный продукт, просто так, потому как существенных отличий в их функциональности просто нет. Все вышесказанное относится только к категории програмных продуктов, определенных моими трабованиями, а именно наличием пользовательского веб-интерфейса.

Итак, на данный момент на рынке представлено множество продуктов, с заложенной в них поддержкой ITIL. Среди них, для себя, после прочтения большого количества материала по ним я выделил несколько.

1. Manageengine ServiceDesk Plus - комлексное решение для управления информационными технологиями, поддерживает ITIL, довольно удобен в использовании, обладает богатыеми возможностями по настройке, разграничению доступа и особенно сбору статистической информации в автоматическом режиме. Многие процессы автоматизированы, или позволяют их автоматизировать. Поддерживает импорт пользователей из ActiveDirectory и их прозрачную авторизацию.

Из недостатков выделю прожорливость до ресурсов сервера, использующего Java, Нет возможности вставить скриншот в форму заявки из буфера обмена, его необходимо прикреплять через вложение файла.

Пробную версию можно скачать с сайта производителя.

2. SysAid - очень комфортное в работа решение, менее функционально в сравнении с Manageengine, зато отлично кастомизировано, есть версия Free - поддерживает работу до 100 пользователей и 2 администраторов, не умеет практически ничего из ITIL, зато дальше есть простор где развернуться - коммерческие версии могут быть сконфигурированы практически как угодно, множество дополнительных подключаемых модулей (естественно, за дополнительную плату). В работе, немного раздражает не совсем корректный русский перевод, и невозможность использовать разные языки для админстраторской части и пользовательской (а может я не нашел). Довольно запутанное меню, требующее привыкания, но затем все просто.

3. GLPI - достойная внимания вещь, для небольшого отдела информационных технологий в самый раз, есть русский интерфейс, интеграция с AD, OCS Inventory. Работал с этой системой мало, т.к. уже был выбран продукт, но в принципе довольно интересная вещица.

По большому счете здесь можно перечислить еще два десятка похожих продуктов, все они будут чем-либо отличаться, иметь одно преимущество над другим, но уступать третьему в чем-то еще.

Так что в выборе программного обеспечения для вашего подразделения информационных технологий, в выборе я бы рекомендовал руководствоваться соображениями удобства для пользователей, поддержки и цены продукта. ФУнкциональность же у всех примерно одинаковая.

От себя добавлю что мы выбрали открытый программный продукт, и ниразу об этом не пожалели, хотя изначального его даже не рассматривали.

Десять заповедей techsupport

2010-11-13T16:46:00.000+02:00

Саппорт - лицо компании для пользователя.

Лицо должно быть красивым, улыбающимся и приветливым.

Пользователь - живой человек.
Отвечая на письмо пользователя, подумай: а устроил бы такой ответ тебя? Не забывай, что с другой стороны монитора живой человек и общаться с ним нужно как с живым человеком.

Любое письмо - вопрос.
Если пользователь написал, значит у него проблема, и он хочет получить ответ именно на поставленный вопрос, а не отписку, не имеющую отношения к его проблеме. Всегда отвечай на вопрос пользователя.

Читай переписку.
Тебе понравится, когда одно и то же спрашивают по несколько раз? Обязательно читай переписку полностью.

Сокращай итерации.
Если пользователь предоставил недостаточно данных, лучше попросить его прислать всё необходимое (или даже больше) в одном письме, а не задавать по одному наводящему вопросу.

Одно предложение - не ответ.
Ответ обязан содержать помимо ответа на вопрос пользователя еще и объяснение причин возникновения проблемы. Ответ в одно предложение - отписка.

Непонятного - боятся.
Письмо в поддержку - крик о помощи. У пользователя что-то пошло не так. Он не понимает в чем дело. Ответ должен успокоить его, а не вогнать в еще большую панику. Саппортер - всегда немного психолог.

Не задерживай ответ.
Если решение проблемы затягивается, не молчи: скажи пользователю об этом. Не бойся признать наличие проблемы, скажи, что ее решают, назови примерные сроки. Если сроки пока никто не знает, пообещай связаться сразу же, как только получишь ответ - и сделай это! Пусть пользователь знает, что о нем не забыли.

Ты - не робот.
Не старайся отгородиться от пользователя формализмом и канцелярщиной сухих фраз. С живым человеком ему наладить диалог намного проще. Не бери пример с госучреждений.

Не бойся спрашивать.
Если не знаешь, что ответить пользователю - спроси у коллег. Лучше узнать точно, чем показать свою некомпетентность в вопросе пользователю. Не поленись проверить ответ перед отправкой.

Поддержка услуг (Service Support)

2010-11-13T15:59:00.000+02:00

Как известно каждому, кто думает о внедрении ITIL в своей организации, первейшей задачей, в случае внедрения на уже работающую инфраструктуру, будет внедрение всеобъемлющей поддержки услуг.

В моем случае, инфраструктура без видимых изменений действовала уже несколько лет, бизнес-процессы компании были сформированы и работали хорошо. Служба ИТ практически без превлечения сторонних организаций занималась к администрирование и поддержкой работы инфраструктуры, так и разработкой и сопровождением проектов.

Подразделение helpdesk занималось обработкой заявок пользователей, велась единая база этих заявок, эскалация производилась на один уровень до прямого исполнителя в случае с серьезными проблемами в программном коде или аппаратном обеспечении.

Использоватлась своя разработка на основе Lotus Notes.

Первым шагом во внедрении ITIL стала разработка нормативной базы именно для службы поддержки пользователей, которая бы соответствовала стандартам.

В это документацию мы включили

- Соглашение о уровне услуг (SLA)

- Каталог услуг

- Инструкция по эскалации

к тому моменту уже существовала внутренняя база знаний, матрица приоритетов, правила закрытия заявок, но все они нуждались в переработке.

Как итог - перерабатывать пришлось абсолютно всю документацию.

Не менее важным моментом стало то, что было принято отказаться от работы с имеющейся программной платформой. Во многом на это повлияла сложность разработки адекватного требования программного обеспечения. Был начат поиск подходящих вариантов, для использования в качестве единой базовой основы работы IT.

Сейчас же мне хотелось бы разобраться с самим понятием поддержки услуг. Как уже было сказано, поддержка услуг включает в себя

Процесс управления инцидентами (Incident Management)
Процесс управления проблемами (Problem Management)
Процесс управления конфигурациями (Configuration Management)
Процесс управления изменениями (Change Management)
Процесс управления релизами (Release Management)

Все эти процессы было решено объеденить в едином службе Service Desk, построеной на основе существовавшего Helpdesk.

Было определено, что под процессом управления инциндентами понимается следующее - базовая функция службы поддержки пользователей и всего ИТ подразделения, направленая на принятие заявок о инциндентах, сервис-запрос, и заявок на консультацию от пользователей ИТ-сервисов, их разрешение, анализа и закрытия. Реализована система приоритетов, на основе срочности и влияния на бизнес. В ходе анализа, инциндент любым из сотрудников ИТ, по его решению, может быть переведен в статус проблемы и перенесен в процесс управленимя проблемами. Контроль за процессом возложен на службу servicedesk. Определены правила эскалации инциндентов. На основе инциндентов ведется база знаний, с разделенным доступом, для пользователей и технических специалистов.

Процесс управления проблемами определяется как базовый внутренний сервис службы информационных технологий, определяющий проблемы в инфраструктуре, и требующий разрешения данных проблем в соответствии с регламентом закрытия проблем. Под проблемой понимается нарушение функционирования сервиса, предоставляемого службой конечным пользователям и повлекший за собой нарушение SLA, и проявившийся более 2 раз за установленный период. Контроль за проблемами осуществляется службой servicedesk и руководителями структурных подразделений службы, в том числе и руководителем службы напрямую. Целью процесса является минимизация проявления инциндентов ит-инфраструктуры, их влияния на сервисы.

Процесс управления конфигурациями является внутренним сервисом службы информационных технологий, направленный на всесторонний контроль сервисов предоставляемых пользователям, и реализован посредствам всестороннего мониторинга сервисов, перечисленных в Каталоге услуг. Так как каталог услуг включает все сервисы, которые мы предоставляем пользователям, нам по сути пришлось мониторить все - от аппаратного обеспечения рабочих станций и серверов, до пользовательских приложений. Любая пользовательская заявка автоматически привязвается к рабочей станции пользователя, ведется статистика заявок по пользователям и рабочим станциям. Контроль осуществляется силами службы servicedesk, и отдельных специалистов в пределах своей компетенции.

Процес управления изменениями - внутренний сервис службы информационных технологий направленный на стандартизацию внесения изменений в инфраструктуру, сбор и анализ статистической информации по изменениям, минимизацию рисков, связанных с внесением изменений в инфраструктуру предприятия. Реализован стандартизированной процедурой анализа требований, принятия решения, тестировнаия, закупки и ввода в эксплуатацию аппаратных и программных продутов, вопросов их сопровождения сторонними организациями, обновлений и масштабирования. Контроль осуществляется силами службы servicedesk и руководителя

Процесс управления релизами - внутренний сервис службы информационных технологий, направленный на примение многих изменений одновременно, стандартизацию используемого ПО и аппаратного обеспечения, выработку механизмов устранения различий версиях. Контроль осуществляется силами службы servicedesk, руководителя службы ИТ.

В контенсте поддержки услуг, при постановке задачи были приняты некоторые ключенвые для выбора ПО решения:

- ПО должно иметь веб-интерфейс и не требовать установки отдельного клиента. Это решение было обусловлено в первую очередь большим числом пользователей, работавших на тонких клиентах, и наличием филиалов, удаленных от центрального офиса.

- интерфейс пользовательской части должен иметь русский язык, быть минималистичным и настраиваемым, иметь возможность публикации новостей непосредственно в нем.

- иметь Базу знаний, как часть пользовательского интерфейса.

- иметь строгое разделение и широкие возможности в назначении прав доступа пользователей. Для обеспечения работы специалистов разного уровня доступа и различных функций.

- соответствовать стандартам ITIL v.2 / ITIL v.3 (в ходе анализа документов, стало понятно не очень существенное их различие, а лишь перегрупировки и углубление)

- Масштабироваться.

брутальный ITIL

2010-11-13T12:05:00.000+02:00

Не стану вдаваться в описание всех красивостей и полезностей ITIL для среднестатистической службы IT, отдельно взятого it-директора или простого сисадмина, не буду вставлять и большие копипасты с wikipedia и прочих крайне популярных ресурсов, хотя без этого тоже не обойдется. А попытаюсь рассказать о практике внедрения iTIL в отдельно взятой компании, которая по мере своего роста пришла к нему. Так же напомню, всем джедаям, которые особо увлекаются чтением стандартов, но не практикой внедрения, что таких компаний большинство и опыт внедрения ITIL в компании в 20.000 человек, пригодится только 1%, а опыт внедрения в компании с числом около 1.000 сотрудников будет интересен многим.

Итак, черный ящик открывается и из него появляется великий и ужасный ITIL, встречайте!

ITIL (произносится как «айти́л», IT Infrastructure Library — библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

Честно говоря не лучшее определение, но для начала сойдет. Да действительно это набор библиотек, которые рекомендуют нам best practices. ITIL не единственна в своем роде. Существует еще много различных документов, продумывающих работу IT службы, от того же cobit и до метода сисадмина Васи Пупкина, организовавшего работу в своей организации в соответствии со своими лучшими практиками и видением мира.

Мой выбор остановился на ITIL, и объяснять ее преимущества и недостатки я не стану, потому как они есть везде, а их обсасывание является пустейшей тратой времени, не ведущей не к чему.

ITIL, наиболее подходит компаниям-аутсортерам, хотя и обычной службе IT сгодится, как и не помешает одинокому сисадмину небольшой компании, не только для профессионального роста и изучения, но и для внедрения.

А вот и мои исходные данные. Компания, в которой я работаю и где на мою долю выпало внедрение ITIL, в полном его объеме, состоит из примерко 1500 сотрудников, 50 % из них является активными пользователями. IT инфраструктура включает в себя 3 домена и неисчислимое множетсво маленьких, но очень гордых филиалов и филиальчиков, разбросанных на растоянии до 300 км. друг от друга (не так уж и много)). С точки зрения айтишника, бизнес-процессы компании выглядят зрелыми и довольно отработанными.

К моменту начала внедрения часть сервисов описанных в ITIL уже были внедрены, но практически все работали на разных платформах, не имели общей точки входа, и не было возможности делать статистические срезы в масштабах всего-всего-всего.

Теперь, собственно, задача. IT-службе необходим мощный максимально гибкий и масштабируемый инструмент управления самой собой и ее грешными пользователями.

Таким вот инструментом и оказался ITIL вкупе с программными средствами.

Итак попытаюсь разобрать по пунктам разделы ITIL. оговорюсь сразу - т.к. это только лучшие практики и руководство к действию, но никак не инструкция по применению, внедряем ITIL v.2 c вкраплениями в него ITIL v.3 и, местами, своих личных заморочек. Все недовольные и пытающиеся бросать в меня тапком - идут лесом и ищут правды в других местах. Здесь представлен только краткий обзор, подробнее о каждом пунтке в отдельности и серьезно - позже.

Ну, что ж, пошли по порядку

Поддержка услуг (Service Support)- один из самых простых во внедрении, но самых неприятых в ежедневной работе моментов. Включает в себя процесс упарвления инциндентами - собственно, это есть в любом отделе IT и рассматривается, как его главная задача - появилась проблема - решили ее - ждем следующей)) формы могут быть разные от продвинутого helpdesk cо штатными сотрудниками оного, до эникейщика-студента, приходящего три раза в неделю и решающего проблемы. Суть не в этом, а в том, что среднестатистический отдел IT на этом и заканчивает. ITIL же писали грамотныю люди, придумавшие наличие в оном слудющего пункта поддержки услуг - процесс управление проблемами, куда более мощная вещь, и присутствует она обычно только в крупном helpdesk. Управление проблемами заключается в анализе инциндентов и вычленении из них проблем. Ведь как бывает, сервер упал, его подняли и ждут следующего падения, несмотря на то, что это уже пятое падение за два месяца, устранено следствие, а не проблема, которая все еще ждет своего звездного часа. Не менее полезной вещью становится и следующий пункт - процесс управление конфигурациями. Многие знаю Nagios, мониторят им сервера и акативное сетевое оборудование. А как вам идея глобального активного мониторинга всей сети, всех серверов и рабочих станций, всего ПО и всех лицензий, пользователей, доменной структуры собранных в одном месте? Согласитесь, привлекательно? Еще бы! А ITIL от нас требует этого напрямую и неукоснительно, здесь и сейчас. А чтоб закрепить дисциплину просит еще воспользоваться и процессом управления изменениями, который позволит стандартизировать внесение изменений в IT-инфраструктуру, и сделает этот процесс менее болезненным. Добавление нового филиала, отдела, сервера, не всегда приятная и развлекательная процедура, чаще это поиск резервов, места куда же воткнуть, так, чтоб не отвалилось завтра же. Грамотное планирование, основанное на анализе и сборе статистических данных, таки позволяют решить этот вопрос. Ну и завершает Поддержку услуг процесс управления релизми. Это полезно. Чтобы доказать это сразу и без всяких доказательств, спрошу у Вас - сколько версий одного ПО использует ваша компания, как часто Вы не можете понять, почему здесь стоит не то оборудовани, которое Вы представляли? Когда мы провели полную инвентаризацию, оказалось, что было до 9 разных версий одного ПО. Очень, кстати, неприятно для службы поддержки.

Идем дальше, перед поддержкой услуг нам нужно их предоставить, поэтому ITIL включает Предоставление услуг (Service Delivery). А он включает в себя не менее интересные подпункты.

Управление уровнем сервиса - любой сервис предоставленный it пользователю, в соответствии с каталогом услуг и соглашением об уровне услуг, должен быть учтен и проанализирован. Выводы тоже стоит сделать и начать действовать. Не стоит забывать и о закупках, платежых за хостинг, каналы связи и прочие полезные вещи. Сведение сего в единую базу, анализ и дальнейшие действия на его основе, очень помагает общению с бухгалтерией, финдиректорм, аудитором (кому как повезет). Не меньше это поможет и при попытке выбить новый сервер, маршрутизатор, группу серверов. Ну и, естественно, разговору с гендиректором, когда it не бездонная бочка в которую впустую выброшены средства, а работающий винтик налаженного механизма, обмеранный, утвержденный и готовый отчиться за все. Для этого и существует процесс управления финансами.

А теперь давайте вспомним чудестные моменты из жизни каждого, когда нужнобыло срочно развернуть дополнительный сервер, или настроить резервный, а его не было, не было даже возможности воткнуть куда-либо виртуальную машину. Бороть с этим и призван процесс управления мощностью. Он призван следить за постоянством и стабильностью IT-инфраструктуры.

Процесс управления непрерывностью, так же входящее в предоставление услуг, является ключевым моментом, который нужно измерять, так чтобы не быть виноватым. во всех смертных грехах IT. Составление грамотного SLA и каталога услуг, помогут нам (но об этом позже). Управление непрерывностью - по сути, ключ к успеху IT. Если Вы сможете всегда обосновать что все ваше оборудование, все сервисы работыли в штатном режиме, т.е. не нарушая SLA, Вам не страшен никто.

Завершающий предоставление услуг пункт - процесс упавления доступностью, мало чем отличается от предыдущего пункта, с той лишь разницей, что он направлен на оптимизацию предоставляемых сервисов и их всесторонний анализ.

Планирование внедрения управления услугами является еще одним из разделов ITIL , по сути его первейшим и основополагающим разделом. Так уж сложилось, что все зависит от конкретной конфигурации IT-инфраструктуры и этот раздел в основном является теоретическим. Он включает в себя процесс планирования и дальнейшего внедрения ITSM, сервисов и приложений, структуры службы ИТ и многого другого. В основном это полезно, если Вы строите новую инфраструктуру, если же уже есть полуготовое решение, слабовписывающееся в представления этого раздела, то его попросту стоит пропустить, и повседневно пользоваться следующим.

Управление приложениями ( Application Management) является крайне полезным инструментом в управлении ИТ, если Вы хотите действительно делать все хорошо. Основная мысль заключается в том, чтоб процесс внедрения приложения с момента его разработки и до окончания эксплуатации находился под полным контролем и управлением. Обычно ведь как получается, планирование сервиса или программного продукта это одно, его разработка и ввод в эксплуатацию совсем другое, ну а дальнейшее сопровождение третье. Комплексно на весь жизненный цикл приложения никто не смотрит. А зря. Согласованность между ТЗ, разработчиком и службой поддержки крайне полезная вещь, особенно, когда устранить главные проблемы получается на момент проектирования, а не в ходе эксплуатации. Ну а у инженера техподдержки, поверьте, практического опыта работы с программными обеспечением и в особенности с пользователями ит-сервисов гораздо больше чем у любого менеджера проекта или разработчика. Так что, основная мысль сведена к глобальному и всестороннему участию все, кто будет как-либо использовать сервис к привлечению обменом опытом и мнениями.

Еще одним достойным внимания элементом ITIL является управление безопасностью. Здесь впринципе все ясно, и интерес она состовляет в основном для сотрудников подразделений информационной безопасности, которые обычно несколько абстрагированы от ит-подразделения.

Такие элемента ITIL как Управление инфраструктурой информационно-коммуникационных технологий (ICT Infrastructure Management) и Бизнес-перспектива (The Business Perspective) особого внимания к себе не привлекают, т.к. их элементы, в необходимом для среднестатистической компании объеме, присутствуют в предыдущих разделах.

Вот так в общем, можно описать ITIL v.2 которого по моему скромному мнению хватит для нужд практически любой компании, и нужды во внедрении ITIL v.3 я откровенно не вижу. Еще раз повторю основную мысль вложенную мной во внедрение данного процессного подхода - ITIL этот только каркас, сам же инструмент управления ИТ Вам придется создавать самостоятельно. Если Вы, конечно, хотите разбираться в вопросе полностью, а не быть от кого-то зависимым.