Как предоставлять лучший облачный сервис с помощью ITIL и PRINCE2
Будучи тимлидом в команде инженеров, работающих над облачным сервисом для заказчика, я задумался, как можно улучшить качество услуги с помощью инструментов управления. Изучив вопрос, я остановился на ITIL и PRINCE2 – это логичные, структурированные и масштабируемые инструменты. Они оказались настолько полезными, что через некоторое время я даже получил Foundation по обоим фреймворкам. В этой статье я бы хотел поговорить о том, почему именно ITIL и PRINCE2 оказались так хороши для работы в cloud и поделиться своим опытом.
Часть 0. Вводная
Несмотря на то, что ITIL и PRINCE2 существуют давно, особенности этих методологий в нашей профессиональной среде не очень известны. Полагаю, это связано с тем, что оба фреймворка популярны в основном в Великобритании, где они появились. Но это совершенно не значит, что они больше нигде не применимы. При правильном обращении польза менеджеру PaaS-организации от них огромна, что я и постараюсь доказать, используя собственный опыт.
Часть 1. Строим и сдаём облачную инфраструктуру с PRINCE2
Методология PRINCE2 состоит из следующих основных частей:
Принципы – это основополагающие идеи, которые практикующий PRINCE2 менеджер должен всегда держать в голове.
Темы – это области управления, на которые необходимо обращать внимание на протяжении всего жизненного цикла проекта.
Процессы – это практики, описывающие кто, когда и что должен делать на проекте.
Надо сказать, что лучше всего PRINCE2 работает, когда менеджер чётко следует всем рекомендациям методологии, ничего не игнорируя и не упуская из виду. В то же время фреймворк прекрасно масштабируется и подходит как для крошечных, так и для огромных проектов.
В своей работе я принимаю заказы на создание Kubernetes- и OpenShift-окружений. Каждое такое частное облако состоит из нескольких десятков виртуальных машин (узлов) и, как правило, включает в себя такие сервисы, как: базы данных, брокеры сообщений, инструменты для бизнес-аналитики и так далее. Подходить к созданию такой сложной сущности без адекватного планирования и системного подхода было бы неразумно. Я продемонстрирую, как можно использовать принципы PRINCE2 для ускорения и упрощения этой задачи.
Непрерывное бизнес-обоснование
В начале работы над проектом, руководствуясь принципом непрерывного бизнес-обоснования, я оцениваю риски и убеждаюсь, что они не перевешивают выгоды. Если я нахожу, что риск слишком высок (например, запрошенная заказчиком версия базы данных не тестировалась на Kubernetes, и последствия её установки в облако непредсказуемы), я сообщаю об этом заказчику и договариваюсь с ним о дальнейших действиях.
Определенные роли и обязанности
Затем я использую принцип определённые роли и обязанности чтобы убедиться, что каждый участник моей команды инженеров понимает свою задачу на проекте и обладает достаточной экспертизой, чтобы её выполнить.
Фокус на продуктах и обучение на опыте
Далее я обращаюсь к принципу фокус на продуктах, который заставляет меня постоянно следить за тем, чтобы команда выдавала работу надлежащего качества, удовлетворяющего заказчика. Практическое применение принципа обучение на опыте заключается в том, чтобы тщательно документировать все ошибки и сложности, возникшие в ходе работы над проектом, и не приступать к выполнению проекта, пока не будет изучен весь предшествующий опыт таких работ, ваш или ваших коллег. Игнорирование этого принципа приводит к тому, что неопытный менеджер тратит время и ресурсы команды на решение проблем, которых можно было избежать, предварительно ознакомившись с накопленным опытом.
Управление по исключению
Принцип управления по исключению учит нас работать с рисками и контролировать проект в изменяющейся среде. Подходя к планированию проекта, мы осознаём, какие риски могут осуществиться, и готовим пошаговые инструкции для урегулирования внештатных ситуаций. Это позволяет нам не бегать к заказчику каждую минуту с вопросами, что делать в случае того или иного события.
Управление стадиями
Внимание заказчика и высшего руководства привлекается к проекту тогда и только тогда, когда он значительно отклоняется от утверждённого на старте плана или выходит за бюджетные рамки. Чтобы успешно применять принцип управления по стадиям, нужно сначала разделить проект на условные циклы его существования. Открывать проект всегда будет стадия планирования, закрывать – стадия поставки ценности заказчику. Могут существовать также и промежуточные стадии. Например, в нашем случае это может быть создание виртуальных машин, затем установка на них операционных систем, далее формирование из них кластера, установка оркестратора и вспомогательного ПО. При этом в конце каждого этапа мы оцениваем сделанную работу и принимаем решение, двигаться дальше или нет. Это позволяет сэкономить ресурсы команды и вовремя заметить, если что-то идёт не так.
Адаптация к проектной среде
Наконец, принцип адаптации к проектной среде существует для того, чтобы все остальные принципы PRINCE2 соблюдались вне зависимости от объёма работ даже на самых маленьких проектах.
Хотя я описал применение этих принципов как последовательность действий, на самом деле я обращаюсь к ним на каждом этапе проекта и всё время держу их в голове, чтобы мой проект был успешным.
Помимо принципов, практикующий PRINCE2 менеджер также обязательно использует темы и процессы.
Темы – это части проекта, к которым менеджер обращается на протяжении всего его жизненного цикла. К темам относятся: экономическое обоснование, планы, качество и т. д.
Процесс – это структурированный набор операций, направленных на достижение цели. PRINCE2 группирует операции в 7 процессов:
Начало проекта.
Инициация проекта.
Руководство проектом.
Управление границей стадии.
Контроль стадии.
Управление поставкой продуктов.
Закрытие проекта.
Подробнее о темах и процессах можно почитать на https://prince2.wiki/ru/.
Итак, мы создали приватное облако и сдали его заказчику, используя 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, поэтому я рекомендую всем заинтересованным обратиться к оригиналу либо задавать мне вопросы в комментариях. Начнём с определения:
Практика – это набор ресурсов организации, выделенный для выполнения конкретной работы или достижения цели.
Моя команда редко создаёт окружения для самой себя. Если такое и происходит, то как правило в учебных либо отладочных целях. В большинстве же случаев у инфраструктурного продукта есть внешний заказчик и конечный потребитель, с которыми команде необходимо взаимодействовать. Решить эту задачу помогает практика service desk. Она даёт инструменты для направления потоков информации снаружи сервисной организации внутрь её через единую точку входа. Такой подход очень выгоден как для инфраструктурной команды, так и для пользователей:
экономятся ресурсы старших инженеров по сравнению с ситуацией, когда пользователи обращаются к ним напрямую;
пользователи получают понятный и удобный инструмент для обратной связи;
вся коммуникация хранится в одном месте, что удобно в случае возникновения спорных ситуаций, а также для ведения базы знаний.
С практикой service desk пересекается практика service request management. Она подробно описывает типы заявок, которые могут поступать от пользователей, и согласованный уровень качества сервиса, который необходимо соблюдать по каждому из типов. Примерами service requests в случае нашей организации могут быть запросы на увеличение вычислительной мощности системы, обновление того или иного её компонента, предоставление доступа к ресурсам и т. д.
В работе любой команды operations есть показатели её эффективности. Как правило, в случае PaaS это такие метрики, как MTTR, RPO, RTO и другие. Практика incident management улучшает эти метрики, минимизируя ущерб от инцидентов и уменьшая время восстановления после них. Инцидентом называют незапланированное прерывание либо снижение качества сервиса. Эта практика показывает наилучшие результаты в сочетании с практикой problem management, которая уменьшает количество инцидентов, работая с их корневыми причинами, или проблемами. Проблемой называется реальная, либо потенциальная причина одного или нескольких инцидентов. Она может иметь полное (resolution) или неполное (workaround) решение, либо вовсе не иметь решения на текущий момент. В последнем случае проблема маркируется как known error и вносится в базу знаний, называемую KEDB.
Также для моей команды важна метрика change failure rate, то есть соотношение успешных и неуспешных изменений. Практика ITIL 4, помогающая мне улучшить этот показатель, называется change enablement. Изменением называется добавление, удаление или модификация составной части инфраструктуры, которая может влиять на предоставляемый сервис. Примером такой сущности может служить виртуальная машина, сетевой интерфейс, настройка оборудования или версия ПО. Изменения могут быть инициированы как заказчиком (например, для получения дополнительной функциональности), так и инфраструктурной командой (например, для устранения инцидента).
Теперь я хотел бы привести пример того, как всё описанное выше работает в связке. Допустим, пользователь сервиса заметил, что некая его часть при выполнении определённых действий выдаёт сообщение об ошибке. Вместо звонков менеджеру или сообщений в чаты, он цивилизованно создаёт заявку в системе (практика service desk). Кстати, такой подход работает в том числе тогда, когда облако используют разработчики, то есть ITIL 4 прекрасно подходит для DevOps-команд. Далее заявку принимает и обрабатывает выделенная группа инженеров первого уровня (это может быть и один человек), которая связывается с пользователем и уточняет подробности инцидента (практика service request management). На этом этапе работы группа предполагает, что инцидент произошёл по причине неправильного подключения к базе данных. Однако инженерам не хватает квалификации, чтобы самостоятельно устранить инцидент, поэтому они передают заявку на следующий уровень специалистам по облачным БД (практика incident management). В ходе более глубокого анализа группа инженеров второго уровня обнаруживает вызвавшую инцидент проблему: база данных некорректно настроена (практика problem management). Поскольку такая конфигурация исключает работу БД в штатном режиме, сформированная из старших инженеров и менеджеров change advisory board принимает решение внести экстренные изменения (практика change enablement). После применения новых настроек система тестируется, и команда приходит к выводу, что изменение прошло успешно. Группа специалистов первого уровня связывается с потребителем сервиса, который подтверждает восстановление работоспособности, и дежурный инженер закрывает заявку.
Ещё в ITIL 4 есть такие необходимые operations-командам практики, как service level agreement, monitoring and event management и прочее. Я не преследую цель описать в этой статье их все. Скорее, я хотел бы показать красоту и универсальность ITIL 4 и заинтересовать как можно больше IT-специалистов в использовании этого фреймворка.
Часть 3. Заключительная
Подводя итоги, можно сделать вывод, что знать ITIL и PRINCE2 менеджеру, как минимум, полезно. Применение этих фреймворков не ограничивается случаями, когда команда предоставляет облачную платформу как сервис. Обе методологии достаточно гибкие, чтобы использовать их в различных областях IT. Но я точно могу сказать, что применение ITIL и PRINCE2 помогает мне успешно руководить PaaS operations-командой, эффективно работающей как внутри крупной организации, так и за её пределами. Принципы и процессы PRINCE2 я использую на этапе создания сложного инфраструктурного продукта, а практики ITIL в ходе различных фаз его эксплуатации.