A frontier in IT system reliability: verification

We compare traditional "monitor-and-recover" and proactive fault-injection based approaches to IT system or service reliability and provide a checklist for a company interested in adopting chaos engineering techniques.

Transcript

1. Надежность ИТ-систем Верификация как передовая практика Январь 2020 1
2. В приоритете ли надежность для бизнеса? Традиционно бизнес видит больше выигрышей здесь и сейчас в быстром развитии функционала ИТ-систем, чем в обеспечении надежности и отказоустойчивости. Однако по мере роста масштаба бизнеса, надежность начинает сказываться на качестве сервисов, удовлетворенности и удержании клиентов. С ненадежными системами компании не хотят иметь дело собственные и сторонние разработчики. Традиционное решение – быстрое восстановление после сбоев Когда с надежностью дела идут плохо, компании начинают тушить пожар там, где горит и когда горит: усиливают мониторинг ИТ-систем и требуют от команды эксплуатации быстрое восстановление системы после инцидентов. Эти усилия не проходят зря, но не решают фундаментальной проблемы – они являются реакцией на возникновение сбоев, но не предотвращают их заранее. Передний край работы – верификация системы Компании, для которых надежность «равно» деньги, переходят от просто реагирования на инциденты к верификации систем – периодической проверке ее устойчивости в ходе контрольных испытаний. Эти испытания повторяют часто встречающиеся аппаратные и программные ошибки и проводятся, когда это возможно, на работающей производственной ИТ-системе. Уязвимости выявляются, анализируются и устраняются не дожидаясь неконтролируемых сбоев. Нужно ли это нашей компании? Все это нужно не только банкам, Amazon и Netflix. Новые методы тестирования надежности уже сейчас получают распространение среди более широкого круга компаний. В таких компаниях быстро накапливаются новые технические компетенции. Отношение к надежности меняется от «если что, мы все исправим» к «мы исправляем уже сейчас». Это дает значительные конкурентные преимущества и возможность развивать и поддерживать более сложные и востребованные проекты. 2
3. Разработка Эксплуатация Сбой в работе 1. Вовремя увидеть 2. Восстановить работу системы 3. Написать диагностику (postmortem) 5. Придумать, что поменять 4. Собрать и обобщить все случаи за период Как обычно управляют инцидентами Быстро заметить сбой и восстановить работу Дальше ничего не делать, ждать следующего сбоя. Снова упадет – снова восстановим. Смотрим все инциденты за месяц или квартал. Правильно, но: 1. Это пассивный поиск 2. Это долго 3. Нет гарантий надежности Активная фаза инцидента 3
4. Что нового в сфере надежности? Верификация ИТ-системы: не ждать, а тестировать 1. Диагностируем систему 2. Строим гипотезы об уязвимостях 3. Планируем эксперименты с отказами 4. Проводим эксперименты 5. Подтверждаем гипотезы 6. Знаем, что чинить Правильно, без «но»: 1. Не ждем неприятностей, а заранее их выявляем 2. Короткий цикл между гипотезой об уязвимости и ее подтверждением 3. Команда быстро учится и перенимает опыт 4. Возможна автоматизация части тестов Анализируем архитектуру сервиса и результаты мониторинга. Передаем результаты тестирования в разработку. В случае успешной инъекции добавляем точку отказа в риск-модель. Составляем план проведения испытаний, проверяем какие базы и каналы нужно зарезервировать. Разрабатываем кейс, скрипт, проводим инъекцию (fault injection). По сетевой схеме кластера и фактическом анализе серверов ищем точки отказов. Ключевые слова: сhaos engineering, fault injection 4
5. У вас высокая стоимость простоя ИТ-системы? (cost of downtime >> 0 ) Надо ли компании повышать надежность ИТ-систем? Компания уделяет большое внимание к операционным рискам? Есть уверенность в качествe delivery pipeline? Вы собираетесь масштабировать ИТ- систему? Интегрироваться с чем-нибудь? Да, нужно инвестировать ресурсы в надежность Мониторинг и восстановление 1 2 3 4 Не считали / Нет Есть вопросы Не особо У нас все здорово Как команда применяет DevOps/SRE? Как устроен мониторинг системы? Как компания управляет развитием продуктов и сервисов? Откуда взялись архитектурные решения? Да Реагирование после инцидента Да Да Верификация ИТ-систем Упреждающий поиск уязвимостей Снижение потерь от сбоев системы Рост компетенций персонала Общая боль Коллективная динамика Привлечение внешней экспертизы • Недостаток внимания к инфраструктуре и эксплуатации. Удобно верить в то, что ничего плохого (снова) не произойдет. • Позиционирование контролируемого сбоя среди других видов тестов («у нас уже все протестировано», вендорские гарантии и т.д.) • Страх перед тестами на производственной системе, выбор подходящих заменителей (например, пред-production стенды) • Консенсус внутри команды и мотивация участников тестирования на развитие системы. • В процессе тестирования вылезает разная неудобная правда о системе, готовность компании ее переварить. • Зрелость внутренней технической культуры компании, готовность ее менять. • Нужен разносторонний опыт анализа уязвимостей и подготовки тестов. • Надо разбираться в большом количестве средств мониторинга и проведения тестов (fault injection). • Готовность работать с внешними консультантами по вопросам надежности. Сложности и особенности внедрения 5
6. Контакты Евгений Погребняк e.pogrebnyak@gmail.com Верификация надежности ИТ-систем Диагностика уязвимостей и планирование тестов с контролируемыми сбоями. Организация тестирования, обучение, автоматизация. Иллюстрации: Hanson Lu, John Moeses Bauan, Viktor Talashuk, Mauro Licul (все - Unsplash.com)