Портал №1 по управлению цифровыми
и информационными технологиями

Задать вопрос!

Авторы портала готовы ответить на ваши вопросы!

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

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

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

Комментариев: 9

  • Евгения Мазина

    Здравствуйте!

    Довольно много информации об обязанностях менеджера процесса, а какими полномочиями/правами он должен быть наделен, чтобы эффективно исполнять свои обязанности?

    Буду очень признательна за обмен мнениями по этой теме и примеры из реальной жизни.

    Всем хорошего дня!

  • Павел

    Добрый день!

    Кейс с организацией on-call дежурств для L3 команд. В IT департаменте организации сложилось так, что в L3 командах, которые отвечают за критичные для компании сервисы (сетевая инфраструктура, серверное оборудование, системы версионирования и т.д.) работают по 2 человека в каждой команде (сетевые админы, инфраструктурные админы, атлассиан админы и др.). В обычное рабочее время (8 на 5) идаже с учетом отпусков и больничных этой численности хватает для решения задач.
    Но есть необходимость организовать on-call дежурства 24 на 7 по обработке инцидентов по некоторым самым критичным сервисам. Процесс выглядит так что от системы мониторинга поступают алерты, поступает звонок в L1, далее L2 при необходимости, далее L3 тоже при необходимости. При этом на всех уровнях – это именно дежурство по телефону (ответить на звонок), то есть это не полноценная работа 24 на 7.
    С L1 и L2 командами в этом плане все ок, у них численность побольше, но с L3 – есть вопросы, т.к. сотруднику придется пол месяца условно быть в on-call, хоть инциденты случаются очень редко, тем не менее это все-равно накладывает какие-то ограничения для сотрудника и они сопротивляются такому подходу. Найм в команды L3 сотрудников рассматривается, но пока очень спорный, т.к. тогда не хватает загрузки для дорогих специалистов в обычное время. Также рассматриваем возможность доп мотивации сотрудников за on-call дежурства в различных видах.
    Думаю это не очень уникальный кейс и буду признателен за то, что набросаете варианты решения по нему.

  • Сергей

    Коллеги, здравствуйте.

    Поделитесь, пожалуйста, ссылочками на сборники практик и инструментов для колл-центров. Решаем задачку развития внутреннего интерпрайс колл-центра на 15-25 линий и упёрлись в ограниченность своего кругозора.

    Спасибо!

  • Konstantin

    Возник такой вопрос – периодически приходят алерты с серверов об ошибке память. Теория говорит что есть риск внезапной перезагрузки сервера в период от 1 часа до пары недель. На практике сервер с такой ошибкой живет в среднем 1 неделю до ребута. Решение – миграция всех виртуалок (от 10 до 80) на другой кластер и замена модуля. Мнение как действовать разделилось:
    1. Это P1 инцидент, делаем emergency change, немедленная миграция, несмотря на бизнес часы и риск сбоя виртуалки при миграции.
    2. Это P2, делаем обычный change и выносим на CAB, у нас есть время все спланировать и мигрировать в течении 4-5 дней.
    3. Это P3, используем модель изменения в которой CAB ждать не надо, в изменении минимум согласователей из экспертов, выполняется в тот же день после бизнес часов и после уведомления владельцев виртуалок.
    Кто прав?

  • Павел

    Добрый день, вопрос про управление конфигруациями, CMDB.
    У нас в ИТ департаменте работает CMDB, внедрена система, ведется учет различных нужных нам CI, есть минимальный доступ для всех сотрудников компании, чтобы они могли смотреть свое оборудование и некоторую другую информацию.

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

Добавить комментарий для ПавелОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

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