Download to read offline
Uploaded byRoman Yuferev
Manageability - ADD-2011
Документ обсуждает управляемость и надежность программного обеспечения, а также жизненный цикл его эксплуатации. В нем рассматриваются ключевые аспекты, такие как масштабирование, конфигурирование, миграция и мониторинг систем. Автор, Роман Юферев, предлагает инструменты для оценки состояния приложений и их сопровождения.
Manageability - ADD-2011
- 1.
- 2.
- 3.
- 4.
- 7.
- 8.
- 9.
- 11. …а мы ничегоне забыли?
- 12.
- 13.
- 14.
- 15.
- 16.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24. 1 - МодельЗдоровья
- 26.
- 27.
- 28.
- 33.
- 34.
- 35.
- 36. Реализация модели здоровьяVIAcode
- 37.
- 38.
- 39.
- 42. Спасибо за вниманиеРоманЮферевVIAcodea-jail.blogspot.comwww.viacode.com
Editor's Notes
- #3 Всем привет! Меня зовут Роман Юферев и я менеджер…по совместительству евангелист направления Manageability в компании VIAcode. Мы занимемся этой областью уже более 7 лет и являемся одними из экспертов в этом направлении, сотрудничая с такими компаниями как Quest, Microsoft и Cisco.
- #4 А теперь давайте посмотрим, кто у нас в зале! Для начала прошу поднять руки менеджеров...теперь давайте добавим сюда владельцев и директоров софтверных компаний! Супер – я расскажу вам о том, как делать программное обеспечение, которое вы разрабатываете более привлекательным для заказчиков!Теперь перейдем к тем, кто как раз и является заказчиком этого самого ПО...кто из вас хоть раз в жизни выступал в этой роли? Окей – вам я расскажу о том, как можно существенно снизить стоимость владения ПО. Есть ли среди нас админы,...специалисты службы поддержки – maintanance, support? Ага!!! Я покажу как сделать вашу работу в разы проще, приятнее и спокойнее! Ну и наконец, разработчики – программисты, тестировщики – где вы? Ага! Для вас – новая концепция, технология, о которой пока мало кто знает – тссссссс...строго по секрету! Окей – погнали!
- #5 Итак, начнем разговор со знакомого многим из нас понятия – жизненный цикл программного обеспечения! В зависимости от контекста и образования автора его рисуют по-разному...например так...
- #6 Как видим здесь у нас линейная структура начинающаяся со сбора требований и завершающаяся развертыванием и поддержкой...
- #7 ...авторы другой диаграммы уже догадываются о цикличности характера разработки и предлагают нам более полный сценарий, который лично мне гораздо ближе! Остановившись на этом моменте давайте спросим себя – какой из этих этапов самый важный! (опрос зала)
- #8 С точки зрения самого продукта и его владельца – ввод в строй и эксплуатация продукта являются самыми важными этапами жизненного цикла. Продукт создавался для того, что бы его использовать!
- #9 Вначале было слово и это слово было «Заказчик» или «Владелец» программного обеспечения. И возникло у него желание неодолимое и потребности великие, удовлетворить которые может только новый софт. А поскольку сам он его писать не умеет, то на сцену выходит разработчик программного обеспечения, который умеет это делать превосходно (интересно ведь говорить именно о таких разработчиках ).А еще бывает так, что явного заказчика вроде и нет и разработчикам самим приходится придумывать себе видение и требования. Тогда все ну очень весело, а называется это - стартап.
- #10 Но давайте вернемся к более распространенному сценарию, когда заказчик и разработчик – четыре разных человека Итак, «здравствуйте, владелец», «привет, разработчик»! Что же происходит между ними? Как я уже говорил, сам владелец не умеет разрабатывать программы, а разработчики, что характерно, хотят кушать,iPad-2 и Ford Mustang. Поэтому владелец платит денежки разработчикам, которые в обмен на это создают для владельца самый лучший в мире софт. Вуаля! Прошу – полный цикл разработки ПО – краткая версия Но эта, спаси господи, диаграмма не дает ответа на вопрос – ЗАЧЕМ? Зачем владельцу этот самый лучший в мире софт? Конечно, для того, что бы начать его эксплуатировать! Что бы в том или ином виде приобретать выгоды, которые он не смог бы приобрести без него! Потому что он тоже хочет iPad-2 и новую LadaKalina И теперь на сцену выходят ПОЛЬЗОВАТЕЛИ! Те люди, которые на самом деле будут использовать ваши разработки! Те люди, которые благодаря вашему софту сделают вашего заказчика богатым и счастливым…постойте, я опять что-то пропустил! Нам же нужно предоставить этим пользователям возможность использовать нашу ПО. Давайте сейчас сфокусируемся на сложном, многопользовательском ПО – на неких internet –сервисах. И тогда появляется недостающее звено в цепи – Datacenter или ИВЦ…или ЦОД…или как их еще называют? Именно развернув ваше приложение там вы обеспчите ему высокоую доступность для конечных пользователей. Ура! Круг замкнулся! Все счастливы!
- #11 И что же…теперь можно расслабиться и спокойно попивать пина-колада в тени коксовых пальм?
- #12 Серьезно? Ничего не забыли?
- #13 ЗААААААААААААБЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЛЛЛЛЛЛЛЛЛЛЛИИИИИИИИИИИИИ!!!!!!!!!!!!
- #14 Забыли о том, что там, где есть общедоступные сервисы, где есть датацентры, там всегда рядом админы или IT Operations как их называют…и уж будьте уверены, что они тоже будут претендовать на часть богатств владельца ПО…почему? За что?
- #16 Да в общем-то есть за что – во время начального развертывания и эксплуатации ПО его необходимо обслуживать и на админов ложиться достаточно большая ответственность и куча работы!
- #17 Все эти действия, которые производятся в процессе эксплуатации вашего ПО составляют для владельца ПО стоимость владения, которая для сложных систем может быть весьма существенной, а некоторых ситуациях привести к тому, что ваш софт окажется…
- #18 …окажется на кладбище, так как его эксплуатация будет попросту невыгодна а частые непрогнозируемые отказы лишат владельца всех пользователей.
- #19 Стоп…все это верно…но спрашивается – где здесь это самое MANAGEABILITY? И что это вообще такое???
- #20 Ах да….чуть не забыл…итак,software manageability или легкость администрирования ПО. Эта характеристика программного обеспечения несколько менее известная чем другие «илити» знакомые и разработчикам и тестировщикам…compatibility, availability, portability, scalability, reliability и т.д.
- #21 Давайте вспомним все за что нам приходится платить админам: развертывание, обновлние, конфигурирование и т.д. Как вы думаете, что больнее всего бьет по кошельку владельца ПО? Развертывание? Конфигурирование? Или может знаменитая «прочая фигня»? Открою страшную тайну – то, что происходит чаще всего…конечно, это отказы ПО, которые абсолютно не зависят от того, насколько качественно вы разработали свой софт. Отказы в свою очередь будут негативно влиять и на пользователей и на владельца и уж точно достанется админам…
- #22 И уж поверьте – это не приведет ни к чему хорошему – владелец будет терять пользователей и таким образом терять выгоду, админы, проклиная про себя авторов этой «нетленки» будут долгими ночами разбираться, что же там у вас случилось, а потом выставят километровый счет владельцам продукта…оно вам надо???
- #23 Так что же нам нужно изменить, что бы наш лучший в мире софт был еще и самым manageable? Как изменить процесс разработки ПО таким образом, что бы и админы и владельцы софта и конечные пользователи были еще более счастливы?
- #24 Для этого нужно сделать всего 3 вещи…
- #25 Номер 1 – опишите модель здоровья приложения.
- #26 Модель здоровья приложения описывает основные компоненты системы, определяет возможные отказы для каждого компонента, связывает их с диагностической инструментацией и описывает необходимые действия для восстановления работоспособности системы в случае отказа. Лучше всего объяснить модель здоровья через такую метафору:
- #27 Ваше приложение – это человек на беговой дорожке в центре по подготовке космонавтов. Он бежит, а тело его опутано разнообразными датчиками, непрерывно передающими заботливым людям в белых халатах данные о температуре тела, артериальном давлении, сердечном ритме и уровне гемоглобина в крови. И у каждого врача в голове – годы учебы и практики, позволяющие ему анализировать эти данные, выявлять в них симптомы недомогания, ставить диагноз и предлагать лечение! То есть, например, врач видит рост уровня гемоглобина в крови и делает вывод об обезвоживании нашего космонавта, дает ему стакан воды и затем с удовлетворением наблюдает за нормализацией этого показателя. Понимаете, это – модель здоровья человеческого организма, модель, без которой наша жизнь была бы сейчас просто невозможна!
- #28 Модель, на создание которой медики всего мира потратили многие тысячи лет! Почему? Да потому что они ее строили уже по выпущенному продукту – человеческое тело было релизнуто уже очень давно и доавторов этого «продукта» было довольно трудно достучаться…представляете, как было бы здорово, если бы модель здоровья прилагалась бы к этому продукту?
- #29 И еще один очень важный момент – модель здоровья уникальна для каждого продукта…для мальчиков и девочек,
- #30 Для мышей
- #31 Для водопроводчиков
- #32 Для рыбок
- #33 Для амебы обыкновенной– у каждого из них свои болячки, со своими симптомами и своими способами лечения! Так же и программы не похожи одна на другую!
- #34 Номер 1 – инструментируйте ваш код в соответствие с моделью здоровья и помните, для кого вы это делаете. Некоторые ошибочно полагают, что инструментация – это просто отличное средство отладки…хмм…окей, а что будет делать админ изучая полный стэк-трейс исключения, который вы выводите в eventlogпри ошибке подключения к серверу базы данных? Поэтому при инструментации обратите ваше внимание на то, что вы инструментируете и помните для кого вы это делаете!
- #35 Очень важно понимать, что при этом уровень подготовки админа, который столкнется с вашими отказами может быть очень разным, поэтому дуйте на холодное и делайте инструментацию, которая при анализе потребует от админов минимума мысленных усилий. Тщательно разделяйте различные варианты отказов и подробно документируйте каждый из них. Как говорил один знакомый – «писать код надо так, как будто поддерживать его будет конченый маньяк, который знает твой домашний адрес». Тот же принцип применим и здесь!
- #36 Номер 3 – используйте автоматические системы мониторинга приложений. Эта рекомендация скорее к админам, а не к разработчикам, однако, для разработчиков, создающих модель здоровья, было бы неплохо представлять какие существуют системы мониторинга, в которых будет работать их модель здоровья. Сейчас появляется тенденция при разработке сложных программных систем сразу разрабатывать для них модель здоровья и реализовывать ее на одной из популярных платформ мониторинга.
- #37 Стоит отметить, что сама по себе модель здоровья – это скорее абстракция и для того, что бы сказку о manageability сделать былью необходимо реализовать ее для одной из популярных платформ мониторинга. Мы в VIAcodeиспользуем преимущественно платформу Microsoft System Center Operations Manager отчасти в связи с тем, что на многих наших проектах сам Microsoft и выступает заказчиком. Однако не буду скрывать, что существует еще много разных платформ мониторинга от не менее именитых производителей.И напоследок напомню…
- #38 Рассказать о классах и отношениях
- #39 Рассказать об «Ищейках» - discovery
- #40 Рассказать о мониторах и KB
- #41 Инструментация, модель здоровья и системы мониторинга –
- #42 вот ключ к счастью пользователей и заказчиков ПО в наши дни! Всем спасибо и Даешь Manageability!