Как предоставить лучший облачный сервис с использованием ITIL и PRINCE2 Будучи руководителем группы инженеров, работающих над облачным сервисом для клиента, я задавался вопросом, как можно улучшить качество сервиса с помощью инструментов управления.
Изучив вопрос, я остановился на ITIL и PRINCE2 — это логичные, структурированные и масштабируемые инструменты.
Они оказались настолько полезными, что через некоторое время я даже получил Foundation в обоих рамках.
В этой статье я хотел бы рассказать о том, почему ITIL и PRINCE2 оказались настолько хороши для работы в облаке, и поделиться своим опытом.
Часть 0. Вводная
Несмотря на то, что ITIL и PRINCE2 существуют уже давно, особенности этих методологий не очень известны в нашей профессиональной среде.Я считаю, что это связано с тем, что оба фреймворка популярны в основном в Великобритании, откуда они и зародились.
Но это вовсе не означает, что они не применимы где-либо еще.
При правильном подходе польза для менеджера PaaS-организации огромна, что я и постараюсь доказать на собственном опыте.
Часть 1. Строим и поставляем облачную инфраструктуру с PRINCE2
Методика PRINCE2 состоит из следующих основных частей: Принципы – это фундаментальные идеи, которые должен всегда иметь в виду практикующий менеджер PRINCE2. Темы – это области управления, которые необходимо учитывать на протяжении всего жизненного цикла проекта.Процессы – это практики, которые описывают, кто, когда и что должен делать на проекте.
Надо сказать, что PRINCE2 работает лучше всего, когда руководитель строго следует всем рекомендациям методики, ничего не игнорируя и не упуская из виду.
В то же время фреймворк хорошо масштабируем и подходит как для небольших, так и для огромных проектов.
В своей работе я принимаю заказы на создание сред Kubernetes и OpenShift. Каждое такое частное облако состоит из нескольких десятков виртуальных машин (узлов) и, как правило, включает в себя такие сервисы, как базы данных, брокеры сообщений, инструменты бизнес-аналитики и так далее.
Было бы неразумно подходить к созданию такого сложного образования без адекватного планирования и системного подхода.
Я продемонстрирую, как принципы PRINCE2 можно использовать для ускорения и упрощения этой задачи.
Непрерывный бизнес-кейс
В начале работы над проектом руководствуемся принципом непрерывное бизнес-кейс Я оцениваю риски и слежу за тем, чтобы они не перевешивали выгоды.Если я считаю, что риск слишком высок (например, запрошенная заказчиком версия базы данных не тестировалась на Kubernetes, а последствия ее установки в облако непредсказуемы), я сообщаю об этом заказчику и соглашаюсь с ним о дальнейших действиях.
Определенные роли и обязанности
Тогда я использую принцип определенные роли и обязанности чтобы каждый член моей инженерной команды понимал свою задачу по проекту и обладал достаточным опытом для ее выполнения.
Сосредоточьтесь на продуктах и обучении на собственном опыте
Далее я перехожу к принципу сосредоточиться на продуктах , что заставляет меня постоянно следить за тем, чтобы команда производила работу соответствующего качества, чтобы удовлетворить заказчика.Практическое применение принципа обучение на опыте заключается в том, чтобы тщательно документировать все ошибки и трудности, возникшие в ходе работы над проектом, и не начинать проект до тех пор, пока не будет изучен весь предыдущий опыт такой работы, ваш или ваших коллег.
Игнорирование этого принципа приводит к тому, что неопытный руководитель тратит время и ресурсы команды на решение проблем, которых можно было бы избежать, предварительно ознакомившись с накопленным опытом.
Управление по исключениям
Принцип управление по исключениям учит работать с рисками и контролировать проект в меняющихся условиях.Подходя к планированию проекта, мы осознаем, какие риски могут возникнуть, и готовим пошаговые инструкции по решению нештатных ситуаций.
Это позволяет нам не бегать ежеминутно к заказчику с вопросом, что делать в случае того или иного события.
Сценический менеджмент
Внимание заказчика и высшего руководства привлекается к проекту тогда и только тогда, когда он существенно отклоняется от утвержденного на старте плана или выходит за рамки бюджета.Для успешного применения принципа управление по этапам , необходимо предварительно разделить проект на условные циклы его существования.
Проект всегда открывается стадией планирования и закрывается стадией предоставления ценности заказчику.
Могут быть и промежуточные стадии.
Например, в нашем случае это может быть создание виртуальных машин, затем установка на них операционных систем, затем формирование из них кластера, установка оркестратора и вспомогательного ПО.
При этом в конце каждого этапа мы оцениваем проделанную работу и принимаем решение, двигаться дальше или нет. Это позволяет экономить ресурсы команды и вовремя заметить, если что-то идет не так.
Адаптация к среде проекта
Наконец, принцип адаптация к среде проекта существует для того, чтобы гарантировать соблюдение всех остальных принципов PRINCE2 независимо от объема работы, даже на самых маленьких проектах.Хотя я описал применение этих принципов как последовательность действий, на самом деле я обращаюсь к ним на каждом этапе проекта и всегда держу их в уме, чтобы мой проект был успешным.
Помимо принципов, практикующий менеджер PRINCE2 также обязательно использует темы и процессы.
Темы — это части проекта, к которым обращается менеджер на протяжении всего его жизненного цикла.
Темы включают: экономическое обоснование, планы, качество и т. д. Процесс представляет собой структурированный набор операций, направленных на достижение цели.
PRINCE2 группирует операции в 7 процессов:
- Старт проекта.
- Инициация проекта.
- Управление проектом.
- Управление границами стадий.
- Контроль сцены.
- Управление доставкой продукции.
- Закрытие проекта.
Итак, мы создали частное облако и доставили его заказчику с помощью PRINCE2. После родов обычно начинается операция.
Я расскажу вам, как применять методологию ITIL для успешной навигации на этом этапе жизненного цикла инфраструктуры.
Часть 2. Эксплуатируем и обеспечиваем облачную инфраструктуру по ITIL
Мы поговорим об ITIL 4, как о современной, актуальной редакции фреймворка.В данном случае 4 — это не номер версии, а отсылка к четвертой промышленной революции, которая, по мнению авторов методики, происходит прямо сейчас :) ITIL 4 — это сложная структура, состоящая из множества частей.
Хорошая диаграмма компонентов ITIL 4 доступна здесь: https://itsm.tools/its-here-itil-4-explained/ .
Полную структуру можно найти в книге https://www.oreilly.com/library/view/itil-foundation-itil/9780113316083/ или перейдите по ссылкам, приведенным в конце этой статьи.
Нас в основном интересуют практики, улучшающие качество обслуживания.
При этом все части ITIL 4 взаимосвязаны, а некоторые пересекаются с PRINCE2, поэтому всем интересующимся рекомендую обратиться к оригиналу или задать мне вопросы в комментариях.
Начнем с определения: Упражняться представляет собой совокупность организационных ресурсов, выделяемых для выполнения определенной работы или достижения цели.
Моя команда редко создает себе среду.
Если это происходит, то обычно это делается в целях обучения или отладки.
В большинстве случаев у инфраструктурного продукта есть внешний заказчик и конечный пользователь, с которым команде необходимо взаимодействовать.
Практика помогает решить эту проблему служба поддержки .
Он предоставляет инструменты для направления в нее информационных потоков извне обслуживающей организации через единую точку входа.
Такой подход очень выгоден как для инфраструктурной команды, так и для пользователей:
- ресурсы старших инженеров экономятся по сравнению с ситуацией, когда пользователи обращаются к ним напрямую;
- пользователи получают понятный и удобный инструмент для обратной связи;
- все коммуникации хранятся в одном месте, что удобно в случае возникновения спорных ситуаций, а также для ведения базы знаний.
В нем подробно описаны типы запросов, которые могут быть получены от пользователей, и согласованный уровень качества обслуживания, который должен быть соблюден для каждого типа.
Примерами сервисных запросов в случае нашей организации могут быть запросы на увеличение вычислительной мощности системы, обновление тех или иных ее компонентов, предоставление доступа к ресурсам и т.д. Работа любого оперативного командования имеет показатели своей эффективности.
Обычно в случае с PaaS это такие метрики, как MTTR, RPO, RTO и другие.
Упражняться управление происшествиями улучшает эти показатели, минимизируя ущерб от инцидентов и сокращая время восстановления после них.
Инцидент – это незапланированное прерывание или снижение качества обслуживания.
Эта практика показывает лучшие результаты в сочетании с практикой.
управление проблемами , что снижает количество инцидентов за счет работы с их первопричинами или проблемами.
Проблема — это реальная или потенциальная причина одного или нескольких инцидентов.
Оно может иметь полное (решение) или неполное (обходное решение) решение, либо вообще не иметь решения в текущий момент. В последнем случае проблема помечается как известная ошибка и вносится в базу знаний под названием KEDB. Также важной для моей команды является метрика процента неудачных изменений, то есть соотношение успешных и неудачных изменений.
Практика ITIL 4, которая помогает мне улучшить это, называется возможность изменения .
Изменение — это добавление, удаление или модификация компонента инфраструктуры, который может повлиять на предоставляемую услугу.
Примером такого объекта может быть виртуальная машина, сетевой интерфейс, конфигурация оборудования или версия программного обеспечения.
Изменения могут быть инициированы либо заказчиком (например, для получения дополнительной функциональности), либо инфраструктурной командой (например, для разрешения инцидента).
Теперь хотелось бы привести пример того, как все описанное выше работает в связке.
Допустим, пользователь сервиса замечает, что определенная его часть выдает сообщение об ошибке при выполнении определенных действий.
Вместо звонка менеджеру или сообщений в чатах он цивилизованно создает заявку в системе (практика службы поддержки).
Кстати, этот подход работает и тогда, когда разработчики используют облако, то есть ITIL 4 отлично подходит для DevOps-команд. Далее запрос принимается и обрабатывается выделенной группой инженеров первого уровня (это может быть один человек), которая связывается с пользователем и уточняет детали инцидента (практика управления сервисными запросами).
На этом этапе работы команда предполагает, что инцидент произошел из-за некорректного подключения к базе данных.
Однако у инженеров недостаточно квалификации, чтобы устранить инцидент самостоятельно, поэтому они передают запрос на следующий уровень специалистам по облачным базам данных (практика управления инцидентами).
В ходе более глубокого анализа группа инженеров второго уровня обнаруживает проблему, вызвавшую инцидент: база данных настроена неправильно (практика управления проблемами).
Поскольку такая конфигурация препятствует нормальной работе базы данных, консультативный совет по изменениям, состоящий из старших инженеров и менеджеров, решает внести экстренные изменения (практика внесения изменений).
После применения новых настроек система тестируется, и команда приходит к выводу, что изменение прошло успешно.
Группа специалистов первого уровня связывается с потребителем услуги, тот подтверждает восстановление работоспособности, а дежурный инженер закрывает заявку.
ITIL 4 также содержит методы, необходимые для операционных групп, такие как соглашение об уровне обслуживания, мониторинг и управление событиями и т. д. В мою задачу не входит описать их все в этой статье.
Скорее, мне хотелось бы показать красоту и универсальность ITIL 4 и заинтересовать как можно больше ИТ-специалистов использованием этого фреймворка.
Часть 3. Финал
Подводя итог, можно сделать вывод, что менеджеру знать ITIL и PRINCE2 как минимум полезно.Использование этих фреймворков не ограничивается случаями, когда команда предоставляет облачную платформу как услугу.
Обе методологии достаточно гибки, чтобы их можно было использовать в различных областях ИТ.
Но я могу с уверенностью сказать, что использование ITIL и PRINCE2 помогает мне успешно управлять командой эксплуатации PaaS, которая эффективно работает как внутри крупной организации, так и за ее пределами.
Я использую принципы и процессы PRINCE2 на этапе создания сложного инфраструктурного продукта, а практики ITIL на различных этапах его эксплуатации.
Материалы для самообучения
- Введение в курс управления услугами с помощью ITIL 4 .
- Введение в курс управления проектами с помощью PRINCE2 .
-
Lenovo P2: 5100 Мач И 3 Дня Без Подзарядки
19 Oct, 24 -
Самый Ужасный Код В Моей Жизни
19 Oct, 24 -
Виртуальные Игры, Настоящая Смерть
19 Oct, 24 -
Матрицы Нет...
19 Oct, 24
