Задумывались ли вы когда-нибудь о том, какой из этапов жизненного цикла программного обеспечения является самым важным. Причем не с точки зрения какой-либо конкретной роли, а вне контекста – без рассуждений о том, как тот или иной этап повлияет на последующие. Формирование идеи или, может быть, сбор требований? Разработка дизайна или подбор команды? Но постойте, – разве любой процесс, любая деятельность, любая идея не появляются ради одной только вещи – ради того, что бы достигнуть ЦЕЛИ, добиться запланированного результата? Трудно не согласиться! Тогда и при разработке ПО его апофеозом, его самым важным этапом является именно ввод в эксплуатацию и использование! Мы пишем наш самый лучший в мире продукт именно ради того, что бы кто-то его использовал, что бы пользователи получили новый уникальный инструмент или новые возможности, а заказчик нашего продукта стал немного счастливее (применительно к заказчику это обычно значит – «значительно богаче»).
Современные процессы разработки программного обеспечения в значительной мере фокусируются на том, как сделать это более эффективно, как выпустить новый продукт на рынок за минимальное время и с минимальными затратами. Эти процессы так же описывают и сопровождение программного обеспечения при вводе в строй и эксплуатации. Однако пока мало кто связывает процесс разработки и эксплуатации, мало кто говорит о том, как нам изменить разработку программ так, что бы избежать ненужных затрат после того момента как шампанское на релиз-пати выпито и какой-то чужой человек в майке с надписью «FreeBSD – RuLeZ» установил наше приложение в дейта-центр среди сотен тысяч других, таких же «самых лучших». К счастью, сегодня появилась концепция, действительно дающая ответ на этот вопрос, описывающая характеристики программного обеспечения, требования к процессу разработки, а так же практики разработки и тестирования, направленные на то, что бы значительно снизить стоимость развертывания программного обеспечения и его эксплуатации. Эта концепция – Manageability.
Основы Manageability
Manageability – эта характеристика программного обеспечения, наиболее кратко определяемая как «легкость администрирования». За кажущейся простотой и краткостью определения скрывается целый комплекс действий, которые персонал дейта-центров выполняет каждый день устанавливая новое клиентское программное обеспечение или занимаясь обслуживанием уже установленного. Давайте рассмотрим, какие действия необходимо предпринять системному администратору после получения от клиента дистрибутива с каким-нибудь распределенным бизнес-приложением.
1. Развертывание (установка) – не надо напоминать, что в 95% случаев это не просто запуск setup.exe и next-next-next…иногда это может напоминать сложный квест, включающий в себя нетривиальные действия, типа установки не очевидных программ-prerequisites, настройки веб-сервера IIS или Apache, конфигурирование и/или установка сервера базы данных, изменение настроек брандмауэра и так далее.
2. Конфигурирование – обычно является неотъемлемой частью развертывания. Вынесено в отдельный пункт, поскольку иногда необходимо изменить конфигурации программы или ее окружения уже после изначального развертывания.
3. Обновление – установка новой версии всего продукта или отдельных его компонентов.
4. Масштабирование - изменение конфигурации программного обеспечения для поддержки большего количества пользователей. Для веб-приложений это, например, перевод их на web-farm.
5. Ошибки ПО (bugs) – тоже находятся в зоне ответственности системных администраторов, которые в этой ситуации выполняют роль диспетчера, информирующего о возникшей ошибке владельца программы, который в свою очередь, эскалирует это разработчикам.
6. Сбои ПО – да-да! Сбои ПО – это не ошибки программы, они могут возникнуть независимо от качества разработки. Это перегруженный процессор, закончившийся диск, сгоревший модуль памяти, тетя Люся – уборщица, втыкающая свой Kercher в бесперебойник именно вашего сервера. Все они – враги, убивающие ваше детище, вирусы и бактерии, постоянно кружащие вокруг него. И системным администраторам, конечно, приходится заниматься и ими.
За все эти действия системных администраторов так или иначе приходится платить владельцу (заказчику) программного обеспечения и в сумме они составляют Стоимость Владения. Если задаться вопросом, какая из перечисленных активностей способна стать камнем на шее вашего продукта, то стоит подумать о том, что из этого происходит чаще всего?
| Действие | ЧАСТОТА | СТОИМОСТЬ |
| Развертывание | Однократно | Умеренная |
| Конфигурирование | Крайне редко | Низкая |
| Обновление | Редко | Низкая |
| Масштабирование | Крайне редко | Низкая |
| Ошибки | Часто | Высокая |
| Сбои | Часто | Высокая |
Как мы видим, у нас два лидера: Ошибки и Сбои. И если минимизация ошибок программного обеспечения является одной из ключевых задач процесса разработки, то о сбоях среди разработчиков и тестировщиков не очень принято говорить. Надо, конечно, отдать должное тестировщикам, которые обязательно проверяют негативные сценарии, доводя разработчиков до белого колена, однако даже в этих случаях ожидаемым поведением программы является просто отсутствие критического сбоя (unhandled exception) и логирование сбоя в каком-либо виде. Но увы, этого недостаточно, ведь мы забываем, что разрабатывают и тестируют программу ее авторы, люди, знающие ее вдоль и поперек, а эксплуатировать ее будут системные администраторы, у которых таких программ от нескольких десятков до нескольких тысяч. И ваше сообщение в журнале событий «Ошибка подключения к базе данных» может быть совсем не очевидным для них. В случаях же, когда мы говорим о по-настоящему сложных приложениях даже самая подробная информация о сбое не скажет однозначно администратору, что нужно сделать, что бы восстановить работу программы. Поэтому Manageability вводит понятие «Модели Здоровья Приложения».
Модель здоровья приложения
Модель здоровья приложения описывает основные компоненты системы, определяет варианты отказа (failure modes) для каждого компонента, связывает их с диагностической инструментацией приложения (в журнале событий (Event Log), WMI-провайдерах, performance counters и так далее), а так же описывает необходимые действия для восстановления работоспособности системы в случае отказа. Лучше всего объяснить модель здоровья через такую метафору:
Ваше приложение – это человек на беговой дорожке в центре по подготовке космонавтов. Он бежит, а тело его опутано разнообразными датчиками, непрерывно передающими заботливым людям в белых халатах данные о температуре тела, артериальном давлении, сердечном ритме и уровне гемоглобина в крови. И у каждого врача в голове – годы учебы и практики, позволяющие ему анализировать эти данные, выявлять в них симптомы недомогания, ставить диагноз и предлагать лечение! То есть, например, врач видит рост уровня гемоглобина в крови и делает вывод об обезвоживании нашего космонавта, дает ему стакан воды и затем с удовлетворением наблюдает за нормализацией этого показателя. Понимаете, это – модель здоровья человеческого организма, модель, без которой наша жизнь была бы сейчас просто невозможна! Модель, на создание которой медики всего мира потратили многие тысячи лет!
Теперь вы видите в какой выгодной ситуации находятся разработчики программного обеспечения? Вы создаете новый продукт – «нового человека» прямо сейчас и вы сами в состоянии прямо сейчас создать не только программный продукт, но и описать для него модель здоровья! Создать ее еще на этапе проектирования архитектуры, когда не написано еще ни строчки кода – ведь для этого уже достаточно информации, уже известно, что этот компонент будет работать с базой данных, а этот – с удаленным веб-сервисом, что наше приложение рассчитано на 10000 подключений в минуту и так далее… Комплекс функциональных и нефункциональных требований плюс диаграмма компонентов и основные архитектурные решения – вот и все, что нужно, что бы создать модель здоровья.
И теперь и разработчики и тестировщики могут заботиться о вариантах отказа особо – в соответствие с инструментацией, описанной в модели здоровья, а не просто руководствуясь здравым смыслом.
Это позволяет создавать приложения, стоимость владения которыми значительно ниже, так же как и выше их устойчивость к отказам!
Комментариев нет:
Отправить комментарий