Несколько месяцев назад, в Delta произошел выход из строя IT системы, который привел их к потере 150 миллионов долларов, при этом общая прибыль упала до 3%. Клиенты «застряли» в аэропорту на несколько часов, 2300 рейсов было отменено, и Delta пришлось оплачивать тысячи отелей и проездных билетов, чтобы компенсировать продолжительный сбой, несмотря на высокую вероятность того, что инцидент стал причиной длительной тряски некоторых клиентов.
Простой приложений и сервисов даже от мультимиллионных брэндов может случиться в любой момент, а всего один распространенный случай может привести бизнес к потере сотен миллионов долларов. Но таких ситуаций можно избежать, предприняв следующие шаги:
- Внедрите архитектуру микросервиса.
Традиционно, приложения создавались в монолитном стиле или путем разработки целого приложения как единого.
Сегодня, архитектуры микросервиса набирают популярность. Они включают в себя разработку, тестирование и развертывание приложения в меньшие части, которые не полностью зависят друг от друга. Таким образом, упрощается обслуживание, потому что компоненты приложения изолированы друг от друга. Поэтому, если один определенный компонент перестает работать, его можно исправить без задействования других. В монолитных приложениях, если что-то идет не так, целое приложение находится в простое и сложно определить, что именно не функционирует. Подход с микросервисами делает ваше приложение более устойчивым к простоям, и это первый шаг к достижению высокой доступности. Тем не менее, нужно помнить, что архитектуры микросервисов привносят сложность и рост объема сгенерированных данных, которые необходимо прослеживать, поэтому важно соотносить соответствующие сигналы и удерживать недействующие сигналы, чтобы снизить уровень общего шума.
- Выпускайте релизы быстрее и чаще.
Наибольшее преимущество архитектуры микросервисов заключается в том, что они дают возможность быстрее выпускать релизы — множество раз в день для вэб-приложений и дважды в неделю для мобильных приложений. Ранее было установлено, что лучше выпускать основные версии лучше приблизительно каждый квартал, и каждый раз простои были неизбежны. Современный подход предполагает фрагментированность релизов. Развертывания происходят только во фрагментах приложения на фоне в любое время, таким образом, платформа всегда остается в рабочем состоянии. В этом случае не только уменьшается риск простоя, но и вы становитесь более конкурентоспособным, т.к. вы увеличиваете скорость выпуска новой версии с целью предоставить клиенту передовые характеристики продукта и выгодную цену.
- Доступность – это составляющая качества
Качество и доступность взаимосвязаны. Большинство организаций не видят важности QA, пренебрегая ими до последней минуты. Во избежание ошибок программного обеспечения, команда QA должна быть задействована в процессе разработки как можно раньше и в жизненном цикле выпуска новых версий. QA должны сфокусироваться на стратегии автоматизации и тестирования. Основы тестовой автоматизации помогут уменьшить количество ошибок во время значительного снижения стоимости и сохранения времени в сравнении с ручным подходом. В дополнение, тестеры не только ищут «баги»; они также должны быть упреждающе задействованы в процесс запросов, чтобы направить разработку в правильное направление. Убедившись с самого начала, что команда разработчиков строит рабочий процесс в правильном направлении, в будущем существует меньшая вероятность технических долгов организации. QA – это постоянное улучшение, и мотивы должны быть направлены на достижение этой цели.
- Имейте план аварийного восстановления
Когда базовые службы в вашем приложении нарушены, это катастрофа. В этом случае необходимо иметь план аварийного восстановления. Из-за того, что большинство организаций используют гибридные архитектуры с общедоступной и частной облачной инфраструктурой, важно иметь резерв в сервере и делать резервирование в разных провайдерах. Виртуализация может быть полезной при создании копировании образа существующего физического сервера и даже в большей степени контейнеризации, потому что резерв копий мало весят и занимают меньше места. Такие стратегии обеспечивают доступ базы данных даже во время аварии. Более того, необходимо непрерывно автоматизировать резервный план, чтобы он не зависел от разрешения администратора, особенно если они не доступны. Автоматизация также помогает команде разработчиков легко протестировать аварию, которая может произойти.
- Используйте управление изменениями ITSM
Убедитесь, что такие стандартизованные системы, как ITIL используются в управлении изменениями ITSM. Изменения очень полезны для IT сервисов, без которых не было бы прогресса – но произведенные изменения должны быть записаны. Записывайте процент успешных попыток изменений и оглашайте результаты с целью выявить команды с низким процентом. Такой инструмент ITSM, как ServiceNow хорош для большей видимости и контроля над управлением изменений. Он позволяет вносить изменения быстро, эффективно и с минимальным вредом для сервисов IT.
- Используйте инструмент управления при аварийных случаях
При неизбежном простое важно проинформировать правильных людей команды в реальности. Но часто командам поступает слишком много сигналов, и они могут пропустить по-настоящему важный, который влияет на среднее время разрешения (MTTR). Такая платформа управления авариями, как PageDuty помогает управлять и группировать сигналы от разных мониторинговых систем и и окажется бесценным во время сбоя. Она может сдерживать недействующие сигналы, основанные на легко определенных правилах; группы, связанные с действующими сигналами в аварии и обеспечивает доступ первоочередных сообщений, с правильным содержанием, при аварии нужным людям. Более того, при объединении со всеми существующими мониторингами, генерациями форм, ChatOps и инструментами кооперации и т.д., PagerDuty дает вашей команде быструю диагностику и устранение аварий, и ваше приложение работает настолько долго, насколько это возможно.
- Намерено вызывайте сбои
Запланированные сбои поддерживают команду в состоянии готовности решить любой простой. Netflix известен таким подходом. Они используют скрипт Chaos Monkey, который, например, работает на фоне и произвольно останавливает работу серверов. Такой подход помогает команде быть всегда наготове в случае настоящего простоя, при этом без задержек работая у клиентов. PagerDuty также практикует Failure Fridays каждую неделю, намерено внедряя ошибку в систему для постоянного улучшения ответа, обеспечивает готовность и увеличение надежности.
Хотя идеал достичь нельзя, ориентируясь на людей, процессы и инструменты, которые составляют вашу команду разработчиков, приблизят вас к нему. Не существует волшебной пилюли, которая уберет все проблемы с простоями, но если вы будете следовать данным пунктам, вы создадите более надежные приложения и сможете заработать и сохранить доверие и верность ваших клиентов.
About The Author
Виктор Карабедянц
ИТ директор (CIO), руководитель нескольких DevOps команд. Профессиональный руководитель проектов по внедрению, поддержке ИТ систем и обслуживанию пользователей.