Рубрика «sla» - 3

В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.

Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.

Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!

КДПВ

Так что же такое эскалация, кому и зачем она нужна? Сейчас расскажу своё понимание, после которого Вы, как я надеюсь, полюбите эскалацию также, как и я. Держитесь крепче за стул.

Читать полностью »

Рано или поздно при организации технической поддержки в более или менее крупной организации приходится иметь дело вот с этим: с SLA.

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

  • администрация-руководство и девушки-секретари им всячески помогающие,
  • продавцы — желающие работать удалённо, "бо волка ноги кормят",
  • логисты — ведающие закупками/складом/поставками/транспортом, и желающие жить неплохо,
  • бухгалтерия — учёт всего в денежном выражении,
  • кадры — решение всех вопросов с наймами, отпусками, отсутвиями и здоровьем персонала,
  • безопасность — чтобы ничего не спёрли,
  • маркетологи — как же сайту без них.Читать полностью »

Как написать хороший SLA (Service Level Agreement, оно же Соглашение об уровне сервиса). И какой SLA будет хорошим.

Эта статья является попыткой обобщить имеющийся опыт, а также на неё я собираюсь ссылаться, когда меня будут в дальнейшем спрашивать, как должен выглядеть SLA. Работая в индустрии не первый десяток лет, я к своему удивлению регулярно сталкиваюсь с серьёзным непониманием основ, на которых строится SLA. Наверное, потому что документ довольно экзотический. После прочтения данного текста, я надеюсь, у вдумчивого читателя точечки над ё должны встать на свои места. Целевая аудитория — те, кто пишет SLA, и им сочувствующие.

Ниже сплошной текст без диалогов и картинок.Читать полностью »

SLA на облако: как читать и на что обратить внимание - 1

Сегодня хочу поговорить о том, как читать Service Level Agreement в договоре на облачные сервисы. SLA – это норма: клиенты требуют его на этапе запроса, провайдеры указывают заветные девятки во всех материалах. Отрицать не буду – без SLA плохо, но какие зоны ответственности затрагивает соглашение, не всегда понятно. Попробуем разобраться, что же это такое и когда бежать к провайдеру, размахивая договоров, а когда искать проблему на месте.

Простой пример: у клиента перестает работать ВМ, клиент сразу думает, что проблема в инфраструктуре. И смотрит, что же там в SLA по поводу доступности. А может, на самом деле зависла ОС, клиентская сеть лагает, — предположить можно всё что угодно. Если проблема внутри ОС, то провайдер ресурсов тут не поможет.

Читать полностью »

Всем привет и доброго времени суток.
Не так давно я писал о максимальном разрешении 3D печати.
Но, у некоторых людей появились сомнения на счет возможности такое реализовать. Поэтому, решили повторить опыт, но на другой модели.
Проверяем 3D печать на высоком разрешении (10 мкм) - 1
Читать полностью »

Всем привет. Меня зовут Сергей и я занимаюсь разработками 3D-принтеров. В данной статье я хочу показать варианты использования персонального SLA 3D принтера (с фотографиями, конечно же).

О том, что вы можете напечатать на 3D принтере - 1Читать полностью »

Сегодня я постараюсь разъяснить, что такое концепция доступности данных с точки зрения ИТ-специалиста, будь то ИТ-администратор, системный интегратор, консультант по внедрению и т.д. Надеюсь, что эта статья будет полезна читателям при составлении экономического обоснования на внедрение соответствующих программных иили аппаратных решений, а также соглашений об уровне обслуживания (SLA) – а кому-то поможет сделать эти документы более убедительными.
Для начала в качестве «узелков на память» сформулирую два постулата, с которыми многие, уверен, довольно хорошо знакомы:

  • RPO (recovery point objective) – допустимая потеря данных. Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) защиту своих данных от потери выше приемлемого уровня.
  • RTO (recovery time objective) – допустимое время восстановления данных Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) возможность восстановления своей работы в приемлемый срок.

Часто эта пара показателей отображается в виде одномерного графика вдоль оси времени.
Но в таком одномерном графике нет самого главного, на что ориентируется бизнес – денег! О том, как рассчитывать RTO и RPO, исходя из требований бизнеса, я расскажу под катом.

Обеспечение доступности данных и сервисов: показатели RPO, RTO и планирование SLA - 1


Читать полностью »

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

Два провайдера одновременно или Dual ISP with VRF на Cisco | Part 2 - 1

Добрый день! На написание этого материала меня вдохновил HunterXXI в своей статье Два провайдера одновременно или Dual ISP with VRF на Cisco. Я заинтересовался, изучил вопрос и применил на практике. Хотел бы поделится своим опытом в реализации Dual ISP на Cisco с реальным использованием одновременно двух ISP и, даже, балансировкой нагрузки.
Читать полностью »

«У секретаря закончился картридж, заменишь?» — «Ок». «По дороге посмотри там, бухгалтера 1С не пускает» — «Ок». «Алло, и ещё, пока не забыл — у верстальщика хард скрипит, видимо, помирает». Примерно так координируется работа ИТ-отдела в небольших компаниях, нередко то же самое происходит и в средних. Задачи оказываются забытыми, сотрудники простаивают в ожидании, на момент инвентаризации непременно теряются какие-то комплектующие или бумаги на них, экономисты урезают бюджет, потому что обосновать будущие траты почти нереально. С лицензиями ПО — вообще беда. Ну и ладно, давайте всем новый MS Office купим. Что нам, ITIL с ITSM внедрять, что ли? Да, внедрять. Да, ITIL. Ну точнее, не совсем.

WTF: What The FITS - 1
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js