Представьте, что вы запустили внутреннюю платформу сервисов для разработчиков и DevOps‑команд: хранение кода, инструментарий для CI/CD, контейнеризация (или иной способ выполнения приложений), логирование, мониторинг и т. д. и т. п. и др. и пр.

Пошли потребители. 1, 2... 10-й... 20-й... Вы понимаете, что для их обслуживания вручную в приемлемые сроки вам не хватает «рук». Еще и пользователи создают заявки, используя человеческий язык запросов, трудно поддающийся автоматизации. Из‑за спешки и стресса начали появляться сбои. Итог: вместо работы над улучшением платформы вы занимаетесь разборами жалоб и инцидентов.

Представили?

Как мы пытались решить проблемы и получали новые

Ранее мы упоминали нашу Единую Цифровую Платформу (ЕЦП) — классическая «platform team» делает «Internal Developer Platform» (IDP) — набор сервисов для разработчиков и команд внедрения и сопровождения проектов и информационных систем.

Платформа заслуживает отдельной статьи, а тут я хочу рассказать про обслуживание её потребителей.

С появлением первых сервисов ЕЦП к нам стали приходить запросы на создание новых пространств, инстансов, бакетов, топиков; предоставление к ним доступов и иные запросы на изменения или поддержку. Основным каналом для данных обращений стала электронная почта. Email сейчас есть, наверное, в каждой организации: пишите письмо на определенный групповой ящик — получаете запрашиваемое.

Больше пользователей — больше заявок: в групповом ящике сложно разобраться или отслеживать SLA. И мы завернули заявки на внутреннюю ITSM‑систему.

Однако, с ростом числа пользователей платформы, стало понятно, что необходимо менять подход: на обработку этих заявок стало уходить все больше и больше ресурсов.

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

Основной проблемой было то, что заявки оформлялись в свободной форме.

И, чтобы хоть как‑то систематизировать поток сознания и уйти от «дайте доступ в gitlab», мы постарались подготовить максимально подробное описание того, какую информацию необходимо предоставить и в каком виде: сделали даже шаблоны обращений — достаточно было кликнуть на ссылку, чтобы генерился текст шаблона.

Что оказалось на практике

• Документацию читают единицы. Если мы решили обновить шаблон заявки — скорее всего, этого никто не заметит в ближайшие полгода‑год: не перечитывать же документацию от корки до корки каждый раз, когда необходимо запросить, например, виртуальную машину. Необходим был способ передачи запросов в виде всегда актуальных форм. Файлы табличных процессоров не спасали — они так же не обновляются, заявители пересылают старые с минимальными изменениями.

  

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

  

• Опечатки — это проблема. Решение — автоматические проверки при вводе или отправке формы — это и как «простые» регулярные выражения, так и проверки относительно справочников и каталогов.

  

• У нас достаточно ощутимый процент подрядчиков работает с Платформой. При приходе на проект они ничего не знают про наши процессы, а мы не хотим им платить за неосновную работу типа изучения наших регламентов и шаблонов. Впрочем, любые разработчики приносят наибольшую пользу, когда разрабатывают ПО. Конечно, всегда можно написать email в чатик, в котором скажут про другой чатик, в котором подскажут кого‑то, кто расскажет, как он добился чего‑то от Платформы и порекомендует свой уникальный алгоритм, скорее всего неточный из‑за уже неоднократного применения «испорченного телефона», либо устаревания процесса или шаблона.

Качественное изменение вместо сжигания ресурсов

Можно было продолжать делать, как раньше, «докидывая» людские ресурсы в команду поддержки платформы и создавая новые шаблончики и инструкции. Но мы решили пропилотировать кардинальное изменение в подходе — Портал самообслуживания, который бы позволил создать под каждый запрос соответствующую форму с необходимыми проверками, цель которого отправлять нам от лица заявителей правильно составленные и отформатированные заявки в ITSM‑систему.

Однако, после разработки MVP мы быстро пришли к пониманию, что можно не просто принимать заявки, но и связать Портал с системой автоматизации стандартных изменений, чтобы отправлять запросы и инициировать их выполнение. На начальном этапе для исключения ошибок решили использовать ручную проверку заявок командой Платформы. Так родилась «админка» заявок с возможностью отслеживания, выполнено ли обращение, какие из них ожидают проверки и запуска (передачи на автоматическое исполнение).

Забегая вперед, но не уходя от темы админки: со временем мы решили, что формы‑заявки самообслуживания настолько защищены от ошибок их составителей, что мы можем перестать их проверять и сразу отправлять в автоматическое исполнение.

Возвращаясь к истории: запустили Портал, пошли заявители, начали заводить заявки. Всё, как на первой картинке в посте. Но у нас не «ресторан» быстрого питания: заказчик не просто покушал, потребив сервис до «нуля», и ушел. Мы и наши пользователи задались классическими вопросами совместной работы множества команд: какие сервисы запущены, в какой среде, кто ими владеет и управляет. Можно было бы смотреть все это по каждому сервису в отдельности средствами его управления, но обычно отдельный сервис платформы мало кому нужен, а нужна полная картина в рамках проекта или ИС. Так мы пришли к необходимости создания:

• Ролевой модели: кто чем владеет и что может делать

• Справочников, которые позволяют, например, получить информацию о ролях в экземплярах сервисов Платформы (к ним можно обратиться за предоставлением прав), или оценить выделенные ресурсы под различные приложения

• Каталога Информационных Систем (ИС), как мы его называем. Идея строится вокруг желания связать отдельные сервисы между собой на уровне понятных бизнес‑сущностей — приложений, для создания и сопровождения которых используются наши сервисы. ИС — это сведенный вместе набор сред, ответственных, ссылок, связей с компонентами и сущностями ИС. Это не только удобное и наглядное отображение для команд, но и документация для онбординга, и данные для управления мощностями, изменениями и иными процессами вокруг ИТ‑оборудования и сервисов. Например, оценить, на каких хостах виртуализации и СХД располагаются ноды кластера, чтобы убедиться, что выход оборудования из стоя не повлечет за собой даунтайм информационной системы

Портал самообcлуживания - зачем?

В итоге мы получили Портал самообслуживания, который позволяет:

• Заявителям использовать всегда актуальные шаблоны заявок по лучшим практикам и патернам и стандартам использования сервисов Платформы с автоматическими проверками ввода на ошибки

• Производить onboarding "своих" и подрядчиков: Портал - самоактуализирующаяся база знаний. Люди приходят и уходят. Сервисы приходят и уходят, выводятся из эксплуатации, плодятся кластеры и зависимости. Портал показывает актуальные и доступные сервисы, заявки, ИС и их компоненты

• Запускать стандартные изменения на выполнение автоматически без участия людей

• Не изучать процессы. Процессы меняются, но Портал заставляет использовать самые актуальные

  • А там, где процессов не было, или они были неточными, при внедрении Портала пришлось их разработать или уточнить

• Не знакомиться с ответственными за исполнения личностями: перед вами бездушный Портал самообслуживания, который работает 24х7, а не конкретный Иван Петрович, который когда-то выполнял похожую заявку и может помочь лично, если конечно он не занят, или не в отпуске

• Наладить взаимодействия между подразделениями, ведь теперь каждый видит одну и ту же информацию в одних и тех же терминах и определениях

Есть качественные результаты и на языке управления:

• Кардинально уменьшились

  • Time To Market (T2M)

  • Error rate: количество сбоев и ошибок из-за неправильно поданных данных для операции, или же использования нешаблонных настроек

  • Нагрузка на команду поддержки: все заявки проверяются на ошибки при заполнении, данные для выбора предлагаются из справочников

    • А часть заявок выполняется автоматически без участия сотрудников, что в реальности еще и помогает справляться с "наплывами" заявок, например, при массовом старте проектов.

  • Удовлетворенность платформой увеличилась

Не просто формы для заказа

Портал - это постоянное развитие и бег за

• Потребностями наших пользователей

• Процессами

• Изменения и эволюции лучших практик и подходов

• Изменения в составе сервисов самой Платформы

Давайте еще вот такой "IF" добавим в заказ сервиса...

Важно отметить, что Портал дает не только новый пользовательский опыт, но и постепенно начинает перестраивать процессы внутри компании, так как позволяет взглянуть на различные ИТ‑сервисы с ракурса их потребителей. Это выражается в попытке показать, что за ИТ‑сервисом стоят вполне конкретные ИТ‑сущности (например, ВМ), которые на самом деле используются для доставки бизнес‑ценностей через ИС. А за счет возможности управления этими ИТ‑сущностями у команд появляются необходимые инструменты для повышения скорости и качества решения бизнес‑задач.

В частности, в наших амбициозных мечтах постепенный переход в сторону подхода IaC, когда большинство ИТ‑сервисов доступны через программный контракт — API‑интерфейс, что дает возможность с точки зрения пользовательского опыта перехода на их управления через единую точку входа и в привязке к понятным для пользователей бизнес‑сущностям.

На том же примере с виртуальными машинами это означает возможность их добавления к информационной системе, управления (изменения конфигурации, перезагрузки) через интерфейс Портала без привязки к какому‑то определенному «бэкэнду» для этого — коробочная система виртуализации {{ BRAND_NAME }} или частное/публичное инфраструктурное решение.

За счет ежедневного использования Портала со стороны разных групп пользователей, мы сможем значительно повысить шансы на актуальность информации о приложениях и их компонентах, ответственных за них. По нашему убеждению, любые административные меры, заставляющие команды разработки и сопровождения готовить документацию по определенным, зачастую не понятным шаблонам, не очень сильно эффективны. Равно как и плохо соблюдаются требования работать в интерфейсах классических корпоративных CMDB для заполнения информации об очередных КЕ, даже если это поставить в KPI. Например, лучше обновлять данные в CMDB по результатам выполнения заявки на изменение, а не вносить изменения вручную копируя из системы заявок в систему учета.

На мой взгляд, все объясняется просто — если ты не видишь ценности от использования инструмента / выполнения требования, то желание делать это у тебя резко уменьшается. Именно поэтому мы стараемся отталкиваться, в первую очередь, от пользовательского опыта, создавая удобный интерфейс для взаимодействия с ИТ.

Пример зависимости от UI

Мы создали на Портале форму для заказа с кнопкой, которая добавляет дополнительные поля запроса, дабы заявитель мог подать множество заявок в рамках одной. Прошло некоторое время, в ручном анализе я столкнулся с лавиной однотипных заявок без использования дополнительных полей: 12 заявок вместо 1 — обычное дело. Я пошел общаться с пользователями Портала. Оказалось, что часть пользователей не «видит» кнопку добавления дополнительных полей, поэтому создает 1 заявку на 1 поле. Сделали кнопку заметно‑кричащей — и это помогло!

Безусловно, на это все накладывается специфика enterprise'а — например, появление любой новой ИС в компании с точки зрения процесса требует различных точек контроля. Еще до начала разработки выглядит логичным консультация с коллегами из корпоративной архитектуры на предмет логичности реализации той или иной функциональности именно в этом приложении — возможно, какие‑то задачи уже реализуются/запланированы в других системах. Также важным моментом является определение систем, которые будут выступать как источники, с какими — нужно интегрироваться для передачи данных.

Помимо этого, развертывание новой системы — это еще и повод сходить к коллегам из ИБ, особенно, если приложение будет опубликовано в интернете. Проверка на соблюдение всех требований и ревью архитектуры с точки зрения планируемых технических решений по аутентификации и авторизации, передачи событий безопасности для аудита в SIEM — все это довольно важный с корпоративной точки зрения этап.

И я вижу Портал, как решение для объединения всех заинтересованных лиц в одном месте, но с фокусом на пользовательский опыт. Причем не только команд, планирующих развертывание новых систем, но и остальных участников процесса.

Единый размер не подойдет всем

Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по‑своему.

© Л.Н. Толстой, «Анна Каренина»

Я же согласен с John Cutler, что все проблемные компании похожи друг на друга, а вот счастливые или высокопроизводительные компании могут быть очень и очень уникальны.

В этом посте наша история, а подход универсален — не привязан к компании или индустрии. Рассказанное подойдет всем в той или иной мере. Кому‑то нужно меньше безопасности или больше финансов, а, возможно, борьба с «shadow IT», или куча других вариантов. Скорее всего, вам не требуется самообслуживание для всего, попробуйте оттолкнуться от ваших пользователей, используя продуктовый подход, и тоже делитесь вашим опытом на Хабре.