Как связаны аудит и консалтинг
В чистом виде ИТ-аудит редко интересен компаниям. Узнать, что в бизнес-процессах или ИТ-инфраструктуре что-то идет не так, недостаточно. Надо понимать, что с этим делать. Поэтому, кроме предоставления результатов аудита и их интерпретации, заказчики хотят получить рекомендации о дальнейших действиях. Аудитор может предложить как составление верхнеуровневого описания дальнейших действий, так и детальный план работ для реализации необходимых изменений в затрагиваемой аудитом области.
Для аудитора, получившего в процессе обследования понимание о процессах в организации, также будет логичным предложить компании консалтинговые услуги или техническое сопровождение реализации предлагаемых изменений. Далеко не всегда ИТ-служба заказчика обладает компетенциями для планирования и запуска такого проекта. Например, она не может выделить достаточных внутренних ресурсов или не обладает компетенциями по формированию комплексных технических решений, включающих различное ПО и оборудование разных производителей, или не имеет необходимого опыта их эксплуатации и возможности провести соответствующее обучение. Опыт системных интеграторов показывает, что для большинства современных российских компаний привлечение внешнего партнера для реализации масштабных изменений в области ИТ является стратегией наименьшего риска.
Главное – управление рисками
Для успешного проведения аудита главное – одинаковое понимание всеми заинтересованными сторонами целей и результатов проведения проверки. Аудит может включать множество аспектов и объектов обследования – систему управления ИТ, цифровую зрелость бизнеса, компоненты инфраструктуры, проект создания информационной системы, затраты на ИТ, защиту сетевого контура, процессы поддержки устойчивости бизнеса, соответствие нормативной и регламентирующей документации требованиям и многое другое. С точки зрения управления проектом аудита главный риск – отсутствие результата в поставленные сроки. Например, затягивание сроков проведения работ, незавершенность или неточность обследования, ошибочная интерпретация полученных данных. Чтобы снизить вероятность проявления этих рисков, руководству необходимо быть непосредственно вовлеченным в проект, не только осуществлять мониторинг результатов, но и устранять препятствия.
Бывают ситуации, когда сохранение незакрепленных документально, но действующих на высоком уровне договоренностей важнее возможных результатов формализованной проверки их эффективности, например, при использовании сложных схем лицензирования программных продуктов. Информационные системы могут фактически находиться в собственности одного заинтересованного лица, но формально быть «размыты» по трем юридическим лицам. Так, доступ к системе для одной компании предоставляется как услуга второй компании, при этом в стоимость услуги включена аренда инфраструктуры у третьей компании. То есть физически система представляет собой трехслойный пирог. Первый слой – вычислительные мощности третьей компании, передаваемые в аренду второй компании. Второй слой – инфраструктурное ПО, установленное на этих мощностях, лицензированное на третью компанию, но сдаваемое в аренду второй. И наконец, третий слой – информационная система в виде серверов приложений и баз данных, развернутая поверх инфраструктурного ПО и лицензированная на вторую компанию. Таким образом, весь этот «пирог» оплачивает первая компания, покупая услугу доступа у второй. Механизм формирования стоимости такой аренды не всегда понятен внешнему наблюдателю и может казаться экономически неэффективным для первой компании. При этом вся сложность продиктована, например, необходимостью прозрачного и динамичного формирования затрат на лицензирование по количеству рабочих мест, которое сильно зависит от сезонности в ряде случаев.
Как аудит помогает находить узкие места в ИС
Независимо от типа аудита рекомендуется его проводить по лучшим стандартам и практикам. Среди них – подход ITAF, разработанный международной организацией аудита информационных систем ISACA (сейчас этот подход является одним из разделов их структурированной методологии по управлению ИТ в организациях – COBIT версии 2019). В соответствии с этим подходом проект аудита включает такие этапы, как управление рисками, планирование аудита, проведение аудита, выработка рекомендаций и подготовка отчета.
Перед непосредственным сбором информации обычно проводят разработку методов сбора и обработки информации, которая позволяет ограничить персонал аудируемой компании от лишних волнений и заполнений ненужных форм. Перед началом технического аудита системы необходимо заранее согласовать применяемые процедуры и область данных, которая может быть затронута проверкой.
Существующие средства анализа ИС позволяют проводить как проверку безопасности, так и тестирование, имитирующее работу множества пользователей в системе. Подобные проверки позволяют найти узкие места в инфраструктуре или, наоборот, в программных элементах системы. Если какие-то компоненты не выдерживают нагрузки, выполняется дополнительный анализ этого участка. В зависимости от поведения системы может проводиться анализ настроек оборудования и middleware, а также изучение кода на наличие неоптимальных алгоритмов работы с данными или компонентами системы.
Важно помнить, что технический аудит должен учитывать соответствие уровня доступа к бизнес-критичным или защищаемым данным третьих лиц не только сотрудников компании, но и аудитора. Помимо самой системы и ее компонентов анализируется история внесения изменений в программный код, охват проекта и архитектура системы. После анализа информации проводятся необходимые оценка и выработка рекомендаций. При использовании такого подхода аудит сможет выявить не только последствия вносимых в систему изменений, но и причину их внесения. Часто в ходе аудита выясняется, что влияние конкретных лиц на процессы разработки системы привело к несоблюдению намеченного графика и последующему отставанию в реализации значимых этапов.
Изначальная потребность в определенной проверке может привести к формированию собственных компетенций по аудиту на постоянной основе или к привлечению внешних сертифицированных аудиторов на проект. Например, некоторые компании создают подразделения внутреннего аудита, которые разрабатывают и отслеживают работу системы автоматизированных контролей, встраиваемых в системы исполнения бизнес-процессов. Внутренние аудиторы контролируют как работу информационных систем, так и исполнение бизнес-процессов, выявляя узкие места и возможности оптимизации.
Все ходы записаны: анализ хода проекта
При проведении анализа функциональных возможностей информационной системы производится сопоставление изначальных требований, заявленных в техническом задании или зафиксированных в бэклоге системы управления разработкой и реализованных функциональных возможностей. Обязательно должны быть учтены все вносимые изменения – кто их внес, кто именно согласовал, как они повлияли на сроки и бюджет проекта. Как правило, потребность в таком аудите возникает, когда проект не приносит ожидаемых результатов к заявленному сроку или значимому событию. В данном случае не важна парадигма, в которой система создается, будь то каскадный или гибкий подход, главное – соответствие требованиям заказчика. Даже проект гибкой разработки может «свернуть не в ту сторону», если, например, команда пошла на поводу у наиболее влиятельных, «громких» сотрудников, которые при этом не отвечают за весь ход проекта, а заинтересованы только в выполнении своей части. Если аудит выявляет подобное влияние, это сигнал для вышестоящего руководства – проекту потребуется гораздо больший контроль, хотя бы на этапе пересмотра его охвата (scope). Разрыв между требованиями и реализованными функциями может нарастать к сроку завершения проекта. Следует помнить, что реализация изменения, вносимого в уже запущенный проект на поздних сроках, обойдется дорого. Именно поэтому все значимые изменения должны выноситься на обсуждение ответственных лиц, а их решения – быть отражены в протоколе.
Причины возникновения «разрывов»
Причинами изменений, не входивших в план заказчика, могут стать не только влияние отдельных ответственных лиц, но и инциденты в самой проектной команде. Когда речь идет о крупном проекте, к работе над ним могут подключать сразу несколько команд разработки. Если архитектор не контролирует реализацию, а руководитель не оркеструет взаимодействие команд, могут возникать инциденты: неработоспособность системы в ходе неожиданного для многих penetration теста или проведение нагрузочного тестирования без согласованного ранее расписания может заблокировать ввод в эксплуатацию нового функционального блока и так далее. Особенного внимания требуют ситуации, когда система обеспечения непрерывности, регламенты резервного копирования и регламенты восстановления работоспособности еще не проработаны, а в эксплуатации уже находятся «боевые» базы данных.
Могут возникать и технические инциденты. Например, в 2019 году в Москве из-за короткого замыкания в системе кондиционирования и возникшего в связи с ним пожара в ЦОД DataLine (Tier III) более чем на 15 часов была парализована работа многих публичных высоконагруженных сервисов.
А еще менеджер продукта может «набросать» макет в no-code-платформе и требовать его интеграции в систему, игнорируя правила безопасности, технические ограничения и здравый смысл.
Затраты на инфраструктуру
Выбор модели затрат на эксплуатацию ИС зависит от интересов бизнеса к капитализации и перспективы развития этой системы. Иногда системы лучше размещать только на собственном оборудовании заказчика, например, защищенных контурах государственных информационных систем. Или, напротив, на стороне провайдера – брокерские компании, работающие с иностранными биржами, предпочитают размещаться на наиболее «близких» к ним площадках (близость измеряется как географически, так и числом промежуточных сетевых узлов), ведь для эффективного использования торговых роботов могут быть критичны миллисекунды задержки сетевого трафика.
В любом случае, выбирая услуги провайдера или собственное оборудование, надо учитывать план развития системы: историческое изменение нагрузки, возникновение пиковых моментов, даже изменения в бизнесе, которые могут увеличить число активных пользователей (или подключаемых умных устройств) в разы.
Иногда возникают сомнения, как правильно оценить влияние тех или иных факторов на выбор инфраструктурной модели или модели затрат, или на проведение такого исследования нет времени. Иногда проект настолько крупный и важный для бизнеса, что для принятия окончательного решения о векторе развития нужна внешняя экспертиза. Проект развития ИС может выполняться по плану, но даже при этом результаты не всегда соответствуют ожиданиям. В таких случаях можно обратиться к лучшим практикам или кейсам других компаний или за профильным аудитом и консалтингом.