CC BY
53• Процесс. Хорошо документированные процессы и цели для процессов; четко определено назначение процесса, имеются и выполняются инструкции по процессу.
• Технологии. Технологии могут помочь автоматизировать и обеспечить самообслуживание, высокий доступ к информации и качества этой информации. Инструменты должны адекватно поддерживать процессы.
Даже при том, что существует достаточно большое количество моделей зрелости, трудно найти одну наиболее эффективную модель для оценки процессов ГГ8М. По этой причине также утверждается, что было бы полезно комбинировать различные фреймворки, чтобы получить более тонко настроенный фреймворк.
Одной из наиболее популярных моделей зрелости является модель зрелости 1Т1Ь. В модели зрелости 1Т1Ь оценка уровня зрелости заключается в проведении анкетирования сотрудников об атрибутах, входах, выходах и интерфейсах, связанных с процессами и функциями 1Т1Ь. Уровень зрелости каждого процесса и функции затем определяется в соответствии с пятью уровнями:
1. Начальный уровень. Процесс не организован и хаотичен. Процедуры и действия по управлению процессами не стандартизованы. На процессы и функции выделяется небольшое количество ресурсов. Общий подход к управлению не организован.
2. Повторяемый уровень. Процесс выполняется по образцу. Одинаковые процедуры выполняются разными людьми. Обучение носит неформальный характер, не сообщается о стандартных процедурах, и ответственность остается за человеком. Существует высокая степень доверия к знаниям отдельных лиц, и поэтому возможны ошибки. В целом, действия, связанные с не скоординированы и нерегулярны.
3. Определенный уровень. Процесс определен, а процедуры стандартизированы. Сами процедуры являются формализацией существующих практик. Процесс имеет владельца процесса, цели и задачи с выделенными ресурсами и ориентирован как на эффективность, так и на результативность. Деятельность становится более проактивной и менее реактивной.
4. Управляемый уровень. Процесс был полностью определен, управляем, сервис-ориентирован и имеет цели и задачи, которые основаны на целях и задачах бизнеса. Также процесс контролируется и измеряется. Принимаются соответственные меры, если процесс неэффективен. Могут использоваться инструменты автоматизации процесса.
5. Оптимизируемый уровень. Процесс развит до уровня лучшей практики. ИТ используются интегрированным образом для автоматизации рабочего процесса, предоставляя инструменты для повышения качества и эффективности, что позволяет организации быстро адаптироваться. Процесс имеет стратегические цели и задачи, соответствующие общим стратегическим целям бизнеса и ИТ.
Оценку процессов по уровням зрелости можно проводить самостоятельно либо с помощью стороннего аудита. Очевидно, самостоятельный аудит дешевле, но второй вариант объективнее.
Высокий уровень зрелости процесса не гарантирует эффективность процесса в любой ситуации. Это лишь дает уверенность организации о том, что в большинстве случаев процесс работает правильно. Также, очевидно, эффективность и стоимость процесса зависит от уровня зрелости, но не линейно. По данным учебного центра «ИТ эксперт» [2] затраты на обеспечение зрелости процесса растут по экспоненте (рисунок 1). На графике видно, что снижение рисков процесса, также нелинейно и при высоких уровнях зрелости незначительно. Однако, если изначально риски очень высоки (процесс критичен), то даже незначительное их снижение может быть оправдано.
Рисунок 1. График зависимости затрат и рисков от уровня зрелости процесса
Список литературы
1. ГОСТ Р ИСО/МЭК 33004-2017. Информационные технологии. Оценка процесса. Требования к эталонным моделям процесса, моделям оценки процесса и моделям зрелости, 2017 - 15 с.
2. Рудд К., Сансбури Д. Модель зрелости ITIL. Руководство пользователя // AXELOS. URL: https://www.axelos.com/Corporate/media/Files/Misc%20Qualification%20Docs/ITIL-maturity-model-self-assessment-service-user-guide.pdf (дата обращения: 17.04.2020)
3. Уровни зрелости управления ИТ процессов // IT Expert. URL: https://www.itexpert.ru/rus/ITEMS/200809072359/ (дата обращения: 15.04.2020).
МИКРО-СЕРВИСНАЯ АРХИТЕКТУРА БИЗНЕС-ПРИЛОЖЕНИЙ -ПЕРСПЕКТИВЫ И ПРОБЛЕМЫ
Ворсин Владислав Андреевич
Санкт-Петербургский государственный экономический университет,
г. Санкт-Петербург
Аннотация. В статье рассмотрены перспективы и проблемы микро-сервисной архитектуры бизнес-приложений.
Abstarct. The article discusses the prospects and problems of micro-service architecture of business applications.
Архитектурный стиль микросервиса - это подход к разработке отдельного приложения в виде набора небольших сервисов, каждый из которых работает в своем собственном процессе. Эти сервисы построены вокруг бизнес-возможностей компании и могут работать независимо с помощью полностью автоматизированного механизма развертывания. Существует минимальный уровень централизованного управления этими службами, которые могут быть написаны на разных языках программирования и использовать разные технологии хранения данных.
Благодаря гранулированию и легким протоколам, микросервисы обеспечивают повышенную модульность, упрощая разработку, тестирование, развертывание и, что более важно, изменение и обслуживание приложений. С помощью микросервисов ваш код разбивается на независимые службы, которые выполняются как отдельные процессы. Выход из одного сервиса используется как вход для другого в оркестровке независимых коммуникационных сервисов.
Микросервисы особенно полезны для предприятий, которые не имеют заранее заданного представления о массиве устройств, которые будут поддерживать его приложения. Будучи независимыми от устройств и платформ, микросервисы позволяют компаниям разрабатывать приложения, которые обеспечивают согласованное взаимодействие с пользователем на различных платформах, включая веб, мобильные, 1оТ, носимые устройства и фитнес-трекеры.
Микросервисы часто рассматриваются как противоположный подход к так называемому «монолиту». «Монолит» обычно запускается в одном процессе, где реализованные внутри сервисы не выставляются -и, следовательно, не могут использоваться повторно - снаружи. Данная архитектура имеет как плюсы, так и минусы по сравнению с микросервисной, но на взгляд автора минусов получается больше, что делает ее менее эффективной по сравнению с архитектурой микросервисов. Рассмотрим как плюсы так и минусы «монолита». Начнем с плюсов:
• Простота в освоении
• Проста в тестировании
• Простое масштабирование по горизонтали путем запуска нескольких копий за балансировщиком нагрузки
• Проста в развертывании. Вам просто нужно скопировать упакованное приложение на сервер
На ранних стадиях проекта «монолит» работает хорошо, и в основном большинство крупных и успешных приложений, которые существуют сегодня, были запущены как монолит.
Теперь перейдем к минусам:
• Этот простой подход имеет ограничение по размеру и сложности
• Приложение слишком большое и сложное для полного понимания и быстрого правильного внесения изменений
• Размер приложения может замедлить время запуска
• Другая проблема с монолитными приложениями - надежность. Ошибка в любом модуле может привести к остановке всего процесса. Более того, поскольку все экземпляры приложения идентичны, эта ошибка будет влиять на доступность всего приложения.
• Вы должны повторно развернуть все приложение при каждом обновлении
• Влияние изменений, как правило, не очень хорошо понято, что приводит к тщательному ручному тестированию
• Непрерывное развертывание может вызывать трудности
• Монолитные приложения также могут быть трудно масштабируемыми, когда разные модули имеют противоречивые требования к ресурсам
• Монолитные приложения препятствуют внедрению новых технологий. Поскольку изменения в фреймворках или языках повлияют на все приложение, это чрезвычайно дорого как по стоимости, так и по времени.
В представлении автора микросервисная архитектура при разработке бизнес-приложений имеет следующие перспективы:
• Быстрый выход приложения на рынок. Быстрый выход достигается потому, что микросервисы легче в понимании, их легче усовершенствовать благодаря их небольшому объему, их проще развертывать, а управление данными децентрализовано и, следовательно, более гибко.
• Больше инноваций. С помощью использования лучших технологий для каждой конкретной проблемы и облегчения переключения между технологическими базами появляется возможность создавать инновационный продукт. Нет необходимости в долгосрочной приверженности какой-либо конкретной технологии.
• Лучшая масштабируемость. Достигается за счет отдельного развертывания сервисов и функций автоматического масштабирования инфраструктуры в сочетании с шаблонами отказоустойчивости во избежание перегрузки системы.
• Повышение рентабельности инвестиций (ROI) и повышения совокупной стоимости владения (TCO) за счет более быстрой (а значит, более дешевой разработки) и использование более дешевого оборудования.
• Лучшая устойчивость. Изоляция отказов, меньшее влияние на другие сервисы при возникновении ошибки, достигается с помощью шаблонов устойчивости, таких как переборки, автоматические выключатели.
Несмотря на вышеперечисленные перспективы микросервисной архитектуры для разработки бизнес-приложений, без недостатков не обойтись. Ниже автор рассмотривает проблемы, с которыми сталкиваются проекты, когда они реализуют свою систему в микросервисном архитектурном стиле с использованием нескольких микросервисов.
Если в проекте используется один микросервис, то чаще всего проект работает без проблем. Главные трудности возникают из-за классических проблем со связью, которые внезапно возникают, когда необходимо координировать работу сразу нескольких микросервисов.
Главные проблемы архитектуры микро-сервисов:
• Предотвращение масштабирования. Если вы либо мигрируете существующее приложение, либо ваша команда разработчиков недостаточно опытна, то вы, возможно, разрабатываете микросервис с использованием шаблонов «классического стиля» или монолита.Такой микросервис может опираться на реляционные базы данных, которые трудно масштабировать. Также ими сложно управлять.
• Устойчивость. Очень часто классические приложения зависят от доступности базовой инфраструктуры. В случае сбоя инфраструктуры происходит сбой приложения. В некоторых случаях встроены функции устойчивости, такие как автоматические выключатели или управление скоростью запросов, но это не всегда так. Например, транзакции с двухфазной фиксацией зависят от доступности менеджера ресурсов и транзакций. Если они недоступны, транзакции и связанные ресурсы могут препятствовать работе системы. В подходе микросервисов с таким количеством модулей развертывания и сетевых подключений по сравнению с монолитом существует гораздо больше «движущихся частей», которые могут сломаться. Также есть много частей, которые изменяются или перезапускаются независимо, например, когда разные микросервисы обновляются разными командами. Приложение просто не может полагаться на всю доступную инфраструктуру.
• Коммуникации команд. Микросервисная архитектура разбивает приложение на несколько независимо развернутых микросервисов, которые взаимодействуют друг с другом. Все зависимости, которые раньше были скрыты в монолите, возможно, закодированы в правилах зависимостей между компонентами, теперь должны быть закодированы в конфигурации инфраструктуры. Однако поддерживать связь с инфраструктурой труднее, поскольку нет среды разработки, которая выдает красные метки ошибок, когда IP-адреса или порты не совпадают между производителем и потребителем.
• Технологическое разнообразие. Это является как плюсом разработки, так и минусом. Парадигма микросервиса позволяет использовать разные технологические основы для каждой услуги. Однако это может привести к необходимости использовать разные инструменты для одной и той же функциональности - просто потому, что другой микросервис использует другую технологию.
Кроме того, один микросервис может быть написан на одном языке программирования, другой микросервис - на другом. Есть несколько вещей, которые вы не можете сделать на большинстве языков, что означает, что выбор языка часто основан на личных предпочтениях, а не на реальных технических требованиях.
