Хаос-инжиниринг для Rust: как сделать приложение неубиваемым

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

Ваш Rust-сервер идеален? Давайте это проверим

Вы написали на Rust сервер, который обрабатывает тысячи запросов в секунду. Компилятор доволен, clippy молчит, тесты проходят. Но что случится, если внезапно отключится база данных? Или сетевая карта начнёт «глючить»? Или диск переполнится?

В традиционном тестировании мы проверяем, что код работает как задумано. Chaos engineering — это про другое: мы проверяем, что система выживает вопреки всему. И Rust, с его акцентом на надёжность и производительность, — идеальная площадка для таких экспериментов.

Эта статья — не скучный пересказ документации. Мы пройдём путь от теории до практики: я покажу, как внедрить chaos engineering для Rust приложений с помощью реальных инструментов и кода.

Что такое Chaos Engineering и зачем это Rust-разработчику?

Chaos engineering — это дисциплина экспериментов над распределённой системой, направленная на выявление её слабых мест до того, как они проявятся в production. Netflix, который считается пионером этого подхода, использует инструмент Chaos Monkey для случайного отключения серверов.

Почему это важно именно для Rust? Потому что Rust часто выбирают для критически важных систем:

Сетевые сервисы (прокси, балансировщики, API-шлюзы)
Встраиваемые системы (IoT, автомобили)
Блокчейн-ноды и финансовые системы
Потоковая обработка данных

Во всех этих случаях цена ошибки высока. Chaos engineering помогает убедиться, что ваше приложение на Rust переживёт не только штатную нагрузку, но и хаос реального мира.

Инструменты для Chaos Engineering в экосистеме Rust

Хотя экосистема Rust моложе, чем у Java или Go, у нас уже есть несколько зрелых библиотек для внедрения хаоса.

Инструмент	Назначение	Статус
`tokio-rs/bytes`	Эмуляция сетевых задержек	Активный
`fault-injection`	Внедрение паник и ошибок	Стабильный
`simulation`	Эмуляция отказов диска/сети	Экспериментальный
`chaostoolkit`	Фреймворк для сценариев хаоса	Поддержка через HTTP API

Мы сосредоточимся на практическом примере с использованием fault-injection и эмуляции сетевых проблем.

Практический пример: «Потуши пожар» в Rust-сервисе

Допустим, у нас есть простой HTTP-сервер на axum, который что-то делает (например, обращается к внешнему API). Мы хотим проверить, как он поведёт себя, если внешний сервис станет недоступен или начнёт отвечать с задержкой.

Шаг 1: Базовый сервер с «дырой»

Напишем сервер, который делает запрос к httpbin.org (имитация внешнего сервиса):

use axum::{Router, routing::get, response::Json};
use reqwest::Client;
use std::sync::Arc;
use serde_json::Value;

#[tokio::main]
async fn main() {
    let client = Arc::new(Client::new());

    let app = Router::new()
        .route("/fetch", get(handler))
        .with_state(client);

    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())
        .serve(app.into_make_service())
        .await
        .unwrap();
}

async fn handler(client: Arc<Client>) -> Result<Json<Value>, (StatusCode, String)> {
    let resp = client.get("https://httpbin.org/uuid")
        .timeout(std::time::Duration::from_secs(5))
        .send()
        .await
        .map_err(|e| (StatusCode::SERVICE_UNAVAILABLE, e.to_string()))?;

    let json = resp.json::<Value>()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok(Json(json))
}

Этот код работает, пока httpbin.org отвечает. Но в реальном мире внешние сервисы падают. Давайте проверим наше приложение на прочность.

Шаг 2: Внедряем хаос с помощью fault-injection

Библиотека fault-injection позволяет добавлять «ловушки» в код, которые можно активировать по условию. Установим её:

[dependencies]
fault-injection = "0.4"

Теперь модифицируем обработчик, чтобы он мог «зависать» или возвращать ошибки при определённых условиях:

use fault_injection::{inject_fault, Fault};

async fn handler(client: Arc<Client>) -> Result<Json<Value>, (StatusCode, String)> {
    // Внедряем задержку с вероятностью 10%
    inject_fault!(Fault::Latency {
        probability: 0.1,
        min_duration: std::time::Duration::from_secs(2),
        max_duration: std::time::Duration::from_secs(5),
    });

    // Внедряем панику с вероятностью 5%
    inject_fault!(Fault::Panic {
        probability: 0.05,
        message: "Chaos monkey strikes!",
    });

    // Код как был...
    let resp = client.get("https://httpbin.org/uuid")
        .timeout(std::time::Duration::from_secs(5))
        .send()
        .await
        .map_err(|e| (StatusCode::SERVICE_UNAVAILABLE, e.to_string()))?;

    let json = resp.json::<Value>()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok(Json(json))
}

Теперь при каждом запросе с вероятностью 10% сервер «задумается» на 2-5 секунд, а с вероятностью 5% — упадёт с паникой. Это и есть injection fault — базовый приём chaos engineering.

Шаг 3: Наблюдаем и исправляем

Если мы запустим такой сервер в production (не делайте так!), клиенты начнут жаловаться на таймауты и ошибки. Но в тестовой среде это даёт нам данные: