Наболевшее

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

В целом я согласен с автором сего повествования.

Есть хорошая книга - "Мужчины с Марса, Женщины с Венеры", где автор Джон Грэй советует парам для улучшения своих отношений признать и принять различия между мужчинами и женщинами. Он утверждает, что мужчины и женщины так же отличаются друг от друга, как существа с разных планет. Если понять эти различия, общаться станет гораздо проще. Аналогично в ИТ - мы должны признать, что существуют значительные различия между специалистами по ИТ и непосредственными руководителями (в данном конкретном случае), хотя, казалось бы, и я, и непосредственный руководитель заинтересованы в ИТ. Нам нужно научиться лучше понимать друг друга, чтобы достичь этой цели. Но всегда ли это получается на практике?

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

         Поэтому и говорят так: о начальстве или хорошо или вообще ничего не говорят.

И я выскажу, почему я не хочу тут работать:

Я "увешан" должностями, функционалом и обязанностями:

1. Начальник отдела сопровождения информационных технологий (в непосредственном подчинении четыре системных администратора)

2. Главный администратор по информационной безопасности

3. Руководитель дежурной службы

4. Выполняю функции системного администратора, при необходимости - функции help-desk.

5. Администратор почтовой системы Exchange 2010, администратор домена, Wsus, антивирусной системы, терминального сервера, баз данных (MS SQL), прокси серверов (FreeBSD), Vmware

6. Оказываю техническую и консультационную поддержку системным администраторам филиалов и операционных офисов

                Если еще вспомнить, получится очень неслабый список.

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

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

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

Я лишился эмоций. У нас не принято завидовать и радоваться. Т.е. все это останется внутри меня, постепенно угасая, но я перестаю показывать это все на своем лице. Скука — это моя новая маска.

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

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

Я научился не слушать людей, которые говорят со мной. Большинство опытных офисных работников на совещании, как только с ними начинают говорить, утыкаются в смартфон, начинают болтать и т.д. Я научился постоянно проверять почту и верить в то, что я ОЧЕНЬ заняты и от меня ОЧЕНЬ многое зависит.

Я провожу на работе по 9-12 часов. Но работаю я или нет…. Я научился убеждать себя, что я делаю нужную работу, что я перегружен и все это замечают. Главное не вызвать подозрение, что у меня есть что-то еще в жизни и работа — только средство достижения.

Я боготворю пятницу. Для частного предпринимателя пятница — это ужас, бизнес перестает работать на 2 дня. Для меня же — это лучший день в неделе —забыть о работе на два дня.

Я станете кофеиново (чайно)-зависимым и полюбил туалеты. Кофе (чай) утром, кофе (чай) перед полудником, кофе (чай) перед обедом, кофе (чай) после обеда, кофе (чай) до 5 o’clock tea, кофе (чай) перед выходом домой. Если я курю, то сюда следует добавить столько раз кофе, сколько раз курю. Туалеты спасают, когда пить кофе просто не хочется. Если бы там была курилка, то там бы был главный штаб, переговорка, митинг-рум.

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

И так далее и прочее-прочее. Список может быть бесконечно длинным....

Читать далее ...

Service Desk. Как? Что? Куда? Зачем?

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

                 В результате чего появилось вот это.

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

1. Сколько это стоит?

Сегодня найдется немало компаний, которые могут помочь в построении службы Service Desk (ссылок давать не буду - гугл рулит). Квалифицированные консультанты оценят уровень зрелости процессов ITIL на предприятии, разработают для ИТ-отдела план по внедрению того или иного процесса, подберут и настроят оптимальный инструментарий. Однако услуги консультантов не бесплатны и зачастую достаточно дороги. А руководители компаний среднего и малого бизнеса, как правило, не считают ИТ-отдел стратегическим подразделением и, следовательно, неохотно инвестируют средства в ИТ-проекты. Возникает вопрос: как доказать руководству необходимость выделения средств на развертывание службы Service Desk?

Если не удалось с первого раза убедить высшее руководство предприятия в необходимости инвестиций (а как правило всегда так и бывает), то все последующие попытки также будут обречены на провал. Доказать инвестиционную привлекательность службы Service Desk практически невозможно, точно так же, как и рассчитать срок возврата инвестиций. Чтобы оценить экономический эффект, потребуются начальные данные, такие как среднее время разрешения одного инцидента, количество инцидентов в день, месяц, год и т. д. Но если в ИТ-отделе еще не работает служба Service Desk, то как узнать, какое время в среднем тратится на разрешение одного инцидента? Если нет статистики об обращениях пользователей, то где взять информацию о количестве инцидентов? Помимо этого, на практике в первые месяцы работы службы Service Desk время разрешения одного инцидента увеличивается. Сократить его удается не сразу. Следовательно, говорить о положительном экономическом эффекте в первые месяцы работы службы не приходится.

Итак, если не удается построить Service Desk на средства компании, то можно попробовать развернуть службу самостоятельно, без привлечения сторонних консультантов и затрат на специализированное ПО.

2. С чего начать?

Многие скажут, что начинать надо с оформления проекта. Однако в случае построения службы Service Desk подобный подход зачастую нереализуем. Какие цели проекта следует указать? Какие сроки поставить? Какие риски проекта описать? Практика организаций, в которых работает Service Desk, показывает, что создать идеальную службу невозможно. Она постоянно изменяется и совершенствуется. Поэтому с большой вероятностью описанные грандиозные цели проекта по созданию Service Desk утратят свою актуальность еще в процессе их достижения. А между тем, срок такого проекта может исчисляться месяцами, а то и годами! Так нужен ли такой проект? С другой стороны, работать без четко описанных целей также невозможно. Необходимо понимать, в каком направлении двигаться и что должно получиться в итоге.

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

Шаг I. Фиксируем и пишем регламенты.

Итак, пора переходить к реальным шагам, действиям. На первом этапе потребуются всего лишь лист бумаги и ручка. Создание 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-15 минут. Если проблему не удалось ликвидировать, она переводится на вторую линию поддержки, где на ее решение отводится два часа, после чего обращение переводится на третью линию поддержки. На третьей линии инцидент может решаться, например, пять часов. Если в течение и этого времени не удалось восстановить работоспособность, тогда проблема эскалируется на уровень ИТ-начальника. Существуют более точные, но в то же время и более сложные варианты расчета времени работы над инцидентом (приводить не буду).

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

            При определенном навыке оператор 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. Но многие компании не имеют средств на приобретение такого программного обеспечения, да и нужен ли на стартовом этапе инструмент такого высокого уровня? Скорее всего, нет, так как сначала требуется наладить сам процесс приема и обработки обращений пользователей.

       Если в штате ИТ-департамента есть хотя бы один программист, то задача построения собственной системы приема и обработки обращений пользователей решается сама собой. Любой программист менее чем за месяц может создать базу данных и подготовить генерацию стандартных отчетов. Если же программиста нет, то можно пойти еще более простым путем: достаточно зайти на сайт, где хранится огромный список ссылок на различного рода программное обеспечение для поддержки служб 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. И именно с построения этой службы следует начинать работу по эффективному управлению ИТ-инфраструктурой предприятия.

            Но это темя для другого разговора.

P.$ В чем-то конечно гипотетично, но можно принять к сведению отдельные моменты для работы или для саморазвития.

Читать далее ...

Конвертация толстых (thick) дисков в тонкие (thin) ESXi 5.1

Продолжаю мучать VMware

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

1. Подключаемся к ESXi серверу по SSH (SSH в ESXi 5).
2. Перейдем в папку /vmfs/volumes:
# cd /vmfs/volumes

3. Выведем список дисков:
# ls -lh

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

4. Перейдем в каталог виртуальной машины на втором хранилище:
# cd ......-datastore2/Win7

Выведем список всех файлов:
# ls -lh

Интересует  в моем случае это Win7.vmdk

5. Теперь сконвертируем диск:
# vmkfstools -i Win7.vmdk -d thin Win7-thin.vmdk

6. Удалим старый образ и заменим его новым.
# rm Win7.vmdk
# mv Win7-thin.vmdk Win7.vmdk

Готово! 

Теперь у нас появилось много свободного места! 

Читать далее ...

Решение проблемы медленной сетевой печати

Из сегодняшнего:

Круто тормозит печать на сетевой принтер. Болит голова - придумать ничего не получается толкового. Пришлось тревожить опять гугл и он (как и бывает в большинстве случаев) помог мне.

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

Но - всегда есть решение. Создаем .reg файл следующего содержания:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"NoNetCrawling"=dword:00000001

сохраняем его в доступном для всех пользователей месте , например \\server\netlogon\no_remote_printers.reg , там же создаем .bat файл следующего содержания (или добавляем к существующему логон-скрипту):

@echo off > nul

regedit /s \\server\netlogon\no_remote_printers.reg

Далее открываем Active Directory - пользователи и компьютеры\свойства домена\групповая политика\изменить\конфигурация пользователя\конфигурация Windows\сценарии\вход в систему, и добавляем туда путь к нашему батнику в виде file://server/netlogon/no_remote_printers.bat.

Читать далее ...

SSH в ESXi 5

Как известно, по умолчанию SSH в ESXi 5 отключен в целях безопасности. До недавнего времени я не знал как включить его.

Узнал, делюсь :) (правда это больше для меня самого, так сказать узелок на память).
Как оказалось, все достаточно просто. Подключаемся к нашему серверу (или к vCenter Server) с помощью vSphere Client-а, открываем свойства сервера и заходим во вкладку «Configuration»:

В разделе Software выбираем «Security Profile» и жамкаем  «Properties».Видим вот такое окошко:

Видим что SSH выключен, Remote Tech Support (SSH) -> Options:

Что бы включить SSH нажимаем «Start» и «OK» (здесь также можно подшаманить и изменить способ запуска службы SSH).После запуска SSH на вкладке Summary будет маячить такое предупреждение:

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

Читать далее ...

Настройка MS SQL Express для доступа из локальной сети

В процессе разворачивания одного специфичного ПО, потребовалась база данных под управлением СУБД MS SQL Express.

      Вроде бы все просто: создал базу, создал пользователя, вбил айпишник и радуйся….но мне пришлось все-таки немного потанцевать с бубном, т.к. ПО отказывалась принимать мой сервер БД.

               Перепроверил все права доступа, пароли, файерволлы и т.п. — все как бы гуд…через ODBC подключается и работает отлично, а при подключении ПО  — посылает лесом.

Проблема, как оказалось, в конфигурации портов MS SQL Server. Об этом мне сказал netstat.

Как я понял, по умолчанию, в MS SQL вместо статического порта 1433 указан диапазон динамических портов. Для чего это сделано, точно не скажу, военная тайна Microsoft.

Лечится это все дело быстро и безболезненно:
1. запускаем SQL Server Configuration Manager
2. открываем ветку SQL Server 2005 Network Configuration
3. заходим в Protocols -> TCP/IP (статус должен быть — Enabled)
4. правый клик по TCP/IP -> Properties
5. переходим на вкладку IP Addresses и опускаемся в самый низ
6. удаляем все что написано в поле TCP Dynamic Ports и оставляем поле пустым, а в TCP Port пишем 1433, что бы получилось вот так:

7. перезапускаем службы MS SQL Server

8. проверяем, что у нас получилось, с помощью команды netstat -an, среди всего прочего, там должно быть что-то такое:

Читать далее ...

VMware vCenter Converter Standalone 5.0: экстремально низкая скорость копирования

         Мигрирую Консультант + при помощи VMware vCenter Converter Standalone 5.0 и вижу что, копироваться жесткий диск размером в 60 Гбайт будет два дня!!!!  Это явно очень долго. Понимаю если бы машина была уж очень больших размеров, но тут она малюсенькая (образно говоря). Скорость передачи данных составляла 600КБ — 2МБ/сек, при пропускной способности сети — 1Gb.

Мне это мягко говоря не понравилось :)

Протестировав скорость сети и поняв, что не в сети дело, я сразу стал грешить на дисковую подсистему, но как оказалось это и не в дисках дело…

        Это софтверная проблема и связано напрямую с VMware vCenter Converter Standalone.   

Решилось просто: нужно отключить шифрования передаваемого трафика в настройках этого самого VMware vCenter Converter Standalone.

Как это сделать? 

Ищем файлик с чудесным названием converter-worker.xml и правим его с помощью Nitepad ++ ли любой другой редактор).

Найти этот файлик можно в таких местах: 

Windows 7, Windows Vista, Windows 2008 (R2) — C:\ProgramData\VMware\VMware vCenter Converter Standalone

Windows XP, Windows 2003, Windows 2000 — C:\Documents and Settings\All Users\Application Data\VMware\VMware vCenter Converter Standalone

Вот теперь в этом файлике ищем что-то такое: 

<nfc>

<readTimeoutMs>120000</readTimeoutMs>

<useSsl>true</useSsl>

<!-- Delay is specified in milliseconds, -1 denotes the default.

<acceptTimeoutMs>-1</acceptTimeoutMs>

<requestTimeoutMs>-1</requestTimeoutMs>

<readTimeoutMs>-1</readTimeoutMs>

<writeTimeoutMs>-1</writeTimeoutMs>

<fssrvrReqTimeoutMs>-1</fssrvrReqTimeoutMs>

<fssrvrWriteTimeoutMs>-1</fssrvrWriteTimeoutMs>

-->

</nfc>

И делаем из него что-то такое:

<nfc>

<readTimeoutMs>120000</readTimeoutMs>

<useSsl>false</useSsl>

<!-- Delay is specified in milliseconds, -1 denotes the default.

<acceptTimeoutMs>-1</acceptTimeoutMs>

<requestTimeoutMs>-1</requestTimeoutMs>

<readTimeoutMs>-1</readTimeoutMs>

<writeTimeoutMs>-1</writeTimeoutMs>

<fssrvrReqTimeoutMs>-1</fssrvrReqTimeoutMs>

<fssrvrWriteTimeoutMs>-1</fssrvrWriteTimeoutMs>

-->

</nfc>

Приглядевшись внимательно, можно заметить, что меняется один параметр - из true делаем false.

Файлик сохраняем и закрываем редактор. После чего перезапускаем службу VMware vCenter Converter Standalone Worker. 

               После таких манипуляций скорость копирования возросла в примерно в 30-40 раз :) И машинка мигрировалась вместо двух дней — всего лишь полтора часа (на скорости 30-35 МБ/сек).

                 Но даже на более новых версиях винды (2008 R2 например), скорость передачи данных с использованием шифрования составляет всего 20-25 МБ/сек, что далеко не гигабит. 

Читать далее ...