,
20 tweets,
5 min read
Read on Twitter
#ChaosEngineering – практика, которая активно применяется в серверной разработке, но я не слышал, чтобы о ней говорили в контексте клиентской. Её ROI крайне высок, потратив минимум времени на внедрение, вы будете регулярно совершать новые открытия о своем приложении.
Есть замечательный жизненный принцип – if it hurts, do it more often. Так, системы CI/CD, автоматизирующие сложную рутинную работу и тем самым исключающие из неё человеческий фактор, являются одним из практических воплощений этого принципа в мире ПО. martinfowler.com/bliki/Frequenc…
Однако, автоматизировать всё и вся можно лишь в теории, а на практике жизнь на выдумки хитра. Даже больше скажу, при большом количестве пользователей на практике обязательно случится то, что возможно лишь в теории.
Допустим, вы реализовали основной кейс фичи Х. Напрягшись, обработали сетевую ошибку и даже гипотетический ответ с некорректными данными внутри. Написали на это дело тесты и с чувством выполненного долга отдали таску в тест. QA успешно проверил фичу согласно кейсам продакта.
В бою всё пошло не так гладко:
1. Случилась сетевая ошибка, при нажатии на Retry пришёл "груз 500", к чему форма уже не готова.
2. По Retry приложение разлогинилось, и крешнулось.
3. По Retry приложение разлогинилось, но retry-блок спровоцировал утечку пользовательского сервиса.
1. Случилась сетевая ошибка, при нажатии на Retry пришёл "груз 500", к чему форма уже не готова.
2. По Retry приложение разлогинилось, и крешнулось.
3. По Retry приложение разлогинилось, но retry-блок спровоцировал утечку пользовательского сервиса.
Налицо 3 проблемы, борьбу с которыми мы и рассмотрим сегодня:
1. Краевых кейсов больше, чем можно придумать умозрительно.
2. Разлогины случаются, но только не у разработчиков и тестеров.
3. Есть невидимые баги, которые без спец. инструментов не видны.
1. Краевых кейсов больше, чем можно придумать умозрительно.
2. Разлогины случаются, но только не у разработчиков и тестеров.
3. Есть невидимые баги, которые без спец. инструментов не видны.
Как видим, автотесты нам не помогли, а есть ли что-то, что могло бы? Можно ли регулярно и систематически ловить то, о существовании чего не предполагаешь? Да можно, но тут я перефразирую Йоги Берра: "Если ловишь сам не знаешь что, будь осторожнее, иначе можешь это и не поймать."
#ChaosEngineering силен там, где автотесты бессильны. Cайт principlesofchaos.org определяет его как "...the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production."
В Облаке #mailru мы идентифицировали те места, где чаще всего происходят факапы, и в дебажной версии приложения сами эти факапы начали провоцировать. Сейчас мы внедрили управляемый хаос в сетевом слое и в сервисе авторизации.
Суть Network Chaos Engineering в том, что вместо отправки запроса на сервер сетевой слой даёт ответ на него сам в соответствии с заданными в конфиге параметрами. Рукотворный хаос для нас так важен, что встроен прямо в сетевую библиотеку, а не где-то сбоку.github.com/pavelosipov/PO…
В конфиге прописывается вероятность симуляции (в процентах) и варианты ответа, если до неё таки дошло дело (эдакая лотерея внутри события симуляции). 
Конфиг можно задавать на любом уровне гранулярности: приложение в целом → все методы микросервиса → конкретный метод API → конкретный вызов метода API. Это позволяет эмулировать ошибки, специфичные для одного API, но бессмысленные для другого.
Например, если некоторый микросервис предоставляет возможность использовать его API неавторизированному пользователю, то нет практического смысла эмулировать для него ошибки авторизации.
На скриншоте интерфейсы для задания симуляционных (и не только) опций в классах, моделирующих сетевые абстракции разного уровня гранулярности: Gateway → Host → Request → Request Invokation.
Полезный частный случай симуляционного конфига – откручивание автоответов на 100%. Это позволяет делать заглушки для ещё не реализованных методов API, а также писать на эти методы автотесты.
Следующий хаос – авторизационный. Часто бывает, что при разработке фичи основной кейс и сопутствующие ошибки мы обработали. Однако могли не проверить, все ли будет хорошо, если во время только что реализованного запроса приложение внезапно разлогинится.
В обыденной жизни разработчика и тестировщика разлогины провоцируются нажатием кнопки "Выйти" и в этом контролируемом флоу всё хорошо. Напротив, неожиданные разлогины – уютный пыльный угол под шкафом для целого зоопарка крешей, утечек, зависаний, и тараканов помельче.
Чтобы заставлять самих себя убираться и в труднодоступных местах тоже, сервис авторизации, который призван прозрачно обновлять устаревший токен, иногда поступает ровно наоборот и портит хороший. В течение дня каждый разработчик пару раз разлогинивается в самых неожиданных местах.
С помощью этого хаоса мы узнали курьезные факты про замену рутового контроллера у UIWindow. Он утекает, если на момент замены он модально перезентит на себе другой контроллер или поповер и даже не важно, если на момент замены уже идет анимация их закрытия.
Больше рукотворного хаоса у нас пока нет, но есть хотелка добавить ещё один для общения с файловой системой, благо всё I/O осуществляется централизованно через специальный компонент. Будем готовы к побитым файлам кешей и проверяться на эти кейсы не только в ручном режиме.
