Эта статья предназначена для всех тех системных администраторов, работающих в небольших компаниях, которые иногда сталкиваются с непониманием со стороны начальства и рядовых сотрудников. Такие люди — то есть мы с вами — иногда воспринимаются окружающими отрицательно, причем не всегда по заслугам. Отношения с сотрудниками портятся, когда мы закрываем доступ к социальным сетям. Начальство воспринимает в штыки любой запрос на покупку нового оборудования. Между тем, связи в коллективе — это ваш комфорт, а отношения с начальством — ваши деньги и карьера.
Именно поэтому, хотел бы вам предложить изменить эту схему. А именно — несколько рекомендаций из библиотеки ITIL. Они-то и станут тем фильтром, на который осядет весь неизбежный негатив нашей профессии. Если вам еще интересно – добро пожаловать под кат.
Рассмотри два процесса из книги Service Operation (Incident Management, Problem Management) и два из книги Service Transition (Change Management, Configuration Management). Иными словами предлагаю внедрить управление инцидентами, проблемами, изменениями и конфигурациями.
В качестве примера, возьмем компанию где трудится один администратор. У него есть начальство и некоторый постоянный объем работ по поддержке внутренней ИТ-инфраструктуры и ее пользователей.
Инциденты происходят ежедневно. Ломаются принтеры, компьютеры, выйти из строя может что угодно. Вы честно работаете, исправляя ошибки. Поток поломок и ремонтов смешивается в вашей памяти, и когда в конце квартала вам зададут вопрос о проделанной работе — вы сможете отчитаться только в общих чертах. Разумеется, такой ответ не произведет должного впечатления на руководство, а значит не будет ни повышение зарплаты, ни выделения нового рабочего места под вашего помощника. Для создания объективного отчета нужно лишь внедрить у себя одну из систем управления инцидентами. Платную, бесплатную, разработанную самим или собранную из связки почты с табличным редактором — неважно. Главное, чтоб она была.
Не нужно бегать по каждому запросу лично, часто выслушивая от пользователей нечто в духе «оно само уже починилось». Заставьте людей отправлять запросы по почте или через веб интерфейс, в крайнем случае принимайте их заявки по телефону.
Однако, будьте рассудительны: портить отношения с пользователями вам невыгодно, а потому представьте это как нововведение со стороны высшего руководства. Они вам еще и посочувствуют. Высшему же руководству предварительно принесите на подпись коротенький приказ о порядке обращения в отдел ИТ, и ведении учета обращений. Объясните руководству, что это для порядка. Руководство любит порядок.
Ведение базы данных инцидентов позволит вам планировать свой рабочий день, избавиться от постоянных прогулок под эгидой «посмотри, у меня там компьютер не работает..», и так далее. Ваш начальник в любой момент получит четкий и понятный отчет о проделанной работе, потраченных ресурсах и глупых запросах пользователей за любой период времени. Пользователи получат возможность просматривать состояние своей заявки онлайн, не надоедая при этом лично вам.
Система станет изолирующей прослойкой между вашей личностью и любым негативом, неизбежно циркулирующим в человеческом обществе в поисках удобного “громоотвода”. У нее нет личности. Систему глупо просить, бесполезно ругать; с ней не о чем спорить. В безопасности, системы контроля доступа и видеонаблюдения несут, помимо основной, еще и важную функцию снятия человеческой агрессии с охранника. Опоздавший сотрудник злится на вахтера за то, что тот записывает его в журнал — но ему не прийдет в голову злиться на карточный турникет. Сделайте то же самое для себя, и пользователь сломанного принтера вместо того чтобы рассказывать вам про необходимость печати накладных, просто посмотрит на статус запроса — и распечатает свои накладные в соседнем отделе.
После внедрения управления инцидентами, следующим логическим шагом будет внедрение управления проблемами. Представьте, что у вас есть очень вредный принтер, который ломается каждый месяц, постоянно забирая ваше время на согласование его ремонтных работ, пожирая деньги компании. Имея уже настроенную базу инцидентов, вы можете выбрать те из них, которые касались непосредственно этого принтера, а затем создать проблему — в которой все данные будут связаны воедино. Показать начальству, что его ремонт уже обошелся вам в половину стоимости нового, а в дальнейшем и вовсе ее превысит. Целесообразность покупки нового принтера станет очевидна даже для самого далекого от сферы ИТ руководителя.
Проблема – это не только повторяющиеся, а вообще любые инциденты, имеющие критическое воздействие на вашу инфраструктуру. К примеру, поломка рейд контроллера на почтовом сервере, которая повлекла за собой временное прекращение бизнес-переписки, должна иметь статус проблемы. Иными словами, ведение такой базы позволит выделить инциденты и группы инцидентов для решения которых необходимо использовать изменения в инфраструктуре.
В идеале, с точки зрения организации рабочего процесса, вы должны стремиться к тому чтобы решать проблемы. Все инциденты следует передавать помощнику, которого вам удалось взять благодаря понятным и развернутым отчетам за предыдущий квартал.
Наш следующий шаг — внедрение управления изменениями. Любые замены важного оборудования, все внесения изменений в настройки серверов, должны быть задокументированы. При небольших объемах производства, либо достаточной комплектации штата ИТ-отдела, в базу управления конфигурациями можно вносить даже замену мышки, чтобы можно было отследить: какой пользователь, когда и что заказывал.
База, с которой работают все перечисленные процессы, называется CMDB (Configuration management database). Это часть управления конфигурациями. В ней хранятся все имеющиеся аппаратные, программные решения и персонал компании, каждому из которых присвоен инвентаризационный номер. Каждая такая запись в базе называется конфигурационной единицей. Будь то инцидент или проблема, любой запрос должен иметь внутри себя связь с какой-либо конфигурационной единицей из этой базы.
Если к моменту внедрения управления изменениями у вас уже есть помощник — крайне предпочтительно ввести в отделе систему запросов на изменения (RFC). Любое действие по изменению конфигурации оборудования, либо его замене со стороны вашего помощника, должно иметь формальное ваше разрешение. Без которого этот самый помощник за любое изменение получал бы дисциплинарное взыскание — или, проще говоря, по шапке, даже если он внес информацию в базу.
Повторюсь: самый бюджетный вариант внедрения всего этого хозяйства можно реализовать посредством почты, табличного редактора и html.
В этой статье я постарался как можно проще описать общую идеологию, по возможности не вникая в детали и подробности. Если вам интересно, я могу более глубоко пройтись по каждому процессу или описать другие процессы и рекомендации библиотеки ITIL с их адаптацией к реалиям нашей жизни.
Именно поэтому, хотел бы вам предложить изменить эту схему. А именно — несколько рекомендаций из библиотеки ITIL. Они-то и станут тем фильтром, на который осядет весь неизбежный негатив нашей профессии. Если вам еще интересно – добро пожаловать под кат.
Рассмотри два процесса из книги Service Operation (Incident Management, Problem Management) и два из книги Service Transition (Change Management, Configuration Management). Иными словами предлагаю внедрить управление инцидентами, проблемами, изменениями и конфигурациями.
В качестве примера, возьмем компанию где трудится один администратор. У него есть начальство и некоторый постоянный объем работ по поддержке внутренней ИТ-инфраструктуры и ее пользователей.
Управление инцидентами
Инциденты происходят ежедневно. Ломаются принтеры, компьютеры, выйти из строя может что угодно. Вы честно работаете, исправляя ошибки. Поток поломок и ремонтов смешивается в вашей памяти, и когда в конце квартала вам зададут вопрос о проделанной работе — вы сможете отчитаться только в общих чертах. Разумеется, такой ответ не произведет должного впечатления на руководство, а значит не будет ни повышение зарплаты, ни выделения нового рабочего места под вашего помощника. Для создания объективного отчета нужно лишь внедрить у себя одну из систем управления инцидентами. Платную, бесплатную, разработанную самим или собранную из связки почты с табличным редактором — неважно. Главное, чтоб она была.
Не нужно бегать по каждому запросу лично, часто выслушивая от пользователей нечто в духе «оно само уже починилось». Заставьте людей отправлять запросы по почте или через веб интерфейс, в крайнем случае принимайте их заявки по телефону.
Однако, будьте рассудительны: портить отношения с пользователями вам невыгодно, а потому представьте это как нововведение со стороны высшего руководства. Они вам еще и посочувствуют. Высшему же руководству предварительно принесите на подпись коротенький приказ о порядке обращения в отдел ИТ, и ведении учета обращений. Объясните руководству, что это для порядка. Руководство любит порядок.
Ведение базы данных инцидентов позволит вам планировать свой рабочий день, избавиться от постоянных прогулок под эгидой «посмотри, у меня там компьютер не работает..», и так далее. Ваш начальник в любой момент получит четкий и понятный отчет о проделанной работе, потраченных ресурсах и глупых запросах пользователей за любой период времени. Пользователи получат возможность просматривать состояние своей заявки онлайн, не надоедая при этом лично вам.
Система станет изолирующей прослойкой между вашей личностью и любым негативом, неизбежно циркулирующим в человеческом обществе в поисках удобного “громоотвода”. У нее нет личности. Систему глупо просить, бесполезно ругать; с ней не о чем спорить. В безопасности, системы контроля доступа и видеонаблюдения несут, помимо основной, еще и важную функцию снятия человеческой агрессии с охранника. Опоздавший сотрудник злится на вахтера за то, что тот записывает его в журнал — но ему не прийдет в голову злиться на карточный турникет. Сделайте то же самое для себя, и пользователь сломанного принтера вместо того чтобы рассказывать вам про необходимость печати накладных, просто посмотрит на статус запроса — и распечатает свои накладные в соседнем отделе.
Управление проблемами
После внедрения управления инцидентами, следующим логическим шагом будет внедрение управления проблемами. Представьте, что у вас есть очень вредный принтер, который ломается каждый месяц, постоянно забирая ваше время на согласование его ремонтных работ, пожирая деньги компании. Имея уже настроенную базу инцидентов, вы можете выбрать те из них, которые касались непосредственно этого принтера, а затем создать проблему — в которой все данные будут связаны воедино. Показать начальству, что его ремонт уже обошелся вам в половину стоимости нового, а в дальнейшем и вовсе ее превысит. Целесообразность покупки нового принтера станет очевидна даже для самого далекого от сферы ИТ руководителя.
Проблема – это не только повторяющиеся, а вообще любые инциденты, имеющие критическое воздействие на вашу инфраструктуру. К примеру, поломка рейд контроллера на почтовом сервере, которая повлекла за собой временное прекращение бизнес-переписки, должна иметь статус проблемы. Иными словами, ведение такой базы позволит выделить инциденты и группы инцидентов для решения которых необходимо использовать изменения в инфраструктуре.
В идеале, с точки зрения организации рабочего процесса, вы должны стремиться к тому чтобы решать проблемы. Все инциденты следует передавать помощнику, которого вам удалось взять благодаря понятным и развернутым отчетам за предыдущий квартал.
Управление изменениями и конфигурациями
Наш следующий шаг — внедрение управления изменениями. Любые замены важного оборудования, все внесения изменений в настройки серверов, должны быть задокументированы. При небольших объемах производства, либо достаточной комплектации штата ИТ-отдела, в базу управления конфигурациями можно вносить даже замену мышки, чтобы можно было отследить: какой пользователь, когда и что заказывал.
База, с которой работают все перечисленные процессы, называется CMDB (Configuration management database). Это часть управления конфигурациями. В ней хранятся все имеющиеся аппаратные, программные решения и персонал компании, каждому из которых присвоен инвентаризационный номер. Каждая такая запись в базе называется конфигурационной единицей. Будь то инцидент или проблема, любой запрос должен иметь внутри себя связь с какой-либо конфигурационной единицей из этой базы.
Если к моменту внедрения управления изменениями у вас уже есть помощник — крайне предпочтительно ввести в отделе систему запросов на изменения (RFC). Любое действие по изменению конфигурации оборудования, либо его замене со стороны вашего помощника, должно иметь формальное ваше разрешение. Без которого этот самый помощник за любое изменение получал бы дисциплинарное взыскание — или, проще говоря, по шапке, даже если он внес информацию в базу.
Повторюсь: самый бюджетный вариант внедрения всего этого хозяйства можно реализовать посредством почты, табличного редактора и html.
В этой статье я постарался как можно проще описать общую идеологию, по возможности не вникая в детали и подробности. Если вам интересно, я могу более глубоко пройтись по каждому процессу или описать другие процессы и рекомендации библиотеки ITIL с их адаптацией к реалиям нашей жизни.