Привет! Я Леша Севальников, старший QA-инженер в команде, которая занимается разработкой бэкенд-сервисов для хранения, предоставления и актуализации данных о юридических лицах.
Почти пять лет работаю в Т-Банке, где с нуля организовал тестирование в своей команде. За это время я успел пройти путь от ручного до автоматизированного тестирования, встроить и автоматизировать нагрузочное тестирование и многое другое.
В какой-то момент все эти активности стали работать как единый механизм в текущих процессах, и мы задумались над следующим шагом для развития зрелости команды — повышение надежности. Расскажу о практике, которая поможет повысить надежность систем и команд.
Что такое надежность и почему она важна
Чтобы понять, достаточно ли надежна наша система, можно ответить на вопросы:
Какие метрики надежности мы используем?
Что произойдет, если откажет критичный сервис? Как отреагирует команда?
Есть ли у нас имитации сбоев?
Эти вопросы помогают понять, насколько команда готова к нештатным ситуациям. Но прежде чем углубляться в детали, давайте разберемся, что такое надежность.
Надежность — способность системы работать корректно в условиях сбоев, высокой нагрузки или непредвиденных событий. Если говорить простым языком, надежность — это когда все вокруг горит, а сервис продолжает функционировать.
Надежность команды — это способность команды эффективно и оперативно реагировать на инциденты и сбои, минимизируя их влияние на систему и пользователей.
Важно понимать, что надежность и качество — это не одно и то же. Качество — это соответствие требованиям в идеальной среде, а надежность — это устойчивость к нештатным условиям, багам и высоким нагрузкам. Чтобы обеспечить и качество, и надежность, нужно подходить к разработке и тестированию систем комплексно.
Надежность — это не просто характеристика системы, это залог успешной работы команды, удовлетворенности пользователей и устойчивости бизнеса. Ненадежная система — путь к хаосу, финансовым потерям и утрате доверия. Именно поэтому важно инвестировать в надежность.
Как мы обеспечиваем надежность системы
Для повышения надежности мы внедрили:
Раннее тестирование. Тестируем требования и спецификации на всех этапах разработки. Используем подход «три амиго» — когда разработчики, аналитики и тестировщики совместно обсуждают требования. Этот подход снижает риск появления багов, которые могут повлиять на стабильность системы.
Автоматизацию тестирования. У нас более 3 000 автотестов на каждом сервисе, а покрытие кода достигает 91%. Тесты позволяют оперативно реагировать на изменения в коде и предотвращать сбои.
Нагрузочное и стресс-тестирование. Проводим короткие бенчмарки, трехчасовые ночные прогоны и отдельное покрытие нагрузочными тестами критичных услуг. Позволяет заранее устранить проблемы с производительностью.
Метрики качества и надежности. У нас есть индикаторы, алерты и предупреждения, которые помогают оперативно реагировать на потенциальные проблемы. Помогают быстро выявлять сбои.
На первый взгляд кажется, что мы уже сделали все возможное. Но что происходит, когда сбой случается ночью, да еще и в выходной день? Тогда начинается самое интересное.
Инциденты: неизбежность и стресс
Представьте ситуацию: ночью всей команде поступает звонок от системы инцидент-менеджмента. Для команды это первый подобный случай: часть сотрудников не проснулась, часть подумала, что это мошенники, и добавила номер в черный список.
Из всей команды подвох ощутили только двое — QA и системный аналитик. Они выжидают, но наступает момент, когда пора что-то делать. Итог: сильный стресс, часовой инцидент и решение проблемы через отключение сервиса на ночь (не лучшая идея).
Такие ситуации показывают, что инциденты — это неизбежность. Всегда будет человеческий фактор, невнимательность, баги на стороне других систем или инфраструктуры.
Когда мы сталкиваемся с инцидентом, особенно неожиданным, то проходим через пять стадий принятия сбоя. Это не только психологический процесс, но и важный этап, который помогает осознать проблему и начать действовать:
Отрицание. Думаем, что сбой вовсе не на наших сервисах, а нас задело по касательной. «Это точно не наша проблема, пусть кто-то другой разберется».
Гнев. Мы злимся, потому что система инцидент-менеджмента названивает среди ночи, а мы только что легли спать.
Торг. Мы надеемся, что кто-то другой проснется и устранит сбой. «Может, дежурный разработчик уже встал? Или аналитик? А вдруг проблема сама исчезнет?».
Депрессия. Понимаем, что никто не собирается решать проблему и дальше тянуть нельзя. Наступает осознание, что придется действовать.
Принятие. Принимаем сбой и начинаем устранять его влияние. Это момент, когда мы берем ситуацию под контроль.
Эти стадии — не просто шутка. Они показывают, как важно быть готовым к инцидентам и уметь быстро переходить к стадии «Принятие». Чтобы минимизировать последствия, мы ввели практику учебных сбоев. Они помогают сократить время прохождения первых четырех стадий и быстрее приступить к решению проблемы.
Зачем нужны учебные сбои
Учебные сбои — это тренировки для команды и системы. Проведем аналогию: кто лучше всего справится с пожаром? Конечно, пожарные. А все потому, что они не ждут огня, а тренируются на полигонах. Так и ИТ-системы должны «гореть» на учениях, чтобы не сломаться в бою.
Практика учебных сбоев берет начало из Chaos Engineering. Это подход к тестированию систем, который предполагает создание контролируемых сбоев для проверки устойчивости системы. Основная идея заключается в том, чтобы намеренно создавать хаос в системе и наблюдать, как она справляется с ним. Это позволяет выявить слабые места и подготовиться к реальным инцидентам.
Chaos Engineering основывается на четырех принципах:
Гипотеза устойчивости. Перед началом эксперимента формулируется гипотеза о том, как система и команда должны себя вести в условиях сбоя.
Эксперимент. Создается контролируемый сбой, например отказ сервиса или резкий наплыв пользователей.
Наблюдение. Анализируется поведение системы и команды в условиях сбоя.
Анализ результатов. Оценивается, насколько система и команда соответствуют гипотезе, и выявляются области для улучшения.
Как мы проводим учебные сбои
Основные шаги проведения учебного сбоя:
Выбор сценария. Например, проблемы с данными (переименование колонок, удаление индексов), релиз с багом или имитация реальных инцидентов.
Уведомление дежурного. На начальных этапах мы уведомляем дежурного заранее, но со временем переходим к неожиданным сбоям — когда команда становится достаточно зрелой и хорошо ориентируется в регламенте.
Запуск учебного сбоя. Имитация отказа сервиса, релиза с критичным багом или резкого наплыва пользователей.
Анализ результатов. Что было сделано хорошо, что можно улучшить.
Для проведения учебных сбоев можно использовать инструменты:
Генераторы нагрузки: Gatling, Jmeter, Postman, Insomnia, самописные скрипты.
Триггеры: индикаторы системы инцидент-менеджмента, алерты, имитация негатива от пользователей.
Мониторинг: системы логирования, Grafana, доски баз данных и другие инструменты.
В моей команде в учебных сбоях участвуют все: разработчики, QA и системные аналитики. Обусловлено это тем, что во время дежурства на проде принимает участие вся ИТ-команда. Если команда на начальном уровне зрелости — подключаем только разработчиков. Когда команда становится достаточно зрелой, в учениях участвуют разработчики, QA и системные аналитики.
Пример сценария — сценарий релиза сервиса с критичным багом.
Гипотеза заключалась в том, что команда сможет оперативно обнаружить и откатить критичный баг в условиях, приближенных к реальным, следуя установленным регламентам и используя доступные инструменты. Мы предполагали, что текущие процессы и инструменты инцидент-менеджмента позволят минимизировать влияние сбоя на пользователей и быстро восстановить работоспособность системы.
Имитация сбоя:
На изолированной среде развернут релиз с преднамеренно внедренным критичным багом.
Создан фон активности от пользователей, чтобы имитировать реальную нагрузку на систему.
Уведомление дежурного:
Система инцидент-менеджмента сгенерировала уведомление о сбое и отправила дежурному инженеру.
Дежурный был предупрежден, что это учебный сбой, но должен был действовать, как в реальной ситуации.
Устранение влияния:
Дежурный инженер начал сопровождать инцидент, следуя регламенту.
Дежурный провел диагностику проблемы и начал поиск временного решения для минимизации влияния на пользователей и окончательного отката бага.
Анализ результатов:
После завершения эксперимента провели ретроспективу, чтобы оценить действия и результаты.
Поведение команды и системы. Команда:
Дежурный быстро отреагировал на уведомление и следовал регламенту.
Использованы все доступные инструменты мониторинга и логирования для диагностики и устранения проблемы.
Дежурный не проверил недавние релизы, а сразу полез в логи и надолго закопался в них, тем самым доведя по регламенту сбой до красного цвета.
Система:
Система инцидент-менеджмента корректно сработала, уведомив дежурного о сбое.
Инструменты мониторинга предоставили необходимые данные для анализа и устранения бага.
Результаты эксперимента. Что получилось хорошо:
Быстрая реакция дежурного на уведомление.
Эффективное использование инструментов для диагностики и устранения проблемы.
Хорошая координация и взаимодействие внутри команды.
Обнаруженные проблемы:
Некоторое время потрачено на поиск нужной информации в логах, что замедлило процесс устранения.
Дежурный не был в курсе последних изменений в инструментах, что вызвало задержку при откате последнего релиза.
Выводы и рекомендации:
В первую очередь смотрим на последние релизы, более 50% всех сбоев связаны с человеческим фактором (баги, регламентные работы, кривые релизы).
Улучшить доступность и структурированность логов для ускорения диагностики.
Рассмотреть возможность автоматизации некоторых шагов в процессе инцидент-менеджмента для ускорения реакции.
Как оценить эффективность
Для оценки готовности команды к инцидентам мы используем чек-лист, который помогает структурировать процесс и не упустить важные моменты. Вот основные пункты:
Реакция на алерт. Важно, чтобы команда видела, что с инцидентом начали работу. Это первый шаг к быстрому решению проблемы.
Заведение сбоя. Необходимо четко оценить критичность сервиса и цвет инцидента, а также понять, что конкретно сломалось. Это важно для SRE, CTO и SRO.
Коммуникации так же важны, как и корректность заведения сбоя. Из коммуникаций должно быть понятно, что влияние устраняют и известны примерные сроки устранения.
Вызов SRE. Это важно для ускорения устранения влияния и исключения подозрения на работы на инфраструктуре, БД и т. д.
Эскалация до CTO и SRO. Нужна в том случае, если вы не можете устранить влияние силами своей команды в кратчайшие сроки или вам не хватает компетенций.
Проведение диагностики. Это база, без которой не устранить влияние — просмотр логов, недавних релизов в поиске триггера сбоя для дальнейшего устранения влияния.
Подозрения на другие команды. Всегда есть шанс, что проблема может быть на стороне другой команды.
Скорость устранения. У всех разные регламенты, и время может варьироваться в зависимости от ваших регламентов.
На первых двух учебных сбоях мы видели, как растут показатели команды. Например, из восьми человек успешно прошли проверку сначала трое, а затем все восемь. Это показывает положительную динамику и рост компетенций. Также видны первые победы в виде устранения влияния менее чем за 20 минут.
Частота проведения учебных сбоев играет ключевую роль в их эффективности. Мы проводим сбои еженедельно с участием дежурного инженера. Такой подход позволяет регулярно тренировать навыки реагирования на инциденты и поддерживать команду в состоянии готовности.
Каждый дежурный проходит учебный сбой раз в квартал. Это обеспечивает равномерное распределение нагрузки между членами команды и дает возможность каждому сотруднику отработать действия в условиях, приближенных к реальным. Такой график позволяет поддерживать высокий уровень подготовки команды без излишнего отвлечения от основной работы.
Что получилось улучшить:
Время реакции на подозрения о сбое сократилось со средних 5—10 до 1—2 минут.
Команда работает строго по регламенту.
Поправили все проблемы в индикаторах и алертах, добавили ссылки на логи.
Повысилась уверенность команды в системе.
Над чем еще предстоит работать:
Автоматизация действий для сопровождения инцидента — поможет ускорить реагирование и снизить количество рутинных операций.
Нестандартные сценарии учебных сбоев — для готовности команды идти вне стандартного флоу.
Заключение
Учебные сбои, основанные на принципах Chaos Engineering, предоставляют множество преимуществ для повышения надежности системы и эффективности команды. Вот основные из них.
Уменьшение ущерба от инцидентов. Регулярные тренировки команды на учебных сбоях позволяют сократить время реакции на реальные инциденты, что минимизирует их влияние на пользователей и бизнес. А еще это помогает снизить стресс и нагрузку на команду в критических ситуациях.
Информирование бизнеса о потенциальных рисках. Учебные сбои предоставляют ценные данные о возможных рисках и уязвимостях, которые могут быть использованы для информирования бизнеса. Это позволяет принимать обоснованные решения по улучшению инфраструктуры и процессов.
Улучшение взаимодействия внутри команды. Совместная работа над устранением учебных сбоев способствует улучшению коммуникации и координации внутри команды. Это повышает общую эффективность и уверенность в действиях сотрудников.
Повышение уверенности в системе. Регулярные проверки системы на устойчивость к сбоям повышают доверие команды и бизнеса к ее надежности. Это позволяет более уверенно внедрять новые функции и изменения.
Адаптация к изменениям. Учебные сбои помогают команде адаптироваться к изменениям в системе и инфраструктуре, обеспечивая готовность к новым вызовам и условиям.
Развитие культуры непрерывного улучшения. Регулярные учебные сбои способствуют развитию культуры непрерывного улучшения, где команда постоянно ищет способы сделать систему более надежной и устойчивой.
Учебные сбои — это не просто инструмент для проверки системы, это стратегический подход к повышению ее надежности и устойчивости. Они помогают не только выявлять и устранять слабые места, но и развивать команду, улучшать процессы и информировать бизнес о потенциальных рисках. Внедрение учебных сбоев позволяет создать более надежную и устойчивую систему, готовую к любым вызовам, и обеспечивает уверенность в том, что команда сможет эффективно справляться с любыми инцидентами.