Однажды Роза Бертэн, личная портниха французской королевы Марии-Антуанетты, слегка подновив старое платье королёвы, предложила его королеве, и та с удовольствием его приняла. «Новое — это хорошо забытое старое», — прокомментировала этот случай портниха.
Из мемуаров (1824) Розы Бертэн
Поступательность в единстве с преемственностью составляет суть диалектического развития
Конспект лекций по философии
Если вы решили первым стать в рядах своих сограждан —
Никогда не догоняйте устремившихся вперед.
Через пять минут, ругаясь, побегут они обратно,
И тогда, толпу возглавив, вы помчитесь впереди!
Мое любимое стихотворение Григория Остера
В последнее время часто говорят о необходимости быстрой разработки и внедрения изменений в приложениях и о кризисе традиционной ИТ-поддержки, которая описана в лучших практиках, в том числе в библиотеке ITIL.
Так что же, подходы ITIL поколеблены и он безнадежно устарел или все-таки не все так плохо? Попробуем в этом разобраться и понять, что в ITIL останется незыблемым, а что нужно будет совершенствовать согласно современным вызовам. В своих рассуждениях я буду использовать идеи, которые уже были высказаны до меня авторитетами в области разработки, только мы будем рассматривать их через призму задач поддержки.
В менеджменте, как, впрочем, и в остальных областях человеческой деятельности, люди часто пытаются отказаться от уже существующего и строить все с чистого листа. Но, как мне кажется, многое из того, что будет использовано для быстрых изменений, можно взять из существующих практик или они будут являться их следствием с необходимыми корректировками в соответствии с текущим моментом (и это согласуется с принципами, изложенными в книге ITIL Practitioner). Конечно, в текущей версии ITIL вопросы разработки освещены, скажем так, весьма скудно. Будем надеяться, что этот недостаток будет исправлен в следующей версии ITIL, а пока попробуем показать, какие изменения могут претерпеть лучшие практики в этой области.
Как говорит ITIL, услуга – это способ предоставления ценности заказчикам через содействие им в получении конечных результатов, которых заказчики хотят достичь без владения специфическими затратами и рисками. ИТ-услуга включает в себя информационные технологии, процессы и людей. Бизнес-приложение является только частью услуги, несомненно важной, но только частью.
На общей схеме услуги мы видим, что ИТ-услуга поддерживает бизнес-процессы и может включать в себя ИТ-инфраструктуру, приложения, данные, физическое окружение, команды поддержки и подрядчиков.
Одним из основополагающих принципов ITIL является понятие ценности предоставляемой услуги. А ценность, в свою очередь, складывается из полезности и гарантии.
Полезность часто выглядит как новый функционал, который требуется заказчику. В современных условиях ценностью для заказчика также является возможность быстрого предоставления и использования нового функционала, в некоторых случаях на конкретный период.
Но ценность ИТ-услуг без гарантии – ничто: нужно гарантировать, что параметры ИТ-услуги всегда будут оставаться в согласованных пределах, т.е. риски, возникающие в ходе предоставления такой новой возможности, будут выявлены и управляемы. К тому же на организацию поддержки влияют факторы, исходящие из организации разработки приложений. Исходя из этого, попробуем рассмотреть, какие дополнительные основные риски для гарантии предоставления и поддержки ИТ-услуг возникают, и какие есть мероприятия и механизмы, которые помогут с ними справиться.
Потребность в быстрой разработке приложений вызвала к жизни такие новаторские подходы организации разработки как scrum или микросервисы. Кратко опишем их, выделив те факторы, которые будут влиять на организацию поддержки:
Рассмотрим риски, используя приведенный в ITIL подход жизненного цикла услуги. В небольшой статье трудно учесть все риски, но все же попробуем разобрать некоторые из них:
Данный риск и раньше рассматривался в ITIL. Говорилось о несоответствии скорости реакции ИТ на новые требования бизнеса. Ситуация еще более обостряется. Часть услуг теперь будет изменяться очень часто, возможно практически непрерывно. Какие же меры по уменьшению этого риска можно перечислить?
Согласно рекомендациям лучших практик, для начала необходимо определить заказчиков, у которых будут такие требования, и услуги, которые будут затрагиваться этими требованиями. Заметим также, что согласно подходам по совершенствованию ITIL, такая деятельность должна будет выполняться постоянно для мониторинга изменений как по заказчикам, так и по услугам.
Если рассматривать существующую модель ITIL, то данная деятельность, с точки зрения ITIL, может выглядеть как часть дополнительной деятельности по анализу влияния на бизнес (business impact analysis). После определения таких услуг необходимо перестроить в них работу – создать новые модели (pattern) управления для других этапов жизненного цикла услуги, в особенности это касается этапа преобразования услуги.
В качестве примера создания одной из таких новых моделей управления попробуем определить новый тип изменения, который отвечал бы требованиям к частому изменению приложений, а значит и ИТ-услуг, если рассматривать это с точки зрения терминологии ITIL.
Для простоты назовем данный новый тип изменения «быстрым» («quick»). В существующей библиотеке ITIL наиболее близким к нему является стандартный тип изменения, но есть нюансы J. Например, «быстрое изменение» (далее я буду применять данный термин без кавычек) также несет черты экстренного изменения ITIL (инициация в любой момент, отложенное документирование), а также включает в себя элементы пилотного внедрения. Опираясь на ранее разобранные факторы разработки приложений, можно говорить о том, что быстрое изменение:
Разработка приложений, ведущаяся хаотично без какого-либо плана, рано или поздно приведет к критичным сбоям в работе ИТ-инфраструктуры и прерыванию ИТ-услуг, критичных для бизнеса. Нужен механизм, ограничивающий хаос, нужен «управляемый хаос».
Если распространить идеи быстрой разработки приложений на практику поддержки, то можно предложить путь, дающий возможность защитить гарантию услуги от данного риска – разделить все активы ИТ-услуг на два типа:
Соответственно изменение «базовых компонентов» будет происходить как проекты или как нормальные (normal) изменения ITIL, изменение «динамических» – потребует новых подходов. «Динамические компоненты» можно рассматривать как расширение понятия «компонент приложения», но «динамический компонент» должен рассматриваться в рамках всей услуги, а не только одного приложения. В общем случае в «динамический компонент» услуги могут входить компоненты всех элементов услуги, связанные с компонентом приложения. В чем-то динамический компонент можно рассматривать как реинкарнацию понятия единицы релиза, о котором говорится в ITIL. Данное разделение может быть определено через политики жизненного цикла услуг и введено в классификацию активов услуг.
Далее в этой статье под термином «компонент» для краткости я буду иметь в виду термин «динамический компонент» услуги (далее буду использовать его без кавычек) и рассматривать только этот тип компонентов.
Ужесточение требований к скорости реализации требований бизнеса с сохранением гарантий качества предоставляемых услуг требует от разработчиков и специалистов поддержки соединить свои усилия и наконец-то понять, что их миры должны как минимум сблизиться, а как максимум – слиться в некий симбиоз. В подходах разработчиков говорится о команде по продукту, с точки зрения лучших практик, нужно говорить о команде по услуге. В ITIL уже есть владелец услуги, отвечающий за услугу на протяжении её жизненного цикла. Ему явно не хватает команды по услуге, в которую органично впишутся разработчики. И данное положение не противоречит подходам ITIL, а только дополняет их. Поддержке придется жить в неспокойном мире максимальной полезности, в котором частые изменения будут рутинными событиями, а разработчикам – привыкать заботиться о гарантиях предоставляемых услуг.
В состав группы по услуге могут входить:
Несмотря на то обстоятельство, что «железо» является одним из самых тяжело изменяемых элементов ИТ-услуги, придется меняться и ему. Автор не является глубоким экспертом в области методов построения гибкой ИТ-инфраструктуры, но полагает, что успехи, демонстрируемые в последнее время в области виртуализации ИТ-инфраструктуры, помогут делу и позволят снизить данный риск. Здесь уместно вспомнить такие подходы, как инфраструктура как услуга (Infrastructure-as-a-Service; IaaS) и архитектура Serverless, расширяющиеся границы гибкости ИТ-инфраструктуры. Поскольку динамические компоненты услуги могут включать в себя и «железо», то часть требований бизнеса может быть осуществлена за счет гибкой перенастройки части ИТ-инфраструктуры в ходе быстрых изменений, и это должно быть отражено в лучших практиках.
Давление заказчиков в части уменьшения времени внедрения их новых требований приводит нас к уменьшению времени на разработку приложений, что неминуемо повышает риски того, что в жизненную среду попадут приложения с серьезными ошибками.
Да, конечно, этот риск в первую очередь будет минимизироваться самими разработчиками через применение более совершенных систем разработки и тестирования, использование проверенных наборов стандартных библиотек, максимальную близость сред разработки, тестирования и эксплуатации, максимальную автоматизацию постоянно совершенствующейся системы тестирования, но, тем не менее, такой риск не может быть полностью компенсирован только командами разработки.
Здесь я хотел бы высказать мысль, которая может вызвать возражения – в ряде случаев нам придется пропускать ошибки в динамических компонентах в среду эксплуатации и отлавливать их уже там, и тогда задача сводится к тому, как помочь поддержке это сделать быстро и незаметно, чтобы появление такой ошибки не создавала панику в рядах поддержки и решалась бы как незначительный рядовой инцидент, почти не влияющий на бизнес.
Чем же разработчики на данном этапе могут помочь поддержке? Одним из принципов новых подходов в разработке является разработка приложения с возможностью продолжать работу при частичном сбое и (или) возможность быстрого отката при полном отказе. В ходе разработки можно заложить в приложение элементы встроенного мониторинга, которые могут стать частью общей системы мониторинга поддержки как на уровне ИТ-инфраструктуры, так и на бизнес-уровне.
При возникновении данных событий:
Данный большой риск обитает в самом интересном месте – разработанный динамический компонент внедряется в среду эксплуатации. Плюсом, понижающим данным риск является независимость и малоразмерность внедряемого объекта. Минусом, причем большим – это будет делаться часто, местами непрерывно.
Для начала попробуем более детально разобрать, каков перечень этих неудач, как может выглядеть реализация такого быстрого изменения и какие механизмы могут быть задействованы.
Итак, неудачи быстрых изменений с точки зрения поддержки будут следующие:
Последовательность реализации быстрого внедрения, исходя из подходов быстрой разработки приложений и положений ITIL в области преобразования ИТ-услуг, может включать в себя следующие шаги и механизмы:
В поддержке нам будет необходимо контролировать не одно, а много быстрых изменений и отклики на них в виде инцидентов и обращений пользователей. Здесь нам поможет система мониторинга, связанная с базой конфигураций, в которой должны будут фиксироваться все динамические компоненты и их связи с поступающими после быстрого изменения обращениями и инцидентами. Это будет развитием идей ITIL о постоянном контроле за работой ИТ-инфраструктуры.
Возможными статусами динамических компонентов могут быть следующие:
или в случае неудачи
Таким образом, может быть сформирована карта мониторинга и обеспечена возможность сообщать об изменениях всем заинтересованным сторонам и наблюдать за ростом отклонений и возможность своевременной реакции на это, в том числе автоматической.
Первоочередными мерами решения проблем, вызванных изменениями динамических компонентов, вероятно, будут либо откат к первоначальному состоянию, либо, если это допускает ситуация, быстрая коррекция и повторное внедрение. Необходимо заранее разработать типовые обходные решения проблем, ибо времени на нахождение их решения будет мало. Проблемы могут заключаться в следующих областях:
Первая линия поддержки должна быть в курсе статусов изменений всех динамических компонентов в режиме online, чтобы оказывать поддержку пользователей и формировать статистику по успешности проводимых быстрых изменений.
Здесь нужно понимать, кто на первой и на второй линиях поддержки и в какой форме должен получать такую информацию. Необходимо организовать обмен знаниями, который отвечал бы следующим требованиям:
Если проводимые быстрые изменения будут менять интерфейс или логику работы услуги, то они могут вызвать поток обращений пользователей, вызванных неосведомленностью о таких изменениях или нехваткой знаний или умений, которые будут следствием таких изменений. Необходимо организовать консультации пользователей по проводимым изменениям (чем на практике часто пренебрегают) и своевременное обновление баз знаний для пользователей.
Один из вариантов – организовать точечную блиц-поддержку, встроив в изменяемое приложение или страницу сайта интерфейс взаимодействия с поддержкой в виде чата или звуковой связи. Также необходимо продумать всплывающие подсказки и ссылки на базу знаний по наиболее часто возникающим у пользователей вопросам.
Одна из трудностей здесь – определение, что необходимо изменять в базе знаний в ходе быстрого изменения и реализация быстрого внедрения таких обновлений.
В ходе изменения динамического компонента возможна схема, при которой какое-то время будет осуществляться параллельная работа в среде эксплуатации обеих версий компонента. Вот тогда будет необходима поддержка двух групп пользователей: пилотной, у которой новая версия, и всех остальных – со старой версией. Поддержка должна быть в курсе, какая версия компонента установлена у обращающегося в поддержку пользователя, следовательно, нужен механизм контроля всех пользователей пилотной группы и времени перевода остальной части пользователей на новую версию.
Лучшие практики потому и должны быть лучшими, что они должны отвечать на новые вызовы времени. Как мы видим, в ITIL есть основа, которую можно и нужно развивать.
Существующие описания организации быстрой разработки больше фокусируются на организации разработки приложений, а существующую версию ITIL часто и, наверно, справедливо критикуют за высокоуровневость и чрезмерную научность. Но многие положения и идеи ITIL, уже имеющиеся там, будучи конкретизированы и соединены с новыми подходами разработки, дадут необходимые ответы на вопрос: «Как нам организовать поддержку в этих новых условиях?». Будем же надеяться, что новая версия ITIL расскажет нам об этом и пожелаем ITIL удачи в этом деле.