Подписаться
Читать в телеграм
Рис. 1. Этапы приемки прикладного ПО в эксплуатацию
1) Мы изучаем состав бизнес-приложения и определяем перечень необходимых компетенций для осуществления поддержки. Далее сопоставляем с ним компетенции наших специалистов, чтобы понять узкие места. Возможно, у нас отсутствуют глубокие знания по тем или иным направлениям или недостаточно свободных ресурсов. В первом случае мы либо проводим обучение своих специалистов, либо пополняем команду нужными экспертами. Во втором у нас нередко есть возможность качественно обучить специалиста из смежной области, который, например, имеет неполную загрузку и хотел бы освоить еще один продукт.
Отметим, что поиск специалиста со стороны не всегда оправдан с экономической точки зрения. У хороших внешних экспертов нужная компетенция зачастую идет в сочетании с другими, не менее ценными на рынке, но невостребованными у нас знаниями.
Этап сложен тем, что надо не просто выявить необходимую компетенцию, но и найти исполнителей, которые будут с огоньком в глазах ею заниматься и развивать. Например, у нас в свое время был разрыв между прикладным и системным ПО в части серверов приложений. Для инфраструктурщиков, занимающихся операционными системами, это слишком высокий уровень, больше уровень приклада, нежели системы. Для прикладников же это очередной системный черный ящик, на котором крутится их приложение. В итоге мы нашли людей среди наших инженеров, которые были заинтересованы в том, чтобы заполнить эту нишу.
2) Далее мы делаем прогноз трудозатрат по методике, основанной на нашем опыте эксплуатации аналогичных бизнес-приложений. Она актуализируется каждые 2 года.
3) Проводится анализ документации на бизнес-приложение на предмет полноты и соответствия требованиям и рекомендациям производителей ПО и компонентов. По итогам мы решаем либо устранять недостатки документации до постановки приложения на обслуживание, либо принять документацию и в дальнейшем разбираться с проблемными местами. Формируется список ключевых участков системы, требующих детальной проверки.
С одной стороны, это самый простой этап, с другой – самый сложный. У небольших компаний документация на бизнес-приложение зачастую отсутствует полностью, поскольку их ИТ держатся на одном/двух высококвалифицированных специалистах. Другой случай – документация есть, но ее актуальность оставляет желать лучшего. Такое бывает у крупных заказчиков с амбициозными проектами и внедренцами со стороны. Проект реализовали, документацию передали (всю или частично), на ее актуализацию сил уже не осталось.
4) Обследование системы позволяет выявить ее несоответствия документации. По результатам формируется документ, описывающий найденные недочеты/несоответствия. Далее принимается решение об исправлении документации, либо об устранении на уровне бизнес-приложения.
5) На этапе испытаний мы проверяем работу функционала для администрирования бизнес-приложения. В качестве тест-кейсов используется инструкция для администраторов, по которой они в дальнейшем будут поддерживать ПО.
По сути, надо проверить, что заявленный функционал в принципе работает, что кластер, например, сможет переключиться на резервную ноду за требуемый промежуток времени. Бывают случаи, когда заказчик хочет, чтобы простой был максимум в несколько минут, а кластер при этом работает в ручном режиме. Или кластер в автоматическом режиме, но время переключения никто до нас не проверял. Мы отлавливаем все эти тонкости.
6) При разработке требований для мониторинга формируется список метрик, устанавливаются критичность, время реакции и прочие параметры, которые необходимы для выполнения мониторинга бизнес-приложения и соблюдения SLA. В случае с поддержкой бизнес-функционала, помимо стандартных метрик уровня базиса, может понадобиться разработка скриптов.
На этом этапе очень важны плотный диалог с заказчиком и определение метрик, по которым бизнес оценивает работу ИТ. Желательно иметь терпеливого переводчика с одного «языка» на другой, так как ИТ обычно оперирует «серверами» и «размерами баз данных», а бизнес – «неотправленными фурами» и «недополученной прибылью». Мы умеем настраивать именно бизнес-мониторинг. Один из последних примеров – наша разработка и визуализация мониторинга для личного кабинета на портале для клиентов «ЛИКАРД».
7) Последний шаг – формирование структуры базы знаний, которая необходима для накопления информации об инцидентах и способах их решения, на внутреннем портале. Также на этом этапе происходит первичное наполнение этой базы данными, которые не отражены в документации, но могут быть полезными для уменьшения трудозатрат на выполнение стандартных операций. Это экономит ресурсы и позволяет правильно распределить рутину между сотрудниками. Конечная цель – автоматизировать как можно больше операций.
