Заметки (5) с тэгом «itil»

Для кого Айтиль

02.04.2018 15:21
Комментариев:  _count

Некоторые люди считают, что курс «Основы ITIL» необходимо посетить всем сотрудникам ИТ-подразделения или ИТ-компании, в то время как другие говорят, что это курс только для руководителей. Каково ваше мнение?

Инвестируя деньги в обучение сотрудников, организация стремятся 1) сделать сотрудников более полезными для себя и 2) неденежно промотивировать их (т.е. заплатить за работу, но не давая сотруднику денег). При этом нужно 3) не перестараться, не сделать сотрудника слишком квалифицированными для текущей или запланированной должности. Обучение «Основам ITIL» ИТ-менеджеров помогает достичь этих целей, но обучение рядовых сотрудников ИТ по той же программе ведёт к прямо противоположным результатам. В этом эссе будет рассмотрена польза обучения «Основам ITIL» (далее в тексте — «Основы»).

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

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

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

Хорошим подтверждением для вышесказанного является программа обучения сотрудников эксплуатации и поддержки от компании «Гугль» — в рассчитанном на полгода обучении ни разу не упоминаются ни ITIL, ни процессный подход, ни жизненный цикл сервиса — этот список можно продолжать долго. «Гугль» однозначно показывает, что рядовому айтишнику это не нужно.

Вывод: курс «Основы ITIL» создан для ИТ-руководителей; посылая на «Основы» рядовых айтишников, организация сама себе вредит.

«Гугль» велит за ними следить

02.03.2018 20:04
Комментариев:  _count

«Гугль» считает, что система мониторинга, а вместе с ней и администратор, должна следить за 4 категориями сигналов:

Latency

Дословно — задержка, но здесь это «скорость обработки запросов» или «скорость выполнения действий».

Сервис это действия, а людям, когда они имеют дело с компьютером, очень хочется получить всё побыстрее, поэтому сигналы этой категории помогают понять, как пользователь воспримет ваш сервис: «тупит» он или «летает».

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

Чтобы узнавать скорость выполнения запросов внутри своих систем, «Гугль» встраивает средства мониторинга внутрь самих систем. Аналог: запуск команд внутри команды time. Для примера я несколько раз скачал главную страницу этого сайта и получил вот такую latency (цифры перед total, в секундах).

ADD TEXT

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

Traffic

Трафик (вроде эксперты склоняются к одной ф) — сколько работы делает ваш сервис. Если в предыдущем разделе нас интересовала скорость обработки запросов, то теперь мы измеряем их количество.

Rate of errors

Лучшим переводом видится «процент ошибок». Это лучше, чем «количество ошибок», потому что 10 ошибок при 10 запросах и 20 ошибок при 10 000 запросов — это очень разные ситуации, и первая намного хуже второй, хотя количество ошибок в ней вдвое меньше.

Level of saturation

Дословно — уровень насыщения, но вроде у нас все говорят «утилизация» (если нет, в комментах своё слово укажите, пожалуйста) в качестве общего термина, а когда речь о конкретном объекте, термин будет специфический для него: «загрузка процессора», «свободное место на диске».

Один и тот же показатель может быть про трафик, если он сам по себе, и про утилизацию, если мы его сравниваем с максимально возможным. Например: «10 активных подключений к БД» это трафик, а «из 20 возможных подключений к БД активны 10» это утилизация.

И всё-таки они нужны

20.04.2016 22:52
Комментариев:  _count

Обсуждение прошлой заметки заставляет меня сформулировать мой тезис бо́льшим количеством слов. Я утверждаю, 1) что номер инцидента создаёт удобства поставщику услуг при решении каких-то внутренних проблем, однако из этого не следует, что для пользователя от знания номера тоже есть какие-то удобства; 2) что для пользователя качество сервиса не повысится от того, что он этот номер знает; 3) качественный сервис можно предоставлять, не сообщая пользователю никаких номеров. Отдельно замечу, что если уж невыносимо хочется пользователю какой-то номер инцидента всучить, разумно ограничиться скромным трёхзначным номером, чем самонадеянно рассчитывать, что пользователь захочет посчитать, сколько нолей в вашем INC000000030889.

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

Однако, иногда я бы хотел знать номер инцидента.

Однажды я пытался стать клиентом «Тачбанка». По каким-то причинам приложение Touchbank отказывалось переводить к себе деньги. После нескольких попыток в течение пары недель я даже не стал обращаться в поддержку. Решил, что лучше не связываться: сейчас не работает пополнение, а вдруг потом не сработает снятие? Месяца через три банк обо мне вспомнил и стал требовать 4 доллара за услуги. Я считал, что никаких услуг банк мне не оказал, больше их н ехотел, и просил расторгнуть наш контракт. Первый тачбанкир, которому я сказал об этом, пообещал, что мне позвонит специальный расторгатель контрактов. Наврал. Поддержка на письма сначала не отвечала, а когда их заставили со мной общаться, повела себя не так, как ведут себя люди, собирающиеся помочь. После второго письма ни о чём я попросил сообщить мне номер моего дела, инцидента, обращения или что у них там. Сделали вид, что не понимают, чего я хочу. Тоже поставили наглеца на место, я надеюсь.

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

Номера обращений не нужны

15.04.2016 00:29
Комментариев:  _count

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

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

Знание идентификатора своего взаимодействия с поставщиком (INC000000030889) не приносит пользователю никакой пользы. Но этот номер приносит пользу поставщику, даже три:

Первая польза — считается, что оператор или инженер могут найти инцидент только по номеру. Ведь номер уникальный, по нему можно найти ровно один инцидент, если он есть, а если номер неправильный или пользователь его не знает или не помнит, то и разговаривать с ним не о чем. Это миф. Если пользователь обращается по поводу какого-то инцидента, то это точно не инцидент десятилетней давности — ИТСМ-системы столько не живут. Это точно не инцидент пятилетней давности — люди сейчас не работают по пять лет на одном месте. Это даже не пятинедельный инцидент, потому что тем, кто за 5 недель не может решить инцидент, уже должны были позвонить из отдела кадров. Посмотрите в ваши регламенты и SLA, там, скорее всего, написано, что со всеми ожиданиями и откладываниями максимальный срок решения инцидента не больше трёх недель. А за три недели в норме пользователь генерирует полтора инцидента. Так что как только вы идентифицировали пользователя, и он звонит по поводу ранее открытого инцидента, в норма вам не нужно спрашивать у пользователя номер, вам нужно только узнать, идёт речь о вчерашнем инциденте, или об инциденте, открытом на прошлой неделе.

Вторая польза — номер нужен для расследований. «Мы просрочили решение INC000000030889 на 130 недель, кто-то должен за это ответить!» Полностью согласен с постановкой вопроса, но хочу заметить, что это внутреннее дело поставщика услуг, и пользователь тут ни при чём, и номер инцидента ему знать ни к чему.

Про третью пользу недавно читал в чьей-то заметке: «Он нам звонит за помощью, а мы ему [вместо помощи]: „А какой номер инцидента?!“ Поставили наглеца на место!»

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

Решение инцидента есть, номера нет

Компания, в которой работает Соня, могла бы заставить её отвечать: «Вашему обращению присвоен номер INC000000030889, oбязательно указывайте этот номер при всех последующих обращениях в службу поддержки!», но вместо этого Соня сразу быстро решает инцидент. Вот бы все так делали!

Конечно, у каждого инцидента есть полезный для поставщика идентификатор, и часто не один. Но не всё, что у вас есть, стоит выкладывать клиенту под нос.

Опровержение этой заметки читайте в следующей.

О номерах обращений/инцидентов

26.03.2016 23:15
Комментариев:  _count

Пару лет, а то и больше, я не слышал от сотрудников ИТ-подразделений слова «юзверь». По-моему, это хорошо: тех, кто нам платит за работу, нужно уважать. Следующим шагом в развитии уважения к пользователю может стать отказ от издевательских номеров обращений.

«Ваш инцидент зарегистрирован под номером INC000000030889. Обязательно указывайте этот номер при всех последующих обращениях в службу поддержки!»

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

В параллельной вселенной, где именно такая форма и такая длина номера являются оптимальными, я бы улучшил номер, разбив в нём символы на группы по три: INC 000 000 030 889. Или INC_000_000_030_889, если кто-то опасается, что пользователь не поймёт, что это один номер, а не несколько. Впрочем, для фразы «Ваш инцидент зарегистрирован под номером INC 000 000 030 889» риск непонимания отсутствует.

Для организаций, живущих в реальном мире, вполне достаточно будет номера покороче: INC 030 889 хватит для регистрации миллиона обращений. Много это или мало? Если в норме (константа Конакова) один пользователь генерирует 26 обращений в год, и вы планируете пользоваться этой ИТСМ-системой и её номерами 10 лет, то 6-значных номеров хватит для организации, у которой 3846 пользователей.

А если система продержится дольше 10 лет? Ничего страшного. Нумеруйте обращения и инциденты, как счета-фактуры, начиная с 1 с началом каждого года. Тогда шестизначных номеров хватит для 38 461 пользователя. Если же запускать нумерацию обращений с 1 каждый месяц, то трёхзначных номеров (INC 889) хватит для компании с 500 пользователями. Месяц — слишком короткий промежуток, и возникнет путаница: о каком INC 889 идёт речь, о январском, февральском или мартовском? Во всех SLA, которые я видел, крайние сроки решения выражены в единицах и десятках часов, поэтому если февральский INC 889 ещё не закрыт к моменту появления мартовского INC 889, у этой организации проблемы такого масштаба, которые переход к 6-значным номерам точно не решит.

Приставку INC (REQ, CHG, TAS …) требуют устаревшие ИТСМ-системы, чтобы оператор знал, в каком интерфейсе искать запись. Сегодня поиск устроен, как в «Яндексе»: одно поле ввода, ищет везде. Поэтому вместо принадлежности к интерфейсу (INC 889) полезнее в приставке отразить принадлежность запроса к компании. «Тачбанк» мог бы написать так:

«Вашему обращению присвоен номер TBN 889.»

При чём тут этот банк и куда пропала вторая фраза, про «указывайте номер», читайте в следующих заметках.

HyperComments