Связаться по Skype: vkarabedyants
Позвонить Написать
+7 (499) 404-28-83

Блог о системном администрировании серверов и сайтов

Установка, настройка программного обеспечения Linux, Windows операционных систем

DevOps: 10 советов сопровождения AlwaysOn

DevOps. 10 советов о том, как успешно сопровождать AlwaysOn проект в условиях постоянных изменений.

Современные тренды ИТ ставят высокие требования к доступности систем и сервисов, обеспечивающих работу Вашего бизнес-проекта. На практике это можно прочувствовать, когда подсчитываешь убытки от простоя системы. Для того, чтобы снизить время простоя, прилагаются порой титанические усилия, и, несмотря на все это, все еще очень часто имеют место внеплановые простои, да и плановые занимают больше времени, чем ожидалось. Сегодня мы будем говорить о том, почему это происходит и как реально приблизиться к заветным «24/7».
Для начала давайте еще раз оценим реалии. Потребности бизнеса могут меняться. Причин может быть несколько: изменение внешней среды, поиск золотой жилы, конкуренция. В связи с этими изменениями меняются и бизнес-приложения: будь то программное обеспечение, разработанное компанией, собственный веб-ресурс или системы сторонних разработчиков, обеспечивающие функционирование бизнеса. Собственно говоря, изменения в этих системах и приводят к простоям, а следовательно и к убыткам. Для того, чтобы Ваш проект работал в режиме AlwaysOn к этому должны быть готовы: компания, инфраструктура, бизнес-приложения. Давайте объединим эти три компонента и назовем все это бизнес-системой. Ниже приведены требования, соответствие бизнес-системы которым, по мнению автора, позволяет до минимума снизить риски получения убытков при простоях в реалиях окружающего непостоянства.

  1. Плановый подход. Всегда и во всем. Начиная от выбора материальных ценностей и заканчивая досугом сотрудников. Планировать нужно с прицелом на эффективность и расчетом на будущее и учетом обеспечения отказоустойчивости. Работа бизнес-системы должна быть спланирована так, чтобы изменения в одном сегменте не привели к потере работоспособности другого.
  2. Организация эффективного взаимодействия. При изменении одного из объектов бизнес-системы, все остальные как можно скорее должны быть уведомлены об этом. Например, системные администраторы, должны быть уведомлены о внедрении новой версии ПО, разработчики должны быть уведомлены об изменениях инфраструктуры, а менеджеры по продажам – о временном отсутствии части функционала веб-ресурса. Для достижения этих целей можно внедрять различные программные продукты, такие как системы мониторинга и контроля изменений.
  3. Проведение технического обслуживания и модернизации систем. Периодическое обслуживание всегда эффективнее, и зачастую дешевле, чем срочное решение проблемы. Пример здесь простой: операционная система со всеми установленными обновлениями без дополнительных средств защиты на 90% устойчива к взлому. Аналогичный пример можно привести, говоря об аппаратной части решения.
  4. Стандартизированное построение бизнес-системы. Такой подход упрощает модернизацию, масштабирование, разработку, автоматизацию и понимание принципов работы узлов. Здесь, по мнению автора, примеры излишни.
  5. Автоматизация рутинных задач. Исследование IBM говорит о том, что количество сбоев ИТ систем, которые происходят по причине влияния человеческого фактора на 70% выше, чем предположения ИТ специалистов. Все, что представляет собой однотипные повторяющиеся действия должно быть автоматизировано. При внедрении решения автоматизации нужно также применять плановый подход, учитывать выработанные и по мере необходимости формировать собственные стандарты. В качестве инструментов реализации можно предложить широкий спектр ПО, начиная от скриптов, разработаннх под Ваши нужды, и заканчивая программным обеспечением, которое решает задачи Continuous Integration (CI) и Continuous Delivery (CD).
  6. Выполнение тестирования и поэтапное внедрение нового функционала. Требование говорит само за себя. Любой функционал перед внедрением должен быть протестирован. Приветствуется постепенное внедрение новой разработки. Это нужно для того, чтобы минимизировать отрицательные последствия ошибок новой версии продукта. Например, возможен сценарий, когда клиенту предоставляется новая версия ПО, если он использует определенную модель телефона или версию браузера. Для этих целей также можно внедрять ПО направления CI и CD.
  7. Наличие возможности и плана отката. Это как план эвакуации при пожаре. Автор не знает такого разработчика систем, который мог бы дать 100% гарантию работоспособности нового продукта. Всегда есть риск. И на этот случай всегда должен быть план «отступления».
  8. Ведение проактивного мониторинга. Отличный способ ответить на вопросы «А что будет, если… ?». Предупрежден, значит вооружен. Значит можно планировать, модернизировать, обходя проблемы стороной. И это касается не только ИТ систем. Наблюдение за работой коллектива, своевременная смена лидера или членов команды может способствовать максимальному использованию потенциала команды.
  9. Организация командной работы. Противостояния между различными объектами бизнес-системы снижает продуктивность рабочих процессов. Ничего хорошего не выйдет, если системный администратор будет говорить о том, какой дурак разработчик, а бухгалтер будет считать системного администратора лентяем. Гораздо полезнее будет их эффективное взаимодействие для решения проблемных вопросов и достижения общей цели. Для того, чтобы его обеспечить, необходима работа на разных этапах: правильный подбор персонала, построение здоровой атмосферы общения, организация неформального общения, team-buildingов, обучающих мероприятий.
  10. Организация мероприятий по обучению и взаимообучению. Тут срабатывает правило 80/20. То есть, обладая двадцатью процентами знаний можно избежать 80% проблем. Это хороший показатель, если говорить о смежных направлениях деятельности.

Все эти требования – это задачи DevOps. Причем DevOps в этом контексте – это не просто техническая профессия (которая непосредственно на практике может решить часть задач озвученных выше), это концепция объединения различных служб, обеспечивающих жизнеспособность Вашего бизнес-проекта в единую бизнес-систему – машину, узлы которой эффективно взаимодействуют, для получения общего результата.

средства девопс
Все вышесказанное, кажется, относится к единой команде, однако применимо и в случае использования аутсорсинга. Объединение команд в единый коллектив, как технически, так и социально, обмен опытом и знаниями, в том числе об изменениях в системе, использование технических инструментов для контроля и автоматизации действий – вот пожалуй ключевые ингредиенты рецепта по созданию качественного сопровождения AlwaysOn проекта в условиях постоянных изменений.

Услуги команды опытных девопс администраторов, [email protected]

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.