Говорят, что картинка стоит тысячи слов. Однако, для картинок со схемами процессов это не всегда так. Из-за нумерации пунктов справа больше информации, чем слева.
Картинка в полном размере.
Не рисуйте схемы процессов только потому, что все их рисуют.
Читаю документ, в нём автор от SaaS и PaaS дошла до «Техническая поддержка как сервис». Е. Г-а (это зашифрованное обращение к автору), а как что ещё техническая поддержка может быть? Академический интерес.
Некоторые люди считают, что курс «Основы ITIL» необходимо посетить всем сотрудникам ИТ-подразделения или ИТ-компании, в то время как другие говорят, что это курс только для руководителей. Каково ваше мнение?
Инвестируя деньги в обучение сотрудников, организация стремятся 1) сделать сотрудников более полезными для себя и 2) неденежно промотивировать их (т.е. заплатить за работу, но не давая сотруднику денег). При этом нужно 3) не перестараться, не сделать сотрудника слишком квалифицированными для текущей или запланированной должности. Обучение «Основам ITIL» ИТ-менеджеров помогает достичь этих целей, но обучение рядовых сотрудников ИТ по той же программе ведёт к прямо противоположным результатам. В этом эссе будет рассмотрена польза обучения «Основам ITIL» (далее в тексте — «Основы»).
Задачи рядового сотрудника ИТ: программирование, тестирование, документирование, администрирование и поддержка. Курсы по конкретным системам помогут сотруднику выполнять эти задачи лучше, а «Основы» — нет. Например, если с базой данных случился инцидент, знание администратором принципов присваивания приоритетов инцидентам не поможет решить этот инцидент быстрее, а знания и навыки, полученные на курсе администрирования этой конкретной БД как раз должны помочь. То есть посещение «Основ» не делает рядового сотрудника ИТ более ценным для организации. С другой стороны, ИТ-руководитель как раз не должен знать подробностей администрирования БД, но должен уметь организовать распределение задач между исполнителями и установить очерёдность их выполнения. Это в точности то, что преподают на «Основах».
Многие компании рассматривают обучение и сертификацию сотрудников как часть компенсационного пакета. Например, нормой является оплата обучения только сотрудникам, проработавшим в организации не менее определённого срока. Это свидетельство того, что обучение рассматривается не как способ получить сотрудника, способного решать поставленные задачи, а как средство принудить сотрудника оставаться в организации. Для рядового ИТ-сотрудника «Основы» не представляют ценности, как источник знаний и навыков, потому что знания и навыки этого курса рядовому сотруднику применить негде. Курс «Основ» может быть ценен для ИТ-сотрудника только как трёхдневный отпуск. ИТ-менеджеру, наоборот, «Основы»дают немедленно применимые знания и навыки.
Избыточную квалификацию, то есть когда сотрудник знает и умеет больше, чем нужно знать и уметь на занимаемой должности, принято считать проблемой. Такой сотрудник не будет удовлетворён ни решаемыми задачами, ни получаемой оплатой, потому что он знает, что может делать и зарабатывать больше. Рядовой сотрудник ИТ после «Основ» понимает, что работа ИТ-руководителя вполне посильная и он с ней справился бы. Это лишнее знание для рядового сотрудника, делающее его излишне квалифицированным. Напротив, для руководителя в ИТ знания и навыки «Основ» необходимы, без них он недостаточно квалифицирован для своей должности.
Хорошим подтверждением для вышесказанного является программа обучения сотрудников эксплуатации и поддержки от компании «Гугль» — в рассчитанном на полгода обучении ни разу не упоминаются ни ITIL, ни процессный подход, ни жизненный цикл сервиса — этот список можно продолжать долго. «Гугль» однозначно показывает, что рядовому айтишнику это не нужно.
Вывод: курс «Основы ITIL» создан для ИТ-руководителей; посылая на «Основы» рядовых айтишников, организация сама себе вредит.
Неожиданно хорошо закончил курс «Переговоры и отношения с клиентами»:
«Гугль» считает, что система мониторинга, а вместе с ней и администратор, должна следить за 4 категориями сигналов:
Дословно — задержка, но здесь это «скорость обработки запросов» или «скорость выполнения действий».
Сервис это действия, а людям, когда они имеют дело с компьютером, очень хочется получить всё побыстрее, поэтому сигналы этой категории помогают понять, как пользователь воспримет ваш сервис: «тупит» он или «летает».
Например, это может быть скорость выдачи веб-страницы. Или скорость реакции компьютерной игры на нажатия клавиш. Или время от подачи запроса до момента установки нового ПО на рабочую станцию, то есть скорость выполнения стандартного запроса.
Чтобы узнавать скорость выполнения запросов внутри своих систем, «Гугль» встраивает средства мониторинга внутрь самих систем. Аналог: запуск команд внутри команды time. Для примера я несколько раз скачал главную страницу этого сайта и получил вот такую latency (цифры перед total, в секундах).
Кое-что мне кажется на этой картинке странным, но раз она сделана ради цифр скорости загрузки, прочее не сильно важно, так что если вы тоже заметили странность — я не разбирался, почему так получается.
Трафик (вроде эксперты склоняются к одной ф) — сколько работы делает ваш сервис. Если в предыдущем разделе нас интересовала скорость обработки запросов, то теперь мы измеряем их количество.
Лучшим переводом видится «процент ошибок». Это лучше, чем «количество ошибок», потому что 10 ошибок при 10 запросах и 20 ошибок при 10 000 запросов — это очень разные ситуации, и первая намного хуже второй, хотя количество ошибок в ней вдвое меньше.
Дословно — уровень насыщения, но вроде у нас все говорят «утилизация» (если нет, в комментах своё слово укажите, пожалуйста) в качестве общего термина, а когда речь о конкретном объекте, термин будет специфический для него: «загрузка процессора», «свободное место на диске».
Один и тот же показатель может быть про трафик, если он сам по себе, и про утилизацию, если мы его сравниваем с максимально возможным. Например: «10 активных подключений к БД» это трафик, а «из 20 возможных подключений к БД активны 10» это утилизация.
