Запись CD/DVD дисков из консоли
Запись образа на CD-R или CD-RW диск:
cdrecord -v -eject speed=10 dev=/dev/cdrom ~/disc.iso
При speed=0 программа сама выбирает подходящую скорость.
CD-RW диск необходимо сначала очистить:
cdrecord -v blank=fast dev=/dev/cdrom
blank=all - очистить весь диск
blank=fast - быстрая очистка диска
blank=session - очистить последнюю сессию
blank=unclose - открыть последнюю записанную сессию
Создание образа диска:
mkisofs -o test.iso -Jrv -V test_disk /home/user/something
В этом примере следующие обозначения:
-o - имя создаваемого iso-файла (test.iso)
-J - используем записи Joliet для совместимости с Windows
-r - Rock Ridge расширение для совсестимости с unix (сохраняет права на файлы)
-v - выводить информацию о выполняемом процессе
-V - указываем имя тома (test_disk); Это имя будет отображаться при просмотре в Windows
Запись DVD-R/RW дисков:
Очищаем DVD-RW диск:
dvd+rw-format -f /dev/cdrom
Запись образа:
growisofs -Z /dev/cdrom=image.iso
Запись файлов из каталога:
growisofs -Z /dev/cdrom -R -J /home/user/something
Параметр -Z применяется, если мы начинаем новую сессию. Чтобы добавить другую сессию, вместо -Z пишем параметр -M.
Утилита CDW
Существует ncurses-фронтенд для этих программ - CDW. Позволяет в удобной форме создавать образы и записывать диски.
Читать далее...
четверг, 15 августа 2013 г.
понедельник, 13 августа 2012 г.
Заповеди админов
Заповеди админов (С)перто
By ZaYaC:
0. Не потакай желаниям Юзеров, ибо они ламерны
1. Не внемли Юзеру Просящему, ибо ты можешь проникнуться желанием помочь ему, и нарушишь заповедь 0
2. Ставь все апдейты, дабы не привыкали Юзеры к Софту.
3. Не пытайся помочь юзерам, копаясь в их директориях - не отмоешь потом руки от того дерьма, которым они забивают место.
4. Не набирай Password при юзере - он может воспользоваться всяким ламерным хардом вроде видеокамеры, и таким неэтичным методом узнать твой Password.
5. Не допускай Юзера к ИНету, ибо он развратен.
6. Мочи весь Юзерский софт не думая, чтобы не поддаться соблазну нарушить заповедь 3.
7. Не отвечай на вопросы Юзера, дабы не нарушить заповедь 0.
8. Не давай юзерам прав - они и без прав юзеры.
9. Не допускай Юзеров к Серверу, дабы не нарушить заповедь 8.
A. Не вскрывай комп при юзерах, ибо все, что можно, они пожгут, а что нельзя - утащат.
B. Не оставляй Юзера без присмотра - он может одичать от одиночества или умереть со скуки.
C. Не давай юзеру игрушки , дабы не нарушать правило 6.
D. Убирай все устройства управления компьютера внутрь компьютера.
E. Ставь рубильник в серверную, дабы не нарушать заповеди 8, 9, A, D.
F. Неукоснительно следуй заповедям 0, 1, 2,3, 4, 5, 6, 7, 8, 9, A, B, C ,D, E, F, иначе станешь Юзером.
By Ева_Браун:
By Тигра:
Сравнение админов и программистов Программеры - они толстые. Потому что они сидят. А админы - они тощие. Потому что бегают. Впрочем, бывают тощие программеры. Но не надо думать, что это исключение из правил - это переученные админы. Также встречаются и толстые админы. Это обленившиеся программеры. Программеры курят быстро, потому что мысль. Потому что она уйдет и придется думать ее снова. У админов мыслей нет, поэтому они курят медленно. Они делают это в те моменты, когда все работает и ничего не падает. Поэтому они курят редко. Программеры ходят на обед сами. Они приносят много еды в офис и вкусно ею пахнут. Они едят ее прямо на клаве. Потому что мысль. Админы заказывают еду в офис. Потому что если они за ней пойдут, что-нибудь упадет. И придется бежать в офис с недоеденным гамбургером. Потому что админы любят питаться от Макдональдса. Потому что вкусно, а потолстеть им не грозит. Если они не обленившиеся программеры. Программеры уходят с работы ночью. Потому что мысль. Некоторые из них уходят вечером и думают мысль дома. Некоторые, у которых есть ноутбук, думают ее в метро. Админы домой не ходят. Потому что если они пойдут домой, что-нибудь упадет. И придется идти на работу. А на работу они ходить не любят. И не ходят. Они там живут. У них обычно есть отдельное гнездо за отдельной дверью, часто запираемой на отдельный замок. Программеры спят в выходной. Обычно это среда или понедельник. Потому что мысль. В понедельник мысли еще нет. А в среду идет переход от одной мысли к другой. Админы спят в гнезде. Из-за отдельтного замка в это время иногда раздается храп. Админы редко спят больше десяти минут. Потому что если проспать больше, что-нибудь упадет. И придется просыпаться по необходимости. А админы любят просыпаться сами, пусть и через десять минут. Программеры пьют пиво. В основном светлое и много. Потому что мысль. Пока она плавает - ее можно думать. Главное, чтобы не утонула. Админы тоже пьют пиво. Потому что если что-нибудь упадет, им будет пофиг. Админы любят когда им пофиг. И программеры любят, когда им пофиг. Поэтому часто они пьют пиво вместе. И им вместе пофиг. После этого они спят. Но не вместе. Админы спят в гнезде, а программеры - на клаве. Когда они просыпаются, они снова пьют пиво. Потому что хочется. Потому что они админы. И программеры.
Читать далее...
By ZaYaC:
0. Не потакай желаниям Юзеров, ибо они ламерны
1. Не внемли Юзеру Просящему, ибо ты можешь проникнуться желанием помочь ему, и нарушишь заповедь 0
2. Ставь все апдейты, дабы не привыкали Юзеры к Софту.
3. Не пытайся помочь юзерам, копаясь в их директориях - не отмоешь потом руки от того дерьма, которым они забивают место.
4. Не набирай Password при юзере - он может воспользоваться всяким ламерным хардом вроде видеокамеры, и таким неэтичным методом узнать твой Password.
5. Не допускай Юзера к ИНету, ибо он развратен.
6. Мочи весь Юзерский софт не думая, чтобы не поддаться соблазну нарушить заповедь 3.
7. Не отвечай на вопросы Юзера, дабы не нарушить заповедь 0.
8. Не давай юзерам прав - они и без прав юзеры.
9. Не допускай Юзеров к Серверу, дабы не нарушить заповедь 8.
A. Не вскрывай комп при юзерах, ибо все, что можно, они пожгут, а что нельзя - утащат.
B. Не оставляй Юзера без присмотра - он может одичать от одиночества или умереть со скуки.
C. Не давай юзеру игрушки , дабы не нарушать правило 6.
D. Убирай все устройства управления компьютера внутрь компьютера.
E. Ставь рубильник в серверную, дабы не нарушать заповеди 8, 9, A, D.
F. Неукоснительно следуй заповедям 0, 1, 2,3, 4, 5, 6, 7, 8, 9, A, B, C ,D, E, F, иначе станешь Юзером.
By Ева_Браун:
- Касательно настоящих админов...
- Hастоящий админ суров, вонючь и волосат. А также небрит.
- Hастоящий админ пьет все. Водку, пиво, спирт, самогон и даже фанту.
- Hастоящий админ пару раз в жизни видел Виндомс. Когда к нему приходит ослепительная блондинка и спрашивает что-либо касательно Word'а или Excel'а, он посылает ее нафиг.
- Hастоящий админ никогда не работает на своем компе. Да и вообще, для работы ему нужен комп, где есть telnet, и больше ничего. Этого достаточно.
- Настоящий админ терпеть не может хэ-винды. Хотя иногда их юзает.
- Hастоящий админ сам ко всему пишет патчи. Ему проще это сделать самому, чем разбираться в чужом барахле.
- Hастоящий админ имеет только одну мечту - что бы его не трогали. Поэтому он ищет себе работу где-нибудь на ISP, и соответственно ничего там не делает.
- Hастоящий админ не знает, что такое ICQ и IRC. Зато он хорошо знает что такое talkd. Ему гораздо проще открыть свою душу девушке именно через talk, чем в каком-нибудь мажорном кабаке.
- Hастоящий админ, когда работает, абсолютно глух. Для того, что бы вытащить его на пиво, нужно сделать 'write root poshli na pivo' или же 'talk root'
- Hастоящий админ дома тоже имеет комп. Когда он приводит домой девушку, он показывает ей свои последние патчи к кернелу и sendmail'у.
- Hастоящий админ не терпит Виндомс. Если ему приносят хаб или свитч, который програмируется программкой на дискете под винды, он ни за что не прикоснется к ней. Он напишет свою. Или "в слепую" настроит свитч терминалкой.
- Hастоящий админ никогда не читает чужую почту юзеров. У него своей хватает. Особенно спама.
- Hастоящий админ заводит себе только ту девушку, с которой может переписыватся по е-мейлу, причем пишет он ей транслитом в черно-белом PINE.
- Hастоящий админ никогда не снимает 7-ми битное ограничение с софта, которым пользуется. Поэтому ему можно писать только в кои-8 или транслитом.
- Hастоящий админ может законнектить комп любыми средствами - любой сетевой картой, COM-портом или же LPT-портом. Работает только с IP/NFS. Hепонимает, зачем нужен IPX или Samba client.
- Hастоящий админ никогда не читает компьютерные журналы. Он их ненавидит.
- Hастоящий админ никогда не читает книг и распечатанной документации. Он читает только с экрана и только BUGTRAQ. Может быть даже что-то еще, но только с экрана ...
- Hастоящий админ не знает, что такое usenet, зато хорошо знает, что такое mail-list. А ньюс-сервер он ставит и настраивает только потому, что начальство заставило.
- Hастоящий админ видит другого настоящего админа за километр. Когда они встречаются, они обмениваются обещаниями о аккаунтах. Аккаунты на чужих хостах - это тоже важный аттрибут настоящего админа.
- Hастоящий админ знает только об одном редакторе - vi, но также умеет работать в ed. Emacs для него - самый попсовый редактор.
- Hастоящий админ делает в шелле кучу aliases, и обычно обходится командами в два символа. Hо также хорошо знает все ключи для всех утилит.
- Hастоящий админ помнит всю свою сеть с точностью до IP и открытых портов на каждом своем хосте.
- Hастоящий админ инсталлит FreeBSD на свои роутеры только по ftp. Hе дай Бог с дискет или с сидюка. Только с ftp. (ftp://ftp.hастоящий/)
- Hастоящий админ, как правило, не помнит своего RIPE-кода. Если приходит время регистрировать новый домен, он получает новый RIPE-код, и тут же его забывает.
- Hастоящий админ не пользуется инсталляторами/сетаперами. Он делает проще : mkfs.ext2 /dev/hda1 mount /dev/hda1 /inst mount /dev/hdb1 /tmp1 cd inst cat /tmp1/syscore.tgz | tar -zx lilo -c /inst/etc/lilo.conf reboot ( правда иногда забывает про umount )
- Hастоящий админ никогда не использует доменных имен в telnet'е или ftp. Он коннектится только по IP, т.к. хорошо их помнит.
- Hастоящий админ никогда не отвечает на вопросы простых админов - он говорит лишь - "попробуй, может получится ..."
- Hастоящий админ не имеет своей home page. Зачем она ему ...
- Hастоящему админу может приснится только один ужасный сон - что он платит за интернет. У простого админа есть еще один плохой сон - полетели винты, но настоящему админу это не проблема - он быстро все может насетапить и настроить.
- Hастоящий админ редко реагирует на письма, у которых в подписи нет RIPE-кода.
- Hастоящий админ может писать такие конструкции. Вернее он обычно так и пишет : #define OPTION(c,v) (_O&2&&**v?*(*v)++:!c||_O&4?0:(!(_O&1)&& \ (--c,++v),_O=4,c&&**v=='-'&&v[0][1]?*++*v=='-'\ &&!v[0][1]?(--c,++v,0):(_O=2,*(*v)++):0))
- Когда настоящий админ приходит в гости к девушке, у которой есть компьютер, советует ей поставить FreeBSD, ругается, ищет telnet, опять ругается, телнетится на свой хост и продолжает клепать патчи. Про девушку он тут же забывает.
- "Интим" для настоящего админа - это зателнетится на комп своей девушки, и разговаривать с ней через talk.
- Hастоящий админ редко лазит по www, а если и приходится это делать, делает это через lynx.
- Hастоящий админ редко спит.
- Когда настоящего админа девушка просит выслать свою фотку, он набирает gzip myfoto | uuencode | mail girl@host, потом понимает, что host - это его же хост, и пока сендмейл не ругнулся, он успевает завести юзера girl. Девушке же говорит, что - сливай с поппера такого-то, пароль такой-то. Потом тут же вспоминает, что поппер у него наглухо закрыт извне файрволом, а телнет только через ssh. Короче ничего у них не получается.
- Вообще-то настоящий админ редко имеет свои фотки. Зачем они ему ...
- Hастоящий админ знает только об одном типе архивов - tgz.
- Hастоящий админ пишет курсовые в институт только на perl'е. Когда преподам это не нравится, настоящий админ обзывает всех юзерам и отказывается писать на попсовом паскале, то его отчисляют.
- Hастоящий админ знает только одно оскорбление - "ты юзер".
- Hастоящий админ может с нуля настроить любой конфиг в /etc, даже если его там нет. Даже sendmail.cf
- Если настоящему админу надоедают тормоза на ftp, с которого он что-то тянет, он натравливает на него wget и уходит спать.
- Hастоящий админ не признает RPM.
- Hастоящему админу наплевать на технические особенности компов, на которых работает.
- Первым делом он прописывает все винты, которые есть в компе в /etc/fstab, и тут же забывает о них. (с) 1999 г.
- Пы.Сы.: Глядя на своих коллег, понимаю, что я пока мастдайтный ламер.
- Пы. Пы. Сы.: glukDeLuxe, ты еще будешь мной гордиться))))))
By Тигра:
Сравнение админов и программистов Программеры - они толстые. Потому что они сидят. А админы - они тощие. Потому что бегают. Впрочем, бывают тощие программеры. Но не надо думать, что это исключение из правил - это переученные админы. Также встречаются и толстые админы. Это обленившиеся программеры. Программеры курят быстро, потому что мысль. Потому что она уйдет и придется думать ее снова. У админов мыслей нет, поэтому они курят медленно. Они делают это в те моменты, когда все работает и ничего не падает. Поэтому они курят редко. Программеры ходят на обед сами. Они приносят много еды в офис и вкусно ею пахнут. Они едят ее прямо на клаве. Потому что мысль. Админы заказывают еду в офис. Потому что если они за ней пойдут, что-нибудь упадет. И придется бежать в офис с недоеденным гамбургером. Потому что админы любят питаться от Макдональдса. Потому что вкусно, а потолстеть им не грозит. Если они не обленившиеся программеры. Программеры уходят с работы ночью. Потому что мысль. Некоторые из них уходят вечером и думают мысль дома. Некоторые, у которых есть ноутбук, думают ее в метро. Админы домой не ходят. Потому что если они пойдут домой, что-нибудь упадет. И придется идти на работу. А на работу они ходить не любят. И не ходят. Они там живут. У них обычно есть отдельное гнездо за отдельной дверью, часто запираемой на отдельный замок. Программеры спят в выходной. Обычно это среда или понедельник. Потому что мысль. В понедельник мысли еще нет. А в среду идет переход от одной мысли к другой. Админы спят в гнезде. Из-за отдельтного замка в это время иногда раздается храп. Админы редко спят больше десяти минут. Потому что если проспать больше, что-нибудь упадет. И придется просыпаться по необходимости. А админы любят просыпаться сами, пусть и через десять минут. Программеры пьют пиво. В основном светлое и много. Потому что мысль. Пока она плавает - ее можно думать. Главное, чтобы не утонула. Админы тоже пьют пиво. Потому что если что-нибудь упадет, им будет пофиг. Админы любят когда им пофиг. И программеры любят, когда им пофиг. Поэтому часто они пьют пиво вместе. И им вместе пофиг. После этого они спят. Но не вместе. Админы спят в гнезде, а программеры - на клаве. Когда они просыпаются, они снова пьют пиво. Потому что хочется. Потому что они админы. И программеры.
Читать далее...
понедельник, 26 декабря 2011 г.
Service Desk своими руками
Денис Бобров
Первый вопрос, возникающий у ИТ-руководителя, которому предложили идею процессного подхода к управлению ИТ-инфраструктурой: «Зачем мне нужен ITIL (ITSM, Service Desk, управление инцидентами и т. д.), если у меня и так все хорошо?» Вот каким может быть ответ.
Посмотрим, как обычно происходит управление ИТ-инфраструктурой рядового российского предприятия. Начальнику ИТ-отдела звонит генеральный директор компании и сообщает, например, что у него не работает электронная почта. Руководитель ИТ-подразделения ловит в коридоре технического инженера и отправляет его к директору для восстановления работоспособности почты. К этому моменту секретарь топ-менеджера уже сообщил системному администратору о возникшей проблеме, и тот самоотверженно бросается на помощь. Через считанные минуты в дверях кабинета генерального директора одновременно появляются два запыхавшихся «компьютерщика»… Едва ли такие действия можно назвать эффективным управлением ИТ-инфраструктурой.
В компаниях, где ведется регистрация и анализ обращений пользователей (там, где настроен процесс управления инцидентами и функционирует служба Service Desk), ответы на вопросы о том, сколько раз в месяц «зависает» (дает сбой) критически важная для бизнеса программная система, на каких рабочих местах это происходит, в чем причина каждого инцидента, находятся сами собой и могут существенно повлиять на планы развития компании в области ИТ.
Шаг второй. Обучение
Для того чтобы служба Service Desk начала работать эффективно, недостаточно одной, пусть даже идеальной схемы мотивации сотрудников. Весь штат ИТ-департамента должен знать, а еще лучше – понимать, зачем нужен Service Desk, что такое управление инцидентами и т. д. Для этого необходимо обучить всех сотрудников ИТ-департамента основам ITIL. Затраты при этом будут неизбежны.
Нежелательно обучать специалистов самостоятельно, так как цена неверно понятого описания процесса или термина может оказаться слишком высокой. Наибольший эффект достигается при обучении сотрудников ИТ-отдела профессиональными тренерами. Можно совместить приятное с полезным. К примеру: проведите обучение в выходной день за городом. В этом случае бизнес не останется без поддержки в рабочие дни, а все сотрудники ИТ-департамента приобретут не только полезные знания, но и хорошее настроение. Отказавшись от обучения персонала основам ITIL, можно столкнуться с большой проблемой – саботажем. Выбираться из этой ситуации окажется дороже, чем заранее предотвратить ее, проведя обучение специалистов.
После того как все сотрудники прошли тренинг по основам ITIL/ITSM, следует ознакомить их с регламентами, которые уже составлены. И никак не раньше. Уже с обученными сотрудниками (или с некоторыми из них) можно и нужно проконсультироваться, узнать их мнение, выслушать предложения. Здесь может произойти первая корректировка процесса приема и обработки обращений пользователей.
Шаг третий. Организация call-центра
«Что может быть проще! – скажете вы. – Берем стол, стул, компьютер, телефон, принимаем на работу девушку с приятным голосом. И вот call-центр готов». Однако не все так просто. Существует как минимум два вопроса, которым требуется уделить особое внимание: какими качествами должен обладать оператор и где расположить его рабочее место.
Приятный голос – это далеко не самое главное, чем должен обладать человек, работающий на первой линии поддержки Service Desk. Стрессоустойчивость гораздо важнее для оператора, который в течение одного рабочего дня может несколько десятков раз слышать одну и ту же фразу: «У меня не работает компьютер!» — и при этом обязан всегда одинаково невозмутимо и доброжелательно выяснять у пользователя, что же действительно сломалось. Кроме того, сотрудник первой линии поддержки должен хорошо владеть русским языком. Грубые грамматические и синтаксические ошибки, допущенные оператором при регистрации обращения пользователя, могут неблагоприятно отразиться на понимании сути заявки другими специалистами. Наконец, оператор call-центра должен обладать общими ИТ-знаниями. Комментарии здесь излишни. Очевидно, что оператор, услышав слово «винчестер», должен представлять себе устройство долговременного хранения информации, а не огнестрельное оружие.
Практика показывает, что нахождение первой и третьей линий поддержки в одном помещении крайне негативно сказывается на результатах работы высококвалифицированных специалистов. Резко снижается эффективность системных администраторов. Количество ошибок в программном коде у программистов возрастает в несколько раз! Этот факт обусловлен тем, что сотрудники, работающие на третьей линии поддержки, решают, как правило, нетривиальные задачи, требующие высокой степени сосредоточенности. А как можно сосредоточиться, если рядом каждые десять минут звонит телефон, и оператор отвечает: «Добрый день, отдел ИТ слушает»?
Совсем другая обстановка возникает, если расположить рабочее место оператора call-центра рядом с рабочими местами сотрудников второй линии поддержки. Решение задач второй линии поддержки не требует особой сосредоточенности и, следовательно, общение оператора с пользователями не будет сильно их отвлекать. В то же время тесное общение специалистов первой линии поддержки с сотрудниками второй линии может дать положительные результаты: через некоторое время часть проблем, которые ранее решались на второй линии, смогут устраняться уже на первой. Этим можно улучшить один из главных показателей эффективности Service Desk – сократить среднее время решения проблем.
Шаг четвертый
Когда принципы функционирования службы Service Desk описаны (подготовлена документация), сотрудники знают и понимают основы ITIL/ITSM и определено рабочее место операторов call-центра, стоит задуматься об инструментарии. Для того чтобы контролировать процесс приема и обработки обращений пользователей, необходимо специализированное программное обеспечение. Наиболее распространенным инструментом сегодня является HP OpenView ServiceDesk. Но многие компании не имеют средств на приобретение такого программного обеспечения, да и нужен ли на стартовом этапе инструмент такого высокого уровня? Скорее всего, нет, так как сначала требуется наладить сам процесс приема и обработки обращений пользователей.
Если в штате ИТ-департамента есть хотя бы один программист, то задача построения собственной системы приема и обработки обращений пользователей решается сама собой. Любой программист менее чем за месяц может создать базу данных и подготовить генерацию стандартных отчетов. Если же программиста нет, то можно пойти еще более простым путем: достаточно зайти на сайт http://www.helpdesk.com, где хранится огромный список ссылок на различного рода программное обеспечение для поддержки служб Help Desk, Service Desk и call-центров. Потратив немного времени, можно найти бесплатный и вполне достаточный по набору функций инструментарий. Если и этот вариант не устраивает по каким-либо причинам, то можно, наконец, использовать «подручные» средства – Microsoft Excel и Access. Потратив несколько часов рабочего времени, можно создать свой собственный уникальный инструмент для службы Service Desk.
Первые результаты
Теперь все готово для запуска в работу новой службы Service Desk. Конечно, нужно не забыть оповестить всех пользователей о новой услуге, сообщить единый телефонный номер отдела ИТ, по которому пользователи могут обратиться с любым вопросом.
Каких же результатов стоит ожидать? Если в первый день работы службы на телефон call-центра поступит более одного звонка от пользователей – это достижение. Если в первый месяц работы хотя бы один сотрудник компании скажет, что ему стало удобнее общаться с ИТ-департаментом, – это победа.
Можно выделить две основные проблемы, с которыми придется столкнуться в первое время работы службы Service Desk. Первая заключается в том, что большинство пользователей в первые месяцы будут продолжать «по старинке» звонить системным администраторам, программистам и т. д. Но если система мотивации сотрудников ИТ была выстроена достаточно грамотно и был проведен тренинг по основам ITIL, то об этом можно не беспокоиться. ИТ-руководитель не будет тратить массу своего времени на разъяснительные беседы с пользователями о полезности службы Service Desk. Системный администратор, которому в очередной раз позвонит пользователь, сам объяснит, куда и к кому надо обращаться с вопросами. Причем он найдет такие аргументы, о которых ни один ИТ-менеджер даже не догадывается. Такой путь — приучить пользователей звонить по одному определенному номеру —максимально эффективен.
Известно много случаев, когда руководители ИТ-служб пытались переучить сотрудников предприятия иными способами: воздействуя на пользователей через высшее руководство, меняя внутренние номера телефонов сотрудников ИТ-департамента, проводя массовую разъяснительную работу с пользователями. Но все эти варианты неэффективны и приводят, как правило, к длительному времени адаптации пользователей к работе в новых условиях. Нежелание пользователей взаимодействовать с ИТ-департаментом через единую точку контактов можно преодолеть только с помощью самих сотрудников отдела ИТ.
Вторая проблема, с которой придется столкнуться, – увеличение среднего времени обработки одного инцидента. Это плата за те статистические данные по обращениям, которые получит менеджер уже после первого месяца работы службы Service Desk. Увеличение времени решения инцидента, безусловно, будет заметно для пользователей, и именно с этим будут связаны основные негативные эмоции сотрудников предприятия. Ничего особенного в этом нет: служба только-только начала работать, процесс управления инцидентами еще слабо настроен, и сотрудники ИТ не привыкли действовать по новой схеме. Но уже через месяц после запуска Service Desk можно получить данные, из анализа которых видно, где в процессе слабое место, что и как нужно исправить, кто мешает нормальному ходу процесса. Начнется бесконечная настройка и модернизация службы Service Desk. В зависимости от скорости реагирования на выявленные проблемы и неточности в функционировании службы будет сокращаться среднее время решения инцидентов, повышаться удовлетворенность пользователей и т. д.
Пути развития
После того как служба Service Desk начала стабильно работать и прошел период адаптации, после того как улягутся первые страсти пользователей, можно задуматься о том, в каком направлении развиваться дальше. Путей много. Самым очевидным из них является повышение компетенции первой линии поддержки. Сразу после запуска службы первая линия (операторы call-центра) сможет закрывать максимум 20-30% всех регистрируемых инцидентов. Этот результат весьма хорош. Но совершенству нет предела. Развивая компетенцию операторов, обучая их, добавляя им дополнительные права и обязанности, можно повысить процент инцидентов, закрываемых на первой линии поддержки. В этом случае специалисты второй и третьей линий в большей степени смогут посвятить себя сложным и нетривиальным задачам. Второй эффект от увеличения числа инцидентов, закрываемых операторами, проявится в большей удовлетворенности пользователей работой департамента ИТ: та часть вопросов, которая ранее решалась, к примеру, в течение двух-трех часов (время реакции второй линии поддержки), теперь будет решаться за 10-20 минут.
Дальнейшее развитие службы Service Desk может выражаться в замене того «бесплатного» инструмента регистрации и обработки запросов пользователей, который использовался в первое время работы, на более функциональный, специализированный. Новый инструмент может предоставить более детальную информацию о работе Service Desk, и тогда появится возможность проводить более тонкую настройку процесса управления инцидентами. При этом пользователи также получат дополнительные услуги, к примеру, автоматическое оповещение по электронной почте о решении инцидента. После того, как проявятся реальные положительные результаты работы службы Service Desk (а они проявятся обязательно), доказывать высшему руководству компании необходимость приобретения специализированного программного обеспечения будет намного проще. Не исключен даже вариант, когда руководство компании само предложит помощь и средства на развитие процесса обработки запросов пользователей.
Без рисков не обойтись
Конечно, при самостоятельном выстраивании процессного подхода в управлении ИТ-инфраструктурой не исключены риски, связанные с принятием ошибочных решений, что может нарушить сроки построения и настройки процесса управления инцидентами. Эти риски значительно снижаются, если воспользоваться услугами квалифицированных и опытных консультантов. Но какой бы путь вы ни избрали, стоит помнить: основой для любого процесса ITIL является информация, которую можно получить только имея грамотно построенную и работающую службу Service Desk. И именно с построения этой службы следует начинать работу по эффективному управлению ИТ-инфраструктурой предприятия.
Денис Бобров, заместитель руководителя ИТ-департамента ЗАО «Талосто», Bobrov_DA@talosto.ru
http://www.osp.ru
Читать далее...
Первый вопрос, возникающий у ИТ-руководителя, которому предложили идею процессного подхода к управлению ИТ-инфраструктурой: «Зачем мне нужен ITIL (ITSM, Service Desk, управление инцидентами и т. д.), если у меня и так все хорошо?» Вот каким может быть ответ.
Посмотрим, как обычно происходит управление ИТ-инфраструктурой рядового российского предприятия. Начальнику ИТ-отдела звонит генеральный директор компании и сообщает, например, что у него не работает электронная почта. Руководитель ИТ-подразделения ловит в коридоре технического инженера и отправляет его к директору для восстановления работоспособности почты. К этому моменту секретарь топ-менеджера уже сообщил системному администратору о возникшей проблеме, и тот самоотверженно бросается на помощь. Через считанные минуты в дверях кабинета генерального директора одновременно появляются два запыхавшихся «компьютерщика»… Едва ли такие действия можно назвать эффективным управлением ИТ-инфраструктурой.
В компаниях, где ведется регистрация и анализ обращений пользователей (там, где настроен процесс управления инцидентами и функционирует служба Service Desk), ответы на вопросы о том, сколько раз в месяц «зависает» (дает сбой) критически важная для бизнеса программная система, на каких рабочих местах это происходит, в чем причина каждого инцидента, находятся сами собой и могут существенно повлиять на планы развития компании в области ИТ.
Сколько это стоит?
Сегодня найдется немало компаний, которые могут помочь в построении службы Service Desk. Квалифицированные консультанты оценят уровень зрелости процессов ITIL на предприятии, разработают для ИТ-департамента план по внедрению того или иного процесса, подберут и настроят оптимальный инструментарий. Однако услуги консультантов не бесплатны. А руководители компаний среднего и малого бизнеса, как правило, не считают ИТ-департамент стратегическим подразделением и, следовательно, неохотно инвестируют средства в ИТ-проекты. Возникает вопрос: как доказать руководству необходимость выделения средств на развертывание службы Service Desk?
Если не удалось с первого раза убедить высшее руководство предприятия в необходимости инвестиций, то все последующие попытки также будут обречены на провал. Доказать инвестиционную привлекательность службы Service Desk практически невозможно, точно так же, как и рассчитать срок возврата инвестиций. Чтобы оценить экономический эффект, потребуются начальные данные, такие как среднее время разрешения одного инцидента, количество инцидентов в день, месяц, год и т. д. Но если в ИТ-департаменте еще не работает служба Service Desk, то как узнать, какое время в среднем тратится на разрешение одного инцидента? Если нет статистики об обращениях пользователей, то где взять информацию о количестве инцидентов? Помимо этого, на практике в первые месяцы работы службы Service Desk время разрешения одного инцидента увеличивается. Сократить его удается не сразу. Следовательно, говорить о положительном экономическом эффекте в первые месяцы работы службы не приходится.
Итак, если не удается построить Service Desk на средства компании, то можно попробовать развернуть службу самостоятельно, без привлечения сторонних консультантов и затрат на специализированное программное обеспечение.
С чего начать?
Многие скажут, что начинать надо с оформления проекта. Однако в случае построения службы Service Desk подобный подход нереализуем. Какие цели проекта следует указать? Какие сроки поставить? Какие риски проекта описать? Практика организаций, в которых работает Service Desk, показывает, что создать идеальную службу невозможно. Она постоянно изменяется и совершенствуется. Поэтому с большой вероятностью описанные грандиозные цели проекта по созданию Service Desk утратят свою актуальность еще в процессе их достижения. А между тем, срок такого проекта может исчисляться годами! Так нужен ли такой проект? С другой стороны, работать без четко описанных целей также невозможно. Необходимо понимать, в каком направлении двигаться и что должно получиться в итоге.
Таким образом, при создании службы Service Desk оптимальный вариант – серия небольших проектов с понятными, осязаемыми краткосрочными целями.
Шаг первый. Фиксируем регламенты
Итак, перейдем к реальным действиям. На первом этапе потребуются всего лишь лист бумаги и ручка. Создание Service Desk начинается с описания регламентов функционирования будущей службы. Даже если есть четкое представление о структуре Service Desk, о ролевых обязанностях сотрудников и о процедурах, по которым будут работать специалисты службы, все равно регламенты необходимо зафиксировать.
Допустим, вы купили новый телевизор. Как часто вы будете пользоваться инструкцией по эксплуатации? Наверное, не очень часто. Тем не менее ни у кого не возникает сомнения в полезности этого документа. То же самое можно сказать об описании функционирования службы Service Desk: оно обычно лежит на полке в одном из кабинетов ИТ-департамента до тех пор, пока не потребуется изменить или усовершенствовать процесс приема и обработки обращений пользователей.
Относительно объема данного документа, его полноты и развернутости четких рекомендаций не существует. Тем не менее нет смысла подробнейшим образом и максимально детально описывать все регламенты службы Service Desk. Документ получится слишком большим и нечитабельным. Однако создавать его излишне кратким также не стоит. В первом варианте документа на один регламент достаточно отвести одну-две страницы.
Какие регламенты и правила функционирования Service Desk следует описать? Однозначных, предельно конкретных советов здесь быть не может. Перечислим лишь наиболее общие из них.
Количество линий поддержки службы Service Desk и распределение ИТ-сотрудников по линиям поддержки. Классика ITIL рекомендует развернуть три линии. К первой линии поддержки могут относиться операторы call-центра, ко второй – администраторы баз данных, системные администраторы, технические специалисты, к третьей – программисты, старшие системные администраторы. Ваши сторонние подрядчики, организации, которые предоставляют вам услуги по сопровождению ПО, провайдеры телекоммуникационных услуг и т. д. также могут быть отнесены к третьей линии поддержки.
Способы приема заявок пользователей. Вариантов достаточно много, начиная от официально оформленной служебной записки в бумажной форме и заканчивая дружеским общением с помощью ICQ. Но в первое время работы службы Service Desk стоит ограничиться одним или двумя способами поступления обращений пользователей. Перечислим наиболее распространенные.
Первый – телефонный звонок пользователя – самый простой и самый эффективный вариант. В этом случае оператор Service Desk имеет возможность успокоить пользователя, если тот чрезмерно взволнован очередным сбоем. Кроме того, в процессе общения с пользователем оператор call-центра может быстро определить причину инцидента и предложить решение. Тем самым запрос будет обработан в самые короткие сроки.
Вторым способом обращений пользователей за поддержкой может быть электронная почта. В этом способе коммуникации с Service Desk есть свои преимущества и недостатки. Далеко не на всех предприятиях пользователи настолько грамотны в области применения ИТ, чтобы с первого раза кратко и понятно описать ситуацию (произошедший сбой). Неточное описание может повлечь за собой долгую переписку между оператором call-центра и пользователем. Результат – увеличение времени решения проблемы. Положительные стороны обращения пользователя в службу Service Desk при помощи электронной почты, разумеется, тоже есть. Например, пользователь направляет электронное письмо с описанием сбоя на определенный адрес. При поступлении нового сообщения в этот почтовый ящик происходит автоматическая регистрация обращения в предварительно настроенной системе службы Service Desk. В этом случае оператор первой линии поддержки не тратит время на регистрацию обращения, а может сразу же приступить к поиску решения инцидента.
Третий способ – корпоративный портал или некий сайт, на котором пользователь может самостоятельно зарегистрировать инцидент. Этот способ обращения пользователя обладает всеми теми же положительными и отрицательными чертами, что и в случае с электронной почтой.
Приоритеты и временные регламенты. Здесь необходимо описать временные рамки и возможные приоритеты обращений пользователей. Например, обращение пользователя в связи с остановкой основного бизнес-приложения, от которого напрямую зависит прибыль компании, должно иметь высший приоритет. А обращению по вопросу сбоя в работе принтера у одного пользователя должен присваиваться низкий приоритет (если, конечно, этот пользователь – не генеральный директор). В зависимости от приоритетов обращений, необходимо указать время реакции. Например, время обработки инцидента с высоким приоритетом на первой линии поддержки не должно превышать 10 минут. Если проблему не удалось ликвидировать, она переводится на вторую линию поддержки, где на ее решение отводится два часа, после чего обращение переводится на третью линию поддержки. На третьей линии инцидент может решаться, например, пять часов. Если в течение и этого времени не удалось восстановить работоспособность, тогда проблема эскалируется на уровень ИТ-менеджера. Существуют более точные, но в то же время и более сложные варианты расчета времени работы над инцидентом.
Каждый сбой в ИТ-инфраструктуре влечет за собой остановку бизнес-процесса одного конкретного специалиста, и/или отдельного отдела, и/или целого предприятия. Следовательно, каждый сбой имеет различные степени влияния. Поломка принтера у одного человека влияет только на бизнес-процессы одного сотрудника предприятия, и то не на все. Если же принтер сетевой, то влияние сбоя усиливается, поскольку сбои в бизнес-процессах затрагивают нескольких сотрудников. Если же остановился сервер обмена сообщениями (например Exchange Server), то сбой, скорее всего, затрагивает большинство подразделений.
При определенном навыке оператор Service Desk может сразу определить степень влияния того или иного сбоя. Например, если принтер остановился в бухгалтерии, то приоритет может быть невысоким. Бухгалтерские отчеты можно распечатать и днем позже (если, конечно, бухгалтерия не печатает отчеты накануне их сдачи в налоговую инспекцию). А остановка принтера, допустим, в главной диспетчерской центрального склада влечет за собой остановку отгрузки товара и, как следствие, убытки для предприятия. Таким образом, имеются два параметра: степень влияния и приоритет обращения. Исходя из этих данных, можно более детально рассчитать сроки прохождения инцидента по линиям поддержки.
Задача на этапе составления документации – определить степени влияния и приоритеты и на их основе рассчитать время разрешения инцидента на первой, второй и третьей линиях поддержки.
Классификация обращений. Теория предлагает стандартную классификацию запросов: запрос на обслуживание, на изменение, на предоставление информации и т. д. Можно придумать свои классы или использовать только некоторые из известных. Вообще отказываться от классификации обращений не следует. В дальнейшем, при анализе обращений она сослужит добрую службу.
«Главный регламент». Это не маршрутизация инцидентов и не перечень предоставляемой отчетности. «Главный регламент» – это мотивация ваших сотрудников. По опыту многих организаций и предприятий, которые развертывали службы Service Desk, можно однозначно утверждать: если не будет выстроена система материальной (и нематериальной) мотивации сотрудников, то служба Service Desk никогда не начнет работать эффективно. Необходимо уделить особое внимание этой части документа. Вот несколько рекомендаций, которые помогут в построении грамотной схемы мотивации.
Сегодня найдется немало компаний, которые могут помочь в построении службы Service Desk. Квалифицированные консультанты оценят уровень зрелости процессов ITIL на предприятии, разработают для ИТ-департамента план по внедрению того или иного процесса, подберут и настроят оптимальный инструментарий. Однако услуги консультантов не бесплатны. А руководители компаний среднего и малого бизнеса, как правило, не считают ИТ-департамент стратегическим подразделением и, следовательно, неохотно инвестируют средства в ИТ-проекты. Возникает вопрос: как доказать руководству необходимость выделения средств на развертывание службы Service Desk?
Если не удалось с первого раза убедить высшее руководство предприятия в необходимости инвестиций, то все последующие попытки также будут обречены на провал. Доказать инвестиционную привлекательность службы Service Desk практически невозможно, точно так же, как и рассчитать срок возврата инвестиций. Чтобы оценить экономический эффект, потребуются начальные данные, такие как среднее время разрешения одного инцидента, количество инцидентов в день, месяц, год и т. д. Но если в ИТ-департаменте еще не работает служба Service Desk, то как узнать, какое время в среднем тратится на разрешение одного инцидента? Если нет статистики об обращениях пользователей, то где взять информацию о количестве инцидентов? Помимо этого, на практике в первые месяцы работы службы Service Desk время разрешения одного инцидента увеличивается. Сократить его удается не сразу. Следовательно, говорить о положительном экономическом эффекте в первые месяцы работы службы не приходится.
Итак, если не удается построить Service Desk на средства компании, то можно попробовать развернуть службу самостоятельно, без привлечения сторонних консультантов и затрат на специализированное программное обеспечение.
С чего начать?
Многие скажут, что начинать надо с оформления проекта. Однако в случае построения службы Service Desk подобный подход нереализуем. Какие цели проекта следует указать? Какие сроки поставить? Какие риски проекта описать? Практика организаций, в которых работает Service Desk, показывает, что создать идеальную службу невозможно. Она постоянно изменяется и совершенствуется. Поэтому с большой вероятностью описанные грандиозные цели проекта по созданию Service Desk утратят свою актуальность еще в процессе их достижения. А между тем, срок такого проекта может исчисляться годами! Так нужен ли такой проект? С другой стороны, работать без четко описанных целей также невозможно. Необходимо понимать, в каком направлении двигаться и что должно получиться в итоге.
Таким образом, при создании службы Service Desk оптимальный вариант – серия небольших проектов с понятными, осязаемыми краткосрочными целями.
Шаг первый. Фиксируем регламенты
Итак, перейдем к реальным действиям. На первом этапе потребуются всего лишь лист бумаги и ручка. Создание Service Desk начинается с описания регламентов функционирования будущей службы. Даже если есть четкое представление о структуре Service Desk, о ролевых обязанностях сотрудников и о процедурах, по которым будут работать специалисты службы, все равно регламенты необходимо зафиксировать.
Допустим, вы купили новый телевизор. Как часто вы будете пользоваться инструкцией по эксплуатации? Наверное, не очень часто. Тем не менее ни у кого не возникает сомнения в полезности этого документа. То же самое можно сказать об описании функционирования службы Service Desk: оно обычно лежит на полке в одном из кабинетов ИТ-департамента до тех пор, пока не потребуется изменить или усовершенствовать процесс приема и обработки обращений пользователей.
Относительно объема данного документа, его полноты и развернутости четких рекомендаций не существует. Тем не менее нет смысла подробнейшим образом и максимально детально описывать все регламенты службы Service Desk. Документ получится слишком большим и нечитабельным. Однако создавать его излишне кратким также не стоит. В первом варианте документа на один регламент достаточно отвести одну-две страницы.
Какие регламенты и правила функционирования Service Desk следует описать? Однозначных, предельно конкретных советов здесь быть не может. Перечислим лишь наиболее общие из них.
Количество линий поддержки службы Service Desk и распределение ИТ-сотрудников по линиям поддержки. Классика ITIL рекомендует развернуть три линии. К первой линии поддержки могут относиться операторы call-центра, ко второй – администраторы баз данных, системные администраторы, технические специалисты, к третьей – программисты, старшие системные администраторы. Ваши сторонние подрядчики, организации, которые предоставляют вам услуги по сопровождению ПО, провайдеры телекоммуникационных услуг и т. д. также могут быть отнесены к третьей линии поддержки.
Способы приема заявок пользователей. Вариантов достаточно много, начиная от официально оформленной служебной записки в бумажной форме и заканчивая дружеским общением с помощью ICQ. Но в первое время работы службы Service Desk стоит ограничиться одним или двумя способами поступления обращений пользователей. Перечислим наиболее распространенные.
Первый – телефонный звонок пользователя – самый простой и самый эффективный вариант. В этом случае оператор Service Desk имеет возможность успокоить пользователя, если тот чрезмерно взволнован очередным сбоем. Кроме того, в процессе общения с пользователем оператор call-центра может быстро определить причину инцидента и предложить решение. Тем самым запрос будет обработан в самые короткие сроки.
Вторым способом обращений пользователей за поддержкой может быть электронная почта. В этом способе коммуникации с Service Desk есть свои преимущества и недостатки. Далеко не на всех предприятиях пользователи настолько грамотны в области применения ИТ, чтобы с первого раза кратко и понятно описать ситуацию (произошедший сбой). Неточное описание может повлечь за собой долгую переписку между оператором call-центра и пользователем. Результат – увеличение времени решения проблемы. Положительные стороны обращения пользователя в службу Service Desk при помощи электронной почты, разумеется, тоже есть. Например, пользователь направляет электронное письмо с описанием сбоя на определенный адрес. При поступлении нового сообщения в этот почтовый ящик происходит автоматическая регистрация обращения в предварительно настроенной системе службы Service Desk. В этом случае оператор первой линии поддержки не тратит время на регистрацию обращения, а может сразу же приступить к поиску решения инцидента.
Третий способ – корпоративный портал или некий сайт, на котором пользователь может самостоятельно зарегистрировать инцидент. Этот способ обращения пользователя обладает всеми теми же положительными и отрицательными чертами, что и в случае с электронной почтой.
Приоритеты и временные регламенты. Здесь необходимо описать временные рамки и возможные приоритеты обращений пользователей. Например, обращение пользователя в связи с остановкой основного бизнес-приложения, от которого напрямую зависит прибыль компании, должно иметь высший приоритет. А обращению по вопросу сбоя в работе принтера у одного пользователя должен присваиваться низкий приоритет (если, конечно, этот пользователь – не генеральный директор). В зависимости от приоритетов обращений, необходимо указать время реакции. Например, время обработки инцидента с высоким приоритетом на первой линии поддержки не должно превышать 10 минут. Если проблему не удалось ликвидировать, она переводится на вторую линию поддержки, где на ее решение отводится два часа, после чего обращение переводится на третью линию поддержки. На третьей линии инцидент может решаться, например, пять часов. Если в течение и этого времени не удалось восстановить работоспособность, тогда проблема эскалируется на уровень ИТ-менеджера. Существуют более точные, но в то же время и более сложные варианты расчета времени работы над инцидентом.
Каждый сбой в ИТ-инфраструктуре влечет за собой остановку бизнес-процесса одного конкретного специалиста, и/или отдельного отдела, и/или целого предприятия. Следовательно, каждый сбой имеет различные степени влияния. Поломка принтера у одного человека влияет только на бизнес-процессы одного сотрудника предприятия, и то не на все. Если же принтер сетевой, то влияние сбоя усиливается, поскольку сбои в бизнес-процессах затрагивают нескольких сотрудников. Если же остановился сервер обмена сообщениями (например Exchange Server), то сбой, скорее всего, затрагивает большинство подразделений.
При определенном навыке оператор Service Desk может сразу определить степень влияния того или иного сбоя. Например, если принтер остановился в бухгалтерии, то приоритет может быть невысоким. Бухгалтерские отчеты можно распечатать и днем позже (если, конечно, бухгалтерия не печатает отчеты накануне их сдачи в налоговую инспекцию). А остановка принтера, допустим, в главной диспетчерской центрального склада влечет за собой остановку отгрузки товара и, как следствие, убытки для предприятия. Таким образом, имеются два параметра: степень влияния и приоритет обращения. Исходя из этих данных, можно более детально рассчитать сроки прохождения инцидента по линиям поддержки.
Задача на этапе составления документации – определить степени влияния и приоритеты и на их основе рассчитать время разрешения инцидента на первой, второй и третьей линиях поддержки.
Классификация обращений. Теория предлагает стандартную классификацию запросов: запрос на обслуживание, на изменение, на предоставление информации и т. д. Можно придумать свои классы или использовать только некоторые из известных. Вообще отказываться от классификации обращений не следует. В дальнейшем, при анализе обращений она сослужит добрую службу.
«Главный регламент». Это не маршрутизация инцидентов и не перечень предоставляемой отчетности. «Главный регламент» – это мотивация ваших сотрудников. По опыту многих организаций и предприятий, которые развертывали службы Service Desk, можно однозначно утверждать: если не будет выстроена система материальной (и нематериальной) мотивации сотрудников, то служба Service Desk никогда не начнет работать эффективно. Необходимо уделить особое внимание этой части документа. Вот несколько рекомендаций, которые помогут в построении грамотной схемы мотивации.
- Мотивация в большей степени должна быть построена на поощрении сотрудников, а не на наказании. Использовать штрафные санкции допустимо только в крайних случаях, например при нарушении сотрудником установленных регламентов.
- Материальная мотивация должна быть ощутимой. 5% от оклада специалиста – это пародия на мотивацию.
- Схема мотивации должна быть проста и понятна каждому сотруднику ИТ-департамента. Пять-шесть параметров, которые используются для расчета премий специалистов, можно считать пределом.
Шаг второй. Обучение
Для того чтобы служба Service Desk начала работать эффективно, недостаточно одной, пусть даже идеальной схемы мотивации сотрудников. Весь штат ИТ-департамента должен знать, а еще лучше – понимать, зачем нужен Service Desk, что такое управление инцидентами и т. д. Для этого необходимо обучить всех сотрудников ИТ-департамента основам ITIL. Затраты при этом будут неизбежны.
Нежелательно обучать специалистов самостоятельно, так как цена неверно понятого описания процесса или термина может оказаться слишком высокой. Наибольший эффект достигается при обучении сотрудников ИТ-отдела профессиональными тренерами. Можно совместить приятное с полезным. К примеру: проведите обучение в выходной день за городом. В этом случае бизнес не останется без поддержки в рабочие дни, а все сотрудники ИТ-департамента приобретут не только полезные знания, но и хорошее настроение. Отказавшись от обучения персонала основам ITIL, можно столкнуться с большой проблемой – саботажем. Выбираться из этой ситуации окажется дороже, чем заранее предотвратить ее, проведя обучение специалистов.
После того как все сотрудники прошли тренинг по основам ITIL/ITSM, следует ознакомить их с регламентами, которые уже составлены. И никак не раньше. Уже с обученными сотрудниками (или с некоторыми из них) можно и нужно проконсультироваться, узнать их мнение, выслушать предложения. Здесь может произойти первая корректировка процесса приема и обработки обращений пользователей.
Шаг третий. Организация call-центра
«Что может быть проще! – скажете вы. – Берем стол, стул, компьютер, телефон, принимаем на работу девушку с приятным голосом. И вот call-центр готов». Однако не все так просто. Существует как минимум два вопроса, которым требуется уделить особое внимание: какими качествами должен обладать оператор и где расположить его рабочее место.
Приятный голос – это далеко не самое главное, чем должен обладать человек, работающий на первой линии поддержки Service Desk. Стрессоустойчивость гораздо важнее для оператора, который в течение одного рабочего дня может несколько десятков раз слышать одну и ту же фразу: «У меня не работает компьютер!» — и при этом обязан всегда одинаково невозмутимо и доброжелательно выяснять у пользователя, что же действительно сломалось. Кроме того, сотрудник первой линии поддержки должен хорошо владеть русским языком. Грубые грамматические и синтаксические ошибки, допущенные оператором при регистрации обращения пользователя, могут неблагоприятно отразиться на понимании сути заявки другими специалистами. Наконец, оператор call-центра должен обладать общими ИТ-знаниями. Комментарии здесь излишни. Очевидно, что оператор, услышав слово «винчестер», должен представлять себе устройство долговременного хранения информации, а не огнестрельное оружие.
Практика показывает, что нахождение первой и третьей линий поддержки в одном помещении крайне негативно сказывается на результатах работы высококвалифицированных специалистов. Резко снижается эффективность системных администраторов. Количество ошибок в программном коде у программистов возрастает в несколько раз! Этот факт обусловлен тем, что сотрудники, работающие на третьей линии поддержки, решают, как правило, нетривиальные задачи, требующие высокой степени сосредоточенности. А как можно сосредоточиться, если рядом каждые десять минут звонит телефон, и оператор отвечает: «Добрый день, отдел ИТ слушает»?
Совсем другая обстановка возникает, если расположить рабочее место оператора call-центра рядом с рабочими местами сотрудников второй линии поддержки. Решение задач второй линии поддержки не требует особой сосредоточенности и, следовательно, общение оператора с пользователями не будет сильно их отвлекать. В то же время тесное общение специалистов первой линии поддержки с сотрудниками второй линии может дать положительные результаты: через некоторое время часть проблем, которые ранее решались на второй линии, смогут устраняться уже на первой. Этим можно улучшить один из главных показателей эффективности Service Desk – сократить среднее время решения проблем.
Шаг четвертый
Когда принципы функционирования службы Service Desk описаны (подготовлена документация), сотрудники знают и понимают основы ITIL/ITSM и определено рабочее место операторов call-центра, стоит задуматься об инструментарии. Для того чтобы контролировать процесс приема и обработки обращений пользователей, необходимо специализированное программное обеспечение. Наиболее распространенным инструментом сегодня является HP OpenView ServiceDesk. Но многие компании не имеют средств на приобретение такого программного обеспечения, да и нужен ли на стартовом этапе инструмент такого высокого уровня? Скорее всего, нет, так как сначала требуется наладить сам процесс приема и обработки обращений пользователей.
Если в штате ИТ-департамента есть хотя бы один программист, то задача построения собственной системы приема и обработки обращений пользователей решается сама собой. Любой программист менее чем за месяц может создать базу данных и подготовить генерацию стандартных отчетов. Если же программиста нет, то можно пойти еще более простым путем: достаточно зайти на сайт http://www.helpdesk.com, где хранится огромный список ссылок на различного рода программное обеспечение для поддержки служб Help Desk, Service Desk и call-центров. Потратив немного времени, можно найти бесплатный и вполне достаточный по набору функций инструментарий. Если и этот вариант не устраивает по каким-либо причинам, то можно, наконец, использовать «подручные» средства – Microsoft Excel и Access. Потратив несколько часов рабочего времени, можно создать свой собственный уникальный инструмент для службы Service Desk.
Первые результаты
Теперь все готово для запуска в работу новой службы Service Desk. Конечно, нужно не забыть оповестить всех пользователей о новой услуге, сообщить единый телефонный номер отдела ИТ, по которому пользователи могут обратиться с любым вопросом.
Каких же результатов стоит ожидать? Если в первый день работы службы на телефон call-центра поступит более одного звонка от пользователей – это достижение. Если в первый месяц работы хотя бы один сотрудник компании скажет, что ему стало удобнее общаться с ИТ-департаментом, – это победа.
Можно выделить две основные проблемы, с которыми придется столкнуться в первое время работы службы Service Desk. Первая заключается в том, что большинство пользователей в первые месяцы будут продолжать «по старинке» звонить системным администраторам, программистам и т. д. Но если система мотивации сотрудников ИТ была выстроена достаточно грамотно и был проведен тренинг по основам ITIL, то об этом можно не беспокоиться. ИТ-руководитель не будет тратить массу своего времени на разъяснительные беседы с пользователями о полезности службы Service Desk. Системный администратор, которому в очередной раз позвонит пользователь, сам объяснит, куда и к кому надо обращаться с вопросами. Причем он найдет такие аргументы, о которых ни один ИТ-менеджер даже не догадывается. Такой путь — приучить пользователей звонить по одному определенному номеру —максимально эффективен.
Известно много случаев, когда руководители ИТ-служб пытались переучить сотрудников предприятия иными способами: воздействуя на пользователей через высшее руководство, меняя внутренние номера телефонов сотрудников ИТ-департамента, проводя массовую разъяснительную работу с пользователями. Но все эти варианты неэффективны и приводят, как правило, к длительному времени адаптации пользователей к работе в новых условиях. Нежелание пользователей взаимодействовать с ИТ-департаментом через единую точку контактов можно преодолеть только с помощью самих сотрудников отдела ИТ.
Вторая проблема, с которой придется столкнуться, – увеличение среднего времени обработки одного инцидента. Это плата за те статистические данные по обращениям, которые получит менеджер уже после первого месяца работы службы Service Desk. Увеличение времени решения инцидента, безусловно, будет заметно для пользователей, и именно с этим будут связаны основные негативные эмоции сотрудников предприятия. Ничего особенного в этом нет: служба только-только начала работать, процесс управления инцидентами еще слабо настроен, и сотрудники ИТ не привыкли действовать по новой схеме. Но уже через месяц после запуска Service Desk можно получить данные, из анализа которых видно, где в процессе слабое место, что и как нужно исправить, кто мешает нормальному ходу процесса. Начнется бесконечная настройка и модернизация службы Service Desk. В зависимости от скорости реагирования на выявленные проблемы и неточности в функционировании службы будет сокращаться среднее время решения инцидентов, повышаться удовлетворенность пользователей и т. д.
Пути развития
После того как служба Service Desk начала стабильно работать и прошел период адаптации, после того как улягутся первые страсти пользователей, можно задуматься о том, в каком направлении развиваться дальше. Путей много. Самым очевидным из них является повышение компетенции первой линии поддержки. Сразу после запуска службы первая линия (операторы call-центра) сможет закрывать максимум 20-30% всех регистрируемых инцидентов. Этот результат весьма хорош. Но совершенству нет предела. Развивая компетенцию операторов, обучая их, добавляя им дополнительные права и обязанности, можно повысить процент инцидентов, закрываемых на первой линии поддержки. В этом случае специалисты второй и третьей линий в большей степени смогут посвятить себя сложным и нетривиальным задачам. Второй эффект от увеличения числа инцидентов, закрываемых операторами, проявится в большей удовлетворенности пользователей работой департамента ИТ: та часть вопросов, которая ранее решалась, к примеру, в течение двух-трех часов (время реакции второй линии поддержки), теперь будет решаться за 10-20 минут.
Дальнейшее развитие службы Service Desk может выражаться в замене того «бесплатного» инструмента регистрации и обработки запросов пользователей, который использовался в первое время работы, на более функциональный, специализированный. Новый инструмент может предоставить более детальную информацию о работе Service Desk, и тогда появится возможность проводить более тонкую настройку процесса управления инцидентами. При этом пользователи также получат дополнительные услуги, к примеру, автоматическое оповещение по электронной почте о решении инцидента. После того, как проявятся реальные положительные результаты работы службы Service Desk (а они проявятся обязательно), доказывать высшему руководству компании необходимость приобретения специализированного программного обеспечения будет намного проще. Не исключен даже вариант, когда руководство компании само предложит помощь и средства на развитие процесса обработки запросов пользователей.
Без рисков не обойтись
Конечно, при самостоятельном выстраивании процессного подхода в управлении ИТ-инфраструктурой не исключены риски, связанные с принятием ошибочных решений, что может нарушить сроки построения и настройки процесса управления инцидентами. Эти риски значительно снижаются, если воспользоваться услугами квалифицированных и опытных консультантов. Но какой бы путь вы ни избрали, стоит помнить: основой для любого процесса ITIL является информация, которую можно получить только имея грамотно построенную и работающую службу Service Desk. И именно с построения этой службы следует начинать работу по эффективному управлению ИТ-инфраструктурой предприятия.
Денис Бобров, заместитель руководителя ИТ-департамента ЗАО «Талосто», Bobrov_DA@talosto.ru
http://www.osp.ru
Читать далее...
понедельник, 19 декабря 2011 г.
Тест Лимончелли
32 краеугольных принципа хорошей команды системного администрирования http://www.n-ix.com/ipesin/translations/other/32LimoncelliTest.html
Читать далее...
Читать далее...
четверг, 10 ноября 2011 г.
WiFi адаптер на Asus P5G41T-M LX3
Установка и настройка WiFi адаптера Asus USB-N13 на материнку Asus P5G41T-M LX3, ОС Fedora 13
Обновляем Kernel до последней версии:
yum update kernel
Смотрим версию ядра:
uname -a
Устанавливаем драйверы на адаптер беспроводной сети, в частности для Asus USB-N13 (может, конает и для других, хз):
yum install kmod-rt3070 (если ядро, к примеру kernel-2.6.34.9-69.fc13.i686)
либо же
yum install kmod-rt3070-PAE (если ядро kernel-2.6.34.9-69.fc13.i686.PAE)
А вообще, делаем yum search kmod и смотрим доступные пакеты и выбираем тот, который соответствует по версии установленному ядру kernel.
Ну а дальше адаптер после ребута нормально определяется в NetworkManager.
P.S. Сеть ethernet на Fedora 13 и Fedora 14 не определяется автоматом, возможно нужны танцы с бубном для установки дров на сетевуху. Сеть автоматом определилась только в Fedora 15
Читать далее...
Обновляем Kernel до последней версии:
yum update kernel
Смотрим версию ядра:
uname -a
Устанавливаем драйверы на адаптер беспроводной сети, в частности для Asus USB-N13 (может, конает и для других, хз):
yum install kmod-rt3070 (если ядро, к примеру kernel-2.6.34.9-69.fc13.i686)
либо же
yum install kmod-rt3070-PAE (если ядро kernel-2.6.34.9-69.fc13.i686.PAE)
А вообще, делаем yum search kmod и смотрим доступные пакеты и выбираем тот, который соответствует по версии установленному ядру kernel.
Ну а дальше адаптер после ребута нормально определяется в NetworkManager.
P.S. Сеть ethernet на Fedora 13 и Fedora 14 не определяется автоматом, возможно нужны танцы с бубном для установки дров на сетевуху. Сеть автоматом определилась только в Fedora 15
Читать далее...
четверг, 3 ноября 2011 г.
SAMBA и SELINUX
Confining Samba with SELinux (in Russian)En: As Dan Walsh wrote he started updating the man pages for different confined domains. So, I will update Russian version because now in Fedora 8, Russian man pages are still based on old version of man pages.
Ru: Страницы руководств по сконфигурированным (для которых существует политика SELinux) доменам не обновлялись с 2005 года. Недавно Dan Walsh начал переписывать ряд руководств, приводя описание к современному состоянию политик. Обновленная страница samba_selinux уже в Fedora 7/8. Перевод же в дистрибутиве пока не доступен (точнее, там мой старый перевод на основе старого же оригинала). Новый:
$ man samba_selinux
samba_selinux(8) Samba Selinux Policy documentation samba_selinux(8)
НАЗВАНИЕ
samba_selinux - Защита Samba при помощи SELinux
ОПИСАНИЕ
Security-Enhanced Linux обеспечивает защиту сервера Samba при помощи гибко настраиваемого мандатного контроля доступа. По умолчанию политика SELinux для Samba использует принцип наименьших привилегий. Для настройки того, как SELinux работает с Samba, существует ряд переключателей (booleans) и контекстов файлов.
ОБЩИЙ ДОСТУП К ФАЙЛАМ
SELinux требует наличия у файлов расширенных атрибутов, определяющих тип файла. Политика управляет видом доступа демона к этим файлам. Когда вы предоставляете общий доступ к файлам, у вас есть несколько вариантов как пометить файлы. Если вы хотите предоставить общий доступ к файлам/директориям за пределами домашних или стандартных директорий, этим файлам/директориям необходимо присвоить контекст samba_share_t. Например, при создании специальной директории /var/eng, необходимо установить контекст для этой директории при помощи утилиты chcon.
# chcon -R -t samba_share_t /var/eng
Однако назначенные таким образом метки не сохранятся при выполнении операции обновления меток. Наилучшее решение - сделать эти изменения постоянными. Для этого требуется рассказать системе SELinux об этих изменениях. Команда semanage может изменить назначенный по умолчанию контекст файлов на вашей машине. А команда restorecon прочтет файл file_context и установит описанные контексты для файлов и директорий..
# semange fcontext -a -t samba_share_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng
ОБЩИЙ ДОСТУП К ДОМАШНИМ ДИРЕКТОРИЯМ
По умолчанию политика SELinux запрещает удаленный доступ к домашним директориям. Если вы настроили эту машину как сервер Samba и желаете предоставить доступ к домашним директориям, вы должны установить переключатель samba_enable_home_dirs.
# setsebool -P samba_enable_home_dirs 1
СОВМЕСТНОЕ ВЛАДЕНИЕ ФАЙЛАМИ
Если вы хотите организовать между несколькими доменами (Apache, FTP, rsync, Samba) совместный доступ к файлам, то вы можете установить контекст файлов в public_content_t и public_content_rw_t. Данный контекст позволяет любому из выше перечисленных демонов читать содержимое. Если вы хотите, чтобы конкретный домен имел право записи в домен public_content_rw_t, вы должны установить соответствующий переключатель allow_ДОМЕН_anon_write. Таким образом, для samba вы должны выполнить:
# semange fcontext -a -t public_content_rw_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng
# setsebool -P allow_smbd_anon_write 1
ОБЩИЙ ДОСТУП К СИСТЕМНЫМ ФАЙЛАМ
Замечание: Вы не должны применять действия, описанные выше, к стандартным или домашним директориям! Например, директориям, принадлежащим RPM. Если вы хотите сделать /usr доступным через Samba, то изменение контекста этой директории и всех поддиректорий на samba_share_t - плохая идея. Дело в том, что другие сконфигурированные домены не смогут получить доступ на чтение к /usr, что может вызвать катастрофические последствия для машины. Для предоставления общего доступа к стандартным директориям существуют два переключателя (booleans). Если вы хотите предоставить общий доступ только на чтение к любой стандартной директории, вы можете установить переключатель samba_export_all_ro.
# setsebool -P samba_export_all_ro 1
Данный переключатель позволяет Samba прочесть каждый файл в системе. Аналогично, если вы хотите предоставить общий доступ Samba ко всем файлам и директориям в системе, установите samba_export_all_rw
# setsebool -P samba_export_all_rw 1
Этот переключатель позволяет Samba читать и писать каждый файл в вашей системе. Таким образом, в случае компрометации Samba серверу может угрожать серьезная опасность.
ОБЩИЙ ДОСТУП К NFS ФАЙЛАМ
По умолчанию политика SELinux запрещает демонам Samba чтение/запись nfs ресурсов. Если вы используете Samba для предоставления общего доступа к файловым системам NFS, то вам нужно включить переключатель samba_share_nfs
# setsebool -P samba_share_nfs 1
ИСПОЛЬЗОВАНИЕ CIFS/SAMBA ДЛЯ РАЗМЕЩЕНИЯ ДОМАШНИХ ДИРЕКТОРИЙ
Политика SELinux для Samba запрещает любому сконфигурированному приложению доступ к удаленным samba-ресурсам, смонтированным на вашей машине. Если вы хотите использовать удаленный сервер Samba для хранения домашних директорий вашей машины, то необходимо установить переключатель use_samba_home_dirs.
# setsebool -P use_samba_home_dirs 1
СКРИПТЫ SAMBA
Samba можно настроить для исполнения пользовательских скриптов. По умолчанию если вы инсталлируете такие скрипты в /var/lib/samba/scripts, то они будут помечены как samba_unconfined_script_exec_t. Так как эти скрипты могут использоваться для различных действий в системе, вы можете запускать их как несконфигурированные. Но при этом вам необходимо включить переключатель samba_run_unconfined
# setsebool -P samba_run_unconfined 1
Если вы пишете собственную политику, в файле samba.if описан интерфейс, называемый samba_helper_template(APP). Этот интерфейс создает файловый контекст samba_APP_script_exec_t, и домен samba_APP_script_t. Samba запускает скрипт, помеченный samba_app_script_exec_t, в домене samba_APP_script_t. Далее при помощи audit2allow вы можете создать политику для своего скрипта.
ИСПОЛЬЗОВАНИЕ SAMBA В КАЧЕСТВЕ КОНТРОЛЛЕРА ДОМЕНА
Если вы хотите использовать samba как контроллер домена, то есть добавить машины в файл passwd на сервере под управлением Linux, вам нужно включить переключатель samba_domain_controller. Это позволит демону Samba запускать и осуществлять переход в домены утилит passwd, useradd и groupadd. Данные утилиты предназначены для манипуляций базой данных passwd.
УТИЛИТА С ГРАФИЧЕСКИМ ИНТЕРФЕЙСОМ system-config-selinux
Для управления всеми описанными выше контекстами файлов и переключателями SELinux можно использовать утилиту с графическим интерфейсом system-config-selinux.
АВТОРЫ
Эту страницу руководства написал Dan Walsh.
Перевод руководства - Андрей Маркелов, 2007г.
СМОТРИ ТАКЖЕ
selinux(8), semanage(8), samba(7), chcon(1), setsebool(8), restorecon(8),
dwalsh at redhat com 9 Ноября 2007 samba_selinux(8)
(c)
Читать далее...
Ru: Страницы руководств по сконфигурированным (для которых существует политика SELinux) доменам не обновлялись с 2005 года. Недавно Dan Walsh начал переписывать ряд руководств, приводя описание к современному состоянию политик. Обновленная страница samba_selinux уже в Fedora 7/8. Перевод же в дистрибутиве пока не доступен (точнее, там мой старый перевод на основе старого же оригинала). Новый:
$ man samba_selinux
samba_selinux(8) Samba Selinux Policy documentation samba_selinux(8)
НАЗВАНИЕ
samba_selinux - Защита Samba при помощи SELinux
ОПИСАНИЕ
Security-Enhanced Linux обеспечивает защиту сервера Samba при помощи гибко настраиваемого мандатного контроля доступа. По умолчанию политика SELinux для Samba использует принцип наименьших привилегий. Для настройки того, как SELinux работает с Samba, существует ряд переключателей (booleans) и контекстов файлов.
ОБЩИЙ ДОСТУП К ФАЙЛАМ
SELinux требует наличия у файлов расширенных атрибутов, определяющих тип файла. Политика управляет видом доступа демона к этим файлам. Когда вы предоставляете общий доступ к файлам, у вас есть несколько вариантов как пометить файлы. Если вы хотите предоставить общий доступ к файлам/директориям за пределами домашних или стандартных директорий, этим файлам/директориям необходимо присвоить контекст samba_share_t. Например, при создании специальной директории /var/eng, необходимо установить контекст для этой директории при помощи утилиты chcon.
# chcon -R -t samba_share_t /var/eng
Однако назначенные таким образом метки не сохранятся при выполнении операции обновления меток. Наилучшее решение - сделать эти изменения постоянными. Для этого требуется рассказать системе SELinux об этих изменениях. Команда semanage может изменить назначенный по умолчанию контекст файлов на вашей машине. А команда restorecon прочтет файл file_context и установит описанные контексты для файлов и директорий..
# semange fcontext -a -t samba_share_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng
ОБЩИЙ ДОСТУП К ДОМАШНИМ ДИРЕКТОРИЯМ
По умолчанию политика SELinux запрещает удаленный доступ к домашним директориям. Если вы настроили эту машину как сервер Samba и желаете предоставить доступ к домашним директориям, вы должны установить переключатель samba_enable_home_dirs.
# setsebool -P samba_enable_home_dirs 1
СОВМЕСТНОЕ ВЛАДЕНИЕ ФАЙЛАМИ
Если вы хотите организовать между несколькими доменами (Apache, FTP, rsync, Samba) совместный доступ к файлам, то вы можете установить контекст файлов в public_content_t и public_content_rw_t. Данный контекст позволяет любому из выше перечисленных демонов читать содержимое. Если вы хотите, чтобы конкретный домен имел право записи в домен public_content_rw_t, вы должны установить соответствующий переключатель allow_ДОМЕН_anon_write. Таким образом, для samba вы должны выполнить:
# semange fcontext -a -t public_content_rw_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng
# setsebool -P allow_smbd_anon_write 1
ОБЩИЙ ДОСТУП К СИСТЕМНЫМ ФАЙЛАМ
Замечание: Вы не должны применять действия, описанные выше, к стандартным или домашним директориям! Например, директориям, принадлежащим RPM. Если вы хотите сделать /usr доступным через Samba, то изменение контекста этой директории и всех поддиректорий на samba_share_t - плохая идея. Дело в том, что другие сконфигурированные домены не смогут получить доступ на чтение к /usr, что может вызвать катастрофические последствия для машины. Для предоставления общего доступа к стандартным директориям существуют два переключателя (booleans). Если вы хотите предоставить общий доступ только на чтение к любой стандартной директории, вы можете установить переключатель samba_export_all_ro.
# setsebool -P samba_export_all_ro 1
Данный переключатель позволяет Samba прочесть каждый файл в системе. Аналогично, если вы хотите предоставить общий доступ Samba ко всем файлам и директориям в системе, установите samba_export_all_rw
# setsebool -P samba_export_all_rw 1
Этот переключатель позволяет Samba читать и писать каждый файл в вашей системе. Таким образом, в случае компрометации Samba серверу может угрожать серьезная опасность.
ОБЩИЙ ДОСТУП К NFS ФАЙЛАМ
По умолчанию политика SELinux запрещает демонам Samba чтение/запись nfs ресурсов. Если вы используете Samba для предоставления общего доступа к файловым системам NFS, то вам нужно включить переключатель samba_share_nfs
# setsebool -P samba_share_nfs 1
ИСПОЛЬЗОВАНИЕ CIFS/SAMBA ДЛЯ РАЗМЕЩЕНИЯ ДОМАШНИХ ДИРЕКТОРИЙ
Политика SELinux для Samba запрещает любому сконфигурированному приложению доступ к удаленным samba-ресурсам, смонтированным на вашей машине. Если вы хотите использовать удаленный сервер Samba для хранения домашних директорий вашей машины, то необходимо установить переключатель use_samba_home_dirs.
# setsebool -P use_samba_home_dirs 1
СКРИПТЫ SAMBA
Samba можно настроить для исполнения пользовательских скриптов. По умолчанию если вы инсталлируете такие скрипты в /var/lib/samba/scripts, то они будут помечены как samba_unconfined_script_exec_t. Так как эти скрипты могут использоваться для различных действий в системе, вы можете запускать их как несконфигурированные. Но при этом вам необходимо включить переключатель samba_run_unconfined
# setsebool -P samba_run_unconfined 1
Если вы пишете собственную политику, в файле samba.if описан интерфейс, называемый samba_helper_template(APP). Этот интерфейс создает файловый контекст samba_APP_script_exec_t, и домен samba_APP_script_t. Samba запускает скрипт, помеченный samba_app_script_exec_t, в домене samba_APP_script_t. Далее при помощи audit2allow вы можете создать политику для своего скрипта.
ИСПОЛЬЗОВАНИЕ SAMBA В КАЧЕСТВЕ КОНТРОЛЛЕРА ДОМЕНА
Если вы хотите использовать samba как контроллер домена, то есть добавить машины в файл passwd на сервере под управлением Linux, вам нужно включить переключатель samba_domain_controller. Это позволит демону Samba запускать и осуществлять переход в домены утилит passwd, useradd и groupadd. Данные утилиты предназначены для манипуляций базой данных passwd.
УТИЛИТА С ГРАФИЧЕСКИМ ИНТЕРФЕЙСОМ system-config-selinux
Для управления всеми описанными выше контекстами файлов и переключателями SELinux можно использовать утилиту с графическим интерфейсом system-config-selinux.
АВТОРЫ
Эту страницу руководства написал Dan Walsh.
Перевод руководства - Андрей Маркелов, 2007г.
СМОТРИ ТАКЖЕ
selinux(8), semanage(8), samba(7), chcon(1), setsebool(8), restorecon(8),
dwalsh at redhat com 9 Ноября 2007 samba_selinux(8)
(c)
Читать далее...
Настройка SELinux для SAMBA
Confining Samba with SELinux My next few blogs will be taking different confined domains and writing about the types and booleans related to that domain, I will be updating the man pages for these confined domains. And then showing how the policy for the domain works.
samba has had a man page available for some time named samba_selinux, here is my rewrite for Fedora 7/8
> man samba_selinux
samba_selinux(8) Samba Selinux Policy documentation samba_selinux(8)
NAME
samba_selinux - Securing Samba with SELinux
DESCRIPTION
Security-Enhanced Linux secures the Samba server via flexible mandatory access control. SELinux Samba policy defaults to least privilege access. Several Booleans and file contexts are available to customize the way Samba SELinux works.
SHARING FILES
SELinux requires files be labeled with an extended attribute to define the file type. Policy governs the access daemons have to these files. When sharing files with Samba you have many options on how to label the files. If you want to share files/directories other than home directories or standard directory. You should label these files/directories as samba_share_t. For example if you created the directory /var/eng, you can label the directory and its contents with the chcon tool.
# chcon -R -t samba_share_t /var/eng
This label will not survive a relabel. A better solution to make the change permanent, you must tell the SELinux system about the label customization. The semanage command can customize the default file contexts on your machine. restorecon will read the file_context and apply it to the files and directories..
# semanage fcontext -a -t samba_share_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng
SHARING HOME DIRECTORIES
By default SELinux policy turns off SELinux sharing of home directories If you are setting up this machine as a Samba server and wish to share the home directories, you need to set the samba_enable_home_dirs boolean.
# setsebool -P samba_enable_home_dirs 1
SHARING PUBLIC FILES
If you want to share files with multiple domains (Apache, FTP, rsync, Samba), you can set a file context of public_content_t and public_content_rw_t. These context allow any of the above domains to read
the content. If you want a particular domain to write to the public_content_rw_t domain, you must set the appropriate boolean. allow_DOMAIN_anon_write. So for samba you would execute:
# semanage fcontext -a -t public_content_rw_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng
# setsebool -P allow_smbd_anon_write 1
SHARING FILES SYSTEM FILES
Note: You should not do the above for standard directories or home directories! For example directories owned by an RPM. If you wanted to share /usr via Samba, changing its context and all of the sub directories to samba_share_t would be a bad idea. Other confined domains would no longer be able to read /usr and this would cause havoc on the machine. There are two booleans that you can set to allow the sharing of standard directories. If you want to share any standard directory read/only you can set the boolean samba_export_all_ro.
# setsebool -P samba_export_all_ro 1
This boolean will allow Samba to read every file on the system.Similarly if you want to share all files and directories via Samba, you set the samba_export_all_rw
# setsebool -P samba_export_all_rw 1
This boolean would allow Samba to read and write every file on your system. So a compromised Samba server would be very dangerous.
SHARING PUBLIC NFS FILES
SELinux prevents the Samba daemons from reading/writing nfs shares by default. If you are using samba to share NFS file systems you need to turn on the samba_share_nfs boolean
# setsebool -P samba_share_nfs 1
USING CIFS/SAMBA HOME DIRECTORIES
Samba SELinux policy will not allow any confined applications to access remote samba shares mounted on your machine. If you want to use a remote Samba server for the home directories on this machine, you must set the use_samba_home_dirs boolean.
# setsebool -P use_samba_home_dirs 1
SAMBA Scripts
Samba can be setup to run user defined scripts, by default if you install these scripts /var/lib/samba/scripts they will be labeled samba_unconfined_script_exec_t. Since these scripts can do just about anything on the system you can run them as unconfined. But you need to turn on the samba_run_unconfined boolean
# setsebool -P samba_run_unconfined 1
If you are willing to write policy an interface exists in samba.if called samba_helper_template(APP). This interface will create a file context of samba_APP_script_exec_t, and a domain of samba_APP_script_t. Samba will transition scripts labeled samba_app_script_exec_t to samba_APP_script_t, you can then user audit2allow to write policy to confine your script.
USING SAMBA AS A DOMAIN CONTROLLER
If you want to run samba as a domain controller, IE Add machines to the passwd file on a Linux box, you need to turn on the samba_domain_controller boolean. This allows the Samba daemon to run and transition to the passwd, useradd, and groupadd utilities. These tools can manipulate the passwd database.
GUI system-config-selinux
system-config-selinux is a GUI tool available to customize all of the SELinux booleans and file context described above.
AUTHOR
This manual page was written by Dan Walsh.
SEE ALSO
selinux(8), semanage(8), samba(7), chcon(1), setsebool(8), restorecon(8),
dwalsh@redhat.com 9 Nov 2007 samba_selinux(8)
(с)
Читать далее...
samba has had a man page available for some time named samba_selinux, here is my rewrite for Fedora 7/8
> man samba_selinux
samba_selinux(8) Samba Selinux Policy documentation samba_selinux(8)
NAME
samba_selinux - Securing Samba with SELinux
DESCRIPTION
Security-Enhanced Linux secures the Samba server via flexible mandatory access control. SELinux Samba policy defaults to least privilege access. Several Booleans and file contexts are available to customize the way Samba SELinux works.
SHARING FILES
SELinux requires files be labeled with an extended attribute to define the file type. Policy governs the access daemons have to these files. When sharing files with Samba you have many options on how to label the files. If you want to share files/directories other than home directories or standard directory. You should label these files/directories as samba_share_t. For example if you created the directory /var/eng, you can label the directory and its contents with the chcon tool.
# chcon -R -t samba_share_t /var/eng
This label will not survive a relabel. A better solution to make the change permanent, you must tell the SELinux system about the label customization. The semanage command can customize the default file contexts on your machine. restorecon will read the file_context and apply it to the files and directories..
# semanage fcontext -a -t samba_share_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng
SHARING HOME DIRECTORIES
By default SELinux policy turns off SELinux sharing of home directories If you are setting up this machine as a Samba server and wish to share the home directories, you need to set the samba_enable_home_dirs boolean.
# setsebool -P samba_enable_home_dirs 1
SHARING PUBLIC FILES
If you want to share files with multiple domains (Apache, FTP, rsync, Samba), you can set a file context of public_content_t and public_content_rw_t. These context allow any of the above domains to read
the content. If you want a particular domain to write to the public_content_rw_t domain, you must set the appropriate boolean. allow_DOMAIN_anon_write. So for samba you would execute:
# semanage fcontext -a -t public_content_rw_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng
# setsebool -P allow_smbd_anon_write 1
SHARING FILES SYSTEM FILES
Note: You should not do the above for standard directories or home directories! For example directories owned by an RPM. If you wanted to share /usr via Samba, changing its context and all of the sub directories to samba_share_t would be a bad idea. Other confined domains would no longer be able to read /usr and this would cause havoc on the machine. There are two booleans that you can set to allow the sharing of standard directories. If you want to share any standard directory read/only you can set the boolean samba_export_all_ro.
# setsebool -P samba_export_all_ro 1
This boolean will allow Samba to read every file on the system.Similarly if you want to share all files and directories via Samba, you set the samba_export_all_rw
# setsebool -P samba_export_all_rw 1
This boolean would allow Samba to read and write every file on your system. So a compromised Samba server would be very dangerous.
SHARING PUBLIC NFS FILES
SELinux prevents the Samba daemons from reading/writing nfs shares by default. If you are using samba to share NFS file systems you need to turn on the samba_share_nfs boolean
# setsebool -P samba_share_nfs 1
USING CIFS/SAMBA HOME DIRECTORIES
Samba SELinux policy will not allow any confined applications to access remote samba shares mounted on your machine. If you want to use a remote Samba server for the home directories on this machine, you must set the use_samba_home_dirs boolean.
# setsebool -P use_samba_home_dirs 1
SAMBA Scripts
Samba can be setup to run user defined scripts, by default if you install these scripts /var/lib/samba/scripts they will be labeled samba_unconfined_script_exec_t. Since these scripts can do just about anything on the system you can run them as unconfined. But you need to turn on the samba_run_unconfined boolean
# setsebool -P samba_run_unconfined 1
If you are willing to write policy an interface exists in samba.if called samba_helper_template(APP). This interface will create a file context of samba_APP_script_exec_t, and a domain of samba_APP_script_t. Samba will transition scripts labeled samba_app_script_exec_t to samba_APP_script_t, you can then user audit2allow to write policy to confine your script.
USING SAMBA AS A DOMAIN CONTROLLER
If you want to run samba as a domain controller, IE Add machines to the passwd file on a Linux box, you need to turn on the samba_domain_controller boolean. This allows the Samba daemon to run and transition to the passwd, useradd, and groupadd utilities. These tools can manipulate the passwd database.
GUI system-config-selinux
system-config-selinux is a GUI tool available to customize all of the SELinux booleans and file context described above.
AUTHOR
This manual page was written by Dan Walsh
SEE ALSO
selinux(8), semanage(8), samba(7), chcon(1), setsebool(8), restorecon(8),
dwalsh@redhat.com 9 Nov 2007 samba_selinux(8)
(с)
Читать далее...
среда, 26 октября 2011 г.
Тонкая настройка Gnome (мануал, en)
GNOME Display Manager Reference Manual http://library.gnome.org/admin/gdm/stable/configuration.html.en
Читать далее...
Читать далее...
Подписаться на:
Сообщения (Atom)
